UML聚合与关联

在这里,我还有另外一个关于聚合和关联的问题。 我想学习一些UML的基础知识,所以我开始阅读Martin Fowler的“UML蒸馏”。 我读了关于课程的两章,有一个我不能完全理解的东西我认为,那就是聚合与结合。 书中有这样的引语:

在UML之前的日子里,人们对于什么是聚合和什么是关联通常比较模糊。 无论是否模糊,他们总是与其他人不一致。 结果,许多build模者认为聚合很重要,尽pipe原因不同。 所以UML包含聚合(图5.3),但几乎没有任何语义。 正如Jim Rumbaugh所说:“把它看作一个模拟安慰剂” [Rumbaugh,UML Reference]。

我从这个引用和Stack Overflow上读到的主题可以理解,我使用这两个关系中的哪一个并不重要,它们意味着几乎相同,还是有任何情况下聚合而不是关联的使用是合理的和/或我不能改变一个到另一个而不改变一个类图的“含义”?

我是这样问的,因为这本书是从2003年开始的,有些事情在这几年可能会改变。

Rumbaugh的陈述是最有说服力的,也是Bob叔叔的好build议。 正如我在其他地方所说的那样,聚合在语义上是如此薄弱,以致没有提供任何实际的好处。 它只有一个有效的angular落案例(recursion关系的非循环),但很less有人知道和理解。 所以你最终不得不在评论中指出。

我只是不使用它。 从来没有感到任何损失。 坚持简单的二元关联,关注真正重要的事情 – 获得基数和命名权。 你会得到更多的比试图决定不可判定的关联与聚合。

心连心。

也许这可以帮助你,但我不认为你会find完美的解释:

不同之处在于含义。 聚合表示全部/部分关系,而关联则不表示。 但是,这两种关系的实施方式不可能有太大的差异。 也就是说,查看代码并确定一个特定的关系应该是聚合还是关联是非常困难的。 出于这个原因,完全忽略聚合关系是非常安全的。
[Robert C. Martin | UML]

以下是每种情况的例子:

a)协会是所有对象都有自己的生命周期,没有所有者的关系。 我们举一个师生的例子。 多名学生可以与一名教师联系,单身学生可以与多名教师联系,但对象之间没有所有权,并且都有自己的生命周期。 两者都可以独立创build和删除。

b)聚合是一种特殊的关联forms,所有对象都有自己的生命周期,但是所有权和子对象不能属于另一个父对象。 我们以部门和老师为例。 单个老师不能属于多个部门,但是如果我们删除部门,老师对象不会被销毁。 我们可以考虑“有一个”的关系。
[Maesh | GeeksWithBlogs]

我倾向于使用Aggregation来显示与具有一大区别的组合相同的关系:包含的类不负责包含的对象的生命周期。 通常,将一个(非空)指针或对要包含对象的引用传递给包含类的构造函数。 包含对象在其生命周期期间取决于所包含的对象。 如果没有包含的对象,则包含对象不能完成它的工作。 这是我对Aggregation暗示的“部分/整体”关系的解释。

在UML中,聚合是没有定义的,因为它们没有明确定义的语义。 聚合的一个有效用例是封装了几个类,如Eric Evans的“Domain Driven Design”中所述。

例如一辆车有四个轮子。 您可能要计算每个车轮每个车轮驱动的总米数。 这个计算是由汽车实体完成的,因为它知道它有哪个车轮,而且你不关心哪个车轮属于哪辆车。

汽车是所有部件(如车轮)的聚合根部,不能从聚合体外面访问汽车的部件,只能是根部。

所以基本上聚合封装了一组属于对方的类。

明智的实施没有太大的区别,但概念上有很大的不同: 聚合被用来expression层次结构 。 当您使用组件层次结构时,您需要在根界面中执行某些types的操作:

  • 在层次结构中查找子组件
  • 将子组件添加到层次结构或从层次结构中删除子组件
  • 改变所有组件的通用属性
  • recursion地遍历层次结构(访问者模式)
  • 重新configuration层次结构和组件之间的链接(关联)

与协会打交道时,大多数这些操作是不需要的。

这个词经常被弄糊涂了。

聚合和组合是一些types的关联。 在实现过程中聚合和关联之间几乎没有什么区别,很多会在关联关系图中完全跳过聚合关系。

你可以从这个比喻中得到这个想法。

类:A(人)B类(汽车)具有关联关系 ,如果A类具有B类声明,并且B类(汽车)对象不是创build类的 必要条件 :A

Class:A(汽车)Class:B(轮胎)具有聚合关系 ,如果Class:A具有Class:B声明,并且Class:B(轮胎)对象对于创buildClass:A(汽车)对象也是必不可less的

干杯!

要添加,我只是build议从OMG站点下载UML规范:最佳参考,并参见第110页。

none表示该属性没有聚合语义。

共享表示该属性具有共享聚合语义。 共享聚合的精确语义因应用领域和build模者而异。

复合指示该属性是合成的,也就是说,复合对象负责组合对象的存在和存储(参见11.2.3部分的定义)。

他们不是这个意思! 我可以这样说:

关系关系 :一个类引用另一个类。 实际上,这表明一个class级与另一个class级有关,但他们并不一定具有显示这种关系的属性,例如“老师”class和“学生class”,虽然“老师class”没有提及学生的属性,但我们知道实际上一个老师确实有学生……另外,“学校”class有“老师”和“学生”的属性,现在让这两个class级相互关联。

聚合关系 :一个类包含另一个类。 但是,如果容器(ClassRoom)被销毁,则包含的(Chair)不是。 其实ClassRoom拥有主席。 聚合是一个比协会关系更强大的关系。

这里也是一个关于它的教程,整个UML2.0解释了一切简单易懂的事情,你可能会觉得这很有用: https : //github.com/imalitavakoli/learn-uml2

提示 :我还要提一下,因为大多数时候类之间存在着关联关系 ,所以我们有时候不会用它来防止不必要的复杂性。