概括和专业化的汇总顺序
我在设计 DCD 时遇到了这个问题。 我有一个通用产品和两个专业产品：牛奶和披萨。 我怀疑是否应该使用订单和产品或订单和披萨/牛奶之间的聚合。
- 哪一个是正确的？
- 如果两者都正确，哪一个是首选？
我简化了 uml，以使我的问题尽可能清晰。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这两个图都是正确的，但具有的含义非常不同：
cake而无需更改订单的含义）扩大”）。蛋糕），必须修改订单的定义。考虑到开放式原理绝对是第一个图表选择。第二个太麻烦了。
备注：顺便说一句，尽管由于历史原因，聚合仍然非常受欢迎，但UML规范并未定义其语义。因此，您可以去除白色钻石并表达完全相同的含义。
Both diagrams are correct, but have a very different meaning:
Cakewithout changing the meaning of the order (it is said to be "open for extension").Cake), the definition of your order would have to be modified.Considering the Open-Closed Principle the first diagram is definitely the one to chose. The second one is too cumbersome.
Remark: by the way, while aggregation is still very popular for historical reasons, the UML specifications don't define its semantic. You could therefore remove the white diamonds and express exactly the same meaning.
两者在语义上都是正确的，这意味着它们可以正确解释。
此外，如果所有聚合中的多重性均为
1（在钻石侧）和*（在另一端），并且还有其他有关这些关系的信息相同的语义含义。在这种情况下，通常由于更简单的图，通常首选使用广义类的聚合，但是即使在这种情况下，也可能有理由使用第二个符号。但是，所提出的上述多重性可能并非如此，并且可能还有许多其他原因可以区分两种不同的产品类型之间的聚合。在那些情况下，只有第二个表示法是合适的（但是还有其他可能性）。
您可能还想指出在广义类中的聚集很重要的事情，在这种情况下，这是简单地呈现需求的更好方法。
只有几个例子。
如果您想表明，无论类型如何，您都需要有任何顺序，那么第一个符号都会更好。
如果您需要订购最少数量的披萨，但是牛奶是可选的，那么第二个更好。
如果您有多少比萨饼和订购多少牛奶（每次分开）的限制，那么第二个更好。
如果您的订单有一个重量限制，无论金额如何，那么第一个订单可能会更好（对各自的约束）。
你得到图片。
此外，有时您实际上将这两个都组合在单个图（和相同的类）上。
示例：假设您不能订购10个以上的元素，但同时您需要订购每种类型的至少一项。您将显示两种类型的聚合，添加
/subset限制以表明这些实际上是相同的元素。有关更详细的答案，您必须提供更详细的问题;-)
Both are semantically correct, meaning they can be properly interpreted.
Moreover, if the multiplicities in all aggregations are
1(on diamond side) and*(on opposite end) and there are is other information regarding those relationships then they even have the same semantical meaning. In such case usually using an aggregation to the generalised class is usually preferred due to simpler diagram, but even in such case there may be reasons to use the second notation.However the proposed above multiplicities may not be the case and there can be many other reasons to distinguish the aggregations between two different product types. In those cases only the second notation will be suitable (however there are other possibilities as well).
You may also want to indicate things where the aggregation to the generalised class is significant, in which case it is a better way of simple presentation of the requirements.
Just a few examples.
If you want to show you need to have anything in the order, no matter the type, the first notation will serve better.
If you need to order a minimum quantity of pizza, but milk is optional, the second is better.
If you have a limit of how much pizzas and how much milk can you order (each separate), then the second is better.
If your order has a weight limit, regardless of the amounts, then the first one will probably be better (with respective constraint).
You get the picture.
Moreover, sometimes you actually combine both on a single diagram (and the same classes).
Example: Let's say you cannot order more than 10 elements but at the same time you need to order at least one item of each type. You will show both types of aggregation, adding the
/subsetsconstrain to indicate these are actually the same elements involved.For more detailed answer, you'd have to provide more detailed question ;-)