UML 状态机：深度历史伪状态和最终状态答案

【问题标题】：UML State Machines: Deep History Pseudostate and Final StateUML 状态机：深度历史伪状态和最终状态
【发布时间】：2018-10-10 12:09:17
【问题描述】：

在 UML 状态机中，如果进入子状态的最终状态，复合状态的历史究竟会发生什么？

考虑如下所示的状态机。在触发序列 T1-T2-T3-T4 之后，它将最终处于最终状态。通过进入最终状态，State21 区域的历史被清除，并且由于该区域也由此完成，因此将执行到 State1 的完成转换。现在，当触发器 T5 启用时，状态机进入深度历史状态。我假设在这种情况下，深度历史状态代表 State21，这意味着状态机进入 State21，然后执行从 State21 的初始伪状态到 State211 的转换。这是正确的吗？

我更喜欢上面描述的行为，但我可以看到另一种选择，其中当进入 State21 的最终状态时，State2 的历史记录也会被清除。在这种情况下，状态机执行从 State2 的初始伪状态到 State22 的转换。那你怎么看？

【问题讨论】：

您的第一个解释对您的图表是正确的。要清除，State2 需要在其中包含 FinalState 以及从 State21 到此 FinalState 的完成转换，以及从 State2 到 State1 的完成转换。在这种情况下，第二种解释是正确的。

标签： uml state-machine

【解决方案1】：

从我对deepHistory描述的理解

这种类型的伪状态是一种变量，代表其所属区域的最近的活动状态配置。如上所述，在此伪状态上终止的转换意味着将区域恢复到相同的状态配置，但具有进入状态的所有语义（参见描述状态进入的子条款）。

您的第一个行为描述似乎很好。通过触发 T1、T2、T3、T4 和 T5 转换，您将返回到 State21 条目，即 State211。

【讨论】：

【解决方案2】：

我是这样阅读这张图的：

在 State1 中，您可以通过调用 T1（这是一个新序列）或通过 T2（前一个序列的重试）进入 State2。

当应用程序/系统处于 State1 时，它似乎具有允许在某些情况下重试先前的 State2 序列的逻辑。由于如此深厚的历史，这些过程变量一直保持在父状态中，直到 State1 可以决定它想要继续的方式。

但是示例状态机模型中存在歧义：

返回到 State1 的转换没有命名/编号，并且
尚未定义需要深入历史的中间部分完整状态。该模型需要一个退出状态/标准，定义为 State21 中的一个子状态，作为此未命名转换回 State1 的源。

State21 中的当前流只有一个结束状态，因此每次都运行到完成。只有当您需要在给定的子状态位置重新进入状态时，深度历史才有意义。

【讨论】：