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

Correct order of deferred events in state-machine of UML 2.x

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

当我按顺序向sm1发送e1、e2、e3、e4时,期望的状态是什么?如果e1从defer队列中出队,再次入队到s2中的defer队列,消耗e2过渡到s3,则s3中defer队列的头部为e3,这样期望状态为s5。但是,如果e1保持原来的位置(head)并跳过它,则e2被消耗,预期状态为s4。

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

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

推迟的事件位置

我在状态机图中使用了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

--开始报价

延期活动

一个州可以指定一组可以在该州推迟的事件类型。这意味着只要该 State 保持活动状态,这些类型的 Event 事件就不会被分派。相反,这些事件发生将保留在事件池中,直到:

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

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

--引述结束

重点是"Instead, these Event occurrences remain in the event pool until"。 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

我会报告相关问题。