Object Oriented System Design

Unit 2
Prepared By
Shruti Bharadwaj
Assistant Professor,UCER,Praygraj
INDEX
• Class Diagram
• Object Diagram
 UML - Diagrams
There are two broad categories of diagrams and they are again further
divided into subcategories −
• Structural Diagrams
• Behavioral Diagrams
 Structural Diagrams
The structural diagrams represent the static aspect of the system.
These static aspects represent those parts of a diagram, which forms
the main structure and are therefore stable.
These static parts are represented by classes, interfaces, objects,
components, and nodes. The four structural diagrams are −
➢Class diagram
➢Object diagram
➢Component diagram
➢Deployment diagram
➢Package Diagram
Behavioral Diagrams
Behavioral diagrams basically capture the dynamic aspect of a system.
Dynamic aspect can be further described as the changing/moving parts
of a system.
UML has the following five types of behavioral diagrams −
➢Use case diagram
➢Sequence diagram
➢Collaboration diagram
➢State chart diagram
➢Activity diagram
 Class Diagram
Class diagrams models the analysis and design of the static
view of an application. It captures the key abstractions of the
system at the first level, and is later refined with details of
every abstraction for reference.
 UML Class Notation
• A class is a rectangle divided into three parts
– Class name
– Class attributes (i.e. data members, variables)
– Class operations (i.e. methods)
• Modifiers
– Private: -
– Public: +
– Protected: #
– Static: Underlined (i.e. shared among all members of the class)
• Abstract class: Name in italics

Employee
-Name : string
+ID : long
#Salary : double
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
Class diagram
◼ A class diagram depicts classes and their interrelationships

◼ Used for describing structure and behavior in the use cases

◼ Provide a conceptual model of the system in terms of entities

and their relationships– to translate the models into
programming code.

◼ Represents the structural – static behavior of the System.

◼ Used for requirement capture, end-user interaction

◼ Detailed class diagrams are used for developers

OO Relationships
◼ There are two kinds of Relationships
➢ Generalization (parent-child relationship)
➢ Association (student enrolls in course)

◼ Associations can be further classified as

➢ Aggregation
➢ Composition
 OO Relationships: Association

◼ Represent relationship between instances of classes

➢ Student enrolls in a course
➢ Courses have students
➢ Courses have exams
➢ Etc.

◼ Association has two ends

➢ Role names (e.g. enrolls)
➢ Multiplicity (e.g. One course can have many students)
➢ Navigability (unidirectional, bidirectional)
 Association: Multiplicity and Roles
student
1 *

University Person

0..1 *
employer teacher

Multiplicity Role
Symbol Meaning
1 One and only one Role
0..1 Zero or one “A given university groups many people;
M.. From M to N (natural language)
some act as students, others as teachers.
N A given student belongs to a single
* From zero to any positive integer
university; a given teacher may or may not
0..* From zero to any positive integer be working for the university at a particular
1..* From one to any positive integer time.”
Association: Model to Implementation

* 4
Student Course
has enrolls

class Student {
Course enrolls[4];
}

class Course {
Student have[];
}
Link and Association

◼ Examples of class and object diagrams

◼ Person and Company

◼ Country and CapitalCity

◼ Workstation and Window

 Associations
◼ Association represents a group of links.
Person
◼ Self association:

◼ Binary association: Company Worker

employment
◼ N-array association:
company Worker

Contract
Association End Names

◼ Use of association end names is optional, but it is

often easier and less confusing to assign association
end names instead of or in addition to, association
names.
◼ Association end names are necessary for
associations between two objects of the same class
 Association Classes
◼ An association class is used to model an association as a class.
Association classes often occur in many-to-one and many-to-
many associations where the association itself has attributes. It
is used to break up a many-to-many association between
classes.

◼ These are similar to associative entities on an entity-relationship

diagram.
 Association Classes
◼ Student and Course have a many-to-many relationship, which is resolved by adding
an association class called Section between the classes of Student and Course.
Figure illustrates an association class called Section, shown with a dotted line
connected to the many-to-many relationship line.
 Qualified Associations
◼ It is an Association in which an attribute called qualifier disambiguates the
objects for a “many” association end.
◼ A qualifier selects among target objects, reducing the effective multiplicity
from “many” to “one” and specify a precise path for finding the target
object from the source object.
Qualified Associations(2)
 Whole/Part relationships
◼ Whole/part relationships are when one class represents the whole
object and other classes represent parts.

◼ The whole acts as a container for the parts.

◼ These relationships are shown on a class diagram by a line with a

diamond on one end.

◼ A whole/part relationship may be an entity object that has distinct

parts, such as a computer system that includes the computer, printer,
display, and so on, or an automobile that has an engine, brake system,
transmission, and so on.

◼ Whole/part relationships have two categories: aggregation and

composition.
 Aggregation
Container Class
Aggregation:
Example Bag described as a “has a” relationship..
AGGREGATION
Aggregation provides a means of showing that the
whole object is composed of the sum of its parts
(other objects).
Apples Milk

Aggregation is appropriate when Container and

Containees have no special access privileges to
Containee Classes
each other.
[From Dr.David A. Workman]

In the student enrollment example, the Department Course

department has a course and the course is
for a department. This is a weaker
relationship, because a department may be Classroom Student
changed or removed and the course
may still exist, so independent from each Printer
Computer
other.
 Whole/Part relationships
▪ Composition, a whole/part relationship in which the whole has a responsibility for the part,
is a stronger relationship, shown with a filled-in diamond.
▪ Keywords for composition are one class “always contains” another class.
▪ If the whole is deleted, all parts are deleted.
▪ An example would be an insurance policy with riders. If the policy is canceled, the
insurance riders are also canceled. In a database, the referential integrity would be set to
delete cascading child records. In a university there is a composition relationship between a
course and an assignment as well as between a course and an exam. If the course is deleted,
assignments and exams are deleted as well.

Example
Whole Class Part Classes
A number of different chess boards: Each
square belongs to only one board. If a
chess board is thrown away, all 64
squares on that board go as well.
OO Relationships
Aggregation vs. Composition
◼ Composition is really a strong form of association
➢ components have only one owner
➢ components cannot exist independent of their owner
➢ components live or die with their owner
➢ e.g. Each car has an engine that can not be shared with other cars.

◼ Aggregations
may form "part of" the association, but may not be essential to it. They
may also exist independent of the aggregate. e.g. Apples may exist
independent of the bag.
 Concrete Class
◼ Instantiable – which can have direct instances.
◼ It may have abstract subclasses – But in turn must have concrete
descendants
◼ Only concrete classes may be leaf classes in an inheritance tree.
 Abstract Class

◼ No direct instances but whose descendant classes have direct instances.

◼ Represented by italicized text or place keyword {abstract} below or after
the name

abstract class BankAccount{

String owner;
float dollars;
void deposit(float amount){….}
abstract void withdrawal(float amount);
}
 Abstract Class(2)
◼ Program Example : ABC.java
Class diagram

[from UML Distilled Third Edition]

UML Class Example
 Object Diagram
• Object diagrams can be described as an instance of class diagram.
Thus, these diagrams are more close to real-life scenarios where we
implement a system.
• Object diagrams are a set of objects and their relationship is just like
class diagrams. They also represent the static view of the system at a
particular moment.
 UML Object Notation

• Format is
– Instance name : Class name
– Attributes and Values

– Example:
 Object Diagram

Can add association type and also message type

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 Collaboration

diagram that are enlisted below
➢Objects
➢Actors
➢Links
➢Messages
Objects:

The representation of an object is done by an object

symbol with its name and class underlined, separated
by a colon.
In the collaboration diagram, objects are utilized in the
following ways:
The object is represented by specifying their name and class.
It is not mandatory for every class to appear.
A class may constitute more than one object.
In the collaboration diagram, firstly, the object is created, and
then its class is specified.
To differentiate one object from another object, it is necessary to
name them.
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.
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.
Messages

It is a communication between objects which carries

information and includes a sequence number, so that the
activity may take place.
It is represented by a labeled arrow, which is placed near
a link.
The messages are sent from the sender to the receiver,
and the direction must be navigable in that particular
direction.
The receiver must understand the message.
When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict

the relationship between the object.
Both the sequence and collaboration diagrams represent
the same information, but the way of portraying it quite
different.
The collaboration diagrams are best suited for analyzing
use cases.
Following are some of the use cases enlisted
below for which the collaboration diagram is
implemented:
To model collaboration among the objects or roles that
carry the functionalities of use cases and operations.
To model the mechanism inside the architectural design
of the system.
To capture the interactions that represent the flow of
messages between the objects and the roles inside the
collaboration.
To model different scenarios within the use case or
operation, involving a collaboration of several objects and
interactions.
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.
Choose the context of an interaction: system, subsystem, use case,
and operation.
3. Think through alternative situations that may be involved.
Implementation of a collaboration diagram at an instance level, if
needed.
A specification level diagram may be made in the instance level
sequence diagram for summarizing alternative situations.
Example of a Collaboration Diagram
Example
Collaboration Diagram For ATM machine
Collaboration Diagram for ATM withdrawal
Benefits of a Collaboration Diagram

The collaboration diagram is also known as

Communication Diagram.
It mainly puts emphasis on the structural aspect of
an interaction diagram, i.e., how lifelines are
connected.
The syntax of a collaboration diagram is similar to
the sequence diagram; just the difference is that the
lifeline does not consist of tails.
The messages transmitted over sequencing is
represented by numbering each individual message.
The collaboration diagram is semantically weak in
comparison to the sequence diagram.
The drawback of a Collaboration Diagram

Multiple objects residing in the system can make a

complex collaboration diagram, as it becomes quite hard
to explore the objects.
It is a time-consuming diagram.
After the program terminates, the object is destroyed.
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.
 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.
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:

A pertinent and meaningful name should be

assigned to the actor or a use case of a
system.
The communication of an actor with a use
case must be defined in an understandable
way.
Specified notations to be used as and when
required.
The most significant interactions should be
represented among the multiple no of
interactions between the use case and
actors.
Importance of Use Case Diagrams
To identify functions and how roles interact with them – The primary
purpose of use case diagrams.
For a high-level view of the system – Especially useful when presenting
to managers or stakeholders. You can highlight the roles that interact with
the system and the functionality provided by the system without going deep
into inner workings of the system.
To identify internal and external factors – This might sound simple but in
large complex projects a system can be identified as an external role in
another use case.
Use Case Diagram objects
Use case diagrams consist of 4 objects.
Actor
Use case
System
Package
Actor
Actor in a use case diagram is any entity that performs a role in one given
system. This could be a person, organization or an external system and
usually drawn like skeleton shown below.
Use Case
A use case represents a function or an
action within the system. It’s drawn as an
oval and named with the function.
 System

The system is used to define the scope of the use case and drawn as a
rectangle. This an optional element but useful when you’re visualizing large
systems.
For example, you can create all the use cases and then use the system
object to define the scope covered by your project. Or you can even use it
to show the different areas covered in different releases.
Package

The package is another optional element that is extremely useful in complex

diagrams. Similar to class diagrams, packages are used to group together
use cases. They are drawn like the image shown below.
Relationships in Use Case
Diagrams
There are five types of relationships in a
use case diagram. They are
Association between an actor and a use case
Generalization of an actor
Extend relationship between two use cases
Include relationship between two use cases
Generalization of a use case
Association Between Actor and
Use Case
This one is straightforward and present in
every use case diagram. Few things to
note.
An actor must be associated with at least one use case.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.
Generalization of an Actor

Generalization of an actor means that one

actor can inherit the role of the other actor.
The descendant inherits all the use cases
of the ancestor.
The descendant has one or more use
cases that are specific to that role.
Let’s expand the previous use case
diagram to show the generalization of
an actor.
Extend Relationship Between Two Use Cases

As the name implies it extends the base use case and

adds more functionality to the system. Here are a few
things to consider when using the <<extend>>
relationship.
The extending use case is dependent on the
extended (base) use case. In the below diagram the
“Calculate Bonus” use case doesn’t make much sense
without the “Deposit Funds” use case.
The extending use case is usually optional and can
be triggered conditionally. In the diagram, you can see
that the extending use case is triggered only for deposits
over 10,000 or when the age is over 55.
The extended (base) use case must be meaningful
on its own. This means it should be independent and
Example to show the <<extend>> relationship.
Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part
of the including (base) use case. The main reason for this is to reuse
common actions across multiple use cases. In some situations, this is done
to simplify complex behaviors. Few things to consider when using the
<<include>> relationship.
The base use case is incomplete without the included use case.
The included use case is mandatory and not optional.
banking system use case diagram to show include relationships as
well
Generalization of a Use Case
This is similar to the generalization of an
actor. The behavior of the ancestor is
inherited by the descendant. This is used
when there is common behavior between
two use cases and also specialized
behavior specific to each use case.
For example, in the previous banking
example, there might be a use case called
“Pay Bills”. This can be generalized to
“Pay by Credit Card”, “Pay by Bank
Balance” etc.
Use Case Diagram Guidelines for Better Use Cases

A use case diagram mainly consists of actors, use cases and relationships.
More complex larger diagrams can include systems and boundaries.
Actors
Give meaningful business relevant names for actors – For example, if
your use case interacts with an outside organization it’s much better to
name it with the function rather than the organization name. (Eg: Airline
Company is better than PanAir)
Primary actors should be to the left side of the diagram – This enables
you to quickly highlight the important roles in the system.
Actors model roles (not positions) – In a hotel both the front office
executive and shift manager can make reservations. So something like
“Reservation Agent” should be used for actor name to highlight the role.
External systems are actors – If your use
case is send-email and if interacts with the
email management software then the
software is an actor to that particular use
case.
Actors don’t interact with other actors – In
case actors interact within a system you need
to create a new use case diagram with the
system in the previous diagram represented
as an actor.
Place inheriting actors below the parent
actor – This is to make it more readable and
to quickly highlight the use cases specific for
that actor.
Use Cases
Names begin with a verb – A use case
models an action so the name should
begin with a verb.
Make the name descriptive – This is to
give more information for others who are
looking at the diagram. For example “Print
Invoice” is better than “Print”.
Highlight the logical order – For
example, if you’re analyzing a bank
customer typical use cases include open
account, deposit and withdraw. Showing
them in the logical order makes more
sense.
Place included use cases to the right of
the invoking use case – This is done to
improve readability and add clarity.
Place inheriting use case below parent
use case – Again this is done to improve
the readability of the diagram.
Relationships
Arrow points to the base use case when
using <<extend>>
<<extend>> can have optional extension
conditions
Arrow points to the included use case
when using <<include>>
Both <<extend>> and <<include>> are
shown as dashed arrows.
Actor and use case relationship don’t
show arrows.
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.
 State Machine Diagram
STATE DIAGRAM are used to capture the behavior of a
software system.
UML State machine diagrams can be used to model the
behavior of a class, a subsystem, a package, or even an
entire system.
It is also called a Statechart or State Transition diagram.
Statechart diagrams provide us an efficient way to model
the interactions or communication that occur within the
external entities and a system.
These diagrams are used to model the event-based
system. A state of an object is controlled with the help of
an event.
Why State Machine Diagram?

Statechart diagram is used to capture the dynamic

aspect of a system. State machine diagrams are used to
represent the behavior of an application.
An object goes through various states during its lifespan.
The lifespan of an object remains until the program is
terminated.
The object goes from multiple states depending upon the
event that occurs within the object.
Each state represents some unique information about the
object
Notation and Symbol for State Machine
Initial state
The initial state symbol is used to indicate the beginning of a
state machine diagram.
Final state
This symbol is used to indicate the end of a state machine
diagram.
Decision box
It contains a condition. Depending upon the result of an
evaluated guard condition, a new path is taken for program
execution.
Transition
A transition is a change in one state into another state which
is occurred because of some event. A transition causes a
change in the state of an object.
State box
It is a specific moment in the lifespan of an object. It is defined using some condition or a statement
within the classifier body. It is used to represent any static as well as dynamic situations.
It is denoted using a rectangle with round corners.
The name of a state is written inside the rounded rectangle.
The name of a state can also be placed outside the rectangle.
This can be done in case of composite or submachine states. One can either place the name of a
state within the rectangle or outside the rectangle in a tabular box.
One cannot perform both at the same time.
A state can be either active or inactive.
When a state is in the working mode, it is active, as soon as it stops executing and transits into
another state, the previous state becomes inactive, and the current state becomes active.
Types of State

Unified Modeling Language defines three types of states:

Simple state
They do not have any sub-state.
Composite state
These types of states can have one or more than one substate.
A composite state with two or more sub states is called an
orthogonal state.
Submachine state
These states are semantically equal to the composite states.
Unlike the composite state, we can reuse the submachine states.
Following rules must be considered while drawing a state chart diagram:

The name of a state transition must be unique.

The name of a state must be easily understandable and
describe the behavior of a state.
If there are multiple objects, then only essential objects
should be implemented.
Proper names for each transition and an event must be
given.
When to use State Diagrams?

State diagrams are used to implement real-life working models and object-oriented systems in depth.
These diagrams are used to compare the dynamic and static nature of a system by capturing the
dynamic behavior of a system.
Statechart diagrams are used to capture the changes in various entities of the system from start to
end.
They are used to analyze how an event can trigger change within multiple states of a system.
state chart diagram represents the user authentication
process.
State Machine Diagram example: Toaster
state Diagram for modeling the behavior of the
DigitalClock
State Machine Diagram example: Computer
Testing
State Machine Diagram example: Human Life
Package Diagram

A package in the Unified Modeling Language helps

To group elements
To provide a namespace for the grouped elements
A package may contain other packages, thus providing for a hierarchical organization of packages.
UML elements can be grouped into packages.
Eg: – classes, objects,use cases, components, nodes, node instances etc.
All UML elements can be organized as packages.

UML diagram composed only of packages and the

dependencies between them.
A package is a UML construct that enables you to
organize model elements, such as use cases or classes,
into groups.
Packages are depicted as file folders and can be
applied on any UML diagram.
Packages
Use a tabbed folder to illustrate packages. Write the name of the package on the tab or inside the
folder. Similar to classes, you can also list the attributes of a package
Each package must have a name that
distinguishes it from other packages
A name is a textual string
Two types of names:
Simple names: e.g., Business rules, Client
Qualified names: e.g. Sensors::Vision
Package name prefixed by the name of the package in
which that package lives
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.
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

To envision the hardware topology of the system.

To represent the hardware components on which the
software components are installed.
To describe the processing of nodes at the runtime.
Symbol and notation of Deployment diagram

The deployment diagram consist of the following

notations:
A component
An artifact
An interface
A node
Artifact

An artifact represents the specification of a concrete real-

world entity related to software development.
You can use the artifact to describe a framework which is
used during the software development process or an
executable file.
Artifacts are deployed on the nodes.
Artifacts are deployed on the nodes.
It can provide physical manifestation for any UML element. Generally, they manifest components.
Artifacts are labeled with the stereotype <<artifact>>, and it may have an artifact icon on the top right
corner.
Each artifact has a filename in its specification that indicates the physical location of the artifact.
An artifact can contain another artifact. It may be dependent on one another.
Artifacts have their properties and behavior that manipulates them.
Generally, an artifact is represented as follows in the unified modeling language.
The most common artifacts are as follows

Source files
Executable files
Database tables
Scripts
DLL files
User manuals or documentation
Output files
Artifact Instances

An artifact instance represents an instance of a particular

artifact.
An artifact instance is denoted with same symbol as that
of the artifact except that the name is underlined.
UML diagram allows this to differentiate between the
original artifact and the instance.
Each physical copy or a file is an instance of a unique
artifact.
Generally, an artifact instance is represented as follows
in the unified modeling language.
What is a node?

Node is a computational resource upon which artifacts are

deployed for execution.
A node is a physical thing that can execute one or more
artifacts.
A node may vary in its size depending upon the size of the
project.
Node is an essential UML element that describes the
execution of code and the communication between various
entities of a system.
It is denoted by a 3D box with the node-name written inside
of it. Nodes help to convey the hardware which is used to
deploy the software.
An association between nodes represents a communication
path from which information is exchanged in any direction.
A node has two stereotypes as follows

<< device >>It is a node that represents a physical machine capable of performing computations.
A device can be a router or a server PC.
It is represented using a node with stereotype <<device>>.
In the UML model, you can also nest one or more devices within each other.
Following is a representation of a device in UML.
<< device >>It is a node that represents a physical machine capable of performing computations. A
device can be a router or a server PC. It is represented using a node with stereotype <<device>>.
In the UML model, you can also nest one or more devices within each other.
Following is a representation of a device in UML:
<< execution environment >>It is a node that represents an environment in which software is going
to execute. For example, Java applications are executed in java virtual machine (JVM). JVM is
considered as an execution environment for Java applications. We can nest an execution environment
into a device node. You can net more than one execution environments in a single device node.
Following is a representation of an execution environment in UML:
deployment diagram represents the working of HTML5 video player in the browser
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.
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.
When to use a Deployment Diagram?

To model the network and hardware topology of a

system.
To model the distributed networks and systems.
To model the hardware details for a client/server system.
For modeling the embedded system