Define Aggregation in Object Modeling

Aggregation in the realm of object modeling and design is a paradigm that represents a specific kind of "has-a" relationship between objects. More than just association, it implies that one object, often referred to as the "whole", is composed of one or more other objects, which we term as "parts".
A classic example often used to illustrate this relationship is that of a "Car" and its "Wheels". A "Car" is an aggregate of several "Wheels" among other things, establishing a "Car has Wheels" relationship. In this case, "Car" is the "whole" and "Wheels" are the "parts".
It's essential to grasp that the nature of aggregation does not confine the existence of the "part" objects to the lifecycle of the "whole". A "part" object can exist independently from the "whole". So, using the above example, even if the "Car" is dismantled, the "Wheels" can exist independently, possibly to be used in another "Car".
In UML (Unified Modeling Language), which is frequently used for object modeling, an aggregate relationship is denoted by a hollow diamond attached to the "whole" object, pointing towards the "part" objects.
Aggregation forms a critical part of object-oriented modeling, providing a mechanism for building complex objects from simpler ones, thus allowing modelers to create hierarchical systems that accurately depict real-world relationships. The judicious application of aggregation can lead to more maintainable, modular, and understandable models, serving as an effective tool in the construction of complex systems.

Aggregation describes the assembly of objects to create a new object where the whole (the assembly) is greater than the sum of the parts. One the part objects are assembled into an aggregate, they are essentially hidden. The part objects become the implementation of the aggregate. To use the aggregate, the client objects must access the interface of the aggregate object. The part objects are inaccessible.

When the aggregate interface is invoked, the aggregate propagates the instruction, that is, it sends instructions to its parts to implement the requested function. The aggregate has no behavior of its own other than to coordinate the behavior of its parts. For example, a car is made up of an engine, transmission, fuel system, and other parts. When drivers want to move the car forward, they use the interface of the car, that is, the ignition switch, the gas pedal, the brake pedal, and so on, rather than access the parts directly. For example, a press of the gas pedal is implemented when the fuel system pumps gas, the engine turns over, and the transmission responds to the speed changes. Aggregation is not reflected in code. The implementation looks like any other association. Use aggregation to show intent. The intent of aggregation is to hide the makeup of a complex object by requiring client objects to talk to the aggregate.

Aggregation defines an object in terms of the parts assembled to make it. When you want the parts to be available for use even when the aggregate is dissembled, you are using weak aggregation^[1]. If the parts exist only as long as they are part of the aggregate, you are using strong aggregation^[2] or composition.
The Slide Show below describes an example of both weak and strong aggregation (composition):

Aggregation and composition can represent an infinite number of layers of detail.
However, remember to include only the level of detail needed to support the abstraction required by the problem domain.

[1]Weak aggregation: Players may participate in many teams at the same time. For example, they can play for a city league and a company team

[2]Strong aggregation or Composition: Chapters belong to a specific book. Without the book the chapters have no context and lose their meaning.