为什么关联,聚合和组合使用的方式与本例中的使用方式相同?

时间:2016-10-19 21:03:43

标签: uml aggregation

我理解三者之间的差异(或者至少我认为我这样做)。我知道还有很多其他类似的问题,例如one

我正在寻找gliffy.com的一个例子,我很沮丧地理解为什么使用它们的方式使用了一些关系。我想我真正努力的是了解何时使用关联。

我遇到的一些问题是:

  1. 为什么客户订单和客户信用卡是一个不是像客户地址一样的聚合?
  2. 如果没有订单,ItemOrder将不存在,为什么Order-ItemOrder不是组合?
  3. 为什么ItemOrder-Item不聚合?
  4. Online Golf store UML

2 个答案:

答案 0 :(得分:3)

为了回答这些问题,重要的是要知道绘制这个类图的原因。只有作者知道,但也许它只是一个gliffy功能的演示?否则,也许这个模型中的类对应于源代码中的类,用面向对象的语言(如Java或C#)编写,并且该图旨在深入了解这些类之间的关系。

  1. 为什么客户订单和客户信用卡是关联而非聚合,如客户地址?

    显然,作者并不认为这些关系是'的一部分。关系。也许客户在源代码中没有对Orders或CreditCards的任何引用。也许地址信息属于客户类的责任,但订单和信用卡信息不属于。

  2. 为什么Order-ItemOrder没有给定如果没有订单就不存在ItemOrder?

    也许作者只使用UML的一个子集,并且不按惯例使用合成。也许作者认为聚合和组合之间的区别对于此图的目的来说并不重要。

  3. 为什么ItemOrder-Item不聚合?

    显然,作者并不认为这种关系是一种关系的一部分。也许作者保留了聚合类型的关系来表示一种特定的编程语言结构,在这种情况下,源代码中没有使用它。也许作者认为界面永远不能在另一个类中聚合。

  4. 顺便说一下,ItemOrder和ShoppingCart之间的聚合显然是错误的。我认为钻石应该是关系的另一面。

答案 1 :(得分:-1)

简单地忘记共享/复合聚合。它确实具有较低的语义,只会导致无论是否需要以及使用对错的地方都是徒劳的讨论。只需使用(并解释)关联和多重性。

(几乎)只能以有意义的方式使用聚合的地方是DB外键(强制删除)和内存(免费未使用)管理。