Сценарии, потоки и исключения

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

Основной поток — это наиболее прямой путь к успешному результату. Он не обязан быть единственным возможным, но служит базой для понимания процесса. Например: студент открывает список консультаций, выбирает преподавателя, выбирает свободный интервал, подтверждает запись, система создаёт запись и отправляет уведомления.

Альтернативный поток показывает допустимый вариант нормального выполнения. Цель достигается, но путь отличается. Например, студент выбирает консультацию не по преподавателю, а по дисциплине; система предлагает другой свободный интервал; преподаватель меняет время до подтверждения записи.

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

Нумерация шагов нужна не для формальности, а для управляемости:

1. Студент открывает список консультаций.
2. Система показывает доступные интервалы.
3. Студент выбирает интервал.
4. Система проверяет доступность интервала.
5. Система создаёт запись.
6. Система отправляет уведомления.

4a. Интервал уже занят.
  4a1. Система сообщает, что интервал недоступен.
  4a2. Система предлагает выбрать другой интервал.

*a. Пользователь не авторизован.
  *a1. Система предлагает выполнить вход.

Запись 4a означает альтернативу, возникающую на шаге 4. Запись *a удобно использовать для общей ошибки, которая может произойти на разных шагах. Такая структура помогает потом перенести сценарий на процессную модель: основной поток становится основной веткой, альтернативы — ветвлениями, исключения — отдельными обработчиками или завершениями.

Сценарий должен быть написан на уровне бизнеса. Шаг “система делает SQL-запрос” не подходит для спецификации пользовательского взаимодействия. Лучше написать “система проверяет наличие свободного интервала”. Внутренняя реализация проверки появится в технической модели. На уровне сценария важно, что проверяется, почему это нужно и какой результат влияет на дальнейший ход процесса.

Типовые ошибки при описании сценариев:

Ошибка	Почему мешает
Сценарий состоит из действий интерфейса	модель привязывается к экрану раньше времени
Нет альтернатив	процесс выглядит нереалистично и не показывает решения
Все ошибки собраны в конце	непонятно, на каком шаге они возникают
Система “просто сохраняет данные”	не видно предметного результата
Шаги слишком крупные	невозможно построить процессную модель
Шаги слишком мелкие	сценарий превращается в инструкцию по кликам

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

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