UML：activity 图控制流
UML: activity diagram control flow
我在网上找到了下面的 activity 图：
我不明白为什么从接收订单操作中有两个控制流（到发货订单和向客户开票）。它们平行吗？那为什么没有叉子。如何理解这张图？请解释一下。
这简直就是一个坏例子。
从上下文来看，应该有一个分支来表明Ship order和Bill customer应该并行发生。
那么 Send confirmation 之前应该有一个 Join 来指示两个流程应该在 Send confirmation 执行之前完成。
完全有效的 UML 2。第一个动作不需要标记，因此可以立即开始。当第一个动作完成时，它会为其他两个动作提供令牌，然后它们就可以开始了。在提供所有必需的令牌之前，最后一个操作无法开始。当最后一个动作完成时，包含的 activity 也完成了。
分叉只是复制代币。加入只是合并令牌。因此，分叉和连接通常是不必要的。
请参阅Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology。
我没有检查这是否是对 UML 规范的最新修订，但当前 version 2.5（第 15.2.3.2 章）声明（重点由我自己设置）：
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 and ExecutableNodes in sub clause 15.5). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.
从这个角度来看，我认为@Jim L. 的回答可能会被弃用。我假设，至少在当前版本的 UML 中，有问题的图表没有反映建模者的意图。现在，叉子似乎不仅是干净的方式，而且是唯一正确的方式。
我在网上找到了下面的 activity 图：
我不明白为什么从接收订单操作中有两个控制流（到发货订单和向客户开票）。它们平行吗？那为什么没有叉子。如何理解这张图？请解释一下。
这简直就是一个坏例子。
从上下文来看，应该有一个分支来表明Ship order和Bill customer应该并行发生。
那么 Send confirmation 之前应该有一个 Join 来指示两个流程应该在 Send confirmation 执行之前完成。
完全有效的 UML 2。第一个动作不需要标记，因此可以立即开始。当第一个动作完成时，它会为其他两个动作提供令牌，然后它们就可以开始了。在提供所有必需的令牌之前，最后一个操作无法开始。当最后一个动作完成时，包含的 activity 也完成了。
分叉只是复制代币。加入只是合并令牌。因此，分叉和连接通常是不必要的。
请参阅Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology。
我没有检查这是否是对 UML 规范的最新修订，但当前 version 2.5（第 15.2.3.2 章）声明（重点由我自己设置）：
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 and ExecutableNodes in sub clause 15.5). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.
从这个角度来看，我认为@Jim L. 的回答可能会被弃用。我假设，至少在当前版本的 UML 中，有问题的图表没有反映建模者的意图。现在，叉子似乎不仅是干净的方式，而且是唯一正确的方式。