UML:活动图控制流程

时间:2015-12-12 08:21:51

标签: uml

我在互联网上发现了以下活动图:

enter image description here

我无法理解为什么从Recieve订单操作中有两个控制流程(对于Ship order和Bill customer)。它们是平行的吗?然后为什么没有叉子。如何理解这个图?请解释一下。

3 个答案:

答案 0 :(得分:2)

这是完全有效的UML 2.第一个动作不需要令牌,所以它可以立即启动。当第一个动作完成时,它会向其他两个动作提供令牌,并且可以启动。在提供所有必需的令牌之前,最后一个操作无法启动。完成最后一个操作后,也会完成包含活动。

福克斯只是复制令牌。加入只是合并令牌。因此,叉和连接通常是不必要的。

请参阅Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology

答案 1 :(得分:1)

这只是一个不好的例子。

从上下文来看,应该有一个分叉表示Ship orderBill customer应该并行发生。

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

答案 2 :(得分:0)

我没有检查这是否是UML规范的最新修订版,而是当前的version 2.5(第15.2.3.2章)状态(强调由我自己设置):

由于一个ActivityNode可能是多个ActivityEdge的源,因此可以将同一令牌提供给多个目标。但是,同一令牌一次只能在一个目标上被接受(除非将其复制,否则它不是同一令牌,请参阅第15.3节中的ForkNodes和第15.5节中的ExecutableNodes)。如果将令牌同时提供给多个ActivityNode,则令牌最多应被其中一个接受,但确切地说哪个令牌并不能完全由Activity流语义确定。这意味着其中发生不确定性的活动模型可能会受到计时问题和比赛条件的影响。如果不需要,建模者有责任在活动模型的构建中避免此类情况。

从这个角度来看,我认为@Jim L.的答案可能已被弃用。我认为至少在当前的UML版本中,所讨论的图不能反映建模者的意图。叉子似乎不仅是干净的方法,而且现在也是唯一正确的方法。