Object-Oriented Analysis and Design
Association, Aggregation and Composition in OOAD
In object-oriented analysis and design, an association represents a certain relationship between objects, but all objects have their own lifecycle and there is no ownership among the objects. For example, multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership among the objects and all have their own lifecycle. Aggregation and composition both are specialized form of association. Composition is again specialize form of aggregation.
An aggregation represents a whole that comprises various parts; so, a Committee is an aggregate of its Members. A Meeting is an aggregate of an Agenda, a Room, and the Attendees. At implementation time, this relationship is not containment. (A meeting does not contain a room.) Similaraly, the parts of the aggregate might be doing other things elsewhere in the program, so they might be refereced by several objects. In other words, There's no implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases an object has references to other objects. Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better, and because there are subtle implementation issues. I might allow tighter coupling relationships in an aggregation than I would with a simple "uses," for example.
Composition involves even tighter coupling than aggregation, and definitely involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for a element not to be declared as private. An example might be an Customer's name and address. A Customer without a name or address is a worthless thing. By the same token, when the Customer is destroyed, there's no point in keeping the name and address around. (Compare this situation with aggregation, where destroying the Committee should not cause the members to be destroyed---they may be members of other Committees).
In UML, aggregation is deifned as a special form of association (an association is a structural relationship that specifies that objects are connected to other objects) that specifies a whole-part relationship between the aggregate (whole) and a component part.
In an aggregation relationship, the part may be independent of the whole but the whole requires the part.
An aggregation relationship is indicated in the UML with an unfilled diamond and a line as follows:
There are many exmples of aggregation relationship:
In UML, composition is defined as a form of aggregation which requires that a part instance be included in at most one composite at a time, and that the composite object is responsible for the creation and destruction of the parts.
A composition relationship, also known as a composite aggregation, is a “stronger” form of aggregation where the part is created and destroyed with the whole.
A composition relationship is indicated in the UML with a filled diamond and a line as follows:
A typical example might be 'Invoice' and 'InvoiceLines', where invoice lines are clearly a part of an invoice and would never exist without being part of (and thus linked to) an invoice.
Notice that with both types of aggregation, the diamond is located on the side of the line pointing to the aggregate class which represents the "whole" in an aggregation (whole-part) relationship.
In terms of implementation, the elements in a composition relationship are typically created by the constructor or an initializer in a field declaration, but Java doesn't have a destructor, so there's no way to guarantee that the elements are destroyed along with the container. In C++, the element would be an object (not a reference or pointer) that's declared as a field in another object, so creation and destruction of the element would be automatic. Java has no such mechanism. It's nonetheless important to specify a containment relationship in the UML, because this relationship tells the implementation/testing folks that your intent is for the element to become garbage collectable (i.e. there should be no references to it) when the container is destroyed.
© 2019 Digcode.com. All rights reserved.