Chapter Two

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

Chapter 2 UML Compiled By: Tadesse B.

 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.
Audience
This UML tutorial is made for both beginners and professionals, to help them understand the
fundamental concept of UML. After completion of this tutorial, you will find yourself at a
moderate level of expertise from where you take yourself to the next level.
Prerequisites
No particular skills are required as a prerequisite before starting with this tutorial. The learner must
be enthusiastic about gaining knowledge of UML.
Problems

Chapter 2 UML Compiled By: Tadesse B.

We assure you that you will not find any difficulty in this tutorial. But if there is any query, or you
find any mistake, do let us know by posting it in the contact form so that we can further improve
it.
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;

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

 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 child
independent of a parent. cannot exist independent of the parent.

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 to A hospital and its wards. If the hospital is
another hospital, the patients do not accompany to a destroyed, the wards also get destroyed.
new workplace.
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

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

 Association vs. Aggregation vs. Composition
Association Aggregation Composition

Association relationship is Aggregation relationship is The composition relationship is

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

In UML, it can exist between It is a part of the association It is a part of the aggregation relationship.
two or more classes. relationship.

It incorporates one-to-one, one- It exhibits a kind of weak relationship. It exhibits a strong type of relationship.
to-many, many-to-one, 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 independently associated objects cannot exist
within the scope of the system. independently within the scope of the
system.

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

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

Chapter 2 UML Compiled By: Tadesse B.

Example: A tutor can associate Example: A car needs a wheel for its Example: If a file is placed in a folder and
with multiple students, or one proper functioning, but it may not that is folder is deleted. The file residing
student can associate with require the same wheel. It may inside that folder will also get deleted at
multiple teachers. function with another wheel as well. the time of folder deletion.
association is the semantic relationship between classes that shows how one instance is connected
or merged with others in a system. The objects are combined either logically or physically. Since
it connects the object of one class to the object of another class, it is categorized as a structural
relationship. Following are the constraints applied to the association relationship are enlisted
below:
a. {implicit}: As the name suggests, the implicit constraints define that the relationship is not
visible, but it is based on a concept.
b. {ordered}: It describes that the set of entities is in a particular way at one end in an
association.
c. {changeable}: The changeable constraint ensures that the connections between several
objects within a system are added, improved, and detached, as and when required.
d. {addOnly}: It specifies that any new connection can be added from an object located at
the other end in an association.
e. {frozen}: The frozen constraint specifies that whenever a link is added between objects, it
cannot be altered by the time it is activated over the connection or given link.
Reflexive Association
In the reflexive associations, the links are between the objects of the same classes. In other words,
it can be said that the reflexive association consists of the same class at both ends. An object can
also be termed as an instance.
Let's have a look at its example of a class vegetable. The vegetable class has two objects, i.e., onion
and eggplant. According to the reflexive association's definition, the link between the onion and
eggplant exist, as they belong to the same class, i.e., vegetable.

Chapter 2 UML Compiled By: Tadesse B.

Directed Association
The directed association is concerned with the direction of flow inside association classes. The
flow of association can be shown by employing a directed association. The directed association
between two classes is represented by a line with an arrowhead, which indicates the navigation
direction. The flow of association from one class to another is always in one direction.
It can be said that there is an association between a person and the company. The person works for
the company. Here the person works for the company, and not the company works for a person.

UML-Dependency
Dependency depicts how various things within a system are dependent on each other. In UML, a
dependency relationship is the kind of relationship in which a client (one element) is dependent on
the supplier (another element). It is used in class diagrams, component diagrams, deployment
diagrams, and use-case diagrams, which indicates that a change to the supplier necessitates a
change to the client. An example is given below:

Chapter 2 UML Compiled By: Tadesse B.

Types of Dependency Relationship
Following are the type of dependency relationships, keywords, or stereotypes given below:
o <<derive>> -It is a constraint that specifies the template can be initialized by the source at
the target location utilizing given parameters.
o <<derive>> -It represents that the source object's location can be evaluated from the target
object.
o <<friend>> -It states the uniqueness of the source in the target object.
o <<instanceOf>> -It states that an instance of a target classifier is the source object.
o <<instantiate>> -It defines the capability of the source object, creating instances of a
target object.
o <<refine>> -It states that the source object comprises of exceptional abstraction than that
of the target object.
o <<use>> -When the packages are created in UML, the use of stereotype is used as it
describes that the elements of the source package can also exist in the target package. It
specifies that the source package uses some of the elements of the target package.
o <<substitute>> -The substitute stereotype state that the client can be substituted at the
runtime for the supplier.
o <<access>> -It is also called as private merging in which the source package accesses the
element of the target package.
o <<import>> -It specifies that target imports the source package's element as they are
defined within the target. It is also known as public merging.
o <<permit>> -It describes that the source element can access the supplier element or
whatever visibility is provided by the supplier.
o <<extend>> -It states that the behavior of the source element can be extended by the target.
o <<include>> -It describes the source element, which can include the behavior of another
element at a specific location, just like a function call in C/C++.
o <<become>> -It states that target is similar to the source with distinct roles and values.
o <<call>> -It specifies that the target object can be invoked by the source.

Chapter 2 UML Compiled By: Tadesse B.

 o <<copy>> -It states that the target is an independent replica of a source object.
o <<parameter>> -It describes that the supplier is a parameter of the client's actions.
o <<send>> -The client act as an operation, which sends some unspecified targets to the
supplier.
UML-Generalization
In UML modeling, a generalization relationship is a relationship that implements the concept of
object orientation called inheritance. The generalization relationship occurs between two entities
or objects, such that one entity is the parent, and the other one is the child. The child inherits the
functionality of its parent and can access as well as update it.
Generalization relationship is utilized in class, component, deployment, and use case diagrams to
specify that the child inherits actions, characteristics, and relationships from its parent.
To meet UML's standard, it necessitates usage of the same types of model elements in the
generalization relationship, i.e., generalization relation can either be used between actors or
between use cases, but not between an actor and a use case.
The generalization relationship is incorporated to record attributes, operations, and relationships
in a parent model element so that it can be inherited in one or more child model elements.
The parent model element can have as many children, and also, the child can have one or more
parents. But most commonly, it can be seen that there is one parent model element and multiple
child model elements. The generalization relationship does not consist of names. The
generalization relationship is represented by a solid line with a hollow arrowhead pointing towards
the parent model element from the child model element.

Stereotypes and their constraints

Chapter 2 UML Compiled By: Tadesse B.

<<implementation>> - It is used to show that the child is implemented by its parent, such that the
child object inherits the structure and behavior of its parent object without disobeying the rules.
The implementation of stereotype is mostly used in single inheritance.
In the generalization stereotype, there are two types of constraints that
are complete and incomplete to check if all the child objects are involved or not in the
relationship.
Example:
As we know, the bank account can be of two types; Savings Account and Credit Card Account.
Both the savings and the credit card account inherits the generalized properties from the Bank
Account, which is Account Number, Account Balance, etc.

UML-Realization
In UML modeling, the realization is a relationship between two objects, where the client (one
model element) implements the responsibility specified by the supplier (another model element).
The realization relationship can be employed in class diagrams and components diagrams.
The realization relationship does not have names. It is mostly found in the interfaces. It is
represented by a dashed line with a hollow arrowhead at one end that points from the client to the
server.
Interface Realization
Interface realization is a kind of specialized relation between the classifier and the interface. In
interface realization relationship, realizing classifiers conforms to the contract defined by the
interface.
A classifier implementing an interface identifies the objects that conform to the interface and any
of its ancestors. A classifier can execute one or more interfaces. The set of interfaces that are

Chapter 2 UML Compiled By: Tadesse B.

implemented by the classifier are its given interfaces. The given interfaces are the set of services
offered by the classifiers to its clients.
The interface realization relationship does not contain names, and if you name it, then the name
will appear beside the connector in the diagram.
The interface realization relationship is represented by a dashed line with a hollow arrowhead,
which points from the classifier to the given interface.

Types of realization:
1. Canonical form: In UML, the canonical form realizes the interfaces across the system. An
interface stereotype is used for creating an interface, and a realization relationship is employed to
realize (implement) a specific interface. In this, the realization relationship is represented by a
dashed line with a hollow arrowhead, and the interface is implemented using an object.
From the diagram given below, it can be seen that the object Account Business Rules realizes the
interface Iruleagent.

2. Elided form: It is that kind of realization relationship in which the interface is represented by a
circle, also known as a lollipop notation. When an interface is realized employing anything present
in the system, then an elided structure is created.
Here the interface Iruleagent is denoted by an elided form, which is realized by acctrule.dll.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

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.

Chapter 2 UML Compiled By: Tadesse B.

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.
2. 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.
3. 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.
4. 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.
5. 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.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

 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.

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

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

Chapter 2 UML Compiled By: Tadesse B.

 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.
UML Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such
as executables, files, libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system,
which is replaceable and executable. The implementation details of a component are hidden, and
it necessitates an interface to execute a function. It is like a black box whose behavior is explained
by the provided and required interfaces.
Notation of a Component Diagram
a) A component

b) A node

Chapter 2 UML Compiled By: Tadesse B.

Purpose of a Component Diagram
Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the individual
components that are used to make the functionalities, but not the functionalities of the system. It
visualizes the physical components inside the system. The components can be a library, packages,
files, etc.
The component diagram also describes the static view of a system, which includes the organization
of components at a particular instant. The collection of component diagrams represents a whole
system.
The main purpose of the component diagram is enlisted below:
1. It envisions each component of a system.
2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.
Why use Component Diagram?
The component diagrams have remarkable importance. It is used to depict the functionality and
behavior of all the components present in the system, unlike other diagrams that are used to
represent the architecture of the system, working of a system, or simply the system itself.
In UML, the component diagram portrays the behavior and organization of components at any
instant of time. The system cannot be visualized by any individual component, but it can be by the
collection of components.
Following are some reasons for the requirement of the component diagram:
1. It portrays the components of a system at the runtime.
2. It is helpful in testing a system.
3. It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing the
structure and the organization of a system. It describes how individual components can together
form a single system. Following are some reasons, which tells when to use component diagram:
1. To divide a single system into multiple components according to the functionality.
2. To represent the component organization of the system.
How to Draw a Component Diagram?

Chapter 2 UML Compiled By: Tadesse B.

The component diagram is helpful in representing the physical aspects of a system, which are files,
executables, libraries, etc. The main purpose of a component diagram is different from that of other
diagrams. It is utilized in the implementation phase of any application.
Once the system is designed employing different UML diagrams, and the artifacts are prepared,
the component diagram is used to get an idea of implementation. It plays an essential role in
implementing applications efficiently.
Following are some artifacts that are needed to be identified before drawing a component diagram:
1. What files are used inside the system?
2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?
Following are some points that are needed to be kept in mind after the artifacts are identified:
1. Using a meaningful name to ascertain the component for which the diagram is about to be
drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
Example of a Component Diagram
A component diagram for an online shopping system is given below:

Chapter 2 UML Compiled By: Tadesse B.

Where to use Component Diagrams?
The component diagram is a special purpose diagram, which is used to visualize the static
implementation view of a system. It represents the physical components of a system, or we can
say it portrays the organization of the components inside a system. The components, such as
libraries, files, executables, etc. are first needed to be organized before the implementation.
The component diagram can be used for the followings:
1. To model the components of the system.
2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.
UML Deployment Diagram
The deployment diagram visualizes the physical hardware on which the software will be deployed.
It portrays the static deployment view of a system. It involves the nodes and their relationships.

Chapter 2 UML Compiled By: Tadesse B.

It ascertains how software is deployed on the hardware. It maps the software architecture created
in design to the physical system architecture, where the software will be executed as a node. Since
it involves many nodes, the relationship is shown by utilizing communication paths.
Purpose of Deployment Diagram
The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to perform its
execution.
Both the deployment diagram and the component diagram are closely interrelated to each other as
they focus on software and hardware components. The component diagram represents the
components of a system, whereas the deployment diagram describes how they are actually
deployed on the hardware.
The deployment diagram does not focus on the logical components of the system, but it put its
attention on the hardware topology.
Following are the purposes of deployment diagram enlisted below:
1. To envision the hardware topology of the system.
2. To represent the hardware components on which the software components are installed.
3. To describe the processing of nodes at the runtime.
Symbol and notation of Deployment diagram
The deployment diagram consists of the following notations:
1. A component
2. An artifact
3. An interface
4. A node

Chapter 2 UML Compiled By: Tadesse B.

How to draw a Deployment Diagram?
The deployment diagram portrays the deployment view of the system. It helps in visualizing the
topological view of a system. It incorporates nodes, which are physical hardware. The nodes are
used to execute the artifacts. The instances of artifacts can be deployed on the instances of nodes.
Since it plays a critical role during the administrative process, it involves the following parameters:
1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable
One of the essential elements of the deployment diagram is the nodes and artifacts. So it is
necessary to identify all of the nodes and the relationship between them. It becomes easier to
develop a deployment diagram if all of the nodes, artifacts, and their relationship is already known.
Example of a Deployment diagram
A deployment diagram for the Apple iTunes application is given below.
The iTunes setup can be downloaded from the iTunes website, and also it can be installed on the
home computer. Once the installation and the registration are done, iTunes application can easily
interconnect with the Apple iTunes store. Users can purchase and download music, video, TV
serials, etc. and cache it in the media library.

Chapter 2 UML Compiled By: Tadesse B.

Devices like Apple iPod Touch and Apple iPhone can update its own media library from the
computer with iTunes with the help of USB or simply by downloading media directly from the
Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.

When to use a Deployment Diagram?

The deployment diagram is mostly employed by network engineers, system administrators, etc.
with the purpose of representing the deployment of software on the hardware system. It envisions
the interaction of the software with the hardware to accomplish the execution. The selected
hardware must be of good quality so that the software can work more efficiently at a faster rate by
producing accurate results in no time.
The software applications are quite complex these days, as they are standalone, distributed, web-
based, etc. So, it is very necessary to design efficient software.
Deployment diagrams can be used for the followings:
1. To model the network and hardware topology of a system.
2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.

Chapter 2 UML Compiled By: Tadesse B.