Диаграммы взаимодействия (Sequence, Communication)

Диаграммы взаимодействия (interaction diagrams) — группа поведенческих диаграмм UML, показывающих обмен сообщениями между участниками в рамках одного сценария. Если диаграмма прецедентов (06.01.02 Поведенческие диаграммы (State, Activity, Use Case), 03.02.01 Диаграмма прецедентов (Use Case Diagram)) отвечает на «что делает система», а 03.02.04 Диаграмма состояний (State Machine Diagram) — «как меняется состояние объекта», то interaction diagrams фиксируют как участники обмениваются сообщениями, чтобы выполнить задачу. В UML 2.5 категорию Interactions представляют четыре вида диаграмм; в этой заметке детально Sequence и Communication, обзорно — Timing и Interaction Overview. Прикладное применение sequence в работе SA — в 03.02.03 Диаграмма последовательности (Sequence Diagram).

1. Суть темы

Interaction в UML 2.5 — одна семантическая модель обмена сообщениями; Sequence Diagram и Communication Diagram — два канонических представления (views) одного interaction, а не разные сценарии. В инструментах уровня Sparx EA или PlantUML (частично) их можно синхронизировать: изменение сообщений на sequence автоматически отражается на communication и наоборот. В diagram-as-code (Mermaid) communication обычно рисуют отдельно вручную.

Граница этой заметки и 03.02.03 Диаграмма последовательности (Sequence Diagram):

Четыре вида interaction diagrams в UML 2.5:

Timing и Interaction Overview в повседневной SA-практике встречаются реже Sequence и Communication; минимум нотации — в §2.5. Полная проработка Timing — по спецификации OMG UML 2.5.1 (раздел Interactions). Для обзора activity-подобных потоков см. также 03.02.02 Диаграмма деятельности (Activity Diagram): Activity описывает порядок действий, Interaction Overview — порядок ссылок на interaction (ref).

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

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

2.1 Диаграмма последовательности (Sequence Diagram)

Диаграмма с явной временной осью (сверху вниз). Основной инструмент для чтения порядка вызовов и combined fragments.

Основные элементы:

• Линия жизни (Lifeline) — вертикальная пунктирная линия участника: объект класса, компонент, актор, система (:System). Формат: имя : Класс. Уровень абстракции (актор vs сервис vs класс) — см. 03.01.03 Декомпозиция системы на подсистемы и модули и 06.01.01 Структурные диаграммы (Class, Object, Package).
• Фокус управления (Activation / Execution Specification) — узкий прямоугольник на lifeline: период выполнения операции.
• Сообщения (Messages):

Важно: асинхронная стрелка на диаграмме — UML-семантика «отправитель не блокируется», а не автоматически «очередь Kafka» или message broker. Связь с брокерами и event-driven архитектурой — в 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events) и 03.05.06 Event-Driven Architecture; на диаграмме достаточно подписи async или lifeline :EventBus, если это аналитическая абстракция.

Reply: в учебных и обзорных диаграммах return часто опускают. При спецификации контрактов (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)) явно моделируйте return, если важны тело ответа, коды ошибок или обязательность ответа для следующего шага.

• Комбинированные фрагменты (Combined Fragments) — рамка с оператором UML:

• Gates — именованные точки на границе фрагмента ref или sd, через которые interaction стыкуется с внешним контекстом. Логически близки к found/lost, но привязаны к границе именованного фрагмента, а не к краю листа; полезны при стыковке с 03.01.02 Моделирование контекста системы (Context Diagram) и 03.01.04 Интерфейсы и интеграционные взаимодействия.
• Interaction Use (ref) и Interaction Occurrence (sd) — ref вставляет ссылку на уже существующую именованную interaction (например, ref UC-05-Payment); sd оборачивает фрагмент текущей диаграммы в именованный блок для повторного использования (sd PaymentFlow { ... }). Это основной способ декомпозиции длинных сценариев вместо одной «спагетти»-диаграммы.

Уровни строгости инструментов — не смешивайте при sign-off с заказчиком:

В Mermaid поддерживаются фрагменты alt, opt, loop, par, break, critical; rect — дополнение Mermaid для рамки, не combined fragment UML. ref и found/lost — с ограничениями или вручную через Note.

2.2 Диаграмма коммуникации (Communication Diagram)

То же interaction, но без явной временной оси: объекты — прямоугольники, связи — линии ассоциаций из 06.01.01 Структурные диаграммы (Class, Object, Package), порядок — нумерация сообщений на связях (1, 1.1, 2). Условия и циклы задаются guard-подписями на сообщениях: [есть на складе] 5: провестиОплату(), *[i:=1..n].

Канон UML: объекты + ассоциации между ними + сообщения с номерами на линиях связи, а не отдельные направленные рёбра «от узла к узлу». В EA и на экзаменах по UML проверяют именно эту топологию.

Communication не «не умеет ветвления» — ветки отражаются в guards и иерархической нумерации, но читать сложный alt на communication труднее, чем на sequence.

2.3 Сопоставимый пример: оформление заказа

Один сценарий — ветвление «есть / нет на складе» — в обоих представлениях.

Sequence (Mermaid):

sequenceDiagram
    actor Пользователь
    participant WebUI as Веб-интерфейс
    participant OrderService as СервисЗаказов
    participant StockService as СервисСклада
    participant PaymentGateway as ПлатёжныйШлюз

    Пользователь->>WebUI: Инициировать оформление заказа
    WebUI->>OrderService: создатьЗаказ(данные)
    activate OrderService
    OrderService->>StockService: проверитьНаличие(товар, кол-во)
    activate StockService
    StockService-->>OrderService: результат проверки
    deactivate StockService
    alt есть на складе
        OrderService->>PaymentGateway: провестиОплату(сумма)
        activate PaymentGateway
        PaymentGateway-->>OrderService: успешно
        deactivate PaymentGateway
        OrderService->>StockService: зарезервировать(товар, кол-во)
        OrderService-->>WebUI: заказ создан, статус «оплачен»
    else нет на складе
        OrderService-->>WebUI: ошибка «товар закончился»
    end
    deactivate OrderService
    WebUI-->>Пользователь: уведомление о результате

Communication (иллюстрация порядка; Mermaid не поддерживает нативный Communication Diagram):

Рисунок ниже показывает последовательность сообщений 1, 2, 3… того же сценария. Это не канонический вид UML Communication (нет ассоциаций с нумерацией на связях) — для формальной модели используйте EA или draw.io в UML-режиме (07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io)).

graph LR
    Пользователь((Пользователь)) --- WebUI[Веб-интерфейс]
    WebUI --- OS[СервисЗаказов]
    OS --- SS[СервисСклада]
    OS --- PG[ПлатёжныйШлюз]

    Пользователь -->|1: инициировать| WebUI
    WebUI -->|2: создатьЗаказ| OS
    OS -->|3: проверитьНаличие| SS
    SS -->|4: результат| OS
    OS -->|"[есть на складе] 5: провестиОплату"| PG
    PG -->|"[есть на складе] 6: успешно"| OS
    OS -->|"[есть на складе] 7: зарезервировать"| SS
    OS -->|"[есть на складе] 8: заказ создан"| WebUI
    OS -->|"[нет на складе] 5a: ошибка"| WebUI
    WebUI -->|9: уведомить| Пользователь

PlantUML: отдельного синтаксиса @startcommunication в PlantUML нет (запрос в сообществе с 2014 г.). Для communication-подобного вида используют object diagram или deployment/workaround с нумерованными подписями на связях; sequence-синтаксис с номерами 1:, 2: — это sequence diagram, а не канонический Communication Diagram по UML.

2.4 Сравнение Sequence и Communication

Обе диаграммы связаны с диаграммой классов: lifeline / объект — экземпляр класса; сообщение должно соответствовать операции (или сигналу) класса-получателя.

2.5 Timing и Interaction Overview (обзор нотации)

Timing Diagram — горизонтальная ось времени; каждая lifeline показывает состояние (или значение) в интервалах. Ключевые элементы:

• State invariant — условие на lifeline в момент времени (например, {status = active}).
• Duration constraint — ограничение длительности между событиями ({d .. 500ms}).
• Смена состояния — ступеньки на линии; сообщения — короткие стрелки между lifelines.

Применение: протоколы с таймаутами, SLA по времени отклика, встраиваемые системы. В типовой SA-документации чаще хватает sequence с текстовым NFR по времени (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).

Interaction Overview Diagram — activity-подобный поток, где узлы — не действия, а ref на другие interaction:

[ref: Авторизация] → (alt: роль?) → [ref: Оформление заказа] → [ref: Уведомление]

Поток управления (ветвления, merge) — как на Activity Diagram, но содержимое узлов — ссылки на sequence/communication. Удобна как карта из десятка связанных сценариев вместо одной перегруженной sequence; детали каждого блока — в именованной interaction через ref/sd.

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

Interaction diagrams на проекте обычно следуют за текстовым сценарием прецедента — см. цепочку в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case). На нотационном уровне аналитик решает:

Пошаговая методика и критерии качества SA-артефакта здесь не дублируются — они живут в 03.02.03 Диаграмма последовательности (Sequence Diagram).

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

• Смешение UML-async и «Kafka-async» — открытая стрелка ≠ обязательно брокер; уточняйте в подписи или тексте спецификации.
• Разные сценарии на Sequence и Communication — при сравнении views одного interaction содержание должно совпадать (те же участники, ветки, сообщения).
• Перегрузка одной диаграммы — десятки сообщений без ref; используйте Interaction Overview или набор связанных sequence.
• Неверный уровень lifeline — классы Java на диаграмме согласования с заказчиком; актор + «Система» там, где нужна декомпозиция сервисов.
• Пропуск reply (return) при контрактах — без явного return легко потерять коды ошибок и тело ответа в требованиях.
• Create vs «исчезновение» lifeline — уничтожение объекта моделируется явной стрелкой Destroy (X на lifeline), а не просто обрывом линии; создание — стрелкой <<create>> к новой lifeline.
• Mermaid как «строгий UML» — diagram-as-code удобен для ревью в Git (07.05 Системы контроля версий (Git) для документации), но не покрывает found/lost, gates, полный ref; для формальной модели — EA / PlantUML + OMG.
• rect в Mermaid ≠ combined fragment UML — не переносите Mermaid-ограничения в требования к нотации на sign-off.
• PlantUML sequence с номерами ≠ Communication Diagram — не выдавайте workaround за канонический вид UML.
• Graph LR как Communication — направленные рёбра Mermaid не заменяют ассоциации с нумерацией на связях.
• Дублирование 03.02.03 — не превращайте эту заметку в руководство по ведению артефакта; держите фокус на нотации UML 2.5.

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

• 06.01.01 Структурные диаграммы (Class, Object, Package) — классы и ассоциации, лежащие в основе lifeline и линков Communication
• 06.01.02 Поведенческие диаграммы (State, Activity, Use Case) — прецеденты и activity как контекст для interaction
• 03.02.03 Диаграмма последовательности (Sequence Diagram) — прикладное SA-применение sequence (трассировка, качество артефакта)
• 03.02.01 Диаграмма прецедентов (Use Case Diagram) — источник сценариев для детализации
• 03.02.02 Диаграмма деятельности (Activity Diagram) — порядок действий vs порядок сообщений
• 03.02.04 Диаграмма состояний (State Machine Diagram) — жизненный цикл объекта vs один проход interaction
• 03.01.02 Моделирование контекста системы (Context Diagram) — границы системы, found/lost и gates
• 03.01.04 Интерфейсы и интеграционные взаимодействия — интеграции и контракты на sequence
• 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) — контракты, соответствующие сообщениям
• 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events) — архитектурный контекст async-сообщений
• 03.05.06 Event-Driven Architecture — слой архитектуры за UML-async на диаграмме
• 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) — полная поддержка UML Interactions
• 08.03 Тестирование требований (статическое тестирование) — проверка полноты путей по диаграмме

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

• OMG Unified Modeling Language (OMG UML), Version 2.5.1 — раздел Interactions (Sequence, Communication, Timing, Interaction Overview). https://www.omg.org/spec/UML/2.5.1
• OMG UML 2.5.1 Specification (PDF) — нормативное описание interaction views и combined fragments. https://www.omg.org/spec/UML/2.5.1/PDF
• Гради Буч, Джеймс Рамбо, Ивар Якобсон. «Язык UML. Руководство пользователя» — полное описание диаграмм взаимодействия. 2-е изд., ДМК Пресс.
• Мартин Фаулер. «UML. Основы» — практические советы по Sequence и Communication. 3-е изд., Символ-Плюс.
• Крэг Ларман. «Применение UML и шаблонов проектирования» — образцы sequence для паттернов GRASP. 3-е изд., Вильямс.
• PlantUML Sequence Diagram Guide — синтаксис sequence и combined fragments. https://plantuml.com/sequence-diagram
• PlantUML Q&A: UML Communication diagram — обходной путь через object/deployment diagram (нативного communication-синтаксиса нет). https://forum.plantuml.net/6559/uml-communication-diagram
• Mermaid Sequence Diagram Documentation — ограничения Mermaid (sequence only, без Communication). https://mermaid.js.org/syntax/sequenceDiagram.html
• Scott W. Ambler. «The Elements of UML 2.0 Style» — рекомендации по стилю оформления interaction diagrams.