Aggregation vs Composition

Question

I am wondering is the relationship between a Human and a Driver License an aggregation or a composition? It's clear for me that a Room and a Building relationship is a composition and a Chair and a Room is an aggregation. But a Driver License can exist without a Human but it makes no sense of its existence without a Human. I got stuck.

Answer 1

Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.

Aggregation Example:

It's important to note that the aggregation link doesn't state in any way that Class A owns Class B nor that there's a parent-child relationship (when parent deleted all its child's are being deleted as a result) between the two. Actually, quite the opposite! The aggregation link is usually used to stress the point that Class A instance is not the exclusive container of Class B instance, as in fact the same Class B instance has another container/s.

Composition Example:

We should be more specific and use the composition link in cases where in addition to the part-of relationship between Class A and Class B - there's a strong lifecycle dependency between the two, meaning that when Class A is deleted then Class B is also deleted as a result

Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House.

---

Here is some additional information to elaborate the concept of Composition

As what Grady Booch Stated in the UML User's Guide, Addison Wesley

However, there is a variation of simple aggregation - composition - that does add some important semantics. Composition is a form of aggregation, with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it. Such parts can also be explicitly removed before the death of the composite.

In addition, in a composite aggregation, the whole is responsible for the disposition of its parts, which means that the composite must manage the creation and destruction of its parts. For example, when you create a Frame in a windowing system, you must attach it to an enclosing Window. Similarly, when you destroy the Window, the Window object must in turn destroy its Frame parts.

(Source: UML User's Guide - by Grady Booch, James Rumbaugh, Ivar Jacobson, Addison Wesley)

---

Summing it up - (Read detailed Article)

To sum it up association is a very generic term used to represent when on class used the functionalities provided by another class. We say it's a composition if one parent class object owns another child class object and that child class object cannot meaningfully exist without the parent class object. If it can then it is called Aggregation.

Answer 2

Since a driver license is not part of a human/person, but just related to her/him, there is neither a Composition nor an Aggregation between them, but just a plain Association.

The answer of Gholamali-Irani confuses the fact that a driver license must be associated with a person (that is, the resp. association end has an EXACTLY ONE multiplicty) with the (contingent) characteristics of many compositions to have inseparable parts, and mistakenly concludes that the Association must be a Composition.

In many cases, where we may wonder if an association is a composition, it is safer to model it as a plain association.

The only good reason for modeling an association (like Human-has-DriverLicense) as a composition is when the instances of the component type (here the driver licenses) are "weak entities" not having their own identity. But driver licenses do have their own ID, so there is no need, and no gain, to model them as components of their bearer.

Answer 3

I think that to answer the doubt in this question, we should define the following terms exactly:

1. the Context
2. Existing of an Instance in the Context

If the above terms are defined exactly, then there is not any doubt in using a Composition or an Aggregation.

I my idea, if I want to ask this question, in the my specific definition of terms:

1. Context : Real World
2. Existing of an Instance and destroying it: the usefulness of Instance is not related to it's Existence. Destroying it means to invalidating it. We should invalidate it after vanishing the owner. (But we do not do it immediately)

So, the relationship between a Human and a Driver License can not be a composition in the real world context. Because, by destroying a Human (vanishing, lose the life ,...), we do not destroy the Driver License immediately. It exists.

For example (in some countries), there is not any online and up-to-date invalidation mechanisms to invalidate a Driver License immediately, so it can be exist without the Driver until we invalidate it. So in this period of time (from vanishing the Driver to invalidating the Driver License) it exists and the usefulness of Instance is not related to it's Existence. Note that again: it is my definition of Context and Existence.

Edit (Based on @Thomas Kilian's comment):
For another example in the Context of Programming and it's technologies (like ORM), we should delete (invalidate) the Driver License immediately after deleting a instance of Driver (and we can do it in this Context). So the relationship should be a Composition.

Finally: I want to point the importance of the definition of terms (Context and Existing and other related terms) in modeling. If we do not define them exactly, many solutions appear to the problems (based on hidden definitions in their minds).

Hope to help.