Aggregation overload! - in domain model

[fluxtah]

My domain model contains a LOT of aggregation, infact wherever I see an association, my brain thinks aggregate... I am doing something very wrong!

Can someone please help me understand when and when not to use aggregate.

For instance:

A product and a customer are part of an order

A product is part of a product catalog

I could show aggregation for the product and customer to the order, though I feel this is not correct, would I use normal association here?

I would think the relationship from the product to the product catalog would be an obvious aggregate, though the previous relationship of product/customer to order I can't quite figure out...

A product and a customer are part of an order does not seem quite true, more like a customer buys a product which creates an order  

regards

Ian

[mchiuminatto]

Hi Ian

If you are talking about aggregation (not composition) the difference between association and aggregation is just a matter of taste. Aggregation does not add much more semantic to association, except the constraint that you could not form cycles. If the part can live out of the context of the whole you decide which one is better to clarify the model.

A different history is composition. Here the parts can't live out of the context of the owner and they belong to just one owner.

Let’s take your business objects.

A product can live independently of an order. If an order is destroyed, no necessarily the products are destroyed. It’s a weak aggregation: association or aggregation can be used.

A customer can live independently of an order. If an order is destroyed, not necessarily the customer is destroyed. It’s a weak aggregation: association or aggregation can be used.

Products can live independently of a catalog. If a catalog is destroyed not necessarily the products are destroyed too. It’s a weak aggregation: association or aggregation can be used.

I will alter a little the structure of your Order to show when a stronger aggregation: a composition is required.

“An order is composed of order items”. Order items do not exist if an order doesn’t. If an order is “destroyed” their order items are “destroyed” too. The order items lives only while the order lives. This is a stronger aggregation (a composition) and must be explicitly modeled.


Hope it helps

[sargasso]

Well explained!
As a matter of fact I have been looking for a succint explanation like this for our training material.  So I hope you wont mind if I pinch it!  

The only thing I would add is that weak aggregations in diagrams can also help to highlight multiplicity (i.e owner attibute is a collection).

B

[mchiuminatto]

Oops I forgot to put the © symbol   .

[Rob_M]

From a C++ perspective, I like to think of it this way.

Composition - object is embedded in another.

class Car {

Engine bigass454;

}

Engine cannot exist outside of the Car.

Aggregation - object is owned by (i.e. part of ) another. The owning object is responsible for its deletion.

class Car {

Engine* theEngine;
}

Car exclusively owns the engine (no other car has this particular engine instance.)

Association - object is associated to another, but that object may exist elsewhere as well, as in:

class Car {

Owner* theOwner;
}

In this case, Car is not responsible for the deletion of the Owner, there is merely an association. The same instance of the owner may exist in other Car instances as well.

[fluxtah]

Wah cheers mchiuminatto that was a great explanation!

Cheers lads,

Ian

[mbc]

Hi all

I would like to have a go at explaining aggregation and composition too.

This is the way I see it:

An aggregate is something that consists of parts. It cannot exist without its parts.
To associate the aggregate with its parts an aggregation association is used, either strong (composition) or weak (aggregation). A composition is a special case of aggregation.
If the nature of the aggregate is such that the parts cannot be parts of another aggregate at the same time, then a strong aggregation (composition) is needed.

Example of Composition:
A brick house consists of bricks. It is an aggregate of bricks. Without the bricks, it would not exist. Furthermore, those bricks cannot possibly be part of another house at the same time. There is a strong aggregation relationship between the house and its bricks.

Example of weak aggregation:
A physics class in a school consists of students. It is an aggregate of students. Without the students, it would not exist. However, the students may also be part of a mathematics class as well. Therefore there is a weak aggregation relationship between the physics class and the students (shared aggregation).

Example of normal association:
The physics class is taught by a teacher. However, even if the teacher is sick, the physics class (a group of students) still exists. The teacher is not a part of the class. Therefore the relationship between the class and the teacher is not an aggregation, just a plain association.

What does this mean in code?
The difference between aggregation and association in code is slight. Normally it is not visible in the class declaration. Both aggregation and association would have to include the parts by reference (normally a pointer in C++). However, an aggregate class should implement some way of ensuring that its parts exist, since it cannot exist without them.

A composition is more obvious. A composite class would normally just implement its parts as members by value. That way there is no way around creating the parts when the composite is created.

To conclude:
Composition has a direct effect on code, and is therefore a very useful element in classes for code generation.
Aggregation has no direct effect on code except through the mind of the programmer who is implementing the class. It is a matter of choice whether you like to add this extra information to your model or not.

I hope this little story might be of use to someone.

Mikkel

[JourneymanDave]

Good explanations all around guys.  I like to see the different perspectives on these types of things.

[JohnH]

These are clear and useful explanations, but I can think of two aspects that might be too narrow a view...

1. In modeling, you can think of what the data "is", or what the data is "about". There is a difference between a data item that is composed of other data items, and a domain object that is composed of other domain objects. The data items may be assembled in ways that don't necessarily parallel the domain.

2. When considering history and traceability, deletion of domain objects doesn't necessarily delete the parts, just the relationship between those parts and the whole. An engine might be traced (even given identity with an OID) from manufacture, then assembled into an identifable truck, then removed, reworked, and made available for use in another and different truck. In certain domains keeping traceability of the parts, and even the batches of material used to form them, is critical (e.g., medical implants, nuclear power plants etc.). As more organizations seriously consider having continuous improvement programs, and data-driven decision making, there is an even greater call for building history and traceability into the models and data systems.