4/26/2010

Lecture 19
UML Static Structure
UML Deployment Diagram

Instructor: Saif ur Rehman Khan

COMSATS Institute of Information Technology, Islamabad

Software EngineeringEngineering-II (CSC 392)

What can You Model with UML?

Deployment Diagram
Another model in the implementation diagram category

UML 2.0 defines thirteen types of diagrams, divided into three categories:

The deployment diagram shows how a system will be physically

deployed in the hardware environment

1. Structure Diagrams:
i.
ii.
iii.

Class Diagram
Object Diagram
Component Diagram

iv.

Deployment Diagram

v.
vi.
vii.

Composite
p
Structure Diagram
g
Package Diagram
Profile Diagram

Its purpose is to show where the different components of the system

will physically run and how they will communicate with each
other
h
Since the diagram models the physical runtime, a system's
production staff will make considerable use of this diagram

2. Behavior Diagrams:
i.
ii.
iii.

Use Case Diagram (used by some methodologies during requirements

gathering)
Activity Diagram
State Machine Diagram

3. Interaction Diagrams:
i.
ii.
iii.
iv.

Sequence Diagram
Communication Diagram
Timing Diagram,
Interaction Overview Diagram
Software EngineeringEngineering-II (CSC 392)

Deployment Diagram

Software EngineeringEngineering-II (CSC 392)

Artifact
An artifact is the specification of a physical piece of information that is used or
produced by a software development process, or by deployment and operation of a
system

The Deployments package specifies a set of constructs that can be used to define the execution
architecture of systems that represent the assignment of software artifacts to nodes
The notation in a deployment diagram includes the notation elements used in a component diagram,
with a couple of additions, including the concept of a node

Examples of artifacts include

Nodes are typically defined in a nested manner, and represent either hardware devices or software
execution environments

Artifacts represent concrete elements in the physical world that are the result of a development process

The Deployment diagram models the hardware used in implementing a system and the association
between those hardware components

Components can also be shown on a Deployment diagram to show the location of their deployment

Deployment diagrams can also be used earlyon in the design phase to document the physical
architecture of a system

It is especially useful in building a distributed system,

system, where it is possible to divide the run units of the
application among several interconnected servers

Software Engineering-II (CSC 392)

source files, scripts, and binary executable files, a table in a database system, a development
deliverable, or a word-processing document, a mail message

Artifacts may have composition associations to other artifacts that are nested
within it

Software EngineeringEngineering-II (CSC 392)

For instance, a deployment descriptor artifact for a component may be contained within the
artifact that implements that component. In that way, the component and its descriptor are
deployed to a node instance as one artifact instance

The UML Standard Profile defines several standard stereotypes that apply to
Artifacts

e.g., source or executable

These stereotypes can be further specialized into implementation and platform specific
stereotypes in profiles

For example, an EJB profile might define jar as a subclass of executable for executable Java
archives.

Software EngineeringEngineering-II (CSC 392)

4/26/2010

Artifact: Notation

Deployment Relationship

An artifact is presented using an ordinary class rectangle with the keykey-word

artifact
Alternatively, it may be depicted by an icon
Optionally, the underlining of the name of an artifact instance may be
omitted, as the context is assumed to be known to users

The deployment relationship between a

DeployedArtifact and a DeploymentTarget can be
defined at the type
type level and at the instance
instance level
For example, a type level deployment relationship can
be defined between an application
application server
server Node and
an order
order entry request handler
handler executable Artifact
At the instance level 3 specific instances appserver1
... app
app--server3 may be the deployment target for six
request handler* instances

Software EngineeringEngineering-II (CSC 392)

Diagram Elements

Node
A node represents a piece of
hardware in the system

The elements used in Deployment diagrams are:

1.

Components, as we have seen in Component diagrams,

2.

Nodes, which represent the physical processing resources in

the system,

3.

and Associations

Software EngineeringEngineering-II (CSC 392)

A node is computational resource

upon which artifacts may be
deployed for execution
Nodes can be interconnected
through communication paths to
define network structures
This entity is represented by a
three--dimensional cube
three

Software EngineeringEngineering-II (CSC 392)

Node (cont.)

Software EngineeringEngineering-II (CSC 392)

10

Device
A Device is a physical computational resource with processing
capability upon which artifacts may be deployed for execution.
Devices may be complex (i.e., they may consist of other devices)

Nodes can be connected to represent a network topology by using communication

paths
Communication paths can be defined between nodes such as application server
and client workstation to define the possible communication paths between nodes
Specific network topologies can then be defined through links between node
instances

A Device is notated by a perspective view of a cube tagged with the

keyword device

Hierarchical nodes (i.e., nodes within nodes) can be modeled using composition
associations, or by defining an internal structure for advanced modeling
applications
Non-normative examples of nodes are application server, client workstation,
Nonmobile device, embedded device

Software EngineeringEngineering-II (CSC 392)

Software Engineering-II (CSC 392)

11

Software EngineeringEngineering-II (CSC 392)

12

4/26/2010

Association

Dependency
A dependency is a relationship that signifies that a
single or a set of model elements requires other model
elements for their specification or implementation

An association, drawn as a solid

line between two Nodes,
indicates a line of
communication between the
hardware elements

Software EngineeringEngineering
13 -II (CSC 392)

Software EngineeringEngineering-II (CSC 392)

Deployment Location

Deployment Location using keyword

Deployment diagrams show the allocation of Artifacts to

Nodes according to the Deployments defined between them

Software EngineeringEngineering-II (CSC 392)

14

An alternative notation to containing the deployed artifacts within a

deployment target symbol is to use a dependency labeled deploy
that is drawn from the artifact to the deployment target

15

Deployment Location: List based Representation

Software EngineeringEngineering-II (CSC 392)

16

Deployment Specification: Semantics &

Notation
A Deployment specification is a general mechanism to parameterize a Deployment
relationship, as is common in various hardware and software technologies
The deployment specification element is expected to be extended in specific
component profiles. NonNon-normative examples of the standard stereotypes that a
profile might add to deployment specification are,

for example, concurrencyMode with tagged values {thread, process, none},

or transactionMode with tagged values {transaction, nestedTransaction, none}

A DeploymentSpecification is graphically displayed as a classifier rectangle

attached to a component artifact deployed on a container using a regular
dependency arrow

Software EngineeringEngineering-II (CSC 392)

Software Engineering-II (CSC 392)

17

Software EngineeringEngineering-II (CSC 392)

18

4/26/2010

Software EngineeringEngineering-II (CSC 392)

19

Software EngineeringEngineering-II (CSC 392)

20

Execution Environment: Semantics

ExecutionEnvironment instances are assigned to node instances by using
composite associations between nodes and ExecutionEnvironments
ExecutionEnvironments,, where
the ExecutionEnvironment plays the role of the part
ExecutionEnvironments can be nested

e.g., a database ExecutionEnvironment may be nested in an operating system

ExecutionEnvironment)

Components
of the appropriate
type
p
pp p
yp are then deployed
p y to specific
p
ExecutionEnvironment nodes
Typical examples of standard ExecutionEnvironments that specific profiles
might define stereotypes for are OS, workflow engine, database
system, and J2EE container
An ExecutionEnvironment can optionally have an explicit interface of
system level services that can be called by the deployed elements, in those
cases where the modeler wants to make the ExecutionEnvironment
software execution environment services explicit
Software EngineeringEngineering-II (CSC 392)

21

Software EngineeringEngineering-II (CSC 392)

22

Manifestation: Semantics

Execution Environment: Node

A ExecutionEnvironment is notated by a Node
annotated with the stereotype executionEnvironment
executionEnvironment

An artifact embodies or manifests a number of model elements

The artifact owns the manifestations, each representing the
utilization of a packageable element
Specific profiles are expected to stereotype the manifestation
relationship to indicate particular forms of manifestation
For example, <<tool generated>> and <<custom code>> might be
two manifestations for different classes embodied in an artifact

Software EngineeringEngineering-II (CSC 392)

Software Engineering-II (CSC 392)

23

Software EngineeringEngineering-II (CSC 392)

24

4/26/2010

Manifestation: Notation
A manifestation is notated in the same way as an abstraction
dependency,

i.e., as a general dashed line with an open arrow-head labeled with the
keyword <<manifest>>

In UML 1.x, the concept of Manifestation was referred to as

p
p
implementation
and annotated in the notation as <<implement>>

Software EngineeringEngineering-II (CSC 392)

25

Software EngineeringEngineering-II (CSC 392)

26

Example

Software EngineeringEngineering-II (CSC 392)

27

Software EngineeringEngineering
28 -II (CSC 392)

Deployment diagram for the music

programs example

Software EngineeringEngineering
29 -II (CSC 392)

Software Engineering-II (CSC 392)

Software EngineeringEngineering-II (CSC 392)

30

4/26/2010

An Occurrence of Deployment
Diagram

University Information System

The threethree-dimensional boxes represent nodes, either software or hardware. Physical nodes should be
labeled with the stereotype device
device,, to indicate that it is a physical device such as a computer or switch
Connections between nodes are represented with simple lines, and are assigned stereotypes such as RMI
and message bus to indicate the type of connection

Software EngineeringEngineering
31 -II (CSC 392)

Software EngineeringEngineering-II (CSC 392)

University Information System

(concise diagram)

32

References

A better example is shown in the figure below. Software elements are now simply
listed by their physical filenames, information that developers are very likely to be
interested in, and thus a more compact diagram is possible
A drum is used as a visual stereotype for the University DB database, making it
easier to distinguish on the diagram. Another difference is that the concise version
shows less details, not as many tagged values are shown as this information can be
captured in either supporting documentation, configuration files, or source code

Roger S. Pressman, Software Engineering,

Engineering, A Practitioners Approach,
Sixth Edition, 20005.

Ian Sommerville
Sommerville,, Software Engineering,
Engineering, 2000.

Craig Larman
Larman,, Applying UML and Patterns, An Introduction to object
object-Oriented Analysis and Design and The Unified Process,
Process, Second Edition,
2002.

http://www.uml.org
http://www.omg.org

OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2

http://www.agilemodeling.com/artifacts/deploymentDiagram.htm

Software EngineeringEngineering-II (CSC 392)

Software Engineering-II (CSC 392)

33

Software EngineeringEngineering-II (CSC 392)

34