Does aggregation have to be one-to-many?

Question

I've always avoided using aggregation because it seems so subjective which one-to-many relationships should be classed as aggregations. But I'm reviewing a model produced by someone else in which aggregations are used for many-to-many relationships (as in: a course consists of several modules, a module may be part of several courses). That strikes me as plain wrong, but I can't find a definitive rule against it. What's the official ruling?

Answer 1

Two things:

1. Are shared aggregations allowed? According to the UML spec, yes.
2. Is it useful in practice? Generally I'd say no.

I am not a fan of the UML Aggregation relationship. Whilst ownership is intuitively appealing, it is too subjective practically. I don't use it, and generally don't recommend it be used (although see footnote). Instead, focus on the important questions:

1. What's the cardinality?
2. What's the create/delete behaviour?
3. Why does the relationship exist? (i.e. what business fact/rule is the relationship capturing?

All above can be done with straight associations. If the answer is (a) it's one to many, (b) the 'one' end is responsible for creating/deleting the 'many' end and (c) you really want to, then use the Composite association. Aggregation however doesn't generally improve readability of the model, it adds confusion and detracts from surfacing the underlying domain rules/requirements.

hth.

footnote: there is one scenario where Aggregation does have well-defined semantics and can be useful. Specifically, if you have a recursive relationship, Aggregation says the resultant object structure is acyclic (i.e. a DAG). Downside is relatively few people realise that property - certainly not business domain experts. So you typically have to highlight anyway, e.g. in a comment / constraint.

Answer 2

A good website for this is

http://www.uml-diagrams.org/class-diagrams.html

If you search there for "Shared and Composite Aggregation" you will read, that shared parts can be modeled as aggregations. Even if the composite holding the part will be discarded the parts are allowed to survive.

This seems to make many to many relationships possible. For example sharing a part of a view for several view-components. Why not...

Personally this matches my understanding, that UML is very interpretative.

Answer 3

1. Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. To often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you mean "shared".

2. Again, if we'll look at the UML standards (look for Superstructure documentation there), we'll find, that "Precise semantics of shared aggregation varies by application area and modeler." So, ANY strategy you choose is acceptable. And you even can use different strategy for different projects.

3. But the shared aggregation IS useful and CAN be used with multiplicities on both sides and even the empty diamond can be on both sides.

The association in UML is an abstraction, that can be realized in any language and in any way, only the realization must be up to the diagram.

Such association, as on the diagram, can be realized as following:

Every instance of Student has a list of courses he is registered to, and every instance of Courses has a list of registered students/participants.

But this is not the only way of realization. There could be arrays instead of lists, and even somebody can make it without any normal collection at all - simply using the addresses in memory in C++.

Of course, we could draw two associations, one for student's list of courses and the second for courses' list of students. But thus:

• our diagram becomes more complex and, therefore, less readable.
• we are describing thoroughly the elementary things that any coder will do anyway in 99% cases.
• we are limiting the freedom of coders. And in 1% of cases they'll have to choose between not following the diagram and not coding effectively. It is simply not your job.

So, do as you wish. Forbidden is only to change the strategy during one project and to FORBID others to use their only strategy.