我的UML活动图有什么问题吗？

我想知道我的图表出了什么问题？请帮助我完成以下图表：

---

这里有几个问题：

• 初始节点应该有一个前往

  Login

  的传出边缘。如果没有这一点，人们可以理解什么都不会发生。虽然这可能会引起争论（见评论），但最好避免模棱两可

• 确认放置搜索者

  表单有两个输出边。这并不违法，但一次只有一个目标可以接受它，UML语义没有定义哪一个。如果希望两个目标操作都发生，则应添加一个fork节点（稍后添加一个join节点以同步并行流）。如果您只想要一个，那么通过在两者之间使用决策节点来避免歧义

• 接收确认通知

  没有传出边缘。这不是非法的，与流程最终情况类似。然而，如果有什么东西被遗忘了，这可能会提出一个问题；对于读者来说，系统地使用最终流或活动结束节点不那么模棱两可。因此，如果这是一个并行流，那么在继续并到达activity final节点之前，您需要该流具有到流最终节点（消耗令牌并结束此并行分支）或上述连接节点的边缘。如果这是一个可选流，那么您应该向活动最终节点添加一条边

---

我同意初始节点应具有传出边缘。然而，它的省略并不意味着什么都没有发生。定义的语义是，所有没有传入流的操作都被启用。在本图中，这与初始节点和

登录

抱歉之间的控制流具有完全相同的效果，但是您关于两个传出控制流的语义的声明已经过时。在UML2中，这意味着两者都获得一个令牌。因此，它是一个隐式fork。您可能希望明确地添加它以避免误解，但它实际上是有效的和一致的。

receive confirmation notification

上缺少传出边缘意味着在操作完成执行时不会生成令牌。因此，效果与将其连接到流最终节点完全相同。我建议添加这一点，以使图表更具可读性，但这并不是严格必要的。我同意，您可能希望在活动最终节点之前将其连接到联接节点，因为只有在两个操作都完成后，它才应该结束。@AxelScheithauer感谢您的建设性评论。然而，我认为语义并不像您建议的那样清晰：UML2.5.1远没有过时。在第373页“由于ActivityNode可能是多个ActivityEdge的源，因此可以向多个目标提供相同的令牌。但是，同一令牌一次只能在一个目标接受”，以及“如果一个令牌同时提供给多个ActivityNodes，则最多只能被其中一个接受，但具体是哪一个并不完全由Activity flow语义决定“。我误解了吗？@AxelScheithauer，但我接受你关于最终流程没有生成令牌的论点。我的大脑深处仍然有一些petri网的回忆，告诉我要对标记非常严格；-）关于你的第一句话，你能帮我找到相关的段落吗？我被困在“当传入ActivityEdge上提供给它的令牌满足指定条件时，ActivityNode可以开始执行”和初始节点的段落中，我想找到您解释的关于节点的语义，而不输入edge。