UML关系

Question

问题是将给定的UML图片与所有可能的描述相结合。

UML图

一个。可以从B导航到A.

湾可以从A导航到B.

℃。 B对A只有微弱的引用。

d。 A是B的一部分。

即B是A的一部分。

F。 A和B之间存在非特定关系。

克。当B不再存在时，A就没有理由存在。

小时。当B不再存在时，仍然存在A存在的原因。

我。 B使用A，但没有参考A。

我的尝试......

好吧，我失去了我尝试过多少次的计数。但在我看来，描述有些含糊不清。你可以说它适用与否......最后我像这样研究......

1. 成分：g，e
2. 聚合：e，h
3. 行：f，a，b，h
4. 依赖关系：c，h
5. 协会：a，h

并且它仍然不对......也许我对我确定的事情是错的。但是我们的导师显然没有为我们提供足够的材料来解决这个问题并且拒绝提供任何暗示。这是我从谷歌阅读帖子和文章到目前为止...有人可以帮助指出错误或错过了什么？我觉得我会呕吐......

Answer 1

从UML 2.5的角度来看：

（¹）我将假设，用于绘制图表的工具没有明确显示关联最终所有权，也没有明确显示不可导航的结束，因此我将坚持“共同解释”：

• 如果没有箭头，则两端都由相应的分类器拥有，并且可以导航
• 如果只有一个箭头，那么该方向由分类器拥有并且可以导航;另一端由协会拥有且无法通航

高级UML工具可以通过在末尾或小十字中添加黑点来明确区分，分别说明谁拥有该关联以及是否可以导航。

• A）是4-5，是1-3（¹）
• B）不是4-5（¹），是1-3（¹）
• C）没有基于图中的信息
• D）无
• E）1-2
• F）无; 3只是一个常规关联，并且在前面提到的上下文中并不需要任何额外的内容
  • uml-diagrams.org称这种未指定的导航性，但只有当图表工具支持（或未抑制）所有上述标记（十字，点）时才会出现这种情况。
• G）无;与D）携手并进。
• H）全部;基本上与G）相反。
• I）所有;与A）携手并进，出于同样的原因

总结：我强烈建议您查看UML 2.5 specifications第11.5.5节中的示例。 整章（11.5）可以为您提供更多的见解，但如果您只将UML视为图表而不是模型，那么它可能会非常强大。

更新：依赖

  

模型中依赖关系的存在没有任何运行时语义含义。

我通过Specs更加彻底，这是Dependency元模型

根据这一点，依赖客户和供应商都不会相互了解;严格来说，模型确实声明​​NamedElement（Class的超类）知道它所依赖的对象（clientDependency），但是这定义如下：

{OCL} result = (Dependency.allInstances()->select(d | d.client->includes(self)))

我称之为废话，因为那时每个不可通航的终端都可以通过相同的方法进行导航。

因此，鉴于此，依赖：

• A）是技术性的
• B）没有技术性，但没有什么能阻止我使用相同的方法来解释为什么A可导航以使B可导航

所以A + B都有些解释。

• C）是和否;取决于解释

根据该模型，它没有直接参考，但模型也说

  

依赖性意味着没有供应商，客户的语义就不完整。   ...   Usage是一个依赖关系，其中一个NamedElement 需要另一个NamedElement [...]用于其完整实现或操作。

因此，我不会将其称为弱引用，因为客户需要它。事实上，UML 2.5在Spec的相关部分中没有使用单词 weak 一次（更不用说弱引用），因此该术语本身没有任何意义（也许它是用于旧版本的UML）。

• I）是和否，出于同样的原因;引用是派生的（根据其他信息计算），但规范也说明了

  

涉及派生属性的操作与非衍生属性的操作相同。

摘要：依赖关系是一个想法的表示，而不是一个实现;因此，对使用它的人以及在特定背景下最有意义的人开放实际解释。

我保留了原来的答案，在这部分中，我或多或少地提出了一种非常机械和无意义的约束应用，这通常不是一个好主意。