Search code examples
associationsumlaggregationcomposition

Aggregation or composition or simple association?

There is one example to explaining associations in UML.

A person works for a company; a company has a number offices.

But I am unable to understand the relationship between Person, Company, and Office classes. My understanding is:

  1. a company consists of many persons as employees but these classes exist independently so that is simple association with 0..* multiplicity on Person class' end
  2. a company has many offices and those offices will not exist if there is no company so that is composition having Company as the parent class and 0..* multiplicity on Branch class' end.

But I am not sure of 2nd point. Please correct me if I am wrong.

Thank you.

Solution

  • Why use composition or aggregation in this situation at all? The UML spec leaves the meaning of aggregation to the modeler. What do you want it to mean to your audience? And the meaning of composition is probably too strong for this situation. Thus, why use it here? I recommend you use a simple association.

    If I were you, I would stay truer to the problem domain. In the world I know, Offices don't cease to exist when a Company goes out of business. Rather, a Company occupies some number of Offices for some limited period of time. If a Company goes out of business, the Offices get sold or leased to some other Company. The Offices are not burned to the ground.

    If you aren't true to the problem domain in an application, then the shortcuts you take will become invalid when the customer "changes the requirements" for that application. The problem domain doesn't actually change much, just the shortcuts you are allowed to take. If you take shortcuts to satisfy requirements in a way that are misaligned with the problem domain, it is expensive to adjust the application. Your customer becomes unhappy and you wind up working overtime. Save yourself and everyone the trouble!