Question

我会使用Association for interfaces，因为我无法实例化它们。就像他们这样做here。或者对于静态类，原因相同。

我只使用可以实例化的物体的钻石。像普通班一样。

但我不确定这是否是区分它们的正确方法，因为如果你再次check，你会发现它们并没有那么具体。在UML 2.3 specification中我无法获得更多信息，那你是如何使用它的呢？

还有第三种方式，虚线＆lt;＆gt;箭头，但我没有胶水何时使用这个。那么也许你也可以帮助我呢？

Answer 1

我会使用Association for interfaces，因为我无法实例化它们。就像他们在这里做的那样。或者对于静态类，原因相同。

我只使用可以实例化的物体的钻石。像普通班一样。

这不是他们的工作方式。三种形式（关联，聚合和组合）定义了关系的不同属性。所有这三个通常在类之间使用，但也可以与接口相关。协会和作文是最容易的两个：

关联（无钻石）是最常见的形式，允许在两端定义基数和导航性。
组合物（实心钻石）是一个整体关系，其中“整体”（以黑色钻石结尾）“包含”该部分。它强加了两个关键限制：
1. 只能有1个容器（即整个基数的基数正好是1）;
2. 它对整个部件施加了生命周期责任。因此容器负责创建和删除部件。如果删除了容器，则部件不能继续存在。

聚合（未填充的钻石）位于中间的某个位置。它有点像组合 - 除了它不强制要求上述属性。我不亲自使用它。语义太不清楚，因为它值得。

还有第三种方式，虚线＆lt;＆gt;箭头，但我没有胶水何时使用这个。

我认为你的意思是依赖关系。这是一种较弱的关联形式。例如，采用以下类定义

class Foo {

 def bar(Baz: aParam) {
  ...
 }
}

在这种情况下，类型Foo与bar（）方法签名中使用的类型Baz有依赖关系。然而，它们之间没有关联（不能明智地讨论例如Foo实例和Baz实例之间关系的基数）。

从实际角度来说，我会说：

第h

Answer 2

让我们设定条款。 Aggregation是UML标准中的元项，意味着BOTH组合和共享聚合，简称为 shared 。它经常被错误地命名为“聚合”。它是坏的，因为组合也是聚合。据我了解，您的意思是“共享”。

进一步来自UML标准：

composite - 表示属性是复合聚合的，即复合对象对存在和存在负责存储组合对象（部分）。

所以，大学到cathedras协会是一个组合，因为大学（IMHO）不存在大教堂

共享聚合的精确语义因应用领域而异建模器。

即，如果您只遵循您或其他人的某些原则，则可以将所有其他关联绘制为共享聚合。另请查看here。