UML Deployment Diagrams

When designing complex software systems, understanding how your application components map to physical infrastructure is crucial. UML Deployment Diagrams provide a clear visual representation of how software artifacts are distributed across hardware and execution environments, making them essential for system architects, DevOps engineers, and development teams planning production deployments.

What is a UML Deployment Diagram?

A Deployment Diagram is a structural UML diagram that models the physical deployment of software artifacts onto hardware nodes and execution environments. It shows:

• Hardware topology - The physical devices and servers that make up your infrastructure
• Software placement - Which applications, libraries, and files run on which hardware
• Network architecture - How different nodes communicate with each other
• Execution environments - Runtime platforms like operating systems, containers, or virtual machines
• Deployment configurations - How artifacts are configured and deployed in different environments

Why Use Deployment Diagrams?

Deployment diagrams are particularly valuable for:

• Infrastructure planning - Design and document server topology before implementation
• Cloud architecture - Model AWS, Azure, or GCP deployments with proper resource allocation
• DevOps workflows - Communicate deployment strategies between development and operations teams
• System documentation - Provide clear reference for how production systems are configured
• Environment comparison - Visualize differences between development, staging, and production setups
• Capacity planning - Identify hardware requirements and potential bottlenecks
• Troubleshooting - Understand system architecture when diagnosing deployment issues

Core Components and Notation

Nodes

A Node is the fundamental building block of deployment diagrams, representing a computational resource where artifacts can be deployed. Nodes are drawn as 3D boxes (cubes) to distinguish them from other UML elements.

There are two primary types of nodes:

Device Nodes - Physical hardware resources marked with the «device» stereotype:

• Servers, workstations, mobile devices, embedded systems
• Any physical computing resource that can execute software
• Examples: «server» Web Server, «mobile» iPhone, «pc» Developer Workstation

Execution Environment Nodes - Software platforms that provide runtime services, marked with the «executionEnvironment» stereotype:

• Operating systems (Linux, Windows)
• Runtime platforms (JVM, .NET Runtime, Node.js)
• Containerization platforms (Docker, Kubernetes)
• Application servers (Tomcat, nginx)

Execution environments are typically shown nested inside device nodes to represent the "runs on" relationship.

Artifacts

An Artifact represents a physical, deployable file or component in your system. Artifacts are drawn as rectangles labeled with the «artifact» stereotype. Optionally, a small document icon can be added in the upper-right corner for visual clarity.

Common artifact types include:

• «executable» - Runnable programs (app.jar, server.exe, main.py)
• «library» - Shared libraries (commons-lang.jar, libssl.so, react.dll)
• «file» - Configuration or data files (config.yaml, application.properties)
• «script» - Executable scripts (deploy.sh, Dockerfile, setup.py)
• «document» - Documentation files (api-spec.pdf, README.md)
• «source» - Source code files (Main.java, app.ts)

Artifacts are deployed to nodes using either:

1. Containment - Drawing the artifact inside the node box (implicit deployment)
2. Deploy dependency - A dashed arrow with «deploy» stereotype from artifact to node

Communication Paths

Communication Paths represent network connections between nodes, shown as solid lines connecting node boxes. They indicate that nodes can exchange information.

Communication paths can be labeled with:

• Protocol information - Using stereotypes like «HTTP», «HTTPS», «TCP», «gRPC», «AMQP»
• Port numbers - Showing which ports are used for communication
• Connection names - Descriptive labels for the communication channel
• Multiplicity - Numbers indicating how many connections exist

Example: A line labeled «HTTPS» port 443 connecting a Load Balancer to a Web Server.

Node Instances

While nodes represent types of computational resources, Node Instances represent specific running instances. The entire name (both instance name and type) is underlined in the format instanceName : NodeType.

Example: webServer01 : Ubuntu Server or prod-db-primary : PostgreSQL

The underline distinguishes instances (actual running systems) from node types (abstract architectural components).

Practical Example: Cloud Web Application

Let's model a typical web application deployed on AWS cloud infrastructure:

Infrastructure Components:

• CloudFront CDN for content delivery
• Application Load Balancer for traffic distribution
• ECS (Elastic Container Service) for container orchestration
• Two Docker containers: one for the web app, one for the API service
• RDS PostgreSQL for relational data
• S3 bucket for static assets (images, documents)

Key deployment relationships shown:

1. webapp.jar artifact deployed to web-container execution environment
2. api.jar artifact deployed to api-container execution environment
3. schema.sql artifact deployed to PostgreSQL database
4. static-assets/ deployed to S3 bucket
5. Communication paths showing HTTPS, HTTP, gRPC, and TCP connections with appropriate port numbers

Enterprise On-Premises Deployment

Traditional on-premises deployments can also be effectively modeled with deployment diagrams, showing physical hardware and network topology.

Scenario: Enterprise web application in a corporate data center

Infrastructure Components:

• Hardware load balancer appliance for traffic distribution
• Three web server machines running Apache
• Two application server machines running JBoss
• Primary and replica database servers
• File server for shared storage
• Network segmentation with DMZ and internal network

Node instances shown:

• loadBalancer01 : F5 Load Balancer - Hardware load balancer in DMZ
• webServer01, webServer02, webServer03 : Linux Server - Web tier servers in DMZ
• appServer01, appServer02 : Linux Server - Application tier servers in internal network
• dbPrimary : Oracle Server - Primary database server
• dbReplica : Oracle Server - Read replica for reporting
• fileServer01 : Windows Server - Shared file storage

This diagram clearly shows:

• Physical server instances with specific names
• Execution environments (Linux, JBoss, Apache, Oracle) nested within hardware
• Network boundaries separating DMZ from internal network
• Multiple instances for high availability
• Communication paths with protocols and ports
• Artifacts deployed to each tier

Best Practices

When creating deployment diagrams, follow these guidelines:

• Start with the big picture - Begin with major nodes and communication paths, then add detail
• Use appropriate stereotypes - Leverage standard UML stereotypes («device», «executionEnvironment») and create custom ones for cloud services when needed
• Show execution environment hierarchies - Nest execution environments inside devices to show the full stack (e.g., Docker inside Linux inside AWS EC2)
• Label communication paths clearly - Always indicate protocols and ports for network connections
• Keep diagrams focused - Create separate diagrams for different environments (dev, staging, production) or architectural layers rather than cramming everything into one
• Document artifact versions - When relevant, include version numbers with artifacts (api-v2.3.jar)
• Indicate multiplicity - Show how many instances of nodes exist (e.g., 3 web servers behind a load balancer)
• Use consistent naming - Follow naming conventions that match your actual infrastructure
• Show dependencies clearly - Use deployment specifications to document configuration requirements
• Update regularly - Keep deployment diagrams synchronized with actual infrastructure changes

Conclusion

UML Deployment Diagrams are indispensable for documenting and communicating how software systems are physically deployed across infrastructure. Whether you're planning a cloud migration, documenting microservices architecture, or troubleshooting production issues, deployment diagrams provide the clarity needed to understand the relationship between your software artifacts and the hardware they run on.