В UML на диаграмме состояний команду изменения данных поместили в guard перехода. Какое искажение семантики модели возникает?
Guard — это проверяемое условие, которое разрешает или запрещает переход, а не место для выполнения команды. Если в него поместить операцию изменения данных, модель смешает проверку возможности перехода с побочным эффектом: результат проверки начнёт изменять состояние системы. Команду следует представить как эффект перехода, действие входа или выхода из состояния — в зависимости от момента выполнения.
Диаграммы состояний возникли как способ описывать поведение объекта через его состояния, события и переходы. Такое разделение помогает отдельно показать, при каком условии допускается переход и какие действия выполняются после его выбора.
Разделение условия и действия важно для анализа поведения: условие можно проверять без изменения модели, а действие — связывать с конкретным переходом или состоянием. Это снижает неоднозначность при разработке и тестировании.
Guard отвечает на вопрос: может ли переход быть выполнен при наступлении события. Команда изменения данных отвечает на другой вопрос: что должно произойти после выбора перехода.
Если команда находится внутри guard, проверка перестаёт быть безопасной. Например, попытка определить доступность операции может одновременно списать средства, изменить статус заказа или отправить уведомление. При этом непонятно, произойдёт ли такое изменение, если условие окажется ложным.
Такая модель создаёт риски:
В guard помещают выражение, результат которого можно интерпретировать как истину или ложь. Оно должно отвечать на вопрос о текущих условиях перехода и не выполнять команд, меняющих состояние системы.
Бизнес-операцию следует разместить как effect перехода, если она выполняется при выборе конкретного перехода. Если изменение должно происходить при входе в состояние независимо от того, каким переходом объект туда попал, уместнее действие входа. Если оно связано с выходом, его размещают как действие выхода.
Правильная логика имеет два отдельных шага: сначала проверяется условие, затем, если переход разрешён и выбран, выполняется его действие. Если для принятия решения требуется результат операции, операцию нужно разделить на безопасный запрос и изменяющую команду либо явно представить внешнее взаимодействие и его результат как отдельное событие.
Guard может обращаться к данным и выполнять запрос, если он не меняет состояние и имеет понятный результат. Однако даже такой запрос не должен скрывать сетевой вызов, запись в базу, отправку сообщения или другой побочный эффект без явного отражения этого взаимодействия в модели.
В процессе оформления заказа аналитик поместил в guard перехода операцию резервирования товара. Предполагалось, что переход в состояние «Зарезервирован» будет разрешён только при успешном резервировании.
Рассматривались два варианта. Первый — оставить резервирование внутри guard: запись получается короткой, но условие приобретает побочный эффект, а повторная проверка может создать повторную попытку резервирования. Второй — сначала выполнить отдельную операцию резервирования, получить событие или результат «резервирование успешно», а затем использовать этот результат для перехода.
Выбран второй вариант: резервирование моделируется как действие внешнего взаимодействия, а guard проверяет полученный результат. Это явно показывает границу между командой и условием, позволяет отдельно обработать отказ и делает поведение повторяемым для тестов. В результате повторная оценка условия не приводит к дополнительному резервированию.
Да, если это безопасный запрос, который возвращает значение и не изменяет состояние. Например, проверка срока действия или текущего лимита может быть частью условия. Но метод, который создаёт запись, меняет статус, списывает деньги или отправляет сообщение, не должен скрываться в guard.
Нужно устранить неоднозначность модели: сделать условия взаимно исключающими, уточнить приоритет бизнес-правил или явно показать дополнительное решение. Нельзя полагаться на порядок, зависящий от конкретного инструмента или реализации, если он не является частью согласованной семантики модели.
Да. Действие перехода может изменить данные, а последующие переходы могут использовать новое значение. Важно, чтобы это изменение происходило после выбора текущего перехода и было явно связано с ним; guard текущего перехода не должен зависеть от побочного эффекта, который этот же guard запускает.