聚合或组合或简单的关联？

有一个例子来解释UML中的关联。聚合或组合或简单的关联？

一个人在一家公司工作;一家公司有多个办事处。

但我无法理解Person，Company和Office类之间的关系。我的理解是：

公司由许多人作为员工，但这些类独立存在，这样才符合0简单关联.. *在Person类端多重
一家公司有许多办公室和这些办事处如果没有公司，那么就不存在公司，因此公司是作为父类的组合，并且在Branch类'结尾处具有0 .. *多重性。

但我不确定第二点。如果我错了，请纠正我。

谢谢。

来源

2016-03-19 RashiR

您是对问题域还是解决方案域进行建模？这很重要。 –

这有什么关系？我正在执行给定陈述的解决方案。 – RashiR

问题域模型代表真实世界。在现实世界中，当一家公司倒闭时，各局不会停止存在。由于您正在对解决方案域进行建模，因此您可以自由地为特定应用程序采取某些快捷方式。但是，您可能会因为要求“改变”而后悔。（问题领域并没有真正改变，只有应用程序允许的快捷方式！对于你留下的问题领域更真实，以后每个人都会更开心。） –

为什么在这种情况下使用组合或聚合？ UML规范给建模者留下了聚合的含义。你希望它对观众意味着什么？对于这种情况，构图的意义可能太强大了。那么，为什么在这里使用它？我建议你使用一个简单的关联。

如果我是你，我会更真实地解决问题领域。在我所知的世界里，当公司停业时，办事处不会停止存在。相反，公司占用某些数量的办公室一段有限的时间。如果一家公司倒闭，这些办事处被出售或出租给其他公司。办事处不会烧毁在地上。

如果您在应用程序中的问题域不正确，那么当客户“更改该应用程序的需求”时，所采用的快捷方式将变为无效。问题域实际上并没有太大的改变，只是你允许采取的捷径。如果您采用快捷方式以与问题域错开的方式满足要求，则调整应用程序的开销很大。你的客户变得不开心，你会加班加点。为自己和每个人保存麻烦！

来源

2016-03-20 02:39:24

虽然Jim的回答是正确的，但我想添加一些额外的信息。还有用于聚集

内存管理
数据库管理

在第一种情况下，两个主要用途它给出了一个暗示多久对象应居住。这与内存使用情况直接相关。如果目标语言（如大多数现代语言）使用垃圾收集器，则可以简单地忽略此模型信息。

在第二种情况下，这只是部分记忆问题。数据库中的合成聚合指示聚合元素需要与聚合元素一起删除。这不是一个记忆，但在大多数情况下是一个安全问题。所以在这里你必须考虑三次。

然而，共享聚合在所有情况下都具有非常深奥的含义。

来源

2016-03-20 10:22:41

聚合或组合或简单的关联？

回答

相关问题