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.

• Propagation 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 diagram below describes an example of both weak and strong aggregation (composition):

In the context of object-oriented modeling and design, the terms "weak aggregation" and "strong aggregation" pertain to specific types of relationships between objects, also known as "associations". These terms essentially describe the nature of the bond between the "whole" object and its "part" objects.

1. Weak Aggregation (Shared Aggregation): This refers to an association where the lifecycle of the "part" object is not strictly dependent on the "whole" object. In other words, if the "whole" object is destroyed or removed, the "part" objects can continue to exist independently. They are not necessarily deleted or destroyed along with the whole. An example of this could be a "Classroom" object and "Student" objects - even if a particular classroom is no longer used, the students (parts) still exist and can be associated with other classrooms (wholes).
2. Strong Aggregation (Composition): This refers to an association where the lifecycle of the "part" object is strictly tied to the "whole" object. If the "whole" object is destroyed or removed, all its associated "part" objects are also automatically deleted or destroyed. They cannot exist without the presence of the whole. An example could be a "House" object and "Room" objects - if a house (whole) is demolished, its rooms (parts) cease to exist.

In UML (Unified Modeling Language), these relationships are typically represented as follows:
Weak Aggregation is depicted by a hollow diamond at the "whole" end of the line connecting the objects. Strong Aggregation is depicted by a filled diamond at the "whole" end of the line connecting the objects. Remember, the use of weak or strong aggregation should be dictated by the specific rules of the domain being modeled. Selecting the right type of aggregation ensures that the object model correctly represents the real-world relationships between the entities.
In strong aggregation a part entity cannot exist without the containing whole entity in the whole-part relationship. For example, university has multiple departments. This a composition relationship between the university and department entity. A department cannot exist on its own with out the university.

Composition is used for aggregations where the life span of the member object depends on the life span of the aggregate. The aggregate not only has control over the behavior of the member, but also has control over the creation and destruction of the member. In other words, the member object cannot exist apart from the aggregate. This greater responsibility is why composition is sometimes referred to as strong aggregation. Composition is a subset of aggregation, just as aggregation is a subset of association.
1) Weak Aggregation

2) Strong Aggregation or 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.