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

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

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

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

Часть 2

СОЗДАНИЕ АРХИТЕКТУРЫ

В части 1 книги мы сформулировали определение архитектурно-экономического цикла (Architecture Business Cycle, ABC) и разобрались с основными понятиями, необходимыми для дальнейшего изучения программной архитектуры. В частности, мы установили факторы влияния на архитектора, проявляющиеся на начальных стадиях производства систем, и выяснили, что требования к тем или иным атрибутам качества — будь то производительность или модифицируемость — во многих случаях обусловливаются коммерческими задачами компании-разработчика. Так что же собой представляет процесс создания архитектуры архитектором? Об этом речь пойдет в части 2. Поскольку успех системы в значительной степени определяется реализацией атрибутов качества, мы начнем с рассмотрения качества и тех средств, при помощи которых архитектор способен его обеспечить.

Перефразируя Бута Таркингтона (Booth Tarkington), скажем, что качество — в глазах смотрящего. Заказчики не обязаны принимать решения архитектора с бурным восторгом — у них, в конце концов, могут быть свои представления о качестве. Инструментом объективной оценки качества являются сценарии атрибутов качества. В главе 4 мы рассмотрим различные составляющие качества, которые в тех или иных обстоятельствах оказываются значимыми для архитектуры. Для всех шести важнейших атрибутов (готовность, модифицируемость, производительность, безопасность, контролепригодность и практичность) мы представим методики составления сценариев, отражающих требования по качеству. Эти сценарии определяют степень значимости конкретного атрибута качества в контексте данной системы, и именно исходя из этой его оценки архитекторы и заказчики должны выносить суждения о проекте.

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

Глава 6 отводится под второй в книге конкретный пример — систему, разработанную по заказу Федерального авиационного агентства США и предназначенную для реализации функций управления воздушным движением. Эта система, к которой в процессе проектирования предъявлялись очень высокие требования по готовности (ограничивавшие простой пятью минутами в год), иллюстрирует применение тактик, перечисленных в главе 5.

Сценарии атрибутов качества и архитектурные тактики — это лишь некоторые из инструментов архитектора. В главе 7 мы обсудим, как эти инструменты применяются при проектировании архитектуры и создании макета системы; кроме того, мы проанализируем влияние архитектуры на структуру компании-разработчика.

В главе 8 рассматривается третий конкретный пример — система моделирования условий полета. От подобного рода систем требуется производительность в реальном времени и удобство модифицирования. Мы раскроем механизмы реализации этих задач.

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

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