UML 关系

Question

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

UML 图

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

b.可以从 A 导航到 B。

c。 B 在 A 上只有一个弱引用。

d。 A 是 B 的一部分。

e。 B 是 A 的一部分。

f。 A 和 B 之间存在不特定的关系。

g.当 B 不再存在时，A 就没有存在的理由。

h。当 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 视为图表而不是模型，那么它可能会让人不知所措。

---

更新：依赖关系

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

我更彻底地了解了规范，这里是依赖元模型

据此，客户和供应商都不知道彼此的依赖关系；严格来说，模型确实声明​​ NamedElement（Class 的超类）知道它依赖于谁（clientDependency），但是它的定义如下：

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

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

因此，鉴于此，对于依赖项：

• A) 技术上是的
• B) 技术上没有，但没有什么能真正阻止我使用相同的方法，为什么 A 可以导航，B 也可以导航

所以 A+B 都可以解释。

• C) 是和否；取决于解释

根据模型它不直接引用，但是模型也说

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

所以我不会把它称为弱引用，因为客户需要它。事实上，UML 2.5 在规范的相关部分并没有使用一次 weak 这个词（更不用说 weak 引用了），所以这个词本身没有任何意义（也许是在旧版本的 UML 中使用）。

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

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

总结： 依赖是一个想法的表现，而不是一个实现；因此，实际的解释对使用它的人以及在特定上下文中最有意义的内容是开放的。

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