Диаграмма последовательности (Sequence Diagram) — поведенческая диаграмма UML, моделирующая обмен сообщениями между участниками во времени. Если 03.02.01 Диаграмма прецедентов (Use Case Diagram) отвечает на вопрос «что делает система?», а 03.02.02 Диаграмма деятельности (Activity Diagram) — «в каком порядке выполняются шаги?», то sequence diagram фиксирует кто кому, когда и с каким результатом передаёт управление или данные. На проекте это основной инструмент детализации прецедента до уровня вызовов, событий и ответов — без превращения заметки в спецификацию протоколов (REST, Kafka и пр. — в 03.05.01 Виды интеграции (точка-точка, ESB, API-led) и смежных статьях).

1. Суть темы

Главная цель — перевести сценарий взаимодействия в проверяемую модель: участники, порядок сообщений, условные ветки, синхронные и асинхронные границы. Диаграмма связывает прецедент (03.02.01 Диаграмма прецедентов (Use Case Diagram), 10.01.02 Шаблон Use Case) с технической спецификацией (02.03.03 Спецификация требований (SRS, Use Case, User Story), 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)): каждое сообщение — кандидат на API-метод, интеграционный вызов, событие или шаг интеграционного теста.

Диаграмма решает задачи системного аналитика:

  • детализировать прецедент — main / alternate / exception на уровне сообщений между компонентами;
  • согласовать взаимодействие — кто инициирует, кто отвечает, где граница синхронного ожидания;
  • прояснить условную логику — alt, opt, loop, par вместо размытых формулировок «если… то…»;
  • подготовить тесты — каждый путь по диаграмме → интеграционный или приёмочный сценарий (08.03 Тестирование требований (статическое тестирование), [[02.04.02 Критерии приёмки (Acceptance Criteria)]).

Граница этой заметки и 06.01.03 Диаграммы взаимодействия (Sequence, Communication): здесь — прикладной слой SA в ветке функционального моделирования: один сценарий, участники проектируемой системы, связь с прецедентом и SRS. В 06.01.03 — формальная нотация UML 2.5 (Interaction, Communication Diagram, ref, sd, таксономия сообщений, Timing Diagram). Не дублируйте определения: сверяйте строгую семантику там, рисуйте для команды здесь.

Sequence vs Activity Diagram: развёрнутое сравнение — в 03.02.02 Диаграмма деятельности (Activity Diagram); здесь достаточно критерия: AD — порядок шагов и ветвления внутри сценария; sequence — те же шаги через конкретных участников и сообщения.

Sequence vs Communication Diagram: sequence удобна, когда важен хронологический порядок вызовов (типичный кейс SA при детализации UC). Communication (collaboration) diagram показывает структуру связей между объектами с номерами сообщений — лучше для обзора архитектуры связей, хуже для чтения длинного сценария. Выбор — в 06.01.03 Диаграммы взаимодействия (Sequence, Communication).

Sequence vs State Machine (03.02.04 Диаграмма состояний (State Machine Diagram)): sequence описывает один проход сценария — обмен сообщениями за ограниченный интервал времени. State Machine — жизненный цикл объекта (статусы заказа, платежа, заявки) независимо от конкретного вызова. На одном проекте обе диаграммы дополняют друг друга: sequence для «что происходит при оплате»; state — для «какие статусы допустимы и из какого в какой переходим».

Sequence vs BPMN: сквозной бизнес-процесс с человеческими задачами, эскалациями и SLA между отделами — 03.04.01 BPMN 2.0 - введение и основы; цепочка системных вызовов между сервисами в рамках одного сценария — sequence.

Сколько диаграмм на один прецедент: практичное правило — одна диаграмма = один связный поток (main или одна alternate/exception ветка). Прецедент «Оформить заказ» из 10.01.02 Шаблон Use Case обычно даёт 2–4 sequence: основной поток, отказ платежа, недоступность товара. Перегруженную «спагетти»-диаграмму разбивают с префиксом UC-ID (UC-05-main, UC-05-alt-payment-declined).

2. Ключевые понятия

Полная палитра interaction-диаграмм UML — в 06.01.03 Диаграммы взаимодействия (Sequence, Communication) и 06.01.02 Поведенческие диаграммы (State, Activity, Use Case). Ниже — минимум для SA.

Линия жизни (Lifeline)

Участник взаимодействия: актор, компонент, сервис, внешняя система, иногда очередь/топик как аналитическая абстракция. Вертикальная пунктирная линия — время существования в рамках сценария.

Формат имени: ИмяОбъекта : ИмяКласса (например, customerPage : SPA, :OrderService). На ранних этапах SDLC достаточно роли или имени сервиса; к проектированию — имена из декомпозиции (03.01.03 Декомпозиция системы на подсистемы и модули).

Уровень абстракции участника:

ЭтапКого ставим на lifeline
Согласование с заказчикомАктор + «Система» (чёрный ящик)
Проектирование сервисовКомпоненты, API Gateway, БД, внешние системы
Детализация для разработкиКонкретные сервисы с :ServiceName, при необходимости — слои внутри одного сервиса

Фокус управления (Activation)

Узкий прямоугольник на lifeline: объект активен — выполняет операцию между получением сообщения и возвратом управления.

Сообщения (Messages)

ТипОбозначение в UMLСмысл для SA
Синхронное (Synchronous)Сплошная линия, закрашенная стрелкаВызывающий ждёт ответа (типичный HTTP request–response)
Асинхронное (Asynchronous)Сплошная линия, открытая стрелкаОтправитель не блокируется (событие в очередь, fire-and-forget)
Возвратное (Reply)Пунктир, открытая стрелкаОтвет на синхронный вызов; часто опускают, если очевидно
Создание (Create)Пунктир к новой lifelineПоявление экземпляра в ходе сценария
Уничтожение (Destroy)Стрелка к «×» на lifelineЗавершение жизни объекта
Self-messageСтрелка к той же lifelineВнутренний вызов: валидация, маппинг DTO, расчёт внутри сервиса

Семантика REST-кодов, идемпотентности и контрактов — не на этой диаграмме, а в 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) и 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).

Комбинированные фрагменты (Combined Fragments)

ОператорНазначениеПример для SA
altАльтернативные ветки (if/else), у каждого операнда — [guard]paymentMode = IMMEDIATE vs DRAFT
optНеобязательный фрагмент при истинности условияПромокод применён — дополнительный вызов Pricing
loopЦикл с границами или условиемRetry платежа до 3 попыток
parПараллельные операндыПараллельно fraudCheck() и inventoryReserve() перед commit
breakПрерывание сценария при условии—
criticalКритическая секция (атомарность)—
refСсылка на другую sequence-диаграммуref UC-05-async-fulfillment

Аналитику чаще всего хватает alt, opt, loop, par. Редкие операторы (break, critical, вложенные ref/sd) — в 06.01.03 Диаграммы взаимодействия (Sequence, Communication).

Mermaid / PlantUML ≠ строгий UML

Примеры ниже — diagram-as-code для ревью в Git (07.05 Системы контроля версий (Git) для документации). Mermaid не различает sync/async стрелки так же явно, как UML: в коде ->> обычно трактуют как синхронный вызов, -->> — ответ; асинхронность помечайте в подписи (async, event) или в Note. Для формальной модели — 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) и спецификация OMG UML 2.5.1.

3. Как применяется в работе аналитика

Точка входа: прецедент или user story

Начинайте с текстового сценария (10.01.02 Шаблон Use Case, 04.02 Пользовательские истории (User Stories) и Job Stories). Критерий выбора формата — 04.03 Use Case vs User Story — выбор подхода. Выписываете участников слева направо в порядке первого вовлечения, затем — сообщения по шагам main flow. Alternate и exception выносите в alt/opt или на отдельные диаграммы.

Пример: оформление заказа (синхронный сценарий)

Сценарий UC «Оформить заказ» — две alternate-ветки на одной диаграмме (на практике их часто разносят): paymentMode: IMMEDIATE → INSERT с status = CONFIRMED и вызов платёжного шлюза; paymentMode: DRAFT → INSERT с status = NEW, без Payment. Guard на alt — по входному параметру paymentMode, а не по статусу «из ниоткуда» после единственного INSERT.

sequenceDiagram
    actor Customer as Покупатель
    participant SPA as SPA
    participant Gateway as API Gateway
    participant OrderSvc as Order Service
    participant DB as База данных
    participant Payment as Платёжный шлюз

    Customer->>SPA: Оформить заказ
    SPA->>Gateway: POST /orders (paymentMode=...)
    Gateway->>Gateway: Проверка JWT
    Gateway->>OrderSvc: createOrder(orderData)
    activate OrderSvc
    OrderSvc->>DB: BEGIN

    alt [paymentMode = IMMEDIATE]
        OrderSvc->>DB: INSERT (status=CONFIRMED)
        OrderSvc->>Payment: authorize(paymentData)
        activate Payment
        Payment-->>OrderSvc: authorized / declined
        deactivate Payment
        alt авторизован
            OrderSvc->>DB: UPDATE status=PAID; COMMIT
            OrderSvc-->>Gateway: 201 Created
        else отклонён
            OrderSvc->>DB: ROLLBACK
            OrderSvc-->>Gateway: 422 Payment declined
        end
    else [paymentMode = DRAFT]
        OrderSvc->>DB: INSERT (status=NEW)
        OrderSvc->>DB: COMMIT
        OrderSvc-->>Gateway: 201 Created (draft)
    end

    deactivate OrderSvc
    Gateway-->>SPA: HTTP-ответ
    SPA-->>Customer: Результат

Детализацию контракта POST /orders переносите в 10.01.04 Шаблон спецификации REST API и 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf); операции INSERT/UPDATE — в 10.01.03 Шаблон спецификации БД сервиса. Sequence показывает порядок и ветвления, не полную схему JSON.

Пример: accept-path с асинхронной публикацией

Когда после принятия запроса обработка продолжается через событие, на одной диаграмме фиксируют только accept-path: синхронный ответ клиенту и fire-and-forget публикацию. Потребление события и последующие шаги — отдельная диаграмма (UC-05-async-fulfillment), иначе нарушается правило «один связный поток».

Асинхронное сообщение в UML — открытая стрелка; в Mermaid помечайте (async) в подписи (см. §2). Топик как lifeline — условность для наглядности; паттерны producer/consumer и EDA — в 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events), 03.05.06 Event-Driven Architecture и шаблонах 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ), 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ).

sequenceDiagram
    participant Client as Клиент
    participant API as API Gateway
    participant OrderSvc as Order Service
    participant Kafka as Topic: orders

    Client->>API: POST /orders
    API->>OrderSvc: createOrderAsync()
    activate OrderSvc
    OrderSvc->>Kafka: OrderCreatedEvent (async)
    OrderSvc-->>API: 202 Accepted
    deactivate OrderSvc
    API-->>Client: 202 Accepted

    Note over Kafka: Резервирование на складе — UC-05-async-fulfillment

Связь с другими артефактами

АртефактСвязь с sequence
Use Case / User StoryОдин UC → несколько sequence по потокам
Activity DiagramПорядок шагов — в AD; участники и сообщения — в sequence (03.02.02 Диаграмма деятельности (Activity Diagram))
OpenAPI / AsyncAPISequence — эскиз цепочки; контракт — формальная спецификация (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf))
Матрица трассировкиСообщения и участники → FR / компоненты (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки)
НФТТаймауты, retry в loop, лимиты — помечайте Note и сверяйте с 08.02 Нефункциональные требования (НФТ) — классификация и стандарты

Практики оформления

4. Типовые ошибки и ограничения

Ошибки:

Ограничения:

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • OMG. Unified Modeling Language (OMG UML), Version 2.5.1. 2017. https://www.omg.org/spec/UML/2.5.1
  • Гради Буч, Джеймс Рамбо, Ивар Якобсон. «Язык UML. Руководство пользователя». 2-е изд. — М.: ДМК Пресс, 2006.
  • Мартин Фаулер. «UML. Основы». 3-е изд. — СПб.: Символ-Плюс, 2005.
  • IIBA. BABOK Guide v3 (2015). Раздел 7.4 «Specify and Model Requirements»; техника 10.42 Sequence Diagrams (не путать с 10.37 Reviews).
  • Martina Seidl, Marion Scholz et al. «UML @ Classroom: An Introduction to Object-Oriented Modeling». Springer, 2015.

Онлайн-ресурсы и инструменты

Дополнительно по async-сценариям

  • Ben Stopford. «Designing Event-Driven Systems». O’Reilly, 2018 — связь sequence с событийными цепочками (детали EDA — 03.05.06 Event-Driven Architecture).