Задача Неправильный перевод информации как причина ошибок в программных средствах
Работа добавлена на сайт bukvasha.net: 2015-10-29Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
уметь оценивать сложность системы по числу её элементов, а именно по числу потенциальных путей взаимодействия между её элементами, т. е. п!, где п - число её элементов. Систему назовем малой, если п < 7 (6! = 720 < 1000), систему назовем большой, если п > 7. При п=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Человек, создавший большую систему (систему требований, систему управления, программную систему и т. п.), рискует увязнуть в переборе большого числа вариантов. Задача технологии программирования - научиться делать большие системы простыми.
Полученная оценка простых систем по числу элементов широко используется на практике. Так, для руководителя коллектива весьма желательно, чтобы в нем не было больше шести взаимодействующих между собой подчиненных. Весьма важно также следовать правилу: всё, что может быть сказано, должно быть сказано в шести пунктах или меньше. Этому правилу мы будем стараться следовать в настоящем пособии: всякие перечисления взаимосвязанных утверждений (набор рекомендаций, список требований и т. п.) будут соответствующим образом группироваться и обобщаться. Полезно ему следовать и при разработке ПС.
2.2. Неправильный перевод информации как причина ошибок в программных средствах
При разработке и использовании ПС мы многократно имеем дело [35, с. 22-28] с преобразованием (переводом) информации из одной формы в другую (см. рис. 2.1). Заказчик формулирует свои потребности в ПС в виде некоторых требований. Исходя из этих требований, разработчик создает внешнее описание ПС, используя при этом спецификацию (описание) заданной аппаратуры и, возможно, спецификацию базового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является исходной информацией при любом ее преобразовании, в частности, при исправлении в ней ошибки.
Пользователь на основании документации выполняет ряд действий для применения ПС и осуществляет интерпретацию получаемых результатов. Везде здесь, а также в ряде других процессах разработки ПС, имеет место указанный перевод информации.
На каждом из этих этапов перевод информации может быть осуществлён неправильно. Возникнув на одном из этапов разработки ПС, ошибка в представлении информации преобразуется в новые ошибки результатов, полученных на последующих этапах разработки, и, в конечном счёте, окажется в ПС.
2.3. Модель перевода
Чтобы понять природу ошибок при переводе рассмотрим модель [35, с. 22-28], изображённую на рис. 2.2. На ней человек осуществляет перевод информации из представления А в представление В. При этом он совершает четыре основных шага перевода:
• он получает информацию, содержащуюся в представлении А, с помощью своего читающего механизма R;
• он запоминает полученную информацию в своей памяти М;
• он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
• с помощью этого механизма он фиксирует представление В.
На каждом из этих шагов человек может совершить ошибку разной природы. На первом шаге способность человека «читать между строк» (способность, которая часто оказывается полезной, позволяя ему понимать текст, содержащий неточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникает в том случае, когда при чтении документа А человек, пытаясь восстановить недостающую информацию, видит то, что он ожидает, а не то, что имел в виду автор документа А. В этом случае лучше было бы обратиться к автору документа за разъяснениями. При запоминании информации человек осуществляет её осмысливание (здесь важен его уровень подготовки и знание предметной области, к которой относится документ А). И, если он поверхностно или неправильно поймёт, то информацию он запомнит в искажённом виде. На третьем этапе забывчивость человека может привести к тому, что он может выбрать из своей памяти не всю преобразуемую информацию или не все правила перевода, в результате чего перевод будет осуществлён неверно. Это обычно происходит при большом объёме плохо организованной информации. И, наконец, на последнем шаге
стремление человека быстрее зафиксировать информацию часто приводит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной ее интерпретации.
2.4. Основные пути борьбы с ошибками
Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:
• сужение пространства перебора (упрощение создаваемых систем),
• обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),
• обеспечение однозначности интерпретации представления информации,
• контроль правильности перевода (включая и контроль однозначности интерпретации).
Вопросы к главе 2
2.1. Что такое простая и сложная системы!
2.2. Что такое малая и большая системы!
2.3. Перечислите основные шаги, осуществляемые человеком при переводе информации из одного представления в другое, и какого рода ошибки он может совершать на этих шагах?
Лучшее - враг хорошего.
Народная мудрость
Глава 3
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ
ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств. Жизненный цикл программного средства. Понятие качества программного средства. Обеспечение надёжности - основной мотив разработки программного средства. Методы борьбы со сложностью программных средств. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Обеспечение контроля правильности принимаемых решений.
3.1. Специфика разработки программных средств
Разработка программных средств имеет ряд специфических особенностей [22].
• Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а, как известно, переход от неформального к формальному существенно неформален.
• Разработка ПС носит творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым, эта разработка ближе к процессу проектирования каких-либо технических устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого её конца.
• Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т. е. статических объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т. е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приёмов, методов и средств.
• Продукт разработки имеет и другую специфическую особенность: ПС при своём использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.
Эти особенности превращают разработку программных средств в уникальный вид человеческой деятельности. Первая особенность означает, что разработка ПС является в значительной степени формализацией описаний требуемых процессов обработки данных, при этом сохраняется опасность, что полученное формальное описание будет недостаточно точно отражать неформальное описание требуемых процессов обработки данных. Вторая особенность позволяет заметить сходство разработки ПС с проектированием технического устройства, но это сходство продолжается до самого конца разработки ПС. Другими словами, можно сказать, что ПС является своим собственным проектом, а процесс его производства является вырожденным. В связи с этим весьма осторожно следует относиться к так называемому индустриальному подходу к разработке программных средств (точно так же, как бы мы относились к индустриальному подходу к проектированию). Третья особенность означает, что статическая форма представления программного продукта слишком мало говорит о его приемлемости для пользователя, ценности и надёжности. Всё это может быть выявлено только в результате его применения на компьютере. Четвёртая особенность отражает уникальные свойства информации: ПС как информационный объект после каждого его применения сохраняется в неизменном состоянии (не уменьшается, не «устает», не «стареет»). Его надёжность не связана со временем или интенсивностью его применения. Каждое его применение связано с работой компьютера, на котором ПС для выполнения своих функций использует память, каналы ввода и вывода и другие ресурсы компьютера. После применения этого ПС все эти ресурсы сохраняются в компьютере и могут использоваться при применении другого ПС.
3.2. Жизненный цикл программного средства
Под жизненным циклом ПС {software
life
cycle
) понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [22, 24, 25, 44]. Жизненный цикл охватывает довольно сложный процесс создания и использования ПС. Этот процесс может
быть организован по-разному для разных классов ПС и в зависимости от особенностей коллектива разработчиков.
В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС [65].
• Водопадный подход. При таком подходе разработка состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС.
• Исследовательское программирование. При этом подходе предполагается быстрая (насколько это возможно) реализация рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей. Такой подход применялся на ранних этапах развития программирования, когда технологии программирования не придавали большого значения (использовалась интуитивная технология). В настоящее время этот подход применяется для разработки таких ПС, для которых пользователи не могут точно сформулировать требования (например, для разработки систем искусственного интеллекта).
• Прототипирование (разработка прототипа). Этот подход моделирует начальную фазу исследовательского программирования (вплоть до создания рабочих версий программ, предназначенных для проведения экспериментов) с целью установить требования к ПС. В дальнейшем должна последовать разработка ПС по установленным требованиям в рамках какого-либо другого подхода (например, водопадного).
• Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется компьютерная технология (CASE-технология) разработки ПС.
• Сборочное программирование. При этом подходе предполагается, что ПС конструируется, главным образом, из программных компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются
повторно используемыми {
reusable
). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования [32].
В дальнейшем мы в основном будем рассматривать водопадный подход с некоторыми модификациями. Во-первых, потому, что в этом подходе приходиться иметь дело с большинством процессов программной инженерии, а во-вторых, потому, что в рамках этого подхода создается большинство больших программных систем. Именно этот подход рассматривается в качестве индустриального подхода разработки программного обеспечения. Исследовательское программирование исходит из взгляда на программирование как на искусство. Оно применяется, когда не удается точно сформулировать требования к ПС (когда водопадный подход не применим). В нашей книге мы этот подход рассматривать не будем. Прототипирование рассматривается как вспомогательный подход, используемый в рамках других подходов, в основном, для прояснения требований к ПС. Компьютерной технологии (включая обсуждение жизненного цикла ПС, созданного по этой технологии) будет посвящена отдельная глава. Сборочное программирование мы также рассматривать не будем, хотя о повторно используемых программных модулях мы говорить будем, обсуждая свойства программных модулей.
В рамках водопадного подхода различают следующие стадии жизненного цикла ПС (см. рис. 3.1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.
Стадия разработки ПС {software
development
) состоит из этапов его внешнего описания, конструирования ПС, кодирования (программирование в узком смысле) ПС и аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управления ПС {software
manage
ment
). Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Этап внешнего описания ПС включает процессы, приводящие к созданию документа, который мы будем называть внешним описанием ПС {software
requirements
document
). Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со сто-
роны пользователей (заказчика), а также включает процессы спецификации этих требований.
Рис. 3.1. Структура жизненного цикла ПС
Конструирование ПС {
software
design
) охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.
Кодирование ПС {
software
coding
) включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС.
На этапе аттестации ПС {software
certfication
) производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается законченной. Это обычно оформляется в виде документа, фиксирующего решение комиссии, проводящей аттестацию ПС.
Программное изделие (ПИ) - экземпляр или копия разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [22]. Стадия производства ПИ в жизненном цикле ПС является, по существу, вырожденной (не сущест-
венной), так как представляет собой рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники, поэтому в литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [44, 65].
Применение ПС (
software
operation
) - это использование ПС для решения практических задач на компьютере путём выполнения его программ.
Сопровождение ПС (
software
maintenance
) - это процесс сбора информации о качестве ПС в эксплуатации, устранения обнаруженных в нём ошибок, его доработки и модификации, а также извещения пользователей о внесённых в него изменениях [22, 44, 65].
3.3. Понятие качества программного средства
Каждое ПС должно выполнять определённые функции, т. е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течение длительного периода, т. е. обладать определённым качеством. Качество (quality) ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданным потребностям пользователей [59]. Из этого определения не следует, что разные ПС должны обладать одной и той же совокупностью таких свойств с их наилучшими показателями, поскольку улучшение одного из таких свойств ПС часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и ухудшения других свойств этого ПС. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, в какой гарантируется успешное его использование.
Совокупность свойств, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т. е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС (criteria of software quality) принято считать [7, 30,49,59,63]:
• лёгкость применения,
• надёжность,
• функциональность,
• эффективность,
• сопровождаемость,
• мобильность.
Функциональность (
functionality
) ПС - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Этот набор определяется во внешнем описании ПС.
Надёжность ПС подробно обсуждалась в первой главе.
Лёгкость применения (
easy
of
use
) ПС - это характеристики ПС, позволяющие минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывающие положительные эмоции определённого или подразумеваемого пользователя.
Эффективность (
efficiency
) ПС - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объёму используемых ресурсов.
Сопровождаемость (
maintainability
) ПС - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нём ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность (
portability
) ПС - это способность ПС быть перенесённым из одной среды применения в другую, в частности, с одного компьютера на другой.
Функциональность и надёжность являются обязательными критериями качества ПС, причем обеспечение надёжности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС. Обеспечение этих критериев будет обсуждаться в подходящих частях книги.
3.4. Обеспечение надёжности - основной мотив разработки программных средств
Рассмотрим теперь общие принципы обеспечения надёжности ПС, что является основным мотивом разработки ПС, задающим специфиче-
скую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности [35]:
• предупреждение ошибок,
• самообнаружение ошибок,
• самоисправление ошибок,
• обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах (в нашем случае - в ПС) или хотя бы свести их количество к минимуму. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
• упрощение создаваемой ПС,
• обеспечение точности перевода,
• преодоление барьера между пользователем и разработчиком в понимании информации, которой они обмениваются,
• обеспечение контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т. е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надёжности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе её выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе её выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако эти подходы используются весьма редко (относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, до-
бавление в программу дополнительных фрагментов приводит к ее усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.
3.5. Методы упрощения создаваемой ПС
Мы уже обсуждали в главе 2 сущность вопроса упрощения систем при разработке ПС. Известны два общих метода упрощения систем:
• обеспечения независимости компонент системы,
• использование в системах иерархических структур.
Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование. Использование в системах иерархических структур позволяет локализовать связи между компонентами, допуская их лишь между компонентами, принадлежащими смежным уровням иерархии. Этот метод, по существу, означает разбиение большой системы на подсистемы, образующие малую систему. Здесь существенно используется способность человека к абстрагированию.
3.6. Обеспечение точности перевода
Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует при переводе информации придерживаться определённых правил (определённой дисциплины). Май-ере предлагает использовать общую дисциплину решения задач, рассматривая перевод как решение задачи [35]. Лучшим руководством по решению задач он считает книгу Пойа «Как решать задачу» [38]. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:
• обеспечение понимания задачи;
• составление плана (включая цели и методы решения);
• выполнение плана (с проверкой правильности каждого шага);
• анализ полученного решения.
Подробно обсуждать этот вопрос мы здесь не будем.
3.7. Преодоление барьера между пользователем и разработчиком
Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого разработчикам необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, знать его уровень подготовки и окружающую его обстановку. Ясное описание соответствующей сферы деятельности пользователя или интересующей его проблемной области во многом облегчает достижение разработчиками этой цели. При разработке ПС следует привлекать пользователя для участия в процессах принятия решений, а также тщательно освоить особенности его работы (лучше всего - побывать в его "шкуре").
3.8. Контроль принимаемых решений
Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после её возникновения, что существенно снижает стоимость её исправления и повышает вероятность правильного её устранения.
С учётом специфики разработки ПС необходимо применять везде, где это возможно,
• смежный контроль,
• сочетание как статических, так и динамических методов контроля.
Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон: во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут использовать полученный документ в качестве исходного в последующих технологических процессах. Такой контроль позволяет обеспечивать однозначность интерпретации полученного документа.
Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отражает одну из специфических особенность ПС (статическая форма, динамическое содержание).
Вопросы к главе 3
3.1. Что такое жизненный цикл ПС1
3.2. Что такое внешнее описание ПС1
3.3. Что такое сопровождение ПС!
3.4. Что такое качество ПС!
3.5. Что такое смежный контроль!
Не переходи мост, пока не дошёл до него. Народная пословица
Глава 4
ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО
СРЕДСТВА
Понятие внешнего описания, его назначение и роль в обеспечении качества программного средства. Определение требований к программному средству. Спецификация качества программного средства. Основные примитивы качества программного средства. Функциональная спецификация программного средства. Контроль внешнего описания.
4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства
Разработчикам больших программных средств (систем) приходится решать весьма специфические и трудные проблемы, особенно, если это ПС должно представлять собой программную систему нового типа, в плохо компьютеризированной предметной области. Разработка ПС начинается с процесса формулирования требований к ПС, в котором, исходя из довольно смутных пожеланий заказчика, должен быть создан документ, достаточно точно определяющий задачи разработчиков ПС. Этот документ мы называем внешним описанием ПС.
Очень часто требования к ПС путают с требованиями к процессам его разработки (технологическим процессам). Последние не следует включать во внешнее описание, если только они не связаны с оценкой качества ПС. В случае необходимости требования к технологическим процессам можно оформить в виде самостоятельного документа, который будет использоваться при управлении разработкой ПС.
Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Более того, оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС. Оно является исходным документом для трёх параллельно протекающих процессов: разработки текстов (конструированию и кодированию) программ, входящих в ПС, разработки документации по применению ПС и разработки существенной части комплекта тестов для тестирования ПС. Ошибки и неточности во
внешнем описании, в конечном счёте, трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три упомянутые параллельных процесса. Это требует принятия особенно серьёзных мер по их предупреждению.
Исходным документом для разработки внешнего описания ПС является определение требований к ПС. Через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, поэтому формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком. Трудности, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в "узких" местах деятельности пользователей может на самом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадываются). Кроме того, проблемы, которые необходимо отразить в определении требований, могут не иметь определённой формулировки [65], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо "заказываемое" ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда бывает полезным разработка упрощенной версии требуемого ПС, называемую прототипом ПС. Анализ "пробного" применения прототипа позволяет выявить действительные потребности пользователей и существенно уточнить требования к ПС.
В определении внешнего описания сразу бросаются в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [35], которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (ее часто называют нефункциональной спецификацией [65], но в этом случае она включает и требования к технологическим процессам). Она, в отличие от функцио-
нальной спецификации, представляется в неформализованном виде и играет роль тех ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ требуемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС.
Обычно разработка спецификации качества предшествует разработке функциональной спецификации ПС, так как некоторые требования к качеству ПС могут предопределять включение в функциональную спецификацию специальных функций, например, функции защиты от несанкционированного доступа к информационной среде. Таким образом, структуру внешнего описания ПС можно выразить формулой: внешнее описание ПС = определение требований к ПС + спецификация качества ПС + функциональная спецификация ПС
Внешнее описание определяет, что должно делать ПС и какими внешними свойствами оно должно обладать. Оно не отвечает на вопросы, как обеспечить требуемые внешние свойства ПС и как это ПС должно быть устроено. Внешнее описание должно достаточно точно и полно определять задачи, которые должны решить разработчики требуемого ПС. В то же время оно должно быть понято представителем пользователей - на его основании заказчиком достаточно часто принимается окончательное решение на заключение договора на разработку ПС. Внешнее описание играет большую роль в обеспечении требуемого качества ПС, так как спецификация качества ставит для разработчиков ПС конкретные ориентиры, управляющие выбором приемлемых решений при реализации специфицированных функций.
4.2. Определение требований к программному средству
Определение требований к ПС являются исходным документом разработки ПС - заданием, отражающим в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования. Неправильное понимание потребностей пользователя трансформируются в ошибки внешнего описания. Поэтому разработка ПС начинается с создания документа, достаточно полно характеризующего потребности пользователя и позволяющего разработчику адекватно воспринимать эти потребности.
Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь должна быть понятной пользователю, не ориентирующемуся в специальных программистских понятиях. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, с математической подготовкой) - формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования [65]. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т. п.) и характеристики связей между ними.
Известны три способа разработки определения требований к ПС [35]:
• управляемая пользователем разработка,
• контролируемая пользователем разработка,
• независимая от пользователя разработка.
В управляемой пользователем разработке, определения требований к ПС формулируются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. Роль разработчика ПС в создании этих требований состоит, в основном, в выяснении того, насколько понятны ему эти требования, и в соответствующей критике рассматриваемого документа. Это может приводить к созданию нескольких редакций этого документа в процессе заключения указанного договора.
В контролируемой пользователем разработке, требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС, а также к контролю того, чтобы формулируемые требования действительно выражали его потребности в
ПС. Разработанные требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке, требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчёте на то, что разработанное им ПС найдёт спрос на рынке программных средств.
С точки зрения обеспечения надёжности ПС наиболее предпочтительным является контролируемая пользователем разработка.
4.3. Спецификация качества программного средства
Разработка спецификации качества сводится, по существу, к построению своеобразной модели качества требуемого ПС [22, 35]. В этой модели должен быть перечень всех тех свойств, которые необходимо обеспечить в этом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной мере конкретизировано с учётом определения требований к ПС, а также с учётом возможности оценки его наличия у разработанного ПС или оценки степени, в которой ПС обладает этим свойством.
Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС, разработанных ISO [7, 22, 59, 63], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.
Функциональность: завершённость.
Надёжность: завершённость, точность, автономность, устойчивость, защищённость.
Лёгкость применения: П-документированность, информативность (применительно к документации по применению), коммуникабельность, устойчивость, защищённость.
Эффективность: временная эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам.
Сопровождаемоеть. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифици-
руемость. Изучаемость - это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость - это характеристики ПС, которые позволяют автоматически настраивать на условия применения ПС или упрощают внесение в него вручную необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, лёгкость изменения, структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность.
Ниже определяются используемые примитивы качества ПС [22, 59, 63]. Здесь приводится достаточно большой список, состоящий из 19 примитивов качества, которые следует рассматривать как независимые (самостоятельные) понятия. Некоторые их комбинации образуют более крупные понятия - критерии и подкритерии качества. Такие комбинации можно рассматривать как определённые системы. Но ни одна из этих комбинаций не содержит более шести примитивов (см. выше), так что правило, сформулированное в п. 2.1, здесь не нарушается.
Завершённость {
completeness
) ПС - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность {
accuracy
) ПС - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.
Автономность {
self
-
containedness
) ПС - свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость {
robustness
) ПС - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Защищённость {
defensiveness
) ПС - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
П-документированностъ {и.
documentation
) ПС - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность
учебной, инструктивной и справочной документации, необходимой для применения ПС.
Информативность {
accountability
) ПС - свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений, существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.
Коммуникабельность {
communicativeness
) ПС - свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, и способность выдавать полезные сведения в достаточно простой форме и с простым для понимания содержанием.
Временная эффективность {
time
efficiency
) ПС - мера, характеризующая способность ПС выполнять возложенные на него функции в течение определённого отрезка времени.
Эффективность по ресурсам {
resource
efficiency
) ПС - мера, характеризующая способность ПС выполнять возложенные на него функции при определённых ограничениях на используемые ресурсы (память).
Эффективность по устройствам {
device
efficiency
) ПС — мера, характеризующая экономичность использования устройств компьютера для решения поставленной задачи.
С-документированность ПС {
documentation
) - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данного ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.
Понятность {
understandability
) ПС - свойство, характеризующее степень, в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ISO [59], как согласованность, самодокументированность, четкость и, собственно, понятность (текстов программ).
Структурированность {
structuredness
) ПС - свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определённым образом (например, в соответствии с принципами структурного программирования).
Удобочитаемость (
readability
) ПС - свойство, характеризующее лёгкость восприятия текста программ ПС (отступы, фрагментация, фор-матированность).
Расширяемость (
augmentability
) ПС - свойство, характеризующее способность ПС к наращиванию объёма памяти для хранения данных или расширению функциональных возможностей отдельных компонент.
Лёгкость изменения (
modifiability
) ПС - мера, характеризующая ПС с точки зрения простоты внесения необходимых изменений и доработок на всех этапах и стадиях жизненного цикла ПС.
Модульность (
modularity
) ПС - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость ПС от устройств (
device
independence
) - свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях компьютеров).
4.4. Функциональная спецификация программного средства
С учётом назначения функциональной спецификации ПС и тяжёлых последствий неточностей и ошибок в этом документе, функциональная спецификация должна быть математически точной. Это не означает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать программы, решающие поставленную задачу. А означает лишь, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточно часто функциональная спецификация формулируется на естественном языке. Тем не менее, использование математических методов и формализованных языков при разработке функциональной спецификации весьма желательно, так что этим вопросам будет посвящена отдельная глава.
Функциональная спецификация состоит из трёх частей:
• описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;
• определение функций ПС, определённых на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС);
• описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы.
В первой части должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. Примером описания информационной среды может быть концептуальная схема базы данных или описание сети датчиков и приборов, которой должна управлять разрабатываемая ПС.
Во второй части вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты. И, наконец, определяется семантика каждой из этих функций, что является наиболее трудной задачей функциональной спецификации ПС. Обычно эта семантика описывается неформально на естественном языке - примерно так, как это делается при описании семантики многих языков программирования. Эта задача может быть в ряде случаев существенно облегчена при достаточно четком описании внешней информационной среды, если внешние функции задают какие-либо манипуляции с её объектами.
В третьей части должны быть перечислены все существенные случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (с точки зрения внешнего наблюдателя). Примером может служить обнаружение ошибки во время взаимодействия с пользователем, попытка применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в её спецификации, или получение результата, нарушающего заданное ограничение. Для каждого такого случая должна быть определена (описана) реакция ПС.
4.5. Методы контроля внешнего описания программного средства
Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля его правильности. Цель этого процесса состоит в поиске как можно большего числа ошибок, сделанных на этом этапе. Учитывая, что результатом этого
этапа будет, как правило, еще неформализованный текст, здесь на первый план выступают психологические факторы контроля. Можно выделить следующие методы контроля, применяемые на этом этапе:
• статический просмотр,
• смежный контроль,
• пользовательский контроль,
• ручная имитация.
Первый метод предполагает внимательное прочтение текста внешнего описания разработчиком с целью проверки его полноты и непротиворечивости, а также выявления других неточностей и ошибок.
Смежный контроль спецификации качества сверху - это её проверка со стороны разработчика требований к ПС, а смежный контроль функциональной спецификации - это её проверка разработчиками требований к ПС и спецификации качества. Смежный контроль внешнего описания снизу - это его изучение и проверка разработчиками архитектуры ПС и текстов программ, а также его изучение и проверка разработчиками документации по применению и разработчиками комплекта тестов.
Пользовательский контроль внешнего описания - это участие пользователя (заказчика) в принятии решений при разработке внешнего описания и его контроле. Если разработка требований к ПС велась под управлением пользователя, то пользовательский контроль внешнего описания, по существу, означает его смежный контроль сверху. Однако, если представителю пользователя оказывается трудно самостоятельно разобраться во внешнем описании, создается специальная группа разработчиков, выполняющая роль пользователя (и взаимодействующая с ним) для проведения такого контроля.
Ручная имитация представляет собой своеобразный динамический контроль внешнего описания, точнее говоря, функциональной спецификации ПС. Для этого необходимо подготовить исходные данные (тесты) и на основании функциональной спецификации осуществить имитацию поведения (работы) разрабатываемого ПС. При этом такую имитацию осуществляет специально назначенный разработчик, выполняющий, по существу, роль будущих программ ПС. Разновидностью такого контроля является имитация за терминалом. В этом случае данные вводятся в компьютер человеком, играющим роль пользователя, и они передаются с помощью несложной программы на другой терминал,
за которым сидит разработчик, играющий роль программ ПС. Полученные результаты передаются через компьютер на первый терминал.
Вопросы к главе 4
4.1. Что такое определение требований к ПС!
4.2. Что такое спецификации качества ПС!
4.3. Что такое устойчивость {robustness
) ПС!
4.4. Что такое защищённость (defensiveness
) ПС!
4.5. Что такое коммуникабельность {communicativeness
) ПС!
4.6. Что такое функциональная спецификация ПС!
А.1. Что такое ручная имитация внешнего описания ПС!
Разделяй и властвуй!
Латинское изречение
Глава 6 АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА
Понятие архитектуры и задачи её описания. Основные классы архитектур программных средств. Взаимодействие между подсистемами и архитектурные функции. Контроль архитектуры программных средств.
6.1. Понятие архитектуры программного средства
Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т. е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом упрощения создаваемой ПС, на котором реализуется принцип выделения относительно независимых компонент.
Основные задачи разработки архитектуры ПС:
• выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;
• определение способов взаимодействия между выделенными программными подсистемами.
С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация функциональных спецификаций, включая в необходимых случаях описание интерфейса между выделенными подсистемами и пользователем (пользовательского интерфейса).
6.2. Основные классы архитектур программных средств
Различают следующие основные классы архитектур программных средств [35]:
• цельная программа;
• комплекс автономно выполняемых программ;
• слоистая программная система;
• коллектив параллельно действующих программ.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну ка-
кую-либо ярко выраженную функцию, реализация которой не представляется слишком сложной. Описание такой архитектуры сводится, в основном, к описанию пользовательского интерфейса.
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
• любая из этих программ может быть активизирована (запущена) пользователем;
• при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
• все программы этого набора применяются к одной и той же информационной среде.
Таким образом, программы этого набора не взаимодействуют по управлению, а взаимодействие между ними осуществляется только через общую информационную среду.
Слоистая программная система состоит из упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
• на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев;
• каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определённый интерфейс, ничего не зная о внутреннем строении всех предшествующих слоев;
• каждый слой располагает определёнными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции.
Таким образом, в слоистой программной системе каждый слой может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [60]. Эта операционная система состоит из четырёх слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение централь-
ного процессора программам (процессам) в пакетном режиме. Только этот уровень осведомлён о мультипрограммных аспектах системы. На первом слое осуществляется управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не страничная) память. На втором слое осуществляется связь с консолью (пультом управления) оператора. Только этот слой знает технические характеристики консоли. На третьем слое осуществляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные программы не знают технических характеристик устройств ввода и вывода.
Прикладные программы
3: Управление входными и выходными потоками данных
2: Обеспечение связи с консолью оператора
1: Управление памятью
0: Диспетчеризация и синхронизация процессов
Компьютер
Рис. 6.1. Архитектура операционной системы THE
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производится их синхронизация. Обычно взаимодействие между такими процессами производится путём передачи друг другу некоторых сообщений.
Простейшей разновидностью такой архитектуры является конвейер. Возможности для организации конвейера имеются, например, в операционной системе UNIX [28]. Конвейер представляет собой последова-
тельность программ, в которой стандартный вывод каждой программы, кроме самой последней, связан со стандартным вводом следующей программы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступает на ввод первой программе, которая переработанное сообщение передаёт следующей программе, а сама начинает обработку очередного сообщения потока. Таким же образом действует каждая программа конвейера: получив сообщение от предшествующей программы и, обработав его, она передаёт переработанное сообщение следующей программе и приступает к обработке следующего сообщения. Последняя программа конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из п программ, может одновременно находиться в обработке до п сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение).
Рис. 6.2. Конвейер параллельно действующих программ
В общем случае коллектив параллельно действующих программ может быть организован в систему с портами сообщений. Порт сообщений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выдавать очередное сообщение другой программе по ее требованию. Сообщение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и использовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в порядке очереди не будет передано какой-либо программе по ее запросу. Таким образом, программа, передающая сообщение, не будет находиться в стадии ожидания, пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен принимающий порт).
Пример программной системы с портами сообщений приведен на рис. 6.3. Порт U может рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W - как порт выводных сообщений для этого коллектива программ.
Рис. 6.3. Пример программной системы с портами сообщений
Программные системы с портами сообщений могут быть как жёсткой конфигурации, так и гибкой конфигурации. В системах с портами жёсткой конфигурации каждая программа жёстко связывается с одним или с несколькими входными портами. Для передачи сообщения такая программа должна явно указать адрес передачи: имя программы и имя её входного порта. В этом случае при изменении конфигурации системы придётся корректировать используемые программы: изменять адреса передач сообщений. В системах с портами гибкой конфигурации с каждой программой связаны как входные, так и выходные виртуальные порты. Перед запуском такой системы должна производиться предварительная настройка программ по информации, задаваемой пользователем. Эта настройка производится с помощью специальной программной
компоненты, осуществляющей совмещение каждого выходного виртуального порта одной программы с каким-либо входным виртуальным портом другой. Тем самым, в этом случае при изменении конфигурации системы не требуется какой-либо ручной корректировки используемых программ. Однако в этом случае требуется иметь специальную программную компоненту, осуществляющую настройку системы.
6.3. Архитектурные функции
Для обеспечения взаимодействия между подсистемами в ряде случаев не требуется создавать какие-либо дополнительные программные компоненты (помимо реализации внешних функций) - для этого может быть достаточно заранее фиксированных соглашений и стандартных возможностей базового программного обеспечения (операционной системы). Так, в комплексе автономно выполняемых программ для обеспечения взаимодействия достаточно описания (спецификации) общей внешней информационной среды и возможностей операционной системы для запуска программ. В слоистой программной системе может оказаться достаточным спецификации выделенных программных слоев и обычного аппарата обращения к процедурам. В программном конвейере взаимодействие между программами также может обеспечивать операционная система (как это делается в операционной системе UNIX).
Однако в ряде случаев для обеспечения взаимодействия между программными подсистемами может потребоваться создание дополнительных программных компонент. Так, для управления работой комплекса автономно выполняемых программ часто создают специализированный командный интерпретатор, более удобный (в данной предметной области) для подготовки требуемой внешней информационной среды и запуска требуемой программы, чем базовый командный интерпретатор используемой операционной системы. В слоистых программных системах может быть создан особый аппарат обращения к процедурам слоя (например, обеспечивающий параллельное выполнение этих процедур). В коллективе параллельно действующих программ для управления портами сообщений требуется специальная программная подсистема. Такие программные компоненты реализуют не внешние функции ПС, а функции, возникшие в результате разработки архитектуры этого ПС для поддержки взаимодействия между выделенными программными подсистемами. Функцию, поддерживающую взаимодействие между программными подсистемами, выделенными в архи-
тектуре ПС, и выполняемую программной компонентой ПС, видимой из-вне ПС, будем называть архитектурной функцией.
6.4. Контроль архитектуры программных средств
Для контроля архитектуры ПС используется смежный контроль и ручная имитация.
Смежный контроль архитектуры ПС сверху - это её контроль разработчиками внешнего описания: разработчиками спецификации качества и разработчиками функциональной спецификации. Смежный контроль архитектуры ПС снизу - это ее контроль потенциальными разработчиками программных подсистем, входящих в состав ПС в соответствии с разработанной архитектурой.
Ручная имитация архитектуры ПС производится аналогично ручной имитации функциональной спецификации, только целью этого контроля является проверка взаимодействия между программными подсистемами. Так же, как и в случае ручной имитации функциональной спецификации ПС, должны быть сначала подготовлены тесты. Затем группа разработчиков должна для каждого такого теста имитировать работу каждой программной подсистемы, входящей в состав ПС. При этом работу каждой подсистемы имитирует один какой-либо разработчик (не автор архитектуры), тщательно выполняя все взаимодействия этой подсистемы с другими подсистемами (точнее, с разработчиками, их имитирующими) в соответствии с разработанной архитектурой ПС. Тем самым обеспечивается имитационное функционирование ПС в целом в рамках проверяемой архитектуры.
Вопросы к главе 6
6.1. Что такое архитектура ПС!
6.2. Какие классы архитектур Вы знаете?
6.3. Что такое архитектурная функция!
