要非常明确：我不是要问这四种关联之间的区别。我知道有很多问题已经问到过。不幸的是，对于这些问题中的每一个都有十几个看似合理但不同的答案，因为每个答案都是基于对不同概念层面的系统的思考。
换句话说：关于这些概念的一些描述（在教科书中，在SO上，以及在整个互联网上）仅仅表示系统的高级概念视图。他们说，“因为如果没有建筑物，房间就不可能存在，那么建筑就是'组成'的房间。”
另一方面，其他人仅仅根据内存中对象的实际运行时存在来说话。比如说，“如果删除Building对象时将删除Room对象，那么Building将由Room组成。” （在任何人跳入之前，两者之间存在区别。如果另一个对象持有对该Room对象的引用（或者你的析构函数在C ++中不够彻底），那么Room对象仍然可以存在于内存中。）同样的面向运行时的解释器也会说“如果ClassA'拥有'对ClassB的引用，但ClassB仍然可以在没有ClassA的情况下存在，那么ClassB'会聚合到'ClassA'中。”从技术上讲，这只是“房间对象/建筑对象”硬币的另一面，因为Room对象可能独立于该Building对象而存在于内存中，而不管房间在现实世界中应该如何表现的概念概念。
甚至有人说Java根本不可能有任何组合，因为所有“组成”构建对象的Room对象实际上只是引用，所以它们存在于堆上，存在于“组合”的内存空间之外房间对象，即使在删除Building对象后，Room对象可能注定要进行垃圾回收。如果一个人想要获得关于事物的picayune，我可以说真正的房间可以存在而没有真正的建筑物，因为它可以撕毁一个真正的建筑物，只留下一个房间。
因此，正如您所看到的，构建对象是组合还是这些Room对象的聚合完全取决于您的特定实现，编码中的单个错误可以将其从一个切换到另一个。有些事情告诉我，UML并不意味着要达到这种程度的细节和特异性。这就是代码的用途。
所以，我的问题是UML的基本目的：在创建UML图时，我是否应该只考虑房间和建筑物的更高概念层次？或者我是否应该考虑如何实施此特定代码？
我的问题也不是关于你应该考虑什么样的正确概念水平的意见。我想知道是否有一个公认的行业标准。如果没有公认的行业标准，那就这么说吧。如果行业标准只是人们自己决定他们正在考虑什么级别，那就这么说吧。如果没有关于是否存在行业标准的行业标准，那么也要说明这一点。
我很清楚这个问题的答案很容易转化为意见。请尽量避免这种情况。我想知道是否存在指定这种或那种方式的现有规范（或真正的权威作者）。
实际上，使用UML并不意味着具有不同的抽象级别。 UML几乎适用于所有抽象级别。人们所做的是建立一个名为Model Driven Architecture的流程（以及许多类似/更复杂的流程）。在那里你处理不同的抽象级别。事实上，组合的语义在3个抽象层中是不同的。在较低的杠杆中，您可以（/可能）将它与您的房间/建筑物解释一起使用，而在混凝土层上，您可以将其解释为内存处理。在任何情况下，都应该有一个（meta）模型文档来解释组合的使用。