Thursday, December 20, 2007

Class diagram

In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.



Relationships
A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships:

Association:

An Association represents a family of links. Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are five different types of association. Bi-directional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Associations can only be shown on class diagrams.

Example: "department offers courses", is an association relationship.

Aggregation

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container--essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a clear diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Composition:

Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation. It is repersented with solid diamond shape.

Composition has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, every instance that it contains is destroyed as well.

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Differences between Composition and Aggregation:

The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole. The whole of an aggregation may have any multiplicity.

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car, the composition relationship is most appropriate. However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model, CM02. This is often called a "catalog" relationship.

No comments: