uml - 在依赖、关联、聚合和组合之间做出决定时要考虑的正确概念级别？

Question

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

换句话说：关于这些概念的一些描述（包括在教科书、SO 和整个互联网上）仅根据系统的高级概念视图进行说明。他们说，“因为没有建筑物就不可能存在房间，所以建筑物是由房间‘组成’的。”

另一方面，其他人只谈论内存中对象的实际运行时存在。说诸如“如果在删除 Building 对象时会删除 Room 对象，那么 Building 是由 Room‘组合’。” （在任何人介入之前，两者之间存在区别。如果另一个对象持有对该 Room 对象的引用（或者您的析构函数在 C++ 中不够彻底），那么该 Room 对象可能仍然存在于内存中。）那些相同，面向运行时，解释者也会说，“如果 ClassA '持有'对 ClassB 的引用，但 ClassB 在没有 ClassA 的情况下仍然存在，那么 ClassB 被'聚合到' ClassA 中。” 从技术上讲，这只是“房间对象/建筑对象”的另一面应该在现实世界中表现。

甚至有人说 Java 根本不可能有任何组合，因为“组合成”一个 Building 对象的所有 Room 对象实际上只是引用，所以它们存在于堆上，在“组合”的内存空间之外Room 对象，即使在删除 Building 对象后该 Room 对象可能注定要进行垃圾回收。如果有人要对事情有那么大的了解，我可以说没有真正的建筑物也可以存在一个真正的房间，因为可以将一座真正的建筑物拆除，只留下一个房间。

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

所以，我的问题是关于 UML 的基本目的：在创建 UML 图时，我是否应该只考虑房间和建筑物的更高概念级别？还是我应该考虑我打算如何实现这个特定的代码？

我的问题也不是关于您对应该考虑的正确概念级别的看法。我想知道是否有一个公认的行业标准。如果没有公认的行业标准，就这么说吧。如果行业标准只是人们自己决定他们正在考虑的级别，那就这么说吧。如果没有关于是否有行业标准的行业标准，那么也只需说明这一点。

我很清楚这个问题的答案很容易变成意见。请尽量避免这种情况。我想知道是否存在指定一种或另一种方式的现有规范（或真正权威的作者）。

标签： umlclass-diagram

Answer 1

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