在 class 图中过度使用聚合？
Over-use of aggregation in a class diagram?
我试图解决这个问题：
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.
否：组合意味着排他性所有权，并且组合对象原则上不会在组合后继续存在。但是在这里，如果一家汽车公司被摧毁，租房者可能会留下来，干脆去其他汽车公司。所以没有作文。
已发布解决方案的聚合与您的关联
solution shows all the relationships are aggregation.
您描述的关系似乎对应于 UML 关联。已发布的解决方案使用聚合这一事实不一定是错误的，但不建议这样做：
从UML规范来看，语义没有明确定义。所以在设计模型中使用聚合并没有真正的好处。参见 UML 2.5 第 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.
从设计者的角度来看，聚合是一种纯粹的概念符号，并没有从根本上改变图表的含义。为此，UML 之父 James Rumbaugh 曾将聚合称为“modelling placebo”。我在《统一建模语言参考手册》一书中找到了引用，第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.
在实现方面，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 更准确地表达了这些语义。
解决方案图上做出了一些真正值得讨论的选择：如果我们以Renter和Rental为例，从承租人的设计角度来看有一些租赁合同，可能需要找回。毕竟，租金是承租人业务角色的一部分。反之，从合同的角度来看，承租人是合同的一方。因此，人们可以在两个方向上捍卫聚合，但您 。武断地选择只显示真相的一面可能会令人困惑。并且在相反的方向上添加两个聚合并不能恰当地表明实际上它是相同的关系。 尽可能避免聚合的另一个论点。
结论：由于没有objective标准来决定何时使用聚合，并且鉴于没有使用聚合或关联的其他重大影响，只需保留很简单：当你在图表中阅读聚合时，请忽略聚合，避免在你自己的图表中使用它，而更喜欢关联。
我试图解决这个问题：
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.
否：组合意味着排他性所有权，并且组合对象原则上不会在组合后继续存在。但是在这里，如果一家汽车公司被摧毁，租房者可能会留下来，干脆去其他汽车公司。所以没有作文。
已发布解决方案的聚合与您的关联
solution shows all the relationships are aggregation.
您描述的关系似乎对应于 UML 关联。已发布的解决方案使用聚合这一事实不一定是错误的，但不建议这样做：
从UML规范来看，语义没有明确定义。所以在设计模型中使用聚合并没有真正的好处。参见 UML 2.5 第 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.从设计者的角度来看，聚合是一种纯粹的概念符号，并没有从根本上改变图表的含义。为此，UML 之父 James Rumbaugh 曾将聚合称为“modelling placebo”。我在《统一建模语言参考手册》一书中找到了引用，第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.
在实现方面，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 更准确地表达了这些语义。
解决方案图上做出了一些真正值得讨论的选择：如果我们以
Renter和Rental为例，从承租人的设计角度来看有一些租赁合同，可能需要找回。毕竟，租金是承租人业务角色的一部分。反之，从合同的角度来看，承租人是合同的一方。因此，人们可以在两个方向上捍卫聚合，但您
结论：由于没有objective标准来决定何时使用聚合，并且鉴于没有使用聚合或关联的其他重大影响，只需保留很简单：当你在图表中阅读聚合时，请忽略聚合，避免在你自己的图表中使用它，而更喜欢关联。