UML Activity диаграмма на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Activity diagram — диаграмма потока работ. Заменяет flowchart на «правильную нотацию». На собесе SA: «нарисуй activity для оформления заказа», «зачем fork/join», «отличие activity от BPMN». Спрашивают часто в сочетании с BPMN.

Главная боль без понимания — SA рисует flowchart с прямоугольниками и ромбами без UML-нотации, разработчик плохо читает, тестировщик не понимает варианты ветвления.

Элементы Activity diagram

Initial node — закрашенный круг, точка старта.

Final node — закрашенный круг с обводкой (бычий глаз), завершение activity.

Action — закругленный прямоугольник с глаголом в инфинитиве: «Проверить email», «Создать заказ».

Control flow — стрелка между элементами. Показывает порядок.

Decision — ромб, ветвление по условию.

Merge — ромб, объединение веток (вход — несколько потоков, выход — один).

Fork — толстая чёрная горизонтальная линия (sync bar), запуск параллельных потоков.

Join — то же изображение, но ждёт всех потоков и продолжает.

Object node — прямоугольник, объект-данные между actions (например, документ).

Swimlane (partition) — вертикальные / горизонтальные дорожки, ответственный за action.

●
↓
[Открыть корзину]
↓
<Корзина пуста?>
   yes              no
   ↓                ↓
[Показать пустую]  [Перейти к оформлению]
                   ↓
                   ━━━ fork ━━━
                   ↓     ↓
              [Резерв]  [Платёж]
                   ↓     ↓
                   ━━━ join ━━━
                   ↓
                   ◉

Decision и merge

Decision — точка, где поток разветвляется на несколько в зависимости от условия. Каждое условие на стрелке в [квадратных скобках].

              <amount > 1000?>
              /                \
        [yes] /                  \ [no]
            ↓                    ↓
   [Запросить approval]    [Списать сразу]

Merge — где несколько потоков сходятся в один. Не ждёт всех (это join), а просто объединяет.

Правила:

• Условия на decision должны покрывать все случаи (включая else).
• Условия должны быть взаимоисключающими.
• Стрелка [default] или [else] для catch-all.

В строгом UML decision и merge — разные ромбы. На практике часто рисуют один ромб с несколькими входами и выходами — UML это допускает.

Fork и join: параллелизм

Fork — все исходящие потоки запускаются одновременно.

Join — ждёт завершения всех входящих, продолжает один.

               ━━━━━━━━━ fork ━━━━━━━━━
                ↓         ↓         ↓
          [Email]    [SMS]      [Push]
                ↓         ↓         ↓
               ━━━━━━━━━ join ━━━━━━━━━
                          ↓
                  [Записать в лог]

В реальной системе это значит: послать email, sms, push параллельно, потом залогировать.

Asynchronous flow (выход из fork без последующего join) допустим для «fire and forget»:

[Создать заказ]
     ↓
   ━━━ fork ━━━
   ↓        ↓
[Send analytics event]  [Continue main flow]
                          ↓
                          ...

Здесь analytics event улетает «в сторону», основной flow продолжается без ожидания.

Swimlanes (partitions)

Дорожки определяют, кто (роль / система) выполняет action.

| Customer    | WebApp        | PaymentService | Bank      |
|             |               |                |           |
| ●           |               |                |           |
| ↓           |               |                |           |
| [Choose pay]|               |                |           |
| ────────────→               |                |           |
|             | [Authorize]   |                |           |
|             | ──────────────→                |           |
|             |               | [Charge]       |           |
|             |               | ──────────────→|           |
|             |               |                |[Decision] |
|             |               | ←─────────────|            |
|             | ←─────────────|                |           |
| ←──────────|               |                |           |
| ◉           |               |                |           |

Когда swimlanes полезны:

• Кросс-функциональные процессы (где Customer ↔ WebApp ↔ Backend ↔ External).
• Ответственность разных ролей.
• Бизнес-процесс с несколькими отделами.

Когда нет:

• Технические потоки внутри одной системы — лишний оверхед.

Object flow и signals

Object flow. Стрелка с прикреплённым прямоугольником-объектом — данные передаются между actions.

[Сформировать счёт] → ⟦Invoice⟧ → [Отправить клиенту]

Полезно, когда важен пайплайн данных, не только последовательность.

Send signal / Accept signal action. Для асинхронных взаимодействий.

[Send "OrderCreated"] (флажок)         (треугольник) [Accept "PaymentReceived"]

В современной архитектуре часто моделируется через event-driven flow.

Activity vs BPMN — когда что

Эмпирическое правило:

• Внутри одной системы / разработка — UML Activity.
• Бизнес-процесс с многими участниками / автоматизация workflow — BPMN.
• В банках / госе на собесе спросят оба.

Частые ошибки

Перепутать decision и merge. Decision — ветвление по условию. Merge — объединение без ожидания. На бумаге выглядят одинаково (ромб), но разные семантически.

Fork без join. Параллельные потоки запущены, но никто не ждёт — может быть багом или сознательным fire-and-forget. Делать выбор сознательно.

Условия не покрывают все случаи. Decision с [yes] и без [no] (или с пропущенным else) — поток зависает.

Swimlanes без явного исполнителя. Если action не лежит чётко в одной дорожке — непонятно, кто отвечает.

Слишком много actions на одной диаграмме. Декомпозиция: высокоуровневая activity → каждый сложный action разворачивается в свою sub-activity.

Использовать activity для sequence-сценариев. Sequence показывает взаимодействие объектов с временем. Activity — поток шагов. Не путай.

Стрелка без направления. UML требует стрелок — направление потока критично.

Initial / Final отсутствуют. Любая activity должна иметь явный старт и конец, иначе чтение становится неоднозначным.

Связанные темы

• UML Use Case на собесе SA
• UML Sequence на собесе SA
• UML и BPMN на собесе SA
• User Stories и Acceptance Criteria для SA
• Подготовка к собесу системного аналитика

FAQ

Activity vs flowchart?

Activity — UML-стандарт с чёткой семантикой (fork, join, swimlanes). Flowchart — более старая нотация без формальных правил для параллелизма. Activity — практически современный flowchart с строгими правилами.

Можно ли вкладывать activity?

Да, через subactivity (action со специальным символом — небольшой rectangle inside). Декомпозиция бизнес-процесса.

Что такое exception в activity?

UML 2.5 поддерживает interruptible activity region и exception handler — ловят сигналы прерывания и направляют поток в обработчик.

Activity для технических флоу подходит?

Да. Но если речь о взаимодействии объектов с временной осью — лучше sequence diagram.

Как ставится time constraint?

Через note или constraint-блок: {duration ≤ 5s} рядом с переходом или actions.

Это официальная информация?

Нет. Статья основана на спецификации UML 2.5 (OMG) и стандартных практиках моделирования.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.