What is UML

The UML stands for Unified modeling language, is a standardized general-purpose visual
modeling language in the field of Software Engineering. It is used for specifying, visualizing,
constructing, and documenting the primary artifacts of the software system. It helps in designing
and characterizing, especially those software systems that incorporate the concept of Object
orientation. It describes the working of both the software and hardware systems.
The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James Rumbaugh at the
Rational Software. In 1997, it got adopted as a standard by the Object Management Group
(OMG). ckward Skip 10sPlay VideoForward Skip 10s

The Object Management Group (OMG) is an association of several companies that controls the
open standard UML. The OMG was established to build an open standard that mainly supports
the interoperability of object-oriented systems. It is not restricted within the boundaries, but it
can also be utilized for modeling the non-software systems. The OMG is best recognized for the
Common Object Request Broker Architecture (CORBA) standards.

Goals of UML

o Since it is a general-purpose modeling language, it can be utilized by all the modelers.

o UML came into existence after the introduction of object-oriented concepts to systemize
and consolidate the object-oriented development, due to the absence of standard
methods at that time.
o The UML diagrams are made for business users, developers, ordinary people, or anyone
who is looking forward to understand the system, such that the system can be software
or non-software.
o Thus it can be concluded that the UML is a simple modeling approach that is used to
model all the practical systems.
Characteristics of UML
The UML has the following features:
o It is a generalized modeling language.
o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.
Conceptual Modeling

Before moving ahead with the concept of UML, we should first understand the basics of the
conceptual model.

A conceptual model is composed of several interrelated concepts. It makes it easy to understand

the objects and how they interact with each other. This is the first step before drawing UML
diagrams.

Following are some object-oriented concepts that are needed to begin with UML:

o Object: An object is a real world entity. There are many objects present within a single
system. It is a fundamental building block of UML.
o Class: A class is a software blueprint for objects, which means that it defines the variables
and methods common to all the objects of a particular type.
o Abstraction: Abstraction is the process of portraying the essential characteristics of an
object to the users while hiding the irrelevant information. Basically, it is used to envision
the functioning of an object.
o Inheritance: Inheritance is the process of deriving a new class from the existing ones.
o Polymorphism: It is a mechanism of representing objects having multiple forms used for
different purposes.
o Encapsulation: It binds the data and the object together as a single unit, enabling tight
coupling between them.

OO Analysis and Design

OO is an analysis of objects, and design means combining those identified objects. So, the main
purpose of OO analysis is identifying the objects for designing a system. The analysis can also be
done for an existing system. The analysis can be more efficient if we can identify the objects.
Once we have identified the objects, their relationships are then identified, and the design is also
produced.

The purpose of OO is given below:

o To identify the objects of a system.
o To identify their relationships.
o To make a design that is executable when the concepts of OO are employed.

Following are the steps where OO concepts are applied and implemented:
Step 1: OO Analysis

The main purpose of OO analysis is identifying the objects and describing them correctly. After
the objects are identified, the designing step is easily carried out. It is a must to identify the
objects with responsibilities. Here the responsibility refers to the functions performed by the
objects. Each individual object has its own functions to perform. The purpose of the system is
fulfilled by collaborating these responsibilities.

Step 2: OO Design

This phase mainly emphasizes on meeting the requirements. In this phase, the objects are joined
together as per the intended associations. After the association is completed, the designing
phase also gets complete.

Step 3: OO Implementation

This is the last phase that comes after the designing is done. It implements the design using any
OO languages like C++, Java, etc.

Role of UML in OO design

As the UML is a modeling language used to model software as well as non-software systems, but
here it focuses on modeling OO software applications. It is essential to understand the relation
between the OO design and UML. The OO design can be converted into the UML as and when
required. The OO languages influence the programming world as they model real world objects.

The UML itself is an amalgamation of object-oriented notations like Object-Oriented Design

(OOD), Object Modeling Technique (OMT), and Object-Oriented Software Engineering (OOSE).
The strength of these three approaches is utilized by the UML to represent more consistency.

UML-Building Blocks

UML is composed of three main building blocks, i.e., things, relationships, and diagrams. Building
blocks generate one complete UML model diagram by rotating around several different blocks.
It plays an essential role in developing UML diagrams. The basic UML building blocks are enlisted
below:
1. Things
2. Relationships
3. Diagrams
Things

Anything that is a real world entity or object is termed as things. It can be divided into several
different categories:

o Structural things
o Behavioral things
o Grouping things
o Annotational things
Structural things
Nouns that depicts the static behavior of a model is termed as structural things. They display the
physical and conceptual components. They include class, object, interface, node, collaboration,
component, and a use case.
Class: A Class is a set of identical things that outlines the functionality and properties of an object.
It also represents the abstract class whose functionalities are not defined. Its notation is as
follows;

Object:: An individual that describes the behavior and the functions of a system. The notation of
the object is similar to that of the class; the only difference is that the object name is always
underlined and its notation is given below;
Interface: A set of operations that describes the functionality of a class, which is implemented
whenever an interface is implemented.

Collaboration: It represents the interaction between things that is done to meet the goal. It is
symbolized as a dotted ellipse with its name written inside it.

Use case: Use case is the core concept of object-oriented modeling. It portrays a set of actions
executed by a system to achieve the goal.

Actor: It comes under the use case diagrams. It is an object that interacts with the system, for
example, a user.
Component: It represents the physical part of the system.

Node: A physical element that exists at run time.

Behavioral Things
They are the verbs that encompass the dynamic parts of a model. It depicts the behavior of a
system. They involve state machine, activity diagram, interaction diagram, grouping things,
annotation things
State Machine: It defines a sequence of states that an entity goes through in the software
development lifecycle. It keeps a record of several distinct states of a system component.
Activity Diagram: It portrays all the activities accomplished by different entities of a system. It is
represented the same as that of a state machine diagram. It consists of an initial state, final state,
a decision box, and an action notation.

Interaction Diagram: It is used to envision the flow of messages between several components in
a system.
Grouping Things

It is a method that together binds the elements of the UML model. In UML, the package is the
only thing, which is used for grouping.

Package: Package is the only thing that is available for grouping behavioral and structural things.

Annotation Things

It is a mechanism that captures the remarks, descriptions, and comments of UML model
elements. In UML, a note is the only Annotational thing.

Note: It is used to attach the constraints, comments, and rules to the elements of the model. It
is a kind of yellow sticky note.

Relationships
It illustrates the meaningful connections between things. It shows the association between the
entities and defines the functionality of an application. There are four types of relationships given
below:

Dependency: Dependency is a kind of relationship in which a change in target element affects

the source element, or simply we can say the source element is dependent on the target element.
It is one of the most important notations in UML. It depicts the dependency from one entity to
another.
It is denoted by a dotted line followed by an arrow at one side as shown below,

Association: A set of links that associates the entities to the UML model. It tells how many
elements are actually taking part in forming that relationship.

It is denoted by a dotted line with arrowheads on both sides to describe the relationship with the
element on both sides.

Generalization: It portrays the relationship between a general thing (a parent class or superclass)
and a specific kind of that thing (a child class or subclass). It is used to describe the concept of
inheritance.

It is denoted by a straight line followed by an empty arrowhead at one side.

Realization: It is a semantic kind of relationship between two things, where one defines the
behavior to be carried out, and the other one implements the mentioned behavior. It exists in
interfaces.

It is denoted by a dotted line with an empty arrowhead at one side.

Diagrams

The diagrams are the graphical implementation of the models that incorporate symbols and text.
Each symbol has a different meaning in the context of the UML diagram. There are thirteen
different types of UML diagrams that are available in UML 2.0, such that each diagram has its
own set of a symbol. And each diagram manifests a different dimension, perspective, and view
of the system.

UML diagrams are classified into three categories that are given below:
 1. Structural Diagram
2. Behavioral Diagram
3. Interaction Diagram

Structural Diagram: It represents the static view of a system by portraying the structure of a
system. It shows several objects residing in the system. Following are the structural diagrams
given below:

o Class diagram
o Object diagram
o Package diagram
o Component diagram
o Deployment diagram

Behavioral Diagram: It depicts the behavioral features of a system. It deals with dynamic parts
of the system. It encompasses the following diagrams:

o Activity diagram
o State machine diagram
o Use case diagram

Interaction diagram: It is a subset of behavioral diagrams. It depicts the interaction between two
objects and the data flow between them. Following are the several interaction diagrams in UML:

o Timing diagram
o Sequence diagram
o Collaboration diagram

UML- Architecture

Software architecture is all about how a software system is built at its highest level. It is needed
to think big from multiple perspectives with quality and design in mind. The software team is tied
to many practical concerns, such as:

o The structure of the development team.

o The needs of the business.
o Development cycle.
 o The intent of the structure itself.

Software architecture provides a basic design of a complete software system. It defines the
elements included in the system, the functions each element has, and how each element relates
to one another. In short, it is a big picture or overall structure of the whole system, how
everything works together.

To form an architecture, the software architect will take several factors into consideration:

o What will the system be used for?

o Who will be using the system?
o What quality matters to them?
o Where will the system run?

The architect plans the structure of the system to meet the needs like these. It is essential to
have proper software architecture, mainly for a large software system. Having a clear design of a
complete system as a starting point provides a solid basis for developers to follow.

Each developer will know what needs to be implemented and how things relate to meet the
desired needs efficiently. One of the main advantages of software architecture is that it provides
high productivity to the software team. The software development becomes more effective as it
comes up with an explained structure in place to coordinate work, implement individual features,
or ground discussions on potential issues. With a lucid architecture, it is easier to know where
the key responsibilities are residing in the system and where to make changes to add new
requirements or simply fixing the failures.

In addition, a clear architecture will help to achieve quality in the software with a well-designed
structure using principles like separation of concerns; the system becomes easier to maintain,
reuse, and adapt. The software architecture is useful to people such as software developers, the
project manager, the client, and the end-user. Each one will have different perspectives to view
the system and will bring different agendas to a project. Also, it provides a collection of several
views. It can be best understood as a collection of five views:

1. Use case view

2. Design view
3. Implementation view
4. Process view
5. Development view
Use case view
o It is a view that shows the functionality of the system as perceived by external actors.
o It reveals the requirements of the system.
o With UML, it is easy to capture the static aspects of this view in the use case diagrams,
whereas it?s dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Design View
o It is a view that shows how the functionality is designed inside the system in terms of static
structure and dynamic behavior.
o It captures the vocabulary of the problem space and solution space.
o With UML, it represents the static aspects of this view in class and object diagrams,
whereas its dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.
Implementation View
o It is the view that represents the organization of the core components and files.
o It primarily addresses the configuration management of the system?s releases.
o With UML, its static aspects are expressed in component diagrams, and the dynamic
aspects are captured in interaction diagrams, state chart diagrams, and activity diagrams.

Process View
o It is the view that demonstrates the concurrency of the system.
o It incorporates the threads and processes that make concurrent system and synchronized
mechanisms.
o It primarily addresses the system's scalability, throughput, and performance.
o Its static and dynamic aspects are expressed the same way as the design view but focus
more on the active classes that represent these threads and processes.

Deployment View
o It is the view that shows the deployment of the system in terms of physical architecture.
o It includes the nodes, which form the system hardware topology where the system will be
executed.
o It primarily addresses the distribution, delivery, and installation of the parts that build the
physical system.

UML-Diagrams

The UML diagrams are categorized into structural diagrams, behavioral diagrams, and also
interaction overview diagrams. The diagrams are hierarchically classified in the following figure:
1. Structural Diagrams

Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure
diagrams, component diagrams, deployment diagrams, object diagrams, and package diagrams.
It presents an outline for the system. It stresses the elements to be present that are to be
modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the
backbone of all the object-oriented software systems. It depicts the static structure of the
system. It displays the system's class, attributes, and methods. It is helpful in recognizing
the relation between different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts within the
class. It displays the relationship between the parts and their configuration that ascertain
 the behavior of the class. It makes full use of ports, parts, and connectors to portray the
internal structure of a structured classifier. It is similar to class diagrams, just the fact it
represents individual parts in a detailed manner when compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point in time.
It can be used to test the accuracy of class diagrams. It represents distinct instances of
classes and the relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components within the
system. It is used for modeling execution details. It determines whether the desired
functional requirements have been considered by the planned development or not, as it
depicts the structural relationships between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware by telling what
the existing physical components are and what software components are running on
them. It produces information about system software. It is incorporated whenever
software is used, distributed, or deployed across multiple machines with dissimilar
configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are
organized. It shows the dependencies between distinct packages. It manages UML
diagrams by making it easily understandable. It is used for organizing the class and use
case diagrams.

2. Behavioral Diagrams:

Behavioral diagrams portray a dynamic view of a system or the behavior of a system, which
describes the functioning of the system. It includes use case diagrams, state diagrams, and
activity diagrams. It defines the interaction within the system.

o State Machine Diagram: It is a behavioral diagram. it portrays the system's behavior

utilizing finite state transitions. It is also known as the State-charts diagram. It models the
dynamic behavior of a class in response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the other. With the
help of an activity diagram, we can model sequential and concurrent activities. It visually
depicts the workflow as well as what causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by utilizing actors and use
cases. It encapsulates the functional requirement of a system and its association with
actors. It portrays the use case view of a system.

3. Interaction Diagrams
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object
interactions and also depicts the flow between various use case elements of a system. In simple
words, it shows how objects interact with each other and how the data flows within them. It
consists of communication, interaction overview, sequence, and timing diagrams.

o Sequence Diagram: It shows the interactions between the objects in terms of messages
exchanged over time. It delineates in what order and how the object functions are in a
system.
o Communication Diagram: It shows the interchange of sequence messages between the
objects. It focuses on objects and their relations. It describes the static and dynamic
behavior of a system.
o Timing Diagram: It is a special kind of sequence diagram used to depict the object's
behavior over a specific period of time. It governs the change in state and object behavior
by showing the time and duration constraints.
o Interaction Overview diagram: It is a mixture of activity and sequence diagram that
depicts a sequence of actions to simplify the complex interactions into simple interactions.

UML-Relationship

Relationships depict a connection between several things, such as structural, behavioral, or

grouping things in the unified modeling language. Since it is termed as a link, it demonstrates
how things are interrelated to each other at the time of system execution. It constitutes four
types of relationships, i.e., dependency, association, generalization, and realization.

Dependency

Whenever there is a change in either the structure or the behavior of the class that affects the
other class, such a relationship is termed as a dependency. Or, simply, we can say a class
contained in other class is known as dependency. It is a unidirectional relationship.

Association

Association is a structural relationship that represents how two entities are linked or connected
to each other within a system. It can form several types of associations, such as one-to-one, one-
to-many, many-to-one, and many-to-many. A ternary association is one that constitutes three
links. It portrays the static relationship between the entities of two classes.

An association can be categorized into four types of associations, i.e., bi-directional,

unidirectional, aggregation (composition aggregation), and reflexive, such that an aggregation is
a special form of association and composition is a special form of aggregation. The mostly used
associations are unidirectional and bi-directional.

Aggregation

An aggregation is a special form of association. It portrays a part-of relationship. It forms a binary

relationship, which means it cannot include more than two classes. It is also known as Has-a
relationship. It specifies the direction of an object contained in another object. In aggregation, a
child can exist independent of the parent.

Composition

In a composition relationship, the child depends on the parent. It forms a two-way relationship.
It is a special case of aggregation. It is known as Part-of relationship.

Aggregation VS Composition relationship

Features Aggregation relationship Composition relationship

Dependency In an aggregation relationship, a child can exist In a composition relationship, the chi
independent of a parent. cannot exist independent of the paren

Type of It constitutes a Has-a relationship. It constitutes Part-of relationship.

Relationship

Type of It forms a weak association. It forms a strong association.

Association

Examples A doctor has patients when the doctor gets transfer A hospital and its wards. If the hospit
to another hospital, the patients do not accompany is destroyed, the wards also ge
to a new workplace. destroyed.

Generalization

The generalization relationship implements the object-oriented concept called inheritance or is-
a relationship. It exists between two objects (things or entities), such that one entity is a parent
(superclass or base class), and the other one is a child (subclass or derived class). These are
represented in terms of inheritance. Any child can access, update, or inherit the functionality,
structure, and behavior of the parent.

Realization

It is a kind of relationship in which one thing specifies the behavior or a responsibility to be carried
out, and the other thing carries out that behavior. It can be represented on a class diagram or
component diagrams. The realization relationship is constituted between interfaces, classes,
packages, and components to link a client element to the supplier element.

UML Association vs. Aggregation vs. Composition

In UML diagrams, relationships are used to link several things. It is a connection between
structural, behavioral, or grouping things. Following are the standard UML relationships enlisted
below:

o Association
o Dependency
o Generalization
o Realization

Association

Association relationship is a structural relationship in which different objects are linked within
the system. It exhibits a binary relationship between the objects representing an activity. It
depicts the relationship between objects, such as a teacher, can be associated with multiple
teachers.

It is represented by a line between the classes followed by an arrow that navigates the direction,
and when the arrow is on both sides, it is then called a bidirectional association. We can specify
the multiplicity of an association by adding the adornments on the line that will denote the
association.

Example: Skip 10sPlay VideoForward Skip 10s

1) A single teacher has multiple students.

2) A single student can associate with many teachers.

The composition and aggregation are two subsets of association. In both of the cases, the object
of one class is owned by the object of another class; the only difference is that in composition,
the child does not exist independently of its parent, whereas in aggregation, the child is not
dependent on its parent i.e., standalone. An aggregation is a special form of association, and
composition is the special form of aggregation.

Aggregation

Aggregation is a subset of association, is a collection of different things. It represents has a

relationship. It is more specific than an association. It describes a part-whole or part-of
relationship. It is a binary association, i.e., it only involves two classes. It is a kind of relationship
in which the child is independent of its parent.
For example:

Here we are considering a car and a wheel example. A car cannot move without a wheel. But the
wheel can be independently used with the bike, scooter, cycle, or any other vehicle. The wheel
object can exist without the car object, which proves to be an aggregation relationship.

Composition

The composition is a part of aggregation, and it portrays the whole-part relationship. It depicts
dependency between a composite (parent) and its parts (children), which means that if the
composite is discarded, so will its parts get deleted. It exists between similar objects.

As you can see from the example given below, the composition association relationship connects
the Person class with Brain class, Heart class, and Legs class. If the person is destroyed, the brain,
heart, and legs will also get discarded.
Association vs. Aggregation vs. Composition

Association Aggregation Composition

Association relationship is Aggregation relationship is The composition relationship is

represented using an represented by a straight line with represented by a straight line with
arrow. an empty diamond at one end. a black diamond at one end.

In UML, it can exist It is a part of the association It is a part of the aggregation

between two or more relationship. relationship.
classes.

It incorporates one-to-one, It exhibits a kind of weak It exhibits a strong type of

one-to-many, many-to-one, relationship. relationship.
and many-to-many
association between the
classes.

It can associate one more In an aggregation relationship, the In a composition relationship, the
objects together. associated objects exist associated objects cannot exist
independently within the scope of independently within the scope of
the system. the system.

In this, objects are linked In this, the linked objects are Here the linked objects are
together. independent of each other. dependent on each other.

It may or may not affect the Deleting one element in the It affects the other element if one
other associated element if aggregation relationship does not of its associated element is deleted.
one element is deleted. affect other associated elements.

Example: A tutor can Example: A car needs a wheel for Example: If a file is placed in a folder
associate with multiple its proper functioning, but it may and that is folder is deleted. The file
students, or one student not require the same wheel. It residing inside that folder will also
can associate with multiple may function with another wheel get deleted at the time of folder
teachers. as well. deletion.
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: Skip 10s

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.
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 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.

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.
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:

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 to alt 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 cover the 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 State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which shows
the order of states underwent by an object within the system. It captures the software system's
behavior. It models the behavior of a class, a subsystem, a package, and a complete system.

It tends out to be an efficient way of modeling the interactions and collaborations in the external
entities and the system. It models event-based systems to handle the state of an object. It also
defines several distinct states of a component within the system. Each object/component has a
specific state.

Following are the types of a state machine diagram that are given below:

1. Behavioral state machine

The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementation of a particular entity. It models the behavior of the
system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change
in the state of the protocol and parallel changes within the system. But it does not
portray the implementation of a particular component.

Why State Machine Diagram?

Since it records the dynamic view of a system, it portrays the behavior of a software application.
During a lifespan, an object underwent several states, such that the lifespan exist until the
program is executing. Each state depicts some useful information about the object.

It blueprints an interactive system that response back to either the internal events or the external
ones. The execution flow from one state to another is represented by a state machine diagram.
It visualizes an object state from its creation to its termination.

The main purpose is to depict each state of an individual object. It represents an interactive
system and the entities inside the system. It records the dynamic behavior of the system.
Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

a. Initial state: It defines the initial state (beginning) of a system, and it is represented by a
black filled circle.
b. Final state: It represents the final state (end) of a system. It is denoted by a filled circle
present within a circle.
c. Decision box: It is of diamond shape that represents the decisions to be made on the basis
of an evaluated guard.
d. Transition: A change of control from one state to another due to the occurrence of some
event is termed as a transition. It is represented by an arrow labeled with an event due to
which the change has ensued.
e. State box: It depicts the conditions or circumstances of a particular object of a class at a
specific point of time. A rectangle with round corners is used to represent the state box.

Types of State

The UML consist of three states:

1. Simple state: It does not constitute any substructure.

 2. Composite state: It consists of nested states (substates), such that it does not contain
more than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state,
but it can be reused.

How to Draw a State Machine Diagram?

The state machine diagram is used to portray various states underwent by an object. The change
in one state to another is due to the occurrence of some event. All of the possible states of a
particular component must be identified before drawing a state machine diagram.

The primary focus of the state machine diagram is to depict the states of a system. These states
are essential while drawing a state transition diagram. The objects, states, and events due to
which the state transition occurs must be acknowledged before the implementation of a state
machine diagram.

Following are the steps that are to be incorporated while drawing a state machine diagram:

1. A unique and understandable name should be assigned to the state transition that
describes the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.

When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as the object-oriented
systems. It records the dynamic behavior of the system, which is used to differentiate between
the dynamic and static behavior of a system.

It portrays the changes underwent by an object from the start to the end. It basically envisions
how triggering an event can cause a change within the system.

State machine diagram is used for:

1. For modeling the object states of a system.

2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.
Example of a State Machine Diagram

An example of a top-level state machine diagram showing Bank Automated Teller Machine (ATM)
is given below.

Initially, the ATM is turned off. After the power supply is turned on, the ATM starts performing
the startup action and enters into the Self Test state. If the test fails, the ATM will enter into
the Out Of Service state, or it will undergo a triggerless transition to the Idle state. This is the
state where the customer waits for the interaction.

Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM state
changes from Idle to Serving Customer, the entry action readCard is performed after entering
into Serving Customer state. Since the customer can cancel the transaction at any instant, so the
transition from Serving Customer state back to the Idle state could be triggered by cancel event.
Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.

Customer Authentication and Transaction are the composite states itself is displayed by a
hidden decomposition indication icon. After the transaction is finished, the Serving
Customer encompasses a triggerless transition back to the Idle state. On leaving the state, it
undergoes the exit action ejectCard that discharges the customer card.

State Machine vs. Flowchart

State Machine Flowchart

It portrays several states of a system. It demonstrates the execution flow of a

program.

It encompasses the concept of WAIT, i.e., wait for an event It does not constitute the concept of
or an action. WAIT.

It is for real-world modeling systems. It envisions the branching sequence of a

system.

It is a modeling diagram. It is a data flow diagram (DFD)

It is concerned with several states of a system. It focuses on control flow and path.

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.
Pins

It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that precisely
represents one input to or output from the action.

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.