- •Содержание
- •Предисловие
- •Краткая история uml
- •1. Зачем мы моделируем
- •Значение моделирования
- •Принципы моделирования
- •Объектное моделирование
- •2. Введение в язык uml
- •Обзор uml
- •Где используется uml
- •Концептуальная модель uml
- •Строительные блоки uml
- •Правила языка uml
- •Общие механизмы языка uml
- •Жизненный цикл разработки по
- •4. Классы
- •Термины и понятия
- •Атрибуты
- •Операции
- •Организация атрибутов и операций
- •Обязанности
- •Другие свойства
- •5. Отношения
- •Термины и понятия
- •Зависимости
- •Обобщения
- •Ассоциации
- •Другие свойства
- •Типичные приемы моделирования Простые зависимости
- •Одиночное наследование
- •6. Диаграммы классов
- •Термины и понятия
- •Общие свойства
- •Типичные примеры применения
- •Типичные приемы моделирования Простые кооперации
- •Прямое и обратное проектирование
- •7. Диаграммы объектов
- •Термины и понятия
- •Общие свойства
- •Типичные примеры применения
- •Типичные приемы моделирования Объектные структуры
- •Прямое и обратное проектирование
- •8. Диаграммы деятельности
- •Термины и понятия
- •Общие свойства
- •Наполнение
- •Состояния действия и состояния деятельности
- •Переходы
- •Ветвление
- •Разделение и слияние
- •Дорожки
- •Траектория объекта
- •Операция
- •9. Диаграммы состояний
- •Термины и понятия
- •Типичные примеры использования
- •Типичные приемы моделирования Реактивные объекты
- •29. Диаграммы компонентов
- •11. Диаграммы развертывания
- •Термины и понятия
- •Общие свойства
- •Типичное применение
- •Клиент-серверная система
- •12. Применение uml
- •Переход к uml
- •Литература
Термины и понятия
Диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) -это описание последовательности состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода. Переход (Transition) - это отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) -это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами.
Типичные примеры использования
Диаграммы состояний применяются для моделирования динамических аспектов системы. Имеется в виду обусловленное порядком возникновения событий поведение объектов любого рода в любом представлении системной архитектуры, включая классы, интерфейсы, компоненты и узлы. Использовать диаграммы состояний для моделирования некоторого динамического аспекта системы можно в контексте практически любого элемента модели. Обычно, однако, диаграммы состояний применяются в контексте системы в целом, подсистемы или класса. Можно присоединять диаграммы состояний и к прецедентам (для моделирования сценария).
При моделировании динамических аспектов системы, класса или прецедента диаграммы состояний обычно используются только с целью моделирования реактивных объектов.
Реактивный, или управляемый событиями, объект - это такой объект, поведение которого лучше всего характеризовать его реакцией на внешние события. Как правило, реактивный объект находится в состоянии ожидания, пока не получит событие, а когда это случается, его реакция зависит от предшествующих событий. После того как объект отреагирует на событие, он снова переходит в состояние ожидания следующего события. Для таких объектов интерес представляют прежде всего устойчивые состояния, события, инициирующие переходы из одного состояния в другое, и действия, выполняемые при смене состояния.
Примечание: В противоположность этому диаграммы деятельности используются для моделирования рабочего процесса или операции. Они в большей степени подходят для показа протекания деятельности во времени и этим напоминают блок-схемы.
Типичные приемы моделирования Реактивные объекты
Чаще всего диаграммы состояний используются для моделирования реактивных объектов, особенно экземпляров классов, прецедентов и системы в целом.
В то время как взаимодействия применяются для моделирования поведения сообщества объектов, совместно решающих некоторую задачу, диаграммы состояний предназначены для моделирования поведения одного объекта на протяжении его жизненного цикла. Если диаграммы деятельности моделируют поток управления от деятельности к деятельности, то диаграммы состояний - поток управления от события к событию.
При моделировании поведения реактивного объекта нужно специфицировать главным образом три вещи: устойчивые состояния, в которых может находиться объект, события, которые иницируют переходы из одного состояния в другое, и действия, выполняемые при каждой смене состояния. Моделирование реактивного объекта подразумевает моделирование всего его жизненного цикла, начиная с момента создания и вплоть до уничтожения, с особым акцентом на устойчивые состояния, в которых может находиться объект.
Устойчивое состояние - такое, в котором объект может находиться неопределенно долгое время. Когда происходит некое событие, объект переходит в новое состояние. События могут также инициировать переходы в себя и внутренние переходы, когда исходное и целевое состояния совпадают. В ходе реакции на событие или изменения состояния объект может выполнить некоторое действие.
Примечание: При моделировании поведения реактивного объекта вы можете специфицировать действие, привязав его к переходу или изменению состояния. В специальной литературе автомат, все действия которого привязаны к переходам, называется машиной Мили (Mealy), а автомат, все действия которого привязаны к состояниям, машиной Мура (Moore). C математической точки зрения тот и другой обладают одинаковой выразительной мощью. На практике при разработке диаграмм состояний обычно используется комбинация машин Мили и Мура.
Моделирование реактивного объекта складывается из следующих процессов:
Выберите контекст для автомата - класс, прецедент или систему в целом.
Выберите начальное и конечное состояния для объекта. Для использования в остальной части модели, возможно, стоит сформулировать пред- и пост условия для начального и конечного состояния.
Определите устойчивые состояния объекта, - те, в которых он может находиться неопределенно долгое время. Начните с состояний верхнего уровня, а затем переходите к подсостояниям.
Определите разумное частичное упорядочение устойчивых состояний на протяжении жизненного цикла объекта.
Определите, какие события могут инициировать переходы между состояниями. Смоделируйте эти события как триггеры переходов из одного допустимого упорядочения состояний в другое.
Присоедините действия к переходам (как в машине Мили) и/или к состояниям (как в машине Мура).
Рассмотрите, как можно упростить автомат за счет использования подсостояний, ветвлений, разделений, слияний и исторических состояний.
Проверьте, что любое из состояний достижимо при некоторой комбинации событий.
Убедитесь в отсутствии тупиковых состояний, то есть таких, из которых нет переходов ни при какой комбинации событий.
Трассируйте автомат вручную или с помощью инструментальных средств и проверьте, как он ведет себя при ожидаемых последовательностях событий и реакций на них.
На рис. 24.2 показана диаграмма состояний для разбора простого контекстно-свободного языка. Примеры таких язков можно найти в системах, для которых входной или выходной поток составляют XML-сообщения. В таких случаях проектируется автомат для разбора потока символов, удовлетворяющего синтаксису языка:
Рис.
24.2 Моделирование реактивных объектов
Первая строка представляет тэг, вторая - тело сообщения. Из данного потока символов извлекаются только сообщения, удовлетворяющие правилам синтаксиса.
Из рисунка видно, что для автомата предусмотрены только три устойчивых состояния: Ожидание, ПолучениеЛексемы и ПолучениеТела. Диаграмма состояний спроектирована в виде машины Мили - действия привязаны к переходам. На самом деле в автомате есть только одно представляющее интерес событие - вызов put с фактическим параметром с (символом). В состоянии Ожидание автомат отбрасывает все символы, не интерпретируемые как начало лексемы (это специфицировано сторожевым условием). При обнаружении начала лексемы состояние объекта изменяется на ПолучениеЛексемы. Находясь в этом состоянии, автомат сохраняет все символы, не интерпретируемые как конец лексемы (это тоже специфицировано сторожевым условием). Обнаружив конец лексемы, объект переходит в состояние ПолучениеТела. В этом состоянии автомат сохраняет все символы, не интерпретируемые как конец сообщения. Как только получен конец сообщения, состояние объекта меняется на Ожидание; возвращается значение, показывающее, что сообщение разобрано и автомат готов к приему следующего.
Обратите внимание, что эта диаграмма описывает автомат, работающий непрерывно - в нем нет конечного состояния.
Обратное проектирование (создание модели по коду) теоретически возможно, но практически не очень полезно. Выбор того, что составляет значимое состояние, - прерогатива проектировщика. Инструмент для обратного проектирования не обладает способностью к абстрагированию и потому не может автоматически породить осмысленные диаграммы состояний. Более интересный вариант - анимация модели, задача которой заключается в том, чтобы показать, как будет исполняться развернутая система. Скажем, в предыдущем примере инструментальная программа могла бы анимировать состояния диаграммы по мере их достижения в работающей системе. При этом можно также подвергнуть анимации и срабатывание переходов, показав получение событий и выполнение соответствующих действий. Под управлением отладчика допустимо контролировать скорость выполнения и устанавливать точки прерывания для остановки работы в представляющих интерес состояниях, чтобы просмотреть значения атрибутов отдельного объекта.
