Войти
Конечный автомат UML, также известный как диаграмма состояний UML, улучшенная реализация математической <7199>конечного автомата в компьютерных приложений, как выражено в унифицированном языке моделирования (UML) нотация.
Концепции, лежащие в основе этого, касаются организации устройства работы, компьютерной программы или другого (часто технического) процесса таким образом, чтобы объект или каждый из его суб-объектов всегда находился ровно в одном из источников состояния и где есть четко условные переходы между этими состояниями.
Конечный автомат UML представляет собой объектно-ориентированный вариант диаграммы состояния Харела, адаптированный и расширенный с помощью UML., Цель UML - преодолеть ограничение конечных автоматов , сохранив их конечные преимущества. Диаграммы состояний UML вводят новые концепции иерархически вложенных состояний и ортогональных областей, одновременно расширяя понятие действий. Конечные автоматы UML имеют характеристики как машин Мили, так и машин Мура. Они содержат действия, которые зависят от состояний, так и отрующего события, как в машинех Мили, а также действия входа и выхода, с состояниями, а не с переходами, как в машинах Мура.
Термин «конечный автомат UML» может относиться к двум типам конечных автоматов: поведенческим конечным автоматам и конечным автоматам протокола. Поведенческие конечные автоматы друг относительно друга к личным сообщениям (например, экземпляры классов). Конечные автоматы языка используются для обозначения языковых языков.
Реакция на событие обычно зависит как от типа события, так и от внутреннего состояниясистемы и может изменить состояние, ведущее к переход состояния . Шаблон событий, состояний и переходов между этими состояниями может быть абстрагирован и представлен в виде конечного автомата (FSM).
Концепция конечного автомата важна в программировании, управляемом событиями, потому что он делает обработку событий явно зависимой как от типа события, так и от состояния системы. При правильном использовании конечный автомат может значительно сократить количество путей выполнения, упростить условия, проверяемые в каждой точке ветвления, и упростить переключение между различными режимами выполнения. И наоборот, происходит запуск программы, без использования модели конечного автомата.
UML поддерживает общую диаграмм состояний. Диаграммы состояний UML - это ориентированные графы, в которых отмечаются обозначаемые состояния, соединители обозначают переходы между состояниями. Например, на изображении представлена диаграмма состояния UML, соответствующая конечному автомату компьютерной клавиатуры. В UML состоянии представленных в виде закругленных состояний. Переходы, представленные в виде стрелок, помечены запускающими событиями, за которые, при необходимости, следует список выполненных действий. Начальный переход исходит из сплошного круга и указывает состояние по умолчанию при первом запуске системы. Каждая диаграмма состояния должна иметь такой переход, который не следует маркировать, поскольку он не запускается событие. Первоначальный переход может иметь связанные действия.
Рисунок 1: Диаграмма состояний UML, представляющая конечный автомат компьютерной клавиатуры Событие - это то, что происходит, влияет на систему. Строго говоря, в спецификации UML относится термин «событие» к типу событий, а не к конкретному экземпляру этого события. Например, являются неотъемлемыми частями клавиатуры, конкретными экземплярами отдельных клавишами. Другим интересным событием для клавиатуры может быть включение питания, но включение питания завтра в 10:05:36 будет всего лишь экземпляром события Power-on.
С событием могут быть связаны параметры, позволяющие вызвать событие не возникновение некоторого интересного инцидента, также количественную информацию, касающуюся этого события. Например, событие Нажатие клавиш, запускается нажатием клавиш на клавиатуре компьютера, это действие, которое передают символы, а также состояние клавиш Shift, Ctrl и Alt.
Экземпляр события переживает мгновенное событие, вызвавшее его, и может передать это событие одному или нескольким конечным автоматам. После создания экземпляра события проходит жизненный цикл обработки, который может состоять из трех этапов. Во-первых, экземпляр события получен, когда он принят и ожидает обработку (например, он помещается в очередь событий ). Позже экземпляр события отправляется в конечный автомат, после чего он становится текущим событием. Наконец, он потребляется, когда конечный автомат завершает обработку экземпляра события. Использованный экземпляр события больше не доступен для обработки.
Каждый конечный автомат имеет состояние, которое управляет реакцией конечного автомата на события. Например, когда вы нажимаете на клавиатуру, сгенерированный код будет либо прописным, строчным, в зависимости от того, активен ли Caps Lock. Таким образом, поведение клавиатуры можно разделить на два состояния: состояние «по умолчанию» и состояние «caps_locked». (На большинстве клавиатур есть светодиод, который указывает, что клавиатура находится в состоянии «caps_locked».) Поведение клавиатуры зависит только от конкретной ее истории, и именно от того, была ли нажата клавиша Caps Lock, но не, например, сколько и какие другие другие другие клавиши были нажаты ранее. Состояние может абстрагироваться от всех (но не относящихся к делу) последовательностей событий и захватывать только релевантные.
В контексте программных конечных автоматов (и особенно классических автоматов) термин часто понимается как единственное переменное состояние, которое может принимать только ограниченное число заранее определенных значений (например, два значения в случае клавиатуры или, в более общем смысле, какой -то тип перечисления во многих языках программирования). Идея модели состояния (и классической модели конечного автомата) заключается в том, что значение измененного состояния полностью определяет текущее состояние системы в любой момент времени. Концепция сводит проблему идентификации контекста кода к тестированию стандартных состояний вместо многих чисел, тем самым тестяя много условной логики.
Практика выполнения всего состояния становится конечного автомата как одного состояния непрактичной для всех конечных автоматов, кроме очень простых очень простых. В самом деле, даже если у нас есть одно 32-битное целое число в нашем машинном состоянии, оно может быть более чем 4 миллиардов различных состояний - и приведет к преждевременному взрыву состояний. Эта интерпретация непрактична, поэтому в конечных автоматах UML все состояние конечного автомата обычно разделяется на (а) перечисляемую переменную состояния и (б) все другие переменные, которые называются расширенным состоянием. Другой способ увидеть это - интерпретировать перечислимую переменную состояние как качественный аспект, а расширенное состояние как количественные аспекты всего состояния. В этой интерпретации изменений не всегда означает изменение качественных характеристик системы и, следовательно, не приводит к изменению состояния.
Конечные автоматы, дополненные переменными расширенного состояния, называются машины с расширенными состояниями и машины UML к этой категории. Автоматические с расширенными состояниями Автоматическая базовая формализм к более сложным задачам, чем это возможно без включения расширенного состояния. Например, если нам нужно реализовать какое-то ограничение в нашем автомате (скажем, ограниченное количество клавиш на клавиатуре до 1000), нам нужно создать и обработать 1000 состояний - что непрактично; однако с расширенным конечным автоматом мы можем ввести переменную key_count, которая инициализируется до 1000 и происходит при каждом использовании без изменения состояния.
Рисунок 2: Расширенный конечный автомат «дешевой клавиатуры» с расширенным числом и различных защитных условий Диаграмма состояний на рисунке 2 является примером расширенного конечного автомата, в котором полное состояние системы (называется расширенным состоянием) представляет собой комбинацию качественного - состояния - и количественных - расширенных состояний.
Очевидным преимуществом расширенных конечных автоматов является гибкость. Например, изменение предела, определяемого key_countс 1000 до 10000 различных клавиш, вообще не усложнитенный расширенный конечный автомат. Единственная необходимая модификация - это изменение параметров инициализации расширенного альтернативного состояния key_countво время инициализации.
Эта гибкость автоматов расширенного состояния, однако имеет свою цену из-за сложной связи между «качественными» и «количественными» факторами расширенного состояния. Связь происходит через защитные условия, прикрепленные к переходам, как показано на рисунке 2.
Защитные условия (или просто охранные) - это логические выражения, вычисляемые динамически на основе по значению расширенных значений состояния и параметров события. Условия защиты влияют на поведение конечного автомата, разрешают действие или переходы, когда они оцениваются как ИСТИНА, и отключаются их, когда они оцениваются как ЛОЖЬ. Вотации защитные условия UML отображается в квадратных скобках (например, [key_count == 0]на рисунке 2).
Необходимость в защитном процессе немедленным следствием добавления памяти расширенная форма численного состояния в защитном процессе конечного автомата. При умеренном использовании расширенные переменные состояния и средства защиты мощный механизм, упрощающий механизм. С другой стороны, довольно легко можно использовать расширенные состояниями и охранниками.
Когда отправляется экземпляр события, конечный автомат отвечает, выполняя действия, такие как изменение вариантов, выполнение ввода-вывода, вызов функции, создание другого экземпляра события или переход в другое состояние. Любые значения параметров, связанные с текущим событием, доступны для всех событий, непосредственно вызванных этим событием.
Переключение из одного состояния в другое называется переходом между состояниями, событие, которое вызывает его, называется запускающим событием или просто триггером . В примере с клавиатурой, если клавиатура находится в состоянии «по умолчанию» при нажатии клавиши CapsLock, клавиатура перейдет в состояние «caps_locked». Однако, если клавиатура уже находится в состоянии «caps_locked», вызовет CapsLock другой переход - из состояния «caps_locked» в состояние «по умолчанию». В обоих случаях CapsLock является запускающим событием.
В машинах с расширенными состояниями переход может иметь охранник, что означает, что переход может «зарабатывать», только если защита оценивается как ИСТИНА. Состояние может иметь много переходов в ответ на один и тот же триггер, если у них есть неперекрывающиеся; однако такая ситуация может создать проблемы в настройке охранников при срабатывании обычного триггера. Спецификация UML намеренно не предусматривает какого-либо конкретного порядка; скорее, UML возлагает на проектировщика бремя разработки таких средств защиты, при которых порядок их оценки не имеет значения. Практически это означает, что выражения защиты не имеют побочных эффектов, по крайней мере, таких, которые повлияли бы на оценку других средств защиты, имеющую тот же триггер.
Все формализмы конечного автомата, включая конечные автоматы UML, повсеместно предполагают, что конечный автомат завершает обработку каждого события, прежде чем он сможет начать обработку следующего события. Эта модель выполнения называется до завершения или RTC.
В модели RTC система обрабатывает события дискретными, неделимыми шагами RTC. Новые входящие события не могут прервать текущие события и должны храниться (обычно в очереди событий ) до тех пор, пока конечный автомат снова не станет бездействующим. Эта семантика полностью исключает любые внутренние проблемы параллелизма в одном конечном автомата. Модель RTC также позволяет обойти концептуальную проблему обработки действий, связанных с переходами, когда конечный автомат не находится в четко определенном состоянии (находится между двумя состояниями) в течение действия. Во время обработки событий система не отвечает (ненаблюдаемая), поэтому неопределенное состояние в течение этого времени не имеет практического значения.
Обратите внимание, однако, что RTC не означает, что конечный автомат должен монополизировать ЦП до завершения этапа RTC. Ограничение вытеснения имеет только к контексту задачи конечного автомата, который уже занят обработкой событий. В среде многозадачности могут быть другие задачи (не связанные с контекстом задачи конечного автомата занятости), возможно, вытесняя выполняющийся в данный момент конечный автомат. Пока другие конечные автоматы не используют общие переменные или другие ресурсы друг с другом, не существует опасностей параллелизма.
Ключевым преимуществом обработки является RTC простота. Его самый большой недостаток заключается в том, что скорость отклика конечного автомата определяет его самым длинным шагом RTC. Достижение коротких шагов RTC часто может значительно усложнить проектирование в реальном времени.
Хотя традиционные конечные автоматы являются отличным инструментом для решения небольших проблем, в том числе общеизвестно, что они становятся неуправляемыми, даже для систем средней сложности. Из-за явления, известного как взрыв состояний и переходов, сложность традиционного конечного автомата имеет тенденцию расти намного быстрее, чем сложность системы, которую он указало. Это происходит потому, что эта формализм конечного автомата вызывает повторы. Например, если вы попробуете представить поведение простого карманного калькулятора с помощью традиционного конечного автомата, вы сразу заметите многие события (например, эффекты Clear или Off) во многих состояниях обрабатываются одинаково. Обычный автомат, показанный на рисунке, не имеет средств улавливания такой общности и требует повторения одних и тех же действий и переходов во многих состояниях. Чего не хватает традиционным конечным автоматом, чтобы использовать его во многих состояниях.
Карманный калькулятор (слева) и конечный автомат с переходами Очистить и выключить (справа) Конечный автомат UML устраняет именно этот недостаток обычных автоматов. Они предоставлены функции для исключения повторений, так что сложность конечного автомата UML больше не увеличена, а стремится точно отражать сложность реактивной системы, которую он указан. Эти функции очень интересны подход к программному обеспечению, потому что они делают в целом с конечным автоматом действительно применимы к реальным проблемам.
Самым важным нововведением конечных автоматов UML по сравнению с традиционными конечными автоматами введение иерархически вложенных состояний (вот почему диаграммы состояний также называются иерархическими конечными автоматами или HSM s). Семантика, связанная с вложением состояний, следующая (см. Рисунок 3): Если система находится во вложенном состоянии, например «результат» (называемый подсостоянием ), она также (неявно) находится в окружающем состоянии «включено» ( так называемое супергосударство ). Этот конечный автомат будет пытаться обработать любое событие в контексте подсостояния, которое концептуально находится на нижнем уровне иерархии. Однако, если подсостояние «результат» не предписывает, как обрабатывать событие, событие не отбрасывается незаметно, как в традиционном «плоском» конечном автомате; скорее, это автоматически обрабатывается на более высоком уровне контекста сверхсостояния «включено». Это означает, что система находится как в состоянии «результат», так и в состоянии «включен». Уровень не ограничивается одним уровнем, и простое правило обработки событий рекурсивно к любому уровню вложенности.
Рисунок 3. Карманный калькулятор (слева) и конечный автомат UML с вложением состояния (справа). Состояния, другие состояния, называются составными состояниями; наоборот, состояния без внутренней структуры называются простыми состояниями. Вложенное состояние называется подсостоянием, если оно не содержится в каком-либо другом состоянии; в случае это называется транзитивно вложенным подсостоянием.
Внутренняя структура составного состояния может быть произвольно сложная, любой иерархический конечный автомат можно рассматривать как внутреннюю часть (более высокого) составного состояния. Концептуально удобно определить одно составное состояние как конечный корень иерархии конечного автомата. В спецификации UML каждый конечный автомат имеет верхнее состояние (абстрактный корень каждой иерархии конечного автомата), которое содержит все остальные элементы конечного автомата. Графическое отображение этого всеобъемлющего верхнего состояния необязательно.
Как видите, семантика иерархической декомпозиции положения для облегчения повторного использования поведения. Подсостояния (вложенные состояния) должны определять отличия от суперсостояния (вложенные состояния). Подсостояние может легко унаследовать общее поведение от своего суперсостояния, просто игнорируемое поведение обычно обрабатываются событиями более высокого уровня. Другими словами, иерархическое вложение состояния позволяет .
наиболее часто используемым аспектом иерархии состояний абстракция - старый и мощный метод преодоления сложности. Вместо того, чтобы рассматривать все аспекты сложной системы одновременно, часто можно игнорировать (абстрагироваться) некоторые системы. Иерархические состояния - идеальный механизм для сокрытия внутренних деталей, потому что дизайнер может легко уменьшить или увеличить масштаб, чтобы скрыть или показать вложенные состояния.
Однако составные состояния не просто скрывают сложность; они также активно сокращают его с помощью мощного механизма иерархической обработки событий. Без такого повторного использования даже умеренного увеличения сложности системы могло бы привести к взрывному увеличению числа состояний и переходов. Например, иерархический конечный автомат, представляющий карманный калькулятор (рис. 3), избегает повторения переходов Clear и Off практически в каждом состоянии. Избегание повторения позволяет рост HSM поддерживать рост системы сложности. Увеличение масштабов числа состояний и переходов, типичных для автоматов увеличения противодействует непропорциональному увеличению числа состояний и переходов.
Анализ иерархической декомпозиции включительно в применение операции «исключающее ИЛИ» к любому заданному состоянию. Например, если система находится в подсостоянии «on» (рисунок 3), это может быть случай, когда она также находится либо в подсостоянии «operand1», либо в подсостоянии «operand2» ИЛИ в подсостоянии «opEntered» ИЛИ в «result» подсостоянии. Это привело бы к описанию «включенной» сверхдержавы как «состояния-ИЛИ».
Диаграммы состояний UML вводят дополнительное И-разложение. Такое разложение означает, что составное состояние может содержать две формы или более ортогональные области (в таком составном состоянии совместимые иые), и что нахождение в составном состоянии влечет за собой нахождение во всех его ортогональных областях одновременно.
Адрес ортогональных областей частая проблема комбинаторного увеличения числа показателей, когда системы поведения фрагментировано на одновременные активные части. Например, клавиатура компьютерная клавиатура имеет независимую цифровую клавиатуру. Из предыдущего обсуждения вспомните два уже определенных состояния основной клавиатуры: «по умолчанию» и «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.” Однако такое решение может вызвать повторение во многих переходах. ошибкам во время поправок к поведению (например, следующий программист, работающий над новой функцией, такой как потемнение сверху, может просто забыть отключить нагреватель при переходе к "door_open").
Действия входа и выхода позволяют реализовать желаемое поведение более Как показано на рисунке 5, можно указать, что действие из «обогрева» отключает нагреватель, действие входа «door_o». ручка »включает лампу духовки, действие выхода из« door_open »гасит лампу. Использование действий входа и выхода предпочтительнее, чем оно позволяет избежать повторяющегося кодирования и функции, устраняя угрозу безопасности; (обогреватель включен при открытой двери). Семантика гарантирует действия, независимо от выхода нагреватель будет отключен, когда тостер не находится в состоянии «нагреватель».
>Временные действия входа выполняются автоматически всякий раз, когда происходит переход в связанное состояние, они часто определяют условия работы или идентичности состояния, так же, как конструктор класса идентичности создаваемого объекта. Например, идентичность состояния «нагрев» означает тем, что нагреватель включен. Это условие должно быть установлено перед входом в любое подсостояние «нагрев», потому что действия входа в подсостояние «нагрев», например, «поджаривание», основаны на правильной инициализации суперсостояния «нагрев» и только отличия от этой инициализации. Следовательно, порядок выполнения действий входа всегда должен идти от самого внешнего состояния к самому внутреннему состоянию (сверху вниз).
Неудивительно, что этот порядок аналогичен порядку, в котором вызываются конструкторы классов. Построение класса всегда начинается с самого корня иерархии классов. Выполнение выхода действий, соответствующий вызову деструктора, происходит в точном обратном порядке (снизу вверх).
Очень часто событие вызывает только некоторые внутренние состояния, но не приводит к изменению состояний (переходу). В этом случае все выполняемые действия составляют внутренний переход . Например, когда кто-то печатает на клавиатуре, он отвечает, генерируя разные коды символов. Однако, пока не будет нажата клавиша Caps Lock, состояние клавиатуры не изменится (переход между состояниями не произойдет). В UML эту ситуацию следует моделировать с помощью внутренних переходов, как показано на рисунке 6. Нотация UML для внутренних переходов соответствует общему синтаксису, используемому для действий выхода (или входа), за исключением того, что вместо слова вход (или выход) внутренний переход помечен запускающим событием (например, см. внутренний переход, запускаемым ANY_KEY на рисунке 6).
Рисунок 6. Диаграмма состояний UML конечного автомата клавиатуры с внутренними переходами Отсутствие действий входа и выхода внутренние переходы были бы идентичны самопереходам (переходам, в которых наступает состояние такое же, как исходное состояние). Фактически, в классической машине Мили связаны исключительно с переходами между состояниями, поэтому единственный способ выполнить действия без изменений состояния - это самопереход (изображенный как направленный цикл на рис. Начало статьи). Однако при наличии действий входа и выхода, как в диаграммах состояний UML, самопереход включает в себя выполнение действий выхода и входа, и поэтому он заметно отличается от внутреннего перехода.
В отличие от самоперехода, действия входа или выхода не выполняются в результате внутреннего перехода, даже если внутренний переход унаследован от более высокого уровня иерархии, чем текущее активное состояние. Внутренние переходы, унаследованные от суперсостояния на любом уровне вложенности, каковы они были в текущем активном состоянии.
Вложение состояний в сочетании с действиями входа и выхода значительно усложняет семантику перехода состояний в HSM по сравнению с традиционными автоматами. Имея дело с иерархически вложенными состояниями и ортогональными областями, простой термин «сбивать с толку» может сбивать с толку. В HSM может быть одновременно активным более одного состояния. Если конечное автоматическое состояние находится в конечном состоянии, которое, возможно, содержится в составном состоянии более высокого уровня и т. Д.), Все составные состояния, которые либо прямо, либо транзитивно содержат конечное состояние, также активны.. Более того, поскольку некоторые из составных состояний в этой иерархии могут иметь ортогональные области, текущее активное состояние фактически представлено деревом состояний, начиная с единственного верхнего состояния в корне и заканчивая отдельными простыми состояниями в листьях. В спецификации UML такое дерево состояний называется конфигурацией состояний.
Рисунок 7: Роли состояний при переходе между состояниями В UML переход между состояниями может напрямую связывать любые два состояния. Эти два состояния, которые могут быть составными, обозначаются как основной источник и основная цель перехода. На рисунке 7 показан простой пример перехода и поясняются роли состояний в этом переходе. Спецификация UML предписывает, что переход между состояниями включает в себя выполнение следующих действий в следующей последовательности (см. Раздел 15.3.14 в OMG Unified Modeling Language (OMG UML), Infrastructure Version 2.2):
Последовательность перехода легко интерпретировать в простом случае, когда основной источник и основная цель находятся на одном уровне. Например, переход T1, показанный на рисунке 7, вызывает оценку защиты g (); после чего следует последовательность действий: a (); б (); t (); c (); d ();и e (); предполагая, что охранник g ()оценивается как ИСТИНА.
Однако в общем случае исходных и целевых состояний, вложенных на разных уровнях иерархии состояний, может быть не сразу очевидно, из скольких уровней вложенности необходимо выйти. Спецификация UML предписывает, что переход включает в себя выход из всех вложенных состояний из текущего активного состояния (которое может быть прямым или транзитивным подсостоянием основного исходного состояния) до, но не включая, наименее общего предка ( LCA) состояния основного источника и основного целевого состояния. Как видно из названия, LCA - это самое низкое составное состояние, которое одновременно является суперсостоянием (предком) как исходного, так и целевого состояний. Как описано ранее, порядок выполнения действий выхода всегда от самого глубоко вложенного состояния (текущего активного состояния) вверх по иерархии до LCA, но без выхода из LCA. Например, LCA (s1, s2) состояния «s1» и «s2», показанная на фиг. 7, является состоянием «s».
Ввод конфигурации целевого состояния начинается с уровня, на котором завершились действия выхода (т. Е. Изнутри LCA). Как описано ранее, действия входа должны быть, начиная с состояния самого высокого уровня вниз по иерархии состояний до основного целевого состояния. Если основное целевое состояние является составным, семантика UML предписывает рекурсивно «углубляться» в его вспомогательную машину с использованием локальных начальных переходов. Конфигурация целевого состояния полностью вводится только после обнаружения конечного состояния, в котором нет начального перехода.
До UML 2 использовалась единственная семантика перехода внешний переход, в котором из основного источника перехода всегда выходили, а всегда вводится основная цель перехода. UML 2 сохранил семантику «внешнего перехода» для обратной совместимости, но представил также новый вид перехода, названный локальным переходом (см. Раздел 15.3.15 в Unified Modeling Language (UML), Infrastructure Version 2.2). Для многих топологий переходов внешние и локальные переходы фактически идентичны. Однако локальный переход не вызывает выхода из основного исходного состояния и повторного входа в систему. Кроме того, локального состояния не вызывает выхода из основного целевого состояния и повторного входа в него, если основная цель является суперсостоянием основного состояния.
Рисунок 8: Локальные (a) и внешние переходы (b). На рисунке 8 показаны контрасты между локальными (a) и внешними (b) переходами. В верхнем ряду вы видите случай основного источника, содержащего основную цель. Локальный переход не вызывает выхода из источника, в то время как внешний переход вызывает выход и повторный вход в источник. В нижнем ряду рисунка 8 вы видите случай, когда основная цель содержит основной источник. Локальный переход не вызывает входа в цель, тогда как внешний переход вызывает выход и повторный вход в цель.
Иногда событие наступает в особенно неудобное время, когда конечный автомат находится в состоянии, которое не может обработать событие. Во многих случаях характерные события таков, что его можно отложить (в определенных пределах) до тех пор, пока система не перейдет в другое состояние, в котором она лучше подготовлена к обработке исходного события.
Конечные автоматы UML специальный механизм для откладывания событий в состояниях. В каждом состоянии вы можете включить предложение [список событий] / отложить. Если происходит событие в списке отложенных событий текущего состояния, оно будет сохранено (отложено) для будущей обработки до тех пор, пока не будет введено состояние, в котором событие не перечислено в его списке отложенных событий. При входе в такое состояние конечный автомат UML автоматически вызывает сохраненные события, которые больше не откладываются, или отбрасывает эти события. В суперсостоянии может быть определен переход для события, которое откладывается подсостоянием. В соответствии с указанными указаниями конечных автоматов UML имеет приоритет над предыдущими автоматами, которые будут выполнены. В случае ортогональной области, где одна ортогональная область откладывает событие, а другое потребляет событие, потребитель имеет приоритет, и событие потребляется, а не откладывается.
диаграммы состояний, являющиеся предшественниками конечных автоматов UML, были изобретены как «визуальные формы для сложных систем», поэтому самого начала они неразрывно связаны с графическим представлением в виде диаграмм состояний. Однако важно понимать, что концепция конечного автомата UML выходит за рамки любых обозначений, графических или текстовых. Спецификация UML делает это различие очевидным, четко отделяя семантику конечного автомата от нотации.
Однако нотация диаграмм состояний UML не является чисто визуальной. Любой нетривиальный конечный автомат требует большого количества текстовой информации (например, указаны действия и средств защиты). Точный синтаксис действий и защитных выражений не определен в UML, поэтому многие люди используют либо структурированный английский язык, либо более формально, выражения на языке реализации, такой как C, C ++ или Java. На практике это означает, что нотация диаграммы состояний UML сильно зависит от конкретного языка программирования.
Тем не менее, большая часть семантики состояний сильно смещена в сторону графической нотации. Например, диаграммы состояния плохо последовательность обработки, то порядок оценки охранников или порядок отправки событий в ортогональные области. Спецификация UML обходит эти проблемы, возлагая на проектировщика бремя полагаться на какую-либо конкретную последовательность. Однако бывает так, что когда конечные автоматы UML фактически реализованы, неизбежно имеется полный контроль над порядком выполнения, что вызывает критику в том, что семантика UML может быть излишне ограничивающей. Точно так же диаграммы состояний требуют большого количества вспомогательного оборудования (псевдосостояния, таких как соединения, соединения, точки выбора и т. Д.). Другими словами, эти элементы графической нотации не добавляют особой ценности при представлении потока управления по основному структурированным кодом.
Нотация и семантика UML действительно ориентированы на компьютеризированные инструменты UML. Конечный автомат UML, представленный в инструменте, - это не просто диаграмма состояний, а смесь графического и текстового представления, которая точно фиксирует как топологию состояний, так и действия. Пользователи могут получить несколько дополнительных представлений одного и того же конечного автомата, как визуального, так и текстового, в то время как сгенерированный код лишь одним из множества доступных представлений.
