UML class diagram Association vs ( Aggregation | Composition )-Diamonds

Question

I am not sure if I do use the association and aggregation or composition diamond properly.

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.

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?

Answer 1

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. There can only be 1 container (i.e. cardinality at whole end is exactly 1);
  2. It imposes a lifecycle responsibility for parts on the whole. So the container is responsible for creating and deleting parts. A part cannot continue to exist if its container is deleted.

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) {
  ...
 }
}

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:

• you can use straight Associations for 80%+ of the relationships you're likely to want to model
• Composition probably accounts for most of the remaining scenarios
• Dependency can be useful in some circumstances
• You can get by quite happily without ever using Aggregation.

hth.