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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-04-25