UML 类图 Association vs (Aggregation | Composition)-Diamonds [英] UML class diagram Association vs ( Aggregation | Composition )-Diamonds
问题描述
我不确定我是否正确使用了关联和聚合或组合菱形.
I am not sure if I do use the association and aggregation or composition diamond properly.
我会为接口使用 Association，因为我无法实例化它们.比如他们在这里这样做.或者对于静态类，同样的原因.
I would use the Association for interfaces, because I can't instantiate them. Like they do it here for example. Or for static classes, same reason.
我仅将钻石用于可以实例化的对象.和普通班一样.
And the diamonds I use only for objects I can instantiate. Like normal classes.
但我不确定这是否是区分它们的正确方法，因为如果您检查 再一次，您会发现他们对此并不那么具体.在 UML 2.3 规范中，我无法了解更多，所以你如何使用它吗?
But I am not sure if this is the correct way to differentiate them, because if you check again, you will see they aren't so specific about it. In the UML 2.3 specification I couldn't get out more, so how are you using it?
还有第三种方式，虚线 <> 箭头，但我不知道何时使用这种方式.所以也许你也可以帮我解决这个问题?
And there is a third manner, the dashed lined <> arrow, but I don't have a glue when to use this one. So maybe you can help me with that one, too?
推荐答案
我会为接口使用 Association，因为我无法实例化它们.就像他们在这里做的那样.或者对于静态类，同样的原因.
I would use the Association for interfaces, because I can't instantiate them. Like they do it here for example. Or for static classes, same reason.
我仅将钻石用于可以实例化的对象.和普通班一样.
And the diamonds I use only for objects I can instantiate. Like normal classes.
这不是他们真正的工作方式.三种形式(关联、聚合和组合)定义了关系的不同属性.尽管也可以关联接口，但所有这三个通常都在类之间使用.关联和组合是两个最简单的:
That's not really how they work. The three forms (Association, Aggregation and Composition) define different properties about a relationship. All three are normally used between classes although can relate Interfaces too. Association and Composition are the two easiest:
- 关联(无菱形)是最通用的形式，允许在两端定义基数和可导航性.
- 合成(实心菱形)是一种整体-部分关系，其中整体"(以黑色菱形结尾)包含"部分.它施加了两个关键限制:
- Association (no diamond) is the most general form, allowing cardinality and navigability to be defined at both ends.
- Composition (filled diamond) is a whole-part relationship where the 'whole' (end with the black diamond) 'contains' the part. It imposes two key restrictions:
- 只能有 1 个容器(即整个端的基数正好是 1)；
- 它对整体施加了生命周期责任.所以容器负责创建和删除部件.如果容器被删除，部件将无法继续存在.
聚合(未填充的菱形)位于中间的某个位置.它有点像组合 - 除了它不强制要求上述属性.我个人不使用它.语义太不清楚，不值得.
Aggregation (unfilled diamond) sits somewhere in the middle. It's a bit like composition - except it doesn't mandate the properties described above. I don't personally use it. The semantics are too unclear for it to be worthwhile.
还有第三种方式，虚线 <>箭头，但我不知道什么时候用这个.
And there is a third manner, the dashed lined <> arrow, but I don't have a glue when to use this one.
我认为您的意思是依赖关系.这是一种较弱的关联形式.以下面的类定义为例
I think you mean the dependency relationship. It's a weaker form of association. As an example, take the following class definition
class Foo {
def bar(Baz: aParam) {
...
}
}
在这种情况下，Foo 类型依赖于 Baz 类型，因为它在 bar() 方法签名中使用.但是，它们之间没有关联(无法明智地讨论例如 Foo 实例和 Baz 实例之间关系的基数).
In this case type Foo has a dependency on type Baz from its use in the bar() method signature. However there's no association between them (can't sensibly discuss e.g. cardinality of relationship between an instance of Foo and an instance of Baz).
从实践的角度来看，我想说:
From a practical perspective I'd say:
- 您可以对 80% 以上的可能想要建模的关系使用直接关联
- 组合可能占剩余场景的大部分
- 依赖在某些情况下很有用
- 即使不使用聚合，您也可以过得很愉快.
第
这篇关于UML 类图 Association vs (Aggregation | Composition)-Diamonds的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
