Class Diagram

U M L – C l a s s   Diagram

Basics

What is a class diagram? Imagine you were given a task of drawing a family tree. The steps you would take would be:

• Identify the main members of the family
• Determine how they are related to each other
• Identify the characteristics of each family member
• Find relations among family members
• Decide the inheritance of personal traits and characters

A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modelled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.

Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram.

By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.

A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modelling and designing systems design the system's class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.

Figure 1: sample class diagram

How does a class diagram relate to the use case diagrams?

When you designed the use cases, you must have realized that the use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. Each use case is further analyzed and broken up into atomic components that form the basis for the classes that need to be designed.

Elements of a Class Diagram

A class diagram is composed primarily of the following elements that represent the system's business entities:

• Class: A class represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business functionality, a class also has properties that reflect unique features of a class. The properties of a class are called attributes. Simply put, individual members of a family of our family tree example are analogous to classes in a class diagram.

As an example, let us take a class named Student. A Student class represents student entities in a system. The Student class encapsulates student information such as student id #, student name, and so forth. Student id, student name, and so on are the attributes of the Student class. The Student class also exposes functionality to other classes by using methods such as getStudentName(), getStudentId(), and the like.

A class is represented by a rectangle. The following diagram shows a typical class in a class diagram:

If you are familiar with object-oriented concepts, you will be aware of the concept of access modifiers. You can apply access modifiers such as public access, protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine the scope of visibility of the class and its methods and attributes.

You also can add documentation information to a class. Notes and constraints can be added to a list of attributes. Notes contain additional information for reference while developing the system, whereas constraints are the business rules that the class must follow, and are text included in curly brace brackets.

During the early phase of the system design conception, classes called Analysis classes are created. Analysis classes are also called stereotypes. In the UML context, stereotypes are UML models that represent an existing UML element, while showing additional characteristics that are common across the classes to be used for that application. Only one stereotype can be created for any UML element in the same system.

Analysis classes are of the following types as per their behavior, as shown in the following table:

Class	Behavior
Boundary	In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.
Control	These classes typically don't contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the boundary classes.
Entity	These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes.

• Interface: An interface is a variation of a class. A class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a definition of business functionality of a system. A separate class implements the actual business functionality.

You can define an abstract class that declares business functionality as abstract methods. A child class can provide the actual implementation of the business functionality. The problem with such an approach is that your design elements get tied together in a hierarchy of classes. So, even though you may not have intended to connect your design elements representing drastically different business entities, that is what might result. Hence, the use of the interface design construct in class diagrams. Different classes belonging to different and discrete hierarchies can maintain their distinct hierarchies and still realize the functionality defined in the methods of the interface.

An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that the methods are only declared in the interface and will be implemented by the class implementing the interface.

• Package: A package provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams. 

Figure 4 - A Package

From Figure 4, you can see a package is represented as a tabbed folder. A package can also have relationships with other packages similar to relationships between classes and interfaces.

Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean.

Sr. No.		Relation	Symbol	Description
1	Association			When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:
1 a.	Multiplicity			An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).
1 b.	Directed Association			Association between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.
1 c.	Reflexive Association		No separate symbol. However, the relation will point back at the same class.	An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.
2	Aggregation			When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.
2 a.	Composition			Composition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.
3	Inheritance/Generalization			Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.
4	Realization			In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.

Sr. No.

Relation

Symbol

Description

1

Association

When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:

1 a.

Multiplicity

An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).

1 b.

Directed Association

Association between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.

1 c.

Reflexive Association

No separate symbol. However, the relation will point back at the same class.

An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.

2

Aggregation

When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.

2 a.

Composition

Composition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.

3

Inheritance/Generalization

Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.

4

Realization

In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.

Here are a few terms that we will be using to annotate our class diagrams. You should be familiar with them:

1. Responsibility of a class: It is the statement defining what the class is expected to provide.

2. Stereotypes: It is an extension of the existing UML elements; it allows you to define new elements modelled on the existing UML elements. Only one stereotype per element in a system is allowed.

3. Vocabulary: The scope of a system is defined as its vocabulary.

4. Analysis class: It is a kind of a stereotype.

5. Boundary class: This is the first type of an analysis class. In a system consisting of a boundary class, the users interact with the system through the boundary classes.

6. Control class: This is the second type of an analysis class. A control class typically does not perform any business functions, but only redirects to the appropriate business function class depending on the function requested by the boundary class or the user.

7. Entity class: This is the third type of an analysis class. An entity class consists of all the business logic and interactions with databases.

Dos and Don'ts

Classes in a class diagram should be descriptive and must be named after business entities. Using business entities as names ensures greater readability of class diagrams.
Relationships between classes may not be apparent in the first iteration. Revise and refine your class diagrams to determine possible relationships during each iteration.
Designing is an incremental process and class diagrams are updated as the system gets built. Hence, do not try to capture and freeze the class diagrams of a system in the first pass.

Summary

Class diagrams are the basic building block used to define the design of a system. Today, we learned about the elements of a class diagram—classes, interfaces, and packages—and the different types of relationships among these elements such as association, aggregation, composition, generalization, and realization.

Consider a hospital:

Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two.

Heathcare assistants also attend to the patients, a number of these are associated with each ward.

Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time.