Use case и сценарии
Спрашивают, когда хотят понять, умеешь ли ты описывать поведение системы связно, а не набором разрозненных пунктов. Часто просят прямо на встрече набросать сценарий по описанной задаче - и смотрят, с какого уровня ты начнёшь.
Стержень: сценарий пишется на уровне цели актора и состоит из основного потока, альтернатив и исключений. Предусловия и постусловия задают рамку - что должно быть верно до и что станет верным после.
// Формулировки: «опиши use case для оформления заказа», «чем альтернативный поток отличается от исключения?», «что такое include и extend?»
Актор, цель и уровень описания
Актор - это роль вне границы системы: кассир, бухгалтер, платёжный шлюз. Именно роль, а не конкретный человек, и различие рабочее: один сотрудник в маленькой компании легко выступает и кассиром, и кладовщиком, а сценарии у этих ролей разные.
Сценарий пишется на уровне цели, ради которой актор вообще пришёл в систему: «оформить возврат», «согласовать заявку». Не «нажать кнопку Сохранить» - это шаг интерфейса, и дробление до такого уровня рождает десятки сценариев, которые никто не прочтёт.
Проверка уровня умещается в один вопрос: может ли актор после выполнения этого сценария уйти и считать свою задачу решённой? Если да - уровень взят верно. Если он должен сделать ещё три вещи, чтобы получить результат, ты описал шаг, а не сценарий.
// Обратная крайность тоже встречается: «работать с заказами» - это не цель, а раздел меню. Внутри него живут пять разных сценариев с разными акторами, разными предусловиями и разными способами провалиться.
- актор
- роль или внешняя система, которая обращается к нашей системе ради собственной цели. Всегда находится за границей системы, иначе это не актор, а её часть
Потоки: основной, альтернативный, исключение
Основной поток - путь, на котором цель достигнута и ничего не пошло не так. Альтернативный - другой корректный путь к той же цели: оплата при получении вместо оплаты картой. Исключение - цель не достигнута: банк отклонил платёж.
Разделение выглядит терминологическим, а на деле определяет объём работы. У альтернативы постусловие обычное, как у успеха: заказ оформлен, просто другим способом. А у исключения нужно явно описать, в каком состоянии осталась система, - и вот это описание почти всегда забывают.
Разберём на отказе банка. Снят ли резерв товара со склада? В каком статусе висит заказ? Что увидит пользователь и что ему предложат дальше? Сколько заказ может провисеть в этом статусе и что произойдёт потом? Четыре вопроса, и без ответов на них заказ останется в статусе «ожидает оплаты» навсегда, а товар - зарезервированным.
// Именно здесь чаще всего и находится главная дыра сценария: постусловие описали только для успеха. Признак болезни - в документе есть раздел «результат», и в нём одна строчка.
include и extend
Две связи между сценариями, которые постоянно путают. include выносит обязательное поведение, повторяющееся в нескольких сценариях: «проверить права доступа» вызывается всегда, при каждом обращении. extend подключает необязательное поведение в заданной точке при выполнении условия: «применить промокод» срабатывает, только если пользователь его ввёл.
Путаница делает диаграмму нечитаемой, но хуже другое - она прячет обязательные шаги. То, что должно выполняться всегда, оказывается нарисовано как опция, и в реализации его спокойно пропускают в половине путей. Проверка прав, оформленная через extend, - это готовая дыра в безопасности.
// Практика на одну секунду: спроси себя, может ли основной сценарий пройти без этого куска и остаться корректным. Может - значит extend. Не может - include.
Как отвечать: «Оплата отклонена банком. Куда это в сценарии?»
Это исключительный поток, потому что цель актора - оформленный и оплаченный заказ - не достигнута. Альтернативным потоком я бы это не назвал: альтернатива ведёт к той же цели другим путём, скажем оплата при получении, а отказ банка цели не даёт вовсе. Для исключения обязательно описываю постусловие, и подробно: заказ остаётся в статусе ожидания оплаты, резерв товара снимается через заданное время, пользователю показывается причина отказа и предлагается другой способ оплаты. Отдельно фиксирую, сколько заказ может висеть в этом статусе и что происходит по истечении срока - иначе он останется там навсегда, а товар будет числиться зарезервированным под покупателя, который уже ушёл.
Ответ классифицирует поток и тут же закрывает главную дыру исключений - состояние системы после провала. Причём закрывает конкретно, с резервом и сроком, а не общей фразой про обработку ошибок.
На чём валятся
- −− Пишут сценарий на уровне кнопок и экранов вместо уровня цели актора.
- −− Называют исключение альтернативой: вместе с названием теряется требование описать состояние после провала.
- −− Забывают постусловия исключений, и заявки навсегда зависают в промежуточных статусах.
- −− Прячут обязательный шаг в extend, и он выглядит как необязательный - классика для проверки прав.
- −− Пихают в предусловие то, что на деле может нарушаться и требует обработки: это место альтернативного потока.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Основной поток use case — это…A)самый частый по статистике путь пользователяB)путь к цели актора без отклоненийC)путь, который реализуют в первом релизеD)перечень всех возможных шагов сценария
показать ответ и разбор
+B)путь к цели актора без отклонений// разбор: Основной поток — это успешный сценарий: актор доходит до своей цели, ничего не ломается и выбор всегда идёт по прямой. Частотность здесь ни при чём, хотя обычно она совпадает. Всё остальное — альтернативные потоки (другой корректный путь к той же цели) и исключения (цель не достигнута).
- Оплата картой отклонена банком. Куда это писать в use case «Оформить заказ»?A)В основной поток отдельным шагомB)В предусловие: карта должна быть действующейC)В исключительный поток: цель не достигнутаD)В альтернативный поток: это равноправный путь
показать ответ и разбор
+C)В исключительный поток: цель не достигнута// разбор: Отказ банка не даёт достичь цели «заказ оформлен», значит это исключение, а не альтернатива. Альтернативный поток — другой корректный путь к той же цели, например оплата при получении. Разделение важно: у исключений описывают возврат системы в согласованное состояние, а у альтернатив — обычное постусловие успеха.
- Когда между use case уместна связь include, а не extend?A)Когда поведение обязательно и повторяетсяB)Когда поведение выполняется лишь при особом условииC)Когда один сценарий длиннее другогоD)Когда сценарии выполняет один и тот же актор
показать ответ и разбор
+A)Когда поведение обязательно и повторяется// разбор: include выносит обязательный общий кусок: «Проверить права» вызывается всегда и переиспользуется несколькими сценариями. extend, наоборот, подключает необязательное поведение в точке расширения при условии: «Применить промокод» срабатывает, только если код введён. Путаница делает диаграмму нечитаемой и прячет обязательные шаги.
- Аналитик описал use case «Нажать кнопку Сохранить». Что не так с уровнем детализации?A)Слишком общий: не указана роль актораB)Это шаг интерфейса, а не цель актораC)Не хватает предусловий и постусловийD)Название должно быть существительным
показать ответ и разбор
+B)Это шаг интерфейса, а не цель актора// разбор: Use case описывается на уровне цели, ради которой актор пришёл в систему: «Оформить возврат», «Согласовать заявку». Нажатие кнопки — элементарный шаг внутри сценария, и дробление до этого уровня рождает десятки бессмысленных сценариев, которые невозможно ни приоритизировать, ни оценить, ни связать с бизнес-целью.
- В чём главный риск постусловия «заказ создан» для сценария с исключением на этапе оплаты?A)При исключении состояние системы не заданоB)Постусловие дублирует основной потокC)Постусловие дублирует критерии приёмкиD)Постусловие должно совпадать с предусловием
показать ответ и разбор
+A)При исключении состояние системы не задано// разбор: Постусловие успеха не описывает, что стало с системой при провале. Без явного постусловия исключения остаётся дыра: заказ в статусе «ожидает оплаты» висит вечно, товар зарезервирован, склад заблокирован. Для каждого исключения нужно зафиксировать минимальную гарантию — что откатили, что сохранили и в каком статусе всё осталось.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.