
- •Часть 1. Планирование архитектуры
- •Заключение
- •Дополнительная литература
- •4.10. Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 6. Управление воздушным движением. Пример разработки, ориентированной на высокую готовность
- •Глава 7. Проектирование архитектуры
- •Глава 8. Моделирование условий полета. Конкретный пример архитектуры, ориентированной на интегрируемость
- •8.4. Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 9. Документирование программной архитектуры
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 10. Реконструкция программной архитектуры
- •Глава 11. Метод анализа компромиссных архитектурных
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 12. Метод анализа стоимости и эффективности — количественный подход к принятию
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 13. Всемирная паутина. Конкретный пример реализации способности к взаимодействию 374
- •Глава 14. Линейки программных продуктов.
- •Заключение
- •Дополнительная литература
- •Глава 15. CelsiusTech. Конкретный пример разработки
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Заключение
- •Часть 1. Планирование архитектуры
- •Часть 2. Создание архитектуры
- •Часть 3. Анализ архитектуры
- •Часть 4. От одной системы к множеству
- •Часть 1
- •Глава 1
- •1.1. Откуда берутся варианты архитектуры?
- •1.2. Программный процесс и архитектурно-экономический цикл
- •1.3. Из чего складывается «качественная» архитектура?
- •1.4. Заключение
- •1.5. Дискуссионные вопросы
- •Глава 2
- •2.1. Чем является программная архитектура и чем она не является
- •2.2. Другие взгляды на архитектуру
- •2.3. Архитектурные образцы, эталонные модели и эталонные варианты архитектуры
- •2.4. Почему программная архитектура так важна?
- •2.5. Архитектурные структуры и представления
- •2.6. Заключение
- •2.7. Дополнительная литература
- •2.8. Дискуссионные вопросы
- •Глава 3
- •3.1. Связь с архитектурно-экономическим циклом
- •3.2. Требования и атрибуты качества
- •3.3. Архитектура авиационной электронной системы а-7е
- •3.4. Заключение
- •3.5. Дополнительная литература
- •3.6. Дискуссионные вопросы
- •Часть 2
- •Глава 4
- •4.1. Функциональность и архитектура
- •4.2. Архитектура и атрибуты качества
- •4.3. Атрибуты качества системы
- •4.4. Практическое применение сценариев атрибутов качества
- •4.5. Другие атрибуты качества системы
- •4.6. Коммерческие атрибуты качества
- •4.7. Атрибуты качества архитектуры
- •4.8. Заключение
- •4.9. Дополнительная литература
- •4.10. Дискуссионные вопросы
- •Глава 5
- •5.1. Определение тактики
- •5.2 Тактики реализации готовности
- •5.3. Тактики реализации модифицируемости
- •5.4. Тактики реализации производительности
- •5.5. Тактики реализации безопасности
- •5.6. Тактики реализации контролепригодности
- •5.7. Тактики реализации практичности
- •5.8. Взаимосвязь тактик и архитектурных образцов
- •5.9. Архитектурные образцы и стили
- •5.10. Заключение
- •5.11. Дополнительная литература
- •5.12. Дискуссионные вопросы
- •Глава 6
- •6.1. Связь с архитектурно-экономическим циклом
- •6.2. Требования и атрибуты качества
- •6.3. Архитектурное решение
- •6.4. Заключение
- •6.5. Дополнительная литература
- •6.6. Дискуссионные вопросы
- •Глава 7
- •7. 1. Архитектура в контексте жизненного цикла
- •7.2. Проектирование архитектуры
- •1. Выбор модуля для декомпозиции
- •2А. Выбор архитектурных мотивов
- •2Ь. Выбор архитектурного образца
- •2D. Задание интерфейсов дочерних модулей
- •7.3. Формирование рабочих групп
- •7.5. Заключение
- •7.6. Дополнительная литература
- •7.7. Дискуссионные вопросы
- •Глава 8
- •8.1 Связь с архитектурно- экономическим циклом
- •8.2. Требования и атрибуты качества
- •8.3. Архитектурное решение
- •8.2 Заключение
- •8.5 Дополнительная литература
- •8.6. Дискуссионные вопросы
- •Глава 9
- •9.1. Варианты применения архитектурной документации
- •9.2. Представления
- •9.3 Выбор значимых представлений
- •9.4. Документирование представления
- •9.5. Перекрестная документация
- •9.6. Унифицированный язык Моделирования
- •9.7. Заключение
- •9.8. Дополнительная литература
- •9.9. Дискуссионные вопросы
- •Глава 10
- •10.1. Введение
- •10.2. Извлечение информации
- •10.3. Создание базы данных
- •10.4. Объединение представлений
- •10.5. Реконструкция
- •10.6. Пример
- •10.7. Заключение
- •10.8. Дополнительная литература
- •10.9. Дискуссионные вопросы
- •Часть 3
- •Глава 11
- •Результаты проведения оценки по методу атам
- •Этапы atam
- •1 Источник: приводится по изданию [Clements 02а] (адаптированная версия).
- •11.4. Система Nightingale: конкретный пример проведения оценки по методу атам
- •11.5. Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 12
- •Результаты оценки по методу свам
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 13
- •13.1. Отношение к архитектурноэкономическому циклу
- •13.4. Еще одна итерация архитектурноэкономического цикла: эволюция вариантов веб-архитектуры систем электронной коммерции
- •13.7. Заключение
- •13.8. Дополнительная литература
- •13.9. Дискуссионные вопросы
- •Часть 4
- •Глава 14
- •За счет чего работают линейки программных продуктов?
- •Варианты архитектуры линеек продуктов
- •Факторы, усложняющие применение линеек программных продуктов
- •Заключение
- •Дополнительная литература
- •Дискуссионный вопрос
- •Глава 15
- •Связь с архитектурноэкономическим циклом
- •Требования и атрибуты качества
- •Архитектурное решение
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 16
- •Связь с архитектурноэкономическим циклом
- •16.3. Архитектурное решение
- •16.4. Решения по размещению системы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 17
- •17.2. Требования и атрибуты качества
- •17.3. Архитектурное решение
- •17.4. Механизм реализации атрибутов качества в архитектуре Luther
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 18
- •18.1. Воздействие компонентов на архитектуру
- •18.2. Архитектурное несоответствие
- •18.3. Компонентное проектирование как поиск
- •18.4. Пример приложения aseilm
- •18.5. Заключение
- •18.6. Дополнительная литература
- •Глава 19
- •19.1. Снова архитектурноэкономический цикл
- •19.2. Создание архитектуры
- •19.3. Архитектура в рамках жизненного цикла
- •Влияние коммерческих компонентов
- •Заключение
- •8 Все перечисленные специалисты работают в корпорации Inmedius (Питтсбург, сша).
Глава 6
Управление воздушным движением.
Пример разработки, ориентированной на высокую готовность.
В течение целых десяти лет Федеральное авиационное агентство пыталось заменить стремительно старевшую систему управления воздушным движением и все это время сталкивалось с проблемой сложности выполнения поставленной задачи. Новый проект под названием «Комплексная система автоматизации» (AAS) полностью отвечает всем требованиям, которые предъявляются к вычислительным системам в 1990-е годы. Программа, в которой больше миллиона строк, распределяется между многими сотнями компьютеров и встраивается в новое, модернизированное оборудование, которое, в свою очередь, должно круглосуточно реагировать на непредсказуемые, поступающие в реальном времени события. Минимальный сбой в такой ситуации потенциально угрожает общественной безопасности.
В. Вейт Гиббс [Gibbs 94]
К программным приложениям управления воздушным движением (Air Traffic Control, АТС) предъявляются невероятно высокие требования. Они должны работать в жестких условиях реального времени (hard real time) — иначе говоря, безусловно соответствовать временным ограничениям; выполнять особые требования к безопасности (safety critical) — из-за неправильной работы системы могут погибнуть ЛЮДИ; кроме того, они относятся к категории сверхраспределенных (highly distributed) — для ведения самолетов по авиалиниям требуется сотрудничество десятков диспетчеров. Коммерческие, частные и военные воздушные суда пользуются воздушным пространством Соединенных Штагов интенсивнее, чем во всех остальных странах, — соответственно, на эту сферу обращено серьезное общественное внимание. Но безопасностью проблемы не исчерпываются ~ правительство тратит на построение и сопровождение хорошо защищенных. надежных систем управления воздушным движением огромные деньги. Стоимость разработки системы АТС исчисляется миллиардами и даже десятками миллиардов долларов.
В настоящей главе мы рассмотрим конкретный пример одного из элементов спроектированной недавно системы управления воздушным движением нового поколения, разработанной в СШ А. Мы увидим, как за счет архитектуры — в частности, набора тщательно отобранных проекций (см. главу 2) и тактик (см. главу 5) ее разработчикам удалось добиться выполнения серьезных разнородных требований. За недостатком финансирования систему так и не ввели в действие, однако ее реализация явственно продемонстрировала соответствие всем поставленным качественным задачам.
Управлением воздушным движением в Соединенных Штатах занимается Федеральное авиационное агентство (Federal Aviation Administration, FAA) — правительственное учреждение, отвечающее за общую безопасность полетов. Именно оно и выступило заказчиком описанной ниже системы. Безопасность прохождения самолета по авиалиниям и через наземные средства обслуживания обеспечивается во взаимодействии с различными элементами системы АТС. Координация передвижения самолета по территории аэропорта осуществляется службой наземного движения (ground control). Со специальных вышек координируется его перемещение в узловом диспетчерском районе (terminal control area) — цилиндрическом сегменте воздушного пространства с центром над аэропортом. Обязанности по обеспечению безопасности полетов в воздушном пространстве страны поделены между 22 районными центрами (en route centers).
Рассмотрим перелет из г. Ки-Уэст (Флорида) в аэропорт Далласа (Вашингтон, округ Колумбия). От стоянки до конца взлетно-посадочной полосы передвижение самолета координируется службой наземного движения Ки-Уэста. Во время взлета и набора высоты контроль переходит к диспетчерской вышке. С момента выхода самолета из узлового диспетчерского района Ки-Уэста он находится в зоне ответственности районного центра управления полетами Майами (он, помимо прочего, обязан контролировать полеты над Ки-Уэстом). Впоследствии управление полетом передается районным центрам Джексонвиля, Атланты и т. д. вплоть до того момента, как самолет входит в воздушное пространство, подконтрольное районному центру Вашингтона. Тот через какое-то время передает управление диспетчерской вышке аэропорта Далласа, которая берет на себя обязанности по координации захода рейса на посадку и приземления. Покинув взлетно-посадочную полосу, экипаж связывается со службой наземного движения, которая доводит самолет до стоянки. Эта схема работы систем управления воздушного движения в США сильно упрощена, однако для анализа нашего конкретного примера такого уровня детализации вполне достаточно. На рис. 6.1 приводится иллюстрация процесса передачи управления воздушным движением, а на рис. 6.2 — карта 22 американских районных центров управления полетами.
Система, обзор которой мы собираемся представить вашему вниманию, называется Основной системой контроля секторов (Initial Sector Suite System, ISSS). Изначально она предназначалась для замены устаревшего оборудования и программного обеспечения 22 районных центров управления полетами в США. Это лишь один из элементов крупномасштабного правительственного проекта, в результате поэтапной реализации которого аналогичные системы нового поколения предполагалось установить на диспетчерских вышках, в службах наземного движения и трансокеанских центрах управления полетами.
То обстоятельство, что ISSS задумывалась лишь как один из элементов набора близкородственных систем, оказало на ее архитектуру глубочайшее влияние. В частности, везде, где это возможно, разработчики должны были внедрять решения и элементы, предусматривающие возможность повторного применения в последующих системах. Как-никак, у систем в районных центрах управления полетами, на диспетчерских вышках и в службах наземного движения много общего: наличие интерфейсов для обмена данными с радиосистемами, базами планирования полетов и друг с другом, необходимость в обработке показаний РЛС, повышенные требования к надежности и производительности и т. д. Таким образом, проектные решения, реализованные в ISSS, в значительной степени обусловливались требованиями ко всем обновлявшимся системам. Весь набор модернизированных систем предполагалось назвать комплексной системой автоматизации (Advanced Automation System, AAS).
В конце концов от программы AAS отказались в пользу менее амбициозного и дорогостоящего, зато постепенного плана модернизации. Тем не менее конкретный пример системы ISSS до сих пор сохраняет свою ценность — дело в том, что, когда пришло известие об отмене проекта, проект и львиная доля кода уже были подготовлены. Более того, независимая группа аудиторов, обследовавшая архитектуру системы (равно как и большинство других ее аспектов), пришла к выводу о ее соответствии сформулированным требованиям. Наконец, система, впоследствии размещенная вместо ISSS, заимствовала у архитектуры последней множество элементов. Все эти обстоятельства позволяют говорить об архитектуре ISSS как о примере решения в высшей степени трудной задачи.