На этом шаге рассмотрим моделирование архитектурных представлений в UML.
Использование пакетов для группирования родственных элементов весьма важно – без него нельзя разработать сложную модель. Данный подход применим к организации таких элементов, как классы, интерфейсы, компоненты, узлы и диаграммы. Но при рассмотрении архитектурных представлений программных систем возникает потребность в еще более крупных блоках. Архитектурные представления тоже можно моделировать с помощью пакетов.
Напомним, что представлением (view) называется проекция организации и структуры системы, в которой внимание акцентируется на одном из конкретных ее аспектов. Из этого определения вытекают два следствия. Во-первых, систему можно разложить на почти ортогональные пакеты, каждый из которых имеет дело с набором архитектурно значимых решений (например, можно создать представления с точки зрения проектирования, взаимодействий, реализации, размещения и вариантов использования). Во-вторых, этим пакетам будут принадлежать все абстракции, относящиеся к данному представлению. Так, все компоненты модели принадлежат пакету, который моделирует представление реализации. В то же время пакеты могут содержать ссылки на элементы других пакетов.
Для моделирования архитектурных представлений необходимо:
- идентифицировать набор архитектурных представлений, значимых в контексте вашей проблемы. На практике этот набор обычно включает представления проектирования, взаимодействия, реализации, размещения и вариантов использования;
- разместить те элементы и диаграммы, которые необходимы и достаточны для визуализации, специфицирования, конструирования и документирования семантики каждого представления, в соответствующем пакете;
- при необходимости выполнить дальнейшую группировку этих элементов в пакеты.
Между элементами различных представлений обычно возникают зависимости. Таким образом, каждое представление на верхнем уровне системы должно быть открыто для всех остальных представлений этого уровня.
В качестве примера на рис. 1 показана каноническая декомпозиция верхнего уровня, типичная для большинства сложных систем.
Рис.1. Моделирование архитектурных представлений
Моделируя пакеты в UML, помните, что они нужны только для организации элементов вашей модели. Если имеются абстракции, непосредственно материализуемые как объекты в системе, не пользуйтесь пакетами. Вместо них применяйте такие элементы моделирования, как классы или компоненты.
Хорошо структурированный пакет характеризуется следующими свойствами:
- он внутренне согласован и очерчивает четкую границу вокруг группы родственных элементов;
- он слабо связан и экспортирует в другие пакеты только те элементы, которые они действительно должны "видеть", а импортирует лишь те, которые принципиально важны для работы его собственных элементов;
- глубина вложенности пакета невелика, т.к. сложно воспринимать слишком глубоко вложенные структуры;
- владея сбалансированным набором элементов, пакет по отношению к другим пакетам в системе не должен быть ни слишком большим (если надо, расщепляйте его на более мелкие), ни слишком маленьким (объединяйте элементы, которыми можно манипулировать как единым целым).
Изображая пакет в UML, руководствуйтесь следующими принципами:
- применяйте простую форму пиктограммы пакета, если не требуется явно раскрыть его содержимое;
- раскрывая содержимое пакета, показывайте только те элементы, которые принципиально необходимы для понимания его назначения в данном контексте;
- моделируя с помощью пакета сущности, относящиеся к управлению конфигурацией, раскрывайте значение меток, связанных с номерами версий.
На следующем шаге рассмотрим понятие экземпляра в языке UML.
