Конечный автомат UML

Общее введение см. в разделе «Диаграмма состояний» .

конечный автомат UML , ранее известная как диаграмма состояний UML , является расширением математической концепции конечного автомата в приложениях информатики , выраженной в нотации Unified Modeling Language (UML).

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

Конечный автомат UML — это объектно-ориентированный вариант диаграммы состояний Хареля . адаптирован и расширен с помощью UML. Целью конечных автоматов UML является преодоление основных ограничений традиционных конечных автоматов, сохраняя при этом их основные преимущества. Диаграммы состояний UML вводят новые концепции иерархически вложенных состояний и ортогональных областей , одновременно расширяя понятие действий . Конечные автоматы UML обладают характеристиками как автоматов Мили , так и автоматов Мура . Они поддерживают действия, которые зависят как от состояния системы, так и от запускающего события , как в машинах Мили, а также действия входа и выхода , которые связаны с состояниями, а не переходами, как в машинах Мура.

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

Основные понятия конечного автомата

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

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

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

Базовые диаграммы состояний UML

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

Рисунок 1. Диаграмма состояний UML, представляющая конечный автомат клавиатуры компьютера.

События

Событие – это то , что происходит и влияет на систему. Строго говоря, в спецификации UML термин «событие» относится к типу события, а не к какому-либо конкретному случаю этого события. Например, нажатие клавиши — это событие для клавиатуры, но каждое нажатие клавиши — это не событие, а конкретный экземпляр события нажатия клавиши. Еще одним событием, представляющим интерес для клавиатуры, может быть включение питания, но включение питания завтра в 10:05:36 будет всего лишь примером события включения.

Событие может иметь связанные параметры , позволяющие экземпляру события передавать не только возникновение некоторого интересного инцидента, но и количественную информацию об этом происшествии. Например, событие Keystroke, создаваемое нажатием клавиши на клавиатуре компьютера, имеет связанные параметры, которые передают код сканирования символов, а также состояние клавиш Shift, Ctrl и Alt.

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

Штаты

У каждого конечного автомата есть состояние , которое управляет реакцией конечного автомата на события. Например, когда вы нажимаете клавишу на клавиатуре, сгенерированный код символа будет либо прописным, либо строчным, в зависимости от того, активен ли Caps Lock. Таким образом, поведение клавиатуры можно разделить на два состояния: состояние «по умолчанию» и состояние «caps_locked». (Большинство клавиатур имеют светодиод, который указывает, что клавиатура находится в состоянии «caps_locked».) Поведение клавиатуры зависит только от определенных аспектов ее истории, а именно от того, была ли нажата клавиша Caps Lock, но не, например, от нажатия клавиши Caps Lock. от того, сколько и какие именно клавиши были нажаты ранее. Состояние может абстрагировать все возможные (но нерелевантные) последовательности событий и фиксировать только значимые.

В контексте программных конечных автоматов (и особенно классических автоматов) термин « состояние» часто понимается как одна переменная состояния , которая может принимать только ограниченное количество априорно определенных значений (например, два значения в случае клавиатуры или более). вообще — какая-то переменная с типом перечисления во многих языках программирования). Идея переменной состояния (и классической модели конечного автомата) заключается в том, что значение переменной состояния полностью определяет текущее состояние системы в любой момент времени. Концепция состояния сводит проблему идентификации контекста выполнения в коде к тестированию только переменной состояния вместо множества переменных, тем самым устраняя большую часть условной логики.

Расширенные состояния

Однако на практике интерпретация всего состояния конечного автомата как одной переменной состояния быстро становится непрактичной для всех конечных автоматов, за исключением очень простых. Действительно, даже если у нас есть одно 32-битное целое число в состоянии нашей машины, оно может способствовать более чем 4 миллиардам различных состояний — и приведет к преждевременному взрыву состояний . Такая интерпретация непрактична, поэтому в конечных автоматах UML все состояние конечного автомата обычно разделяется на (а) перечислимую переменную состояния и (б) все остальные переменные, которые называются расширенным состоянием . Другой способ увидеть это — интерпретировать перечислимую переменную состояния как качественный аспект, а расширенное состояние — как количественный аспект всего состояния. В этой интерпретации изменение переменной не всегда подразумевает изменение качественных аспектов поведения системы и, следовательно, не приводит к изменению состояния.

Конечные автоматы, дополненные расширенными переменными состояния , называются расширенными конечными автоматами , и конечные автоматы UML относятся к этой категории. Автоматы с расширенными состояниями могут применять базовый формализм для решения гораздо более сложных задач, чем это практически возможно без включения переменных расширенного состояния. Например, если нам нужно реализовать какое-то ограничение в нашем автомате (скажем, ограничить количество нажатий клавиш на клавиатуре до 1000), без расширенного состояния нам нужно будет создавать и обрабатывать 1000 состояний, что непрактично; однако с помощью расширенного конечного автомата мы можем ввести key_count переменная, которая инициализируется значением 1000 и уменьшается при каждом нажатии клавиши без изменения переменной состояния .

Рисунок 2: Расширенный конечный автомат «дешевой клавиатуры» с расширенной переменной состояния key_count и различными защитными условиями.

Диаграмма состояний на рисунке 2 является примером расширенного автомата состояний, в котором полное состояние системы (называемое расширенным состоянием ) представляет собой комбинацию качественного аспекта — переменной состояния — и количественных аспектов — состояния расширенных переменных . .

Очевидным преимуществом автоматов с расширенными состояниями является гибкость. Например, изменение предела, регулируемого key_count от 1000 до 10000 нажатий клавиш вообще не усложнит расширенный конечный автомат. Единственной необходимой модификацией будет изменение значения инициализации key_count расширенная переменная состояния во время инициализации.

Однако эта гибкость расширенных автоматов имеет свою цену из-за сложной связи между «качественными» и «количественными» аспектами расширенного состояния. Соединение происходит посредством защитных условий, связанных с переходами, как показано на рисунке 2.

Условия охраны

Условия защиты (или просто охранники) — это логические выражения , вычисляемые динамически на основе значений расширенных переменных состояния и параметров событий . Условия защиты влияют на поведение конечного автомата, разрешая действия или переходы только тогда, когда они оцениваются как TRUE, и отключая их, когда они оцениваются как FALSE. В нотации UML защитные условия показаны в квадратных скобках (например, [key_count == 0] на рисунке 2).

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

Действия и переходы

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

Переключение из одного состояния в другое называется переходом состояния , а событие, вызывающее его, называется событием-триггером или просто триггером . В примере с клавиатурой, если клавиатура находится в состоянии «по умолчанию» при нажатии клавиши CapsLock, клавиатура перейдет в состояние «caps_locked». Однако если клавиатура уже находится в состоянии «caps_locked», нажатие CapsLock вызовет другой переход — из состояния «caps_locked» в состояние «по умолчанию». В обоих случаях нажатие CapsLock является триггерным событием.

В машинах с расширенными состояниями переход может иметь защиту , что означает, что переход может «срабатывать» только в том случае, если защита оценивается как TRUE. Состояние может иметь множество переходов в ответ на один и тот же триггер, если они имеют непересекающиеся защитные меры; однако эта ситуация может создать проблемы в последовательности оценки средств защиты при возникновении общего триггера. Спецификация UML намеренно не оговаривает какой-либо конкретный порядок; скорее, UML возлагает на проектировщика бремя разработки средств защиты таким образом, чтобы порядок их оценки не имел значения. На практике это означает, что защитные выражения не должны иметь побочных эффектов, по крайней мере, таких, которые могли бы изменить оценку других охранников, имеющих тот же триггер.

Модель выполнения до завершения

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

В модели RTC система обрабатывает события дискретными, неделимыми шагами RTC. Новые входящие события не могут прерывать обработку текущего события и должны храниться (обычно в очереди событий ), пока конечный автомат снова не станет бездействующим. Эта семантика полностью позволяет избежать каких-либо внутренних проблем параллелизма внутри одного конечного автомата. Модель RTC также решает концептуальную проблему обработки действий, связанных с переходами, когда конечный автомат не находится в четко определенном состоянии (находится между двумя состояниями) на протяжении всего действия. Во время обработки событий система не отвечает (ненаблюдаема), поэтому нечеткое состояние в это время не имеет практического значения.

Однако обратите внимание, что RTC не означает, что конечный автомат должен монополизировать ЦП до тех пор, пока шаг RTC не будет завершен. Ограничение вытеснения применяется только к контексту задачи конечного автомата, который уже занят обработкой событий. В многозадачной среде могут выполняться другие задачи (не связанные с контекстом задач занятого конечного автомата), возможно, вытесняя текущий выполняющийся конечный автомат. Пока другие конечные автоматы не используют общие переменные или другие ресурсы друг с другом, опасности параллелизма не возникает .

Ключевым преимуществом обработки RTC является простота. Его самым большим недостатком является то, что скорость реагирования конечного автомата определяется его самым длинным шагом RTC. Достижение коротких шагов RTC часто может значительно усложнить проектирование в реальном времени.

UML-расширения традиционного формализма FSM

Хотя традиционные автоматы являются отличным инструментом для решения небольших задач, общеизвестно также, что они имеют тенденцию становиться неуправляемыми даже для систем средней сложности. Из-за явления, известного как взрыв состояний и переходов , сложность традиционного автомата имеет тенденцию расти намного быстрее, чем сложность системы, которую он описывает. Это происходит потому, что традиционный формализм государственной машины вызывает повторения. Например, если вы попытаетесь представить поведение простого карманного калькулятора с помощью традиционного автомата, вы сразу заметите, что многие события (например, нажатие кнопки «Очистить» или «Выключить») обрабатываются одинаково во многих состояниях. Обычный автомат, показанный на рисунке ниже, не имеет средств уловить такую ​​общность и требует повторения одних и тех же действий и переходов во многих состояниях. Чего не хватает в традиционных машинах состояний, так это механизма выделения общего поведения, чтобы разделить его на множество состояний.

Карманный калькулятор (слева) и традиционный конечный автомат с несколькими переходами «Очистить» и «Выключить» (справа).

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

Иерархически вложенные состояния

Самым важным нововведением конечных автоматов UML по сравнению с традиционными автоматами является введение иерархически вложенных состояний (именно поэтому диаграммы состояний также называются иерархическими конечными автоматами или HSM ). Семантика, связанная с вложенностью состояний, следующая (см. рисунок 3): Если система находится во вложенном состоянии, например «результат» (называемом подсостоянием ) , она также (неявно) находится в окружающем состоянии «включено» (называемом сверхдержава ) . Этот конечный автомат попытается обработать любое событие в контексте подсостояния, которое концептуально находится на нижнем уровне иерархии. Однако, если подсостояние «результат» не предписывает, как обрабатывать событие, событие не отбрасывается незаметно, как в традиционном «плоском» конечном автомате; скорее, оно автоматически обрабатывается в контексте более высокого уровня сверхсостояния «включено». Это то, что подразумевается под нахождением системы в состоянии «результат» и «включено». Конечно, вложенность состояний не ограничивается одним уровнем, и простое правило обработки событий рекурсивно применяется к любому уровню вложенности.

Рисунок 3. Карманный калькулятор (слева) и конечный автомат UML с вложенностью состояний (справа).

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

Поскольку внутренняя структура составного состояния может быть сколь угодно сложной, любой иерархический конечный автомат можно рассматривать как внутреннюю структуру некоторого составного состояния (более высокого уровня). Концептуально удобно определить одно составное состояние как основной корень иерархии конечных автоматов. В спецификации UML

у каждого конечного автомата есть регион (абстрактный корень каждой иерархии конечного автомата),

который содержит все остальные элементы всей конечной машины. Графическое отображение этой всеобъемлющей области не является обязательным.

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

Аспект государственной иерархии, на который чаще всего обращают внимание, — это абстракция — старый и мощный метод преодоления сложности. Вместо одновременного рассмотрения всех аспектов сложной системы часто можно игнорировать (абстрагировать) некоторые части системы. Иерархические состояния — идеальный механизм для сокрытия внутренних деталей, поскольку дизайнер может легко уменьшить или увеличить масштаб, чтобы скрыть или показать вложенные состояния.

Однако составные состояния не просто скрывают сложность; они также активно уменьшают его с помощью мощного механизма иерархической обработки событий. Без такого повторного использования даже умеренное увеличение сложности системы может привести к взрывному увеличению числа состояний и переходов. Например, иерархический конечный автомат, представляющий собой карманный калькулятор (рис. 3), избегает повторения переходов «Очистить» и «Выключить» практически в каждом состоянии. Избежание повторения позволяет росту HSM оставаться пропорциональным росту сложности системы. По мере роста моделируемой системы возможность повторного использования также увеличивается и, таким образом, потенциально противодействует непропорциональному увеличению числа состояний и переходов, типичному для традиционных автоматов.

Ортогональные области

Анализ путем иерархической декомпозиции состояний может включать применение операции «исключающее ИЛИ» к любому заданному состоянию. Например, если система находится в сверхсостоянии «включено» (рис. 3), возможно, она также находится либо в подсостоянии «операнд1», ИЛИ в подсостоянии «операнд2», ИЛИ в подсостоянии «opEntered», ИЛИ в «результате». подгосударство. Это привело бы к описанию «включенного» сверхсостояния как «ИЛИ-состояния».

Диаграммы состояний UML также вводят дополнительное И-разложение. Такое разложение означает, что составное состояние может содержать две или более ортогональные области (ортогональные в данном контексте означает совместимые и независимые) и что пребывание в таком составном состоянии влечет за собой пребывание во всех его ортогональных областях одновременно.

Ортогональные области решают частую проблему комбинаторного увеличения числа состояний, когда поведение системы фрагментируется на независимые, одновременно активные части. Например, помимо основной клавиатуры, клавиатура компьютера имеет независимую цифровую клавиатуру. Из предыдущего обсуждения вспомните два уже определенных состояния основной клавиатуры: «default» и «caps_locked» (см. рисунок 1). Цифровая клавиатура также может находиться в двух состояниях — «цифры» и «стрелки» — в зависимости от того, активен ли Num Lock. Таким образом, полное пространство состояний клавиатуры в стандартной декомпозиции представляет собой декартово произведение двух компонентов (основной клавиатуры и цифровой клавиатуры) и состоит из четырех состояний: «по умолчанию — цифры», «по умолчанию — стрелки», «caps_locked — числа, " и "caps_locked–стрелки." Однако это было бы неестественным представлением, поскольку поведение цифровой клавиатуры не зависит от состояния основной клавиатуры и наоборот. Использование ортогональных областей позволяет избежать смешивания независимых поведений в виде декартова произведения и вместо этого оставить их отдельными, как показано на рисунке 4.

Рисунок 4. Две ортогональные области (основная клавиатура и цифровая клавиатура) компьютерной клавиатуры.

Обратите внимание: если ортогональные области полностью независимы друг от друга, их совокупная сложность просто аддитивна, а это означает, что количество независимых состояний, необходимых для моделирования системы, представляет собой просто сумму k + l + m + ... , где k, l, m, ... обозначают количество ИЛИ-состояний в каждой ортогональной области. Однако общий случай взаимной зависимости, с другой стороны, приводит к мультипликативной сложности, поэтому в общем случае необходимое количество состояний равно произведению k × l × m × ... .

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

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

Действия при входе и выходе

Каждое состояние в диаграмме состояний UML может иметь дополнительные действия входа , которые выполняются при входе в состояние, а также необязательные действия выхода , которые выполняются при выходе из состояния. Действия входа и выхода связаны с состояниями, а не с переходами. Независимо от того, как происходит вход в состояние или выход из него, все его действия по входу и выходу будут выполнены. Из-за этой характеристики диаграммы состояний ведут себя как машины Мура . Нотация UML для действий входа и выхода из состояния заключается в размещении зарезервированного слова «вход» (или «выход») в состоянии прямо под отсеком имени, за которым следует косая черта и список произвольных действий (см. рисунок 5).

Рисунок 5. Конечный автомат тостера с действиями входа и выхода.

Ценность действий входа и выхода заключается в том, что они предоставляют средства гарантированной инициализации и очистки , очень похожие на конструкторы и деструкторы классов в объектно-ориентированном программировании . Например, рассмотрим состояние «door_open» на рисунке 5, которое соответствует поведению тостера, когда дверца открыта. Это состояние имеет очень важное требование с точки зрения безопасности: всегда отключать обогреватель, когда дверь открыта. Дополнительно, пока дверца открыта, должна гореть внутренняя лампа, освещающая духовку.

Конечно, такое поведение можно смоделировать, добавив соответствующие действия (отключение обогревателя и включение света) к каждому пути перехода, ведущему к состоянию «door_open» (пользователь может открыть дверцу в любой момент во время «выпекания» или «поджаривания» " или когда духовка вообще не используется). Не следует забывать гасить внутреннюю лампу при каждом переходе из состояния «дверь_открыта». Однако такое решение привело бы к повторению действий во многих переходах. Что еще более важно, такой подход делает проект подверженным ошибкам при последующих изменениях поведения (например, следующий программист, работающий над новой функцией, такой как подрумянивание верха, может просто забыть отключить нагреватель при переходе к «door_open»).

Действия входа и выхода позволяют реализовать желаемое поведение более безопасным, простым и интуитивно понятным способом. Как показано на рисунке 5, можно указать, что действие выхода из «нагревания» отключает нагреватель, действие входа «door_open» зажигает лампу духовки, а действие выхода из «door_open» гасит лампу. Использование действий входа и выхода предпочтительнее размещения действия на переходе, поскольку оно позволяет избежать повторяющегося кодирования и улучшает функциональность за счет устранения угрозы безопасности; (обогреватель включен при открытой двери). Семантика выходных действий гарантирует, что независимо от пути перехода нагреватель будет отключен, когда тостер не находится в состоянии «нагрев».

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

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

Внутренние переходы

Очень часто событие вызывает выполнение только некоторых внутренних действий, но не приводит к изменению состояния (переходу состояния). В этом случае все выполняемые действия составляют внутренний переход . Например, когда кто-то печатает на клавиатуре, он реагирует генерацией различных кодов символов. Однако до тех пор, пока не будет нажата клавиша Caps Lock, состояние клавиатуры не изменится (переход состояний не произойдет). В UML эту ситуацию следует моделировать с помощью внутренних переходов, как показано на рисунке 6. Обозначение внутренних переходов в UML соответствует общему синтаксису, используемому для действий выхода (или входа), за исключением того, что вместо слова вход (или выход) используется внутренний переход. помечен инициирующим событием (например, см. внутренний переход, инициируемый событием ANY_KEY, на рисунке 6).

Рисунок 6: UML-диаграмма состояний конечного автомата клавиатуры с внутренними переходами.

В отсутствие действий входа и выхода внутренние переходы были бы идентичны самопереходам (переходам, в которых целевое состояние совпадает с исходным состоянием). Фактически, в классической машине Мили действия связаны исключительно с переходами состояний, поэтому единственный способ выполнить действия без изменения состояния — через самопереход (изображенный в виде направленного цикла на рисунке 1 вверху этой статьи). Однако при наличии действий входа и выхода, как в диаграммах состояний UML, самопереход включает в себя выполнение действий выхода и выхода и, следовательно, он существенно отличается от внутреннего перехода.

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

Последовательность выполнения перехода

Вложенность состояний в сочетании с действиями входа и выхода значительно усложняет семантику перехода состояний в HSM по сравнению с традиционными FSM. При работе с иерархически вложенными состояниями и ортогональными областями простой термин « текущее состояние» может сбивать с толку. В HSM одновременно может быть активным более одного состояния. Если конечный автомат находится в листовом состоянии, которое содержится в составном состоянии (которое, возможно, содержится в составном состоянии более высокого уровня и т. д.), все составные состояния, которые прямо или транзитивно содержат листовое состояние, также активны. . Более того, поскольку некоторые из составных состояний в этой иерархии могут иметь ортогональные области, текущее активное состояние фактически представлено деревом состояний, начиная с одного региона в корне и заканчивая отдельными простыми состояниями на листьях. Спецификация UML называет такое дерево состояний конфигурацией состояний.

Рисунок 7. Роли состояний при переходе состояний

В UML переход между состояниями может напрямую соединять любые два состояния. Эти два состояния, которые могут быть составными, обозначены как основной источник и основная цель перехода. На рис. 7 показан простой пример перехода и поясняются роли состояний в этом переходе. Спецификация UML предписывает, что переход между состояниями включает выполнение действий в следующей предопределенной последовательности (см. раздел 14.2.3.9.6 унифицированного языка моделирования OMG (OMG UML). ):

1. Оцените условие защиты, связанное с переходом, и выполните следующие шаги, только если защита оценивается как TRUE.
2. Выйдите из конфигурации исходного состояния.
3. Выполните действия, связанные с переходом.
4. Введите конфигурацию целевого состояния.

Последовательность перехода легко интерпретировать в простом случае, когда основной источник и основная цель вложены на одном уровне. Например, переход T1, показанный на рисунке 7, вызывает оценку защиты g(); далее следует последовательность действий: a(); b(); t(); c(); d(); и e(); если предположить, что охранник g() оценивается как ИСТИНА.

Однако в общем случае исходного и целевого состояний, вложенных на разные уровни иерархии состояний, может быть не сразу очевидно, из скольких уровней вложенности необходимо выйти. Спецификация UML предписывает, что переход включает в себя выход из всех вложенных состояний из текущего активного состояния (которое может быть прямым или транзитивным подсостоянием основного исходного состояния) до состояния наименьшего общего предка (LCA) основного источника и основного состояния , но не включая его. целевые состояния. Как следует из названия, LCA — это низшее составное состояние, которое одновременно является сверхсостоянием (предком) как исходного, так и целевого состояний. Как описано ранее, порядок выполнения действий выхода всегда от самого глубоко вложенного состояния (текущего активного состояния) вверх по иерархии до LCA, но без выхода из LCA. Например, LCA(s1,s2) состояний «s1» и «s2», показанный на рисунке 7, — это состояние «s».

Вход в конфигурацию целевого состояния начинается с уровня, на котором завершились действия по выходу (т. е. изнутри LCA). Как описано ранее, действия входа должны выполняться, начиная с состояния самого высокого уровня вниз по иерархии состояний к основному целевому состоянию. Если основное целевое состояние является составным, семантика UML предписывает рекурсивно «детализировать» его подмашину, используя локальные начальные переходы. Конфигурация целевого состояния полностью вводится только после обнаружения конечного состояния, не имеющего начальных переходов.

Локальные и внешние переходы

До UML 2 единственной используемой семантикой перехода был внешний переход , при котором всегда происходит выход из основного источника перехода и всегда вводится основная цель перехода. UML 2 сохранил семантику «внешнего перехода» для обратной совместимости, но также представил новый вид перехода, называемый локальным переходом (см. раздел 14.2.3.4.4 унифицированного языка моделирования (UML)). ). Для многих топологий переходов внешние и локальные переходы фактически идентичны. Однако локальный переход не вызывает выхода из основного исходного состояния и повторного входа в него, если основное целевое состояние является подсостоянием основного источника. Кроме того, переход локального состояния не приводит к выходу из основного целевого состояния и повторному входу в него, если основная цель является суперсостоянием основного исходного состояния.

Рисунок 8: Локальные (а) и внешние переходы (б).

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

Отсрочка мероприятия

Иногда событие приходит в особенно неудобное время, когда конечный автомат находится в состоянии, которое не может обработать событие. Во многих случаях природа события такова, что его можно отложить (в определенных пределах) до тех пор, пока система не перейдет в другое состояние, в котором она лучше подготовлена ​​к обработке исходного события.

Конечные автоматы UML предоставляют специальный механизм для отсрочки событий в состояниях. В каждом штате вы можете включить пункт [event list]/defer. Если происходит событие в списке отложенных событий текущего состояния, событие будет сохранено (отложено) для будущей обработки до тех пор, пока не будет введено состояние, в котором это событие не указано в списке отложенных событий. При входе в такое состояние конечный автомат UML автоматически вызывает любые сохраненные события, которые больше не откладываются, а затем либо использует, либо отбрасывает эти события. В суперсостоянии может быть определен переход для события, которое отложено подсостоянием. Как и в других областях спецификации конечных автоматов UML, подсостояние имеет приоритет над надсостоянием, событие будет отложено, а переход в суперсостояние не будет выполнен. В случае ортогональных регионов, где один ортогональный регион откладывает событие, а другой потребляет событие, потребитель имеет приоритет, и событие потребляется, а не откладывается.

Ограничения конечных автоматов UML

Диаграммы состояний Хареля, являющиеся предшественниками конечных автоматов UML, были изобретены как «визуальный формализм для сложных систем». поэтому с момента своего создания они были неразрывно связаны с графическим представлением в виде диаграмм состояний. Однако важно понимать, что концепция конечного автомата UML выходит за рамки любых конкретных обозначений, графических или текстовых. Спецификация UML делает это различие очевидным, четко отделяя семантику конечного автомата от обозначений.

Однако обозначение диаграмм состояний UML не является чисто визуальным. Любой нетривиальный конечный автомат требует большого количества текстовой информации (например, спецификации действий и мер защиты). Точный синтаксис выражений действия и защиты не определен в спецификации UML, поэтому многие люди используют либо структурированный английский, либо, более формально, выражения на языке реализации, таком как C , C++ или Java . На практике это означает, что нотация диаграммы состояний UML сильно зависит от конкретного языка программирования .

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

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

Внешние ссылки

• Единый язык моделирования 2.5.1 . Официальный номер документа OMG /05.12.2017. Организация по разработке стандартов группы управления объектами (OMG SDO). Декабрь 2017.

• Диаграммы конечных автоматов UML 2