[BOOST] [MSM] Guard可以是Action的后置条件，而不是前置条件

Question

我是MSM的新手，也是UML状态机标准。我以前使用过状态机设计，使用状态设计模式，但这次我想学习使用BOOST MSM，而不是再次烹饪。

让我很困惑的一件事是卫队。我想这样做，在状态S1，我收到一个事件E1，然后执行一些动作A1，根据动作A1的结果，我应该转换到新的状态S2，或保持在相同的状态S1。

使用MSM，我不能将Guard G1指定为Action A1的结果，因为在MSM的概念中，G1是否应该执行A1的前提条件，而不是执行A1的结果。

我能想到的两个解决方案是：

1. 引入一个伪选择状态post_S1，在其 on_entry 中执行Action A1，并让一个后卫G1测试此操作的结果，然后返回S1，或者进入S2。

//启动事件操作Next Guard

S1 E1无post_S1无
post_S1无无S2 G1 post_S1无无S1 G1'（与G1相反）


2

将Action A1代码移动到Guard G1（Afterall，A1是一个函数调用，我可以让它返回boolean）。所以基本上我的过渡行将是

//启动事件操作下一个警卫

S1 E1无S2 G1 = A1

我使用MSM吗？有没有更好的解决这个问题的做法？在我的应用程序中，我会有很多这些伪选择状态，我真的试图避免。

谢谢！ 王宗军

Answer 1

这是UML标准定义的内容，防护是先决条件。

你有几种方法可以实现目标，在这种情况下我个人的口味是：

• 在状态S1中，在事件E1上添加内部转换。
• 此转换将A1作为操作。在A1中，执行操作，然后检查结果。
• 如果结果意味着“留在原地”，请停止
• 其他呼叫（仍然在A1内）fsm.template process_event（E2）; E2是一个新的事件，将你带到S2。

我建议这样，因为它会节省一些编译时间，状态很昂贵; - ）

这是最简单的方法。同样，还有其他一些，比如使用eUML让A1返回结果，然后在转换表中添加if_，但这要先进得多。

HTH， 克里斯托夫

Answer 2

//开始事件操作下一个警卫
      S1 E1无S2 Result_of_A1
在Guard函数本身内部，我们执行动作A1，然后根据A1的结果返回True或False。这样，如果后卫是假的，那么留在S1;否则，转到S2。

这样可以保存伪选择状态，这很有用但是如果有很多状态转换到下一个状态是“发布条件”而不是“预 condition“，那么转换表中会有很多这些伪选择状态。与上面的转换表相比，它更加混乱。