在类图中过度使用聚合?

Posted

技术标签:

【中文标题】在类图中过度使用聚合?【英文标题】:Over-use of aggregation in a class diagram? 【发布时间】:2021-07-29 05:24:03 【问题描述】:

我试图解决这个问题:

为一家汽车租赁公司绘制一个面向对象模型的 UML 类图,该公司跟踪汽车、租赁者和租赁汽车的租赁者。创建一个 UML 类图来表示此信息。显示正确的类和关系就足够了。不要向类添加属性或方法。

我在想租车公司和租车公司应该是联合体,租车公司和租车公司应该是联合体。然而,提议的解决方案(此处简化)与我的预期不符:

该解决方案将所有关系显示为聚合。有人可以帮我理解为什么它们都是聚合而不是我想象的关联和组合吗?

【问题讨论】:

如果您认为作业不清楚,请询问设置它的人。他们可能想知道他们的学生是否不理解他们的要求。这个网站是用来解决编程问题的,不是用来解释你的作业的。 该解决方案使用关于聚合的常见做法,这根本不会使您自己的解决方案无效。不幸的是,该链接不再可视化。将来其他读者至少可以看到该图表的摘录,以更好地理解您的担忧,并帮助他们理解类似的问题。 链接已更新。你能解释一下聚合和关联之间的区别吗?我对如何区分两者有点困惑。 【参考方案1】:

对您自己的分析的评论

我在想租房者和汽车公司应该是协会

是的,这是有道理的:一个承租人可能是一家汽车公司的客户,反过来,一家汽车公司可以为多个承租人提供服务。租车人不属于汽车公司,并且互惠互利。

应该和租车公司和租车人组成。

否:组合意味着独占所有权,并且组合的对象原则上不会在组合中存在。但在这里,如果一家汽车公司被摧毁,租房者可能会留下来,干脆去其他汽车公司。所以没有作文。

已发布解决方案的聚合与您的关联

解决方案显示所有关系都是聚合。

您描述的关系似乎对应于 UML 关联。已发布的解决方案使用聚合这一事实不一定是错误的,但不建议这样做:

从 UML 规范的角度来看,语义没有明确定义。因此,在设计模型中使用聚合并没有真正的好处。请参阅 UML 2.5 第 110 页:

有时,Property 用于对使用一个实例将一组实例组合在一起的情况进行建模;这称为聚合。 (...) 共享聚合的精确语义因应用领域和建模者而异。

从设计者的角度来看,聚合是一种纯粹的概念符号,不会从根本上改变图表的含义。为此,UML 的创始人 James Rumbaugh 曾将聚合称为“modelling placebo”。我在《统一建模语言参考手册》第 14 章中找到了引用:

请记住,聚合就是关联。聚合传达了这样一种思想,即聚合本质上是其部分的总和。事实上,它添加到关联中的唯一真正语义是聚合链接链可能不会形成循环的约束(...)尽管附加到聚合的语义很少,但每个人都认为这是必要的(出于不同的原因)。将其视为建模安慰剂。

在实现方面,object composition 是 OOP 的基础之一。一些实践者和academics 倾向于用 UML 聚合来表示对象组合,以表明聚合元素是整个聚合的一部分(UML 组合限制性太强,特别是对于类具有引用语义的语言,如 Java或 C#)。然而,这个论点是可以讨论的,因为设计不应该由实现技术驱动。此外,现代 UML 的dot notation 更准确地表达了这些语义。

在解决方案图上做出了一些真正值得讨论的选择:如果我们以RenterRental 为例,从租户的设计角度来看,一些租赁合同并且会可能需要找回他们。毕竟,租金是承租人业务角色的一部分。相反,从合同的角度来看,承租人是合同的一方。所以一个人可以在两个方向上捍卫一个聚合,但是你cannot have an aggregation on both sides at the same time。仅显示事实的一面的武断选择可能会令人困惑。并且在相反方向添加两个聚合并不能恰当地表明它实际上是相同的关系。 尽可能避免聚合的另一个论点。

结论:由于没有客观标准来决定何时使用聚合,并且鉴于使用聚合或关联没有其他重大影响,请保持简单:阅读时忽略聚合在图表中,以及您自己,避免在您自己的图表中使用它,而是更喜欢关联。

【讨论】:

你能解释一下聚合和关联之间的区别吗?我对如何区分两者有点困惑。 @GameTop 聚合是一种关联。如果两个类被聚合,就好像它们是关联的,只是聚合暗示了一种部分-整体的关系。但是什么是部分-整体关系?我的眼睛是我身体(整体)的(一部分)。但我的假牙也是我身体的一部分。我的结婚戒指也是如此,因为它在我手指上的长度比任何假肢都长。同时,在较短的 scala 上,我的智能手机也是其中的一部分,因为它是我原来的部分的扩展,我总是随身携带。关键是“部分-整体”很难定义。 因为不可能清楚地定义什么是part-while关系,UML规范说语义取决于建模者的上下文。结论:如果没有客观的标准来决定何时使用它,并且如果使用一个或另一个没有其他影响,请在图表中阅读时忽略它,以及您自己,避免在自己的图表中使用聚合,而是更喜欢关联。投资多重符号比添加空心菱形更有用 参考 UML 2.5 p 总是值得的。 110,其中明确声明不存在共享聚合语义。 @qwerty_so 好主意!我也进行了编辑以添加精确的参考。我还添加了一些引用 + 最终建议。

以上是关于在类图中过度使用聚合?的主要内容,如果未能解决你的问题,请参考以下文章

UML类图中的三种关系----关联聚合和泛化

UML 图中的聚合基数

类图(类相互关系在类图中的表示)

如何在UML类图中建模非成员聚合

UML类图

UML——类图