UML类关系

Question

在确定常见的UML类关系时，我想确认自己是否走在正确的轨道上。例如，是：

之间的关系

1 stackoverflow成员和他/她的stackoverflow用户帐户被分类为组合关系或聚合关系？起初我认为这是一个协会，因为这个成员“有一个”帐户。然而，在第二个想法，我正在考虑它的组成，因为每个“部分”（用户帐户）一次只属于一个整体（用户），这意味着只要我登录到stackoverflow，我必须使用这一个而且只有帐户，直到我注销。如果我使用不同的帐户重新登录到stackoverflow，那么它的组成将再次出现。你同意吗？

2 数据库与个人用户帐户的聚合关系？我是这么认为的，因为1个数据库（整个）可以存储0 ... *用户帐户（部分）的数量，但另一个数据库可以存储相同的用户帐户。

最后，任何人都可以推荐一个专门使用UML设计代码的网站吗？ 提前致谢

Answer 1

  

stackoverflow成员和他/她的stackoverflow用户帐户被分类为组合关系或聚合关系？

好吧，让我们看看下图

• 聚合

可以移植

如果我想念一些手指，那么其他手可以接收我失踪的手指

---

• 组合物

移植是不可能的

如果我想念一些手指，那么没有其他手可以接收我失踪的手指

聚合和组合，手指（部分）的生命周期与其拥有的实体实例的生命周期（如果我想念我的手，那么它的手指将被遗漏）所以，如果我删除我的Stackoverflow会员，其UserAccount将被删除。

回到你的问题：你的UserAccount，虽然它的生命周期绑定到Stackoverflow会员，如果错过，可以分配给另一个Stackoverflow会员??? 我不这么认为。所以，它是组合

Answer 2

UML规范在聚合与组合定义方面不一致。正如几位作者（亨德森 - 塞勒斯等人）所表明的那样，它们没有得到恰当的定义。我建议你不要浪费你的时间来确定你脑海中的某些东西是否最能映射到其中一个。没有正确的答案。 ： - ）

我自己，我经常使用抽象的整体/部分关系来模拟整体和部分。关于绑定，生命周期和排他性的语义可以通过伪代码或注释给出。有许多不同的案例和场景试图预先预测所有可能性是不值得的。 编辑：这种方法是Henderson-Sellers和我自己在几年前的早期版本的UML评审期间向OMG提出的。不幸的是，它没有成功。 ： - ）

即使UML是连贯的，也没有正确或错误的模型;有些模型很有用，有些则没有。您创建模型取决于您追求的目的。

Answer 3

UML最好的书是Martin Fowler的“UML Distilled”。这是第三版，所以经得起时间的考验。它具有包含良好信息和剩余瘦的罕见优点。

它对聚合与关联进行了很好的讨论。

Martin Fowler也对不同的UML阵营有一些好的想法：MDA与“草图”。我坚定地参与了草图营地：不要过于依赖UML来制作工程图纸。它只是一种通讯设备。

Answer 4

聚合：弱'有' 组成：强'有''

Answer 5

我用来记住的约定是哪个复合关系意味着包含的实例在没有它的封闭类型的情况下不能存在，而在聚合关系中，对象可以存在而没有封闭类型 举个例子：

• 汽车'有'4.Wheels（聚合）

• 汽车车辆识别号码是'汽车（组成）的一部分

（垃圾示例，但我能想到的最好的事情：）

Answer 6

此附加信息仅在UML中可用，因为您无法查看聚合和组合之间Java代码的差异。所以我不同意聚合与构图不是一个好主意，因为这些信息对项目质量很重要!!