Some sources say that aggregation means that the class owns the object and shares reference. Lets assume an example where a company class holds a list of cars but departments of that company has list of cars used by them.

class Department
   list<Car> listOfCars;

class Company
   list<Car> listOfCars;
   //initialization of the list

So in UML class diagram, I would do it like this. But I assume this is not allowed because it would imply that both company and department own the objects..

[DEPARTMENT]<>---|        //imagine this goes up to the car class

1 Answer 1


Mind the difference between aggregation and composition!

While in an aggregation instances of both associated classes may exist without a relation (e.g. a restaurant and a chair), for a composition the one can not exist without the other (e.g. a child without a parent).

In your case an aggregation seems more appropriate to me, and than it is no problem to model a aggregation between Department and Car AND Company and Car.

Besides that: such a situation is often modeled like Company <*>-- Department <>-- Car (where only Department stores the list of cars).

  • Not sure why the downnvote. Well it seems fine to me as well but some sources do say that aggregation can only have ONE owner and share references.
    – John V
    Nov 1, 2013 at 13:15
  • What sources? In which context?
    – Andy
    Nov 1, 2013 at 13:47
  • Books related to UML available on Google.
    – John V
    Nov 1, 2013 at 14:04
  • 2
    All aggregation means is that a class has a relationship with the other class. It doesn't mean ownership, although it can. An object should only have ONE owner. The owner is responsible for deleting the object. Ownership can be transferred and only the owner should delete an object. Adherence to this rule virtually eliminates memory leak issues in languages like C++. Not having to worry about transferring ownership of objects is the benefit of having a garbage collector. Aggregation does not mean ownership but composition does. However, composition is not really part of your question.
    – Dunk
    Nov 1, 2013 at 14:24
  • 1
    @user:It depends on how you want to design your application. I don't think a board owning the pieces makes sense. But possibly the player can own the pieces? However, probably a ChessGame instance is even a better owner for the pieces, in which case board and player would both show aggregation. Also, you may not know the best choice for owner until you start doing sequence diagrams. Thus, start out with aggregation and let your design tell you who should own the pieces. More often than not, the flow of your sequence diagrams makes this obvious.
    – Dunk
    Nov 1, 2013 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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