UML class diagram Association vs ( Aggregation | C

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.

Answer 2

Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. Too often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you mean "shared".

Further from UML standard:

composite - Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).

So, University to cathedras association is a composition, because cathedra doesn't exist out of University (IMHO)

Precise semantics of shared aggregation varies by application area and modeler.

I.e., all other associations can be drawn as shared aggregations, if you are only following to some principles of yours or of somebody else. Also look here.