UML：活动图控制流

Question

我在互联网上找到了以下的活动图：

我不理解为什么从“接收订单”这个动作有两个控制流（分别指向“装运订单”和“向客户开发票”）。它们是并行的吗？那为什么没有使用分支节点（fork）？请问如何理解这个图示呢？

- Pavel_K

Answer 1

这只是一个糟糕的例子。

从上下文来看，应该有一个分支来表示Ship order和Bill customer应该同时进行。

然后，在Send confirmation之前应该有一个Join，以表示在执行Send confirmation之前，两个流程都已经完成。

- Geert Bellekens

---

谢谢你的回答。我也是这么想的，但有一件事让我感到困惑，这是来自Rumbaugh所著的UML参考书中的内容，而他可是UML的创造者之一。 - Pavel_K

即使教皇可能犯错，但他永远不会承认。正如Geert所说：一个真正糟糕的例子。 - qwerty_so

这不是错误，而是有效的UML，只是一个选择不当的例子。 - Geert Bellekens

我认为这是错误的。请看我在Jim的回答中的评论。 - qwerty_so

@Thomas：这并不是错误的。请查看我在我的答案下回复你评论的内容。 - Jim L.

所以教皇并没有错误（请参见其他答案中的评论）。然而，为了清晰起见，我更喜欢使用分支。 - qwerty_so

Answer 2

这是完全有效的UML 2。第一个动作不需要令牌，因此它可以立即开始。当第一个动作完成时，它向另外两个动作提供令牌，它们也可以开始。最后一个动作只有在所有必需的令牌都被提供后才能开始。当最后一个动作完成时，包含该活动的活动也完成了。

分支只是复制令牌。合并只是合并令牌。因此，分支和合并通常是不必要的。

请参阅Conrad Bock在Object Technology杂志上关于活动图的系列文章。

- Jim L.

---

谢谢您的回答。如果我理解得正确，令牌是在对象之间传递的一些数据。您是如何理解这些令牌的呢？ - Pavel_K

不可能的。当一个活动结束时，它会提供所有的控制令牌。 - Jim L.

此外，发货订单确实需要控制令牌才能启动。 - Jim L.

现在我在我的笔记本电脑上，找到了康拉德系列的第一个链接，并将其添加到了我的答案中。我强烈建议任何使用UML 2活动图的人阅读这些文章。 - Jim L.

@johnson：在 OP 图中，提供了两个令牌，而不是一个。 - Jim L.

Answer 3

我没有检查这是否是 UML 规范的最新修订，但目前的2.5 版本（第 15.2.3.2 章）说明如下（强调是我自己设置的）：

由于 ActivityNode 可以是多个 ActivityEdge 的源，因此同一令牌可以提供给多个目标。但是，同一令牌只能在一个目标上被接受（除非它被复制，此时它不是同一令牌，请参见子条款 15.3 中的 ForkNodes 和子条款 15.5 中的 ExecutableNodes）。如果一个令牌同时提供给多个 ActivityNode，则最多只能由其中一个接受，但确切是哪一个并不完全由 Activity 流语义确定。这意味着在发生非确定性的 Activity 模型中可能存在时间问题和竞争条件。如果不需要这些条件，则模型师有责任在构建 Activity 模型时避免这种情况。

从那个角度来看，我会认为@Jim L.的回答可能已经过时了。我认为，至少在当前版本的UML中，所讨论的图示并不反映建模者的意图。现在似乎分支不仅是清晰的方式，而且是唯一正确的方式。

- Johnson

---

你是正确的。我强调了重要的句子。我猜这在问题最初被提出时已经存在了。 - qwerty_so

从同一节中：“在执行过程中，可执行节点被认为持有一个单独的控制令牌，表示它正在执行。当它完成执行时，它会在所有传出的控制流上提供控制令牌。可执行节点的所有传入和传出活动边必须是控制流。”（重点是我的） - Jim L.

No Magic 以准确遵循规范为傲。他们的客户坚持如此。 - Jim L.

@JimL。这可能是正式规格和实际解释之间差异的例子。也许该工具只是放宽了规范，因为在实践中允许非确定性行为可能并不理想。谈到确定性，重点在于，虽然给定的图表符合UML的语法，但我强烈建议不要对非确定性进行建模，并依赖工具来按照我需要的方式进行解释。 - Johnson

规范的书写对于许多人和我来说似乎很清晰，但是你提出了一个关于确定性建模行为优越性的极好观点。 - Jim L.