UML状态图中，Join伪状态是什么？

前导码

这篇材料可能对于一篇文章来说有点小、粗糙和显而易见。它也纯粹是理论性的、推测性的，并且没有代码。尽管如此，我还是决定把它发布在CodeProject上以获取反馈。它可以扩展或移动到CodeProject上的我的博客中，或者合并到关于并发状态机的一个更大的文章中。最初的标题是：“UML Join是邪恶的”。

有趣的是，我找不到一个现成的（商业或开源）状态机（SM）框架，它具有Join的显式实现。通过消息在并发区域之间的同步很常见，并且Join可以隐式地完成。并非每个SM框架都支持正交区域，但我没有看到任何一个框架具有Join对象，例如。如果你知道一个，请告诉我。

问题

Join是UML中的伪状态吗？Join的语义是否定义明确？应该如何使用它？

假设

状态：状态机（SM）应该处于一个能够处理消息的状态。如果SM需要在一定时间内接收并处理一条消息，那么这将设定“相当长的时间”的上限。一个显而易见的推论：状态之间的转换应该是原子的。

伪状态：我找不到伪状态的严格定义。现在，让我们假设，由于它们不是状态，SM不会在伪状态中花费相当长的时间。

示例

状态图

• 此示例中的状态机具有两个并发区域（通道1和通道2）。
• 状态 S11 通过进行转换 T1 来响应消息 M3。
• 状态 S21 和 S22 通过设计，通过内部方式响应 M2；通道2始终必须响应 M2。
• S21 还通过进行转换 T2 来响应 M1。
• 由于分叉 F1 和 Join J1，在 T1 完成之前，从 S21 到 S22 的完整转换是不可能的。

不错的图片！这是一个拓扑图，其中未定义时间（或任何其他坐标）。但是，我们可以提出一个场景并为它创建一个时间线，如图2所示。

场景

• M1 首先到达，状态 S21 进行转换 T2，现在被卡在 J1 上。
• M2 到达，但通道2没有状态，并且无法处理该消息。这就是问题所在。

解决方案

实际上，解决方案很简单——Join应该驻留在它所起源的状态的上下文中。我们还能将Join称为伪状态吗？

参考文献

[OMG 07] OMG 统一建模语言 (OMG UML)，超结构，V2.1.2

修订历史

• 0.1：初始草稿：2009年2月15日。