Модуль 2.3. Сценарии и юзкейсы
Use Case, сценарии/альтернативы, state-based подход. Как готовить список вопросов на собеседовании и при обследовании. Артефакты: UC-диаграмма + описания. Практика: 3 ключевых UC с альтернативами.
Use Case (UC) — это «мост» между бизнес-целью и реализацией: кто взаимодействует с системой, зачем, в каком порядке шагов, какие исключения, что меняется в данных/состояниях. В модуле вы:
- научитесь писать UC так, чтобы Dev/QA могли сразу делать работу;
- связывать сценарии с состояниями (state-based) и BDD/AC;
- отличать «хорошие альтернативы» от избыточных ответвлений;
- подготовите UC-диаграмму и три полных описания с альтернативами.
Основа Use Case: из чего состоит качественный сценарий
Термины
- Actor (актор) — внешний по отношению к системе участник: человек, сервис, таймер.
- System Under Consideration (SUC) — система, для которой пишем UC (важно очертить границу).
- Goal (цель) — измеримая ценность для актора.
- Preconditions (предусловия) — что должно быть истинно до старта.
- Trigger (триггер) — событие/стимул старта.
- Main Success Scenario (MSS) — основной путь до ценности.
- Extensions / Alternative flows — ветви, исключения, ошибки, повторы.
- Postconditions (результат) — инварианты данных/состояний на финише.
- Special requirements — NFR/ограничения, специфичные для UC.
Уровни UC (по А. Кокберну) — пригодится для декомпозиции
- User goal («уровень моря») — завершённая ценность («Оформить заказ»).
- Sub-function (ниже уровня моря) — служебные шаги («Рассчитать доставку»).
- Summary/Cloud (выше) — крупные процессы («Сделать покупку в магазине»).
Нотация и связи на UC-диаграммах (и когда их использовать)
-
Include — обязательная подсценарная часть, всегда выполняется внутри другого UC.
Пример: «Оформить заказ» include «Рассчитать доставку». -
Extend — дополнительное поведение, включается при условии.
Пример: «Оформить заказ» extend «Применить купон», если пользователь ввёл купон. -
Generalization — обобщение акторов или UC (наследование ролей/доступов).
Пример: «Покупатель» ⟶ «VIP-покупатель».
Анти-паттерны
- Рисовать UI-экран как UC (UC описывает ценность, не интерфейс).
- Использовать extend вместо бизнес-правила (правило — в DMN/NFR, не в линиях UC).
- Сваливать все альтернативы в MSS — альтернативы живут в Extensions.
Шаблон «правильного» описания UC
UC-ID: UC-CHK-001 Название: Оформить заказ и оплатить Акторы: Покупатель (primary), Платёжный шлюз (supporting), Система складов (supporting) Граница системы (SUC): Веб-чекаут + API чекаута Цель: Получить подтверждение заказа и оплаты Предусловия: — У пользователя есть корзина с валидными товарами; пользователь аутентифицирован или гость. Триггер: Пользователь нажимает «Оформить заказ». Основной сценарий (MSS): 1. Система показывает форму доставки и оплаты. 2. Пользователь вводит адрес и выбирает способ доставки. 3. Система **включает** UC «Рассчитать доставку». 4. Пользователь вводит данные оплаты; система **включает** UC «Создать платёж». 5. Система подтверждает заказ, присваивает номер и отправляет письмо/событие `OrderCreated`. Альтернативы/Исключения: A1) Неверный адрес → подсказки/валидация, остаёмся на шаге 2. A2) Платёжный шлюз не ответил ≤10с → система возвращает 202 «Ожидается подтверждение», ставит retry≤3, уведомляет. A3) Недостаточно средств → `PaymentFailed`, заказ остаётся в статусе `Created`, предлагаем другой способ оплаты. A4) Купон введён → **расширение** UC «Применить купон» (успех/некорректен/просрочен). Постусловия (на успехе): — Сущность Order создана со статусом `PAID`, есть `paymentId`; отправлено событие `OrderPaid`. Спец. требования (NFR): — p95 POST /payments < 3с; audit-лог изменений статуса заказа; маскирование PII. Открытые вопросы: — Нужна ли поддержка отложенной оплаты? (до dd.mm) Связи: BPMN Checkout v1.2, Sequence «Оплата», OpenAPI `/orders`, `/payments`, ER «Order/Payment».
Чек-лист качества UC
- Название «глагол + ценность» (не «форма заказа»).
- MSS 5–9 шагов, каждый шаг — наблюдаемое действие/результат.
- Альтернативы только там, где меняется поведение/результат (не косметика UI).
- Есть pre/postconditions, NFR, ссылки на модели и контракты.
Сценарии: основа vs альтернативы (и как не утонуть в ветках)
Когда делать альтернативу, а когда уточнить шаг MSS
- Альтернатива, если: иной исход (код/состояние), новая ветка обработки, ошибка/повтор/таймаут.
- В MSS, если: вариант данных не меняет поток (например, два способа доставки — один шаг выбора).
Форма альтернативы
Ax) Название (условие)
На шаге N: <изменение> → далее N+1 или завершение с результатом R
Типовые альтернативы
- Повтор запроса (идемпотентность).
- Таймаут/ретрай.
- Конфликт состояния (409).
- Валидация данных (422).
- Отмена пользователем.
Контр-примеры
- «Если пользователь передумал, пусть вернётся на страницу профиля» — это поведение UI, а не системная ценность → не альтернатива в UC.
State-based подход: связываем сценарии с состояниями
Зачем состояния
- Уменьшают взрыв веток: вместо «100 альтернатив» — чёткая машина состояний.
- Даёт инварианты и правила переходов: когда и почему можно/нельзя делать действие.
Как делать
- Определите ключевую сущность (Order/Payment/Refund/Delivery).
- Перечислите статусы (минимально необходимые).
- Опишите события/триггеры и guards (условия перехода).
- Назначьте идемпотентность и «источник правды» по статусу.
Пример: Order (PlantUML)
@startuml
[*] --> CREATED
CREATED --> PAID : payment.captured
PAID --> SHIPPED : warehouse.shipped
SHIPPED --> DELIVERED : courier.delivered
PAID --> CANCELLED : cancel.request [before SHIPPED]
CREATED --> CANCELLED : cancel.timeout [>30d]
state DELIVERED {
[*] --> CONFIRMED
CONFIRMED --> RETURN_REQUESTED : customer.requestReturn
}
@enduml
Связь UC ↔ состояния
- UC «Оформить заказ» завершается Order=PAID или Order=CREATED (если платёж отложен).
- UC «Смена адреса» допустим только при Order.status in {CREATED, PAID, PACKED}.
- UC «Возврат платежа» доступен при Payment.status=CAPTURED.
Плюс ко всему: state-машина — база для AC/BDD и для DMN (правила переходов/разрешений).
От UC к backlog/BDD/RTM (поток артефактов)
- UC → Stories/Tasks (по альтернативам/интеграциям/данным).
- Из шагов UC формируются AC/BDD: Given (состояние), When (действие), Then (результат/событие).
- RTM связывает: UC → FR/NFR → модели/контракты → Jira → тесты → метрики.
Три готовых примера UC (с альтернативами)
UC-CHK-001. Оформить заказ и оплатить
(см. шаблон выше; альтернативы A1–A4)
Доп. альтернативы
- A5) Отмена пользователем на шаге 4 → заказ остаётся CREATED, корзина не меняется.
- A6) Дубликат запроса POST /payments (повтор по сети) → тот же paymentId (идемпотентность).
UC-ADR-002. Изменить адрес доставки
Акторы: Покупатель (primary).
Предусловия: Есть Order; пользователь аутентифицирован.
Триггер: Нажат «Изменить адрес».
MSS:
- Система показывает текущий адрес.
- Пользователь вводит новый адрес.
- Система валидирует адрес и пишет Address.version+1.
- Система пишет аудит-лог и отправляет событие AddressChanged.
Альтернативы
- B1) Order.status=SHIPPED → 409 ADDRESS_CHANGE_FORBIDDEN.
- B2) Валидация адреса не прошла → 422 + подсказки.
- B3) Сервис валидации недоступен → деградация: разрешаем временно без нормализации? (ADR/DMN решают).
Постусловия: Версия адреса увеличена; изменения аудируются.
NFR: p95 PATCH < 500 мс; маскирование PII; аудит-лог обязателен.
UC-REF-003. Запросить возврат платежа
Акторы: Покупатель; Платёжный шлюз.
Предусловия: Payment.status=CAPTURED.
MSS:
- Пользователь задаёт сумму возврата.
- Система проверяет правила (DMN «Правила возвратов»).
- Система создаёт возврат POST /refunds (идемпотентно) и отдаёт 201.
- Отправляется событие RefundRequested.
Альтернативы
- C1) Сумма > capturedAmount → 422.
- C2) PSP timeout → 202 PENDING, ретраи ≤3 (экспонента).
- C3) Повтор запроса с тем же Idempotency-Key → 200 с тем же refundId.
Постусловия: Создан Refund c status=PENDING/COMPLETED.
NFR: p95 POST /refunds < 2с; error-rate < 0.5%; аудит.
Как готовить вопросы: «собеседование» и «обследование»
Для обследования (сбор требований под UC)
- Контекст: «Кто актор? где старт/финиш? какой KPI успеха?»
- Состояния: «В каких статусах сущность бывает? когда переходит? кто владелец статуса?»
- Исключения: «Что делаем при таймауте/повторе/конфликте?»
- Данные: «Что минимально нужно на каждом шаге? домены/справочники/маски?»
- Интеграции: «Кто владелец внешнего API? SLA? идемпотентность?»
- NFR: «Сколько секунд приемлемо ждать? что логируем/трейсируем?»
- Приёмка: «Как поймём, что UC завершился успехом? что будет считаться ошибкой?»
На собеседовании SA (про UC/state-based)
- «Чем UC отличается от user story и BPMN?»
- «Когда вы используете include/extend? примеры анти-паттернов.»
- «Покажите, как вы связываете UC с state-машиной и BDD.»
- «Пример альтернатив: таймаут/ретрай/идемпотентность.»
- «Как ограничить ветвление альтернатив? критерии “что унести в DMN/NFR?”»
- «Пример ваших артефактов: UC-диаграмма + описание + AC/BDD.»
Риски и как их гасить
-
Сценарии про UI, а не про ценность.
Мера: называйте UC «глагол + ценность», UI детали — в UX-спецификацию. -
Взрыв альтернатив.
Мера: вынесите правила в DMN, ошибки — в единый блок, используйте state-машину. -
Нет postconditions.
Мера: всегда фиксируйте «что стало истинно» (статус/событие/инвариант в данных). -
Смешение доменов в одном UC.
Мера: один UC — одна цель одного актора; остальное — отдельные UC + связи. -
Отсутствие NFR/observability.
Мера: добавляйте NFR в UC и связывайте со SLI/алертами. -
Разрыв UC ↔ контракты/API.
Мера: в UC ставьте ссылки на OpenAPI/AsyncAPI/Sequence/ER; обновление — через PR.
Вопрос–Ответ
Q: Когда лучше BPMN, а когда UC?
A: BPMN — «кто/что делает» в процессах с ролями и очередями; UC — «какую ценность получает актор от системы». Часто оба: BPMN для «сквозняка», UC — для ключевых взаимодействий с SUC.
Q: Сколько UC нужно на фичу?
A: Обычно 1–3 на «user goal» + несколько суб-функций (include). Если больше 5 — возможна недекомпозированная цель.
Q: Где хранить UC?
A: Канон — в Git (Markdown + исходники диаграмм), витрина — Confluence (страницы с рендерами), ссылки — в Jira.
Q: Как связывать UC с AC/BDD?
A: Каждый шаг MSS → 1–2 BDD; ключевые альтернативы → отдельные BDD (позитив/негатив/ошибка).
Q: Что делать с бизнес-правилами внутри UC?
A: Кратко упоминать и ссылаться на DMN-таблицы; сами правила — вне текста UC, иначе сценарии «распухнут».
Артефакты модуля
UC-диаграмма (PlantUML)
@startuml
left to right direction
actor Buyer as A
actor "Payment Provider" as PSP
rectangle "Checkout System" {
usecase "Оформить заказ" as UC1
usecase "Рассчитать доставку" as UC2
usecase "Создать платёж" as UC3
usecase "Применить купон" as UC4
usecase "Изменить адрес доставки" as UC5
usecase "Запросить возврат" as UC6
UC1 --> UC2 : <<include>>
UC1 --> UC3 : <<include>>
UC1 <.. UC4 : <<extend>>
}
A --> UC1
A --> UC5
A --> UC6
PSP --> UC3
@enduml
Шаблон описания UC (скопируйте)
UC-ID / Название / Акторы / SUC Цель / Предусловия / Триггер MSS (нумерованные шаги 5–9) Альтернативы (Ax на шаге N, условие, результат) Постусловия / Спец. требования (NFR) Связи: BPMN/State/Sequence/OpenAPI/ER/DMN Открытые вопросы / Риски
Практика: «3 ключевых UC с альтернативами» (2–4 часа)
Задание: для вашего проекта (или возьмите примеры из модуля) подготовьте:
- UC-диаграмму (PlantUML/drawio) с 5–8 UC и 1–2 актором.
-
Три UC уровня user-goal (например: «Оформить заказ», «Изменить адрес», «Запросить возврат») по шаблону:
- MSS 5–9 шагов, 3–6 альтернатив (ошибки/таймауты/повторы/правила).
- Pre/Postconditions, NFR, ссылки на контракты/диаграммы.
- State-машину для ключевой сущности (Order/Payment) с guards.
- Список вопросов (10–15) для обследования UC с бизнесом.
Критерии зачёта
- UC пишутся «глагол + ценность», без UI-деталей.
- Альтернативы покрывают ошибки/таймауты/повторы и важные правила.
- State-машина согласована с UC (нет запрещённых переходов).
- Есть NFR/observability и ссылки на артефакты.
- Диаграмма читабельна, связи include/extend уместны.
Шпаргалка (распечатайте)
- UC = «кто/зачем/как»; UI — потом.
- MSS короткий; альтернативы — только когда меняется исход.
- Правила — в DMN; доступность/скорость/безопасность — в NFR.
- Думайте состояниями (state-based): так меньше веток и больше ясности.
- Связывайте UC ↔ BDD ↔ RTM: без приёмки сценарий — просто текст.
