Статусная модель — это формальное описание состояний, в которых может находиться объект (заявка, документ, процесс интеграции), и правил перехода между ними. Для аналитика статусная модель — не просто перечень значений поля «Статус», а рабочий инструмент: она задаёт, какие действия допустимы в каждом состоянии, кто и как реагирует на смену статуса и какие события запускаются автоматически. Ниже разобраны два практических среза: статусы процесса интеграции с реакцией на каждый из них и жизненный цикл документа с уведомлениями при смене статуса.
1. Суть темы
Статусная модель описывает жизненный цикл объекта через конечный набор состояний и допустимых переходов. Каждое состояние отвечает на три вопроса: что произошло, что можно делать дальше и какие автоматические действия запускаются. Такой подход напрямую связан с 03.02.04 Диаграмма состояний (State Machine Diagram): диаграмма состояний визуализирует ту же логику — состояния, переходы и события-триггеры.
Ключевые понятия, которые нужно различать:
- Состояние (статус) — текущее положение объекта в жизненном цикле.
- Событие — то, что вызывает переход (смена статуса, действие пользователя, срабатывание таймера).
- Действие — реакция системы или человека на новое состояние (уведомление, эскалация, повторный запуск).
Смена статуса — это типичный пример события в процессе, а реакция на него — поток работ. Поэтому статусную модель удобно читать вместе с материалом 06.02.01 Потоки, шлюзы, события.
2. Статусы процесса интеграции
Процесс интеграции запускается с экранной формы кнопкой «Инициализация процесса интеграции». В ходе выполнения поле Статус обновляется, отражая текущее состояние. Поле принимает пять значений:
| Значение | Описание | Действие аналитика / пользователя |
|---|---|---|
| COMPLETE | Интеграция завершена успешно, все задачи выполнены | Приступать к дальнейшим действиям |
| FAIL | Интеграция завершилась неудачно из-за ошибок | Изучить сообщения об ошибках и логи, устранить причину, повторить запуск |
| WAIT | Процесс приостановлен и ждёт условий или действий | Если статус держится долго — проверить причины задержки (зависимость от внешних систем) |
| REPAIR | Требуются исправления из-за ошибок или неполадок | Устранить ошибки перед продолжением или завершением |
| NO_INFO | Данные о состоянии недоступны или ещё не обновлены | Проверить доступность данных, обновить информацию, при необходимости обратиться к администратору |
Порядок работы с формой: подготовка (настройки, права доступа) → открытие формы → инициализация → отслеживание статуса → документирование итогов → повторный запуск при необходимости. По завершении процесса независимо от результата фиксируются итоги, а при ошибках составляется отчёт с описанием проблем и предпринятых действий.
3. Жизненный цикл документа
Второй пример — статусная модель документа. Полный перечень статусов охватывает путь от создания до архивирования или аннулирования:
- Старт — документ создан.
- Регистрация — документ проходит регистрацию.
- На согласовании — направлен ответственным лицам.
- Согласован — согласование завершено успешно.
- Отклонен — документ отклонён по результатам рассмотрения.
- На доработке — возвращён на доработку.
- Утвержден — утверждён уполномоченным лицом.
- Подписан — документ подписан.
- В исполнении — по документу ведётся исполнение.
- Исполнен — исполнение завершено.
- Архивирован — документ перемещён в архив.
- Аннулирован — документ признан недействительным.
Для англоязычных интерфейсов и интеграций предусмотрен перевод статусов:
| Русский | English |
|---|---|
| Старт | Start |
| Регистрация | Registration |
| На согласовании | Under Approval |
| Согласован | Approved |
| Отклонен | Rejected |
| На доработке | Returned for revision |
| Утвержден | Confirmed |
| Подписан | Signed |
| В исполнении | In Execution |
| Исполнен | Executed |
| Архивирован | Archived |
| Аннулирован | Canceled |
Обратите внимание: статуса «устарел», о котором идёт речь в сценарии уведомлений ниже, в этом перечне нет. Соотношение статуса «устарел» с перечисленными двенадцатью требует уточнения — это открытый вопрос модели.
4. Уведомления при смене статуса
Отдельный сценарий — автоматическое информирование пользователей при переходе документа в статус «устарел». Цель — своевременно напоминать об обновлении или архивировании документа, чтобы в рабочих процессах не использовалась неактуальная информация.
Уведомления отправляются дважды:
- Немедленное — сразу после смены статуса на «устарел».
- Отложенное — повторно через три месяца, как напоминание.
Архитектурно решение состоит из трёх частей:
- Триггер на событие смены статуса — реализуется на уровне СУБД (триггеры) либо бизнес-логики приложения (контроллер или сервис, отвечающий за изменение статуса).
- Система уведомлений — отдельный модуль или сервис, отправляющий email, push-уведомления или сообщения.
- Планировщик задач — механизм для отложенной отправки второго уведомления.
Для доставки сообщений может применяться система обмена сообщениями (например, Kafka), а для отложенной отправки — планировщик задач (например, Celery или встроенные средства языка).
5. Как читать статусную модель аналитику
Чтобы статусная модель была рабочей, а не декоративной, проверяйте её по чек-листу:
| Вопрос | Зачем |
|---|---|
| Все ли состояния достижимы и имеют выход? | Исключить «тупиковые» статусы |
| Какое событие вызывает каждый переход? | Связать модель с потоками и событиями |
| Какие действия запускаются автоматически? | Уведомления, эскалации, повторные запуски |
| Кто реагирует на «проблемные» статусы (FAIL, REPAIR, NO_INFO)? | Задать регламент обработки ошибок |
| Согласованы ли названия статусов между системами и языками? | Избежать расхождений в интеграциях |
Статусная модель становится основой для диаграммы состояний, спецификации API и регламентов поддержки. Именно на этом стыке анализ требований превращается в проектирование поведения системы.