Both aggregation and composition are special kinds of associations. Aggregation is used to represent ownership or a whole/part relationship, and composition is used to represent an even stronger form of ownership. With composition, we get coincident lifetime of part with the whole. The composite object has sole responsibility for the disposition of its parts in terms of creation and destruction. In implementation terms, the composite is responsible for memory allocation and deallocation.
Moreover, the multiplicity of the aggregate end may not exceed one; i.e., it is unshared. An object may be part of only one composite at a time. If the composite is destroyed, it must either destroy all its parts or else give responsibility for them to some other object. A composite object can be designed with the knowledge that no other object will destroy its parts.
Composition can be used to model by-value aggregation, which is semantically equivalent to an attribute. In fact, composition was originally called aggregation-by-value in an earlier UML draft, with “normal” aggregation being thought of as aggregation-by-reference. The definitions have changed slightly, but the general ideas still apply. The distinction between aggregation and composition is more of a design concept and is not usually relevant during analysis.
Finally, a word of warning on terminology. While UML uses the terms association, aggregation, and composition with specific meanings, some object-oriented authors use one or more of these terms with slightly different interpretations. For example, it is fairly common to see all three UML relationships grouped under a single term, say composition, and then to discuss object-oriented relationships as being either inheritance (generalization) or composition.
2 comments:
:- For more clear understanding
A Slice Loaf is made of bread slices. Is the Association between the loaf and its slice is composition or aggregation?? i think its composition if we see the aspect of composition which states that.. the life time of child object is dependent upon life tmie of outer object there here... life time of slice is dependent upon life of "slice loaf" number 2 aspect is compulsory and optionality since "slice loaf" does not have any occurence if slices are not there.. which means "slife loaf" is the combination of slices and without slices "slife loaf" can not be a "slice loaf" this also proves that it must be composition instead aggregation comments can let me correct so don't hesitate to comment on it..
This is a very good question. The difference is that in Composition you will have additional code that involves deleting all the objects that are part of the composite object.
class TreeCutter {
public void cut(Tree aTree) {
//Implementation that will destroy the tree
// object, Leaf object, TreeRoot object etc.
// This implementation depends on the programming language.
// Could be a separate destructor or garbage collector based
// implementation.
}
}
In aggregation the lifetime of the parts can be beyond its whole. So, the destroy message will not propage to its components. If a plane is destroyed, you could still use some of the re-usable parts in another plane.
There is a lot confusion among the OOAD community on these concepts. The UML 2.0 has cleared some of these confusion by defining them clearly. For beginners I would suggest not to get hung up on the subtle differences but to know when to use which form of association in your model. Keep your model simple. If it does not add any clarity, don't use aggregation.
Post a Comment