Class relations

In object-oriented programming, besides the inheritance relation that represents one of the fundamental concepts, there are a few other class relations that help us to model and develop complex software systems:

• Generalization and realization
• Dependency
• Association, aggregation, and composition
• 
  

Generalization and realization :

    

Generalization

Inheritance is also called an is-a relationship because the class inherited from another class can be used as the superclass.

When a class represents the shared characteristics of more than one class, it is called a generalization; for example, Vehicle is a generalization of Bike, Car, and Truck. Similarly, when a class represents a special instance of a general class, it is called a specialization, so a Car is a specialization of Vehicle, as shown in the following diagram:

In UML terminology, the relation to describe inheritance is called Generalization.

Realization

If generalization is the corresponding term in UML for object-oriented inheritance, realization, in UML, represents the implementation of an interface by a class in object-oriented programming.

Let's assume we create an interface called Lockable, which is implemented only by Vehicles that can be locked. In this case, a version of the previous diagram implementing Lockable for the Car class will look like this:

Dependency

Dependency is one of the most generic types of UML relationship. It is used to define that one class depends in some way or other on another class, while the other class may or may not depend on the first one. A dependent relationship is used to represent relations that do not fall into one of the cases described in the following sections. Dependency is sometimes called Uses-A relationship.

In general, in object-oriented programming languages dependency is used to describe whether one class contains a parameter of the second class in the signature of a method, or whether it creates instances of the second class by passing them to other classes without using them (without invoking its methods):

Association

An association represents the relationship between two entities. There are two types of association, namely composition and aggregation. In general, an association is represented by an arrow, as shown in the following diagram:

Aggregation

An aggregation is a special type of association. If inheritance is considered to be the is-a relationship, aggregation can be considered to be the HAS-A relationship.

Aggregation is used to describe a relation between two or more classes, when one class contains the other from a logical point of view, but instances of the contained class can live independently of the first class, outside of its context, or can be shared among other classes. For example, a Department HAS-A Teacher; additionally, every Teacher must belong to Department, but if a Department ceases to exist, a Teacher can still be active as shown in the following diagram:

Composition

As the name suggests, a class is a composition of another one. This is somewhat similar to aggregation, with the difference being that the dependent class ceases to exist when the main class ceases to exist. For example, a House is made up of a Room, but the Room ceases to exist if the House is destroyed, as shown in the following diagram:

In practice, especially in languages such as Java that have garbage collectors, the boundary between composition and aggregation is not so well defined. Objects are not destroyed manually; when they are no longer referenced, they are automatically destroyed by the garbage collector. For this reason, from a coding point of view, we should not really be concerned if we deal with a composition or an aggregation relationship, but it's important if we want to have a well-defined model in UML.