In UML terms, a role can have one of three types:
1. Association
2. Composition
3. Aggregation.
Associations indicate that the two classes have a relationship as discussed above. Composition and aggregation indicate something more about the relationship:
Composition (Call By Value ) indicates that one class belongs to the other. It’s strong Aggregation ( represented by Blackend Diamond in UML) Whole is responsible for the parts Creation and Destruction . A polygon is made up of several points. If the polygon is destroyed, so are the points. A Owner has a house ; ( Aggregation ) ; A house has a chair ( Aggregation ) ; A house has Wall , Roof , Floor ( Composition ) ; A chair can exist independent of House ; When a house is destroyed Wall, Roof anf Floor will be destroyed,
Aggregation (Call by Reference ) is similar to composition, but is a less rigorous way of grouping things. It’s week Whole-Part Relationship ; ( Represented by Hallow Diamond in UML) ( Call By Reference ) An order is made up of several products, but a product continues to exist even if the order is destroyed.
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.
Example:
Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university.
Composition is usually implemented such that an object contains another object. For example, in C++:
class Professor;
class Department
{
...
private:
// Aggregation
Professor* members[5];
...
};
class University
{
...
private:
std::vector< Department > faculty;
...
create_dept()
{
...
// Composition (must limit to 20)
faculty.push_back( Department(...) );
faculty.push_back( Department(...) );
...
}
};
In aggregation, the object may only contain a reference or pointer to the object (and not have lifetime responsibility for it).
Sometimes aggregation is referred to as composition when the distinction between ordinary composition and aggregation is unimportant.
The above code would transform into the following UML Class diagram:
ref:
http://en.wikipedia.org/wiki/Object_composition#Aggregation
