1

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.

RashiR
  • 35
  • 1
  • 4
  • Are you modeling the problem domain or solution domain? It matters greatly. – Jim L. Mar 19 '16 at 23:50
  • How does it matter? And I am implementing a solution to the given statement. – RashiR Mar 20 '16 at 00:55
  • A problem domain model represents the real world. In the real world, when a Company goes out of business, the Offices don't cease to exist. Since you are modeling the solution domain, you are free to take certain shortcuts for a particular application. However, you may regret doing so as requirements "change". (The problem domain doesn't really change, only the allowed shortcuts in your application! The truer to the problem domain you stay, the happier everyone will be later.) – Jim L. Mar 20 '16 at 02:15
  • I think your assumptions are correct (but a subject matter expert should confirm them) and your conclusions are also correct. – www.admiraalit.nl Mar 20 '16 at 21:27

2 Answers2

1

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!

Jim L.
  • 6,177
  • 3
  • 21
  • 47
1

While Jim's answer is correct, I want to add some extra information. There are two main uses for aggregation

  • Memory management
  • Database management

In the first case it gives a hint how long objects shall live. This is directly related to memory usage. If the target language is one which (like most modern languages) uses a garbage collector, you can simply ignore this model information.

In the second case, it's only partially a memory question. A composite aggregation in a database indicates that the aggregated elements need to be deleted along with the aggregating element. This is less a memory but in most cases a security issue. So here you have to think twice.

A shared aggregation however has a very esoteric meaning in all cases.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86