UML状态图上的混乱
我在网上提到了很多材料,我看到合并的用法几乎相同吗?一些站点说要使用钻石形状合并,有些人说使用交界处。我知道哪一个是正确的吗?以下图像是我读过的材料。
使用钻石形状合并
使用交界处合并 “合并”>
I have referred quite a lot of materials online, I saw the usage of merge and junction is almost the same? Some sites said to use the diamond shape as a merge, some said to use junction. Can I know which one is correct? The following images are the material I have read.
merge using diamond shape
merge using junction
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在状态机图中,有两个通常混淆的伪状态:连接状态(黑色填充圆圈)和选择状态(一个空心钻石)。不要将它们与活动图(初始节点,决策节点和合并节点)中的类似形状混淆。他们看起来只有一样。
现在,对于选择和交界处的差异真实。然后,在检查选择状态之前,所有效果行为均在检查之前进行。这允许动态分支,具体取决于某些仅在启动过渡时评估的值。
A 交界处状态只是连接过渡。可以用尽可能多的过渡代替可能的路由。这样的过渡仅在路线上的所有全部后卫评估为true时就会发射。
这两种州都可以根据需要进行尽可能多的内外过渡。
In a state machine diagram there are two pseudo states that are often confused: The junction state (a black filled circle) and the choice state (a hollow diamond). Don't confuse them with similar shapes in an activity diagram (initial node, decision node and merge node). They only look the same.
Now for the difference between choice and junction states: A compound transition fires, when its triggering event occurs AND all guards before an eventual choice state evaluate to true. Then all the effect behaviors up to the choice state are executed before any of the guards of outgoing transitions are checked. This allows dynamic branching depending on some value that only gets evaluated when the transition has fired.
A junction state just connects transitions. It could be replaced with as many transitions as there are possible routings. Such a transition only fires if all guards on the route evaluate to true.
Both states can have as many in- and outgoing transitions as you like.
作为一个旁注(不长时间评论),合并合并/决策的符号需要一些澄清。 UML 2.5 p。 387:
下面(有点晦涩!):
请注意,这是关于活动而不是国家的!
如 @AxelsCheithauer 指出,该图渲染可能会偏差。 UML 2.5州的P. 390
As a side note (too long for a comment) the notation for the combined merge/decision needs some clarification. UML 2.5 states on p. 387:
and below (a bit more obscure!):
Note that this is about activities and not states!
As @AxelScheithauer noted, the diagram rendering may deviate. P. 390 of UML 2.5 states