UML状态机:深度历史伪状态和最终状态
在UML状态机中，如果输入子状态的最终状态，复合状态的历史会发生什么？
考虑下面所示的状态机。在触发序列T1-T2-T3-T4之后，它将进入最终状态。通过进入最终状态，State21区域的历史将被清除，并且由于该区域也由此完成，所以将执行到State1的完成转换。现在，当启用触发器T5时，状态机进入深度历史状态。我假设在这种情况下，深层历史状态表示State21，这意味着状态机进入State21，然后执行从State21的初始伪状态到State211的转换。这是正确的吗？
我更喜欢上面描述的行为，但我可以看到另一种选择，即当输入State2中的最终状态时，也会清除State21的历史。在这种情况下，状态机执行从State2的初始伪状态到State22的转换。你怎么看？
回答 2
Stack Overflow用户
发布于 2018-05-02 09:19:23
从我对deepHistory描述的理解
这种类型的伪状态是一种变量，它表示其所属区域的最近的活动状态配置。如上所述，在这个伪状态上终止的转换意味着将区域恢复到相同的状态配置，但是使用的所有语义进入一个状态(参见描述状态条目的子子句)。
你的第一次行为描述似乎是好的。通过trigerring T1、T2、T3、T4和T5转换，您将返回State21条目，即State211。
Stack Overflow用户
发布于 2020-09-01 21:59:58
我阅读此图表的方式如下：
在State1中，您可以通过调用T1 (这是一个新序列)或通过T2 (前一个序列的重试)进入State2。
当应用程序/系统在State1中时，其中似乎有逻辑允许在某些情况下重新尝试以前的State2序列。因此，深厚的历史将这些进程变量保持在父状态中，直到State1能够决定它想要以哪种方式进行。
然而，在示例状态机模型中存在歧义：
- 返回到State1的转换没有命名/编号，并且
- 还没有定义需要深厚历史的中间部分完整的状态。该模型需要一个退出状态/条件，该退出状态/条件定义为State21中的子状态，作为此未命名的转换回State1的源。
State21中的当前流只有一个结束状态，因此每次都运行到完成状态。只有当您需要在给定的子状态位置重新进入一个状态时，深厚的历史才有意义。
https://stackoverflow.com/questions/50099794
复制相似问题
腾讯云开发者
