3

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.

  • 1
    Read my answer here: https://stackoverflow.com/questions/48268986/is-correct-relationships-of-class-diagram-in-uml – qwerty_so Jan 20 '18 at 21:35
  • @ThomasKilian thank you for your respond. But still, I think that not solves my misunderstanding, according to explanations that you've suggested in your answer `Driver License` won't vanish if owner will lose it `Human` so I could say that's aggregation. But the `Driver License` makes no sense when its `Owner` will die for example, and the one concrete entity of `License` cannot be used by another `Human` while the concrete entity of `Engine` could be used by another `Car`. Factually, `Human` lifetime defines lifetime of `License`, but `License` can exist w/o `Human` in the same time. – eshkere111222333 Jan 20 '18 at 22:19
  • @ThomasKilian so we get composition and aggregation at the same moment. But I guess there is a mistake made in my thoughts. Where's the truth? – eshkere111222333 Jan 20 '18 at 22:20
  • 1
    Well, it's the security aspect here. The license **must** vanish (invalidated) if the driver passes by. So you can make it a composite aggregation. – qwerty_so Jan 20 '18 at 23:23
  • 1
    I should have said: "You **must** make it a composite..." – qwerty_so Jan 20 '18 at 23:51

3 Answers3

3

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.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • You mean it can not be an Aggregation between `Human` and `Driver License`? – Gholamali Irani Jan 21 '18 at 20:55
  • It can be a **whole/part relationship**. Please read the **Primary and Secondary Characteristics of Whole-Part relationships** in [this paper](https://www.researchgate.net/publication/228635656_The_whole-part_relationship_in_the_Unified_Modeling_Language_A_new_approach). – Gholamali Irani Jan 21 '18 at 21:01
  • For another example [here](https://www.uml-diagrams.org/composition.html), consider the Composition between a `Department` and `Staff`. We can say: `Staff` is not part of `Department` too. **But** there is a Whole/Part relationship here. – Gholamali Irani Jan 21 '18 at 21:05
  • @Gholamali-Irani: The only good reason for modeling a binary association (like Humand-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. – Gerd Wagner Jan 21 '18 at 23:24
  • In the real word context I only said: It can not be a composition. Maybe the association is the right. – Gholamali Irani Jan 22 '18 at 00:30
  • Notice that in my answer, I did not try to answer Aggregation or Composition. I focused on **importance** of definitions of Context and other terms in our discussions and modeling. However your point (about Association) in very good to me. I will research again about the meaning and history of Aggregation in UML. – Gholamali Irani Jan 22 '18 at 00:37
  • @Gholamali-Irani The current version of UML no longer give a part-whole semantic to the aggregation. So whenever the conclusion would be to prefer aggregation over composition, one step more should be taken to prefer silple association over shared aggregation. – Christophe Oct 21 '22 at 06:26
1

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.

Gholamali Irani
  • 4,391
  • 6
  • 28
  • 59
  • 1
    In a real world it's not composite, but in ORM terms you would make `Human*--License` a composite to express that the license **must** be destroyed if the driver dies. And the OP is talking about the model, not the real world (I guess). – qwerty_so Jan 21 '18 at 00:34
  • @ThomasKilian, you are absolutely right. I want to say the importance of definitions of Context and other terms – Gholamali Irani Jan 21 '18 at 00:36
-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.

Class - Aggregation

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

Composiiton

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.

enter image description here

(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.

lynch warren
  • 105
  • 10
  • 2
    *"Composition implies a relationship where the child cannot exist independent of the parent. "* That is just plain wrong. UML specifically states that composition doesn't imply that the part cannot exist without the whole. – Geert Bellekens Jan 24 '18 at 04:46
  • 1
    "Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it." Extracted from - Page 110, OMG Unified Modeling Language Specification, Version 2.5, 2015 -http://www.omg.org/spec/UML/2.5 – lynch warren Jan 24 '18 at 09:57
  • Indeed, *at most* not *at least*. See also the next sentence: "NOTE. A part object may (where otherwise allowed) be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object." – Geert Bellekens Jan 24 '18 at 11:06
  • 1
    I am not sure you fully understand what the NOTE you quoted from the OMG specification above? ---- It simply means that " however, a part can be removed individually from a composition without having to delete the entire composition.” – lynch warren Jan 25 '18 at 03:27
  • Wikipedia - "Composition is a kind of association where the composite object has sole responsibility for the disposition of the component parts. The relationship between the composite and the component is a strong “has a” relationship, as the composite object takes ownership of the component. This means the composite is responsible for the creation and destruction of the component parts. An object may only be part of one composite. If the composite object is destroyed, all the component parts must be destroyed. ". I believe this definition should be now crystally clear. – lynch warren Jan 25 '18 at 03:29
  • 2
    No sorry, it means that I can remove a *part* from the compositions before deleting the *whole*. Multiplicity on the *whole* end may be [1] or [0..1]. The latter means that the *part* may exist without a whole as well. The only authority on the matter are the specifications of the OMG, not Wikipedia. (although that doesn't contradict the way I understand it) – Geert Bellekens Jan 25 '18 at 04:30
  • 1
    I can only agree your interpretation of the concept related to composition is quite "new" and different from most of the other people in the industry, OMG specification and the Wikipedia. – lynch warren Jan 25 '18 at 05:18
  • Please explain how you interpret a multiplicity of [0..1] on the *whole* side. According to your interpretation, is the lowerbound of 0 is invalid? (because a *part* cannot exist without it's *whole*)? – Geert Bellekens Jan 25 '18 at 05:56
  • 1
    I wouldn't either say “if the 0 lower bound is invalid, or it is just a plain wrong” (although personally I would try my best to avoid it), or on the other hand considers “Composition implies a relationship where the child cannot exist independent of the parent.” suggested by the 3 Amigos in the UML User’s Guide is “just a plain right”, that we have to be blindly followed without any practical consideration; that may result in a nonconstructive & absolute binary opposition. – lynch warren Jan 26 '18 at 00:20
  • 1
    If you are stating your advise or best practice that is fine with me. But please don't make it appear as it were as a rule in UML The UML specifications clearly allow optional composites as well. – Geert Bellekens Jan 26 '18 at 05:05