Конечный автомат (state machine) — это способ описать жизненный цикл одной сущности через её состояния и переходы между ними по событиям. Заказ бывает «создан», «оплачен», «собран», «отгружён», «доставлен», «отменён» — это состояния; «клиент оплатил», «склад собрал» — события, которые двигают заказ из одного состояния в другое. Главная ценность для аналитика: автомат заставляет явно сказать, какие переходы разрешены, а какие запрещены (нельзя отгрузить неоплаченный заказ). От BPMN отличается фокусом: BPMN — про процесс и роли (кто что делает), state machine — про то, что происходит с одной сущностью. Артефакт аналитика — таблица переходов: строки-состояния, столбцы-события, в ячейках — куда переходим или «запрещено».
Однажды я сдал спеку на заказы, где аккуратно описал счастливый путь: создан → оплачен → собран → отгружён → доставлен. Через неделю тестировщик пришёл с вопросом: «А можно отменить заказ, который уже доставлен? У меня кнопка „Отмена“ висит на всех статусах». Я открыл рот и закрыл. В моей спеке не было ни слова про то, из каких состояний отмена разрешена, а из каких нет. Разработчик сделал кнопку везде — и теперь можно было «отменить» товар, который клиент держит в руках. Дыра была не в коде. Дыра была в том, что я описал, куда заказ может идти, и забыл описать, куда он идти не должен.
С тех пор любую сущность со статусами я описываю автоматом. Это дёшево — полчаса работы — и закрывает целый класс багов «а что если из этого состояния сделать вот это». Запрещённые переходы важнее разрешённых: разрешённые разработчик и сам угадает, а вот про запрет он не узнает, если вы его не написали.
Что такое конечный автомат простыми словами
Конечный автомат — это всего две вещи: набор состояний, в которых может находиться сущность, и набор переходов между ними. Сущность всегда находится ровно в одном состоянии. Перейти в другое она может только по событию и только если такой переход разрешён.
Самый бытовой пример — светофор. Состояния: красный, жёлтый, зелёный. Переходы по событию «таймер истёк»: красный → жёлтый → зелёный → жёлтый → красный. Светофор не может прыгнуть с красного сразу на зелёный, минуя жёлтый, — этот переход не определён. Вот и весь автомат: состояния, события, разрешённые переходы. Всё остальное — детали.
Ключевое слово — «конечный»: состояний конечное, перечислимое число. Вы можете их все выписать в столбик. Если состояний «бесконечно много» или «зависит от текста» — это не автомат, и инструмент не подходит.
Зачем это аналитику: жизненный цикл заказа
Возьмём заказ в интернет-магазине. У него есть жизнь: он рождается, что-то с ним происходит, он умирает (доставлен или отменён). Опишем эту жизнь как автомат.
Состояния заказа: создан, оплачен, собран, отгружён, доставлен, отменён. События, которые его двигают: клиент оплатил, склад собрал, курьер забрал, курьер довёз, кто-то отменил.
Теперь главный вопрос, на который автомат заставляет ответить: из каких состояний что разрешено? Оплатить можно только созданный заказ. Собрать — только оплаченный (нельзя собирать то, за что не заплатили). Отменить можно созданный, оплаченный и собранный — а вот отгружённый и доставленный отменять уже нельзя, для них есть отдельный процесс возврата. Доставленный заказ — это финал, из него никуда нельзя. Эти «нельзя» и есть та половина требований, которую вечно забывают.
Диаграмма состояний заказа
stateDiagram-v2 [*] --> Создан Создан --> Оплачен : оплата прошла Создан --> Отменён : отмена Оплачен --> Собран : склад собрал Оплачен --> Отменён : отмена Собран --> Отгружён : курьер забрал Собран --> Отменён : отмена Отгружён --> Доставлен : курьер довёз Доставлен --> [*] Отменён --> [*]
Схема выше — жизненный цикл заказа в виде диаграммы состояний. Чёрная точка слева — точка входа: заказ рождается в состоянии «Создан». Стрелки — это разрешённые переходы, и на каждой подписано событие, которое его запускает. Из «Создан» можно уйти в «Оплачен» (оплата прошла) или в «Отменён». Из «Оплачен» — в «Собран» или «Отменён». Из «Собран» — в «Отгружён» или «Отменён». А вот из «Отгружён» отмены уже нет: единственный путь — в «Доставлен». «Доставлен» и «Отменён» ведут в чёрную точку-финал: это конечные состояния, из них переходов нет. Самое важное на этой схеме — то, чего на ней нет: нет стрелки из «Доставлен» в «Отменён», нет стрелки из «Создан» сразу в «Отгружён». Отсутствие стрелки — это и есть запрет.
Таблица переходов — артефакт аналитика
Диаграмма наглядна, но плохо проверяется на полноту: глазом легко не заметить, что вы забыли описать какое-то событие в каком-то состоянии. Поэтому рядом с диаграммой я всегда делаю таблицу переходов (state transition table): строки — состояния, столбцы — события, в ячейке — куда переходим или «запрещено».
| Состояние Событие | оплатить | собрать | отгрузить | доставить | отменить |
|---|---|---|---|---|---|
| Создан | → Оплачен | запрещено | запрещено | запрещено | → Отменён |
| Оплачен | запрещено | → Собран | запрещено | запрещено | → Отменён |
| Собран | запрещено | запрещено | → Отгружён | запрещено | → Отменён |
| Отгружён | запрещено | запрещено | запрещено | → Доставлен | запрещено |
| Доставлен | запрещено | запрещено | запрещено | запрещено | запрещено |
| Отменён | запрещено | запрещено | запрещено | запрещено | запрещено |
Видите силу таблицы? Каждая ячейка — это явное решение. Нет ни одной незаполненной клетки, а значит, нет ни одного «а что если». Это та самая ситуация с кнопкой «Отмена»: в таблице сразу видно, что в строках «Отгружён», «Доставлен», «Отменён» столбец «отменить» — это «запрещено». Разработчик читает таблицу и не вешает кнопку там, где нельзя. Тестировщик читает ту же таблицу и пишет негативные тесты: «попробовать отменить доставленный — должно отлететь».
Запрещённые переходы и тупики — вот где баги
Две классические ошибки, и обе про то, чего на схеме нет. Первая — забыть запрещённые переходы: описать только счастливый путь, а про «нельзя» промолчать (моя история с кнопкой). Вторая — тупик (dead-end): состояние, из которого нет ни одного выхода, хотя по бизнесу выход должен быть. Например, заказ «завис на оплате» и из него нет пути ни в «оплачен», ни в «отменён» — клиент застрял навсегда. Проверяйте каждое состояние: можно ли в него попасть и можно ли из него выйти? Конечные состояния (доставлен, отменён) — выхода не имеют намеренно, и это нормально; а вот рабочее состояние без выхода — это баг.
Чем отличается от BPMN
Тут постоянная путаница, поэтому разведём чётко. И BPMN, и диаграмма состояний рисуют квадратики со стрелками — но отвечают на разные вопросы.
BPMN — про процесс: кто что делает, в каком порядке, в каких ролях, где развилки. На дорожках BPMN сидят разные участники — менеджер, склад, платёжный сервис, — и видно, кто за какой шаг отвечает. BPMN отвечает на «как идёт работа».
Диаграмма состояний — про одну сущность: что происходит с заказом, в каких он бывает состояниях и какие переходы разрешены. Тут нет ролей и нет «кто делает» — есть только сам заказ и его жизнь. Отвечает на «что происходит с этим объектом».
Грубое правило: если в центре внимания работа и люди — берите BPMN; если в центре один объект и его статусы — берите state machine. Часто они дополняют друг друга: BPMN-процесс «обработка заказа» меняет состояние сущности «заказ», и обе диаграммы описывают одно и то же с разных сторон. Какую нотацию когда выбирать в целом — в записи BPMN, UML и C4.
| BPMN | Диаграмма состояний | |
|---|---|---|
| В центре | Процесс и роли | Одна сущность |
| Отвечает на | Кто что делает и в каком порядке | В каких состояниях бывает и какие переходы разрешены |
| Есть роли/дорожки | Да | Нет |
| Типичный объект | Заявка проходит через отделы | Заказ: создан → оплачен → … |
Откуда это взялось
Конечные автоматы пришли из теории автоматов — раздела математики, который оформился в 1950-х. Два классических типа назвали по фамилиям инженеров: автомат Мура (Эдвард Мур, 1956) — где выход зависит только от текущего состояния, и автомат Мили (Джордж Мили, 1955) — где выход зависит от состояния и входного сигнала. Изначально это была математика для проектирования цифровых схем и компиляторов. В программную инженерию автоматы пришли через UML state diagram (диаграмма состояний UML, 1990-е), которая добавила вложенные состояния и условия. Аналитику глубокая теория не нужна — нужна сама идея «состояния плюс разрешённые переходы», и ей семьдесят лет.
Как это спрашивают на собесе
«Когда бы вы использовали диаграмму состояний вместо BPMN?» — отвечайте через фокус: state machine, когда описываете жизненный цикл одной сущности со статусами (заказ, заявка, тикет); BPMN, когда описываете процесс с ролями и шагами. Частый практический вопрос: «Как вы описываете статусную модель заказа?» — рисуйте состояния, переходы по событиям и обязательно проговорите запрещённые переходы и таблицу переходов. Подвох, на котором валятся джуны: «А отменить можно из любого статуса?» — правильный ответ «нет, и это надо явно прописать»; покажите, что вы думаете про запреты и тупики, а не только про счастливый путь.
Частые вопросы
Что такое конечный автомат простыми словами?
Это описание сущности через её состояния и переходы между ними по событиям. Сущность всегда находится ровно в одном состоянии, а перейти в другое может только по событию и только если такой переход разрешён. Пример — светофор: состояния красный/жёлтый/зелёный, переходы по таймеру, и нельзя прыгнуть с красного сразу на зелёный. Для аналитика это способ описать жизненный цикл заказа, заявки, тикета.
Чем диаграмма состояний отличается от BPMN?
BPMN описывает процесс: кто что делает, в каком порядке, в каких ролях (на дорожках сидят разные участники). Диаграмма состояний описывает одну сущность: в каких состояниях она бывает и какие переходы между ними разрешены, без ролей и без «кто делает». Правило: процесс и люди — BPMN; один объект и его статусы — state machine. Часто они дополняют друг друга, описывая одно с разных сторон.
Зачем нужна таблица переходов, если есть диаграмма?
Диаграмма наглядна, но глазом легко не заметить пропущенный случай. Таблица переходов (строки — состояния, столбцы — события, в ячейках — куда переходим или «запрещено») заставляет заполнить каждую клетку, то есть принять явное решение по каждой паре «состояние + событие». Так не остаётся необработанных «а что если», и тестировщик сразу видит, какие негативные сценарии проверять (например, отмена доставленного заказа).