UML Notation - Aggregations/Compositions vs "Vanilla" Associations

In fact, most cases of associations in UML class models are neither aggregations nor compositions. For instance, the association between the classes Publisher and Book for assigning the books published by a publisher to this publisher is neither an aggregation nor a composition because the books published by a publisher are not parts or components of this publisher.

An aggregation is a special form of association with the intended meaning of a part-whole-relationship, but without a precise semantics (the UML spec says: "Precise semantics of shared aggregation varies by application area and modeler"). For instance, we can model an aggregation between the classes Car and Engine and between the classes Course and Lecture since an engine is part of a car and a lecture is part of a course.

A composition (also called "composite aggregation" in the UML spec) is a special form of aggregation, where a component instance is part of at most one aggregate instance at a time (that is, it cannot be shared between several aggregates). This means that the aggregation between Car and Engine is a composition (because an engine cannot be shared between two cars at the same time), while an aggregation between Course and Lecture is not necessarily a composition since a lecture can be shared among two courses (e.g. a database management course and a software engineering course could share a lecture on UML). This implies that the multiplicity of a composition's association end at the aggregate side is either 1or 0..1, while it may be also * in the case of a non-composite aggregation.

In addition to this main characteristics of a composition (to have exclusive parts), a composition may also come with a life-cycle dependency between an aggregate and its components implying that when an aggregate is deleted, all of its parts are deleted with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. The UML spec states: "A part may be removed from a composite instance before the composite instance is deleted, and thus not be deleted as part of the composite instance." In our example of the Car-Engine composition, it's clearly the case that the engine can be removed from the car before the car is destroyed, in which case the engine is not destroyed and can be re-used.

Vanilla Associations, Aggregration and Compositions are sometimes explained with the following semantics:

• vanilla association: one object 'knows' one ore more other objects
• aggregation: one objects 'has' one ore more other objects
• composition: one object 'consists of' one or more other objects - the subobject can not be without the composing container

mostly differentation of aggregation and composition go around the question "if the master object is gone - what happens to the part objects?".

So the idea is to have some integrity constraint like "on delete cascade" be described using a differentiation in using one of the three options. UML has three different symbols for this

• no symbol - vanilla association
• diamond - aggregation
• filled diamond - composition

The issue with these three options is that the semantics are not precise enough for real life situations, especially if you look at situations that change over time

E.g. Trying to answer the simple question "How many tire-wheels does my car have?" Will lead to different answers:

• 4 wheels which are permantly attached to my car
• 1 spare wheel which I might use in an emergency
• 4 wheels that are either my summer or my winter wheels and are not attached to the car in the other seasons

see

• UML diagram on diagrams.bitplan.com
• PlanUml markup for diagram

How many of these wheels will be gone when the car is gone? If you try to model this situation with the three symbols UML is offering you'll end up with a lot of discussion and negotiation what your model really means. I think it is far better never to use aggegation and composition symbols but instead always describe the association semantics as precisely as possible with a few lines of text. This way you can make it clear to the people reading your model what you really want. I think it is even o.k. to write "A car is a composition of parts which includes the wheels ...."

But now you are not using a composition symbol but are really referencing the act of composing something.

see also http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition (german)