I have some questions regarding relations between aggregations, compositions, references (arrow) and simple link (nothing) relations within UML2 ?

  1. If A -> B -> C each have composition relationship. Are the root responsable of creation and destruction of the object B and C ?

  2. What aggregations have that the simple link or references doesn't ? What make them different ?


Edit: The question was a bit unclear and not objective. I edited it.

  • 1
    Before asking such a bizarre question, please post what you know already about these things. What have you read? What are you looking at? What specific issues have you seen that you can't resolve? This is very, very well documented. What have you already read on the subject? – S.Lott Feb 11 '11 at 2:16
  • Agreed! en.wikipedia.org/wiki/Class_diagram – Steven Jeuris Feb 11 '11 at 12:04
  • Edited the question. – Rushino Feb 11 '11 at 12:33
  • 1
    Was your question answered enough for your liking? If so, we can just close it here. If not, I can migrate it to StackOverflow where it'd fit better, since it's an objective technical question. – Adam Lear Feb 11 '11 at 13:28
  • 1
    Could you move this to StackOverFlow please. It seem i need more answers on this Thanks. – Rushino Feb 11 '11 at 15:15

Aggregation and Composition are both "Has a" relationship and there is no difference in coding view. The difference between them is that aggregation has a looser realtionship and it does not imply an ownership. For example, university is composed of departments but departmens has number of(aggregation) professors. If university is closed all composing departmens are closed, too. However, if a department is closed, professors continue to live and can find another job.

Associations can be directed (references-arrow) or undirected (simple link - nothing) and they represent the ability of one instance to use another instances facilities such as variables and functions. Directed associtaions only implies which uses which.

  • 1
    "there is no difference in coding view", ... there is. In a composition (owns a) relationship the owner takes care of the creation and destruction of the object. – Steven Jeuris Feb 11 '11 at 12:06
  • 1
    Ok, I can say that it is best practice but I am not sure that it is strictly enforced or recommended. Some other controller class can take care of those jobs. – Korhan Feb 11 '11 at 12:20
  • @Steven Jeuris. If there 3 elements in a composition. (A -> B -> C) If -> is a composition relationship. Who is responsable of the creation and the destruction of the object ? It is the root ? or A have responsability of B and B have responsability of C ? – Rushino Feb 11 '11 at 12:28
  • 1
    @oosterwal Of course there is no good way to handle that problem but there can be just D controller with composition relationships with both A and B. – Korhan Feb 11 '11 at 20:45
  • 1
    @Korhan +1: I agree--I was running out of room so I left that option out. – oosterwal Feb 12 '11 at 2:37

If A -> B -> C each have composition relationship. Are the root responsable of creation and destruction of the object B and C ?

It is common practice, for A to control the lifetime of B, and for B to control the lifetime of C. This way there is no relation between A and C which is better decoupling. (UPDATE: or as Korhan mentioned, the lifetime of e.g. B is dependant on A, an external class could also handle the lifetime management. The essence is, if the container is destroyed, normally every instance that it contains is destroyed as well.)

This is in the case of composition.

What aggregations have that the simple link or references doesn't ? What make them different ?

Aggregation is more specific than association. Aggregation represents a part-whole or part-of relationship. If the container is destroyed, its contents are not, this is the main difference with composition. The contents are most likely also used outside of the container.

A association doesn't have a direct 'has a' relationship. It's rather a 'uses a' relationship. This can occur for example when A does need to be aware of C for some reason. (try to prevent this!) Then there is a association from A to C. A more common scenario is when a certain function takes a certain type as input, but doesn't store it internally. Or when a helper class is called.

  • I would rather say association means there is a relationship between objects of two classes, maybe like in the relational models. Uses is confusing, because there is a dependency relationship in UML with <<uses>> stereotype. The main difference between aggregation and association lies on the conceptual level rather then implementation. Some even regard aggregation as useless, although I would not agree, it can show the main purpose of contained class or important dependency between the containing ant contained classes. – Gabriel Ščerbák Feb 16 '11 at 10:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.