非常清楚：我不询问这四种关联类型之间的区别。我知道已经有很多问题要问。不幸的是，对于每个问题，都有十二个合理但不同的答案，因为每个答案都基于在不同概念级别上对系统的思考。
换句话说：关于这些概念的某些描述（在教科书中，在SO上以及整个互联网）都仅从系统的高级概念视图的角度讲。他们说：“因为没有建筑物，就不可能有房间，那么建筑物就是房间的'组成'。”
另一方面，其他人仅根据对象在内存中的实际运行时状态发言。这样说，“如果在删除建筑物对象时将删除房间对象，则建筑物是房间的'组成'。” （在任何人跳入之前，两者之间是有区别的。如果另一个对象持有对该Room对象的引用（或者您的析构函数在C ++中不够彻底），则该Room对象可能仍存在于内存中。）面向运行时的解释器也会说：“如果ClassA'持有'对ClassB的引用，但是如果没有ClassA，则ClassB仍然存在，则ClassB被'聚合为'ClassA。”从技术上讲，这只是“房间对象/建筑物对象”硬币的另一面，因为无论对象关于应该如何工作的概念性观念，房间对象都可能独立于该建筑物对象而存在于内存中现实中。
甚至有人说Java根本不可能进行任何组合，因为所有“组合到” Building对象中的Room对象实际上只是引用，因此它们存在于堆中，位于该对象的内存空间之外“组合” Room对象，即使一旦删除Building对象，该Room对象可能注定要进行垃圾回收。如果要对事物进行微妙的描述，我可以说一间真正的房间可以不存在一栋真正的建筑物而存在，因为可以将一栋真正的建筑物倒掉，而只剩下一间房间。
因此，如您所见，该Building对象是这些Room对象的组合还是聚合完全取决于您的特定实现，并且编码中的单个错误可能会将其从一个切换到另一个。某些事情告诉我，UML并非旨在达到如此详细和特定的水平。这就是代码的用途。
因此，我的问题涉及到UML的基本目的：在创建UML图时，我是否应该只考虑总体上更高的房间和建筑物的概念级别？还是我应该在考虑如何计划实施此特定代码？
关于您的意见，应该应该考虑的正确概念级别，我的问题也不是。我想知道是否有接受的行业标准。如果没有公认的行业标准，那就这么说。如果行业标准只是人们自己决定要考虑的级别，那就这么说。如果没有关于是否存在行业标准的行业标准，则也要说明。
我很清楚，这个问题的答案很容易演变成观点。请尝试避免这种情况。我想知道是否存在指定一种或另一种方式的现有规范（或真正权威的作者）。
答案 0 :(得分：3)
实际上，使用UML并不意味着具有不同的抽象级别。 UML将适用于几乎所有抽象级别。人们所做的就是建立一个名为Model Driven Architecture的流程（以及许多类似/更复杂的流程）。在那里您处理不同的抽象级别。确实，合成的语义在3个抽象层中会有所不同。在较低的控制杆中，您可以（可以）将其与房间/建筑物的解释一起使用，而在混凝土层上，可以将其解释为用于内存处理。无论如何，应该有一个（元）模型文档来说明合成的用法。