Class Diagram | Unified Modeling Language (UML)

A UML class diagram is a visual tool that represents the structure of a system by showing its
classes, attributes, methods, and the relationships between them. It helps everyone involved in a
project—like developers and designers—understand how the system is organized and how its
components interact
What are class Diagrams?
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system i.e. used
to construct and visualize object-oriented systems.

In these diagrams, classes are depicted as boxes, each containing three compartments for the class name,
attributes, and methods. Lines connecting classes illustrate associations, showing relationships such as
one-to-one or one-to-many.

Class diagrams provide a high-level overview of a system’s design, helping to communicate and document the
structure of the software. They are a fundamental tool in object-oriented design and play a crucial role in the
software development lifecycle.

What is a class?
In object-oriented programming (OOP), a class is a blueprint or template for creating objects. Objects are
instances of classes, and each class defines a set of attributes (data members) and methods (functions or
procedures) that the objects created from that class will possess. The attributes represent the characteristics or
properties of the object, while the methods define the behaviors or actions that the object can perform.

UML Class Notation

class notation is a graphical representation used to depict classes and their relationships in object-oriented
modeling

1.​ Class Name:

●​ The name of the class is typically written in the top compartment of the class box and

is centered and bold.

2.​ Attributes:

●​ Attributes, also known as properties or fields, represent the data members of the

class. They are listed in the second compartment of the class box and often include

the visibility (e.g., public, private) and the data type of each attribute.

3.​ Methods:

●​ Methods, also known as functions or operations, represent the behavior or

functionality of the class. They are listed in the third compartment of the class box

and include the visibility (e.g., public, private), return type, and parameters of each

method.

4.​ Visibility Notation:

●​ Visibility notations indicate the access level of attributes and methods. Common

visibility notations include:

○​ + for public (visible to all classes)

○​ - for private (visible only within the class)

○​ # for protected (visible to subclasses)

○​ ~ for package or default visibility (visible to classes in the same

package)

***********************************************
1 Online Railway Ticket Reservation System
Online Railway ticket reservation is very useful nowadays. This is very

important to design a good-working system software for ticket booking

and related transactions. To design it, full-track documentation of

models(ER, DFD, Class, Use-case, Activity, Sequence) is required as per as

software development is concerned.

Features of the System:

The Reservation system should contain the following features:

1.​ If a passenger wants to reserve ticket(s), firstly, he/she has to log

in to the Railway system with valid credentials. Then, the

passenger has to provide his/her details with the date of the

journey, names of the passengers and their details, origin station

details, destination station details, and the class type of the

required ticket(s).

2.​ The Railway Reservation System will provide the available

Train-list, and Seat-availability, via-details.

3.​ To book a ticket passengers can pay through online/offline mode.

After successful payment of the ticket fare the System will

generate the ticket and PNR no. will be given to the passenger.
 The System also keeps the payment details and sends them to

the system Admin.

4.​ The Passenger can check PNR status (confirmed, RAC, waiting

list) by entering the PNR no. into the Reservation system.

5.​ The Reservation system should store all train details, fare details

(by zone, class, and date wise), PNR no, date of trains, etc. This

maintenance should be controlled by the Admin.

6.​ The System also has refund rules which have a date of

reservation, ticket fare, and refundable percentage. The

passenger can simply cancel the ticket(s) by entering the PNR no

and a cancel ticket request. After cancelation, the Admin will pass

the refundable amount to the System and the System will give

the refundable amount to the passenge

Class Diagram:

These diagrams describe the operation and attributes of a class with

imposed constraints in the system. In this article the classes to be considered
are ‘payment’, ‘train’, ‘passenger’, ‘ticket’, ‘railway reservation system’, ‘admin’.
The description of the classes is given below.

Class Attributes Processes

Payment amount ticketGeneration

train code, train name,

Train —
frequency

login, search Train, modify

the form,

passenger PAX_id, name,age,sex

pay charges, book tickets
now ticket, cancel tickets

PNR_no, status,
payment type, train code
search train,
ticket new Ticket, delete tickets

date of journey
 railway
reservation system response
system

formDetails,
Admin ID, name cancellationForm,
refundAmt
2 Class Diagram of Hospital Management System:
Class Diagram for Hospital Management System simply describes structure
of Hospital Management System class, attributes, methods or operations,
relationship among objects.

For a Hospital Management System (HMS), the class diagram and its
characteristics would typically include:
1.​ Classes: Representing entities such as Patient, Doctor, Nurse,

Administrator, Appointment, MedicalRecord, Department, and

Billing.

2.​ Attributes: Each class would have attributes representing its

properties. For example, the Patient class might have attributes like

patientID, name, gender, dateOfBirth, and contactDetails.

3.​ Operations (Methods): These would define the behaviors

associated with each class. For instance, the Appointment class

might have methods like scheduleAppointment(),

cancelAppointment(), and rescheduleAppointment().

4.​ Associations: Relationships between classes would be depicted to

show how they are connected. For instance, an association between

Patient and Doctor classes would show that a patient can be

associated with one or more doctors.

5.​ Multiplicity: Multiplicity would specify how many instances of one

class are associated with instances of another class. For example, a

Doctor can have multiple patients, indicating a one-to-many

relationship.

6.​ Inheritance (Generalization): If there are common attributes or

methods shared between classes, inheritance can be used to depict

this relationship. For example, Doctor and Nurse classes might

inherit from a common super class called Healthcare Professional.

 7.​ Composition and Aggregation: These relationships would show

how one class contains or is composed of another class. For

example, a Hospital class may have a composition relationship with

the Department class, indicating that a hospital consists of multiple

departments.

8.​ Dependency: This would show when one class relies on another

class, usually through method parameters or return types. For

example, the Billing class may have a dependency on the Patient

class to retrieve patient information for billing purposes.

3 Class diagram for an ATM system

An ATM Class Diagram depicts the common classes, relationships, associations, and
components of an ATM system, including the customer, card, terminal, and bank12. It
shows how these components interact to enable customers to withdraw and deposit
money. The diagram includes classes like CardReader, Keypad, Display, CashDispenser,
and Transaction, along with their attributes and methods

What classes do we need to create?

In the real world, each of these classes might have a lot more attributes and
methods, but we’ll keep things simple and only model what we need.

We can start with the Bank class. The bank needs a code to identify it and an
address. The methods that the bank class can use to interact with its ATM are
manage and maintain.

Next, we need to create an ATM at the bank. The ATM is managed by

the bank and it has a location. Its methods are related to transactions,
which it identifies and carries out.
Every bank needs customers, so we’ll create the Customer class.
Customers need a name and an address. The relationship between the
bank and the customer is that the bank has customers.
The only method for the customer is to own an account and to own a
debit card. Let’s create those two now. An account is owned by a
customer and also has a type, such as savings or checking. It has a
method to enable it to check the account balance.
The DebitCard class has a card number and is also owned by a
customer. Its method enables it to access the ATM and therefore the
account.
Now we need to model the transactions that can take place when the
customer uses the ATM.

The base class for this is ATMTransaction. It has three attributes:

transaction ID, date, and type. Its method is to update.

Let’s imagine that the customer can perform two different types of
transactions. They can withdraw funds or they can transfer funds to
another account.

For the first, we need a WithdrawalTransaction class. That has an

amount attribute and a withdrawal method. The second is covered by
a TransferTransaction class. This also has an amount attribute, but in
addition it has an account number attribute so that the customer can
send the money to a different account.

Putting it all together in an ATM class diagram

We have all the classes we need, so our finished class diagram now models the interaction
between the bank, a customer, the ATM, and the customer account.

●​ The bank class has customers and it maintains the ATM.

●​ The customer owns an account and also owns a debit card.
●​ The ATM identifies an active ATM transaction and the transaction can in turn
modify the customer account.
4 Online shopping system and its components
In general terms, an online shopping system is a platform on which you can buy
products online. Consequently, there are two parties — sellers and buyers — as
well as the object of sale, i.e., product (or items).

It is also worth bearing in mind that the product is bought and sold for money,
which leads to the payment process. In addition, since we are talking about online
commerce, the shipping process is set up separately.

The purchase and delivery of a product in an online shopping system are usually
arranged as one order attached to the buyer.

Online Shopping
UML Class Diagram Example

Here we provide an example of UML class diagram which shows a domain model
for online shopping. The purpose of the diagram is to introduce some common
terms, "dictionary" for online shopping - Customer, Web User, Account, Shopping
Cart, Product, Order, Payment, etc. and relationships between. It could be used as
a common ground between business analysts and software developers.
Each customer has unique id and is linked to exactly one account. Account owns
shopping cart and orders. Customer could register as a web user to be able to buy
items online. Customer is not required to be a web user because purchases could
also be made by phone or by ordering from catalogues. Web user has login name
which also serves as unique id. Web user could be in several states - new, active,
temporary blocked, or banned, and be linked to a shopping cart. Shopping cart
belongs to account.
Online shopping domain UML class diagram example.

Account owns customer orders. Customer may have no orders. Customer orders
are sorted and unique. Each order could refer to several payments, possibly none.
Every payment has unique id and is related to exactly one account.
Each order has current order status. Both order and shopping cart have line items
linked to a specific product. Each line item is related to exactly one product. A
product could be associated to many line items or no item at all.