Question

Explain the backgrounds and the rationale for the following modelling advice: When you are in doubt whether you should model a relationship as an association or an aggregation, model it as an association.

Answer 1

Let's take a quick look at three types of relationships -

One-to-many (1:M or 1..*) - A person draws many sketches, but each sketch is drawn by only one person.

Many-to-one (M:N or "..") - A worker can learn many job-skills, and each job-skill can be learned by many workers.

One-to-One (1:1 or 1..1) - A comany has each departemnt manages by one chief engineer, and each chief-engineer can manage only one department.

Now what's an association?

An association simply is a relationship between two objects. In other words, association defines the multiplicity between objects. The above one-to-one, one-to-many, many-to-one, many-to-many words - all define an association between objects. Eg: A student and his professor have an association. A professor and his university have an association. A "CS student" and his "department (CS)" have an association. A CS student may have associations with multiple professors but a point of time, generally, he'll have association with only one department (CS). The professor, on the other hand, may have associations with multiple students and multiple departments (CS, Maths, Mechanical, etc) at the same time. However, the professor generally has association with only one university.

Cardinality is an indicator of the "associations" around a relationship.

Now what's aggregation?

Think of aggregation as a class A that comes into existence as result of another class B being aggregrated as a collection. Class B can however exist independently from A. Continuing our above example if the university ceases to exist, the departments will cease to exit, but the students and professors can still exist (students can enroll in different universities, while professors can apply to other universities).

Now instead of deleting the university, delete the "CS department". The university still continues to exist. If we think of a CS student as a child class object, then can the CS students still continue to meaningfully exist without the parent class object i.e. the CS department? After all, if a student doesn't have a department of his own, what shall the poor chap do? The answer is it depends. In a model it all depends on your requirements. If a "CS student" is required to be a separate entity and isn't allowed to enroll in midway in another department in the same university, then the entity "CS student" will cease to exist if the department dissolves. However, as a "student" he can still exist if enrollment to other departments is permitted within his university. So it all depends on the requirements of the model and the design. All in all, in aggregation, there is no ownership relation. Thus, aggregation is a weak association , that is, if the life of contained object doesn't depends on the container object, it is called weak association.

You can see the confusion this creates. When will the above student-department relationship qualify as pure aggregation and when will it be safe to consider it just as an association? This can create problems furthermore as we continue developing our model and as new requirements emerge.

To quote Fowler:

"aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation."

Thus, the precise semantics of shared aggregation varies by application area and modeler. Aggregation is semantically very weak as to offer nothing practically beneficial. It only has one valid corner case and that is acyclicity of recursive relationships. Thus from a practicality point of view we can use:

1. Straight Associations for 80%+ of the relationships that we're likely to want to model.
2. Compositions that will probably accounts for most of the remaining scenarios.

Aggregations can be avoided most of the times.