【发布时间】：2021-06-05 05:29:47
【问题描述】：
【问题讨论】：
标签： uml activity-diagram
【发布时间】：2021-06-05 05:29:47
【问题描述】：
这里有几个问题：
- 初始节点应该有一个出边去
Login。如果缺少这一点，人们可以理解什么都不会发生。虽然这可能会引起争论（参见 cmets），但最好避免歧义。 -
Confirm placement seekers表单有两个传出边。这不是非法的，但一次只有一个目标可以接受它，并且 UML 语义没有定义哪一个。如果您希望两个目标操作都发生，您应该添加一个 fork 节点（然后添加一个 join 节点以同步并行流）。如果您只想要一个，那么通过使用中间的决策节点来避免歧义。 -
Receive confirmation notification没有出边。这不是非法的，并且类似于并且类似于流最终情况。然而，如果忘记了某些东西，这可能会引发问题；对读者来说，系统地使用 flow-final 或 activity end 节点就不那么模棱两可了。因此，如果这是一个并行流，则在继续并到达活动之前，您需要该流具有到流最终节点（以消耗令牌并结束此并行分支）或到上述连接节点的边缘最终节点。如果这是一个替代流程，那么您应该向活动最终节点添加一条边。
【讨论】：
-
我同意初始节点应该有一个出边。然而，它的遗漏并不意味着什么都不会发生。定义的语义是启用所有没有传入流的操作。在此图中，这与初始节点和
Login之间的控制流具有完全相同的效果 -
抱歉，您关于两个传出控制流语义的陈述已经过时。在 UML 2 中，这意味着两者都获得了一个令牌。因此，它是一个隐式分叉。您可能希望明确添加它以避免误解，但它实际上是有效且一致的。
-
receive confirmation notification上缺少传出边仅意味着当操作完成执行时没有生成令牌。因此，效果与将其连接到流最终节点完全相同。我建议添加这个，以使图表更具可读性，但这不是绝对必要的。我同意，您可能希望在活动最终节点之前将其连接到连接节点，因为它应该仅在两个操作完成后才结束。 -
@AxelScheithauer 感谢您的这些建设性意见。但是，我认为语义并不像您建议的那样明确：UML 2.5.1 远未过时。在第 373 页上“由于 ActivityNode 可能是多个 ActivityEdge 的源，因此可以将相同的令牌提供给多个目标。但是，一次只能在一个目标上接受相同的令牌 ”和“如果一个token同时提供给多个ActivityNode，最多只能被其中一个接受，但具体哪一个不完全由Activity流程决定语义”。我误会了吗？
-
@AxelScheithauer 但我接受你关于流决赛没有生成令牌的论点。我的大脑深处仍然有一些 petri-net 回忆，告诉我对令牌非常严格;-) 关于你的第一句话，你能帮我找到相关的段落吗？我被困在“当满足指定条件时启用 ActivityNode 以开始执行在传入的 ActivityEdges 上提供给它的令牌”和初始节点的 para，并希望找回您解释的关于没有传入边缘的节点的语义。