Базовый уровень архитектуры

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

в себя наиболее важные с ТОЧКР! зрения архитектуры варианты использования и их

реализации. Мы также остановили свой выбор, как рассматривалось в подразделе

«Варианты использования и архитектура» данной главы, на некоторых стандартах,

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

обеспечении и программном обеспечении среднего уровня, определились

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

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

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

моделей (рис. 4.4) является базовым уровнем архитектуры^ В него входят версии

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

построения.

Рис. 4.4. Базовый уровень архитектуры — внутренний релиз системы,

направленный на определение архитектуры

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

что и проектируемая система, но без большей части «мяса». Однако он обладает

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

превращается в полномасштабную, при этом возможны небольшие изменения

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

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

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

достигнута.

На рис. 4.4 заштрихованная часть каждой модели представляет долю завершения

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

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

и незаштрихованных частей) представляют версию модели в конце фазы внедрения,

то есть базовый уровень внешнего выпуска (приложение В) (не следует

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

на рис. 4.4, они показаны в качестве иллюстрации). Между базовым уровнем

' Это не совсем так. В конце фазы проектирования у нас имеется версия модели вариантов использования, которая содержит

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

в модель), описываемые нами в порядке осознания бизнес-вариантов. Таким образом, на базовом уровне архитектуры

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

такое упрощение вполне допустимо.__

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

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

(приложение В). Мы можем рассматривать эти новые версии как приращения к п-

редыдущим версиям, начиная с базового уровня архитектуры. Каждая новая версия

модели является развитием предыдущей. Различные модели рис. 4.4, конечно,

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

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

в моделях анализа и проектирования и тестовому примеру из модели

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

необходимую для вариантов использования. В противном случае следует

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

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

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

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

сделанные изменения этого требуют. Элементы различных моделей, как мы упоминали

в подразделе «Связи между моделями» главы 2, связаны друг с другом зависимостью

трассировки.

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

в конце стадии разработки, содержит не только элементы модели. Он также включает

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

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

уровня архитектуры, часто даже до этого. Задача описания архитектуры —

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

итераций текущего жизненного цикла, но и всех будущих циклов. Это стандарт,

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

Поскольку архитектура должна быть стабильной, стандарт также не должен сильно

изменяться.

Описание архитектуры может принимать различные формы. Это могут быть

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

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

к этому в подразделе «Описание архитектуры». Однако описание включает

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

По мере того как система развивается и модели на поздних стадиях

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

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

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

изменяются в ходе итераций, — мы можем считать, что описание архитектуры также

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

системы.

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

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

скажем, 30% первого выпуска. Эта архитектура станет фундаментом, на который

система будет опираться всю свою жизнь. Так как любое изменение фундамента

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

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

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

стороны, люди разрабатывают архитектуру не первый год. Накоплены опыт__

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

решений — структур, коопераций и физических архитектур, — которые создавались

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

Такие решения обычно называют «образцами», как архитектурные образцы,

описанные в [12] и образцы проектирования из [23]. Обобщенные образцы — это

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