Диаграмма деятельности (Activity Diagram) — поведенческая диаграмма UML для моделирования потока управления: последовательность действий, ветвления, параллельные потоки и распределение ответственности между участниками. Если 03.02.01 Диаграмма прецедентов (Use Case Diagram) отвечает на вопрос «что делает система?», то Activity Diagram закрывает «в каком порядке?, при каких условиях?, кто выполняет шаг?». На проекте это главный инструмент детализации сценариев прецедентов, описания системных workflow и прояснения алгоритмов до спецификации и кода.

1. Суть темы

Главная цель — перевести текстовый или устный сценарий в проверяемую модель потока, с которой можно согласовать логику с разработкой и тестированием. Диаграмма деятельности связывает прецедент (03.02.01 Диаграмма прецедентов (Use Case Diagram)) с реализацией: каждый шаг — кандидат на функциональное требование, API-вызов или шаг приёмки (02.04.02 Критерии приёмки (Acceptance Criteria)).

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

  • моделирование потока управления — линейного, условного и параллельного;
  • детализация прецедентов — основной, альтернативные и исключительные потоки;
  • описание workflow внутри ПО — операции, интеграции, ожидание ответов;
  • прояснение алгоритмов обработки данных на уровне операции или сервиса;
  • фиксация стыков между людьми, подсистемами и внешними системами в смешанных процессах.

Три контекста применения (выбор нотации, не полный курс по процессам):

КонтекстЧто моделируемТипичные элементы
Детализация прецедентаMain / alternate / exception из 10.01.02 Шаблон Use CaseДорожки, decision/merge, связь с UC-ID
Системный workflowЛогика реализации фичи в ПОДействия системы, интеграционные шаги, fork/join
Алгоритм операцииЛогика метода, правила расчётаВетвления, циклы, без дорожек

Для сквозных бизнес-процессов, регламентов, as-is/to-be и автоматизации в BPMS — основная нотация 03.04.01 BPMN 2.0 - введение и основы; Activity Diagram здесь допустима как быстрый эскиз, но не заменяет BPMN в домене описания бизнес-процессов. Сравнение нотаций и типовые паттерны BPMN — в 03.04.01 BPMN 2.0 - введение и основы и 10.01.08 Шаблон сквозной фичи (BPMN-процесс).

Activity Diagram vs State Machine (03.02.04 Диаграмма состояний (State Machine Diagram)): Activity Diagram описывает процесс (последовательность работ над данными); State Machine — жизненный цикл объекта (состояния сущности и переходы между ними). Прецедент «Оформить заказ» — Activity Diagram; сущность «Заказ» со статусами Создан → Оплачен → Отгружен — State Machine. На одном проекте обе диаграммы часто сосуществуют: AD показывает, что происходит в сценарии; SM — в каком состоянии находится заказ после каждого шага.

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

Полная палитра UML 2.5 — в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case). Ниже — то, что системный аналитик рисует в UC-детализации, workflow и алгоритмах; остальные элементы (signal, expansion region, interruptible region) сверяйте со справочником UML.

Деятельность, действие и декомпозиция

ПонятиеСмысл для SA
Деятельность (Activity)Композитный процесс: одна «рамка» сценария = одна деятельность
Действие (Action)Атомарный шаг: «Проверить остатки», «Отправить запрос в шлюз». Именуют глагольной фразой
Call ActivityСсылка на другую AD или операцию — декомпозиция без перегрузки одного листа

Узлы управления: что рисуем чаще всего

ЭлементКогда нужен SA
Initial NodeСтарт потока. В детализации UC — почти всегда один; несколько initial допустимы для независимых параллельных стартов (редко в UC)
Activity FinalЗавершение всей деятельности
Flow FinalЗавершение одного потока при параллельности (после fork)
Decision / MergeАльтернатива (или/или): ветки main / alternate / exception
Fork / JoinПараллельность (и/и): несколько действий одновременно, затем синхронизация

Decision/merge и fork/join — разная семантика; смешивать нельзя. Подробные обозначения и редкие узлы — в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case).

Циклы

Повторение моделируют Loop Node (test-before / test-after) или стрелкой назад к merge/decision со сторожевым условием выхода — упрощённый приём, если редактор не поддерживает loop node. Для контекста «алгоритм операции» (см. §3) циклы так же важны, как ветвления.

Поток управления и поток объектов

ТипЧто передаётсяКогда нужен SA
Control flowУправление: «после A выполни B»Большинство UC-детализаций
Object flowДанные между действиями (object node)Когда важно, что передаётся: «Корзина», «Черновик заказа», «Квитанция об оплате». Имена сверяют со 03.03.03 Словарь данных (описание)

Object flow не заменяет 03.04.02 Диаграмма потоков данных (DFD): DFD — потоки между процессами и хранилищами; Activity Diagram — управление шагами с опциональной привязкой объектов.

Критерий добавления object node: объект меняет форму или статус между шагами и это влияет на FR или тест. Если достаточно «система сохранила заказ» — достаточно control flow.

Дорожки и асинхронность

  • Дорожка (Swimlane) — группировка по исполнителю: роль, подсистема, внешняя система.
  • Send Signal / Accept Event — ожидание асинхронного события (webhook, таймаут, сообщение из очереди).

Правило выбора нотации для async: если важен порядок шагов и ветвления внутри сценария («ожидать webhook до 30 с, иначе отменить») — Activity Diagram с Accept Event; если важен обмен сообщениями между компонентами во времени (кто кому и в какой последовательности) — 03.02.03 Диаграмма последовательности (Sequence Diagram). Оба артефакта дополняют друг друга; стыкуется с 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events).

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

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

Детализация AD одинаково нужна и для UC, и для stories: различается исходный артефакт. Команда на прецедентах начинает с 10.01.02 Шаблон Use Case; на stories — со story map или эпика (04.02 Пользовательские истории (User Stories) и Job Stories). Критерий выбора подхода — в 04.03 Use Case vs User Story — выбор подхода. В обоих случаях AD переводит narrative в проверяемый поток.

Детализация прецедента

Один прецедент → одна или несколько диаграмм:

  • основной поток — отдельная AD или выделенный путь на общей схеме;
  • альтернативы и исключения — ветки через decision/merge или отдельные диаграммы с префиксом UC-ID (например, UC-05-alt-промокод);
  • extension points — вход через decision «расширение X активно» или отдельная AD со ссылкой на точку расширения в 10.01.02 Шаблон Use Case.

Критерий: каждый путь от initial до activity final должен соответствовать шагам в текстовой спецификации (02.03.03 Спецификация требований (SRS, Use Case, User Story)). Шагам на диаграмме присваивают стабильные ID (UC-05-S03, FR-ORD-012) — те же идентификаторы используют в FR, матрице трассировки (10.01.15 Шаблон матрицы трассировки) и тест-кейсах.

Пример: прецедент «Оформить заказ»

Сценарий с дорожками «Покупатель», «Интернет-магазин», «Платёжный шлюз». Проверка доступности — действие системы; decision «Товары доступны?» и «Платёж успешен?» — в дорожке системы (условие по результату системного действия, не бизнес-выбор покупателя). Поток последовательный: fork/join не используется.

Object flow в сценарии: Корзина → после подтверждения Черновик заказа → после успешной оплаты Подтверждённый заказ. В UML-редакторе object node ставят между действиями; в упрощённой схеме ниже объекты указаны в подписи шага.

Три activity final на схеме — три исхода одной деятельности (исключение «товары недоступны», основной успех, альтернатива «ошибка оплаты»), а не три несвязанных процесса. Каждый путь = отдельный сценарий приёмки; merge к одному final не обязателен, если исходы семантически различны.

В Mermaid нет нативных UML-дорожек, object flow и различия activity final / flow final; ниже — flowchart с subgraph. В 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) семантика строже.

flowchart TD
    start([Start]) --> A

    subgraph Customer[Покупатель]
        A[UC-05-S01: Просмотр корзины]
        B[UC-05-S02: Ввод адреса доставки]
        C[UC-05-S03: Подтверждение заказа]
        D[UC-05-S04: Переход на страницу платёжного шлюза]
        E[UC-05-S05: Возврат после оплаты]
        A --> B --> C --> D --> E
    end

    subgraph System[Интернет-магазин]
        F[UC-05-S01: Проверить доступность товаров]
        G{Товары доступны?}
        H[Сообщить об ошибке]
        I[UC-05-S02: Рассчитать стоимость доставки]
        J[UC-05-S03: Сформировать запрос на авторизацию]
        K[UC-05-S04: Отправить запрос в платёжный шлюз]
        L[UC-05-S05: Получить результат платежа]
        M{Платёж успешен?}
        N[Сохранить заказ]
        O[Отправить уведомление]
        P[Отобразить ошибку оплаты]
        F --> G
        G -->|Нет| H --> stop1([Activity Final — отказ])
        G -->|Да| G_ok[Товары доступны]
        J --> K --> L --> M
        M -->|Да| N --> O --> stop2([Activity Final — успех])
        M -->|Нет| P --> stop3([Activity Final — ошибка оплаты])
    end

    subgraph Gateway[Платёжный шлюз]
        Q[Авторизовать платёж] --> R[Вернуть результат]
    end

    A --> F
    B --> I
    C --> J
    K --> Q
    R --> L
    E -.->|UI-синхронизация| L

    style H fill:#f9f,stroke:#333,stroke-width:2px
    style P fill:#f9f,stroke:#333,stroke-width:2px

Описание потока (номера шагов совпадают с ID на схеме):

  1. Покупатель просматривает корзину (UC-05-S01); система проверяет доступность позиций. Object: Корзина.
  2. Если позиции недоступны — система сообщает об ошибке → activity final (исключительный поток).
  3. При успехе покупатель вводит адрес (UC-05-S02); система рассчитывает доставку.
  4. Покупатель подтверждает заказ (UC-05-S03); система формирует Черновик заказа и запрос на авторизацию.
  5. Покупатель переходит на страницу шлюза (UC-05-S04); система отправляет запрос; шлюз авторизует платёж и возвращает результат.
  6. Система получает результат на шаге «Получить результат платежа» (UC-05-S05); покупатель возвращается в UI — пунктир показывает синхронизацию интерфейса, не параллельную развилку. Decision «Платёж успешен?» опирается только на ответ шлюза (шаг L), не на факт возврата пользователя.
  7. При успехе — сохранение Подтверждённого заказа и уведомление → activity final (основной поток). При отказе — ошибка оплаты → activity final (альтернативный поток).

Где был бы fork/join: если после успешной оплаты система параллельно отправляет email и публикует событие в шину — fork после «Сохранить заказ», две ветки, join перед activity final.

Алгоритм операции: когда AD вместо псевдокода

Контекст «алгоритм операции» из таблицы §1 закрывает детализацию логики метода или сервиса в SRS, когда текстовый псевдокод плохо читается из-за ветвлений и циклов.

Когда достаточно AD: правило расчёта с 3+ ветками, многошаговая валидация с накоплением ошибок, итерация по коллекции (expansion region или loop). Дорожки не нужны — один исполнитель «Сервис».

Микро-пример — расчёт скидки:

flowchart TD
    s([Start]) --> A[Получить сумму корзины и профиль клиента]
    A --> B{Клиент VIP?}
    B -->|Да| C[Скидка 15%]
    B -->|Нет| D{Сумма >= порога?}
    D -->|Да| E[Скидка 10%]
    D -->|Нет| F[Скидка 0%]
    C --> G[Применить промокод если передан]
    E --> G
    F --> G
    G --> H{Промокод валиден?}
    H -->|Да| I[Пересчитать с учётом промокода]
    H -->|Нет| J[Вернуть базовую скидку]
    I --> K([Activity Final])
    J --> K

Такую AD включают в FRD рядом с контрактом API (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)) вместо абзаца «если VIP, то…».

Activity Diagram vs BPMN

Практическое правило: процесс реализуется в ПО и нужна связь с архитектурой UML → Activity Diagram; регламент, оргструктура, BPMS, согласование с бизнесом → 03.04.01 BPMN 2.0 - введение и основы. Подробное сравнение — там же, не дублируйте таблицу в каждой SA-статье.

Связь с артефактами требований

Диаграмма создаётся на этапе спецификации (02.03.03 Спецификация требований (SRS, Use Case, User Story)) и проходит 02.04.01 Верификация и валидация (V&V): все ветки из UC покрыты?, у каждого decision есть [else]?, join после каждого fork?

ИИ как черновик: LLM-ассистенты ускоряют генерацию PlantUML/Mermaid по тексту сценария, но не гарантируют корректность fork/join и дорожек. Черновик от модели обязательно проверяете сами; промпты и ограничения — в 11.03 Промпт-инжиниринг для аналитика и 11.07 Практические кейсы применения LLM в анализе. Process mining (Celonis, Disco) строит BPMN/process map из логов, а не UML Activity Diagram — результат используют как вход для анализа, не как готовый SA-артефакт.

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

Ошибки моделирования

  • Смешивать decision/merge с fork/join — разная семантика (альтернатива vs параллельность).
  • Decision в «чужой» дорожке — условие по результату системного действия рисуют там, где выполнялась проверка (дорожка системы), а в UI показывают только действия пользователя.
  • Decision до получения данных — «Платёж успешен?» до шага «Получить результат платежа»; типичная ошибка при смешении UI-шагов и API-ответов.
  • Забыть join после fork — теряются зависимости между параллельными ветками.
  • Перегрузить диаграмму — валидация полей, мелкие технические шаги; декомпозируйте через Call Activity.
  • Activity Diagram для структуры — иерархия классов и модулей → 06.01.01 Структурные диаграммы (Class, Object, Package), 03.01.03 Декомпозиция системы на подсистемы и модули.
  • Activity Diagram вместо State Machine — статусы сущности «Заказ» → 03.02.04 Диаграмма состояний (State Machine Diagram).
  • Activity Diagram вместо BPMN — сквозной процесс с таймерами, эскалациями, регламентом → 03.04.01 BPMN 2.0 - введение и основы.

Ограничения нотации

Практики, которые работают

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

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

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

Книги

  • Гради Буч, Джеймс Рамбо, Ивар Якобсон. «Язык UML. Руководство пользователя». 2-е изд. — М.: ДМК Пресс, 2006.
  • Крэг Ларман. «Применение UML и шаблонов проектирования». 3-е изд. — М.: Вильямс, 2013.
  • Мартин Фаулер. «UML. Основы». 3-е изд. — СПб.: Символ-Плюс, 2018.

Статьи и онлайн-руководства

Инструменты

Видеокурсы

  • «UML Fundamentals» (Simon Allardice) — Pluralsight (по подписке).
  • «Software Design and Architecture: UML and Beyond» — Coursera, University of Alberta.
  • «Системный анализ и UML» — Stepik (русскоязычный курс).