На этом шаге рассмотрим приемы моделирования реактивных объектов в UML.
Чаще всего, как уже было сказано, диаграммы состояний используются при моделировании поведения реактивных объектов, особенно экземпляров классов, вариантов использования и системы в целом. В то время как взаимодействия моделируют поведение сообщества объектов, работающих вместе, диаграмма состояний моделирует поведение отдельного объекта во время его жизненного цикла. В отличие от диаграмм деятельности, которые моделируют поток управления от одной деятельности к другой, диаграмма состояний моделирует поток управления от одного события к другому.
При моделировании поведения реактивного объекта, по сути, специфицируются три вещи: стабильные состояния, в которых объект может пребывать, события, вызывающие переходы от состояния к состоянию, и действия, выполняемые при каждой смене состояний. Кроме того, моделирование поведения реактивного объекта подразумевает моделирование его жизненного цикла начиная с создания объекта вплоть до его уничтожения, с выделением стабильных состояний, в которых он может находиться.
Стабильное состояние представляет условие, при котором объект может существовать в течение некоторого определенного периода времени. Когда происходит событие, объект может переходить из одного состояния в другое. Эти события также могут вызывать переходы в себя и внутренние переходы, когда исходное и целевое состояния объекта совпадают. Реагируя на события и изменения состояния, объект может выполнять действия.
Чтобы смоделировать реактивный объект, необходимо:
- Выбрать контекст автомата – класс, вариант использования или систему в целом.
- Установить начальное и конечное состояния объекта. Возможно, чтобы управлять остальными частями модели, понадобится также установить пред- и постусловия начального и конечного состояний соответственно.
- Принять решения относительно стабильных состояний объекта, рассмотрев условия, в которых объект может существовать в течение определенного периода времени. Начать с состояний высшего уровня и только после этого перейти к рассмотрению возможных подсостояний.
- Принять решения относительно осмысленного частичного упорядочения состояний на протяжении времени жизни объекта.
- Принять решения относительно событий, которые могут вызывать переходы из одного состояния в другое. Смоделировать эти события как триггеры переходов между состояниями.
- Присоединить действия к переходам и/или к состояниям.
- Рассмотреть возможности упрощения автомата за счет применения подсостояний, ветвления, разделений, соединений и исторических состояний.
- Убедиться, что все состояния достижимы при некотором стечении событий.
- Проверить, нет ли каких-нибудь "мертвых" состояний, из которых объект не сможет выйти ни при каком сочетании событий.
- Провести трассировку автомата (либо вручную, либо с применением инструментальных средств), чтобы подтвердить соответствие ожидаемым последовательностям событий и реакциям на них.
В качестве примера на рис. 1 показана диаграмма состояний, предназначенная для разбора некоего простого контекстно-свободного языка – вроде того, что можно встретить в системах, обрабатывающих входные и выходные потоки сообщений XML.
Рис.1. Моделирование реактивных объектов
В данном случае автомат предназначен для разбора потока символов, соответствующих синтаксису
message : ‘<’ string ‘>’ string ‘;’.
Первая строка представляет тег, вторая – тело сообщения. Из полученного потока символов принимаются только сообщения с правильным синтаксисом. Как показано на рисунке, у автомата есть только три стабильных состояния: Waiting (Ожидание), GettingToken (ПолучениеСлова) и GettingBody (ПолучениеТела). Состояние спроектировано в виде машины Мили – с действиями, присоединенными к переходам.
Фактически есть только одно событие, которое может нас интересовать при рассмотрении этого автомата – вызов put с параметром c (символом). В состоянии Waiting автомат отбрасывает любой символ, который не означает начало слова (что объявлено в защитном условии). Как только встречается начало слова, состояние объекта изменяется на GettingToken. Находясь в этом состоянии, автомат сохраняет каждый символ, который не является окончанием слова.
Когда приходит символ окончания слова, состояние объекта изменяется на GettingBody. Находясь в этом состоянии, автомат сохраняет каждый символ, который не означает окончания тела сообщения (что объявлено в защитном условии). Как только поступает окончание сообщения, состояние объекта изменяется на Waiting и возвращается значение, указывающее на то, что сообщение было разобрано и автомат готов получать следующее.
Отметим, что последнее состояние специфицирует автомат, который работает непрерывно, – конечного состояния не существует.
На следующем шаге рассмотрим понятие артефакта.
