Deployment Diagram

A UML deployment diagram depicts a static view of the runtime configuration of hardware nodes and the software components that run on those nodes. UML deployment diagrams show the hardware for our system, the software that is being installed on that hardware, and the middleware used to connect the disparate machines to one another. We create a UML deployment model to

·         explore the issues involved in installing your system into production,

·         explore the dependencies that your system has with other systems that are currently in, or planned for, your production environment,

·         depict a major deployment configuration of a business application,

·         design the hardware and software configuration of an embedded system, or

·         depict the hardware/network infrastructure of an organization.

The are 2 main element in the deployment diagram, these are :

·         Node

·         Communication path

A node is something that can host some software. Nodes come in two forms. A device is hardware, it may be a Computer or a simpler piece of hardware connected to a system. An execution environment is software that itself hosts or contains other software, examples are an operating System or a Container process.

The nodes contain artifacts, which are the physical manifestations of software: usually, files. These files might be executables (such as .exe files, binary files, DLLs, JAR files, assemblies, or scripts), or data files, configuration files, HTML documents, and so on. Listing an artifact within a node shows that the artifact is deployed to that node in the running system.

You can show artifacts either as class boxes or by listing the name within a node. If you show them as class boxes, you can add a document icon or the «artifact» keyword. You can tag nodes or artifacts with tagged values to indicate various interesting information about the node, such as vendor, operating system, location, or anything else.

We may have multiple physical nodes carrying out the same logical task. We can either show this with multiple node boxes or state the number as a tagged value. We used the tag number deployed to indicate four physical Web Servers, but there is no standard tag for this.

Communication paths between nodes indicate how things communicate. We can label these paths with information about the communication protocols that are used.

There are two types of connectors used between nodes and artifacts in a deployment diagram. The association represents a communication path between nodes. The association shows the nodes that communicate, and a label on the association can be used to show the communications protocol between nodes. Additionally, an artifact can be drawn outside a node (some tools does not support nesting artifacts in nodes) and attached to a node with a dependency and a «deploy» stereotype. The deploy dependency between an artifact and a node means the same thing as a nested artifact or a listed text artifact—that that kind of artifact is deployed on that kind of node

Common Stereotypes for Communication paths

 

Stereotype	Implication
asynchronous	An asynchronous connection, perhaps via a message bus or message queue.
HTTP	Hypertext Transport Protocol, an Internet protocol.
JDBC	Java Database Connectivity, a Java API for database access.
ODBC	Open Database Connectivity, a Microsoft API for database access.
RMI	Remote Method Invocation, a Java communication protocol.
RPC	Communication via remote procedure calls.
Synchronous	A synchronous connects where the sender waits for a response from the receiver.
web services	Communication is via Web services protocols such as SOAP and UDDI.