UML 关系
UML Relationships
问题是将给定的 UML 图片与所有可能的描述相结合。
UML 图
一个。可以从 B 导航到 A。
b。可以从 A 导航到 B。
c。 B 对 A 的引用很弱
d。 A是B的一部分。
e。 B 是 A 的一部分。
f。 A 和 B 之间存在不明确的关系。
克。当B不存在了，A就没有存在的理由了。
小时。当B不存在的时候，A还有存在的理由
我。 B 使用 A，但没有对 A 的引用。
我的尝试...
好吧，我已经记不清自己尝试了多少次了。但在我看来，这些描述有些含糊。你可以说它是否适用......最后我这样研究......
- 成分：g,e
- 聚合：e,h
- 行：f,a,b,h
- 依赖性：c,h
- 关联：a,h
而且它仍然不对...也许我对某些我确信的事情是错误的。但是我们的导师显然没有提供足够的material给我们解决这个问题，拒绝给出任何提示。这就是我阅读 post 和来自 google 的文章的程度...有人可以帮助指出错误或遗漏的地方吗？我觉得我要吐了...
从 UML 2.5 的角度来看：
(¹) 我会假设，用于绘制图表的工具没有明确显示关联端所有权或不可导航端，所以我会坚持使用 "common interpretation":
- 如果没有箭头，则两端都属于各自的 Classifier，并且可以导航
- 如果只有一个箭头，则该方向属于 Classifier 并且可以导航；另一端归协会所有，不可通航
高级 UML 工具可以通过在末尾添加黑点或小十字来明确区分，分别说明谁拥有关联以及它是否可导航。
- A) 4-5 是，1-3 是 (¹)
- B) 4-5 (¹) 否，1-3 (¹) 是
- C) none 仅根据图表中的信息
- D) none
- E) 1-2
- F) none; 3 只是一个常规关联，在前面所述的上下文中并不需要任何额外的东西
- uml-diagrams.org 称此为未指定的可导航性，但是只有当绘图工具支持（或未抑制）所有上述标记（十字、点）时才为真
- G) none;与 D)
齐头并进
- H)全部；基本上与G)
相反
- 我）全部；出于同样的原因与 A) 齐头并进
总而言之：我强烈建议您查看 UML 2.5 specifications 第 11.5.5 节中的示例。
整章 (11.5) 可以给您更多的洞察力，但是如果您只将 UML 视为图表而不是模型，它可能会让人不知所措。
更新回复：依赖关系
The presence of Dependency relationships in a model does not have any runtime semantic implications.
我更深入地了解了规范，这是依赖元模型
据此，客户和供应商都不了解对方；严格来说，该模型确实声明 NamedElement（Class 的超类）知道它依赖于谁（clientDependency），但是其定义如下：
{OCL} result = (Dependency.allInstances()->select(d | d.client->includes(self)))
我称之为废话，因为这样每个不可导航的端点都可以使用相同的方法进行导航。
因此，鉴于此，对于依赖项：
- A) 技术上是的
- B) 技术上没有，但没有什么能真正阻止我使用相同的方法，为什么 A 可导航也使 B 可导航
所以 A+B 都可以解释。
- C) 是和否；取决于解释
根据模型，它没有直接参考，但是模型也说
A Dependency implies that the semantics of the clients are not complete without the suppliers.
...
A Usage is a Dependency in which one NamedElement requires another NamedElement [...] for its full implementation or operation.
所以我不会称它为弱引用，因为客户需要它。事实上 UML 2.5 并没有在规范的相关部分使用一次 weak 这个词（更不用说 weak 参考了），所以这个术语本身有没有意义（可能是在旧版本的UML中使用的）。
- I) 是和否，出于同样的原因；引用是派生的（从其他信息计算得出），但是规范还声明
Actions involving a derived Property behave the same as for a nonderived Property.
总结：依赖是一种想法的表现，而不是一种实现；因此，实际的解释留给使用它的人以及在特定上下文中最有意义的解释。
我保留了原来的答案，在这部分我或多或少地展示了一种非常机械和盲目的约束应用，这通常不是一个好主意。
问题是将给定的 UML 图片与所有可能的描述相结合。
UML 图
一个。可以从 B 导航到 A。
b。可以从 A 导航到 B。
c。 B 对 A 的引用很弱
d。 A是B的一部分。
e。 B 是 A 的一部分。
f。 A 和 B 之间存在不明确的关系。
克。当B不存在了，A就没有存在的理由了。
小时。当B不存在的时候，A还有存在的理由
我。 B 使用 A，但没有对 A 的引用。
我的尝试...
好吧，我已经记不清自己尝试了多少次了。但在我看来，这些描述有些含糊。你可以说它是否适用......最后我这样研究......
- 成分：g,e
- 聚合：e,h
- 行：f,a,b,h
- 依赖性：c,h
- 关联：a,h
而且它仍然不对...也许我对某些我确信的事情是错误的。但是我们的导师显然没有提供足够的material给我们解决这个问题，拒绝给出任何提示。这就是我阅读 post 和来自 google 的文章的程度...有人可以帮助指出错误或遗漏的地方吗？我觉得我要吐了...
从 UML 2.5 的角度来看：
(¹) 我会假设，用于绘制图表的工具没有明确显示关联端所有权或不可导航端，所以我会坚持使用 "common interpretation":
- 如果没有箭头，则两端都属于各自的 Classifier，并且可以导航
- 如果只有一个箭头，则该方向属于 Classifier 并且可以导航；另一端归协会所有，不可通航
高级 UML 工具可以通过在末尾添加黑点或小十字来明确区分，分别说明谁拥有关联以及它是否可导航。
- A) 4-5 是，1-3 是 (¹)
- B) 4-5 (¹) 否，1-3 (¹) 是
- C) none 仅根据图表中的信息
- D) none
- E) 1-2
- F) none; 3 只是一个常规关联，在前面所述的上下文中并不需要任何额外的东西
- uml-diagrams.org 称此为未指定的可导航性，但是只有当绘图工具支持（或未抑制）所有上述标记（十字、点）时才为真
- G) none;与 D) 齐头并进
- H)全部；基本上与G) 相反
- 我）全部；出于同样的原因与 A) 齐头并进
总而言之：我强烈建议您查看 UML 2.5 specifications 第 11.5.5 节中的示例。 整章 (11.5) 可以给您更多的洞察力，但是如果您只将 UML 视为图表而不是模型，它可能会让人不知所措。
更新回复：依赖关系
The presence of Dependency relationships in a model does not have any runtime semantic implications.
我更深入地了解了规范，这是依赖元模型
据此，客户和供应商都不了解对方；严格来说，该模型确实声明 NamedElement（Class 的超类）知道它依赖于谁（clientDependency），但是其定义如下：
{OCL} result = (Dependency.allInstances()->select(d | d.client->includes(self)))
我称之为废话，因为这样每个不可导航的端点都可以使用相同的方法进行导航。
因此，鉴于此，对于依赖项：
- A) 技术上是的
- B) 技术上没有，但没有什么能真正阻止我使用相同的方法，为什么 A 可导航也使 B 可导航
所以 A+B 都可以解释。
- C) 是和否；取决于解释
根据模型，它没有直接参考，但是模型也说
A Dependency implies that the semantics of the clients are not complete without the suppliers. ... A Usage is a Dependency in which one NamedElement requires another NamedElement [...] for its full implementation or operation.
所以我不会称它为弱引用，因为客户需要它。事实上 UML 2.5 并没有在规范的相关部分使用一次 weak 这个词（更不用说 weak 参考了），所以这个术语本身有没有意义（可能是在旧版本的UML中使用的）。
- I) 是和否，出于同样的原因；引用是派生的（从其他信息计算得出），但是规范还声明
Actions involving a derived Property behave the same as for a nonderived Property.
总结：依赖是一种想法的表现，而不是一种实现；因此，实际的解释留给使用它的人以及在特定上下文中最有意义的解释。
我保留了原来的答案，在这部分我或多或少地展示了一种非常机械和盲目的约束应用，这通常不是一个好主意。