Introduction
Unified Modeling Language (UML) notations are used in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. The model is useless, unless its purpose is depicted properly.
Class Notation
UML class is represented by the following figure. The diagram is divided into four parts.
- Top section is used to name the class.
- Second one is used to show the attributes of the class.
- Third section describe the operations performed by the class.
- Fourth section is optional to show any additional components.
Relationships Between Classes
UML precisely conveys how code should be implemented from diagrams. If precisely interpreted, the implemented code will correctly reflect the intent of the designer.
A relationship can be one of the following types:
- Association
- Inheritance
- Realization
- Dependency
- Aggregation
- Composition
Association
It defines a structural relationship where two components are linked to each other. One class instance uses the other class instance or vice-versa, or both may be using each other. But lifetime of the instances of the two classes are independent of each other and there is no ownership between two classes.
For example, passenger and airline may be linked.
Inheritance
A Inheritance (or Generalization) is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Specific classifier inherits the features of the more general classifier. It represents an is-a relationship.
SubClass1
and SubClass2
are derived from SuperClass
. This relationship is displayed as a solid line with a hollow arrowhead that points from the child element to the parent element.
Realization
Realization is a relationship between the blueprint class and the object containing its respective implementation level details. In other words, it is relationship between the interface and the implementing class.
For example, the Owner
interface might specify methods for acquiring property and disposing of property. Person
and Corporation
classes need to implement these methods.
Dependency
This relationship means that the class at source end of the relationship has some sort of dependency on the class at target (arrowhead) end of the relationship. It defines a relation between two classes, where one class depends on another class but another class may or not may depend on the first class.
For example, the following simple states that class A depends on class B in some way. In UML example, dependency means that class A uses class B, but that class A does not contain an instance of class B as part of its own state. It also means that if class B’s interface changes it will likely impact class A and require it to change.
Aggregation
It refers to the formation of a particular class as a result of one class being aggregated or built as a collection. It is same as association but with an additional point that there is an ownership of the instances, unlike association where there was no ownership of the instances.
For example, the class Library
is made up of one or more books, among other materials. In aggregation, the contained classes are not strongly dependent on the life cycle of the container. Books will remain so even when the library is dissolved. To show aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape near the parent class.
Multiplicity (number on the line) shows that one library can have one to many books.
Composition
This relationship is very similar to the aggregation relationship. With the only difference being its key purpose of emphasizing the dependence of the contained class to the life cycle of the container class. That is, the contained class will be obliterated when the container class is destroyed.
Composition Vs Aggregation
Composition is a subset of association and aggregation. Aggregation is a subset of association. In other wodrs, Association is a super-set of aggregation and composition can be represented as:
Example
Multiplicity shows that one Customer can have zero to many Order.