关于OMG UML/SysML状态机转换时序及行为触发的技术问询

关于Motion::Active::Debounce状态do行为的触发判定 #

根据OMG UML 2.5.1规范的明确流程，状态的执行时序严格遵循以下顺序：

1. 进入状态时，先完整执行entry行为，此过程中不会评估任何内部无触发转换的守卫条件；
2. entry行为完成后，才会对所有无触发转换的守卫条件进行评估；
3. 若没有触发任何退出转换，才会启动并执行该状态的do行为。

因此，即便退出转换的守卫在entry行为执行过程中就变为true，由于此时还未到守卫评估阶段，entry行为仍会完整执行。待entry完成后，守卫条件被评估为true时会立即触发退出转换，Debounce状态的do行为不会被启动。

替代建模方式 #

针对这类易出现时序冲突的场景，有几种更清晰的建模方案：

• 拆分entry逻辑到前置过渡状态：将可能触发退出守卫的逻辑从Debounce的entry行为中剥离，放到专门的前置过渡状态执行，确保进入Debounce状态时守卫条件不会立即满足；
• 添加延迟触发的转换：用带短暂延迟的触发转换替代无触发守卫转换，比如设置after(100ms)的触发条件，确保entry行为完成后再评估退出逻辑；
• 绑定守卫与entry完成标志：在Debounce状态中新增内部标志位，entry行为执行完毕后将标志设为true，退出转换的守卫条件改为原条件 && 标志位，强制守卫评估必须在entry完成后才可能为true；
• 拆分状态为子状态机：将Debounce状态拆分为EntryExecuting和DebounceActive两个子状态，entry行为放在EntryExecuting中执行，完成后自动转入DebounceActive并启动do行为，退出转换仅在DebounceActive状态中设置，从根源上避免时序冲突。

内容的提问来源于stack exchange，提问作者Daniel Ashby