Uml 在依赖性、关联性、聚合性和构造性之间做出决定时，要考虑正确的概念层次吗？

说得很清楚：我不是在问这四种联想之间的区别。我知道已经有很多问题被问到了。不幸的是，对于这些问题中的每一个，都有十几个似是而非但不同的答案，因为每个答案都基于对系统的不同概念层面的思考

换句话说：关于这些概念的一些描述（在教科书上，等等，以及在互联网上）只从系统的高级概念视图的角度来描述。他们说：“因为没有建筑，房间就不可能存在，所以建筑是由房间组成的。”

另一方面，另一些人仅从内存中对象的实际运行时存在性的角度来讨论。比如说，“如果删除建筑对象时删除了房间对象，那么建筑就是由房间组成的。”（在任何人加入之前，这两者之间有区别。如果另一个对象包含对该房间对象的引用（或者你的析构函数在C++中不够彻底），那么房间对象仍然可以存在于内存中。）同样，面向运行时的解释者也会这样说，“如果ClassA‘持有’对ClassB的引用，但是ClassB在没有ClassA的情况下仍然存在，那么ClassB‘聚合到’ClassA中。”从技术上讲，这只是“房间对象/建筑对象”的另一面硬币，因为房间对象可能独立于建筑对象存在于内存中，而与房间在现实世界中的行为无关

甚至有人说Java根本不可能有任何组合，因为“组合成”建筑对象的所有房间对象实际上只是引用，所以它们存在于堆上，在“组合”房间对象的内存空间之外，即使删除建筑对象后，该房间对象可能会注定要进行垃圾收集。如果有人想对一些事情产生这样的不满，我可以说一个真正的房间可以在没有真正的建筑的情况下存在，因为有可能把一个真正的建筑拆掉，只留下一个房间

因此，正如您所看到的，建筑对象是这些房间对象的组合还是聚合完全取决于您的特定实现，编码中的一个错误可能会将其从一个转换到另一个。有些事情告诉我，UML并不意味着要达到那种详细程度和特殊性。这就是代码的用途

所以，我的问题涉及到UML的基本目的：当创建UML图时，我是否应该只考虑房间和建筑物的更高概念层次？或者我应该考虑我计划如何实现这个特定的代码

我的问题也是关于<强>意见> <强> >关于<强>应该是正确的概念层次。我想知道是否有一个公认的行业标准。如果没有公认的行业标准，就这么说吧。如果行业标准只是人们自己决定他们考虑的级别，那么就这么说吧。如果没有关于是否有行业标准的行业标准，那么也请说明

---

我很清楚，这个问题的答案很容易转化为意见。请尽量避免这样。我想知道是否有现有的规范（或真正权威的作者）规定了一种或另一种方式。

实际上，使用UML并不意味着有一个明确的抽象级别。UML将适用于几乎所有的抽象级别。人们所做的是构建一个称为（以及许多类似/更复杂的）的过程。在这里，您可以处理不同的抽象级别。事实上，一个组合的语义在3个抽象层中是不同的。在较低层，您可以（/可以）将其用于房间/建筑的解释，而在混凝土层，您可以将其解释为内存处理。在任何情况下，都应该有一个（元）模型文档来解释组合的使用

所以。。因为UML并没有指定“抽象级别”，所以我可以自由选择适合这个特定图表的。而且，最佳实践建议我在图中保持一致，并在图中记录抽象级别。对吗？我认为这是一条路。@GeertBellekens你可能是对的，尽管标准没有留下讨论的空间。我把它取下来。