BoUML'；状态机生成器正确处理进入复合状态的退出和进入？

考虑以下

历史

状态机：

当下面的代码运行时

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

机器

生成以下输出：

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退出状态

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

但在触发触发器

检查

后（第

07行

），仅执行

外部

的状态退出行为（第

08行

和

09行

）。

内部

的退出行为从不执行

第二，根据第14.2.3.4.4段，国家历史

deepHistory（deepHistory）表示最近访问包含区域的完整状态配置。其效果与在deepHistory伪状态上终止的转换在保留状态配置的最内层状态上终止的效果相同，包括执行过程中遇到的所有条目行为

因此，我希望在第

11行之后看到第
02-06行的副本

我说得对吗？
状态机生成器只是类生成器/模型转换的演示器。它只管理琐碎的状态机，正如您应用它后所看到的，没有生成内部类来支持内部状态，也没有对历史状态或区域、伪状态进行任何处理

它是一个插件，不是modeler（BoUML可执行文件）的一部分，因此您可以自行改进或完全重写它。这就是插件存在的理由，让您不受我提供的功能的限制。
@zer0hedge很难知道，一切都取决于您，试试看，您就会知道；-）。只需注意，可以用java和/或C++实现插件，而不依赖于它可以管理的语言，正确的方法是从分发的特殊的“空”部分中定义BoUML。看见状态机生成器的BoUML模型也是分发的一部分。您根据哪个许可证分发状态机生成器源代码？我找不到任何，这意味着它是独家版权，所以我不能改变它！许可证如所示：
为插件生成的代码属于GNU通用公共许可证的条款
，因此您可以更改它，其结果仍在GPL之下。插头本身也是如此