UML 表示法 - 聚合/组合与 "Vanilla"关联

Question

我最近花了大量时间对我编写的各种软件组件进行详细的 UML 设计。回顾我最近完成的工作并将其与我第一次学习 UML 时进行比较，我发现我现在几乎严格使用聚合和组合关系，并且实际上已经放弃了“普通”非定向/定向关系。我当然仍然使用泛化和实现，但是这些与上面的明显不同，并且不被视为这个问题的一部分。

在我看来，聚合/组合意味着“ Vanilla ”关联的相同含义，等等。聚合和组合自然意味着一个方向，任何现代 UML 程序仍将允许您在聚合/组合关系上定义多重性，并将动词应用于该关系。在这一点上，我认为 Vanilla 协会没有什么意义。

我知道有些人很难理解聚合和组合之间的区别。早些时候，我有点难以理解它们的不同之处，我相信混淆是我使用原版联想的部分原因。我现在认为普通关联很少或没有用处，实际上不喜欢看到它们被使用，因为我相信它们留下了一些问题(特别是两个对象之间的强或弱生命周期关系)。我相信普通关联的唯一实际用途是当您对手头问题的理解尚未发展到足以确定聚合和组合之间的生命周期差异时。在这种情况下，最好至少表明这种关系存在，然后当您对手头的问题有了更好的了解时，可以回来并适本地更改它。

长话短说，我相信在人们使用普通联想的绝大多数时候，它们可以更准确地描述为聚合，有时也可以描述为组合。我的信仰是不是大错特错？我错过了什么吗？让我听听!

Answer 1

实际上，UML 类模型中的大多数关联情况既不是聚合也不是组合。例如，类之间的关联Publisher和 Book将出版商出版的书籍分配给该出版商既不是聚合也不是组合，因为出版商出版的书籍不是该出版商的一部分或组成部分。



聚合是一种特殊形式的关联，具有部分整体关系的预期含义，但没有精确的语义(UML 规范说:“共享聚合的精确语义因应用程序领域和建模者而异”)。例如，我们可以对类 Car 之间的聚合进行建模。和 Engine和类之间 Course和 Lecture因为发动机是汽车的一部分，而讲座是类(class)的一部分。

组合(在 UML 规范中也称为“复合聚合”)是一种特殊的聚合形式，其中一个组件实例一次最多是一个聚合实例的一部分(也就是说，它不能在多个聚合之间共享)。这意味着 Car 之间的聚合和 Engine是一个组合(因为引擎不能同时在两辆车之间共享)，而 Course 之间的聚合和 Lecture不一定是作文，因为一个讲座可以在两门类(class)之间共享(例如，数据库管理类(class)和软件工程类(class)可以共享关于 UML 的讲座)。这意味着在聚合端的组合关联端的多重性是 1 或 0..1，而在非复合聚合的情况下，它也可能是 *。

除了组合的主要特征(具有独占部分)之外，组合还可能带有聚合与其组件之间的生命周期依赖性，这意味着当删除聚合时，其所有部分也随之删除。但是，这仅适用于某些构图情况，不适用于其他情况，因此它不是一个定义特征。 UML 规范指出:“在删除复合实例之前，可以从复合实例中删除一部分，因此不会作为复合实例的一部分删除。”在我们的 Car-Engine 组合示例中，显然可以在汽车被毁坏之前将发动机从汽车上拆下，在这种情况下，发动机不会被毁坏并且可以重新使用。