Отношения между структурами

Все вышеперечисленные структуры предполагают различные представления и под­ходы к проектированию системы; все они эффективны и полезны сами по себе. В то же время они не самостоятельны. Элементы одной структуры связаны с элементами прочих, и на эти отношения следует обратить внимание. В частно­сти, модуль в структуре декомпозиции может декларироваться как отдельный компонент, как часть отдельного компонента или как несколько компонентов в рамках одной из структур «компонент и соединитель», отражая, таким образом, своего представителя периода прогона. Как правило, между структурами уста­навливаются отношения «многие ко многим».

Иногда в рамках отдельных проектов одна структура считается основной, а ос­тальные структуры, если это возможно, определяются в ее категориях. Часто, хотя и не всегда, в качестве доминантной структуры выступает декомпозиция модулей. Объясняется это вполне разумно — декомпозиция модулей порождает структуру проекта. В главе 4 представлены сценарии, которые помогают разви­вать отдельные структуры и их связи с другими структурами. К примеру, если разработчик программного обеспечения желает внести в клиент-серверную струк­туру системы какие-то изменения, он должен учитывать представления процес­сов и размещения: дело в том, что клиент-серверные механизмы, как правило, задействуют процессы и потоки, а физическое распределение реализует различ­ные механизмы управления, которые оказываются необходимы в случае локали­зации упомянутых процессов на одной машине. При необходимости изменения механизмов управления оценить степень их корректировки помогают представ­ление декомпозиции модулей и многоуровневое представление.

Не все системы гарантируют учет различных архитектурных структур. Чем крупнее система, тем существеннее различие между этими структурами; впро­чем, если речь идет о небольшой системе, обойтись, как правило, можно мини­мальными средствами. Вместо нескольких структур «компонент и соединитель» хватит одной. Если процесс в системе всего один, то структуру процессов можно свести к единичному узлу, который по мере проектирования не нужно будет со­провождать. Если распределение не планируется (все операции будут произво­диться на одном процессоре), необходимость в структуре размещения отпадает.

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

Какие структуры выбрать?

Мы привели краткий обзор ряда полезных архитектурных структур, однако на самом деле их значительно больше. С какими из них архитектору имеет смысл работать? Какие архитектор должен задокументировать? Ну конечно, не все.

Недостатка в советах не наблюдается. В 1995 году Филипп Крюхтен (Philippe Kruchten) [Kruchten 95] опубликовал очень важную статью, в которой понятие архитектуры описывается в категориях составляющих ее структур; в ней же он советует сосредоточиться на четырех структурах. Для того чтобы удостоверить­ся, что структуры не конфликтуют друг с другом, а, вместе взятые, действитель­но описывают удовлетворяющую всем требованиям систему, Крюхтен посовето­вал обратиться к основным элементам Use Case. Этот метод, получивший название «4+1», стал довольно популярен, а впоследствии выступил в роли концептуаль­ной основы рационального унифицированного процесса (Rational Unified Process, RUP). О каких именно представлениях рассуждает Крюхтен?

♦ Логическое представление. Элементы — это «ключевые абстракции», кото­рые в контексте объектно-ориентированной технологии декларируются в ка­честве объектов и классов объектов. Это — модульное представление.

♦ Процесс. Это представление связывается с параллелизмом и распределени­ем функций. Оно тождественно представлению «компонент и соединитель».

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

♦ Физическое представление. Отображая прочие элементы на узлы обработ­ки и связи, оно также относится к представлению распределения (которое иногда называют представлением размещения).

Примерно в то же время, когда свою работу выпустил Крюхтен, другие иссле­дователи — Сони, Норд и Хофмайстер [Soni 95] — опубликовали весьма замет­ную статью, в которой описывали структуры, довольно популярные среди архи­текторов их компании. Речь шла о концептуальном представлении, представлениях соединения модулей и исполнения, а также о кодовом представлении. Они, опять же, точно соответствуют моделям модулей, распределения и «компоненту и со­единителю».

За ними последовали другие работы, и список доступных структур стал бы­стро расширяться. Использовать все эти структуры, конечно, не стоит, хотя, с дру­гой стороны, они по большей части присутствуют в конструируемых системах. Не забывайте, что от архитектора, помимо прочего, требуется понимать, каким образом различные структуры обеспечивают реализацию атрибутов качества; именно из этого соответствия и следует исходить, составляя перечень подходя­щих структур. В главе 9, рассуждая об архитектурном представлении, мы наме­рены более полно раскрыть суть этого принципа.

Заключение

В настоящей главе мы привели определение программной архитектуры и некото­рых связанных с ней понятий: эталонной модели, эталонной архитектуры и архи­тектурного образца. Мы объяснили, почему в контексте программной инжене­рии архитектура играет столь существенную роль, выявили ее функции как источника начального накопления знаний о системе, как катализатора взаимо­действия между заинтересованными лицами и как повторно используемого сред­ства. Все эти функции мы рассмотрим в последующих главах.

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

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

Дополнительная литература

Понятийные основы изучения программной архитектуры были в значительной степени заложены ранними работами Дэвида Парнаса (David Parnas) (см. врезку «Архитектурное дежа вю»). Читатели Парнаса, скорее всего, отметили бы его фундаментальную статью об информационной закрытости [Parnas 72], работы по семействам программ [Parnas 76], неотъемлемым структурам программных систем [Parnas 74] и введение в структуру использования, ориентированную на констру­ирование подмножеств и супермножеств систем [Parnas 79]. Все эти исследова­ния включены в более распространенный сборник его основных работ [Hoff­man 01].

Пространная документация по программно-архитектурным образцам перечис­лена в работах «Pattern-Oriented Software Architecture» [Buschmann 96, Schmidt 00].

Применению архитектурных представлений в промышленных проектах по­священы работы [Soni 95] и [Kruchten 95]. На основе первой из них впослед­ствии была выпущена книга [Hofmeister 00] со всесторонним анализом представ­лений и их использования в ходе разработки и анализа. На основе содержания статьи [Kruchten 95], как мы уже говорили, построен рациональный унифициро­ванный процесс, которому посвящено огромное количество исследований. Из них мы рекомендуем [Kruchten 00].

Сведения об архитектурном несоответствии содержатся в работе авторского коллектива под руководством Гарлана [Garlan 95]. Барри Боэм (Barry Boehm) [Boehm 95] раскрывает особенности процессов, относящиеся к программной ар­хитектуре.

На веб-сайте программной архитектуры Института программной инженерии [SEI АТА] приводятся многочисленные ресурсы и ссылки на ресурсы, связанные с программной архитектурой; среди прочего на нем опубликована подборка са­мых разнообразных определений этого термина.

Полиш (Paulish) [Paulish 02] рассматривает влияние на архитектуру финансо­вых и временных ограничений.

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

1. Программная архитектура часто сравнивается с архитектурой зданий. Пе­речислите допустимые аспекты такого сравнения. Как здания ассоцииру­ются со структурами и представлениями программной архитектуры? Как они соотносятся с образцами? В чем недостатки такого сопоставления? На каком этапе оно становится неприемлемым?

2. В чем разница между эталонной архитектурой и архитектурным образцом? Какие возможности в части планирования деятельности организации и ар­хитектурного анализа предусматривает одно из этих понятий и не предусмат­ривает другое?