我是MSM的新手,也是UML状态机标准。我以前使用过状态机设计,使用状态设计模式,但这次我想学习使用BOOST MSM,而不是再次烹饪。
让我很困惑的一件事是卫队。我想这样做,在状态S1,我收到一个事件E1,然后执行一些动作A1,根据动作A1的结果,我应该转换到新的状态S2,或保持在相同的状态S1。
使用MSM,我不能将Guard G1指定为Action A1的结果,因为在MSM的概念中,G1是否应该执行A1的前提条件,而不是执行A1的结果。
我能想到的两个解决方案是:
引入一个伪选择状态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吗?有没有更好的解决这个问题的做法?在我的应用程序中,我会有很多这些伪选择状态,我真的试图避免。
谢谢! 王宗军
答案 0 :(得分:0)
这是UML标准定义的内容,防护是先决条件。
你有几种方法可以实现目标,在这种情况下我个人的口味是:
我建议这样,因为它会节省一些编译时间,状态很昂贵; - )
这是最简单的方法。同样,还有其他一些,比如使用eUML让A1返回结果,然后在转换表中添加if_,但这要先进得多。
HTH, 克里斯托夫
答案 1 :(得分:0)
//开始事件操作下一个警卫
S1 E1无S2 Result_of_A1
在Guard函数本身内部,我们执行动作A1,然后根据A1的结果返回True或False。这样,如果后卫是假的,那么留在S1;否则,转到S2。
这样可以保存伪选择状态,这很有用但是如果有很多状态转换到下一个状态是“发布条件”而不是“预 condition“,那么转换表中会有很多这些伪选择状态。与上面的转换表相比,它更加混乱。