Рекомендации и типичные ошибки при разработке UseCase-диаграмм

Сценарии вариантов использования

Обозначения компонентов диаграммы вариантов использования

Рисунок 16 – Графические обозначения элементов UseCase-диаграмм

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

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

Шаблон для написания сценария некоторого варианта использования состоит из четырех разделов:

Главный раздел содержит основные атрибуты варианта использования:

· Имя варианта использования

· Перечень ассоциированных с ним Актеров

· Цель

· Краткое описание функционального поведения

· Тип (по отношению к другим связанным вариантам)

· Ссылки на другие (связанные) варианты использования

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

Раздел "Исключения" – содержит перечень и краткие описания всех исключительных ситуаций. Оформляется в виде таблицы аналогично разделу " Типичный ход событий "

Раздел "Примечания".

Пример заполнения шаблона сценария варианта использования для UseCase-диаграммы, показанной на рисунке 14, приведен в таблице 1

Таблица 1 – Пример заполнения шаблона сценария

Сценарий варианта использования " Снятие наличных денег по кредитной карте "
Главный раздел
Вариант использования	Снятие наличных денег по кредитной карте
Актеры	Клиент, Банк
Цель	Получение запрошенной клиентом денежной суммы наличными
Краткое описание	Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к банковскому счету клиента. Банкомат выдает клиенту запрошенную сумму.
Тип	Базовый
Ссылки на другие варианты использования	Включает следующие варианты использования: - идентифицировать кредитную карту - проверить правильность введенного PIN-кода;
Раздел " Типичный ход событий "
Действия актеров	Отклик системы
1. Клиент вставляет кредитную карту в приемное устройство банкомата. Исключение №1. Карта недействительна или неправильно вставлена	2. Банкомат проверяет кредитную карту 3. Банкомат предлагает ввести PIN-код
4. Клиент вводит PIN-код Исключение №2. Введен неверный PIN-код	5. Банкомат проверяет введенный PIN-код 6. Банкомат отображает меню
7. Клиент выбирает пункт меню "Снятие наличных денег"	8. Система делает запрос в Банк и выясняет текущее состояние счета Клиента. 9. Банкомат предлагает Клиенту ввести требуемую сумму.
10. Клиент вводит требуемую сумму. 11. Банк проверяет введенную сумму. Исключение №3. Требуемая сумма превышает сумму, разрешенную к выдаче Клиенту.	12. Банкомат выдает наличные деньги. 13. Банкомат изменяет состояние счета Клиента, уменьшив его на выданную сумму. 14. Банкомат печатает чек.
15. Клиент получает деньги и чек.	16. Банкомат предлагает клиенту забрать кредитную карту.
17. Клиент получает свою кредитную карту.	18. Банкомат отображает сообщение о готовности к работе
Раздел " Исключения "
Действия актеров	Отклик системы
Исключение №1: Карта недействительна или неправильно вставлена
	3. Банкомат отображает информацию о негативном результате проверки кредитной карты. 14. Банкомат возвращает Клиенту кредитную карту.
17. Клиент получает свою кредитную карту.
Исключение №2^ Введен неверный PIN-код
	6. Банкомат отображает информацию о неправильном PIN-коде.
4. Клиент вводит новый PIN-код.
Исключение №3: Требуемая сумма превышает сумму, разрешенную к выдаче Клиенту
	12. Банкомат отображает информацию о превышении суммы кредита.
10. Клиент вводит другую требуемую сумму.

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

1. Определить главных (базовых) актеров модели – желательно, чтобы их количество не превышало 20.

2. Определить цели всех базовых актеров по отношению к системе.

3. Определить "второстепенных" актеров модели, уточнить их частные цели по отношению к системе, установить отношения обобщения между базовыми (предками) и частными (потомками) актерами.

4. Определить базовые варианты использования – желательно, чтобы их общее количество не превышало 50.

5. Определить включаемые варианты использования (последовательности действий, представленные в нескольких базовых вариантах) и обозначить стереотипом "include" их связи с соответствующими базовыми вариантами.

6. Последовательно рассматривая варианты использования, для каждого из них:

· обозначить на диаграмме актеров-участников, определить их интересы;

· определить предусловия и постусловия использования варианта;

· написать сценарий успешного выполнения ("типичный ход событий");

· определить неуспешные ситуации – "исключения";

· написать сценарии для всех "исключений".

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

8. Проверить диаграмму на отсутствие дублирования актеров и вариантов использования; исключить дубликаты.

Завершая обсуждение UseCase-диаграмм, приведем перечень типичных ошибок, допускаемых их разработчиками.

1. UseCase-диаграмма излишне детализируется– разработчик пытается отразить в ней детали и логику поведения системы (вместо отображения функционального поведения), что по сути, превращает ее в диаграмму деятельности.

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

3. Вместо сценария варианта использования формулируются функциональные требования к системе без указания последовательности выполняемых действий.

4. В сценариях описываются только действия актеров и игнорируются отклики системы.

5. В качестве инициаторов действий указывается система, а не актеры, как это должно быть на самом деле.

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

7. При именовании вариантов использования и при написании сценариев используются сокращения и специальные термины, привычные для разработчика, но непонятные заказчику и пользователям системы.

8. До того, как описаны сценарии всех вариантов использования, разработчики приступают к спецификации атрибутов и операций соответствующих классов.