Deployment Diagram Tutorial

In the context of the Unified Modeling Language (UML), a deployment diagram falls under the structural diagramming family because it describes an aspect of the system itself. In this case, the deployment diagram describes the physical deployment of information generated by the software program on hardware components. The information that the software generates is called an artifact. This shouldn't be confused with the use of the term in other modeling approaches like BPMN.

Deployment diagrams are made up of several UML shapes. The three-dimensional boxes, known as nodes, represent the basic software or hardware elements, or nodes, in the system. Lines from node to node indicate relationships, and the smaller shapes contained within the boxes represent the software artifacts that are deployed.

Deployment diagrams have several valuable applications. You can use them to:

• Show which software elements are deployed by which hardware elements.

• Illustrate the runtime processing for hardware.

• Provide a view of the hardware system’s topology.

Use Lucidchart's UML diagram tool to construct deployment diagrams. Before you begin diagramming, ask yourself these questions:

1. Have you identified the scope of your system? For example, you should know whether you are diagramming a single application or the deployment to a whole network of computers.

2. What are the limitations of your physical hardware? What legacy systems will you need to interact with? Make sure that you know the operating software and protocols you will be working with and what monitoring you will be putting into place.

3. Which distribution architecture are you using? You should know how many tiers your application will have and what application you will deploy to.

4. Do you have all the nodes you need? Do you know how they are all connected?

5. Do you know which components are going to be on which nodes?

A variety of shapes make up deployment diagrams. This list offers an overview of the basic elements you may encounter, and you can see most of these items illustrated in the image below.

• Artifact: A product developed by the software, symbolized by a rectangle with the name and the word “artifact” enclosed by double arrows.

• Association: A line that indicates a message or other type of communication between nodes.

• Component: A rectangle with two tabs that indicates a software element.

• Dependency: A dashed line that ends in an arrow, which indicates that one node or component is dependent on another.

• Interface: A circle that indicates a contractual relationship. Those objects that realize the interface must complete some sort of obligation.

• Node: A hardware or software object, shown by a three-dimensional box.

• Node as container: A node that contains another node inside of it—such as in the example below, where the nodes contain components.

• Stereotype: A device contained within the node, presented at the top of the node, with the name bracketed by double arrows.

 

Use these shapes as you build UML deployment diagrams.

Nodes

There are two types of nodes in a deployment diagram: device nodes and execution environment nodes. Device nodes are computing resources with processing capabilities and the ability to execute programs. Some examples of device nodes include PCs, laptops, and mobile phones.

An execution environment node, or EEN, is any computer system that resides within a device node. It could be an operating system, a JVM, or another servlet container.

Database

Databases represent any data stored by the deployed system. In some instances, you'll see a database represented as just another node, but sometimes you will see this shape as a database.

Other shapes

• Communication path: A straight line that represents communication between two device nodes.

• Artifacts: A box with the header "<>" and then the name of the file.

• Package: A file-shaped box that groups together all the device nodes to encapsulate the entire deployment.

• Component: An entity required to execute a stereotype function. Take a look at this guide for UML component notation.

This example shows a basic deployment diagram for Lucidchart. There is a web server, a database server, and the machine where the user views the website. You can add more complexity by showing the different parts of the web server and the way Javascript works on the UserClient, but this example gives you an idea of how a deployment looks in UML notation.