UML关系

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

UML图

a。可以从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没有引用

我的尝试

我记不清我试过多少次了。但在我看来，这些描述有些模糊。你可以说它适用或不适用…最后我研究了这样的东西

组成：g，e

聚合：e，h

行：f、a、b、h

依赖关系：c，h

协会：a，h

---

而且ofc仍然不正确……也许我对某些我确信的事情错了。但我们的导师显然没有为我们提供足够的材料来解决这个问题，并且拒绝给出任何暗示。这就是我阅读谷歌的帖子和文章的程度……有人能帮我指出哪里错了或遗漏了什么吗？从UML 2.5的角度来看，我觉得我要吐了……

：

（1）我假设，用于绘制图表的工具没有明确显示关联端所有权或不可导航端，因此我将坚持“通用解释”：

• 如果不存在箭头，则两端都属于相应的分类器，并且可以导航
• 如果只存在一个箭头，则该方向由分类器所有，且可导航；另一端为协会所有，不可导航

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

• A） 4-5是，1-3是（1）
• B） 4-5（1）为否，1-3（1）为是
• C） 仅基于图表中的信息，无一个
• D） 没有
• E） 1-2
• F） 没有；3只是一个常规的关联，在前面提到的上下文中，它并不需要任何额外的东西
  • 调用此未指定的可导航性，但是，只有当图表工具支持（或未抑制）上述所有标记（十字、点）时，此选项才为真
• G） 没有；与D携手共进）
• H） 全部；基本上与G相反）
• 一） 全部；与A）出于同样的原因

最后：我强烈建议大家看一下第11.5.5节中的示例。 整个章节（11.5）可以给你更多的洞察力，但是如果你只把UML看作是图表，而不是模型，那么它可能会让你感到非常震惊

---

更新相关信息：依赖关系

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

我更深入地研究了规范，这里是依赖项元模型

根据这一点，在依赖关系中，客户和供应商都不了解对方；严格地说，模型确实声明NamedElement（类的超类）知道它依赖于谁（clientDependency），但定义如下：

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

在这一点上我称之为胡说八道，因为这样一来，每个不可导航的端都可以用同样的方法进行导航

因此，鉴于此，对于依赖关系：

• A） 是的，从技术上来说
• B） 从技术上说不是，但没有什么能真正阻止我使用相同的方法，为什么A是可导航的，而B也是可导航的

因此，A+B两者都有一定的解释余地

• C） 是与否；取决于解释

根据模型，它不具有直接的参考，但是模型也说

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

所以我不会称之为弱引用，因为客户需要它。事实上，UML2.5在规范的相关部分中没有使用过弱这个词（更不用说弱引用了），所以这个术语本身没有任何意义（可能是在旧版本的UML中使用的）

• 一） 是与否，原因完全相同；参考是派生的（根据其他信息计算），但规格也说明

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

总结：依赖性是一种想法的表现，而不是一种实现；因此，实际的解释留给使用它的人，以及在特定语境中最有意义的东西

---

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

从UML 2.5的角度来看：

（1）我假设，用于绘制图表的工具没有明确显示关联端所有权或不可导航端，因此我将坚持“通用解释”：

• 如果不存在箭头，则两端都属于相应的分类器，并且可以导航
• 如果只存在一个箭头，则该方向由分类器所有，且可导航；另一端为协会所有，不可导航

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

• A） 4-5是，1-3是（1）
• B） 4-5（1）为否，1-3（1）为是
• C） 仅基于图表中的信息，无一个
• D） 没有
• E） 1-2
• F） 没有；3只是一个普通的社团