4 Архитектуро-

центрированный

процесс

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

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

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

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

на варианты использования.

Одних вариантов использования недостаточно. Чтобы получить работающую

систему, необходимо кое-что еще. Это «кое-что» — архитектура. Мы можем думать

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

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

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

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

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

элементы моделей. Как мы определяем, какие элементы особо важны для нас? По

тому, что они направляют нашу работу с системой как в текущем цикле разработки,

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

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

кооперации, узлы и активные классы (приложение А, см. также подраздел «Артефакт:

класс проектирования» главы 9). Они описывают основу системы, которая

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

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

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

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

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

его оттуда. Нужно ли пользователю что-то еще? Допустим, он хочет устроить там

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

при помощи нескольких окон и электролампочек. Множество инструментов приводятся

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

розеток и электрокабель соответствующей мощности. Вот так строитель разрабатывает

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

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

Строитель действует не вслепую, он уже знаком с типичной архитектурой не-__

большого гаража. Он просто должен собрать воедино все части, чтобы выполнялись

варианты использования гаража. Если бы строитель никогда не видел гараж

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

в самом деле странное сооружение. Так что он должен принимать во внимание не

только функции гаража, но и его форму.

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

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

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

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

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

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

в форме, понятной неспециалистам — владельцу, пользователям и другим

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

архитектуру до строителей и поставщиков.

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

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

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

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

лица. Кроме того, эти решения, эта архитектура, не появляются как по мановению

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

на фазах анализа и определения требований и проектирования. Фактически

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

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

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

системы.

Введение в архитектуру

Нам нужна архитектура. Прекрасно. Но что мы на самом деле понимаем под структурой

программы? Каждому, кто просматривал литературу по архитектуре программ,

вспоминалась притча о слепых и слоне. Слон для слепцов был похож на то,

что ухватил каждый из них, — на большую змею (хобот), кусок каната (хвост) или

дерево (ногу). Точно так же представление об архитектуре, если свести его к краткому

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

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

это такое — архитектура.

Давайте еще раз сравним архитектуру программ и зданий. Заказчик обычно

смотрит на здание как на единую сущность. Поэтому архитектор может посчитать

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

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

понять.

Однако в ходе строительства в него вовлекаются различные виды рабочих —

плотники, каменщики, кровельщики, водопроводчики, электрики, подсобники

и другие. Все они нуждаются в более детальных и специализированных строительных

чертежах, и все эти чертежи должны быть согласованы друг с другом. Трубы

вентиляции и водопровода, например, не должны проходить по одному и тому же

проекта здания. Таким образом, архитектор делает набор чертежей здания, которые

описывают строительные блоки, например котлован под фундамент. Инженер,

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

сооружение. Фундамент поддерживает стены, полы и крышу. Он содержит гнезда

для лифтов, водопровода, электропроводки, кондиционеров, сантехнических систем

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

ним могли работать строители. Проектировщики многих специальностей готовят

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

электроснабжения, водопровода и т. д. Архитектор несет за проект полную ответственность,

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

архитектор является экспертом в объединении всех систем здания, но не

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

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

Архитектурные чертежи — это представления всех прочих типов чертежей,

и они согласуются со всеми этими прочими чертежами.

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

представления детальных чертежей — для того, чтобы получить хорошее общее

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

детальные строительные чертежи.

Подобно зданию, программная система — это единая сущность, но архитектор

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

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

описываются различными представлениями (приложения А и В) моделей системы.

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

Архитектура программы включает в себя данные:

О об организации программной системы;

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

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

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

подсистем;

О о стиле архитектуры (приложение В), принятом в данной организации, — элементах

и их интерфейсах, их кооперации и композиции.

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

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

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

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

эстетики.

В подразделе «Шаги разработки архитектуры» данной главы мы рассмотрим

концепцию архитектуры программ в более конкретных понятиях и опишем, как

она представляется при помощи Унифицированного процесса. Но о том, на что

похоже описание архитектуры (приложение В), мы намекнем прямо здесь. Мы

уже говорили, что архитектура является представлениями моделей: представлением

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

модели проектирования и т. д. Этот набор представлений успешно приводится

к виду 4+1, обсуждаемому в [52]. Поскольку представление модели являет-

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

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

использования, но только те, которые оказывают влияние на архитектуру.

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

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

варианты использования, влияющие на архитектуру (см. подраздел «Риск не создать

правильную архитектуру» главы 12).

В описании архитектуры нет ничего сверхъестественного. Оно похоже на полное

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

ее позже), только меньше. Насколько оно велико? Никаких абсолютных величин

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

спектра систем достаточно от 50 до 100 страниц. Это диапазон для отдельных

прикладных систем (приложение В), описания архитектуры для комплектов прикладных

программ (приложение В) будут больше.

Зачем нужна архитектура?

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

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

систему, не существующую в нашем трехмерном мире. Программные

системы часто бывают в какой-то степени беспрецедентны или уникальны. Нередко

они используют прогрессивные технологии или новое сочетание технологий. Часто

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

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

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

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

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

иного типа» [2].

Кроме того, часто имеется существующая система, которая исполняет некоторые

из функций проектируемой системы. Определение того, что делает эта система,

при минимуме документации или вообще без нее, и решение вопроса о том,

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

добавляет разработке сложности.

Мы нуждаемся в архитектуре для того, чтобы:

О понять систему;

О организовать разработку;

О способствовать повторному использованию кода;

О развивать систему в дальнейшем.

Понимание системы

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

кто имеет к ней какое-то отношение. Сделать современные системы понятней нелегко

по многим причинам.

О Они реализуют сложное поведение.