Описание архитектуры

Базовый уровень архитектуры, разработанный во время фазы проектирования,

сохраняется, как мы отмечали в подразделе «Базовый уровень архитектуры», в форме описания архитектуры. Это описание порождается теми версиями различных

моделей системы, которые были созданы в ходе фазы проектирования, как

это изображено на рис. 4.6. Описание архитектуры — это выдержка или, как мы

говорим, набор представлений — возможно, аккуратно приведенный в удобный для

чтения вид — моделей базового уровня архитектуры. Представления моделей содержат

существенные для архитектуры элементы. Множество элементов моделей,

входящих в базовый уровень архитектуры, разумеется, войдет также и в описание

архитектуры. Однако в описание архитектуры войдут не все элементы базового

уровня, потому что для получения работающего базового уровня мы вынуждены

были разработать некоторые элементы моделей, не существенные для архитектуры,

но необходимые для создания исполняемого кода. Так как базовый уровень

архитектуры используется не только для разработки архитектуры, но и для определения

требований к системе на таком уровне, когда возможно создание детального

плана, модель варианта использования этого базового уровня также может

содержать не только те варианты использования, которые важны для построения

архитектуры.

Описание архитектуры будет поддерживаться актуальным в течение всего времени

жизни системы, отражая вносимые изменения и дополнения, которые существенны

для архитектуры. Эти изменения обычно незначительны и могут включать

в себя:

О обнаружение новых абстрактных классов и интерфейсов;

О добавление новых функциональных возможностей к существующим подсистемам;

О обновление компонентов многократного использования до новых версий;

О перестройку структуры процесса.

Само описание архитектуры может нуждаться в изменении, но увеличиваться

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

(рис. 4.6). На рис. 4.6 заштрихованные фигуры справа вверху показывают разрастание

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

же почти не увеличивается (справа внизу), так как большая часть архитектуры

была определена еще на фазе проектирования. В архитектуре происходят

лишь незначительные изменения, обозначенные на рисунке различной

штриховкой.

Как говорилось ранее, описание архитектуры содержит представления моделей.

Они включают в себя варианты использования, подсистемы, интерфейсы,

некоторые классы и компоненты, узлы и кооперации. Описание архитектуры

также включает в себя важные для определения архитектуры требования, которые

не описываются вариантами использования. Это обычно нефункциональные

требования, определенные как дополнительные, например проблемы безопасности

и важные ограничения, касающиеся распределенного выполнения и параллельности

(приложение В, см. также подраздел «Артефакт: Класс проектирования

» главы 9).

Описание архитектуры должно также содержать краткое описание платформы,

наследуемых систем и используемого покупного программного обеспечения,

например Java RMI, для распределенных объектов. Кроме того, важно описать кар-__

касы, ответственные за обобщенные механизмы (приложение В; см. также подраздел

«Определение обобщенных механизмов проектирования» главы 9), например

сохранения и восстановления объектов в реляционной базе данных. Эти механизмы

могут использоваться в нескольких реализациях вариантов использования,

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

В описании архитектуры, кроме того, должны быть задокументированы все

использованные образцы архитектуры.

Рис. 4.6. Описание архитектуры почти не увеличивается

и изменения в ней незначительны

Описание архитектуры выдвигает на передний план наиболее важные проблемы

проектирования и открывает их для рассмотрения и получения откликов. Эти

проблемы сразу же должны быть обсуждены, проанализированы и решены. Анализ

может, например, включать оценку требуемой производительности, требований

к памяти и прикидку возможных в будущем требований, которые могут разрушить

архитектуру.

Несмотря на свою детализацию, описание архитектуры остается высокоуровневым

представлением. С одной стороны, оно не предназначено для всеобъемлющего

описания и не должно завалить участников разработки избытком деталей.

Это дорожная карта, а не детальная спецификация системы. С другой стороны, оно

должно содержать информацию для всех разработчиков, так что даже 100 страниц

не будет чересчур много. Люди используют большой документ, если в нем есть то,

архитектуры должно быть написано, что разработчикам делать на работе.

При чтении описания архитектуры мы можем заметить, что некоторые подсистемы

описаны в нем поверхностно, а интерфейсы и кооперации части подсистем —

подробно. Причина этого отличия в том, что хорошо описанные подсистемы важны

для построения архитектуры и должны находиться под контролем архитектора

(см. подразделы «Планирование итераций» главы 12 и «Проектирование архитектуры

» главы 14).

Это может помочь нам понять, что не относится к архитектуре. Большинство

классов с операциями, интерфейсами и атрибутами, которЬге скрыты в подсистемах

или сервисных подсистемах (закрыты для остальной части системы), для архитектуры

не важны. Подсистемы, которые являются вариантами других подсистем,

для архитектуры не важны. Опыт показывает, что менее 10% классов важны

для архитектуры. Остальные 90% для архитектуры не важны, потому что большая

часть системы и не подозревает об их существовании. Изменение в одном из таких

классов не затрагивает чего-либо существенного вне сервисной подсистемы. Также

и большинство реализаций вариантов использования не важны для архитектуры,

поскольку они не налагают на систему никаких дополнительных ограничений.

Именно поэтому архитекторы могут планировать архитектуру, имея лишь часть

вариантов использования и других требований. Большинство реализаций вариантов

использования представляют собой просто дополнительное поведение, которое

легко реализовать, даже при том, что оно составляет большую часть предоставляемой

системой функциональности. Подведем итог: как только мы получаем

архитектуру, реализовать большинство функциональных возможностей системы

действительно легко.

Описание архитектуры не содержит информации, необходимой исключительно

для проверки архитектуры. Не существует никаких тестовых примеров, тестовых

процедур и архитектурного представления модели тестирования. Эти вопросы

не относятся к архитектуре. Однако, как можно заметить из рис. 4.6, базовый

уровень архитектуры содержит версии всех моделей, включая модель тестирования.

Таким образом, базовый уровень, на котором основано описание архитектуры,

как и прочие базовые уровни, подвергается тестированию.