← Назад к вопросам

В чём разница между exception flow и alternate flow в Use Case?

1.0 Junior🔥 71 комментариев
#Диаграммы и моделирование#Требования и документация

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI28 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Exception Flow vs Alternate Flow в Use Case: Отличия

Pri описании бизнес-сценариев в Use Case используются разные типы потоков для документирования различных путей выполнения. Exception Flow и Alternate Flow звучат похоже, но описывают совершенно разные ситуации с разной частотой и типом обработки.

Основные определения

Main Flow (Основной поток)

Это счастливый путь (Happy Path) — стандартная, ожидаемая последовательность действий, когда всё работает правильно и не возникает проблем.

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

Alternate Flow (Альтернативный поток)

Это НОРМАЛЬНАЯ альтернатива основному потоку. Это предусмотренный, ожидаемый вариант выполнения, который происходит регулярно, но не в каждом случае.

Exception Flow (Поток исключения)

Это ОШИБКА или аварийное состояние. Это нежелательная ситуация, которая не должна происходить, но может — и система должна это обработать безопасно.

Таблица сравнения

ХарактеристикаAlternate FlowException Flow
Тип ситуацииНормальная альтернативаОшибка/критичная проблема
ЧастотаРегулярно происходитРедко, случайно
ОжидаемостьПредусмотрено бизнесомНе хотели, но готовимся
ИсходПозитивный или нейтральныйОтрицательный или восстановление
ВосстановлениеПродолжаем основной потокОтката или аварийного завершения
ПримерыВыбор разных способов оплатыСбой платёжного шлюза

Практические примеры

Use Case: "Оформление заказа в интернет-магазине"

Main Flow:

  1. Покупатель открывает каталог
  2. Добавляет товар в корзину
  3. Переходит к оформлению заказа
  4. Указывает адрес доставки
  5. Выбирает способ оплаты (кредитная карта)
  6. Вводит реквизиты карты
  7. Система обрабатывает платёж
  8. Заказ подтверждён, отправляется на склад

Alternate Flow 1: "Выбор другого способа оплаты"

  • На шаге 5: Вместо кредитной карты покупатель выбирает PayPal
  • На шаге 6: Перенаправляется на сайт PayPal для аутентификации
  • На шаге 7: Система получает подтверждение от PayPal
  • Продолжаем как в основном потоке

Alternate Flow 2: "Использование сохранённого адреса"

  • На шаге 4: Вместо ввода нового адреса, покупатель выбирает из сохранённых
  • Продолжаем как в основном потоке

Alternate Flow 3: "Использование купона на скидку"

  • На шаге 4: Покупатель вводит код купона
  • Система проверяет валидность и применяет скидку
  • Цена пересчитывается
  • Продолжаем как в основном потоке

Exception Flow 1: "Недостаточно средств на карте"

  • На шаге 7: Система получает отказ от банка (Insufficient funds)
  • Система показывает ошибку: "Недостаточно средств на карте"
  • Предлагает попробовать другую карту
  • Use Case возвращается на шаг 5 (выбор способа оплаты)
  • Если пользователь пытается ещё раз с той же картой — система блокирует попытку

Exception Flow 2: "Товар вышел из наличия"

  • На шаге 2: Покупатель добавляет последний товар в корзину
  • На шаге 7: При обработке заказа другой покупатель скупил весь остаток
  • Система выявляет конфликт инвентаря
  • Система показывает ошибку: "К сожалению, товар больше не в наличии"
  • Предлагает подписаться на уведомление когда товар вернётся в наличие
  • Use Case прерывается, заказ не создаётся

Exception Flow 3: "Сбой платёжного шлюза"

  • На шаге 7: Система не может подключиться к платёжному серверу (timeout)
  • Система логирует ошибку
  • Показывает пользователю: "Временная ошибка. Попробуйте позже"
  • Заказ создаётся в статусе "pending_payment"
  • Через 30 минут система пытается повторить обработку платежа
  • Если не получилось — отправляет email с просьбой повторить попытку

Exception Flow 4: "Фродовая транзакция"

  • На шаге 7: Система детектирует подозрительную активность (IP из другой страны, необычная сумма)
  • Система блокирует транзакцию
  • Требует дополнительную верификацию (SMS code)
  • Только после верификации платёж обрабатывается

Ключевые различия в деталях

Alternate Flow:

  • Задокументирован бизнесом ("мы так хотим")
  • Систематический (повторяется часто)
  • Успешное завершение (заказ создаётся)
  • Может быть статистика (X% пользователей выбирают Способ оплаты 2)

Exception Flow:

  • Обработка ошибок и граничных случаев
  • Непредсказуемый (может произойти или нет)
  • Завершение с ошибкой или отката (заказ не создаётся или требует действия)
  • Тестируется через negative testing

Документирование

Alternate Flow:

AF1: "Использование сохранённого адреса"
Условие: У покупателя есть сохранённые адреса доставки
Шаги:
4a. На экране адреса, нажать "Использовать сохранённый"
4b. Выбрать адрес из списка
4c. Система заполняет форму выбранным адресом
Возвращение: К основному потоку шаг 5

Exception Flow:

EF1: "Сбой платёжного шлюза"
Условие: Платёжный сервер недоступен
Шаги:
7e1. Система не получает ответ от платёжного API
7e2. Логирует ошибку с timestamp и transaction ID
7e3. Показывает пользователю: "Техническая ошибка"
7e4. Предлагает: "Попробовать позже" или "Выбрать другой способ"
Действие: Заказ создаётся в статусе "pending_payment" для повторной обработки

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

  • Путают Alternate Flow с Exception Flow
  • Документируют обработку ошибок как Alternate Flow (неправильно!)
  • Забывают Exception Flow (тестеры потом находят баги)
  • Слишком много Alternate Flows (усложняют документацию)
  • Не обосновывают, почему именно это Alternate Flow

Правильное разделение потоков — основа для полного тестирования и надёжной системы.