На этом шаге рассмотрим моделирование групп элементов в UML.
Чаще всего пакеты применяют для организации элементов моделирования в именованные группы, с которыми потом можно будет работать как с единым целым. Создавая простое приложение, можно вообще обойтись без пакетов, поскольку все ваши абстракции прекрасно разместятся в единственном пакете. В более сложных системах вы скорее обнаружите, что многие классы, компоненты, узлы, интерфейсы и даже диаграммы естественным образом разделяются на группы. Эти группы и моделируют в виде пакетов.
Между классами и пакетами есть одно значительное различие: классы являются абстракцией сущности из предметной области или из области решения, а пакеты – это механизмы организации таких сущностей в модели. Пакеты не видны в работающей системе, они служат исключительно механизмом организации разработки.
Чаще всего с помощью пакетов элементы одинаковых базовых типов организуют в группы. Например, классы и их связи в представлении системы с точки зрения проектирования можно разбить на несколько пакетов и контролировать доступ к ним с помощью зависимостей импорта. Компоненты представления реализации допустимо организовать таким же образом.
Пакеты также применяются для группирования элементов различных типов. Например, если система создается несколькими коллективами разработчиков, расположенными в разных местах, то пакеты можно использовать для управления конфигурацией, размещая в них все классы и диаграммы, так чтобы члены разных коллективов могли независимо извлекать их из хранилища и помещать обратно. На практике пакеты часто применяют для группирования элементов модели и ассоциированных с ними диаграмм.
Чтобы смоделировать группы элементов, необходимо:
- просмотреть элементы модели в некотором представлении архитектуры системы с целью поиска групп элементов, близких семантически или концептуально;
- поместить каждую такую группу в пакет;
- для каждого пакета определить, какие элементы должны быть доступны извне. Пометить их как открытые, а остальные – как защищенные или закрытые. В сомнительных случаях скрыть элемент;
- явно соединить пакеты зависимостями импорта с теми пакетами, от которых они зависят;
- при наличии семейств пакетов соединить специализированные пакеты с более общими связями обобщения.
В качестве примера на рис. 1 показаны пакеты, которые организуют в классическую трехуровневую архитектуру классы, являющиеся частями представления информационной системы с точки зрения проектирования.
Рис.1. Моделирование групп элементов
Элементы пакета User Services (Пользовательские Сервисы) предоставляют визуальный интерфейс для ввода и вывода информации. Элементы пакета Data Services (Сервисы Данных) обеспечивают доступ к данным и их обновление. Пакет Business Services (Бизнес-сервисы) является связующим звеном между элементами первых двух пакетов; он охватывает все классы и другие элементы, отвечающие за выполнение бизнес-задачи, в том числе бизнес-правила, которые диктуют стратегию манипулирования данными.
Все абстракции простой системы можно поместить в один пакет. Однако, организуя классы и другие элементы представления системы с точки зрения проектирования в три пакета, вы не только сделаете модель более понятной, но и сможете контролировать доступ к ее элементам, скрывая одни и экспортируя другие.
Изображая подобные модели, обычно показывают элементы, центральные для каждого пакета. Чтобы прояснить назначение пакетов, можно также использовать документирующее помеченное значение для каждого из них.
На следующем шаге рассмотрим типичные приемы моделирования архитектурных представлений в UML.
