Что такое Use Case в разработке ПО: полное руководство по вариантам использования

Что такое Use Case в разработке ПО? Это список шагов, определяющих взаимодействие между ролью (актором) и системой для достижения цели. Методику популяризировал Алистар Коберн в конце 1990-х годов.

Основная структура и компоненты

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

• Актор (actor): пользователь или внешняя система, взаимодействующая с разрабатываемой системой.
• Цель (goal): обязательный компонент, представляющий результат, который актор хочет достичь через взаимодействие.
• Триггер (trigger): событие, инициирующее выполнение use case.
• Предусловие (precondition): состояние системы, которое должно быть истинным до начала выполнения сценария.
• Основной поток (main flow): последовательность шагов, ведущих к успешному достижению цели без ошибок. Шаги нумеруются последовательно (1, 2, 3...) для отслеживания порядка выполнения.
• Альтернативный поток (alternative flow): ветвление сценария при ошибке, исключении или выборе пользователя.
• Постусловие (postcondition): гарантированное состояние системы после завершения use case.

Уровни детализации по Коберну

Алистар Коберн выделяет три уровня детализации вариантов использования:

1. Sea level (user goal): уровень пользовательской цели. Типичная длина основного потока для этого уровня составляет 5–9 шагов.
2. Fish (summary): обобщённый уровень, описывающий процесс в целом.
3. Clam (subfunction): уровень подфункции, детализирующий отдельные части взаимодействия.

Отношения между вариантами использования

В стандарте Unified Modeling Language (UML) версии 2.5.1 диаграмма вариантов использования поддерживает специальные отношения:

• Включение (include): отношение, при котором один use case обязательно использует функциональность другого.
• Расширение (extend): отношение, при котором один use case добавляет поведение к другому только в определённых условиях.

Пример описания Use Case

Классический пример варианта использования: «Снять деньги со счёта» для банкомата.

• Актор: Клиент банка.
• Предусловие: Клиент вставил карту и ввёл корректный ПИН-код.
• Основной поток:
  1. Клиент выбирает операцию «Снять наличные».
  2. Система запрашивает сумму.
  3. Клиент вводит сумму.
  4. Система проверяет баланс и выдаёт деньги.
  5. Система возвращает карту и обновляет баланс счёта.
• Альтернативный поток: Если карта заблокирована, система выдаёт сообщение об ошибке и возвращает карту.
• Постусловие: Баланс счёта уменьшен на сумму выдачи, клиент получил наличные и карту.

Частые ошибки

• Смешивание уровней детализации: включение шагов уровня подфункции (clam) в основной поток уровня пользовательской цели (sea level), что нарушает рекомендацию о длине в 5–9 шагов.
• Отсутствие нумерации шагов: без последовательной нумерации (1, 2, 3...) отслеживание порядка выполнения и ссылок из альтернативных потоков становится невозможным.
• Пропуск постусловий: описание завершается без фиксации гарантированного состояния системы после выполнения сценария.

FAQ

В чём разница между include и extend?
Включение (include) означает обязательное использование функциональности другого варианта использования, а расширение (extend) добавляет поведение только при определённых условиях.

Какова оптимальная длина основного потока?
По рекомендации Алистара Коберна, для уровня пользовательской цели (sea level) основной поток должен содержать 5–9 шагов.

Можно ли использовать use case в Agile?
Да, вариант использования может служить основой для написания пользовательских историй (user stories), хотя связь между форматами варьируется в зависимости от команды.

Какие инструменты поддерживают моделирование use case?
Запись и моделирование вариантов использования поддерживают такие инструменты, как IBM Rational Software Architect, Visual Paradigm и Enterprise Architect.