На этом шаге рассмотрим типичные приемы моделирования жизненного цикла объекта.
Наиболее общее назначение автоматов – моделирование жизненного цикла объекта, в особенности если речь идет об экземплярах классов, вариантов использования и о системе в целом. В то время как взаимодействие моделирует поведение сообщества работающих вместе объектов, автомат моделирует поведение одного объекта в течение его жизненного цикла – например, так, как это бывает с пользовательскими интерфейсами, контроллерами и различными техническими устройствами.
Когда моделируется жизненный цикл объекта, приходится явно специфицировать три момента: события, на которые объект может реагировать, непосредственную реакцию на эти события и влияние более раннего поведения на текущее. Кроме того, моделирование жизненного цикла объекта включает в себя принятие решений о порядке, в котором объект может осмысленно реагировать на события, начиная с момента его создания и заканчивая уничтожением.
Чтобы смоделировать жизненный цикл объекта, необходимо:
- определить контекст автомата – будет ли это класс или система в целом:
- если речь идет о контексте класса или варианта использования, найти соседние классы, включая всех родителей данного класса и всех доступных ему по ассоциациям или зависимостям. Эти соседи – потенциальные цели действий, а также кандидаты на включение в защитные условия;
- если же речь идет о контексте системы в целом, необходимо сосредоточить внимание на каком-то одном аспекте ее поведения. Теоретически каждый объект системы может участвовать в моделировании ее жизненного цикла, и за исключением работы с простейшими системами такие полные модели будут недоступны для понимания.
- установить начальное и конечное состояния объекта. Чтобы управлять остальной моделью, возможно, понадобится установить пред- и постусловия начального и конечного состояний соответственно;
- принять решения относительно событий, на которые должен реагировать объект. Их можно обнаружить в интерфейсах объекта (если они уже специфицированы); если же нет, следует рассмотреть, какие объекты могут взаимодействовать с данным в имеющемся контексте и какие события они могут передавать и принимать;
- от начального состояния до конечного выделить те состояния высшего уровня, в которых может находиться объект. Соединить их переходами, инициируемыми соответствующими событиями. Продолжать работу, добавляя действия к этим переходам;
- идентифицировать входные и выходные действия (особенно если обнаружится, что соответствующая идиома используется в автомате);
- при необходимости расширить выделенные состояния подсостояниями;
- проверить, все ли упомянутые события в автомате соответствуют событиям, ожидаемым в интерфейсе объекта. Аналогичным образом проверить, все ли события, ожидаемые интерфейсом объекта, обрабатываются в автомате. Наконец, рассмотреть места, где следует явно игнорировать события;
- убедиться, что все действия, упомянутые в автомате, поддерживаются связями, методами и операциями включающего объекта;
- провести трассировку автомата (либо вручную, либо с применением инструментальных средств), чтобы проверить его на соответствие ожидаемым последовательностям событий и реакций на них. Особенно старательно следует поискать недостижимые состояния и состояния, в которых автомат может зациклиться;
- после реорганизации автомата снова проверить его на предмет того, не изменилась ли семантика объекта.
В примере на рис. 1 представлен автомат контроллера домашней системы сигнализации, которая отвечает за отслеживание показаний разнообразных датчиков, расположенных по периметру дома.
Рис.1. Моделирование жизненного цикла объекта
В жизненном цикле этого контроллера имеются четыре основных состояния: Initializing (Инициализация – запуск работы), Idle (Простой – контроллер готов и ожидает сигналов тревоги или команд пользователя), Command (Команда – обработка команд пользователя) и Active (Активен – обработка сигнала тревоги). Впервые создаваемый объект контроллера сначала попадает в состояние Initializing, а затем безусловно переходит в состояние Idle. Подробности этих двух состояний не показаны, за исключением перехода в себя по истечении определенного периода времени (10 с) в состоянии Idle. Временные события подобного рода часто встречаются во встроенных системах, где присутствует таймер, вызывающий периодическую проверку работоспособности системы.
Управление передается от состояния Idle в состояние Active по получении события alarm (тревога). Последнее сопровождается параметром s, идентифицирующим датчик, который был задет. При входе в состояние Active в качестве входного выполняется действие setAlarm (поднятьТревогу) и управление передается сначала состоянию Checking (Проверка), затем состоянию Calling (Вызов), обеспечивающему вызов охранной компании для регистрации сигнала тревоги, и, наконец, состоянию Waiting (Ожидание). Состояния Active и Waiting завершаются только при "очистке" сигнала тревоги (clearAlarm) или же по инициативе пользователя, при посылке события attention (внимание), предположительно предшествующего команде.
Отметим, что конечного состояния здесь нет. И это опять же типично для встроенных систем, которые должны работать непрерывно.
При моделировании автоматов на UML следует помнить, что каждый из них выражает динамические аспекты отдельного объекта, обычно представляющего экземпляр класса, варианта использования либо систему в целом. Хорошо структурированный автомат должен обладать следующими характеристиками:
- быть достаточно простым и не включать излишних состояний или переходов;
- благодаря ясному контексту иметь доступ ко всем объектам, видимым его включающему объекту (все эти соседи должны использоваться только при необходимости обеспечения поведения, специфицированного автоматом);
- быть эффективным, то есть реализовывать свое поведение с оптимальным балансом затрат времени и ресурсов;
- быть понятным, а потому именовать свои состояния и переходы в терминологии словаря системы;
- не допускать слишком глубоких уровней вложенности (вложенных подсостояний первого-второго уровней вполне хватит для описания самого сложного поведения);
- умеренно использовать ортогональные области, поскольку часто предпочтительно применение активных классов.
При изображении автомата в UML необходимо:
- избегать пересекающихся переходов;
- раскрывать составные состояния "по месту" только в том случае, если это сделает диаграмму более понятной.
На следующем шаге рассмотрим понятие активного объекта, потока и процесса в UML.
