2014-02-09
5121
UML-диаграммы вариантов использования
Диаграмма вариантов использования (UseCase diagram – в русскоязычных источниках называется иногда диаграммой прецедентов) – это форма представления концептуальной модели проектируемой системы, которая описывает ее функциональное назначение и в дальнейшем будет детализирована и преобразована в модели логического и физического уровней.
Разработка диаграммы вариантов использования преследует следующие цели:
· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
· Сформулировать общие требования к функциональному поведению системы.
· Разработать исходную концептуальную модель системы для ее последующей детализации в форме моделей логического и физического уровней.
· Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Проектируемая система представляется на UseCase-диаграмме в виде множества актеров, взаимодействующих с системой с помощью вариантов использования.
|
|
|
Диаграмма строится базе трех основных типов компонентов: собственно вариант использования (use case), действующее лицо или актер (actor) и связь или отношение (Relationship). Диаграмма может содержать и компоненты четвертого типа – интерфейсы (interface), а также примечания (notes) - произвольные текстовые комментарии разработчика, имеющие отношение к компонентам UseCase-диаграммы.
2.2. Компонент диаграммы "Актер"
Актером или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему или потребителем информации, генерируемой системой.
Актеры взаимодействуют с вариантами использования посредством передачи запросов вариантам использования и получения от них соответствующих сервисов. Такое взаимодействие выражается посредством ассоциативных связей (п. 2.2.4). Кроме этого, с актерами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актерами.
Актер представляет определенную роль (группу, тип) пользователей системы или внешних систем, взаимодействующих с проектируемой системой. Два и более актера могут иметь общие свойства, т. е. взаимодействовать одинаковым образом с одним и тем же множеством вариантов использования. Такая общность свойств и поведения представляется в виде отношения обобщения (п. 2.2.4) с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей. Реально с системой будут взаимодействовать отдельные субъекты или объекты - экземпляры актеров, каждый из которых может принадлежать к одной или нескольким ролям.
|
|
|
Актер – это именованный элемент модели, имя актера должно быть кратким и информативным. Для имен актеров подходят наименования должностей сотрудников или ролей пользователей (например, "продавец-консультант", "бухгалтер", "клиент банка") или наименования типов технических устройств (например, "сервер баз данных", "маршрутизатор").
Не рекомендуется использовать в качестве имен актеров "слишком конкретные" имена: названия моделей конкретных объектов ("маршрутизатор Cisco 3640" или "Oracle 10.0") или имена собственные ("технолог Петухов"). Дело в том, что реальный субъект – технолог по фамилии "Петухов" – в контексте рассматриваемой модели может быть представлен экземплярами разных актеров (ролей), взаимодействующих с системой посредством разных вариантов использования.
По той же причине не рекомендуется использовать излишне обобщенные имена актеров, например, имя "клиент банка" может оказаться эффективнее имени "посетитель банка", так как посетителем банк может быть вовсе и не клиент, а, например, налоговый инспектор – а это уже совсем другая роль и, скорее всего, совсем другой набор сервисов.
Часть проблем с именованием актеров может быть снята использованием обобщающей связи между актерами, которая уже упоминалась выше и будет рассмотрена далее в этом разделе.
Поскольку актер является внешней сущностью по отношению к моделируемой системе, его внутренняя структура в контексте данной диаграммы никак не определяется.
Актер представляется на диаграмме вершиной графа и изображается в виде схематичного человечка, помеченного соответствующим именем (рисунок 5).
2.3. Компонент диаграммы "Вариант использования"
Варианты использования служат для описания сервисов, которые система предоставляет актерам. Каждый вариант использования определяет некоторый сценарий - набор действий, совершаемый системой при взаимодействии с актером, причем детали реализации такого взаимодействия в данной диаграмме не раскрываются.
Предполагается, что вариант использования инициализируется по запросу (сигналу), поступающему от актера, и должен представлять собой законченную последовательность действий. После того, как эти действия будут выполнены, сервис должен прийти в исходное состояние и должен быть готовым к выполнению следующего запроса.
Вариант использования представляется на UseCase-диаграмме вершиной графа и изображается в виде овала, внутри которого записывается имя варианта (рисунок 6). Варианты использования могут быть связаны с одним или несколькими актерами, другими вариантами использования и интерфейсами.
Вариант использования имеет следующие атрибуты:
1. Имя, ясно говорящее о назначении варианта использования.
- Описание -несколько предложений, описывающих этот вариант использования.
- Частота – показывает, как часто возникает данный вариант использования.
- Предусловия - все условия запуска варианта использования.
- Постусловия - все условия, которые должны быть выполнены после успешного выполнения варианта использования.
- Основной сценарий работы, который используется в большинстве случаев.
- Альтернативные сценарии, используемые иногда: для каждого альтернативного сценария указываются условия его запуска.
- (Необязательно) Задействованные актеры.
- (Необязательно) Расширяемые варианты использования.
- (Необязательно) Включаемые варианты использования.
- (Необязательно) Статус: "в разработке", "готов к проверке", "в процессе проверки", "подтвержден", "отвергнут".
- (Необязательно) Допущения об окружении и ходе работы системы, использованные при разработке данного варианта. В полностью готовом варианте эти допущения либо должны быть подтверждены и стать ограничениями системы, либо должны давать начало различным сценариям работы.
2.4. Компонент диаграммы "Интерфейс"
|
|
|
Интерфейсы (interface) в UseCase-диаграммах определяют совокупность операций, обеспечивающих выполнение сценариев вариантов использования.
Интерфейсы UseCase-диаграмм не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций - они содержат только операции без указания особенностей их реализации.
Интерфейс представляется на UseCase-диаграмме вершиной графа и изображается в виде маленького круга, рядом с которым записывается имя интерфейса (рисунок 5). В качестве имени может быть существительное или короткий текст, характеризующие соответствующую информацию или сервис: например, «датчик», «видеокамера», «запрос к базе данных», «форма ввода», «устройство подачи звукового сигнала».
Рисунок 5 – Примеры изображения интерфейсов на UseCase-диаграмме
Графический символ отдельного интерфейса может соединяться на диаграмме сплошной линией с тем вариантом использования, который его поддерживает (рисунок 5, а). Сплошная линия в этом случае указывает на тот факт, что связанный с интерфейсом вариант использования должен реализовывать все операции, необходимые для данного интерфейса, а возможно и больше.
Если интерфейс соединен с вариантом использования пунктирной линией со стрелкой (рисунок 5, б), то это означает, что вариант использования предназначен для спецификации только того сервиса, который необходим для реализации данного интерфейса.
2.5. Компонент диаграммы "Связь"("Отношение")
Связь используется в UseCase-диаграммах для обозначения различных отношений между компонентами модели.
Связи представляются на UseCase-диаграмме дугами графа и изображаются стрелками определенного вида, которые могут попарно соединять другие компоненты диаграммы (актеров, варианты использования и интерфейсы) в различных комбинациях.
|
|
|
На рисунке 6 приведен пример UseCase-диаграммы. Связь актера с вариантом использования показывается стрелкой, направленной от актера к варианту использования, что отображает факт использования актером соответствующего сервиса, а также то, что сервис будет активизирован по инициативе данного актера.
Рисунок 6 – Укрупненная UseCase-диаграмма для Интернет-магазина
Связь на UseCase-диаграмме может принадлежать к одному из четырех типов, каждый из которых соответствует определенному типу отношения, установленного между парой связанных компонентов модели:
- Отношение ассоциации (association relationship)
- Отношение расширения (extend relationship)
- Отношение обобщения (generalization relationship),
- Отношение включени я (include relationship).
