UML 状态图中的转换：更好地使用触发器或守卫？答案

【问题标题】：Transitions in UML state charts: better to use triggers or guards?UML 状态图中的转换：更好地使用触发器或守卫？
【发布时间】：2023-03-23 20:00:01
【问题描述】：

在 UML 状态图的设计中，我似乎可以选择使用 triggers 或 guard 逻辑来实现状态之间的转换。

那么哪个更好用？给定相同的转换逻辑，触发器的行为与守卫有什么不同吗？一个比另一个有什么好处/缺点？

是否可能存在差异取决于特定工具，或者 UML 标准是否严格定义了任何一种转换方法的行为？

我目前正在使用 Simulink Stateflow 来设计状态机。

【问题讨论】：

【解决方案1】：

这两个是不同的概念。

Trigger 是一个 event 事件，它启用了转换，而 guard 是一个条件，必须将其评估为 true 才能进行转换。

所以你不能互换使用它们——它们有不同的作用。

另请注意，默认保护（如果未指定）是[true]，因此触发器通常足以从一种状态移动到另一种状态。

更新：

总结：

触发器（事件）是其他参与者触发的外部事件 - 用户按下按钮，浏览器请求页面加载等。因此在上图中，每次用户按下数字锁上的数字时，它都会触发“按下数字”事件。

如果 pin（数字序列）有效，则将启用到 unlocked 状态的转换。

另一种看待它的方式：

如果您按下键盘键，系统会触发keypress event，这将是一个触发器，其值为按下的键。然后你可以做一个守卫[pressedKey = enter]（守卫总是一个布尔表达式）。

但是这里只有守卫是不够的，因为没有什么可以比较的。

【讨论】：

我只是看到名称和术语，但最终动作或结果似乎是相同的，使用警卫或触发器没有什么不同。如果我将表达式 $x$ 放在守卫中，并使用相同的数据、逻辑、事件或任何您想给它的名称驱动它为真或假，这给我的结果与驱动具有相同的触发器的结果相同。过渡要么发生，要么不发生。目前还不清楚为什么会这样。
与另一个可能不同。您能否提供一个更具体的例子来说明结果或行动方面的差异？
@docscience 我更新了答案，现在可能更清楚了。
触发器决定是否尝试转换，然后守卫将确定是否可以进行转换。如果没有事件触发它，则永远不会进行转换。仅当事件（触发器）指示可以进行转换时，才会评估转换的保护。
我玩了一些类似的状态图，一个只使用警卫和输入数据来控制转换，另一个只使用触发器来控制转换。有了警卫，我总是可以在状态之间进行可预测的过渡。有了触发器，我得到了过渡——有时。但是触发因素是非常不可预测的。就像图表并不总是看到它们一样。一个区别是触发器需要指定上升沿、下降沿、两者或函数调用。我一直在使用上升沿。我想我还是不明白触发器。

【解决方案2】：

严格来说，没有触发器就不能使用守卫。

UML 2.5.1 specification（第 14.2.4.8 节，第 331 页）通过以下 BNF expression 定义状态机的转换：

[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]

虽然 UML 2.0 将它们定义为：

<transition> ::= <trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <activity-expression>]

触发器定义为：

<trigger> ::= <call-event> | <signal-event> | <any-receive-event> | <time-event> | <change-event>

因此，在这两种情况下，都不能使用没有任何触发器的守卫进行转换。

根据 UML 2.5.1，唯一的例外是 内部转换，由以下各项指定：

{<trigger>}* ['[' <guard>']'] [/<behavior-expression>]

【讨论】：