Thursday, May 28, 2009

UML Class Diagram: Association, Aggregation and Composition

The UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways.

There are three primary inter-object relationships: association, aggregation, and composition. Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity.

Association

The most abstract way to describe static relationship between classes is using the ‘Association’ link, which simply states that there is some kind of a link or a dependency between two classes or more.

image 

Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB instance, or returns instance of ClassB.

image

Strong Association

ClassA may also be linked to ClassB in order to show that it holds reference to ClassB instance.

image

Aggregation (Shared Association)

In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, taking special notice that ClassB can also be aggregated by other classes in the application (therefore aggregation is also known as shared association).

image

So basically, the aggregation link doesn’t state in any way that ClassA owns ClassB nor that there is 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 usually used to stress the point that ClassA is not the exclusive container of ClassB, as in fact ClassB has another container.  

image

Aggregation v.s. Association

The association link can replace the aggregation link in every situation, while aggregation cannot replace association in situations were there is only a ‘weak link’ between the classes, i.e. ClassA has method/s that contain parameter of ClassB but ClassA doesn’t hold reference to ClassB instance.

Martin Fowler suggest that the aggregation link should not be used at all because it has no added value and it disturb consistency, Quoting  Jim Rumbaugh "Think of it as a modeling placebo".

Composition (Not-Shared Association)

In cases where in addition to the part-of relationship between ClassA and ClassB - there’s a strong life cycle dependency between the two, meaning that when ClassA is deleted then ClassB is also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link.

image

The composition link shows that a class (container, whole) has exclusive ownership over other class/s (parts), meaning that the container object and its parts constitute a parent-child/s relationship.

Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class,  thus changes in the composed class cannot be propagated to the rest of the system. Consequently, usage of composition limits complexity growth as the system grows.

Measuring system complexity

System complexity can be measured simply by looking at a UML class diagram and evaluating the association, aggregation, and composition relationship lines. The way to measure complexity is to determine how many classes can be affected by changing a particular class. If class A exposes class B, then any given class that uses class A can theoretically be affected by changes to class B. The sum of the number of potentially affected classes for every class in the system is the total system complexity.

Related Articles in Design Codes

UML Use Case Diagrams – Modeling the System Functionality
UML Deployment Diagrams – Modeling the System Physical Architecture
UML 2.0 Component Diagrams – Modeling the System Logical Architecture
UML Activity Diagram – Modeling Parallel Applications
UML Sequence Diagram: Interaction Fragment (Alt, Opt, Par, Loop, Region)

68 comments:

  1. This is a good explaination of relationships among classes.
    Recently I have to make a presentation file about this topic, may I use the content of this article ?

    This is Jack Yeh (jao_chin@so-net.net.tw)

    ReplyDelete
  2. Sure, Feel free to use it :-)

    ReplyDelete
  3. Thank you very much.

    Jack Yeh

    ReplyDelete
  4. Been all over looking for the best explanations about these relationships. This is by far the best. Simple, short and direct to the point. Thanks man.

    ReplyDelete
  5. Thanks a lot, I appreciate the feedback :-)

    ReplyDelete
  6. Excellent summary, finally after may search I could find out how to draw the differece between strong association and weak association.

    ReplyDelete
  7. Nice explaination.

    thanks.

    ReplyDelete
  8. Great explanation..

    Thanks

    ReplyDelete
  9. Thanks it was really nice . Specially the optional aggregation thing

    ReplyDelete
  10. nice helped a lot

    ReplyDelete
  11. are you sure that v can have 2 whole(s) in a whole-part relationship for a given part???
    eg:A(whole)------->B(part) and
    C(whole)-------->B(part)

    because v hav been taught that it is not possible..
    plz send a response ASAP to
    ruma.bhatnagar@gmail.com

    ReplyDelete
  12. Finally a good explanation! Thanks so much.

    ReplyDelete
  13. Good explanation, i read many books but did not find explanttion like this. keep it up.

    ReplyDelete
  14. Excellent work, finally understood relations ship between these 3 definitions

    ReplyDelete
  15. great work...it 'll be still be greater if u can pls put Java coding examples for each one.

    ReplyDelete
  16. That's really a good explanation!

    I have a tutorial how to determine the relationships through questions: http://yanny0808.blogspot.com/2010/08/uml-association-aggregation-composition.html

    ReplyDelete
  17. Thanx...really v nice stuff...for basic information and advance information as well

    ReplyDelete
  18. Excellent!! All UML books are confusing the above concepts. But this one simply describes it. Congrats!!

    ReplyDelete
  19. Thanks a lot...This is the best explanation I have seen for this topic...:)

    ReplyDelete
  20. finally a reasonable explaination of the uml and those arrows

    ReplyDelete
  21. Straight forward.. finally I understood UML !!! wait what's aggregation? lol

    ReplyDelete
  22. it would have better if completed this explaination with some code examples like which class holds what..

    ReplyDelete
  23. Thanks for a very accurate and simplified explanation on this topic.

    ReplyDelete
  24. Thanks for your explanation, it is much clearar compared to all other sources I read. However, one detail is still confusing. You mention in your explanation of aggregation and composition that one class is or is not exclusive owner of another class. Did you rather mean instances of a specific class? I guess class A and class B can have a composite relationship to class C, if class A and Class B have different instances of class C.

    ReplyDelete
  25. Yes, that's correct. Multiple classes can have a composite relationship with the same class, as long as they don't expose the composed class to the outside world and there's a life-cycle dependency between them.

    ReplyDelete
  26. It is a straightforward explanation. But does it mean that aggregation is a stronger case of association.

    ReplyDelete
  27. Yes , it's excellent explanation.


    Thanks,
    Anji

    ReplyDelete
  28. Thanks..
    Excellent post

    ReplyDelete
  29. Dude you are a star !!

    ReplyDelete
  30. Really a great explanation, I've never really understood the meaning/semantic of them and where to use them, and u put it very simple!

    I still have 2 situations I dodn't understand. So, when using composite, it means an object of class A (the one with the black symbol) stores 1 or more objects of class B, and when that A object is deleted, those B objects are also deleted?

    Another question. You talked about weak aggregation where class A has operation that receives parameter or returns object of class B. But what if an operation of class A does some processing using class B (being it static class or object instance)? That operation could call a class C operation, receive a class B object return, use that object internally but its return doesn't involve class B anymore. So, if inside class A's operation there's a use of class B (and therefore if class B is missing we can't compile class A!), will we need to add assossiation from A to B?

    To finish the comment, I'd add the information that when we have an assossiation of one-to-many, it will be implemented by adding to class A a collection of class B's objects. It's facultative to explicity put in class A the attribute that will hold that collection or leave it implicit by the assossiation.

    I took some time to learn how to implement this kind of model, now I myself like to explicitly show all classes attributes, and leave multiplicity to inform how a class knows about the other. In domain models I use multiplicity to inform how one depends of the other, in database models I use to inform their relational assossiations, and in class models I use to inform if a class relies on the other (it knows about that class and won't compile if the class is missing).

    ReplyDelete
  31. Hikari, the answer for your 1st question is yes - in composition, when the container class is deleted, all the contained objects are deleted as a results.
    I didn't quite understand your second question. My guess is that you were referring to a case where Class A is weakly associated with Class B, and in Class A internal implementation it get instance of Class C through Class B. In that case, there's a weak association relationship between Class A and Class C - and that should made visible in the UML diagram.

    Hope that helps. Aviad

    ReplyDelete
  32. This proved to be of a great help for my Automotive Software Engg. exam. Thanks a ton!!!
    Santosh G.

    ReplyDelete
  33. Superb explanation! Have one question regarding association vs aggression. In your example of strong association, you showed its multiplicity 1:1. That means both classes have class members as pointers to each other class. What about 1:* (one to many) association multiplicity? Would it be same as aggregation? Sometimes, I see 0..1:1..*(zero or one to one or many) multiplicity when looking at some relational database models (drawn with UML class diagram) where associations are used to describe relations between parent and child tables (for example, there are tools that allow to generated database schema from class diagram). But if one-to-many association is the same as aggregation then there's a logic conflict: in relation tables, a child table record can hold a reference (parent_id column) to only one parent record. So those associations are more composition style relations. Any thoughts on that?

    ReplyDelete
  34. Some additional notes: aggregation might be considered as many-to-many association relation because both end classes might be used in different related instances, so in some situations, it might be no matter what class is composite and what component - both might be included in each other. On the other hand, one-to-many association might be considered as composition .... but nop, because association does not restrict the same child object be assigned with another parent object. Actually, I do very agree with Martin Fowler about aggregation link should not be used at all because it adds ambiguity, because the same might be achieved with association with multiplicity one-to-many.

    ReplyDelete
  35. The multiplicity in strong association is a mistake - thanks for bringing this up!

    You can have one to many multiplicity for all the link types - Association, aggregation and Composition. Many to many is possible only for association, as whole-part (or parent-child) can only go one way.
    You also need to remember that with composition, the composed class is only visible to its parent.

    ReplyDelete
  36. I would like to discuss your answers further :)

    a) "The multiplicity in strong association is a mistake" - So, we don't need to put 1:1 multiplicity when modeling strong associations at all? If so then both strong and weak associations will look the same (both will just have association without any multiplicity). How to distinguish them? Maybe I'v missed something in your answer...

    b) "You can have one to many multiplicity for all the link types" - why do we need to have that on aggregation and Composition? Composition is for modeling one-to-many relation, and the same is with aggregation.

    c) I would like to argue about "Many to many is possible only for association". IMHO aggregation is very similar to many-to-many relation. For example, assume there's an aggregation relation between "part" and "airplane" classes . Then both classes might consist from each other: one part might belong to several airplanes, and airplane might consist of several parts. In relational database wold, that is definite a many-to-many relation. Though maybe we should use many-to-many association in such situations ... ?

    ReplyDelete
  37. What I meant by "multiplicity in strong association is a mistake" is that I shouldn't have drawn 1-1 multiplicity because it's confusing. You can have 1-1 multiplicity in strong association, but it's not a must.

    Here's my understanding,
    In aggregation and composition - you can have 1-1 and 1-many multiplicity.
    In association (week and strong) - you can have 1-1, 1-many and many-many multiplicity.

    ReplyDelete
  38. Good explanation this helped me to understand the class relationship well.

    ReplyDelete
  39. Very good explanation.Was of great of help in understanding the concepts

    ReplyDelete
  40. Excellent and Superb Explanation!!!

    ReplyDelete
  41. Very good explanation Superb!!!! Great Job

    ReplyDelete
  42. Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.

    ReplyDelete
  43. Keeping it simple always works!!! Good one.

    ReplyDelete
  44. All these days I could not understand whether to use association or aggregation! you opened my eyes
    kudos to you.
    Keep up your good work!

    ReplyDelete
  45. Thanks for sharing this outstanding stuff.

    ReplyDelete
  46. This post helped me to get ready to exam thanks buddy!!

    ReplyDelete
  47. This the best explanation I have ever read about the subject !

    Thank you soooooo much :D

    ReplyDelete
  48. Thanks for sharing :) I have just one question,
    In the post,as I understood, the only difference between Aggregation and Association, technically, is that the Aggregation can't model the Association(case of weak Association), Actually what mentionned as "weak Association" is the UML "Dependency" relation, so if that's the case what's the difference between the Aggregation and Association?

    ReplyDelete
  49. one of the best explanations ...thank you

    ReplyDelete
  50. I've been confusing these meanings for years.. Now all is clear. Thanks!

    ReplyDelete
  51. Dear aviade,

    Such a nice explanation. i have to question

    i class A have some public private or protected methods, in which we are creating the objects of other classes (let class B or C)
    Then what relationship this will denote?


    Rizwan Ishtiaq

    ReplyDelete
    Replies
    1. if class B and C are not exposed to other classes in the application, then the relationship is composition. The scope of the methods within which the classes was created makes no difference.

      Hope that helps

      Delete
  52. Simple and Effective explanation. good job

    ReplyDelete
  53. Good explanation, should have higher page rank on Google search.

    ReplyDelete
  54. Thanks for the great explanation the three primary relationships. I like how you took it and explained it even more. I was still looking up What is a Class Diagram in UML and found this to be pretty helpful as well. Thanks for all of your great work!

    ReplyDelete
  55. Aggregation and Composition both are specialized form of Association.
    Composition is again specialize form of Aggregation.

    http://www.javabench.in/2011/08/difference-between-association.html

    ReplyDelete
  56. Hello, thank you very much for your great article, but I still don't understand the arrow directions. In Association, arrow points from Class A -> Class B, however, in Aggregation, the diamond (which I, who may may be wrong, think is another kind of arrow) points from Class B to Class A. Would you be kindly to explain it to me? How can I decide which direction should arrow / diamond point to when I draw a class diagram?

    ReplyDelete
  57. This explanation is simple but very effective. It is easily understandable. Great job

    ReplyDelete