1.1. Диаграмма Use Case

Поведение системы с точки зрения пользователя описывают диаграммы Use Case. Они используются для определения функциональных требований к системе. Use Case описывают типичные взаимодействия между пользователями системы и самой системой. Для построения Use Case диаграмм полезно определить сценарии использования системы. Важно определить цели, которые преследует пользователь при взаимодействии с системой. Use Case представляет собой множество сценариев, объединенных некоторой общей целью пользователя. На Use Case изображаются следующие элементы (см. рис.1):

Актер (actor) – это внешняя сущность (процесс или человек), вступающая во взаимодействие с системой, подсистемой или классом. Актер представляет некоторую роль, которую пользователь играет по отношению к системе.

Use Case – вариант использования, или прецедент. Это блок внешне наблюдаемой деятельности системы. Он задает множество последовательностей действий, выполняемых системой, для того, чтобы актер мог получить определенный результат. Вариант использования описывает часть внешнего поведения системы, не вдаваясь в особенности её внутренней структуры. Т.е. описывает, что делает система, но не определяет, каким образом она это делает. Для именования прецедентов используют короткие глагольные фразы в активной форме.

Элементы Use Case диаграмм

Актер

Use Case

Оформить заказ

Рис. 1

Один актер может выполнять несколько Use Case, и наоборот, в соответствии с одним Use Case могут действовать несколько актеров. Между элементами диаграммы Use Case возможны следующие виды отношений (см. рис. 2):

Ассоциация – отношение указывает на связь между Use Case и актером. Это единственный вид отношений, который возможен между ними.

Обобщение – отношение между общим (предок) и более специфическим элементом. Потомок наследует поведение предка и может вносить в него дополнительное поведение.

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

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

Отношения на Use Case диаграмме

Ассоциация

Обобщение

Расширение

Включение

Рис. 2.

База видит включение и может зависеть от него. При обобщении база ничего не знает о потомке и никак от него не зависит. При расширении база не видит расширяющий Use Case, хотя поведение базы меняется, и база должна быть хорошо согласована на случай отсутствия расширяющего Use Case (т.е. база должна сохранять свою функциональность).

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

При прямом проектировании диаграммы прецедентов обычно применяются на двух этапах:

1. Моделирование контекста системы. Оно подразумевает определение границ создаваемой системы и выявление актеров, которые находятся за этой границей и взаимодействуют с системой. Диаграммы Use Case нужны для идентификации актеров и семантики их ролей. Моделирование контекста системы состоит из следующих шагов:

1.1. Идентификация актеров.

1.1.1. Поиск тех, кому участие системы требуется для выполнения своих задач.

1.1.2. Поиск тех, кто необходим для осуществления системой своих функций.

1.2. Помещение актеров на диаграмму Use Case и определение способов их связи с системой.

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

2.1. Для каждого актера рассматривается поведение, которое он ожидает или требует от системы. Запись этого поведения как Use Case.

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

2.3. Помещение прецедентов, отношений между ними и между актерами на диаграмму прецедентов.

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

Обратное проектирование диаграмм Use Case производится в следующей последовательности:

1. Идентификация всех взаимодействующих с системой актеров.

2. Изучение способов, посредством которых они взаимодействуют с системой, изменяют её состояние, реагируют на события.

3. Осуществление трассировки потока событий в системе, для которой осуществляется обратное проектирование относительно каждого актера.

4. Группировка родственных потоков событий в Use Case. Вариации событий в группе следует моделировать отношениями расширения, общие потоки моделируют отношением включения.

5. Изображение Use Case, актеров и отношений между ними на диаграммах Use Case.

На рисунке 3 приведен пример Use Case диаграммы для складской системы.