Моделирование состояний

Модель взаимодействий позволяет составить детализированную спецификацию прецедента. Модель состояний (statechart model) служит детализированным описанием класса или, более точно, динамических изменений состояний класса. Эти динамические изменения обычно описывают поведение объекта в рамках нескольких прецедентов.

Модель состояний (statechart model) фиксирует возможные состояния, в которых может находиться класс, и эффективно фиксирует “жизненный путь” класса. На протяжение своего жизненно цикла объект остается одним и тем же - его идентичность никогда не изменяется. Однако состояние объекта изменяется.

Диаграмма состояний представляет собой граф состояний (прямоугольников с закругленными углами) и переходов (стрелки), вызванных событиями.

Рассмотрим класс Invoice (Счет-фактура), относящийся к приложению Интернет-магазин. Из модели прецедентов известно, что клиент определяет способ оплаты (карточка или наличные), когда закупочная форма заполнена и отослана производителю. Это приводит к генерации заказа и последующей подготовке счета-фактуры. Но диаграмма прецедентов не проясняет вопрос о том, когда производится фактическая оплата в соответствии со счетом фактурой. Можно предположить, что оплата может осуществляться до или после того как счет-фактура выдана, также можно предположить возможность частичной оплаты.

Из модели класса нам известно, что счет-фактура подготавливается продавцом и , в конечном итоге, передается на склад. Склад отправляет счет-фактуру клиенту одновременно с доставкой клиенту компьютера. Состояние оплаты счета-фактуры отслеживается в системе и счет-фактура снабжена соответствующими комментариями.

Приведенный выше пример схватывает сущность моделирования состояний. Модели состояний строятся для классов, которые характеризуются не просто изменениями состояний, а изменениями состояний, представляющими определенный интерес с точки зрения предметной области. Решение о том, что представляет интерес, а что нет, является прерогативой моделирования бизнес-процессов. Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Они относительно независимы от конкретных прецедентов. В действительности прецеденты должны соответствовать бизнес-правилам.

На рис. 4.9. показана модель состояний для класса Invoice. Начальным состоянием объекта Invoice является состояние Unpaid (не оплачено). Из состояния Unpaid возможны два перехода. При наступлении события partial payment (частичная оплата) объект Invoice переходит в состояние Partly Paid (частично оплачено). Допускается только одна частичная оплата. Наступление события finalpayment (окончательная оплата), когда объект Invoice находится в состоянии Unpaid или Partly Paid, инициирует переход в состояние Fully Paid (полностью оплачено). Это конечное состояние.

Рисунок 4.9. Состояния и события для класса Invoice (Интернет-магазин)

Диаграмма состояний обычно присоединяется к классу, но, в общем случае, она может присоединяться к другим представлениям, например, прецедентам. Диаграмма состояний, присоединенная к классу, определяет способ реагирования объектов класса на события. Более точно, диаграмма определяет - для каждого состояния объекта - действие (action), выполняемое объектом при получении им сигнала о событии. Один и тот же объект может выполнять различные действия в ответ на одно и то же событие в зависимости от состояния объекта. Выполнение действия, как правило, вызывает изменение состояния.

Полное описание перехода (transition) состоит из трех частей:

event (parameters) [guard] / action.

Каждая из частей является необязательной. Если строка перехода самоочевидна, допустимо опустить все компоненты. Событие — это кратковременное явление, которое воздействует на объект. Оно может обладать параметрами, например, кнопка мыши нажата (правая-кнопка). Событие может быть защищено ограждающим условием (guard), например, кнопка мыши нажата (правая-кнопка) [внутри окна]. Если условие принимает значение “истина”, событие срабатывает и воздействует на объект. Действие (action) представляет собой короткое атомическое вычисление, которое выполняется при срабатывании перехода. Действие также может быть связано с состоянием.

В общем случае действие - это отклик объекта на обнаруженное событие. Состояние может содержать более продолжительное вычисление - вид деятельности (activity).

Состояние может состоять из других состояний, которые называются вложенными (nested state). Составное состояние (composite state) является абстрактным - это всего лишь родовое имя для всех вложенных состояний. Переход, который берет начало из-за границы составного состояния, означает, что он может сработать от любого из вложенных состояний. Это делает диаграмму более ясной и лаконичной. Конечно, переход, который берет начало вне границы составного состояния, может сработать от вложенного состояния.

Диаграмма состояний для класса Order показана на рис. 4.10. Начальное состояние объекта класса - New Order (новый заказ). Это одно из вложенных состояний составного состояния Pending (ожидающий [заказ]) - к другим относятся состояния Back Order (невыполненный заказ) и Future Order (будущий заказ). Из каждого из этих трех состояний, вложенных в состояние Pending, возможны два перехода. Переход в состояние Canceled (отменен) защищено условием [canceled]. Должна существовать возможность - без изменения правил моделирования состояний - заменить защитное условие событием cancel. Переход в состояние Ready to Ship (готов к доставке) помечен полным описанием, содержащим событие, защиту и действие.

Рисунок 4.10. Диаграмма состояний для класса Order (Интернет-магазин)