Архитектурные виды

Использование пакетов для группирования родственных элементов является весьма важным - без него нельзя разработать сложную модель. Этот подход применим к организации таких элементов, как классы, интерфейсы, компоненты, узлы и диаграммы. Но при рассмотрении архитектурных видов программных систем возникает потребность в еще более крупных блоках. Архитектурные виды тоже можно моделировать с помощью пакетов.

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

Примечание Пакеты как виды отличаются от фасадов. Виду принадлежат его элементы, а фасад лишь ссылается на элементы, входящие в состав других пакетов. Элемент может принадлежать только одному пакету, хотя ссылаться на него можно из нескольких фасадов.

Моделирование архитектурных видов осуществляется следующим образом:

1. Определите, какие виды важны для решения вашей проблемы. Обычно это виды с точки зрения проектирования, процессов, реализации, развертыва­ния и прецедентов.

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

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

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

В качестве примера на рис. 12.7 показана каноническая декомпозиция верхне­го уровня, пригодная даже для самых сложных систем (см. главу 31).

Советы

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

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

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

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

• глубина вложенности пакета невелика, поскольку человек не способен вос­принимать слишком глубоко вложенные структуры;

• владея сбалансированным набором элементов, пакет по отношению к другим пакетам в системе не должен быть ни слишком большим (если надо, расщеп­ляйте его на более мелкие), ни слишком маленьким (объединяйте элементы, которыми можно манипулировать как единым целым).

Изображая пакет в UML, руководствуйтесь следующими принципами:

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

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

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