UML aggregation: how can the "whole" exist without its "parts"?

Question

I understand aggregation is a "whole/part" relationship, where the "parent" class is the whole and the "child" class is the part (and this is unidirectional), and that each class exist independently (as opposed to composition). But some examples I've seen are confusing me. For instance, the path/segment relationship. I understand the segment can exist even if there is no path, but if they're independent then the path should also exist.

Same thing goes for car/wheel. I get that both objects can have independent lifecycles and a wheel can be created without being part of a car yet, but how can the car exist without weels? Some other parts of the car may exist, but it's not a complete car until it has wheels...

I've also seen triangle/line. I can draw lines and have them form a triangle or I can have just lines. But how can I have a triangle without lines?

I suspect this is because the relationship is unidirectional, but then what confuses me is the fact that both classes are independent. I understand how the child class can exist without being aggregated, but I don't understand how the parent class can have its own lifecycle without its child objects.

Answer 1

Composition means mine! Keep your hands off.

Aggregation means look what showed up here.

Association means look what I can find.

Let's try giving these examples some actual stories.

If a car is composed of tires it means those tires belong to that car and nothing else. No sticking them on bicycles. When the car gets crushed in the junk yard the tires are going with it.

If a car has an aggregation of tires it means those tires just happen to be with the car now. They may end up on something else later or even now. The tires have an independant life of their own.

The car needs tires in either case. This isn't about the car's needs. It's about the tires.

Real world examples that try to explain the difference between composition and aggregation often fail to tell the story that makes the difference meaningful and in the end all it tells you is how the author feels about their cars tires.

For example a triangles segments might be part of other shapes while they're part of a triangle. But they might be segments that never exist for anything other than to be part of this triangle.

Examples without the stories are simply a waste of time. Stop expecting them to make sense. Tell me the story and I'll tell you which kind you have. Give me an example with no story and all you'll learn about your car tires is how I feel about mine.

Answer 2

Aggregation is defined by UML as a „property that has a shared semantic“ (section 9.5.3):

Indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeller.

This is rather vague:

• It is generally understood as a part/whole relation, with parts that can potentially be shared. This strongly suggest that the part can exist without the whole.
• It is not fully specified, so can easily lead to misunderstandings. The best is therefore to avoid aggregation if possible. You do not need aggregation to model a part/whole relation.

The shared aggregation is different from the composite aggregation. For the latter, the UML specification is explicit, and it states that the whole (composite) has the responsibility for the existence and storage of the part (composed objects). The composed part can therefore not exist without the composite whole.

Answer 3

Some times an aggregation with no members makes sense... Imagine that one of the classes on your system represents a movie. And you want the system to keep the Actor credited in the movie. Does a movie without actors make sense? Yes. It could be some silent animation or other artsy stuff that manages to have no actors.

I find that a better text book example of Aggregation than the car and wheels thing which could easily descend into Theseus’s paradox (in the student mind, I mean, we put a primary key on that). Oh, and let us not forget that a wheel cannot be in two cars at the same time, however an Actor could be credited in two movies, no problem.

---

On the other hand, sometimes an aggregation with no members makes no sense. For that, we have Multiplicity. What are the constraints on the number of members? A Triangle must have three Lines. No more, no less. Note that Lines can still exist on their own, thus the triangle does not control the life-cycle of Lines... it is not Composition.

---

About the Path and Segment example. A Path without segments takes you from where you are to the same place. Whatever or not that makes sense in your system, you gotta decide. That is, the answer will be different from one system to another.

In fact, it could be different from one part of the system to another… For example, it could make sense to allow a Triangle with no Lines as a view model object, because we create it and then steadily populate it with user input over multiple interactions... while at the same time a Triangle domain model class with any number other than three Lines is not allowed… and in fact, the database entity used to store it might not have that constraint at all (saying “exactly 3” to the database engine is not easy, and could be impossible depending on the database engine).

Answer 4

This is about how you (the developer, or a team of developers) decide to model the problem (i.e., how you decide to view and represent various elements involved based on your understanding of the problem and the relationships within).

That means that the same example can be under different circumstances modeled in two different ways (e.g. in a racing game, the player model may be considered a part of the car model, and for the purposes of that specific game, it may not have an independent existence; in a game where you are normally on foot, but can use vehicles, they are distinct entities that sometimes may assume a "containment" relationship).

So, when reading various material online, don't focus too much on the specifics of the example, but try to understand the intent, and guess at some of the assumptions made based on the context, and based on what you know about composition and aggregation.

Let's go over some of your examples:

• The path/segment relationship: Suppose you are creating some kind of drawing software, or some sort of animation editor, or whatever. While for the user there is no path without segments (and quite possibly, no free floating segments without a path), internally, you, as the developer, may consider a path to be an abstract concept, that contains segments that can be swapped, combined and manipulated in various ways, maybe even shared in order to achieve certain special effects (I'm making this up as I go along, by the way - I'm not saying this is the-one-right-way-to-do-it). So, for you, in terms of how the software works and how things are represented, they have an independent existence. You may even do things like have a null path (with no segments) that serves as a placeholder, or an empty segment container that you'll use later, or it could simply implement the path interface (with each method doing nothing) so that your client code could be written in a simpler way. Again, the user of the software may have a completely different view of these concepts; this is about how you internally went about solving the problem of representing paths and supporting the desired behaviors - i.e., how you modeled the problem.

• car/wheel: Again, depends on the problem domain; if you need to be able to swap wheels, or track the car & the wheels separately (I don't know, maybe the software is for a vehicle repair shop), then model that as aggregation. If it makes no sense for what you are doing to allow the wheels to exist without a car, or even if the decision to not support that is acceptable and it simplifies the problem & the code, then model it as composition.

Note two things. First, you can choose to leave the ownership details unspecified and model things using generic associations, and that is perfectly fine; use aggregation and composition when you feel that the precise relationship between two model elements is important and you want to communicate that to other developers that may be working on the same project. Second, often, all these relationships will be implemented, in terms of language features, keywords used, etc., in the same way; it's the behavior, interactions, and the lifecycle of the instances that makes the difference.

Answer 5

UML aggregation: how can the “whole” exist without its “parts”?

You are actually confusing aggregation with association.

• Aggregation (AKA the having relationship) is a part–whole relationship, meaning that the whole cannot exist without the part. The part is an essential attribute of the whole. E.g. a car (the whole) and its engine (the part) are in aggregation since a car needs its engine to exist.

• Association (AKA the acquaintance relationship or using relationship) on the other hand is not a part–whole relationship. One object is an accidental attribute of the other. E.g. a car and its owner are in association since a car does not need its owner to exist.

Note. — As noted by @Christophe, aggregation can be subdivided into two categories (but it is irrelevant to your question which was about general aggregation): shared aggregation where the part can exist without the whole, and composite aggregation (AKA composition, or unique aggregation as I like to call it) where the part cannot exist without the whole.

---

References

Gamma (Erich), Helm (Richard), Johnson (Ralph), Vlissides (John), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Boston, 1994. Relevant excerpt § 1.6, p. 22:

Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times. Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes.

Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called ”association” or the “using” relationship. Acquainted objects may request operations of each other, but they aren’t responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

Note. — OMT was published in 1991 and UML in 1997, so the authors use OMT aggregation to refer to UML composite aggregation (AKA composition).

Grogono (Peter), Sakkinen (Markku), “Copying and Comparing: Problems and Solutions”, ECOOP 2000: Object-Oriented Programming, Springer, Berlin, p. 226-250, 2000. Relevant excerpt, § 2.1, p. 228:

We distinguish essential and accidental attributes of an object.{Footnote: This distinction is based loosely on Aristotle’s categories.} An essential attribute is indisputably a part of the object; an accidental attribute is another object that is related in some way to the object in question but is not a part of it. For example, if the object in question is an instance of class Car, we would consider the attribute engine to be essential but the basic value distanceTravelled and the reference owner to be accidental. The distinction between “accidental” and “essential” is orthogonal to that between “reference” and “containment”. The model permits all four possibilities. When an attribute is represented by a reference, it is the referent object itself, not the reference, that is the accidental or essential attribute.

Accidental attributes are intended as a generalization of associations. An association is a “structural relationship between peers” where “peers” are classes at the same conceptual level. An association is a kind of accidental attribute but it is not the only kind. Associations are usually implemented as references to other full-fledged objects, although more elaborate implementations have been proposed. But objects may also contain counters, flags, descriptors, and other attributes that are needed by the application software but are conceptually not part of the object.

The distinction between essential and accidental is not always obvious. As a rule of thumb, the relationship between two objects is an association (and therefore accidental) if destroying one object does not logically entail destroying the other, otherwise one object is an attribute of the other. Similarly, an attribute is accidental if removing it from the object does not destroy the basic integrity of the object.

Answer 6

Same thing goes for car/wheel. I get that both objects can have independent lifecycles and a wheel can be created without being part of a car yet, but how can the car exist without wheels?

First, we have to define what a car is, in relation to its wheels. Not the English definition, but what it means for our codebase. Can a car exist without wheels?

• Well, if you work at a car assembly factory and you're writing software to keep track of the car on the production line, then the answer is yes. Unless you really insist on calling it something else until the wheels are fitted, but then you've already decided the answer to your own question.
• If you work at a tyre fitting shop, then you might actually assume that your cars always have some kind of tyres attached to them (not physically, but administratively), but you're going to have many more tyres that exist without being attached to a car.
• If you're making a racing game, the odds are that cars and their wheels share the same lifecycle.

But how can I have a triangle without lines?

It again depends on how you define a triangle. In mathematical terms, the lines are an explicit expectation, because they're a zero cost addition and fixed when you already have the 3 vertices that make up your triangle.
However, even in math, a triangle is generally defined by its points, not its vertices. That's not a blanket statement, but it is predominantly the case when we talk about triangles.

In software development, tracking the lines (on top of the vertices) is extra data, and that's a non-zero addition. So the question becomes if it's necessary to have these lines alongside having the vertices, or not.

In your application, lines might not need to exist on a triangle. You may be substituting the triangle line itself by an on-the-fly calculation based on the two vertices that the line would connect. Or, alternatively, you might simply not care about the edges and only care about the vertices.

but I don't understand how the parent class can have its own lifecycle without its child objects

Because you're defining the parent as something that must have its children. You've already decided that the parent can only be defined as having the child, and then the conclusion that you can't have the parent without its child is obviously set in stone.

But parents don't always have to have children. There are two main ways of thinking about it:

• It might be that the child is not required. You currently think that cars need wheels, because you're both thinking about drivable cars (and not the broken down ones) and also because you haven't accounted for the hovercar yet. A hovercar does not need wheels, so your system has to be able to have both wheeled and hovering cars - therefore making wheels not required.
• It might be that the child is required for the parent to be complete, but that your application will contain incomplete parents and trace their way to completion. The best example here is the car being built in the factory. The wheels are pretty much the last thing to go on, but your car needs to exist well before then if you are to track its production process.