Classes are often directly related to a physical or abstract object in the real world. Think about an automobile, they could derive to other types of vehicles such as a car, truck, or van. They may contain other complex objects such as an engine, dashboard, on board display system, and safety systems.
Just like those objects often relate to one another, in UML a class can relate to other classes. We need different ways of describing those relationships.
There are several class relationships used in UML, six in total,. A line denotes a relationship, and a symbol with the line/line type, denotes what type of relationship there is. The details for them are below:
Inheritance
Inheritance is one of the most common relationships you will find and use. This says one class (the child) inherits from another (the parent). The arrow points to the child class. The child will get all of the attributes and methods of the parent class.
Consider a class called Shape. From it you could derive Circle, Rectangle, Square, and a host of other shapes. In fact, the generic shape would be abstract, as it is something that you couldn’t instantiate – you need a specific shape to create, but by having an abstract class, we can still establish attributes and operations (methods) which will make developing the child classes faster and easier.
If the parent is an abstract class, it will be italicized as you can see from the above example.
An inheritance relationship is called an is-a relationship. Because a child, is a type of the parent. From our example above, you could say that a Circle is a Shape.
Association
An association shows a relationship between classes and is represented by a solid line between classes. They are typically named using a verb or verb phrase which reflects the real world problem domain.
A simple association shows a link between the two classes.
However, you can also show cardinality, which is how many there would be in relation to the source. If you look to the left, you can see how there may be only one, zero or one, or other numbers of contained class objects demonstrated in the cardinality.
If this looks familiar, it may be because you had a database class and you’ve used ERD diagrams, which can show similar relationships between tables.
Aggregation
Aggregation is a special type of relationship showing that one class “is a part of” another class. It is shown with a solid line, and a hollow diamond at one end. It is a special subset of the association relationship.
In aggregation, there is a concept of ownership. In this example, an Animal owned by the Human.
However, with Aggregation the idea is that these two can also exist independently, meaning that their timelines of when they are created and destroyed can be independent of one another, and they can exist without the other.
This means that while Class2 is often associated with Class1, it can be considered separately.
Think about a Class Human and a Class Animal. The Animal may be a pet, and therefore may have an aggregation to it, but it doesn’t have to “belong” to a human for it to exist.
Note: It is important to note that this relationship does not imply a parent/child or ownership style of relationship. In fact, there may be multiple relationships between the second class object and other class objects.
Composition
Composition is another special case of association. It is similar to Aggregation in that the relationship is a “part of” the main class.
The difference however is that the objects of the second class will cease without the object of main class. Likewise, the secondary object cannot exist without the primary object.
It is shown as a solid line with a solid diamond.
Dependency
A dependency is another type of special association. It is for when a class is dependent on another class, but does not store that classes object in a given field. This typically means that it would use a method from the other class’s object.
It is shown as a dashed line with an arrow pointing to the dependent class.
In this case Class1 is dependent on Class2. A change in the definition of Class2 may cause changes to Class1, but not necessarily the opposite of that.
Realization
This special relationship is often used to describe an interface with multiple other classes, in which the classes will need to implement the interface’s methods (thus realize them). It is show with a dashed line, and a filled arrow.
A common example of this would be for an Interface (notice that the interface is denoted in the Class Model), where you need to share a method that needs to be overwritten by the classes with that interface.
Consider a set of classes for a Shape. It might have an abstract class for getArea() since all shapes will need that functionality. However, not all Shapes have sides (i.e. circles and ovals) therefore, only shapes that use the Polygon interface will have the getSides() method.
The realization relationship is a good way to demonstrate this.
UML Class Relationships was originally found on Access 2 Learn
