Взаимоотношения представлений

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

Единицами представления декомпозиции модулей в системе ISSS являются элементы конфигурации компьютерных программ (computer software con figuration items, CSCls). Они состоят из приложении, которые одновременно являются элементами представления процессов и клиент-серверного представления. Реализуется приложение в виде программ и пакетов на языке Ada, участвующих в кодовое представлении; в свою очередь, зги приложения и пакеты отображаются на потоки — единицы представления параллелизма (о нем мы не говорили). Многоуровневое представление описывает распределение функциональности между модулями в рамках представления декомпозиции и демонстрирует те элементы, к которым эти модули могут обращаться. Наконец, специализированное представление, направленное на реализацию конкретного атрибута качества периода прогона — представление отказоустойчивости, — предполагает участие элементов представления процессов, модульного и многоуровневого представлений.

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

Адаптационные данные

В ISSS широко используется тактика реализации модифицируемости под назва­нием «конфигурационные файлы», которая, согласно терминологии этой систе­мы, имеет и другое название — адаптационные данные. Конкретно-узловые адап­тационные данные присутствуют в 22 районных центрах управления полетами, в которых планировалось разместить систему ISSS. Так называемые предопреде­ленные адаптационные данные приспосабливают программные средства к изме­нениям, которые происходят в период разработки и размещения, но при этом не отражают различия между узлами. Адаптационные данные — это очень удобное и важное средство модифицирования системы согласно специфическим требова­ниям узлов, предпочтениям пользователей и центров, изменениям конфигура­ции и требований, а также многим другим аспектам программных средств, кото­рые допускают модификации с течением времени и в зависимости от узлов размещения. Проектное решение программного продукта допускает считывание рабочих параметров и поведенческих спецификаций с входных данных; таким образом, в отношении набора линий поведения, которые возможно представить в этих данных, программный продукт совершенно универсален (и отражает так­тику «обобщение модуля»), К примеру, для того чтобы реализовать новые требо­вания, согласно которым данные, ранее отображавшиеся в одном окне, следует разделить на два отдельных окна (во многих системах сделать это не так уж просто), достаточно внести изменения в адаптационные данные и отредактиро­вать несколько строк кода.

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

Уточнение тактики «общие абстрактные службы»: кодовые шаблоны для приложений

Как вы помните, согласно схеме «первичное/вторичные адресные пространства», отказоустойчивость достигается за счет резервирования — отдельные копии про­граммного продукта хранятся в разных процессорах. Во время исполнения пер­вичная копия регулярно отсылает всем вторичным копиям информацию о своем состоянии — делается это для того, чтобы при необходимости они могли взять на себя функции первичной копии. План реализации этих копий основывается на точных копиях одного и того же исходного кода (source code). Несмотря на то что первичная и вторичные копии никогда не выполняют одни и те же задачи в одно и то же время (первичная копия работает над исполнением своих обязанностей и отправляет вторичным копиям пакеты с обновлениями состояния; те, помимо того что получают эти пакеты, ожидают ситуаций, в которых им придется взять на себя обязанности основной копии), обе программы происходят от идентичных копий одного исходного кода. В расчете на это для каждого из приложений раз­работаны стандартные кодовые шаблоны; один из них приводится в листинге 6.1.

Соответствующая структура представляет собой непрерывный цикл, обслу­живающий входящие события. Если результатом поступления данного события должно стать выполнение приложением нормального (не связанного с обеспече­нием отказоустойчивости) действия, приложение выполняет это действие, а за­тем отправляет своим вторичным копиям информацию для обновления. Боль­шинство приложений обрабатывают от 50 до 100 нормальных событий. Среди Других возможных событий — передача (пересылка и прием) пакетов с инфор­мацией об обновлении состояния и данных. Наконец, еще один набор событий включает уведомления о принятии данным элементом обязанностей первичного адресного пространства и поступающие от клиентов запросы на обслуживание, ^не завершенное предыдущим (поврежденным в данный момент) первичным ад­ресным пространством.

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

Кодовые шаблоны — это не что иное, как уточненная версия тактики «общие абстрактные службы»; в шаблоне конкретизируются общие элементы каждого приложения. Эта тактика связана с рядом других тактик реализации модифицируемости. Относительно изменяемых элементов она отражает тактику «прогнозирование ожидаемых изменений», а процессам придает «семантическую связность» — дело в том, что все они при абстрактном рассмотрении выполняют одни и те же задачи. Шаблон позволяет программистам сконцентрироваться на деталях приложения, в результате чего реализуется тактика «обобщение модуля». Благодаря введению в шаблон интерфейсов и протоколов поддерживается стабильность интерфейсов и обеспечивается «применение предписанных протоколов».

Обзор методик и тактик, позволивших программной архитектуре системы ISSS реализовать задачи по качеству, приводится в табл. 6.1.

Листинг 6.1. Структурный кодовый шаблон для отказоустойчивых приложений ISSS terminates:= false

инициализировать приложение/протокол взаимодействия приложений запрос текущего состояния (запрос образа)

Loop

Get_event

Case Event_Type is

-- «нормальные» (не связанные с обеспечением отказоустойчивости) запросы -- на выполнение действий;

--их поступление возможно только в том случае, если данный элемент -- в настоящее время исполняет роль основного адресного пространства

when X=>Process X

отправка пакетов обновления состояния другим адресным пространствам

when Y=>Process Y

отправка пакетов обновления состояния другим адресным пространствам

...

when Terminate_Directive =>очистка ресурсов; terminate:= true

when State_Data_Update =>лрименяется к данным о состоянии

-- возможно только в том случае, если данный элемент является вторичным

-- адресным пространством, принимающим от первичного пространства,

-- выполнившего «нормальное действие», пакет с обновлениями

-- отправка, прием данных о состоянии

when Image_Request =>отправка новому адресному пространству данных

о текущем состоянии when State_Data_Image =>инициализация данных о состоянии

when Switch_Directive =>оповещение обслуживающих пакетов об изменении

ранга.

такие запросы поступают после перехода (переключения) вторичного -- адресного пространства в роль основного; они сообщают об обслуживании, запрошенном у старого (поврежденного) основного пространства, перешедшего в обязанности нового (текущего). основного пространства. Символами А,В и др. обозначаются имена клиентов

Recon__fгоm_А=>восстанавливает взаимодействие с А Recon_fгоm_В=>восстанавливает взаимодействие с В

when others=>log error

end case

exit when terminate

end loop

 

Заключение

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

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

♦ внесение серьезных изменений в человеко-машинный интерфейс консоли мониторинга и управления;

♦ импортирование в систему ISSS приложений для управления воздушным движением, разработанных сторонней компанией;

♦ введение в систему новых представлений управления воздушным движением;

♦ замена процессоров RS/6000 микросхемой с аналогичными характеристиками;

♦ исключение из списка требований электронной полетной ленты;

♦ 50-процентное увеличение максимальной нагрузки системы по обработке маршрутов полета.

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

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

Мероприятия, предпринятые Федеральным авиационным агентством США с целью модернизировать программное обеспечение управления воздушным движением, освещены в литературе достаточно широко; взять, например, исследование [Gibb 94]. Отчет о проверке системы ISSS на предмет возможности дальнейшего применения содержится в работе [Brown 95]. Удобство сопровождения в этих статьях понимается двояко: во-первых, как атрибут качества системы, а во-вторых, как способность организации-подрядчика выполнять задачи, связанные с сопровождением. Такой существенный аспект удобства сопровождения, как соответствие между потребностями системы в сопровождении и возможностями компании по проведению соответствующих действий, исследователи обычно упускают из виду

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

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

2. Сколько архитектурных образцов вы смогли обнаружить в архитектуре системы ISSS?

3. Согласно требованиям, перечисленным в разделе 6.2, составьте ряд сценариев атрибутов качества (см. главу 4). В тех случаях, когда каких-то сведений недостает, пытайтесь делать логические выводы.