Структура процессов

Третьей из ряда важнейших для системы А-7Е архитектурных структур является структура процессов. Модуль расширения компьютера содержит виртуальный интерфейс программирования с поддержкой мультипроцессорной обработки, хотя собственно бортовой компьютер А-7Е такой возможности не имеет. Предполагалось, что в определенный момент его заменят мультипроцессорным компьютером. Исходя из этого предположения, программное обеспечение было реализовано в виде набора сотрудничающих последовательных процессов, которые путем синхронизации (для взаимодействия друг с другом) получали возможность обращаться к совместно используемым ресурсам. При помощи неоперативного (пред-прогонного) планирования этот набор удалось сформировать как одиночный исполняемый поток, который впоследствии должен был загружаться на базовый компьютер.

Процессом называется набор программных шагов, повторяющихся в ответ на запускающее событие или временное ограничение. У него собственный поток управления, а в ожидании события он сам себя приостанавливает (обычно для этого вызывается одна из программ сигнализации о событиях интерфейса данного модуля).

Процессы в системе А-7Е создаются с двумя целями. Во-первых, с их помощью драйверы функций вычисляют для авиационной программной системы выходные значения. Исполняться они должны либо с определенной периодичностью (например, для беспрерывного обновления позиции символов на проекционном бортовом индикаторе), либо в ответ на какое-то запускающее событие (например, после нажатия пилотом кнопки сброса снаряда). Реализовывать эти действия в виде процессов вполне естественно. Обобщенно структуру процессов управления функциями можно представить следующим образом:

♦ Периодический процесс: запускается каждые 40 мс.

- В целях сбора всех значимых входных значений вызывает процедуры доступа других модулей.

- Вычисляет конечное выходное значение.

- Для отправки выходного значения окружению вызывает процедуру со- ответствующего модуля интерфейса устройства.

♦ Периодический процесс завершается.

♦ Процесс по требованию.

- Ожидание запускающего события.

- Процесс вычисляет конечное выходное значение.

- С целью запуска действия в окружении процесс запускает соответству- ющую процедуру модуля интерфейса устройства.

4- Процесс по требованию завершается.

Несколько реже процессы запускаются в целях реализации отдельных процедур доступа. Если издержки вычисления значения, возвращаемого процедурой доступа, оказываются непозволительно высокими, то, для того чтобы выдержать временные рамки, программист может организовать непрерывное фоновое вычисление значений и при вызове процедуры доступа возвращать последнее из них. К примеру, это может выглядеть так:

♦ Процесс: запускается каждые 100 мс.

- Для подсчета значения собирает входные данные.

- Подсчитывает значение.

- Сохраняет его в переменной most_recent.

♦ Процесс завершается.

♦ Процедура get_value(р!)

pi:= most_recent.

return

♦ Процедура завершается.

Итак, структура процессов состоит из набора программных процессов. Характерное для нее отношение «синхронизируется с...» основывается на событиях, о которых одни процессы сигнализируют, а другие этого ожидают. На этом отношении, в свою очередь, базируются операции планирования, и в том числе — предотвращение взаимоблокировки.

Методики неоперативного планирования, задействованные в программном обеспечении А-7Е, мы обсуждать не будем; сказать о них нужно лишь следующее: во-первых, они позволяют избежать непроизводительных издержек, свойственных оперативному планированию; во-вторых, они не могут существовать без информации, содержащейся в структуре процессов. Последняя также предусматривает оригинальный прием оптимизации — путем слияния двух, по большому счету несвязанных, процессов планирование во многих ситуациях упрощается,

а издержки контекстного переключения, которые имеют место при приостановке одного процесса и возобновлении другого, сводятся на нет. Эта методика, применяемая автоматически в период конструирования системы, скрыта от программистов. Роль структуры процессов в архитектуре А-7Е сформулирована в табл. 3.5.

Структура процессов появилась последней — уже после проектирования остальных структур. Процедуры модулей управления функциями были реализованы в виде процессов. Другие процессы в фоновом режиме выполняли продолжительные вычисления, обеспечивая готовность соответствующих значений.

В структуре процессов зафиксирована информация двух видов. Первый вид — это документация по процедурам, включенным в тела процессов. Она дает представление о проходящих через систему потоках и сообщает конструкторам перечень процедур, требующих реентерабельного кодирования (кодирования в расчете на способность одновременного ведения нескольких потоков управления), — для этого применяются защищенные хранилища данных или взаимное исключение. Кроме того, эта информация позволила проектировщикам понять, какие процедуры впоследствии будут запускаться чаще других, и, соответственно, определить области, перспективные в плане проведения оптимизации.

Второй вид информации в рамках структуры процессов предполагает документирование процессов (или последовательных сегментов потоков процесса), которые не могут исполняться одновременно. На самом деле области взаимного исключения окончательно фиксируются только после завершения кодирования процессов; и все же, исходя из выявленных на раннем этапе отношений «исключения» между объектами, участники группы планирования могут установить отдельные количественные требования к неоперативному планировщику и приступить к планированию в областях, в которых автоматизация должна была принести наибольший эффект.

УСПЕХ ИЛИ ПРОВАЛ?

В своей колонке редактора The Journal of Systems and Software за ноябрь 1998 года [Glass 98] Боб Гласс (Bob Glass) высказывает мнение, что проект А-7Е в конечном итоге провалился, поскольку рассмотренная в этой главе программная система так никогда и не заработала. Я очень уважаю Боба как личность и как специалиста, но в данном случае, уверен, он ошибается, пытаясь оценивать исследовательскую систему по коммерческим стандартам.

Что я имею в виду? У научного и предпринимательского сообществ разные культуры и разные критерии успеха. Взять хотя бы то, как представители этих сообществ «подают» себя клиентам. Предприниматели делают упор на надежность поставок, соблюдение временных

 

и финансовых ограничений. Вполне законными были бы претензии покупателя, если бы заказанный им автомобиль доставили в автосалон позже оговоренного срока, за более высокую цену и с нежелательными характеристиками.

Исследователи «выставляют на продажу» свои концепции. Так, в любом научно-исследовательском проекте описывается, каким образом в случае открытия финансирования этот проект изменит окружающий мир. Если окажется, что аналог результата исследований можно купить в соседнем супермаркете, у спонсора будут все основания выказывать недовольство. Обычно если спонсор видит, что выработанные в результате проведенных исследований идеи действительно способны в каком-то отношении изменить мир, он остается доволен.

Пусть эти характеристики немного шаблонны, но они, по большому счету, довольно точны. Потребителям коммерческих изделий часто нужны инновации. Заказчики научных исследований почти всегда хотят получения результатов. Представители обоих сообществ, стремясь обеспечить заключение контрактов, иногда прибегают к заведомо невыполнимым обещаниям. И тем не менее, по своей сути, представленные характеристики верны.

Назначение описанного в этой главе проекта А-7Е состояло в том, чтобы продемонстрировать всем скептикам жизнеспособность «объектно-ориентированных методик» (правда, назывались они в то время по-другому) применительно к конструированию высокопроизводительных программных систем реального времени. Это — задача, поставленная перед исследовательским проектом. Требовалось изменить тогдашнее видение мира. Успех программы по снижению стоимости программного обеспечения систем ВМС США (разработка системы А-7Е была его составной частью) с научной точки зрения не подлежит сомнению — доказательством тому сотни отзывов в профильных изданиях. Такую реакцию можно воспринимать как одобрение революционных по тем временам принципов инкапсуляции и сокрытия информации.

Итак, с коммерческой позиции система А-7Е потерпела неудачу, но по исследовательским меркам — это успех. Возвращаясь к утверждениям Боба Гласса, вопрос нужно поставить следующим образом: получило ли военно-морское ведомство тот результат, на который рассчитывало? Ответ зависит от того, о чем изначально шла речь: о производственной системе или о научной работе? Поскольку разработки проводились в научно-исследовательской лаборатории ВМС США, надо думать, что проект А-7Е следует оценивать по стандартам научного сообщества.

-LJB

Заключение

Мы рассмотрели архитектуру высокопроизводительной авиационной системы с точки зрения трех связанных, но различающихся структур. Структура декомпозиции модулей описывает отношения между компонентами — блоками реализации, которые распределяются между группами разработчиков, — в период проектирования. Структура использования описывает отношения использования между компонентами — процедурами и модулями — в период прогона. На основе этих сведений формируются очертания многоуровневой архитектуры. Структура процессов описывает параллелизм системы и является основой для их распределения между элементами аппаратной части.

Каждую из этих структур важно спроектировать как можно тщательнее — дело в том, что они закладывают основу для реализации трех атрибутов качества: 1) простоты изменения, 2) простоты извлечения подмножеств и 3) повышенных параллелизма и производительности. Не менее существенное значение имеет составление для каждой из этих структур комплексной документации, поскольку в других документах сведений о них не содержится. 

Несмотря на ортогональность упомянутых структур, они связаны — в моду, лях содержатся процедуры, которые, с одной стороны, обращаются друг к другу, а с другой — совместно работают’ в рамках процессов. Для системы А-7Е можно было задать и другие структуры — в частности, представление потока данных (представление «компонент и соединитель», вспомогательное по отношению к тем, что рассматривались в главе 2) могло бы выглядеть так, как показано на рис. 3.5. Все данные через модули интерфейсов устройств приходят из внешнего мира; затем, минуя этапы вычисления и модули хранения, они добираются до модулей управления функциями; те вычисляют выходные значения и отправляют их обратно соответствующим устройством. Проектировщики системы А-7Е, впрочем, считали представления потока данных ненужными. «Какой атрибут качества из тех, что не реализуют другие представления, помогает реализовать это?» — так они аргументировали свою позицию. Но мнения могут быть разными, и иные проектировщики, возможно, удостоят своего внимания представление потока данных. По сути своей, архитектурные представления призваны углублять знания о системе и ее свойствах, усиливать интеллектуальный контроль над ней. Если то или иное представление соответствует этим требованиям, значит, оно вам подойдет.

Помимо прочего, мы рассмотрели архитектуру в контексте атрибутов качества, которые проектировщики стремились реализовать, — заменяемости и понятности. В этой связи уместно привести тезис, аргументацией которого мы займемся в двух последующих главах: «варианты архитектуры отражают ряд желаемых атрибуте в качества».

Дополнительная литература

Документация по проекту авиационной электронной системы А-7Е содержится в работе [Parnas 85а). Анализ данных о внесенных в систему изменениях и описание этих изменений приводятся в исследованиях [Hager 91] и [Hager 891- Значительную часть материала о модульной структуре мы позаимствовали из руководства по модулям А-7Е, написанного Кэтрин Бриттон (Kathryn Britton) и Дэвидом Парнасом [Britton 81].

Дискуссионные вопросы

1. Предположим, что одна из версий программной системы А-7Е установлена на летном тренажере. На нем нет вооружения, а его функция заключается в обучении пилотов способам навигации при помощи бортовой электроники. Какие архитектурные структуры следовало модифицировать в процессе разработки такой системы и каким образом эти изменения нужно было внести?

2. В главе 7 мы обсудим архитектуру как основу для инкрементной разработки; этот способ предполагает постепенное наращивание системы и регулярное развертывание ее готовых подмножеств. Предположим, что даже самое небольшое подмножество программной системы А-7Е (корректно, согласно требованиям) выполняет некую функцию, результаты которой видны пилоту. (Скажем, отображает некоторое значение — например, выводит на бортовой индикатор текущий курс.) Какие модули требуются этому подмножеству и без каких можно обойтись? Предложите три инкрементных дополнения к нему и наметьте для них план разработки (иначе говоря, составьте перечень необходимых модулей).

3. Предположим, что для проверки правильности значений, хранящихся в банке данных и вычисляемых драйверами функций, в систему введен ряд контрольных блоков. В случае обнаружения несоответствия между хранимыми или вычисленными значениями, с одной стороны, и корректными значениями, которые определяются этими блоками, — с другой, они должны подавать сигнал об ошибке. Расскажите, какие изменения следует внести в каждую из архитектурных структур системы А-7Е в целях адаптации к этому решению? Если вы считаете необходимым введение дополнительных модулей, перечислите критерии сокрытия информации, по которым эти модули будут размещены в иерархической системе.