Типичные приемы моделирования Группы элементов

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

Между классами и пакетами есть одно значительное различие: классы являют­ся абстракцией сущностей из предметной области или области решения, а паке­ты - это механизмы организации таких сущностей в модели. Пакеты не имеют «индивидуальности» (то есть нельзя создать экземпляры пакетов, поэтому в ра­ботающей системе они невидимы); классы же можно индивидуализировать (у mix есть экземпляры, которые являются элементами работающей системы). Системы и подсистемы, во многом подобные пакетам, отличаются от них тем, что имеют «индивидуальность», как и классы (см. главу 31).

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

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

Моделирование группы элементов производится так:

1. Просмотрите моделирующие элементы в некотором представлении архитек­туры системы с целью поиска групп семантически или концептуально близ­ких элементов.

2. Поместите каждую такую группу в пакет.

3. Для каждого пакета определите, какие элементы должны быть доступны извне. Пометьте их как открытые, а остальные - как защищенные или за­крытые. Если сомневаетесь, скройте элемент.

4. Явно соедините пакеты отношениями импорта с теми пакетами, от которых они зависят.

5. Если имеются в наличии семейства пакетов, соедините специализированные пакеты с общими отношениями обобщения.

В качестве примера на рис. 12.6 показаны пакеты, кото­рые организуют в классическую трехуровневую архитекту­ру классы, являющиеся частями представления информаци­онной системы с точки зрения проектирования. Элементы пакета Сервисы Пользователя предоставляют визуальный интерфейс для ввода и вывода информации. Элементы па­кета Сервисы Данных обеспечивают доступ к данным и их обновление. Пакет Бизнес-Сервисы является связующим звеном между элементами первых двух пакетов; он охваты­вает все классы и другие элементы, отвечающие за выполне­ние бизнес-задачи, - в том числе бизнес-правила, которые диктуют стратегию манипулирования данными в ответ на запросы пользователя.

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

Примечание Изображая подобные модели, обычно показывают элементы, цен­тральные для каждого пакета. Чтобы прояснить назначение па­кета, можно также раскрыть помеченные значения, содержащие документацию (см. главу 6).