Диаграмма состояний (диаграмма автомата) UML

Автор:Давиденко Сергей

Диаграмма состояний (диаграмма автомата) UML

Для чего используется техника креативности

Показать поведение одного объекта в течение его жизни, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат.

План действий

В разделе «Описание» изучите основной набор символов диаграммы состояний, необходимый для того, чтобы уметь читать диаграммы.

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм состояний.

Замечания (описание)

Здесь представлен основной набор символов диаграммы состояний , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы состояний самостоятельно!

 Термин Изображение  Описание
 Начальное псевдосостояние (initial pseudostate)  диаграмма состояний - начальное псевдосостояние Начальное состояние системы
 Переход   Переход (transition) означает перемещение из одного состояния в другое.
 Состояние   Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
 Состояние
активности (activity state)
  Сложный шаг в прецеденте можно представить другим прецедентом.
В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
 Конечное состояние   Позволяет обозначить границы систем или подсистем.
Внутренние активности (internal activities) Случай когда состояния могут реагировать на события без совершения перехода, и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния.

 

Входная активность Входная активность выполняется всякий раз, когда вы входите в состояние

 

Выходная активность Выходная активность – выполняется всякий раз, когда вы покидаете состояние.

 

Суперсостояние Диаграмма состояний UML - суперсостояние Часто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate).
Параллельные состояния Диаграмма состояний UML - параллельные состояния Состояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно.

Как применять технику креативности

Диаграммы состояний UML хороши для описания поведения одного объекта в нескольких прецедентах. Но они не очень подходят для описания поведения, характеризующегося взаимодействием множества объектов. Поэтому имеет смысл совместно с диаграммами состояний применять другие технологии. Например, диаграммы взаимодействия (глава 4) прекрасно описывают поведение нескольких объектов в одном прецеденте, а диаграммы деятельности UML хороши для показа основной последовательности действий нескольких объектов в нескольких прецедентах.

Не все считают диаграммы состояний естественными. Понаблюдайте, как специалисты работают с ними. Вполне возможно, что члены вашей команды не думают, что диаграммы состояний подходят для их стиля работы. Это не самая большая трудность; вы должны не забывать совместно использовать различные приемы работы.

Если вы применяете диаграммы состояний, то не старайтесь нарисовать их для каждого класса системы. Такой подход часто применяется в целях формально строгой полноты, но почти всегда это напрасная трата сил. Применяйте диаграммы состояний только для тех классов, которые проявляют интересное поведение, когда построение диаграммы состояний помогает понять, как все происходит.

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

Как научиться

Здесь мы попытались предоставить как можно более простой способ изучения диаграммы состояний языка UML.

Как и многие другие языки он использует для описания набор знаков. Смысл этих знаков вы найдете в таблице в разделе «Замечания (описание)». Каждый знак имеет свое наименование (термин) и написание. Также каждый термин снабжен кратким пояснением, чтобы быстро уяснить его основную суть.

Далее мы бы рекомендовали перейти в раздел «Примеры» диаграмм состояний, чтобы попробовать свои силы в чтении разных диаграмм. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять соответствующие диаграммы по назначению.

Пример использования

Диаграмма состояний UML

Диаграмма состояний (state machine diagrams) – это известная технология описания поведения системы. В том или ином виде диаграмма состояний существует с 1960 года, и на заре объектно-ориентированного программирования они применялись для представления поведения системы. В объектно-ориентированных подходах вы рисуете диаграмму состояний единственного класса, чтобы показать поведение одного объекта в течение его жизни.

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

На рис. 10.1 показана диаграмма состояний класса контроллера, который управляет моей необычной системой безопасности. Диаграмма состояния начинается с состояния создаваемого объекта контроллера: состояния Wait (Ожидание). На диаграмме это обозначено с помощью начального псевдосостояния (initial pseudostate), которое не является состоянием, но имеет стрелку, указывающую на начальное состояние.
На диаграмме показано, что контроллер может находиться в одном из трех состояний: Wait (Ожидание), Lock (Замок) и Open (Открыт). На диаграмме также представлены правила, согласно которым контроллер переходит из одного состояния в другое. Эти правила представлены в виде переходов – линий, связывающих состояния.

Диаграмма состояний UML

Переход (transition) означает перемещение из одного состояния в другое. Каждый переход имеет свою метку, которая состоит из трех частей:
триггер-идентификатор [защита]/активность (trigger-signature [guard]/activity). Все они не обязательны. Как правило, триггер-идентификатор – это единственное событие, которое может вызвать изменение состояния.

Защита, если она указана, представляет собой логическое условие, которое должно быть выполнено, чтобы переход имел место. Активность – это некоторое поведение системы во время перехода. Это может быть любое поведенческое выражение. Полная форма триггера-идентификатора может включать несколько событий и параметров. Переход из состояния Wait (рис. 10.1) в другое состояние можно прочесть как «В состоянии Wait, если свеча удалена, вы видите замок и переходите в состояние Lock».

Все три части описания перехода не обязательны. Пропуск активности означает, что в процессе перехода ничего не происходит. Пропуск за щиты означает, что переход всегда осуществляется, если происходит инициирующее событие. Триггер-идентификатор отсутствует редко,  но и так бывает. Это означает, что переход происходит немедленно, что можно наблюдать главным образом в состояниях активности.

Когда в определенном состоянии происходит событие, то из этого состояния можно совершить только один переход, например в состоянии Lock (рис. 10.1) защиты должны быть взаимно исключающими. Если событие происходит, а разрешенных переходов нет – например закрытие сейфа в состоянии Wait или удаление свечи при открытой двери, – событие игнорируется.

Конечное состояние (final state) означает, что конечный автомат закончил работу, что вызывает удаление объекта контроллера. Так что для тех, кто имел неосторожность попасть в ловушку, сообщаем, что поскольку объект контроллера прекращает свое существование, мы вынуждены посадить кролика обратно в клетку, вымыть пол и перегрузить систему.

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

Когда разработчики говорят об объектах, они часто ссылаются на состояние объектов, имея в виду комбинацию всех данных, содержащихся в полях объектов. Однако состояние на диаграмме конечного автомата является более абстрактным понятием состояния; суть в том, что различные состояния предполагают различные способы реакции на события.

Внутренние активности в диаграмме состояний

Состояния могут реагировать на события без совершения перехода, используя внутренние активности (internal activities), и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния.

На рис. 10.2 представлено состояние с внутренними активностями символов и событиями системы помощи, которые вы можете наблюдать в текстовых полях редактора UI. Внутренняя активность подобна самопереходу (self-transition) – переходу, который возвращает в то же самое состояние. Синтаксис внутренних активностей построен по той же логической схеме события, защиты и процедуры.

На рис. 10.2 показаны также специальные активности: входная и выходная активности. Входная активность выполняется всякий раз, когда вы входите в состояние; выходная активность – всякий раз, когда вы покидаете состояние. Однако внутренние активности не инициируют входную и выходную активности; в этом состоит различие между внутренними активностями и самопереходами.

Диаграмма состояний UML - внутренние активности

Состояния активности в диаграмме состояний

В состояниях, которые мы описывали до сих пор, объект молчит и ожидает следующего события, прежде чем что-нибудь сделать. Однако возможны состояния, в которых объект проявляет некоторую активность.

Состояние Searching (Поиск) на рис. 10.3 является таким состоянием активности (activity state): ведущаяся активность обозначается символом do/; отсюда термин do-activity (проявлять активность). После того как поиск завершен, выполняются переходы без активности, например показ нового оборудования (Display New Hardware). Если в процессе активности происходит событие отмены (cancel), то do-активность просто прерывается и мы возвращаемся в состояние Update Hardware Window (Обновление окна оборудования).
Диаграмма состояний UML - состояние с активностью

И do-активности, и обычные активности представляют проявление некоторого поведения. Решающее различие между ними заключается в том, что обычные активности происходят «мгновенно» и не могут быть прерваны обычными событиями, тогда как do-активности могут выполняться в течение некоторого ограниченного времени и могут прерываться, как показано на рис. 10.3. Мгновенность для разных систем трактуется по-разному; для систем реального времени это может занимать несколько машинных инструкций, а для настольного программного обеспечения может составить несколько секунд.

В UML 1 обычные активности обозначались термином action (действие), а термин activity (активность) применялся только для do-активностей.

Суперсостояния

Часто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate), как показано на рис. 10.4. Без суперсостояния пришлось бы рисовать переход cancel (отмена) для всех трех состояний внутри состояния Enter Connection Details (Ввод подробностей соединения).

Диаграмма состояний UML - суперсостояние

Параллельные состояния

Состояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно. На рис. 10.5 показан простой будильник, который может включать либо CD, либо радио и показывать либо текущее время, либо время сигнала.

Опции CD/радио и текущее время/время сигнала являются параллельными. Если бы вы захотели представить это с помощью диаграммы непараллельных состояний, то получилась бы беспорядочная диаграмма при необходимости добавить состояния. Разделение двух областей поведения на две диаграммы состояний делает ее значительно яснее.

Диаграмма состояний UML - параллельные состояния

Рис. 10.5 включает также состояние предыстории (history pseudostate). Это означает, что когда включены часы, опция радио/CD переходит в состояние, в котором находились часы, когда они были выключены. Стрелка, выходящая из предыстории, показывает, какое состояние существовало изначально, когда отсутствовала предыстория.

Реализация диаграмм состояний

Диаграмму состояний можно реализовать тремя основными способами: с помощью вложенного оператора switch, паттерна State и таблицы состояний. Самый прямой подход в работе с диаграммами состояний – это вложенный оператор switch, такой как на рис. 10.6.

Реализация диаграммы состояний UML на C#

Хотя этот способ и прямой, но очень длинный даже для этого простого случая. Кроме того, при данном подходе очень легко потерять контроль, поэтому не рекомендуем применять его даже в элементарных ситуациях.
Паттерн «Состояние» (State pattern) представляет иерархию классов состояний для обработки поведения состояний. Каждое состояние на диаграмме состояний имеет свой подкласс состояния. Контроллер имеет методы для каждого события, которые просто перенаправляют к классу состояния. Диаграмма состояний, показанная на рис. 10.1, могла бы быть реализована с помощью классов, представленных на рис. 10.7.

Диаграмма состояний UML - паттерн, реализующий диаграмму

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

Так, диаграмма на рис. 10.1 может быть представлена в виде табл. 10.1.
Затем мы строим интерпретатор, который использует таблицу состояний во время выполнения программы, или генератор кода, который порождает классы на основе этой таблицы.

Очевидно, большая часть работы над таблицей состояний проводится однажды, но затем ее можно использовать всякий раз, когда надо решить проблему, связанную с состояниями. Таблица состояний времени выполнения может быть модифицирована без перекомпиляции, что в некотором смысле удобно. Шаблон состояний собрать легче, и хотя для каждого состояния требуется отдельный класс, но размер кода, который при этом надо написать, совсем невелик.

Приведенные реализации практически минимальные, но они дают представление о том, как применять диаграммы состояний. В каждом случае реализация моделей состояний приводит к довольно стереотипной программе, поэтому обычно для этого лучше прибегнуть к тому или иному способу генерации кода.

Если вам понравилась статья - поделитесь ссылкой с друзьями!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Об авторе

Давиденко Сергей administrator

Оставить ответ