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

Зачем нотации

Нотации — это язык, на котором СА разговаривает с разработчиками, архитекторами и бизнесом. Текст не передаёт связи между сущностями и порядок шагов так же чётко, как диаграмма.

На собесе СА проверяют не «знаете ли все диаграммы UML», а «умеете ли выбрать правильную нотацию для задачи». Базовый минимум — sequence, activity, class, ERD, BPMN.

UML behavior-диаграммы

Sequence diagram

Показывает взаимодействие между объектами/сервисами во времени. Используется для:

• Описания API-сценариев (клиент → backend → БД → внешний сервис)
• Визуализации интеграций
• Протокола между микросервисами

Главные элементы: lifeline (вертикальная линия объекта), activation (вытянутый прямоугольник на lifeline), сообщения (стрелки).

На собесе попросят: «Нарисуй sequence для оплаты картой». Ответ должен включать клиента, frontend, backend, payment provider, БД.

Activity diagram

Бизнес-процесс или алгоритм. В отличие от sequence не привязан к объектам — фокус на потоке управления.

Используется для: описания шагов процесса, decision points, параллельных веток.

Активити похож на BPMN, но проще. На практике BPMN чаще, потому что специально создан под бизнес-процессы.

State diagram

Жизненный цикл сущности: какие состояния, переходы между ними, события.

Пример: заказ может быть в состоянии created → paid → shipped → delivered → completed. Возможные переходы — стрелки с триггерами.

На собесе спрашивают про state diagram редко, но в банках и финтехе часто.

UML structure-диаграммы

Class diagram

Структура объектной модели: классы, поля, методы, связи (inheritance, aggregation, composition).

Используется СА для:

• Документирования domain model
• Спорной точки между разработчиками: «как выглядит User, заказ, инвойс»

Главные связи:

• Association — обычная связь (User имеет Orders)
• Aggregation — слабая владение (Department содержит Employees, но Employee может существовать без Department)
• Composition — сильное владение (Order содержит OrderItems, без Order их нет)
• Inheritance — наследование

Component diagram

Архитектурные компоненты системы и их зависимости. На собесе обычно заменяется C4 Model уровня Context/Container.

Deployment diagram

Где что запускается: серверы, контейнеры, процессы. Редко спрашивают на собесе СА.

BPMN 2.0

BPMN — Business Process Model and Notation. Стандарт для описания бизнес-процессов.

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

• Pool — границы участника процесса (например, банк)
• Lane — роль внутри pool (например, оператор, кассир)
• Task — шаг процесса (rectangle)
• Gateway — точка решения (ромб)
• Event — начало/конец/промежуточное событие (круг)
• Sequence flow — стрелка между шагами

Типы Gateway:

• Exclusive (XOR) — выбирается один путь
• Parallel (AND) — выполняются все пути одновременно
• Inclusive (OR) — выполняются одновременно подходящие условиям пути

На собесе попросят: «Опиши BPMN для процесса возврата товара в маркетплейсе». Ответ — нарисовать pool «маркетплейс» с lanes (клиент, продавец, поддержка), tasks (создал заявку → проверена продавцом → одобрена → возврат денег), gateways (заявка валидна?).

ERD: связи и кардинальность

ERD (Entity-Relationship Diagram) — описание данных. Сущности, их атрибуты, связи.

Связи

• 1:1 — у каждого юзера один профиль
• 1:N — у одного клиента много заказов
• N:N — студенты записаны на курсы (через промежуточную таблицу)

Кардинальность в Crow's Foot

• Одна линия — обязательно
• Двойная линия — необязательно (zero or one)
• «Ножки» — many

Например: Customer || ━━ {< Order означает «один Customer имеет ноль или больше Orders, у каждого Order ровно один Customer».

Нормализация

• 1NF — атомарные значения, нет повторяющихся групп
• 2NF — 1NF + нет частичных зависимостей от составного ключа
• 3NF — 2NF + нет транзитивных зависимостей
• BCNF — 3NF + каждая зависимость идёт от суперключа

На собесе спрашивают редко глубже 3NF. Главное — уметь объяснить, зачем нормализация и когда нужна денормализация (для скорости чтения).

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

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

Использовать UML где нужен BPMN. Activity-диаграмма для бизнес-процесса работает хуже BPMN. BPMN специально для процессов.

Слишком детальный sequence. На один сценарий — одна диаграмма. 50 стрелок на одной странице — это нечитаемо.

Игнорировать кардинальность в ERD. «Customer связан с Order» — недостаточно. Нужно указать 1:N с обязательностью.

Слишком много pool в BPMN. Pool — это участник вне нашей системы. Внутренние роли — lanes внутри одного pool.

Не использовать стандартные обозначения. Если рисуете «свои» иконки — никто не поймёт. Используйте стандартные элементы.

FAQ

Какой инструмент использовать на собесе?

Live-coding обычно — draw.io / Miro / Lucidchart. Дома — что угодно. Главное — стандартные обозначения, не свои.

Сколько UML-диаграмм нужно знать?

Sequence + activity + class + state — 80% задач. ERD и BPMN отдельно. Component, deployment, communication — реже.

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

Нет. Статья основана на стандартах OMG (UML, BPMN) и опыте кандидатов.