BoUML的状态机生成器是否可以正确处理退出和进入复合状态？

编程问答 2022-06-13

问题描述

考虑以下History状态机：

enter image description here

运行下面的代码时... 

  machine.create();
  machine.check();
  machine.stop();

machine生成以下输出：

01 DEBUG : current state is Now .History.Outer
02 DEBUG : execute entry behavior of .History.Outer
03 Entry behavior Outer
04 DEBUG : current state is Now .History.Outer.Inner
05 DEBUG : execute entry behavior of .History.Outer.Inner
06 Entry behavior Inner
07 DEBUG : fire trigger check
08 DEBUG : execute exit behavior of .History.Outer
09 Exit behavior Outer
10 DEBUG : current state is Now .History
11 DEBUG : current state is Now .History.Outer
12 DEBUG : fire trigger stop
13 DEBUG : execute exit behavior of .History.Outer
14 Exit behavior Outer
15 DEBUG : current state is Now .History
16 DEBUG : final state reached

我看到此输出有两个问题。首先，根据UML规范， 14.2.3.4.6退出状态

从复合状态退出时，退出从活动状态配置中最里面的状态开始。这意味着退出行为将从最里面的活动状态开始按顺序执行。

但是在触发check（行07）之后，仅执行Outer的状态退出行为（行08和09）。 Inner的退出行为永远不会执行。

第二，根据 14.2.3.4.4状态历史记录

深层历史记录（deepHistory）表示对包含区域的最近访问的完整状态配置。效果与终止于deepHistory伪状态的Transition相反地终止于保留状态配置的最内部状态（包括执行沿途遇到的所有条目行为）相同。

因此，我希望在第02-06行之后看到第11行的副本。

我说得对吗？

解决方法

状态机生成器只是类生成器/模型转换的演示器。它仅管理琐碎的状态机，如您所见，在应用它之后，不会生成支持内部状态的内部类，并且对历史状态，区域，伪状态也不会做任何事情。

这是一个插件，它不是建模器（BoUML可执行文件）的一部分，因此您可以自由地对其进行改进或完全重写。这是插件的 raison d'être，以使您不受我提供的功能的限制。

code-generationstate-machineumluml