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

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

Sequence diagram — основной инструмент для описания межсистемных взаимодействий. На собесе SA это второй по частоте после use case: «нарисуй sequence интеграции с банком», «как показать асинхронный вызов», «когда alt, а когда opt». Без понимания невозможно описывать API и интеграции в ТЗ.

Главная боль без понимания — SA рисует «sequence», в котором стрелки идут не туда, alt-фрагменты висят без условия, retry не показан — разработчик не понимает что делать.

Элементы диаграммы

Lifeline (линия жизни) — вертикальная пунктирная линия для каждого участника (актёр, система, объект). Сверху — заголовок: имя или класс.

Activation bar — узкий прямоугольник на lifeline, показывающий период «активного» исполнения.

Сообщения — горизонтальные стрелки между lifeline'ами.

Combined fragments — прямоугольники для условных конструкций (alt, opt, loop, par и т.д.).

[Customer]   [WebApp]   [PaymentService]   [Bank]
    |          |              |              |
    |─login──▶│              |              |
    |          |              |              |
    |─pay────▶│              |              |
    |          │─authorize──▶│              |
    |          |              │─charge─────▶│
    |          |              │◀──ok────────│
    |          │◀──success───│              |
    |◀──ack────│              |              |

Сообщения: sync, async, return

Synchronous (sync) — вызов и ожидание ответа. Стрелка с закрашенным треугольником.

A ─────▶ B    sync (A ждёт)

Пример: REST API вызов.

Asynchronous (async) — вызов без ожидания ответа. Стрелка с открытой стрелкой (часто тонкой).

A ────▷ B    async (A продолжает работу)

Пример: публикация в Kafka, message broker.

Return — возврат значения. Пунктирная стрелка с открытым окончанием.

A ◀ - - - B    return value

На практике: после sync-вызова автоматически подразумевается return, иногда явно показывают для значимых ответов.

Self-message — стрелка lifeline в саму себя. Внутренняя операция объекта.

A ──┐
    │  self-call
A ◀─┘

Combined fragments: alt, opt, loop, par

Combined fragment — рамка с заголовком (operator), внутри — кусок диаграммы.

alt (alternative). Несколько взаимоисключающих веток с условиями.

┌─[alt]──────────────────────────┐
│   [сумма < 1000]               │
│   A ─────▶ B (charge instant)  │
│   - - - - - - - - - - - - - - -│
│   [сумма >= 1000]              │
│   A ─────▶ B (request approval)│
└────────────────────────────────┘

opt (optional). Условный блок без альтернатив.

┌─[opt]──────────────────────────┐
│   [user.is_premium]            │
│   A ─────▶ B (apply discount)  │
└────────────────────────────────┘

loop. Повторение. Условие — в заголовке.

┌─[loop while items]─────────────┐
│   A ─────▶ B (process item)    │
└────────────────────────────────┘

par (parallel). Параллельные ветки.

┌─[par]──────────────────────────┐
│   A ─────▶ B (send email)      │
│   - - - - - - - - - - - - - - -│
│   A ─────▶ C (send sms)        │
└────────────────────────────────┘

break. Прерывание sequence (как exception).

critical. Атомарный блок (для concurrent сценариев).

ref. Ссылка на другую sequence diagram (переиспользование).

Создание и уничтожение объектов

Create. Стрелка с <<create>> к новому lifeline'у. Lifeline начинается в этой точке.

A ────<<create>>───▶ B (новый объект)

Destroy. Крестик на lifeline. Объект больше не существует.

В современных распределённых системах редко используется — мы не управляем жизненным циклом удалённых сервисов.

Сценарий: интеграция с банком

Типовой собес-вопрос: «нарисуй sequence для оплаты картой».

[Customer]  [WebApp]  [PaymentSvc]  [BankAPI]  [DB]
    │          │            │           │        │
    │─checkout▶│            │           │        │
    │          │─create────────────────────────▶│
    │          │◀──order_id────────────────────│
    │          │            │           │        │
    │─pay─────▶│            │           │        │
    │          │─authorize▶│            │        │
    │          │            │─charge───▶│        │
    │          │            │           │        │
    │  ┌───[alt]────────────────────────────────┐│
    │  │  [bank: success]                       ││
    │  │           │◀──ok──────│                ││
    │  │           │─update_status──────────▶│ ││
    │  │           │◀──ok───────────────────│ ││
    │  │  ─────────────────────────────────────││
    │  │  [bank: declined]                      ││
    │  │           │◀──error───│                ││
    │  │           │─update_status (fail)───▶│ ││
    │  └────────────────────────────────────────┘│
    │          │◀──result──│                     │
    │◀──page───│            │                    │

На собесе ожидают: чёткие lifelines, корректные sync/async, alt с двумя ветками (успех/ошибка), update в БД.

Когда sequence, а когда что-то другое

Sequence:

• Описать взаимодействие между объектами / сервисами с временной последовательностью.
• Раскрыть use case в шагах.
• Показать API-вызовы между микросервисами.

Activity diagram (UML):

• Бизнес-процесс с ветвлениями, swimlanes.
• Когда нужно показать workflow без объектов.

BPMN:

• Бизнес-процесс с участием людей и систем, особенно для регулируемых процессов.

Communication diagram (UML):

• Объектная связь без акцента на время. Редко используется на собесе.

State machine:

• Изменение состояния одного объекта.

Для интеграции с внешней системой — sequence. Для внутреннего бизнес-процесса — BPMN.

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

Не показывать activation bar. Активные периоды важны для понимания «кто сейчас держит управление».

Использовать sync, когда async. REST — sync. Kafka publish — async. Не путай — это меняет архитектуру.

Огромная sequence на 50 сообщений. Декомпозируй через ref-фрагменты на меньшие диаграммы.

Условия без [skobok]. Условия в alt/opt/loop пишутся в [квадратных скобках], иначе непонятно.

Скрытые ошибки. На собесе обязательно покажи alt-ветку для ошибки — иначе SA выглядит, как будто всегда happy path.

Перепутать lifeline и actor. Актёр — конкретный человек / роль. Lifeline — конкретный объект / экземпляр.

Не показать timeout / retry. В реальной интеграции это критично. Покажи через note или alt с условием «если timeout — retry с exponential backoff».

Слишком много self-messages. Они засоряют диаграмму. Если сервис делает много внутренних шагов — описывай как «обработка», а декомпозируй на отдельной диаграмме.

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

• UML Use Case на собесе SA
• UML и BPMN на собесе SA
• REST API на собесе SA
• Webhook polling SSE на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Чем sequence отличается от communication diagram?

Sequence показывает временную ось вертикально. Communication — те же объекты и сообщения, но без времени, фокус на связях. UML 2.x позволяет легко переключаться, но в РФ почти везде sequence.

Как показать timeout?

Через note рядом со стрелкой — «timeout 5s» — и alt-ветку для случая, когда таймаут истёк. Или сделать break-фрагмент.

Можно ли смешивать sync и async на одной диаграмме?

Да, и нужно. Реальные системы — гибрид. Главное — четко обозначать тип каждой стрелки.

Когда ref использовать?

Когда фрагмент диаграммы повторяется или слишком большой. Например, «обработка платежа» — отдельный sequence, который вызывается из нескольких высокоуровневых.

Как показать «не отвечает»?

Альтернатива — alt с веткой [no response]. Или break + note. Главное — явно показать ошибку.

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

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

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