UML状态机

有关一般介绍，请参见状态图。

UML状态机，也称为UML Statechart ，是计算机科学应用程序中有限自动机的数学概念的扩展，如统一建模语言（UML）符号所示。

其背后的概念是关于组织设备，计算机程序或其他（通常是技术）的过程的工作方式，以使实体或其每个子本地始终处于许多可能的状态之一，并且有很好的状态这些状态之间定义的条件过渡。

UML状态机是Harel Statechart的基于对象的变体，由UML改编和扩展。 UML国家机器的目标是克服传统有限国家机器的主要局限性，同时保留其主要收益。 UML Statecharts介绍了层次嵌套状态和正交区域的新概念，同时扩展了动作的概念。 UML状态机具有Mealy机器和Moore机器的特性。他们支持依赖于系统状态和触发事件的动作，例如在Mealy机器中，以及与摩尔计算机一样与状态而不是过渡相关的进入和退出操作。

术语“ UML状态机”可以参考两种状态机：行为状态机和协议状态计算机。行为状态计算机可用于建模单个实体（例如，类实例），子系统，软件包甚至整个系统的行为。协议状态计算机用于表示使用协议，可用于指定分类器，接口和端口的法律用法方案。

基本状态机概念

许多软件系统都是事件驱动的，这意味着他们不断等待某些外部或内部事件的发生，例如单击鼠标，按钮按下，时间tick或数据包的到来。识别事件后，此类系统通过执行适当的计算来做出反应，该计算可能包括操纵硬件或生成触发其他内部软件组件的“软”事件。 （这就是为什么事件驱动的系统被称为反应系统。）事件处理完成后，系统将返回到下一个事件。

对事件的响应通常取决于事件的类型和系统的内部状态，并且可以包括导致​​状态过渡的状态更改。这些状态之间事件，状态和状态过渡的模式可以抽象并表示为有限状态机器（FSM）。

FSM的概念在事件驱动的编程中很重要，因为它使事件处理明确依赖于事件类型和系统状态。正确使用后，状态机可以通过代码大幅度缩小执行路径的数量，简化每个分支点测试的条件，并简化不同执行模式之间的切换。相反，使用事件驱动的编程无基础FSM模型可以使程序员产生容易出错，难以扩展和过度复杂的应用程序代码。

基本UML状态图

UML保留了传统状态图的一般形式。 UML状态图是定向图，其中节点表示状态和连接器表示状态过渡。例如，图1显示了与计算机键盘状态计算机相对应的UML状态图。在UML中，状态表示为标有状态名称的圆形矩形。表示为箭头的过渡标记为触发事件，然后选择执行操作列表。初始过渡起源于实体圆，并指定系统首次开始时的默认状态。每个状态图都应具有这样的过渡，因为它不是由事件触发的，因此不应标记。最初的过渡可以具有关联的动作。

图1：代表计算机键盘状态计算机的UML状态图

事件

事件是影响系统的事情。严格来说，在UML规范中，事件一词是指发生的类型，而不是发生这种情况的任何具体实例。例如，击键是键盘的事件，但是键的每条按下不是事件，而是键盘事件的具体实例。键盘感兴趣的另一个事件可能是电动的，但是明天在10:05:36扭转电源将只是电动事件的一个实例。

事件可以具有关联的参数，使事件实例不仅传达了一些有趣的事件的发生，还可以传达有关此事件的定量信息。例如，通过在计算机键盘上按键来生成的击键事件具有关联的参数，该参数传达了字符扫描代码以及Shift，CTRL和Alt键的状态。

事件实例超出了产生它的瞬时事件，并可能将这种情况传达给一个或多个状态机器。生成后，事件实例将经历一个处理生命周期，该生命周期最多包含三个阶段。首先，当事件实例被接受并等待处理时收到（例如，将其放置在事件队列上）。后来，将事件实例派往状态机，此时它将成为当前事件。最后，当状态机完成处理事件实例时，它将被消耗。消耗的事件实例不再可用于处理。

状态

每个状态机都有一个状态，该状态控制状态机对事件的反应。例如，当您在键盘上键入键时，生成的字符代码将是大写或小写字符，具体取决于帽子锁是否处于活动状态。因此，键盘的行为可以分为两种状态：“默认”状态和“ caps_locked”状态。 （大多数键盘都包含一个指示键盘在“ caps_locked”状态中的LED。）键盘的行为仅取决于其历史记录的某些方面，即是否已按下Caps Lock键，但不在关于以前按下哪些其他钥匙的数量以及确切的数量。一个状态可以抽象所有可能（但无关）的事件序列，并仅捕获相关事件序列。

在软件状态机器（尤其是经典FSM）的上下文中，通常将术语状态理解为单个状态变量，该变量只能假设有限数量的先验确定值（例如，两个键盘中的两个值，或更多的值通常 - 某种变量具有许多编程语言的枚举类型）。状态变量（和经典FSM模型）的想法是，状态变量的值在任何给定时间都完全定义了系统的当前状态。状态的概念减少了识别代码中的执行上下文的问题，仅测试状态变量而不是许多变量，从而消除了许多条件逻辑。

扩展国家

但是，实际上，将状态机的整个状态解释为单个状态变量，对于所有更简单的机器以外的所有状态机器，所有状态机都会很快变得不切实际。确实，即使我们在机器状态中有一个32位的整数，它也可能导致超过40亿个不同的州 - 并将导致过早的状态爆炸。这种解释是不切实际的，因此在UML状态机中，状态机的整个状态通常分为（a）枚举状态变量，以及（b）所有其他命名为扩展状态的变量。看到它的另一种方法是将枚举状态变量解释为定性方面，并将状态扩展为整个状态的定量方面。在这种解释中，变量的变化并不总是意味着系统行为的定性方面的变化，因此不会导致状态变化。

补充扩展状态变量的州机器称为扩展状态机，UML状态机属于此类别。扩展的状态机器可以将潜在的形式主义应用于比不包括扩展状态变量的情况下更为复杂的问题。例如，如果我们必须在FSM中实现某种限制（例如，将键盘上的击键数量限制为1000），而无需扩展状态，则我们需要创建和处理1000个状态 - 这是不切实际的；但是，使用扩展的状态机，我们可以引入一个key_count变量，该变量初始化为1000，并由每个击键降低而不会更改状态变量。

图2：带有扩展状态变量键的“便宜键盘”的扩展状态机器和各种防护条件

图2中的状态图是扩展状态机的一个示例，其中系统的完整条件（称为扩展状态）是定性方面的组合（状态变量- 定量方面） -扩展状态变量。

扩展状态机的明显优势是灵活性。例如，将key_count调节的限制从1000更改为10000键，这根本不会使扩展状态机器复杂化。所需的唯一修改是在初始化过程中更改key_count扩展状态变量的初始化值。

但是，扩展状态机器的这种灵活性是有代价的，但是由于“定性”和扩展状态的“定量”方面之间的复杂耦合。耦合通过附着在过渡上的后卫条件发生，如图2所示。

后卫条件

后卫条件（或简单的后卫）是根据扩展状态变量和事件参数的值动态评估的布尔表达式。只有在评估false时，才能在评估true并将其禁用时，才能通过启用行动或过渡来影响状态机器的行为。在UML符号中，防护条件在方括号中显示（例如，图2中的[key_count == 0] ）。

对后卫的需求是将内存扩展状态变量添加到状态机形式主义中的直接结果。很少使用的扩展状态变量和警卫构成了可以简化设计的强大机制。另一方面，很容易滥用扩展的州和守卫。

行动和过渡

派遣事件实例时，状态计算机会通过执行操作（例如更改变量，执行I/O，调用函数，生成另一个事件实例或更改为另一个状态）来做出响应。与当前事件关联的任何参数值都可以直接可用于该事件引起的所有操作。

从一个状态切换到另一种状态称为状态过渡，导致其称为触发事件的事件，或简单地触发事件。在键盘示例中，如果按下Capslock键时键盘在“默认”状态中，则键盘将输入“ caps_locked”状态。但是，如果键盘已经处于“ caps_locked”状态，则按Capslock将导致不同的过渡 - 从“ caps_locked”到“默认”状态。在这两种情况下，按Capslock都是触发事件。

在扩展的状态机器中，过渡可以具有后卫，这意味着只有当后卫评估为真时，过渡才能“开火”。只要有非重叠的守卫，一个国家就可以对同一触发器进行许多转变。但是，这种情况可能会在发生共同触发器时在守卫的评估顺序中造成问题。 UML规范故意不规定任何特定的顺序；相反，UML承担了设计师的负担，以使他们的评估顺序无关紧要。实际上，这意味着后卫表情不应具有没有副作用，至少没有任何会改变对具有相同触发的警卫的评估。

运行到完成执行模型

所有状态机器形式主义（包括UML状态机器）都普遍认为状态机可以在每个事件开始处理下一个事件之前完成处理每个事件的处理。该执行模型称为“运行到完成”或RTC。

在RTC模型中，系统以离散的，不可分割的RTC步骤处理事件。新的传入事件不能中断当前事件的处理，必须存储（通常在事件队列中），直到状态机再次闲置为止。这些语义完全避免了单个状态机器内的任何内部并发问题。 RTC模型还解决了与过渡相关的处理操作的概念问题，在该操作期间，状态机机器不处于定义明确的状态（在两个状态之间）。在事件处理过程中，该系统无反应（无法观察到），因此在此期间定义不明的状态没有实际意义。

但是请注意，RTC并不意味着状态机必须在RTC步骤完成之前垄断CPU。抢先限制仅适用于已经忙于处理事件的状态计算机的任务上下文。在多任务环境中，可以运行其他任务（与繁忙状态机的任务上下文无关），可能会抢占当前执行的状态计算机。只要其他州机器不共享变量或其他资源，就没有并发危害。

RTC处理的主要优点是简单性。它最大的缺点是状态机的响应能力取决于其最长的RTC步骤。实现简短的RTC步骤通常会显著使实时设计复杂化。

向传统FSM形式主义扩展

尽管传统的FSM是解决较小问题的绝佳工具，但通常也众所周知，即使对于中度参与的系统，它们也倾向于变得难以管理。由于被称为状态和过渡爆炸的现象，传统FSM的复杂性往往比其描述的系统的复杂性快得多。发生这种情况是因为传统的国家形式主义会造成重复。例如，如果您尝试用传统的FSM来表示简单的口袋计算器的行为，您会立即注意到许多州（例如，清除或关闭按钮按下）在许多州都相同处理。下图中显示的常规FSM，无需捕获这种共同点，需要在许多州重复相同的动作和过渡。传统状态机器中缺少的是为了在许多州分享共同行为的机制。

袖珍计算器（左）和传统状态机，具有多个过渡清晰的过渡（右）

UML状态机正好解决了常规FSM的这一缺点。它们提供了许多功能来消除重复，因此UML状态机的复杂性不再爆炸，而是倾向于忠实地代表其描述的反应性系统的复杂性。显然，这些功能对于软件开发人员来说非常有趣，因为只有它们使整个状态机方法真正适用于现实生活中的问题。

层次嵌套状态

UML状态机器对传统FSM的最重要创新是引入层次嵌套状态（这就是为什么Statecharts也称为层次结构机器或HSM S）。与状态嵌套相关的语义如下（请参见图3）：如果系统处于嵌套状态，例如“结果”（称为替代），则它（隐式）在周围状态中“ on”（称为“称为”）迷信）。该状态机将尝试在替代的上下文中处理任何事件，从概念上讲，该事件位于层次结构的较低层。但是，如果取代“结果”没有规定如何处理事件，则该事件不会像传统的“平坦”状态机中悄悄丢弃；相反，它会自动在“ On”超级遗产的更高层次上下文中处理。这就是系统处于状态“结果”和“ on”的含义。当然，状态嵌套不限于一个级别，事件处理的简单规则递归适用于任何层次的嵌套。

图3：袖珍计算器（左）和带状态嵌套的UML状态机（右）

包含其他状态的状态称为复合状态；相反，没有内部结构的状态称为简单状态。当嵌套状态不包含任何其他状态时，称为直接替代；否则，它被称为固定嵌套的替代。

由于复合状态的内部结构可以任意复杂，因此任何分层态机器都可以视为某些（高级）复合状态的内部结构。从概念上讲，将一个复合状态定义为状态机层次结构的最终根源很方便。在UML规范中，每个状态计算机都有一个最高状态（每个状态机层次结构的抽像根），其中包含整个状态机的所有其他元素。此全包顶状态的图形渲染是可选的。

如您所见，层次状态分解的语义旨在促进行为的重复使用。取代（嵌套状态）只需要定义与超级遗产（包含状态）的差异。替代可以通过简单地忽略常见的事件来轻松地从其超级遗产中继承共同行为，然后这些事件会自动由高级状态自动处理。换句话说，分层状态嵌套可以通过差异编程。

最常强调的国家等级制度的方面是抽象- 一种应对复杂性的古老而有力的技术。与其同时解决复杂系统的所有方面，不如忽略（抽象）系统的某些部分。层次状态是隐藏内部细节的理想机制，因为设计师可以轻松放大或放大以隐藏或显示嵌套状态。

但是，复合状态并不简单地隐藏复杂性。他们还通过层次事件处理的强大机制积极减少它。没有这样的重用，即使系统复杂性的适度增加也可能导致状态和过渡的数量爆炸性增加。例如，代表口袋计算器的分层状态机（图3）避免在几乎每个状态下重复清晰的过渡。避免重复允许HSM的增长与系统复杂性的增长成正比。随着建模系统的增长，重复使用的机会也增加了，因此有可能抵消传统FSM典型的状态和过渡的不成比例增加。

正交区域

通过层次状态分解分析可以包括将“独家或”操作应用于任何给定状态。例如，如果系统在“ On”超级遗产中（图3），则可能是在“ operand1”替代或“ permand2”替代或“ opentered”替代或“替代”或“结果”或“结果”中的情况。取代。这将导致将“ On”超级遗产描述为“或状态”。

UML Statecharts还引入了互补和分类。这种分解意味着复合状态可以包含两个或多个正交区域（正交表示在这种情况下兼容和独立），并且处于这种综合状态，则需要同时在其所有正交区域中。

正交区域解决了系统的行为分散成独立的，同时活跃的部分时，状态数量的常见问题。例如，除了主要键盘外，计算机键盘具有独立的数字键盘。从上一个讨论中，回顾已经确定的主要键盘的两个状态：“默认”和“ caps_locked”（见图1）。数字键盘也可以在两个状态下：“数字”和“箭头” - 努力努力是否处于活动状态。因此，标准分解中键盘的完整状态空间是两个组件的笛卡尔产物（主要键盘和数字键盘），由四个状态组成：“默认值- 名称”，“默认值”，“ default -arrows”， “ caps_locked – locked – lumbers，numbers，numbers，numbers，numbers，numbers，numbers，” “和“ caps_locked – Arrows。”但是，这将是不自然的表示，因为数字键盘的行为不取决于主键盘的状态，反之亦然。正交区域的使用允许避免独立行为作为笛卡尔产物的混合，而使它们保持分开，如图4所示。

图4：计算机键盘的两个正交区域（主要键盘和数字键盘）

请注意，如果正交区域完全独立于彼此，则它们的组合复杂性仅是加性的，这意味着建模系统所需的独立状态数仅为总和k + l + m + ... ，其中k，其中k， l，m，...表示每个正交区域中的或状态数量。但是，另一方面，相互依赖性的一般情况会导致乘法复杂性，因此通常，所需状态的数量是乘积K×L×M×...。

在大多数现实生活中，正交区域仅是正交的（即不是真正独立的）。因此，UML Statecharts为正交区域提供了多种方式交流和同步其行为。在这些丰富的（有时复杂）机制的集合中，也许最重要的特征是正交区域可以通过将事件实例彼此发送来协调其行为。

尽管正交区域意味着执行的独立性（允许或多或少的并发），但UML规范并不要求将单独的执行线分配给每个正交区域（尽管可以根据需要进行）。实际上，最常见的是，正交区域在同一线程中执行。 UML规范仅要求设计人员不依赖任何特定顺序将事件实例派往相关的正交区域。

进入和退出行动

UML StateChart中的每个州都可以在进入状态时执行可选的输入措施，以及可选的退出诉讼，这些措施将在退出状态时执行。进入和退出措施与状态相关联，而不是过渡。无论国家如何进入或退出状态，其所有进入和退出诉讼都将被执行。由于这种特征，Statecharts的行为就像摩尔机器。状态输入和退出操作的UML表示法是将保留的单词“输入”（或“退出”）放在名称隔间下方的状态，然后是向前斜线和任意操作的列表（见图5）。

图5：带入口和退出操作的烤箱烤箱状态机

进入和退出操作的价值在于，它们提供了用于保证初始化和清理的手段，非常类似于以对象为导向的编程中的类构造函数和破坏者。例如，考虑图5中的“ door_open”状态，该状态对应于门打开时的烤面包烤箱行为。该状态具有非常重要的安全性要求：门打开时始终禁用加热器。此外，在门打开时，内部灯照亮了烤箱。

当然，可以通过添加适当的动作（禁用加热器并打开光线）来建立此类行为“或者根本不使用烤箱时）。在每次过渡时都会熄灭内部灯，就不会忘记。但是，这种解决方案会导致许多过渡中的行动重复。更重要的是，这种方法在随后的行为修订过程中容易出错（例如，下一个从事新功能的程序员，例如顶式棕色功能，可能会忘记在过渡到“ door_open”时禁用加热器）。

进入和退出操作允许以更安全，更简单，更直观的方式实施所需的行为。如图5所示，可以指定“加热”的退出动作禁用加热器，“ door_open”的入口操作点亮了烤箱灯，而“ door_open”的退出动作熄灭了灯。进入和退出操作的使用比在过渡上进行动作更可取，因为它可以避免重复编码并通过消除安全危害来改善功能； （门打开时加热器）。退出动作的语义可确保，无论过渡路径如何，当烤面包机不在“加热”状态时，加热器将被禁用。

因为每当输入关联的状态时，就会自动执行输入操作，因此他们通常会确定操作条件或状态的身份，就像类构造函数确定要构造对象的身份一样。例如，“加热”状态的身份取决于打开加热器的事实。在输入“加热”的任何替代之前，必须建立这种情况，因为将动作的输入动作取代了“加热”，例如“敬酒”，依靠“加热”超级遗产的适当初始化，仅执行与此初始化的差异。因此，执行入境操作的顺序必须始终从最外面的状态到达最内向的状态（自上而下）。

毫不奇怪，此顺序类似于调用类构造函数的顺序。班级的构造总是从类层次结构的根源开始，并遵循所有继承级别，直到正在实例化的类。与Destructor Invocation相对应的退出操作的执行以确切的反向顺序（自下而上）进行。

内部过渡

通常，事件仅导致某些内部动作执行，但不会导致状态变化（国家过渡）。在这种情况下，执行的所有操作均包括内部过渡。例如，当键盘上的一种类型时，它通过生成不同的字符代码做出响应。但是，除非按下上限锁定键，否则键盘的状态不会更改（没有发生状态过渡）。在UML中，应以内部过渡为模型，如图6所示。内部过渡的UML符号遵循用于退出（或条目）操作的一般语法，除非而不是单词条目（或退出）内部过渡用触发事件标记（例如，请参阅图6中的Any_key事件触发的内部过渡）。

图6：具有内部过渡的键盘状态机的UML状态图

在没有进入和退出行动的情况下，内部过渡将与自我转变相同（目标状态与源状态相同的过渡）。实际上，在经典的Mealy机器中，操作仅与状态过渡仅相关联，因此执行动作而无需改变状态的唯一方法是通过自我转变（从本文的顶部描述为图1中的定向循环）。但是，在进入和退出行动的情况下，就像在UML Statecharts中一样，自我转变涉及执行退出和入境操作，因此它与内部过渡截然不同。

与自我转变相反，即使内部过渡是从层次结构较高的层次上继承的，也没有执行任何进入或退出措施，即从任何层次的嵌套行为中继承的内部过渡就像直接在当前活跃状态下定义的那样。

过渡执行序列

与传统FSM相比，状态嵌套与进入和退出动作相比，HSMS中的状态过渡语义的复杂化显著复杂。在处理层次嵌套的状态和正交区域时，简单的术语当前状态可能会令人困惑。在HSM中，多个状态可以一次活跃。如果状态机处于叶状态，该叶状态包含在复合状态（可能包含在更高级别的复合状态，等等），则所有直接或传统含有叶子状态的复合状态也有效。此外，由于该层次结构中的某些复合状态可能具有正交区域，因此当前的活动状态实际上是由一个状态树表示，从根部的单个顶部状态开始，直到叶子处的单个简单状态。 UML规范指的是状态树作为状态配置。

图7：状态过渡中的状态角色

在UML中，国家过渡可以直接连接任何两个状态。这两个状态可能是复合的，被指定为过渡的主要来源和主要目标。图7显示了一个简单的过渡示例，并解释了该过渡中的状态角色。 UML规范规定了进行状态过渡的规定涉及在以下序列中执行以下操作（请参阅OMG统一建模语言（OMG UML）第15.3.14节，基础结构版本2.2 ）：

  1. 评估与过渡相关的后卫条件，并仅在警卫评估为true时执行以下步骤。
  2. 退出源状态配置。
  3. 执行与过渡相关的操作。
  4. 输入目标状态配置。

在主源和主要目标嵌套的简单情况下，过渡序列易于解释。例如，图7所示的过渡T1导致对后卫G（）的评估；然后是一系列动作： a(); b(); t(); c(); d();和e() ;假设后卫g()评估为真。

但是，在嵌套在状态层次结构层面的不同级别的一般情况下，可能并不明显需要退出多少层次。 UML规范规定了一个过渡涉及从当前的活动状态（可能是主要源状态的直接或及时替代）退出所有嵌套状态，但不包括，主要祖先（LCA）的主要状态来源和主要目标状态。顾名思义，LCA是最低的复合状态，它同时是源和目标状态的超级遗产（祖先）。如前所述，执行退出动作的顺序始终是从最深层嵌套的状态（当前的活动状态）到LCA的层次结构，但没有退出LCA。例如，图7中显示的状态“ S1”和“ S2”的LCA（S1，S2）是状态“ s”。

输入目标状态配置是从离开操作的级别开始的（即从LCA内部）。如前所述，必须从从最高级别的状态开始执行进入行动，从沿状态层次结构到主要目标状态。如果主要目标状态是综合状态，则使用局部初始过渡将UML语义规定为“钻入”的平均冲平。目标状态配置仅在遇到没有初始过渡的叶状态后才完全输入。

本地与外部过渡

在UML 2之前，使用的唯一过渡语义是外部过渡，其中始终会退出过渡的主要来源，并且始终输入过渡的主要目标。 UML 2保留了向后兼容性的“外部过渡”语义，但也引入了一种称为本地过渡的新型过渡（请参阅第15.3.15节中的统一建模语言（UML），基础结构版本2.2 ）。对于许多过渡拓扑，外部和局部过渡实际上是相同的。但是，如果主要目标状态是主要源的替代，则本地过渡不会导致退出并重新进入主要源状态。此外，如果主要目标是主要源状态的超级巨星，则当地状态过渡不会导致退出并重新进入主要目标状态。

图8：本地（a）与外部过渡（b）。

图8对比局部（A）和外部（B）过渡。在第一行中，您会看到包含主要目标的主源的情况。局部过渡不会导致源头退出，而外部过渡会导致退出并重新进入来源。在图8的底部行中，您会看到包含主源的主目标的情况。局部过渡不会导致目标进入，而外部过渡会导致退出并重新进入目标。

事件延期

有时，当状态机处于无法处理事件的状态时，事件会出现特别不便的时间。在许多情况下，事件的性质使得可以推迟（在限制内），直到系统进入另一个状态为止，在该状态下，它可以更好地准备处理原始事件。

UML状态机提供了一种特殊的机制来推迟州的事件。在每个州，您都可以包括一个子句[event list]/defer 。如果发生当前状态的延期事件列表中的事件，则将为将来处理（延期）保存该事件，直到输入未在其延期事件列表中列出事件的状态为止。进入这样的状态后，UML状态机将自动回忆起不再延期的任何已保存事件，然后消耗或丢弃这些事件。超级巨星有可能在被取代的事件上定义过渡。与UML状态机规范中的其他区域一致，取代优先于超级Sterstate，该事件将被延期，并且无法执行超级Sterstate的过渡。如果一个正交区域对事件进行防御并消耗事件的正交区域，则消费者优先考虑，并且该事件被消费且不推迟。

UML状态机的局限性

Harel Statecharts是UML状态机器的前体，已被发明为“复杂系统的视觉形式”，因此，从他们的启动开始，它们以状态图的形式与图形表示密不可分。但是，重要的是要了解，UML状态机的概念超越了任何特定的符号图形或文本。 UML规范可以通过将状态机语义与符号明确分开，从而显而易见。

但是，UML Statecharts的符号并不是纯粹的视觉效果。任何非平凡的状态机都需要大量文本信息（例如，操作和警卫的规范）。在UML规范中未定义动作和后卫表达式的确切语法，因此许多人使用结构化的英语或更正式的表达方式，例如C ， C ++或Java 。实际上，这意味着UML Statechart符号在很大程度上取决于特定的编程语言。

然而，大多数Statecharts语义都大大偏向图形符号。例如，状态图代表处理的顺序，无论是评估警卫的顺序还是向正交区域派遣事件的顺序。 UML规范通过在设计师身上承担不依赖任何特定测序来避免这些问题。但是，在实际实施UML状态机器时，不可避免地会完全控制执行顺序，从而引起批评，即可能不必要地限制了UML语义。同样，Statechart图需要大量的管道齿轮（如连接，叉子，连接，选择点等）以图形方式表示控制流程。换句话说，与普通的结构化代码相比，图形符号的这些元素在表示控制流程中并没有增加太多价值。

UML符号和语义确实针对计算机化的UML工具。工具中表示的UML状态计算机不仅是状态图，而且是图形和文本表示的混合物，可以精确地捕获状态拓扑和动作。该工具的用户可以从视觉和文本中获得同一台机器的几个互补视图，而生成的代码只是许多可用视图之一。