在类图中过度使用聚合? [英] Over-use of aggregation in a class diagram?

问题描述

我试图解决这个问题:

<块引用>

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

我在想租车人和租车公司应该是联合，租车公司和租车人应该是组合.然而，提议的解决方案(此处简化)与我的期望不符:

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

解决方案

评论自己的分析

<块引用>

我在想租房者和汽车公司应该是联合的

是的，这是有道理的:承租人可能是一家汽车公司的客户，反过来，一家汽车公司可以为多个承租人提供服务.承租人不归汽车公司所有，互惠互利.

<块引用>

和租车公司和租车人应该是组成的.

否:组合意味着独占所有权，并且组合对象原则上不会在组合中存活.但在这里，如果一家汽车公司被摧毁，租客可能会留下来，干脆去其他汽车公司.所以没有构图.

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

<块引用>

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

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

• 从 UML 规范的角度来看，语义没有明确定义.所以在设计模型中使用聚合并没有真正的好处.参见 UML 2.5 p.110:

  <块引用>

  有时，属性用于模拟使用一个实例将一组实例组合在一起的情况；这称为聚合.
  (...) 共享聚合的精确语义因应用领域和建模者而异.

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

  <块引用>

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

• 在实现方面，对象组合是基础之一面向对象的.一些从业者和学术界倾向于用UML 聚合以显示聚合元素是整个聚合的一部分(UML 组合过于严格，特别是对于类具有引用语义的语言，如 Java 或 C#).然而，这个论点是可以讨论的，因为设计不应该由实现技术驱动.此外，现代 UML 的点符号更准确地表达了这些语义.

• 在解决方案图中做出了一些真正值得讨论的选择:如果我们以 Renter 和 Rental 为例，从租户的设计角度来看有一些租赁合同，可能需要找回来.毕竟，租金是承租人业务角色的一部分.相反，从合同的角度来看，承租人是合同的一方.因此，您可以为两个方向的聚合辩护，但是您不能同时在两侧进行聚合.武断地选择只显示事实的一方面可能会令人困惑.并且在相反方向上添加两个聚合并不能恰当地表明它实际上是相同的关系.尽可能避免聚合的另一个论据.

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

I tried to solve this problem:

Draw a UML class diagram of an Object-Oriented model for a car rental company that keeps track of cars, renters and renters renting cars. Create a UML class diagram to represent this information. Showing the correct classes and relationships is enough. Do not add attributes or methods to the classes.

I was thinking the that renters and car company should be association, and car company and renters renting cars should be composition. However the proposed solution (simplified here), did not match my expectations:

The solution shows all the relationships as aggregation. Can someone help me understand why they all are aggregation and not association and composition as I thought?

解决方案

Comments on your own analyse

I was thinking the that renters and car company should be association

Yes, this makes sense: a renter may be a customer of a car company, and reciprocally, a car company could serve several renters. Renters are not owned by a car company and reciprocally.

and car company and renters renting cars should be composition.

No: composition means exclusive ownership, and that the composed objects would in principle not survive the composite. But here, if a car company is destroyed, the renters may stay and simply go to other car companies. So no composition.

Published solution's aggregation vs. your associations

solution shows all the relationships are aggregation.

The relations that you describe seem to correspond to UML associations. The fact that the published solution uses aggregation is not necessaritly false, but it’s not recommended:

• From the point of view of the UML specifications, the semantics are not clearly defined. So there’s no real benefit to use aggregation in a design model. See UML 2.5 p.110:

  Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation.
  (...) Precise semantics of shared aggregation varies by application area and modeler.

• From the point of view of the designer, aggregation is a purely conceptual notation that does not fundamentally change the meaning of the diagram. For this reason, James Rumbaugh, a founding father of UML, once called aggregation a "modelling placebo". I found back the quote in the book "Unified Modeling Language Reference Manual", chapter 14:

  Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.

• On the implementation side, object composition is one of the basics of OOP. Some practitioners and academics tend to represent object composition with an UML aggregation to show that the the aggregated element is a part of a whole aggregate (the UML composition would be too restrictive, especially for languages in which classes have reference semantics, as Java or C#). This argument is however discussable because the design should not be driven by the implementation techniques. Moreover, modern UML's dot notation expresses those semantics much more accurately.

• Some really discussable choices are made on the solution diagram: If we take the example of the Renter and the Rental, from a design point of a renter has some rental contracts and would probably need to find them back. After all, the rentals are a part the renter business role. Conversely, from a contractual point of view, the renter is a party of the contract. So one could defend an aggregation in both directions, but you cannot have an aggregation on both sides at the same time. The arbitrary choice to show only one side of the truth could be confusing. And adding two aggregations in the opposite direction would not appropriately show that in fact it's the same relation. Another argument to avoid aggregation whenever possible.

Conclusion: since there’s no objective criteria to decide when to use aggregation, and in view of absence of other significant impact of using aggregation or association, just keep it simple: ignore aggregation when you read it in a diagram, and yourself, avoid using it in your own diagram and prefer association instead.

这篇关于在类图中过度使用聚合?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！