【问题标题】:Do forked nodes have to be joined? UML State Diagram必须加入分叉节点吗? UML 状态图
【发布时间】:2020-03-27 15:47:51
【问题描述】:

最后一定要加入分叉节点吗? 并且出局的分叉节点可以有守卫吗?

基本上我想做的是将零钱退还给客户,同时继续洗车。

但是,也许有更好的方法来做到这一点?

【问题讨论】:

  • 这是一个非常有趣的问题。当你问“必须加入”时,你的意思是UML要求吗?或者它需要有一个有用的模型?您能否还提供您的图表的绝杀完整图片,以便我们可以看到每个分叉的分支如何结束? (与你的叙述一起显示的部分导致认为有问题)

标签: design-patterns uml computer-science state-machine state-diagram


【解决方案1】:

分叉的节点最后一定要加入吗?

对我来说不,这不是强制性的,但是当所有流和链接元素也结束时,组将结束

传出的分叉节点可以有守卫吗?

你的意思是传出,规范说一个fork段不能有Guards或Trigger

基本上我想做的是将零钱退还给客户,同时继续洗车。

是的,它们可以并行完成,从洗衣机的角度来看,当它返回零钱时,一切都完成了,洗涤也完成了

【讨论】:

  • 好的,所以我需要摆脱说 Return Change [Deposit > Required] 的守卫。您是否碰巧知道并行执行此操作的任何替代方法?看起来分叉不是一个很好的选择,我不能特别提到传出分叉节点中的任何内容来返回更改。
  • @Don 对于右边的过渡你需要添加一个决定是否还钱,并且你需要之前的分叉
  • 注意我说错了transition,我的意思当然是flow
【解决方案2】:

分叉的节点最后一定要加入吗?

这取决于。如果您想继续拆分流程,那么可以。如果你不加入他们,你就会有两个松散的结局独立地继续,直到他们每个人都以一种或另一种方式终止。

并且传出的分叉节点可以有守卫吗?

P。 360 个 UML 2.5 状态

  • fork_segment_guards

fork 段不能有 Guards 或 Triggers。

inv: (source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::fork) implies (guard = null and trigger->isEmpty())

(我错了,在bruno 注意到我之后解决了这个问题。)

也许有更好的方法?

当然。描述事物的方式有很多种。不过除了多余的守卫似乎还可以。

【讨论】:

  • 当规范明确表示相反时,请不要说分叉的流出流可以有保护。此外,从分叉流出的流到达连接也不是强制性的(注意 OP 说“分叉节点 必须最后加入吗?”)
  • @bruno 嗯。 OCL 似乎更清楚: inv: (source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::fork) 暗示 (guard = null and trigger->isEmpty()) 所以你显然是对的.
  • 规范,永远规范 :-)
  • 当然可以。在这种情况下,文字描述有点不正常;-)
【解决方案3】:

总之

它不是白底黑字,但如果你分叉,你会有一些限制,迟早会要求你加入实践。只有一个有效的构造可以让您在实践中避免加入。

更多细节

这是令牌并发流和结束流的规则的间接结果。

根据 UML 2.5 规范,flow-final 具有以下行为:

FlowFinalNode 是终止流的 FinalNode。所有代币 FlowFinalNode 接受的被销毁。这对其他没有影响 在 Activity 中流动。

您可以使用它来吸收其中一个并发流上的令牌,而不会影响其他分支。

同样,activity-final 遵循以下原则:

ActivityFinalNode 是一个 FinalNode,它会停止一个 活动。一个令牌 到达 Activity 拥有的 ActivityFinalNode 会终止 该活动的执行。

但是没有规则来定义每个流的速度,如果您没有连接,每个流也不会执行所有预期的活动。这就是缺少同步的问题。

假设您有两个保持独立的分叉流:每个流都必须以某种方式结束。如果你没有加入:

如果一个 Activity 拥有多个 ActivityFinalNode,然后是第一个接受令牌的节点(如果有) 终止Activity的执行,包括执行 任何其他 ActivityFinalNodes。

因此,到达活动最终的第一个流将中断其他流上正在进行的活动,从而使其他流的性能不完整。

确保两个分支都正确结束而不会中断的唯一方法是,因此在每个分支上都有一个 flow-final。

如果其中一个流程循环存在令牌与并发流程相乘的问题,则会在电路中重新注入(对应于并发执行)。

避免连接节点的唯一另一种方法是使用隐式连接:

一个 ExecutableNode 在所有传入的 ControlFlow 之前都不会执行 (如果有)正在提供代币。也就是说,有一个隐式连接 在传入的控制流上。特定种类的可执行节点可能 在节点之前必须满足的其他先决条件 可以执行。

无论是隐式还是显式,它都是一个连接 ;-)

【讨论】:

  • 你会有一些限制是不正确的。您可以通过点击最终流或没有流出流的操作来结束彼此独立的两条路径。绝对合法有效。
  • @qwerty_so 我说的不是合法性而是实际意义。获得安全结果的唯一方法是在两边都有一个 flow-final(而不是 activity-final),这极大地限制了未连接分叉的有用性。并且 OP 似乎在循环中使用这个构造。这意味着正常情况下的最终流程可能会中断分叉的流程,或者令牌重新注入会导致同时执行多个黄色活动。也许合法,有用,我怀疑。
  • 通常我也加入一个fork。但我们无法推测他的意图。并且有足够的理由说明您不需要/想要加入。您提到的约束经常发生,但绝不会强制执行...
  • @qwerty_太好了。所以我们同意:在实践中,大多数时候在建模有用的东西时需要连接,即使理论上它不是必需的。 Byw,OP 没有询问执法或规范。所以实际方面很重要,我只是想确保 OP 得到全面的了解。如果没有连接,OP 试图实现的目标是错误的(这不是推测:图表+叙述的部分说明了这一点)。
猜你喜欢
  • 2023-02-22
  • 1970-01-01
  • 2015-04-21
  • 1970-01-01
  • 2020-12-31
  • 2012-10-09
  • 1970-01-01
  • 1970-01-01
  • 2011-01-31
相关资源
最近更新 更多