Поведенческие диаграммы UML отвечают на вопрос «как система работает?» — в отличие от структурных (06.01.01 Структурные диаграммы (Class, Object, Package)), которые описывают состав. В UML 2.5 к поведению относятся также диаграммы взаимодействия (Sequence, Communication и др.) — обзор нотации в 06.01.03 Диаграммы взаимодействия (Sequence, Communication), прикладной разбор Sequence — в 03.02.03 Диаграмма последовательности (Sequence Diagram). Диаграммы Timing и Interaction Overview в этой заметке не разбираются — они реже нужны в повседневной работе аналитика. Здесь — три базовые вида для выбора нотации и уровня абстракции: State Machine, Activity и Use Case. Полная прикладная проработка каждого вида — в 03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.02.02 Диаграмма деятельности (Activity Diagram) и 03.02.04 Диаграмма состояний (State Machine Diagram). Формальная опора — спецификация OMG UML 2.5; контекст стандартов — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

1. Суть темы

Три диаграммы покрывают разные уровни модели поведения:

ДиаграммаГлавный вопросУровеньФокус
State MachineВ каких состояниях объект и как они меняются?Низкий (экземпляр класса)Жизненный цикл одного объекта
ActivityВ какой последовательности выполняются действия?Средний (процесс, алгоритм)Поток работ; объект-привязка необязательна
Use CaseКакие услуги система даёт внешнему миру?Высокий (система в целом)Функциональный scope и требования, не динамика одного объекта

Граница статьи. Ниже — шпаргалка по нотации UML 2.5, сравнение и минимальные примеры. Каталог элементов, паттерны (протокольный автомат, interruptible activity region, expansion region) и пошаговые сценарии процессов — в ветке 03.02. Диаграммы обмена сообщениями — в 06.01.03 Диаграммы взаимодействия (Sequence, Communication) и 03.02.03 Диаграмма последовательности (Sequence Diagram).

Цепочка артефактов на проекте (одна фича, разные представления):

  1. Use Case Diagram — граница системы и список прецедентов.
  2. Текстовый сценарий — по 02.03.03 Спецификация требований (SRS, Use Case, User Story) или 10.01.02 Шаблон Use Case; выбор формата — 04.03 Use Case vs User Story — выбор подхода.
  3. Activity или Sequence — пошаговый поток (03.02.02 Диаграмма деятельности (Activity Diagram)) или обмен сообщениями (06.01.03 Диаграммы взаимодействия (Sequence, Communication), 03.02.03 Диаграмма последовательности (Sequence Diagram)).
  4. State Machine — допустимые статусы ключевой сущности (заказ, заявка, сессия); guard и переходы — основа для 02.04.02 Критерии приёмки (Acceptance Criteria) и тест-кейсов.
  5. Трассировка — связь прецедентов, диаграмм, AC и тестов по 02.03.04 Трассировка требований (концепция) или 10.01.15 Шаблон матрицы трассировки.

Овал на диаграмме прецедентов — не спецификация: это маркер функции; детали живут в текстовом use case или связанных диаграммах.

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

2.1 Диаграмма состояний (State Machine Diagram)

Моделирует жизненный цикл одного экземпляра (заказ, заявка, устройство, сессия checkout). Важно не путать со «статусом процесса» на Activity: state machine привязан к объекту, а не к workflow в целом. Условия на переходах ([guard]) и допустимые события — проверяемые правила: их удобно выносить в критерии приёмки и сценарии 08.03 Тестирование требований (статическое тестирование).

Шпаргалка элементов:

ЭлементНазначение
StateУстойчивая ситуация; секции entry / do / exit
Transitionсобытие [guard] / действие
Initial / FinalНачало и конец жизненного цикла
Composite StateСостояние с вложенной диаграммой подсостояний внутри того же автомата
Submachine StateСсылка на отдельную переиспользуемую диаграмму состояний

Composite vs Submachine: composite детализирует фазу «на месте»; submachine выносит общий автомат (например, «Оплата») в отдельную модель и подключает её в нескольких родительских состояниях.

Дополнительные псевдосостояния UML — choice, junction, shallow/deep history, entry/exit point составных состояний — см. 03.02.04 Диаграмма состояний (State Machine Diagram).

stateDiagram-v2
    [*] --> Новый
    Новый --> Подтверждён : оплатить [корзина не пуста]
    Подтверждён --> ВОбработке : начатьСборку()
    ВОбработке --> Отправлен : отгрузить()
    Отправлен --> Доставлен : доставить()
    Доставлен --> [*]

    state ВОбработке {
        [*] --> Укомплектование
        Укомплектование --> Упаковка : товарыСобраны
        Упаковка --> [*]
    }

2.2 Диаграмма деятельности (Activity Diagram)

Моделирует поток работ: последовательность, ветвления, параллельные ветки, зоны ответственности. Похожа на блок-схему, но в UML есть строгая семантика Fork/Join, object flow и сигналов — flowchart в Mermaid или draw.io не заменяет эти элементы без явной договорённости в команде.

Шпаргалка элементов:

ЭлементНазначение
Initial NodeТочка входа в поток (закрашенный круг)
ActionАтомарный шаг
Decision / MergeВетвление и слияние альтернатив (ромб)
Fork / JoinЖирная полоса: разделение и синхронизация параллельных потоков
Activity FinalКонец всего потока (закрашенный круг в обводке)
Flow FinalЗавершение одной ветки без остановки остальных
Swimlane (Partition)Одно действие — одна дорожка ответственности
Object Flow / PinПередача объекта или данных между действиями
SignalАсинхронный приём или отправка

Продвинутые конструкции (interruptible activity region, expansion region, параллельные ветки с циклами оплаты) — в 03.02.02 Диаграмма деятельности (Activity Diagram).

flowchart TD
    start(( )) --> A[Проверить наличие на складе]
    A --> B{Товар есть?}
    B -->|Нет| C[Уведомить клиента о задержке]
    C --> finish((( ))
    B -->|Да| D[Зарезервировать товар]
    D --> E[Сформировать счёт]
    E --> F[Передать в доставку]
    F --> finish

Замечание: пример выше — упрощённый happy path; Fork/Join, swimlanes и object flow — в 03.02.02 Диаграмма деятельности (Activity Diagram). В UML Fork/Join — синхронизационные полосы, а не действия с текстом. В Mermaid узлы — иллюстрация идеи; в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) и PlantUML используются классические UML-фигуры.

Activity vs BPMN 2.0: BPMN (03.04.01 BPMN 2.0 - введение и основы) выбирают, когда процесс согласуют с бизнесом в привычной нотации или нужна исполняемость (Camunda и аналоги). UML Activity — когда модель уже в UML-стеке, нужна связка с классами, state machine и sequence на одной платформе, или описывается алгоритм операции без выхода в BPMN.

2.3 Диаграмма прецедентов (Use Case Diagram)

Фиксирует функциональный scope: кто (акторы) и какие цели (прецеденты) обслуживает система. Это модель требований, а не трассировка состояний одного объекта во времени.

Шпаргалка элементов:

ЭлементНазначение
ActorВнешнее действующее лицо; основной инициирует прецедент, вспомогательный только откликается (например, платёжный шлюз)
Use CaseУслуга системы; имя — глагольная форма цели
System BoundaryПрямоугольник вокруг прецедентов системы
AssociationЛиния связи актора с прецедентом (не зависимость)
<<include>>Стрелка от базового прецедента к включаемому; общий обязательный фрагмент
<<extend>>Стрелка от расширяющего прецедента к базовому; опциональное поведение в точке расширения (extension point) базового сценария
ОбобщениеНаследование акторов или прецедентов
graph LR
    Клиент((Клиент)) --- ОформитьЗаказ[Оформить заказ]
    Клиент --- ПросмотрКаталога[Просмотреть каталог]
    ПлатёжныйШлюз((Платёжный шлюз)) --- ОформитьЗаказ

    ОформитьЗаказ -.->|include| Авторизоваться[Авторизоваться]
    ПрименитьПромокод[Применить промокод] -.->|extend| ОформитьЗаказ

    subgraph Система["Интернет-магазин"]
        ОформитьЗаказ
        ПросмотрКаталога
        Авторизоваться
        ПрименитьПромокод
    end

Пояснение: линии актор–прецедент — ассоциации. <<extend>> идёт от «Применить промокод» к «Оформить заказ» — расширение подключается в точке расширения базового сценария (например, шаг «Подтвердить сумму»), а не к просмотру каталога. Детали отношений и elicitation — 03.02.01 Диаграмма прецедентов (Use Case Diagram).

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

Когда какую диаграмму выбрать

СитуацияДиаграмма
Статусы сущности, протокол допустимых переходов, риск неконсистентных состоянийState Machine
Пошаговый процесс, параллельные ветки, роли/системы в одном сценарииActivity (или BPMN — см. 03.04.01 BPMN 2.0 - введение и основы)
Старт проекта, граница системы, согласование функций со стейкхолдерамиUse Case + 03.01.02 Моделирование контекста системы (Context Diagram)
Уточнение сценария прецедента или операцииActivity → затем Sequence (06.01.03 Диаграммы взаимодействия (Sequence, Communication) — обзор UML; 03.02.03 Диаграмма последовательности (Sequence Diagram) — рабочий артефакт в SRS)
Ключевая сущность с жизненным циклом после согласования потокаState Machine для этой сущности

Практический порядок работы

  1. Scope: диаграмма прецедентов и контекст — что внутри системы, кто снаружи (02.01.04 Определение границ решения (Scope Modelling)).
  2. Детализация: текстовый use case (10.01.02 Шаблон Use Case, 02.03.03 Спецификация требований (SRS, Use Case, User Story)).
  3. Поток: Activity для happy path и веток; при необходимости Sequence для сообщений между компонентами (03.02.03 Диаграмма последовательности (Sequence Diagram)).
  4. Инварианты объекта: State Machine для заказа, платежа, сессии — отдельно от «процесса оформления» на Activity; guards → AC и тесты.
  5. Трассировка: матрица связей прецедент ↔ диаграммы ↔ AC ↔ тесты (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки).

State machine всегда про один экземпляр; activity может описывать сквозной процесс без привязки к одному объекту. Путаница «state заказа» vs «state шага checkout на диаграмме деятельности» — частый источник ошибок в спецификации.

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

ОшибкаКак избежать
Неверное направление <<extend>> (как у include)Стрелка от расширяющего к базовому; на базовом — extension point
extend к нерелевантному прецеденту (промокод ↔ каталог)Связывать расширение с прецедентом, где поведение реально вставляется
Fork/Join как обычные действияСинхронизационные полосы; параллельные ветки сходятся в Join
Merge вместо Join (или наоборот)Merge — для альтернатив после Decision; Join — для параллельных веток после Fork
Дублирование действий в swimlanesОдно действие — одна дорожка
State machine для целого процессаProcess → Activity/BPMN; state — для объекта с дискретными статусами
Use Case diagram вместо спецификацииОвал — индекс; сценарии, AC и данные — в тексте и смежных диаграммах
Избыточная деталь нотации в scope-диаграмме или обзореНа UC и обзорных схемах — минимум; полная нотация — 03.02.02 Диаграмма деятельности (Activity Diagram), 03.02.04 Диаграмма состояний (State Machine Diagram)
Flowchart «как UML» без договорённостиЯвно помечайте упрощения; для ревью с архитекторами — инструмент с UML 2.5 (07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io))

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

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

Стандарты и спецификации

Книги

  • Гради Буч, Джеймс Рамбо, Ивар Якобсон. «Язык UML. Руководство пользователя» — обзор поведенческих диаграмм. 2-е изд., ДМК Пресс.
  • Мартин Фаулер. «UML. Основы» — краткий ввод в state, activity и use case. 3-е изд., Символ-Плюс.
  • Крэг Ларман. «Применение UML и шаблонов проектирования» — связка диаграмм в проектировании. 3-е изд., Вильямс.
  • Алистер Коберн. «Современные методы описания функциональных требований к системам» — практика текстовых use case (дополняет 03.02.01 Диаграмма прецедентов (Use Case Diagram) и 04.03 Use Case vs User Story — выбор подхода).

Справочники по нотации в инструментах