UML 2.x 状态机中延迟事件的正确顺序

Question

UML 2.x 的状态机图支持延迟事件。 这是状态机。

当我按顺序发送 e1、e2、e3、e4 到 sm1 时，预期的状态是什么？如果e1从defer队列中出队，并再次入队到s2中的defer队列，并且消耗e2过渡到s3，那么defer队列的头是s3中的e3，因此期望状态是s5。但是，如果 e1 保持原始位置（头）并跳过它，则 e2 被消耗，预期状态为 s4。

UML 2.x 规范是否定义了哪个是正确的？

Answer 1

感谢评论，我得到了答案。

推迟事件位置

我在状态机图中使用了

defer queue

这个词，但是UML 2.5.1（最新）规范中没有这个概念。

查看网站： https://www.omg.org/spec/UML/About-UML/

文件： 正式-17-12-05.pdf

UML 2.5.1 定义

event pool

。

在

14.2.3.4.4 State history

，

--开始报价

延期活动

一个州可以指定一组可以在该州推迟的事件类型。这意味着只要该状态保持活动状态，就不会调度这些类型的事件发生。相反，这些事件发生保留在事件池中，直到：

• 达到状态配置，这些事件类型不再延迟，或者，
• 如果在源是延迟状态的转换的触发器中显式使用延迟事件类型（即一种覆盖选项）。

事件可能会被复合状态或子机状态推迟，在这种情况下，只要复合状态保持在活动配置中，事件就会保持推迟状态。

--引用结束

重要的一点是“相反，这些事件发生保留在事件池中直到”。 remain这个词意味着保持事件池中的原始位置。

活动评估顺序

事件池中的事件是有顺序的。

请参阅网站：https://www.omg.org/spec/PSSM/About-PSSM/

文件：ptc-17-04-04.pdf

9.3.16.2 Deferred 001

,

RTC Steps

Step7 表示事件评估顺序为 head("old") to tail("young")。

结论

事件池中的事件评估顺序是从头到尾。推迟的事件只是保持原来的位置。因此，在我的图中，

e1

应该在

s3

处进行评估。

注意

Boost.MSM（版本 1.68.0）实现不正确。 https://wandbox.org/permlink/v5hRtdJXRek8RidW

我会报告相关问题。

Answer 2

花了一些时间，但我回答了这个问题： https://github.com/boostorg/msm/issues/18

抱歉耽误了您的时间。