Class Diagram Relationships in UML with Examples

Many people consider class diagrams a bit more complicated to build compared with ER diagrams. While this might be true, this article helps clip some of the complexities of class diagrams in such a way that even non-programmers and less tech-savvy individuals will come to appreciate the usefulness of this modeling approach. In particular, this article explains how to correctly determine and implement the different class diagram relationships that are applicable in object-oriented modeling.

Relationships in UML class diagrams

Class Diagrams Explained

Class diagrams are visual representations of the static structure and composition of a particular system using the conventions set by the Unified Modeling Language (UML). Out of all the UML diagram types it is one of the most used ones. System designers use class diagrams as a way of simplifying how objects in a system interact with each other. Using class diagrams, it is easier to describe all the classes, packages, and interfaces that constitute a system and how these components are interrelated. For example, a simple class diagram may be used to show how an organization such as a convenient store chain is set up. On the other hand, precisely detailed class diagrams can readily be used as the primary reference for translating the designed system into a programming code.

The following figure is an example of a simple class diagram:

Simple class diagram with attributes and operations

In the example, a class called “loan account” is depicted. Classes in class diagrams are represented by boxes that are partitioned into three:

1. The top partition contains the name of the class.
2. The middle part contains the class’s attributes.
3. The bottom partition shows the possible operations that are associated with the class.

Those should be pretty easy to see in the example: the class being described is a loan account, some of whose attributes include the type of loan, the name of the borrower/loaner, the specific date the loan was released and the loan amount. As in the real world, various transactions or operations may be implemented on existing loans such as renew and extend.  The example shows how class diagrams can encapsulate all the relevant data in a particular scenario in a very systematic and clear way.

In object-oriented modeling, class diagrams are considered the key building blocks that enable information architects, designers, and developers to show a given system’s classes, their attributes, the functions or operations that are associated with them, and the relationships among the different classes that make up a system.

Relationships in Class Diagrams

Classes are interrelated to each other in specific ways. In particular, relationships in class diagrams include different types of logical connections. The following are such types of logical connections that are possible in UML:

• Association
• Directed Association
• Reflexive Association
• Multiplicity
• Aggregation
• Composition
• Inheritance/Generalization
• Realization

Association

Association

is a broad term that encompasses just about any logical connection or relationship between classes. For example, passenger and airline may be linked as above:

Directed Association

Directed Association

refers to a directional relationship represented by a line with an arrowhead. The arrowhead depicts a container-contained directional flow.

Reflexive Association

Reflexive Association

occurs when a class may have multiple functions or responsibilities. For example, a staff working in an airport may be a pilot, aviation engineer, a ticket dispatcher, a guard, or a maintenance crew member. If the maintenance crew member is managed by the aviation engineer there could be a managed by relationship in two instances of the same class.

Multiplicity

Multiplicity

is the active logical association when the cardinality of a class in relation to another is being depicted. For example, one fleet may include multiple airplanes, while one commercial airplane may contain zero to many passengers. The notation 0..* in the diagram means “zero to many”.

Aggregation

Aggregation

refers to the formation of a particular class as a result of one class being aggregated or built as a collection. 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. In the same example, books will remain so even when the library is dissolved. To render aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape near the parent class.

Composition

Composition

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. For example, a shoulder bag’s side pocket will also cease to exist once the shoulder bag is destroyed. To depict a composition relationship in a UML diagram, use a directional line connecting the two classes, with a filled diamond shape adjacent to the container class and the directional arrow to the contained class.

Inheritance / Generalization

Inheritance

refers to a type of relationship wherein one associated class is a child of another by virtue of assuming the same functionalities of the parent class. In other words, the child class is a specific type of the parent class. To depict inheritance in a UML diagram, a solid line from the child class to the parent class is drawn using an unfilled arrowhead.

Realization

Realization

denotes the implementation of the functionality defined in one class by another class. To show the relationship in UML, a broken line with an unfilled solid arrowhead is drawn from the class that defines the functionality to the class that implements the function. In the example, the printing preferences that are set using the printer setup interface are being implemented by the printer.

Conclusion – Class diagram relationships are easy to understand

If you are a programmer or systems designer, you’ll be building or analyzing class diagrams quite often since they are, after all, the building blocks of object-oriented modeling. As demonstrated by this article, class diagram relationships are fairly easy to understand. As a rule of thumb, keeping class diagrams as simple as possible allows them to be more easily understood and appreciated by different types of audiences. For this purpose, remember to label your classes and relationships as descriptive as possible. Lastly, class diagrams also evolve as the real world systems they represent change. This implies that you don’t need to put in much detail in your first draft. All the classes, interfaces and relationships that are integral to the system or application you are designing will eventually emerge as the development process moves forward.

To make your job a lot easier, you can check out the online diagramming application offered on the Creately site. Besides being easy to use, the platform provides a comprehensive range of UML templates among other diagramming services. In addition, the platform supports collaboration and may be integrated into an existing company wiki or Intranet to keep diagrams well documented and updated. Having such a tool on your side will greatly improve your company’s development initiatives and will help your team meet its targets.

Now that you understand class diagram relationships it’s time to draw some, get started with this easy to use class diagram templates.

References:

1. UML basics: The class diagram An introduction to structure diagrams in UML 2 by Donald Bell

2. Class diagram as published on the Wikipedia website

3. The UML Class Diagram Part 1 as published in the website developer.com

4. The Class Diagram from Visual Case Tool – UML Tutorial as published on Visual Case website

5.  Associations as published on the Sybase website