Uml 聚合与合成

我想知道

人类

和

驾照

之间的关系是聚合还是合成？我很清楚，

房间

和

建筑

关系是一种组合，

椅子

和

房间

是一种聚合。但是

驾照

可以没有

人

存在，但是没有

人

就没有意义。我被卡住了。

我认为要回答这个问题中的疑问，我们应该准确地定义以下术语：

上下文

实例在上下文中的存在性

如果上述术语定义准确，那么使用合成或聚合是毫无疑问的

我的想法，如果我想问这个问题，在我对术语的具体定义中：

背景：现实世界

实例的存在和销毁：实例的有用性与它的存在无关。摧毁它意味着使它无效。我们应该在主人消失后使它失效。（但我们不会立即这样做

因此，

人类

与

驾照

之间的关系不可能是现实世界背景下的一种组合。因为，通过毁灭一个

人类

（消失，失去生命，…），我们不会立即毁灭

驾照

。它存在

例如（在某些国家/地区），没有任何在线和最新的失效机制来立即失效

驾照

，因此它可以在没有

驾驶员的情况下存在，直到我们将其失效为止。所以在这段时间内（从
司机消失到
驾照失效）它是存在的，实例的有用性与它的存在无关。再次注意：这是我对语境和存在的定义

编辑（基于@Thomas Kilian的评论）：

例如，在编程及其技术（如ORM）的上下文中，我们应该在删除
驱动程序
的实例后立即删除
驱动程序许可证
（我们可以在这种上下文中执行此操作）。因此，这种关系应该是一种组合



最后：我想指出建模中术语定义（上下文、现有术语和其他相关术语）的重要性。如果我们不准确地定义它们，问题就会出现许多解决方案（基于他们心中隐藏的定义）

希望能有所帮助。
由于驾照不是人的一部分，而是与人的关系，两者之间既没有组合，也没有聚合，只有简单的关联

Gholamali Irani的回答混淆了驾驶执照必须与一个人（即，相应的关联端有一个确切的多重数）相关联的事实和许多组合的（或有）特征有不可分割的部分，并错误地得出结论，该组合必须是一个组合

在许多情况下，我们可能会怀疑关联是否是一个组合，将其建模为普通关联更安全

将关联（如
Human
-has-
DriverLicense
）建模为组合的唯一好理由是当组件类型的实例（此处为驱动程序许可证）是没有自己身份的“弱实体”时。但是驾照确实有自己的ID，因此没有必要也没有好处将其建模为其持有者的组件。
聚合意味着子级可以独立于父级存在。示例：班级（家长）和学生（孩子）。删除该类，学生仍然存在

聚合示例：

需要注意的是，聚合链接并没有以任何方式声明类A拥有类B，也没有声明二者之间存在父子关系（当父对象删除其所有子对象时，其结果将被删除）。事实上，恰恰相反！聚合链接通常用于强调类A实例不是类B实例的独占容器，因为实际上同一个类B实例有另一个容器


合成示例：

我们应该更具体一些，在除了类A和类B之间的部分关系之外的情况下使用组合链接，这两个类之间存在很强的生命周期依赖性，这意味着当删除类A时，也会删除类B


组合意味着子对象不能独立于父对象而存在的关系。示例：房子（家长）和房间（孩子）。房间不是与房子分开存在的


这里有一些额外的信息来阐述构图的概念

正如《UML用户指南》中所述，Addison Wesley

然而，有一种简单聚合的变体-组合-，它确实添加了一些重要的语义。组合是一种聚合形式，具有很强的所有权和作为整体一部分的重合寿命具有非固定多重性的零件可以在复合材料本身之后创建，但一旦创建，它们就会与复合材料一起生存和死亡。此类零件也可以在复合材料死亡之前明确移除

此外，在复合聚合中，整体负责其部分的处置，这意味着复合必须管理其部分的创建和销毁。例如，在窗口系统中创建框架时，必须将其附着到封闭窗口类似地，当您销毁