Техники Руководство BABOK v3, 10.44
Моделирование состояний
Коротко Модель состояний показывает, какие статусы бывают у сущности за её жизнь — от создания до удаления — и какие события переводят её из одного статуса в другой. Расплывчатое поле «статус» превращается в явные правила, которые разработчики могут реализовать, а тестировщики — проверить.
По материалам: IIBA, Руководство BABOK® v3, техника 10.44 «Моделирование состояний»; Watermark Learning, BABOK v3 Study Tables (2016); Ю. А. Маглинец, «Анализ требований к информационным системам», лекция 5.
На этой странице
Что это#
Руководство BABOK® применяет моделирование состояний (state modelling), чтобы показать состояния (статусы), через которые сущность или класс проходит за свой жизненный цикл, события или триггеры, вызывающие изменение, и сами переходы. Элементы техники:
- Состояние — устойчивое положение, в котором сущность ведёт себя определённым образом, например «Ждёт запчасть». Называйте его как положение дел, а не как действие.
- Переход между состояниями — смена одного состояния другим. Его вызывает событие, и иногда он разрешён только при выполнении условия.
- Диаграмма состояний — изображение модели. Состояния — прямоугольники со скруглёнными углами, переходы — стрелки, закрашенная точка отмечает начало, точка в кольце — конец.
- Таблица состояний — то же содержание в виде сетки «текущее состояние — событие — следующее состояние». Таблица удобнее для проверки полноты, диаграмма — для обсуждения.
В конспекте лекций Маглинца приведена запись перехода в UML: Событие [сторожевое условие] / действие. Событие запускает переход, сторожевое условие должно быть истинным, чтобы переход произошёл, а действие система выполняет по ходу перехода. Маглинец советует строить диаграммы состояний, когда систему нужно понять как конечный автомат, поведение которого выходит за рамки одного варианта использования.
Когда применять#
Применяйте технику, когда:
- у сущности есть статус, от которого зависит, что люди и системы могут с ней делать: заказы, заявки, обращения, счета, договоры, ремонтные заказы;
- одну и ту же сущность меняют несколько вариантов использования или процессов, и нужен единый согласованный взгляд (задача BABOK 7.1 «Спецификация и моделирование требований»);
- вы подозреваете скрытые бизнес-правила. Модель состояний хорошо вскрывает правила, атрибуты (даты, причины) и действия, разрешённые в каждом состоянии;
- поведение нужно объяснить яснее, чем это получается текстом.
Выберите другую технику, когда:
- сущность простая и у неё два-три очевидных состояния — хватит одного предложения. Руководство BABOK отмечает, что техника обычно окупается только для сложных сущностей;
- нужно показать, кто что делает на протяжении всей работы, — используйте моделирование процесса;
- нужен порядок сообщений между участниками — используйте диаграммы последовательности.
Заложите время. Чтобы заинтересованные стороны договорились об определениях состояний, нужны усилия, а уровень детализации может кого-то смутить. Помогает заранее согласовать термины в глоссарии.
Как это делать#
- Выберите одну сущность и дайте ей определение в одну строку.
- Составьте список состояний по документам, экранам, отчётам и интервью («Какие статусы бывают у заказа?»). Объедините синонимы; разделите состояние, если за ним скрывается разное поведение.
- Отметьте начальное и конечные состояния.
- Перечислите события: действия пользователей, системные события и события по времени.
- Постройте таблицу состояний. Для каждого состояния пройдите по всем событиям и решите: проигнорировать событие, отклонить его или перейти — в какое состояние, при каком условии и с каким действием.
- Ищите пробелы: недостижимые состояния, тупики без выхода, отсутствующие пути отмены или отката.
- Нарисуйте диаграмму по таблице для обсуждения.
- Извлеките требования: правила (из сторожевых условий), атрибуты (отметки времени, коды причин), уведомления (из действий) и права доступа в каждом состоянии.
- Проверьте модель с теми, кто отвечает за сущность, и зафиксируйте базовую версию.
- Составьте тесты: минимум один на каждый переход и один на каждое запрещённое событие в каждом состоянии.
Пример#
«Мастерская», вымышленная сеть веломастерских, моделирует жизненный цикл ремонтного заказа:
| Текущее состояние | Событие [условие] | Следующее состояние | Действие |
|---|---|---|---|
| (начало) | Клиент бронирует время | Забронирован | Отправить подтверждение |
| Забронирован | Клиент отменяет бронь [больше чем за 24 часа до начала] | Отменён | Освободить время |
| Забронирован | Наступило время записи [велосипед не принят] | Неявка | Предупредить стойку приёма |
| Забронирован | Стойка приёма принимает велосипед | Принят | Распечатать карточку заказа |
| Принят | Механик осматривает [запчасти на складе] | В ремонте | Зарезервировать запчасти |
| Принят | Механик осматривает [запчастей нет] | Ждёт запчасти | Создать заказ на запчасти |
| Ждёт запчасти | Запчасти доставлены | В ремонте | Предупредить механика |
| В ремонте | Механик отмечает ремонт завершённым | Готов к выдаче | Уведомить клиента |
| Готов к выдаче | Клиент забирает велосипед и платит | Выдан (конец) | Закрыть заказ |
Показать текстом
На диаграмме те же переходы, что в таблице состояний выше: одна стрелка на каждую строку.
Построение таблицы выявило три правила, которые никто не записывал: при поздней отмене заказ остаётся «Забронирован», поэтому время оплачивается; заказ не может перейти в «В ремонте» без зарезервированных запчастей; для «Неявки» нужен код причины для отчётности. Кроме того, обнаружился пропущенный путь: что делать с велосипедом, который неделями стоит в состоянии «Готов к выдаче». Этот вопрос ушёл владельцу как открытый.
Частые ошибки#
- Состояния названы действиями («Ремонт») → называйте положение дел («В ремонте»); действия относятся к переходам или к моделям процесса.
- Только «счастливый путь» → проверьте отмену, отказ, тайм-аут и откат из каждого состояния.
- Две сущности в одной модели (бронь и счёт) → одна сущность на модель, связи — через события.
- Пропущенные или пересекающиеся условия → если из состояния по одному событию выходят две стрелки, у каждой должно быть сторожевое условие, и условия не должны пересекаться.
- Состояния без согласованного смысла → определите каждое в глоссарии, с условиями входа и выхода.
- Избыточное моделирование → оставьте технику для сущностей с действительно сложным поведением.
Шаблон#
Сущность: <название> — <определение в одну строку>
Состояния:
- <состояние>: <определение / условие входа>
Начальное: <состояние> Конечные: <состояние(я)>
| Текущее состояние | Событие | Сторожевое условие | Следующее состояние | Действие | ID правила |
|---|---|---|---|---|---|
Запрещённые события:
- <состояние>: <события, которые нужно отклонять, и показываемое сообщение>
Открытые вопросы: <список>
Чек-лист#
- У каждого состояния есть определение, с которым согласны заинтересованные стороны.
- Каждое состояние достижимо, и из каждого неконечного состояния есть выход.
- Рассмотрены все пары «состояние — событие», а не только очевидные.
- Условия на одном событии не пересекаются.
- Правила, атрибуты и уведомления, найденные в модели, записаны как требования.
- На каждый переход есть хотя бы один тест.
Источники и что почитать#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.44 «Моделирование состояний».
- Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Техника 10.44.
- Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 5 (диаграммы состояний UML, подписи переходов).