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

Отношение (relationship) — это семантическая связь между отдельными элементами модели.

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

В основном на диаграммах прецедентов используются следующие типы отношений:

- ассоциации (association relationship);

- включения (include relationship);

- расширения (extend relationship);

- обобщения (generalization relationship).

Ассоциация – это структурное отношение, показывающее, что объект неким образом связан с другим объектом.

Отношение этого типа используется не только на диаграммах прецедентов, но и на других диаграммах. Если между элементами модели показано отношение ассоциации, то это означает, что между ними существует семантическая связь. Ассоциативное отношение может быть направленным. В этом случае направление связи показывает, кто является инициатором. Если отношение направленно от актера к прецеденту, то это означает, что актер инициирует выполнение прецедента.

Пример. Покупатель в системе заказов магазина «Style» инициирует выполнение прецедента Заказ товаров (рис. 10).

Рис. 10 - Отношение ассоциации между актером и прецедентом

Между прецедентами также возможны взаимоотношения, которые описываются отношениями двух типов: включения и расширения (дополнения).

Включение (include) говорит о том, что исходный прецедент явным образом включает в себя поведение целевого.

Другими словами, включение создается, когда один прецедент использует другой. При этом исполнение базового прецедента невозможно без исполнения используемого. Изображается включение в виде пунктирной стрелки с надписью <<include>>, которая направлена от базового элемента к используемому.

Пример. В системе заказов магазина «Style» невозможен заказ товаров без оплаты. На диаграмме прецедентов это можно отразить так, как это показано на рисунке 11.

Рис. 11 - Отношение включения между прецедентами

Расширение (extend) показывает, что целевой прецедент расширяет поведение исходного.

Используемый прецедент выполняется не всегда вместе с базовым, а только при выполнении дополнительных условий, таким образом, расширяя функциональность базового элемента. Изображается расширение пунктирной стрелкой с надписью <<extend>>, направленной от используемого варианта использования к базовому.

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

Рис. 12 - Отношение расширения между прецедентами

Обозначения отношений <<include>> и <<extend>> есть не что иное, как обозначения стереотипов, которые широко используются в UML для создания новых элементов модели путем расширения функциональности базовых элементов.

Стереотип (Stereotype) – это механизм, позволяющий категоризировать элементы модели.

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

В UML мы можем создавать собственные стереотипы на основе уже имеющихся типов, но также существуют и стандартные, заранее определенные стереотипы нотации UML. Так, отношение зависимости (о котором мы еще будем говорить) расширяется для прецедентов и актеров с помощью двух стереотипов <<include>> и <<extend>>.

Ассоциация – это коммуникативное отношение, которое соответствует стереотипу <<communicate>>, который, впрочем, всегда опускается.

Два и более актера могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей.

Обобщение (Generalization) – это отношение между общей сущностью и ее конкретным воплощением.

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

Пример. Для изменения статуса заказов в магазине «Style» с проектируемой системой будут работать сотрудник отдела продаж и кладовщик. На диаграмме мы можем показать с помощью отношения обобщения взаимосвязь между актером Сотрудник и актерами Сотрудник отдела продаж и Кладовщик (рис. 13).

Рис. 13 - Отношение обобщения между актерами

Актеры, прецеденты и отношения – это основные элементы нотации диаграмм вариантов использования. Диаграмма вариантов использования помогает отобразить основные требования к моделируемой системе и обеспечить взаимопонимание функциональности системы между разработчиком и заказчиком. Можно построить одну, главную диаграмму прецедентов, на которой будут отражены границы системы (актеры) и ее основная функциональность (прецеденты). Для более подробного представления системы допускается построение вспомогательных диаграмм прецедентов.

3.2 Построение диаграммы вариантов использования

В StarUML главная диаграмма прецедентов называется Main и располагается в представлении Use Case. Если в навигаторе модели щелкнуть два раза по имени этой диаграммы, то откроется ее рабочее поле. Для того чтобы создать прецедент, щелкните по овальному символу прецедента на панели элементов слева от рабочего поля диаграммы, а затем щелкните по тому месту на рабочем поле диаграммы, в которое вы хотите поместить прецедент. Аналогичным образом создается актер. Когда элемент помещается на поле диаграммы, он становится доступен для редактирования имени и некоторых свойств. В выделенное поле введите новое имя прецедента или актера (рис. 14).

Рис. 14 - Именование элементов в StarUML

Для создания отношения между элементами диаграммы щелкните по изображению соответствующего отношения на панели элементов справа, а затем проведите линию от одного элемента к другому, удерживая левую кнопку мыши (рис. 15).

Рис. 15 - Создание отношений между элементами в StarUML

Чтобы удалить элемент с диаграммы достаточно щелкнуть левой кнопкой мыши по этому элементу, а затем нажать кнопку Delete, либо щелкнуть правой кнопкой мыши по элементу и в контекстном меню выбрать Edit -> Delete (рис. 16).

Рис. 16 - Удаление элемента диаграммы в StarUML

Обратите внимание, что элемент был удален с диаграммы, но не из модели (рис. 17)! Его можно найти в навигаторе модели, не смотря на то, что на диаграмме он больше не отображается (элемент Прецедент1):

Рисунок 17. Элемент Прецедент1 удален с поля диаграммы, но отображается в навигаторе модели

Если мы передумали и решили вернуть элемент на диаграмму, то это можно сделать, перетащив его с навигатора модели на поле диаграммы.

Для того чтобы удалить элемент из модели нужно щелкнуть по нему на диаграмме или по его изображению в навигаторе модели правой кнопкой мыши и в контекстном меню выбрать пункт Delete from Model. Элемент будет полностью удален.

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

Пример. Для системы заказов магазина «Style» мы определили актеров Покупатель, Сотрудник, Система Склад и прецеденты Заказ товаров, Управление статусом заказа, Получение информации о заказе. Построим основную диаграмму прецедентов (рис. 18).

Рис. 18 - Основная диаграмма вариантов использования системы заказов магазина "Style"

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

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