Types of UML: The UML diagrams are divided into two parts: Structural UML

diagrams and Behavioral UML diagrams which are listed below:

1. Structural UML diagrams

 Class diagram
 Package diagram
 Object diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
2. Behavioral UML diagrams
 Activity diagram
 Sequence diagram
 Use case diagram
 State diagram
 Communication diagram
 Interaction overview diagram
 Timing diagram

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:

a. The attributes are written along with its visibility factors, which are public (+),
private (-), protected (#), and package (~).
b. The accessibility of an attribute class is illustrated by the visibility factors.
 c. 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.

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 Activity Diagram

In UML, the activity diagram is used to demonstrate the flow of control within the
system rather than the implementation. It models the concurrent and sequential
activities.

The activity diagram helps in envisioning the workflow from one activity to another. It
put emphasis on the condition of flow and the order in which it occurs. The flow can be
sequential, branched, or concurrent, and to deal with such kinds of flows, the activity
diagram has come up with a fork, join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of

a set of actions or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

The categorization of behavior into one or more actions is termed as an activity. In other
words, it can be said that an activity is a network of nodes that are connected by edges.
The edges depict the flow of execution. It may contain action nodes, control nodes, or
object nodes.

The control flow of activity is represented by control nodes and object nodes that
illustrates the objects used within an activity. The activities are initiated at the initial
node and are terminated at the final node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can
be either vertical or horizontal. It used to add modularity to the activity diagram. It is not
necessary to incorporate swimlane in the activity diagram. But it is used to add more
transparency to the activity diagram.

Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of
one inward edge and several outward edges. It is the same as that of various decision
parameters. Whenever a data is received at an inward edge, it gets copied and split crossways
various outward edges. It split a single inward flow into multiple parallel flows.
Join Nodes

Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all
of the inward edges as it synchronizes the flow of input across one single output
(outward) edge.

Notation of an Activity diagram

Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.

Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one
path.

Action Box: It represents the set of actions that are to be performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of nodes associated
with edges. To model the behavior of activities, they can be attached to any modeling
element. It can model use cases, classes, interfaces, components, and collaborations.

It mainly models processes and workflows. It envisions the dynamic behavior of the
system as well as constructs a runnable system that incorporates forward and reverse
engineering. It does not include the message part, which means message flow is not
represented in an activity diagram.
It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict the flow
between several activities.

How to draw an Activity Diagram?

An activity diagram is a flowchart of activities, as it represents the workflow among
various activities. They are identical to the flowcharts, but they themself are not exactly
the flowchart. In other words, it can be said that an activity diagram is an enhancement
of the flowchart, which encompasses several unique skills.

Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and
forks, it supports exception handling. A system must be explored as a whole before
drawing an activity diagram to provide a clearer view of the user. All of the activities are
explored after they are properly analyzed for finding out the constraints applied to the
activities. Each and every activity, condition, and association must be recognized.

After gathering all the essential information, an abstract or a prototype is built, which is
then transformed into the actual diagram.

Following are the rules that are to be followed for drawing an activity diagram:

1. A meaningful name should be given to each and every activity.

2. Identify all of the constraints.
3. Acknowledge the activity associations.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order
processing is given below.

Here the input parameter is the Requested order, and once the order is accepted, all of
the required information is then filled, payment is also accepted, and then the order is
shipped. It permits order shipment before an invoice is sent or payment is completed.
When to use an Activity Diagram?
An activity diagram can be used to portray business processes and workflows. Also, it
used for modeling business as well as the software. An activity diagram is utilized for the
followings:

1. To graphically model the workflow in an easier and understandable way.

2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed
within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an
application.
7. To represent a high-level view of a distributed or an object-oriented 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.
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:

Represented by a solid line with a lined

Asynchronous arrowhead. Asynchronous messages don't
 message symbol require a response before the sender continues.
Only the call should be included in the diagram.

Asynchronous
Represented by a dashed line with a lined
 return message
symbol arrowhead.

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.

Example of a Sequence Diagram

Sequence diagram of a hospital management system

Technology has completely transformed the field of medicine, as it has

with most industries. A hospital information system, also known as a
hospital information system, helps doctors, administrators, and
hospital staff managing all of the activities and information collected
at a hospital, including checkups, prescriptions, appointments, and
information on the patients and their caretakers. The diagram below
provides a simple view of how the primary processes operate with
each other over time.
Sequence diagram for ATM systems

An ATM allows patrons to access their bank accounts through a

completely automated process. You can examine the steps of this
process in a manageable way by drawing or viewing a sequence
diagram. The example below outlines the sequential order of the
interactions in the ATM system.

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.