§ 11. Представление управления моделью и дополнительные возможности языка uml

11.1. Представление управления моделью

Пакеты. Любое большое программное приложение удобнее делить на части, тогда команды разработчиков смогут работать над различными частями системы, не мешая друг другу. Управление моделью заключается в правильном делении системы на пакеты и определении зависимостей между ними.

Пакет (package) — это часть модели. Каждая часть модели может принадлежать только одному пакету.

Разработчик может распределить содержимое модели по целому набору пакетов. При этом распределение элементов по пакетам должно производиться с учетом сходства функциональности элементов и их взаимосвязей при реализации в программном коде. Язык UML не предлагает жестких правил для разбиения модели на пакеты, однако чем лучше это делается пользователем, тем удобнее и надежнее будет модель.

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

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

Одни пакеты могут содержать в себе другие. У модели есть также корневой пакет, в котором хранится все ее содержимое. Существует несколько способов организации пакетов: по виду модели, по функциональности или по любому другому признаку, который выберет разработчик.

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

Набор пакетов, на которые разбита модель, отражает архитектуру всей системы (ее деление на подсистемы и зависимости между ними). Зависимости между пакетами объединяют в себе зависимости между их содержимым.

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

Зависимость между пакетами указывает на то, что между единичными элементами этих пакетов существует (при восходящем подходе) или допускается к существованию (при нисходящем подходе), по крайней мере, одно отношение такого типа зависимости. Это своего рода «констатация факта» существования зависимости и вовсе не означает, что такая зависимость есть у каждого элемента пакета. Зависимость между пакетами — своего рода указатель, который говорит проектировщику о наличии более подробной информации по этому поводу.

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

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

На диаграммах пакеты изображаются в виде прямоугольников с «закладкой» (точно так же, как пиктограмма «папка» Windows), а зависимости — в виде пунктирных стрелок.

На рис. 28 показана структура пакетов для подсистемы заказа и продажи билетов. Она содержит зависимости от внешних пакетов и два варианта пакета Выбор_места (через удаленный терминал (Кассовый_терминал) и через транспортное агентство (Агентство). Любая единичная реализация подсистемы в программном коде будет содержать только один из этих вариантов.

Рис 28. Пакеты и отношения между ними

Зависимости доступа и импорта. Содержимое одного пакета недоступно другому, если только между ними не существует зависимости доступа или импорта. Зависимость доступа применяется к пакетам и другим контейнерам. На уровне пакетов она означает, что содержимое пакета-поставщика доступно пакету-потребителю и его подпакетам.

Чтобы стать доступным пакету-потребителю, элемент пакета-поставщика должен иметь соответствующую видимость. В общем случае, другие пакеты могут «видеть» элементы только с открытой (public) видимостью. Элементы с защищенной (protected) видимостью дают доступ к своему содержимому только потомкам того пакета, в котором содержатся. Если же элемент обладает закрытой (private) видимостью, то его содержимое доступно только другим элементам его собственного пакета или вложенным пакетам.

Понятие видимости применимо также и к содержимому классов — атрибутам и операциям. Потомок какого-либо класса может «видеть» элементы своего предка, имеющего открытую или защищенную видимость. Любой другой класс при этом имеет доступ только к элементам с открытой видимостью.

Для ссылки на какой-либо элемент пакета нужны и разрешение доступа, и соответствующий тип видимости. Например, если требуется, чтобы элемент одного пакета «увидел» элемент другого пакета, не связанного с первым, нужно, чтобы первый пакет имел доступ к другому пакету или импортировал его. Элемент, к которому происходит обращение, должен при этом иметь общедоступную видимость в рамках своего пакета.

Вложенный пакет является частью своего пакета-контейнера и имеет полный доступ к его содержимому. Дополнительного разрешения доступа в данном случае не требуется. С другой стороны, не имея прав доступа, контейнер не сможет «увидеть» содержимое вложенных в него пакетов, так как оно инкапсулировано.

Зависимость доступа не изменяет пространство имен пакета-потребителя. Она дает право на создание ссылок, но не создает их автоматически. Зависимость импорта, в свою очередь, используется для добавления имен из другого пакета в пространство имен пакета-потребителя в виде псевдонимов полных имен путей.

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

Подсистема — это пакет, в котором различаются спецификация и реализация и который является связным блоком модели с четким интерфейсом к остальной части системы.

На диаграммах и подсистемы, и модели изображаются в виде пакетов с ключевыми словами-стереотипами (см. рис.28).