Skip to content
Software Architecture Guide

Deployment Diagram Modeling Mistake

Explanation

Section titled “Explanation”

A deployment diagram shows where software runs. Nodes appear as boxes. The artifacts allocated to each node appear as rectangles inside the boxes. The diagram also shows how nodes connect. See the article on the UML Deployment Diagram for the basics. These are the mistakes that come up most.

Deploying the wrong thing. Only artifacts are deployed. UML defines a deployment as allocating an artifact (or an artifact instance) to a deployment target. Deploying a server node onto a class is therefore invalid. A node is the resource that artifacts run on. Other nodes and classes are not deployed onto it.

Confusing artifacts with components. An artifact is a physical piece of information, such as a file or a script. A component is a different element. Do not treat the two as the same box.

Wrong direction on the deploy dependency. A dependency means one element requires another. The «deploy» link is a dependency, so its direction carries meaning. Check each arrow against the UML notation before publishing.

Wrong node type. A «device» is physical hardware with processing capability. An «executionEnvironment» is a software node that hosts certain kinds of components. An application server or a JVM is an execution environment, not a device. Label every node with the right stereotype. A stereotype is a tag in guillemets that states what kind of element it is.

Unnamed connections. Connections between nodes should say which protocol they use, for example JDBC, REST or RMI. An arrow with no label, or a path with no protocol stereotype, leaves readers guessing. Name each path.

Detached configuration. A deployment specification holds the execution parameters of a deployed artifact. It is a separate element. Link it to the artifact it configures. Otherwise nobody can tell what it configures.

Example

Section titled “Example”

A team draws a box called “Order Server” and places it inside a class called “Shop”. This is the first error: a server node cannot be deployed onto a class. They fix it by putting an artifact, such as “orders.jar”, inside the server node. They mark the server as an execution environment, because it is software. They mark the database host as a device, because it is hardware. They label the line between them with the protocol, such as JDBC. Finally, they attach the configuration file’s deployment specification to “orders.jar”.

Trade-offs

Section titled “Trade-offs”

Careful stereotypes and labels make a diagram longer and busier. The gain is that readers do not have to guess what each box and line means. For a rough sketch, you may skip some detail. For a diagram that others will use to build or run the system, name every node type and every connection.

Checks

Section titled “Checks”
  • Every deployment targets a node, and only artifacts (or artifact instances) are deployed onto it.
  • Physical hardware nodes are marked «device». Software hosts such as an application server or JVM are marked «executionEnvironment».
  • Each connection between nodes is labeled with its protocol, such as JDBC, REST or RMI.
  • Each deployment specification is linked to the artifact it configures.
  • Artifacts and components are shown as separate elements, and the direction of each «deploy» dependency has been checked.
Section titled “Related”

Sources

Section titled “Sources”