UML类图关联 vs （聚合|组合）-菱形

Question

我不确定我是否正确地使用了关联和聚合或组合钻石。对于接口，我会使用关联，因为我无法实例化它们。就像他们在这里所做的那样。或者对于静态类，同样的原因。我只使用钻石来表示可以实例化的对象。就像普通类一样。但是我不确定这是否是区分它们的正确方式，因为如果你再检查一下，你会发现他们没有那么具体。在UML 2.3 规范中，我找不到更多信息，所以你是如何使用它的呢？还有第三种方式，虚线<>箭头，但我不知道什么时候使用它。所以也许你可以帮我解决这个问题？

- Christian

Answer 1

我会在接口中使用关联（Association），因为我无法实例化它们。就像这里的例子一样。或者对于静态类，同样的原因。而对于可以实例化的对象，我只会使用钻石标记（diamonds），例如普通的类。

这并不是它们的真正作用方式。三种形式（关联、聚合和组合）定义了关系的不同属性。虽然也可以将它们之间的关系应用于接口，但通常情况下，它们都是用于类之间的关系。关联和组合是两个最基本的：

- 关联（没有钻石标记）是最一般的形式，允许在两端定义基数和可导性。 - 组合（填充的钻石标记）是整体-部分的关系，其中“整体”（黑色钻石结尾的那一端）“包含”部分。它强制执行两个关键限制： - 只能有一个容器（即整体端的基数恰好为1）； - 它为整体负责创建和删除部分的生命周期。如果删除了容器，则部分将不能继续存在。 - 聚合（未填充的钻石标记）位于中间位置。它有点像组合，但不强制执行上述属性。我个人不使用它。其语义太不清晰，不值得使用。

还有一种方式是虚线箭头（dashed lined <> arrow），但我不知道在什么情况下使用它。

我认为您指的是依赖关系。它是关联关系的一种较弱形式。例如，考虑以下类定义：

class Foo {

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

在这种情况下，类型Foo对其在bar()方法签名中使用的类型Baz具有依赖关系。但是它们之间没有关联（例如无法明智地讨论Foo实例和Baz实例之间的关系基数）。

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

• 您可以为80％以上可能要建模的关系使用直接关联
• 组合可能占据了大部分剩余的场景
• 依赖关系在某些情况下可能很有用
• 您可以很愉快地不使用聚合而过得很好。

希望对你有所帮助。

- sfinnie

Answer 2

让我们来明确一下术语。在UML标准中，聚合是一个元术语，表示组合和共享聚合，简称为共享。它经常被错误地称为“聚合”，这是不好的，因为组合也是一种聚合。据我理解，你的意思是“共享”。

进一步来自UML标准：

组合 - 表示属性被组合地聚合，即组合对象对所组成的对象（部分）的存在和存储负有责任。

因此，大学与教师协会是一种组合，因为教师协会不存在于大学之外（依我之见）

共享聚合的精确定义因应用领域和建模者而异。

也就是说，如果你只遵循自己或他人的某些原则，所有其他关联都可以被画成共享聚合。另请参阅此处。

- Gangnus