UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them. A class consists of
its objects, and also it may inherit from other classes. A class diagram is used to
visualize, describe, document various different aspects of the system, and also
construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the
software system. It constitutes class names, attributes, and functions in a separate
compartment that helps in software development. Since it is a collection of classes,
interfaces, associations, collaborations, and constraints, it is termed as a structural
diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the
only diagram that is widely used for construction, and it can be mapped with object-
oriented languages. It is one of the most popular UML diagrams. Following are the
purpose of class diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application
is structured before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be
programmed.
5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:
 o Upper Section: The upper section encompasses the name of the class. A class
is a representation of similar objects that shares the same relationships,
attributes, operations, and semantics. Some of the following rules that should
be taken into account while representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe
the quality of the class. The attributes have the following characteristics:
. The attributes are written along with its visibility factors, which are public (+),
private (-), protected (#), and package (~).
a. The accessibility of an attribute class is illustrated by the visibility factors.
b. A meaningful name should be assigned to the attribute, which will
explain its usage inside the class.
o Lower Section: The lower section contain methods or operations. The methods
are represented in the form of a list, where each method is written in a single
line. It demonstrates how a class interacts with data.

Relationships
In UML, relationships are of three types:

o Dependency: A dependency is a semantic relationship between two or more

classes where a change in one class cause changes in another class. It forms a
 weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

o Generalization: A generalization is a relationship between a parent class

(superclass) and a child class (subclass). In this, the child class is inherited from
the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

o Association: It describes a static or physical connection between two or more

objects. It depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a
relationship. It is more specific then association. It defines a part-whole or part-of
relationship. In this kind of relationship, the child class can exist independently of its
parent class.

The company encompasses a number of employees, and even if one employee resigns,
the company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other
part also gets discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all
the contacts will be lost.
Abstract Classes
In the abstract class, no objects can be a direct entity of the abstract class. The abstract
class can neither be declared nor be instantiated. It is used to find the functionalities
across the classes. The notation of the abstract class is similar to that of class; the only
difference is that the name of the class is written in italics. Since it does not involve any
implementation for a given function, it is best to use the abstract class with multiple
objects.

Let us assume that we have an abstract class named displacement with a method
declared inside it, and that method will be called as a drive (). Now, this abstract class
method can be implemented by any object, for example, car, bike, scooter, cycle, etc.

How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only
represents a static view of the system but also all the major aspects of an application.
A collection of class diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are
given below:

1. To describe a complete aspect of the system, it is suggested to give a

meaningful name to the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number
of the unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the
aspects of a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct
before producing its final version.
Class Diagram Example
A class diagram describing the sales order system is given below.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential
role in the establishment of the component and deployment diagrams. It helps to
construct an executable code to perform forward and backward engineering for any
system, or we can say it is mainly used for construction. It represents the mapping with
object-oriented languages that are C++, Java, etc. Class diagrams can be used for the
following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class
diagram. It represents an instance of a class diagram. The objects help in portraying a
static view of an object-oriented system at a specific instant.

Both the object and class diagram are similar to some extent; the only difference is
that the class diagram provides an abstract view of a system. It helps in visualizing a
particular functionality of a system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class
diagram provides an abstract view which comprises of classes and their relationships,
whereas the object diagram represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The
main purpose is to depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.

o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.

Example of Object Diagram

 How to draw an Object Diagram?
1. All the objects present in the system should be examined before start drawing
the object diagram.
2. Before creating the object diagram, the relation between the objects must be
acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should
be assigned.
5. The objects are to be examined to understand its functionality.

Applications of Object diagrams

The following are the application areas where the object diagrams can be used.

1. To build a prototype of a system.

2. To model complex data structures.
3. To perceive the system from a practical perspective.
4. Reverse engineering.

Class vs. Object diagram

Serial Class Diagram Object Diagram

No.

1. It depicts the static view of a system. It portrays the real-time behavior of a

system.

2. Dynamic changes are not included in the class Dynamic changes are captured in the
diagram. object diagram.
3. The data values and attributes of an instance are It incorporates data values and
not involved here. attributes of an entity.

4. The object behavior is manipulated in the class Objects are the instances of a class.
diagram.

UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a
system. Both the sequence and the collaboration diagrams represent the same
information but differently. Instead of showing the flow of messages, it depicts the
architecture of the object residing in the system as it is based on object-oriented
programming. An object consists of several features. Multiple objects present in the
system are connected to each other. The collaboration diagram, which is also known
as a communication diagram, is used to portray the object's architecture in the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its

name and class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its
class is specified.
o To differentiate one object from another object, it is necessary to name
them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes
the interaction. Each actor has its respective role and name. In this, one actor
initiates the use case.
3. Links: The link is an instance of association, which associates the objects and
actors. It portrays a relationship between the objects through which the
messages are sent. It is represented by a solid line. The link helps an object to
 connect with or navigate to another object, such that the message flows are
attached to links.
4. Messages: It is a communication between objects which carries information
and includes a sequence number, so that the activity may take place. It is
represented by a labeled arrow, which is placed near a link. The messages are
sent from the sender to the receiver, and the direction must be navigable in that
particular direction. The receiver must understand the message.

When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict the relationship between the
object. Both the sequence and collaboration diagrams represent the same information,
but the way of portraying it quite different. The collaboration diagrams are best suited
for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration
diagram is implemented:

1. To model collaboration among the objects or roles that carry the functionalities
of use cases and operations.
2. To model the mechanism inside the architectural design of the system.
 3. To capture the interactions that represent the flow of messages between the
objects and the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a
collaboration of several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number,
such that the top-level message is marked as one and so on. The messages sent
during the same call are denoted with the same decimal prefix, but with
different suffixes of 1, 2, etc. as per their occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are
specified.
2. Discover the structural elements that are class roles, objects, and subsystems
for performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and
operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if
needed.
o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram
1. The collaboration diagram is also known as Communication Diagram.
2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e.,
how lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just
the difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each
individual message.
5. The collaboration diagram is semantically weak in comparison to the sequence
diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram
can be directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while
implementing a collaboration diagram with respect to the sequence diagram.
The drawback of a Collaboration Diagram
1. Multiple objects residing in the system can make a complex collaboration
diagram, as it becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on
every single that has occurred inside the object of a system.

Sequence Diagram
The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It
portrays the communication between any two lifelines as a time-ordered sequence of
events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a vertical
dotted line that extends across the bottom of the page. It incorporates the iterations
as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline
An individual participant in the sequence diagram is represented by a lifeline. It is
positioned at the top of the diagram.
Actor
A role played by an entity that interacts with the subject is called as an actor. It is out
of the scope of the system. It represents the role, which involves human users and
external hardware or subjects. An actor may or may not represent a physical entity, but
it purely depicts the role of an entity. Several distinct roles can be played by an actor
or vice versa.
Activation
It is represented by a thin rectangle on the lifeline. It describes that time period in
which an operation is performed by an element, such that the top and the bottom of
the rectangle is associated with the initiation and the completion time, each
respectively.

Keep Watching

Messages
The messages depict the interaction between the objects and are represented by
arrows. They are in the sequential order on the lifeline. The core of the sequence
diagram is formed by messages and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.
o Return Message: It defines a particular communication between the lifelines of
interaction that represent the flow of information from the receiver of the
corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of
the self message as it represents the recursive calls.
o Create Message: It describes a communication, particularly between the lifelines of an
interaction describing that the target (lifeline) has been instantiated.

o Destroy Message: It describes a communication, particularly between the lifelines of

an interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of

an interaction, which portrays the time passage of the message while modeling a
system.
Note
A note is the capability of attaching several remarks to the element. It basically carries
useful information for the modelers.

Sequence Fragments
1. Sequence fragments have been introduced by UML 2.0, which makes it quite easy for
the creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of interaction
inside a sequence diagram.
3. The type of fragment is shown by a fragment operator.

Types of fragments
Following are the types of fragments enlisted below;

Operator Fragment Type

alt Alternative multiple fragments: The only fragment for which the condition is true, will execute
 opt Optional: If the supplied condition is true, only then the fragments will execute. It is similar
with only one trace.

par Parallel: Parallel executes fragments.

loop Loop: Fragments are run multiple times, and the basis of interaction is shown by the guard.

region Critical region: Only one thread can execute a fragment at once.

neg Negative: A worthless communication is shown by the fragment.

ref Reference: An interaction portrayed in another diagram. In this, a frame is drawn so as to cove
lifelines involved in the communication. The parameter and return value can be explained.

sd Sequence Diagram: It is used to surround the whole sequence diagram.

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.

Any online customer can search for a book catalog, view a description of a particular
book, add a book to its shopping cart, and do checkout.
Benefits of a Sequence Diagram
1. It explores the real-time application.
2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
 3. Since each sequence needs distinct notations for its representation, it may make the
diagram more complex.
4. The type of sequence is decided by the type of message.

UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It
encapsulates the system's functionality by incorporating use cases, actors, and their
relationships. It models the tasks, services, and functions required by a
system/subsystem of an application. It depicts the high-level functionality of a system
and also tells how the user handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system.
It accumulates the system's requirement, which includes both internal as well as
external influences. It invokes persons, use cases, and several things that invoke the
actors and elements accountable for the implementation of use case diagrams. It
represents how an entity from the external environment can interact with a part of the
system.

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case
diagram, and then the system's functionalities are found. And once every single
functionality is identified, they are then transformed into the use cases to be used in
the use case diagram.

Difference between JDK, JRE, and JVM

After that, we will enlist the actors that will interact with the system. The actors are the
person or a thing that invokes the functionality of a system. It may be a system or a
private entity, such that it requires an entity to be pertinent to the functionalities of
the system to which it is going to interact.
Once both the actors and use cases are enlisted, the relation between the actor and
use case/ system is inspected. It identifies the no of times an actor communicates with
the system. Basically, an actor can interact multiple times with a use case or system at
a particular instance of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case
of a system.
2. The communication of an actor with a use case must be defined in an
understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no
of interactions between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase
online. The top-level uses are as follows; View Items, Make Purchase, Checkout, Client
Register. The View Items use case is utilized by the customer who searches and view
products. The Client Register use case allows the customer to register itself with the
website for availing gift vouchers, coupons, or getting a private sale invitation. It is to
be noted that the Checkout is an included use case, which is part of Making
Purchase, and it is not available by itself.
The View Items is further extended by several use cases such as; Search Items, Browse
Items, View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these
extended use cases provide some functions to customers, which allows them to search
for an item. The View Items is further extended by several use cases such as; Search
Items, Browse Items, View Recommended Items, Add to Shopping Cart, Add to Wish
list. All of these extended use cases provide some functions to customers, which allows
them to search for an item.

Both View Recommended Item and Add to Wish List include the Customer
Authentication use case, as they necessitate authenticated customers, and
simultaneously item can be added to the shopping cart without any user
authentication.
Similarly, the Checkout use case also includes the following use cases, as shown
below. It requires an authenticated Web Customer, which can be done by login page,
user authentication cookie ("Remember me"), or Single Sign-On (SSO). SSO needs an
external identity provider's participation, while Web site authentication service is
utilized in all these use cases.

The Checkout use case involves Payment use case that can be done either by the credit
card and external credit payment services or with PayPal.
Important tips for drawing a Use Case diagram
Following are some important tips that are to be kept in mind while drawing a use
case diagram:

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among
the multiple interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn
more generalized.