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

Зачем нужна диаграмма состояний

Диаграмма состояний (state machine, statechart) описывает поведение одного объекта во времени: в каких состояниях он может находиться и по каким событиям переходит из одного в другое. Она незаменима, когда у сущности сложный жизненный цикл — заказ, заявка, платёж, пользователь, договор. Там, где обычным текстом требований легко упустить недопустимый переход, диаграмма делает все состояния и правила перехода явными.

Для системного аналитика это рабочий инструмент постановки задачи: по диаграмме разработчик видит, какие переходы разрешены, а какие должны блокироваться, а тестировщик — какие сценарии нужно проверить. На собесе SA проверяют, умеете ли вы формализовать жизненный цикл сущности: не «нарисовать красиво», а не потерять состояния, корректно расставить события и условия, показать обработку ошибочных путей.

Элементы

Диаграмма состоит из небольшого набора элементов, и на собесе просят их назвать и различать.

• Состояние (State). Ситуация, в которой находится объект в данный момент («Создан», «Оплачен», «Отгружен»). Рисуется прямоугольником со скруглёнными углами.
• Переход (Transition). Стрелка из одного состояния в другое. Срабатывает по событию и может иметь guard-условие и действие. Полная запись перехода: событие [guard] / действие.
• Событие (Event). То, что запускает переход: команда пользователя, сообщение от другой системы, истечение таймера.
• Guard-условие (Guard). Логическое условие в квадратных скобках, при котором переход разрешён. Например, [в течение grace-периода]: если условие ложно, переход не срабатывает.
• Действие (Action). Что выполняется при переходе — записать в лог, отправить уведомление (/log, /notify).

Пример жизненного цикла заказа в текстовой нотации:

[начальное состояние] → Создан
Создан      -- Оплатить                        --> Оплачен
Создан      -- Отменить [если не отгружен]       --> Отменён
Оплачен     -- Отгрузить                        --> Отгружен
Отгружен    -- Доставить                        --> Доставлен
Оплачен     -- Вернуть [если в grace-периоде]    --> Возврат

Здесь Оплатить, Отменить, Вернуть — события; [если не отгружен], [если в grace-периоде] — guard-условия. Один и тот же объект по одному событию может уйти в разные состояния в зависимости от guard — именно это отличает хорошую диаграмму от простого «списка статусов».

Псевдосостояния

Псевдосостояния — это служебные узлы, которые не являются «настоящими» состояниями объекта, а управляют потоком.

• Начальное (Initial). Закрашенный кружок. Точка входа: откуда объект стартует.
• Финальное (Final). Кружок в кольце (bullseye). Завершение жизненного цикла.
• Choice (выбор). Ромб. Ветвление по условию: один вход, несколько выходов с guard-условиями. Ветвь выбирается уже после выполнения предыдущего действия (динамически).
• Junction (соединение). Точка, объединяющая или разветвляющая несколько переходов статически, чтобы не плодить дублирующиеся стрелки.

Разницу между choice и junction любят уточнять на собесе: choice выбирает ветку по условию в момент прохода, junction — это просто «монтажный узел» для склейки переходов на этапе рисования.

Вложенные состояния

Когда состояний много, диаграмма превращается в паутину стрелок. Составное (composite) состояние решает это, вкладывая подсостояния внутрь одного родительского.

Заказ:
  Активен:
    Создан → Оплачен → Отгружен
  Закрыт:
    Доставлен / Отменён / Возврат

Главная выгода — переход от родительского состояния работает для всех вложенных сразу. Например, из любого подсостояния «Активен» объект может уйти в «Закрыт» по событию отмены — не нужно рисовать отдельную стрелку из каждого подсостояния. Это резко снижает визуальную сложность диаграммы и число дублирующихся переходов. На собесе умение свернуть плоскую «звезду» переходов во вложенную иерархию показывает зрелость в моделировании.

Где применяется

• Жизненный цикл заказа. E-commerce: создан, оплачен, отгружен, доставлен, отменён, возврат — классический пример, который чаще всего и просят нарисовать.
• Документооборот. Черновик, на согласовании, утверждён, опубликован, в архиве — с guard-условиями на права и полноту данных.
• Состояния заявки/аккаунта. Онбординг, активен, приостановлен, отток — полезно для продуктовой и биллинговой логики.
• Сетевое соединение. Устанавливается, установлено, простой, закрыто — типичный пример из технической области.
• Игровой персонаж. Ожидание, ходьба, бег, прыжок, атака — состояния поведения в геймдеве.

В коде такие диаграммы реализуют паттерном State или готовыми библиотеками (XState, Spring State Machine), но для SA важнее корректная модель, а не конкретная реализация.

Как это спрашивают на собесе

Типичные форматы вопроса:

• «Нарисуйте жизненный цикл заказа (заявки, платежа).» Здесь смотрят, назовёте ли начальное и финальное состояния, расставите ли события на переходах и не забудете ли ошибочные ветки (отмена, возврат, отказ оплаты).
• «Чем событие отличается от guard-условия?» Событие запускает переход, guard разрешает или запрещает его. Событие может прийти, но переход не состоится, если guard ложен.
• «Как показать, что отменить можно только неотгруженный заказ?» Guard-условием на переходе [если не отгружен], а не отдельным состоянием.
• «Чем диаграмма состояний отличается от диаграммы активностей?» State machine описывает состояния одного объекта и переходы между ними; activity — поток работ и последовательность действий процесса.

Интервьюер проверяет не аккуратность рисунка, а полноту модели: покрыты ли все допустимые состояния, обработаны ли ошибочные пути и явно ли заданы условия переходов.

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

Путать состояние и событие. «Оплата» — это событие (действие), а «Оплачен» — состояние (результат). На диаграмме в прямоугольниках должны быть состояния, на стрелках — события.

Забывать финальные и ошибочные состояния. Рисуют «счастливый путь» и упускают отмену, возврат, отказ. Интервьюер почти всегда спрашивает: «А что если оплата не прошла?»

Не показывать guard-условия. Если из одного состояния по одному событию возможны разные исходы, без guard диаграмма недетерминирована. Условие обязательно выносят в [...].

Плоская «звезда» переходов. Когда из каждого состояния идёт стрелка отмены в «Отменён», диаграмма превращается в кашу. Это сворачивают во вложенное состояние с одним общим переходом.

Смешивать несколько объектов на одной диаграмме. State machine описывает жизненный цикл одной сущности. Заказ и платёж — разные объекты; их моделируют отдельными диаграммами, а связь показывают событиями.

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

• UML Use Case для SA
• UML Activity для SA
• UML Sequence для SA
• Domain events для SA
• Подготовка к собесу системного аналитика

FAQ

Чем диаграмма состояний отличается от диаграммы активностей?

State machine описывает состояния одного объекта и переходы между ними по событиям — фокус на «в каком состоянии сущность». Activity-диаграмма описывает поток работ и последовательность действий процесса, часто с несколькими участниками. Первую берут для жизненного цикла сущности, вторую — для бизнес-процесса.

В чём разница между событием и guard-условием?

Событие запускает попытку перехода (пользователь нажал «Отменить»). Guard-условие в квадратных скобках определяет, разрешён ли переход при этом событии ([если не отгружен]). Если событие пришло, но guard ложен — переход не происходит, объект остаётся в прежнем состоянии.

Зачем нужны вложенные (composite) состояния?

Чтобы не дублировать одинаковые переходы. Если из группы состояний по одному событию идёт один и тот же переход (например, отмена из любого «активного» состояния), их сворачивают в одно составное состояние с общим переходом от родителя. Диаграмма становится компактнее и читаемее.

Что рисовать в прямоугольниках, а что на стрелках?

В прямоугольниках со скруглёнными углами — состояния (существительные-результаты: «Оплачен», «Отгружен»). На стрелках — переходы с подписью событие [guard] / действие. Частая ошибка новичков — писать в прямоугольниках действия вместо состояний.

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

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

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