Диаграмма состояний (State Machine Diagram) — поведенческая диаграмма UML, описывающая жизненный цикл одного бизнес-объекта: в каких состояниях он может находиться и по каким правилам переходит из одного в другое. Если 03.02.02 Диаграмма деятельности (Activity Diagram) и 03.02.03 Диаграмма последовательности (Sequence Diagram) показывают поток работ и обмен сообщениями «вширь», state machine фиксирует эволюцию одной сущности во времени. На проекте это главный инструмент для статусных моделей заказов, заявок, договоров — контракт между бизнесом, разработкой и тестированием.

1. Суть темы

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

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

Не путать с 02.05.05 Жизненный цикл требования: там моделируют статусы артефакта требования (Draft → Approved → Baseline); здесь — runtime-состояние бизнес-объекта в системе (заказ, тикет, платёж). Нотация одна, предмет моделирования разный.

Когда state machine, а когда другая нотация:

ВопросНотацияПример
Меняется статус одной сущности?State MachineЗаказ: Новый → Оплачен → Доставлен
Описывается последовательность шагов сценария?03.02.02 Диаграмма деятельности (Activity Diagram)Оформление заказа: проверка → оплата → уведомление
Важен обмен сообщениями между компонентами?03.02.03 Диаграмма последовательности (Sequence Diagram)POST /pay → callback платёжного шлюза
Сквозной бизнес-процесс с ролями, SLA, BPMS?03.04.01 BPMN 2.0 - введение и основыСогласование заявки в Camunda

State machine vs BPMN / workflow-движок: автомат одной сущности (поле status записи в сервисе) держите на state diagram. Сквозной процесс с несколькими исполнителями, human task и оркестрацией шагов — в BPMN или движке процессов (03.04.01 BPMN 2.0 - введение и основы). Типичный вопрос «статусы заявки в Camunda или в сервисе?»: если меняется только статус одной записи и правила локальны — FSM в сервисе; если процесс координирует людей и систем через пул/дорожки — BPMN.

Полная палитра элементов UML 2.5 — в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case); здесь — применение и артефакты требований. Оставьте в справочнике UML (не дублируйте здесь): defer, join/fork на state diagram, типы сигналов и call event, interruptible region, детали junction vs choice в нотации.

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

Состояния

ЭлементСмысл для SA
Простое состояние (Simple State)Именованный режим объекта: Новый, Оплачен, Доставлен. Имя — существительное или прилагательное, не глагол
Начальное псевдосостояние (Initial)Точка входа в регион. У каждого региона (вложенного и ортогонального) — своё начальное состояние
Конечное состояние (Final)Завершение жизненного цикла в этом регионе. Для объекта «снят с учёта»; запись в БД может оставаться — отдельное решение (03.03.02 Логическая и физическая модель данных)
Составное состояние (Composite State)Состояние с вложенной диаграммой; упрощает главный уровень
Параллельные регионы (Orthogonal Regions)Несколько независимых осей поведения внутри одного объекта, активных одновременно
Состояние-история (History, H*)При повторном входе в composite восстанавливает последнее подсостояние, а не initial

Переходы

Переход записывается в формате:

событие [сторожевое условие] / действие

  • Событие (Event) — внешний стимул: вызов операции, сигнал, истечение таймера (after(30 min)).
  • Сторожевое условие (Guard) — [сумма > 0], [платёж успешен], [роль = support_admin].
  • Действие (Action) — реакция системы на переходе: / списать средства.

Self-transition (переход в себя) — событие обрабатывается, но состояние не меняется: продление таймера, повторная отправка напоминания, идемпотентный повтор оплатить. На диаграмме — стрелка из состояния в себя; в API это не 409, а 200/204 без смены status. Не путать с «перехода нет» — self-transition явно разрешён и описан.

Choice (псевдосостояние выбора) — разветвление внутри composite по guard без отдельного «состояния ожидания»: после входа в Отменен choice направляет либо в «снятие резерва», либо в «инициацию возврата» — в зависимости от [оплата была]. Junction — точка слияния/разветвления без семантики выбора. Детали нотации — 06.01.02 Поведенческие диаграммы (State, Activity, Use Case); для SA важно: разные бизнес-пути не рисуйте одной линией — используйте choice или отдельные composite.

Автоматический переход (completion transition) — без явного события на стрелке; в UML срабатывает при завершении вложенного поведения (activity) внутри состояния, когда внутренний регион достигает final ([*]). В аналитических моделях completion часто дублируют явным событием в спецификации — так проще трассировать в API и тестах (см. пример заказа ниже).

Change event when(условие) — переход при изменении условия. В реализации непрерывный опрос дорог; предпочитайте явные domain events («баланс исчерпан») — стык с 03.05.06 Event-Driven Architecture.

Переходы override / compensating — принудительная смена статуса вне обычного потока: support, регулятор, аварийная отмена. Фиксируйте отдельно: событие, guard [роль ∈ {support_admin, compliance}], аудит, возможная компенсация. Не прячьте их в «скрытые кнопки» без модели.

Внутренние действия и инварианты состояния

Внутри прямоугольника состояния:

  • entry / действие — при входе;
  • do / действие — пока объект в состоянии;
  • exit / действие — при выходе;
  • инвариант — что всегда истинно, пока объект в этом состоянии (отдельная строка в спецификации или примечание к состоянию).

Пример для «Ожидание оплаты»:

entry / запустить таймер 30 мин
do / ожидать callback платёжного шлюза
exit / остановить таймер
инвариант: резерв товаров активен

Инварианты сверяют со 03.03.03 Словарь данных (описание) и negative-тестами («в ОжидаетОплаты резерв не может быть снят без перехода»). Таймаут и SLA согласуют с 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

Кто инициирует событие

На диаграмме актор не обязателен, но в спецификации фиксируйте источник: покупатель (актор прецедента — 03.02.01 Диаграмма прецедентов (Use Case Diagram)), оператор, шедулер, внешняя система (03.01.04 Интерфейсы и интеграционные взаимодействия). Callback платёжного шлюза — событие от внешней системы, не «магия» перехода. Распределение ролей — 10.01.11 Шаблон ролевой модели или дорожки на Activity Diagram.

Пример: жизненный цикл заказа (линейная модель)

Для заказа платёж предшествует сборке, сборка — доставке. Одна линейная диаграмма:

stateDiagram-v2
    [*] --> Новый
    Новый --> Подтвержден : подтвердить [все товары в наличии]
    Новый --> Отменен : отменить
    Подтвержден --> ОжидаетОплаты : выставить_счет
    ОжидаетОплаты --> ОжидаетОплаты : продлить_таймер [роль=оператор]
    ОжидаетОплаты --> Оплачен : оплатить [платеж успешен]
    ОжидаетОплаты --> Отменен : after(30 min)
    ОжидаетОплаты --> Отменен : отменить_покупателем
    Оплачен --> Собирается : начать_сборку
    Собирается --> ГотовКОтгрузке : сборка_завершена
    ГотовКОтгрузке --> Доставлен : доставить
    Доставлен --> [*]

    state Отменен {
        [*] --> СнятиеРезерва
        СнятиеРезерва --> [*] : резерв_снят
    }

    state Собирается {
        [*] --> РезервированиеТоваров
        РезервированиеТоваров --> Комплектация : товары_зарезервированы
        Комплектация --> Упаковка : укомплектован
        Упаковка --> [*]
    }

Зафиксированные бизнес-правила модели:

  • Отмена возможна только из Новый и ОжидаетОплаты. Из Оплачен перехода в Отменен нет — осознанное ограничение.
  • Составное Отменен — только снятие резерва до оплаты. Возврат после оплаты — отдельный жизненный цикл или BPMN-процесс; в одном composite смешивать пути «отмена» и «возврат» без choice нельзя (06.01.02 Поведенческие диаграммы (State, Activity, Use Case)).
  • Сборка не начинается без оплаты; доставка — только после сборка_завершена.
  • Completion vs явное событие: внутри Собирается переход Упаковка → [*] — completion вложенного региона (UML). На верхнем уровне тот же факт трассируем как явное событие сборка_завершена → API POST .../complete-packing, тест «после упаковки статус ГотовКОтгрузке». В споре с разработкой фиксируйте в SRS: «completion региона = событие X».

Запрещённые и привилегированные переходы (отсутствие стрелки недостаточно):

ИзВДопустимоПоведение системы
ОплаченОтмененНетAPI: HTTP 409; UI: кнопка скрыта; тест: negative
ДоставленОжидаетОплатыНетОшибка валидации статуса
НовыйОплаченНетСначала подтверждение и счёт
ЛюбойПроизвольныйТолько supportforce_status [роль=support_admin] + аудит; вне UI покупателя

Таблицу включают в 02.03.03 Спецификация требований (SRS, Use Case, User Story), 10.01.15 Шаблон матрицы трассировки и 02.03.04 Трассировка требований (концепция) (переход ↔ FR ↔ тест-кейс).

History state: reopen тикета

Когда объект повторно открывают и нужно вернуть не в initial, а в последний рабочий подстатус — shallow history (H*):

stateDiagram-v2
    [*] --> Новый
    Новый --> ВРаботе : взять_в_работу
    state ВРаботе {
        [*] --> Анализ
        Анализ --> Разработка : передать
        Разработка --> Тестирование : готово_к_тесту
    }
    ВРаботе --> Закрыт : закрыть
    Закрыт --> ВРаботе : reopen

Требование к reopen: при reopen система восстанавливает последнее подсостояние (Тестирование, если тикет закрыли оттуда), а не всегда Анализ. В UML это H* на границе composite; в спецификации — явное правило + поле «последний подстатус» или enum. Тест: закрыть из Тестирование → reopen → снова Тестирование.

Параллельные регионы — другой домен, не «заказ с доставкой до оплаты»

Ортогональные регионы — когда оси независимы и могут меняться в разном порядке. У заказа из примера выше оси последовательны — линейная модель. Для parallel regions типичнее тикет поддержки: ось «работа» и ось «SLA» не блокируют друг друга:

stateDiagram-v2
    state Тикет {
        state "Работа" as work {
            [*] --> Новый
            Новый --> ВРаботе : взять
            ВРаботе --> Решён : решить
            Решён --> Закрыт : закрыть
        }
        --
        state "SLA" as sla {
            [*] --> ВНорме
            ВНорме --> Предупреждение : after(4 h)
            Предупреждение --> Просрочен : after(8 h)
        }
    }

Правило выбора: линейная диаграмма — оси последовательны (оплата → сборка → доставка). Orthogonal regions — оси независимы (статус решения и эскалация SLA). Если между регионами есть жёсткая зависимость («отгрузка только после оплаты») — это guard или верхний уровень, а не два свободных региона «Платёж» и «Доставка».

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

На этапе выявления требований

  • Перечислите статусы на стикерах, соедините переходами — быстрее выявить «а можно ли отменить после оплаты?» (02.02.02 Воркшопы, фасилитация и совместные сессии).
  • Одна диаграмма — одна сущность (агрегат DDD — 03.06.02 Основы Domain-Driven Design). «Заказ» ≠ «позиция заказа».
  • Для 3–5 состояний без иерархии достаточно таблицы переходов; диаграмма нужна при composite, history, parallel regions, choice или сложных guard.

Связь с артефактами

АртефактСвязь
03.02.01 Диаграмма прецедентов (Use Case Diagram)Прецедент «Оплатить заказ» → переход ОжидаетОплаты → Оплачен; актор UC = инициатор события
10.01.02 Шаблон Use CasePrecondition UC = начальное(ые) состояние(я); postcondition = целевой статус после перехода
03.02.02 Диаграмма деятельности (Activity Diagram)Шаги сценария, меняющие статус; дорожки ролей
03.02.03 Диаграмма последовательности (Sequence Diagram)Сообщения, вызывающие события перехода
03.01.04 Интерфейсы и интеграционные взаимодействияCallback внешней системы как источник события
03.03.03 Словарь данных (описание)Поле status, enum, инварианты
03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)Enum статусов, команды перехода
03.05.02 Синхронные протоколы (REST, gRPC, GraphQL)POST /orders/{id}/pay как команда перехода
02.03.04 Трассировка требований (концепция)Переход ↔ FR ↔ тест в матрице
04.02 Пользовательские истории (User Stories) и Job StoriesAC по допустимым переходам из текущего статуса

Event Storming → state machine: доменные события («OrderPaid») — триггеры переходов; агрегат и инварианты — 03.06.02 Основы Domain-Driven Design; доставка событий — 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events), 03.05.06 Event-Driven Architecture. Одна точка входа, детали транспорта — в смежных статьях.

Проектирование API и UI

  • Каждый переход — кандидат на команду API; состояние — значение enum (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)).
  • UI: кнопки привязаны к текущему состоянию; override — только для ролей из guard.
  • Идемпотентность: повтор оплатить при уже Оплачен — self-transition или no-op (200/204).
  • Конкурентность: два события почти одновременно (оплата + отмена, двойной callback) — зафиксируйте политику: optimistic lock / поле version, «первый выигрывает», второй — 409 Conflict. Идемпотентность не заменяет модель гонок: ключ идемпотентности dedupe повтор того же запроса, а не конкурирующие разные события. Согласуйте с 03.06.01 Архитектурные паттерны распределённых систем.

Тестирование и рецензия модели

Тест-план по диаграмме: все достижимые переходы, запрещённые (negative), таймауты, guard, history, override, конфликт двух событий. Статическая рецензия модели до кода — 08.04 Рецензирование и инспекции (техники Фейгана); V&V процесса — 02.04.01 Верификация и валидация (V&V).

Передача разработчикам

Диаграмма — контракт для паттерна State / enum + guard в коде. Редакторы и синтаксис — 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io); что класть в SRS по state modelling — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

При нетривиальной модели (10+ состояний, таймауты, parallel regions) согласованная state machine снижает дефекты «неверный статус»; для простого CRUD таблица переходов может быть достаточнее.

Современный контекст (кратко)

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

Ошибки:

  • CRUD-as-state: «Создание», «Редактирование» — действия, не статусы.
  • Activity вместо state: цепочка шагов без устойчивых состояний — 03.02.02 Диаграмма деятельности (Activity Diagram) или 03.04.01 BPMN 2.0 - введение и основы.
  • Orthogonal regions для зависимых осей: «доставка» параллельно «оплате» там, где оплата обязательна раньше — линейная модель или guard на верхнем уровне.
  • Раздутая диаграмма без composite — десятки состояний на одном листе.
  • Смешение отмены/возврата в одном composite без choice.
  • Пропуск запрещённых переходов — нужна таблица + поведение (409, скрытая кнопка, override только для роли X).
  • Completion без явного события в SRS — спор с разработкой и тестами на «что триггерит выход из composite».
  • Игнор гонок — два события, один объект, нет политики version/lock.
  • when() без domain event — нереализуемое требование.
  • Несогласованность enum в БД, API и диаграмме — 03.03.02 Логическая и физическая модель данных, 03.05.07 Управление версионированием API и жизненным циклом.

Ограничения:

  • Для простых CRUD (3–4 статуса) Agile-команды часто обходятся таблицей — допустимо, если правила общие.
  • Конечное состояние завершает жизненный цикл в модели; архив записи — отдельное решение.
  • Несколько акторов на одной сущности — явный инициатор события в спецификации.

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

Читать по цепочке артефактов, а не списком «всё подряд»:

1. Выявление и границы

2. Моделирование и смежные диаграммы

3. Спецификация и трассировка

4. Данные, API, интеграции

5. Качество и приёмка

Не путать с жизненным циклом требования: 02.05.05 Жизненный цикл требования — другой предмет моделирования.

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

Стандарты (фокус SA — что класть в спецификацию)

Книги

  • Мартин Фаулер. «UML. Основы». 3-е изд. — СПб.: Символ-Плюс, 2005. (глава о state diagrams в контексте моделирования поведения)
  • Leslie Lamport. Specifying Systems — формальная спецификация state machine (TLA+); для SA — ориентир при высоком риске, не ежедневный артефакт.

Практика моделирования и реализации

Оркестрация vs entity lifecycle (не подмена FSM сущности)