На этом шаге рассмотрим стереотипы связи зависимости в UML.
Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности, например класса SetTopController (УстановитьВерхнийКонтроллер) на рис. 1, может повлиять на другие сущности, которые используют ее, например на класс ChannelIterator (ИтераторКанала) – но не наоборот. Зависимость изображается в виде пунктирной линии со стрелкой, направленной к той сущности, от которой зависит еще одна. Применяйте зависимости, когда хотите показать, что некая сущность использует другую.
Рис.1. Расширенные связи
Простая, без дополнений, связь зависимости встречается чаще всего. Однако, если вы хотите подчеркнуть некие смысловые оттенки, UML предоставляет вам набор стереотипов, которые могут быть приложены к связи зависимости. Имеющиеся стереотипы можно разделить на несколько групп.
Во-первых, есть стереотип, который касается связей зависимости между классами и объектами на диаграмме классов:
- bind – показывает, что исходный объект создает экземпляр
целевого, используя заданные реальные параметры.
Используйте bind, когда нужно уточнить подробности, касающиеся шаблонных классов. Например, связь между шаблонным контейнерным классом и экземпляром этого класса должна моделироваться зависимостью bind. Она включает список действительных аргументов, соответствующих формальным аргументам шаблона.
- derive – показывает, что источник может быть вычислен
по цели.
Использовать derive следует при моделировании связи между двумя атрибутами или двумя ассоциациями, одна из которых конкретна, а вторая – концептуальна. Например, класс Person (Человек) может иметь конкретный атрибут BirthDate (ДатаРождения), а также атрибут Age (Возраст), который происходит от BirthDate, поэтому не объявлен отдельно в классе. Связь между BirthDate и Age выражается зависимостью derive, то есть Age выводится из BirthDate.
- permit – показывает, что источник имеет заданную видимость
для цели.
Такая зависимость пригодится вам, если вы захотите обеспечить классу доступ к закрытым свойствам другого класса. В C++ для этих же целей предусмотрены классы-друзья (friends).
- instanceOf – показывает, что исходный объект является экземпляром целевого. Обычно отображается в текстовой нотации вида исходный объект : Целевой объект.
- instantiate – показывает, что источник создает экземпляры
цели.
Два последних стереотипа позволяют вам явно моделировать связи "класс/объект". Можно использовать instanceOf при моделировании связи между классом и объектом на одной и той же диаграмме либо связи между классом и его метаклассом; однако последняя обычно отображается в текстовом синтаксисе. Стереотип instantiate свидетельствует о том, что один класс создает объекты другого.
- powertype – сообщает, что целевой объект является супертипом исходного.
Супертип – это классификатор, объекты которого являются дочерними по отношению к заданному родительскому. Следует использовать powertype, когда нужно моделировать те классы, которые по отношению к другим являются классификаторами (как иногда бывает при моделировании баз данных).
- refine – показывает, что источник находится на более тонком
уровне абстракции, чем цель.
Используется при моделировании классов, представляющих одно и то же понятие на разных уровнях абстракции. Например, в процессе анализа вы можете определить класс Customer (Покупатель), который в процессе проектирования будет уточнен до более детализированного класса Customer и завершен реализацией.
- use – специфицирует, что семантика исходного элемента зависит от семантики открытой части целевого.
Применяйте use, когда хотите явно обозначить зависимость как связь использования, в противовес прочим значениям зависимостей, представленным в стереотипах.
Следующие два стереотипа, касающихся связей зависимости между пакетами:
- import – показывает, что открытое содержимое целевого пакета входит в открытое пространство имен исходного пакета, как если бы они были декларированы в исходном;
- access – показывает, что открытое содержимое целевого пакета входит в закрытое пространство имен исходного. Неквалифицированные имена могут применяться внутри исходного, но не могут реэкспортироваться.
Используйте import и access, когда захотите задействовать элементы, объявленные в других пакетах. Импорт элементов позволяет отказаться от применения полных квалифицированных имен для ссылок на элементы других пакетов в текстовых выражениях.
Два стереотипа относятся к связям использования между вариантами использования:
- extend – показывает, что целевой вариант использования расширяет поведение исходного;
- include – показывает, что исходный вариант использования явно включает в себя поведение другого варианта использования в месте, указанном в исходном.
Используйте extend и include, а также простое обобщение, когда вам требуется выполнить декомпозицию вариантов использования на повторно используемые части.
Один из стереотипов вы будете встречать в контексте взаимодействия объектов:
- send – показывает, что исходный класс посылает сообщение
целевому.
Используйте send, когда вам предстоит смоделировать операцию (такую как действие, связанное с переходом между состояниями), передающую данное событие целевому объекту, который, в свою очередь, может иметь ассоциированный конечный автомат. Зависимость send позволяет вам эффективно связать друг с другом два независимых автомата.
Еще один стереотип вы встретите в контексте организации элементов вашей системы в подсистемы и модели:
- trace – показывает, что целевой элемент является историческим предшественником исходного (иначе говоря, тем же
элементом, но на ранней стадии разработки).
Используйте trace, когда нужно смоделировать связи между элементами различных моделей. Например, в контексте архитектуры системы вариант использования в модели вариантов использования, представляющий функциональное требование, может трассироваться в пакет соответствующей модели дизайна, представляющей артефакты, которые реализуют данный вариант использования.
Все связи, включая обобщение, ассоциацию и реализацию, являются концептуальными разновидностями зависимостей. Обобщение, ассоциация и реализация обладают довольно важной семантикой, достаточной для того, чтобы трактовать их как различные виды связей в UML. Перечисленные выше стереотипы отражают тонкие нюансы зависимостей, каждая из которых наделена своей собственной семантикой, но не настолько семантически удалена от обычной зависимости, чтобы представлять ее как особый вид связи.
На следующем шаге рассмотрим ограничения на связи обобщения в UML.
