Когда использовать диаграмму последовательности?

Когда использовать диаграмму последовательности

Диаграмма последовательности (Sequence Diagram) — один из самых полезных инструментов UML для Business Analyst. Я часто обращаюсь к ней при анализе и документировании сложных процессов. Расскажу, когда и почему её использовать.

Что такое диаграмма последовательности

Это диаграмма, которая показывает:

• Участников — объекты, системы, пользователи (вертикальные линии)
• Взаимодействия — сообщения между участниками (стрелки)
• Временную шкалу — порядок взаимодействия сверху вниз
• Условия и циклы — алтернативные пути и повторения

Это фактически сценарий взаимодействия, разложенный по времени.

Когда использовать диаграмму последовательности

1. Сложные процессы с несколькими участниками

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

Пример: процесс оплаты в интернет-магазине

В этом процессе участвуют:

• Пользователь (покупатель)
• Фронтенд приложение
• API сервер
• Платёжный сервис (Stripe, PayPal)
• База данных
• Email сервис

Диаграмма последовательности показывает:

1. Пользователь заполняет форму оплаты на фронтенде
2. Фронтенд отправляет запрос на API
3. API создаёт запрос к платёжному сервису
4. Платёжный сервис подтверждает платёж
5. API обновляет статус заказа в БД
6. API отправляет письмо через Email сервис
7. Фронтенд показывает успешное сообщение пользователю

Без диаграммы разработчик может упустить какой-то шаг или неправильно понять порядок.

2. Интеграции между системами

Когда нужно описать, как одна система интегрируется с другой, диаграмма последовательности — идеальный выбор.

Пример: интеграция CRM с Email маркетингом

CRM System → Email Marketing API: POST /contact
Email Marketing API → Database: Save contact
Database → Email Marketing API: OK
Email Marketing API → CRM System: 200 OK
Email Marketing API → Email Service: Send welcome email

Это явно показывает порядок действий и зависимости.

3. Асинхронные процессы

Когда в системе есть очереди сообщений, асинхронные задачи, диаграмма последовательности показывает, как они работают.

Пример: обработка заказов с очередью

Пользователь → API: POST /orders (создать заказ)
API → Database: INSERT order
API → Message Queue: Enqueue processing task
API → Пользователь: 202 Accepted

Worker (async) → Message Queue: Dequeue task
Worker → Warehouse API: Check inventory
Warehouse API → Worker: OK, in stock
Worker → Database: Update order status
Worker → Notification Service: Send SMS
Notification Service → User: SMS received

Это показывает, что API сразу возвращает ответ, а обработка происходит отдельно.

4. Альтернативные сценарии (happy path vs error path)

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

Пример: сценарий авторизации

Пользователь → Application: Enter credentials

alt [Valid credentials]
  Application → API: POST /auth/login
  API → Database: SELECT user WHERE email=...
  Database → API: User found
  API → Application: 200 OK + token
  Application → User: Login successful
else [Invalid credentials]
  API → Application: 401 Unauthorized
  Application → User: Invalid email/password
end

Это показывает, что может произойти в обоих случаях.

5. Обработка ошибок и исключений

Диаграмма последовательности явно показывает, как система обрабатывает ошибки.

Пример: сценарий с ошибкой сети

Application → API: Request

opt [Timeout]
  API --x Application: Connection timeout
  Application → Application: Retry logic (3 attempts)
  Application → User: Network error after retries
else [Server returns error]
  API → Application: 500 Internal Server Error
  Application → Logging Service: Log error
  Application → User: Please try again later
end

6. Параллельные операции

Операции, которые могут происходить одновременно, показываются как параллельные потоки.

Пример: загрузка данных параллельно

Application → API 1: GET /user-profile
Application → API 2: GET /user-orders (параллельно)
Application → API 3: GET /user-notifications (параллельно)

API 1 → Application: User data
API 2 → Application: Orders list
API 3 → Application: Notifications

Application → User: Display combined data

Это показывает, что три запроса идут одновременно, а не последовательно.

7. Система с микросервисами

Диаграмма последовательности идеальна для описания взаимодействия микросервисов.

Пример: архитектура микросервисов для создания заказа

Client → API Gateway: POST /orders
API Gateway → Order Service: Create order
Order Service → Database: Insert order
Order Service → Event Bus: Publish order.created
Event Bus → Payment Service: order.created event
Event Bus → Inventory Service: order.created event
Payment Service → Database: Create payment record
Inventory Service → Database: Decrease stock
Payment Service → Notification Service: Send confirmation
Notification Service → Client: Email sent

Это показывает распределённую архитектуру и асинхронные события.

Когда НЕ использовать диаграмму последовательности

Не используй, если:

1. Процесс очень простой — для простого действия (пользователь нажимает кнопку → открывается диалог) диаграмма неоправданна

2. Нужно показать структуру — для этого используй диаграмму классов или компонентов

3. Нужна общая архитектура — для этого используй диаграмму развёртывания (deployment diagram)

4. Очень много участников — диаграмма станет нечитаемой. Разбей на подпроцессы

5. Требуется показать состояния — для этого используй диаграмму состояний

Лучшие практики при создании

1. Начни с happy path Сначала нарисуй основной, успешный сценарий. Потом добавляй альтернативы и ошибки.

2. Используй осмысленные имена

Плохо: System A → System B: msg1
Хорошо: Order Service → Payment Service: process_payment(order_id)

3. Избегай слишком много деталей Диаграмма должна быть понятна за 2-3 минуты, не за 30 минут.

4. Используй alt/opt/loop для управления сложностью

alt [успех]
  ...
else [ошибка]
  ...
end

5. Разбей большие процессы Если участников больше 6-7, разбей на подпроцессы:

• Общая диаграмма (high-level)
• Подробные диаграммы для каждого шага

Инструменты для создания

• Draw.io — быстро, удобно, бесплатно
• Lucidchart — профессиональнее, дороже
• PlantUML — текстовая нотация, версионируется в Git
• Enterprise Architect — для больших проектов

Практический совет

В своей практике я создаю диаграмму последовательности когда:

1. Формулирую требования — чтобы убедиться, что я правильно понял процесс
2. Объясняю архитектуру — чтобы разработчики поняли порядок действий
3. Тестирую — чтобы QA знал, какие сценарии проверять
4. Документирую — чтобы у новых членов команды была ясная картина

Диаграмма последовательности — это мой лучший друг при описании "как работает" в отличие от "какая структура".