Complete guide to UML Deployment Diagrams: learn how to model physical deployment of software artifacts to hardware nodes. Master deployment architecture, nodes, artifacts, and communication paths.
Table of Contents
1. What are Deployment Diagrams?
Deployment diagrams model the physical deployment of software artifacts to hardware nodes. They show the runtime architecture of a system, including servers, devices, network configurations, and how software components are deployed.
Deployment diagrams are used to:
- Plan system deployment
- Document infrastructure architecture
- Show system topology
- Model hardware and software relationships
- Plan capacity and scalability
Unlike component diagrams that show logical structure, deployment diagrams show physical structure—where software runs and how hardware is configured.
2. Nodes
2.1 What is a Node?
A node represents a computational resource, typically a physical device or execution environment. Nodes can be:
- Device Nodes: Physical hardware (servers, workstations, mobile devices)
- Execution Environment Nodes: Software environments (application servers, containers, virtual machines)
2.2 Node Notation
Nodes are shown as 3D boxes (cubes):
2.3 Device Nodes
Device nodes represent physical hardware:
- Servers (Web Server, Database Server, Application Server)
- Client devices (Desktop, Laptop, Mobile Device)
- Network devices (Router, Switch, Firewall)
- Storage devices (NAS, SAN)
2.4 Execution Environment Nodes
Execution environment nodes represent software environments:
- Application servers (Tomcat, WebLogic, WebSphere)
- Containers (Docker, Kubernetes)
- Virtual machines (VMware, Hyper-V)
- Cloud platforms (AWS EC2, Azure VM)
2.5 Nested Nodes
Execution environments can be nested within device nodes:
3. Artifacts
3.1 What is an Artifact?
An artifact represents a physical piece of information that is used or produced by software development. Artifacts are deployed to nodes and represent executable files, libraries, configuration files, and other deployable units.
3.2 Artifact Notation
Artifacts are shown as rectangles with the <
3.3 Types of Artifacts
- Executable Files: .exe, .jar, .war, .ear files
- Libraries: .dll, .so, .jar files
- Configuration Files: .xml, .properties, .yml files
- Database Scripts: .sql files
- Documentation: .pdf, .html files
3.4 Artifact Manifestation
Artifacts manifest (implement) components. The same component can be manifested by different artifacts:
OrderService (component)
↑
│ manifests
│
order-service.jar (artifact)
4. Communication Paths
4.1 What is a Communication Path?
A communication path represents a connection between nodes that allows them to exchange signals and messages. It shows how nodes communicate in the deployment architecture.
4.2 Communication Path Notation
Communication paths are shown as solid lines connecting nodes:
Web Server ──────── Database Server
4.3 Communication Path Properties
Communication paths can specify:
- Protocol: HTTP, HTTPS, TCP/IP, JDBC
- Bandwidth: Network capacity
- Stereotypes: <
>, < >, < >
4.4 Labeled Communication Paths
Web Server ──<>── Application Server
App Server ──<>─── Database Server
5. Deployment Relationships
5.1 Deployment
A deployment relationship shows that an artifact is deployed to a node. Shown as a dashed arrow with the <
order-service.jar ──<>── Application Server
┌─────────────────────┐
│ Application Server │
│ ┌───────────────┐ │
│ │order-service │ │ ← Artifact deployed
│ │.jar │ │
│ └───────────────┘ │
└─────────────────────┘
5.2 Manifestation
A manifestation relationship shows that an artifact implements (manifests) a component. Shown with a dashed arrow labeled <
OrderService ──<>── order-service.jar
5.3 Dependency
Artifacts can depend on other artifacts:
order-service.jar ────▶ payment-lib.jar
6. Best Practices
6.1 Show Key Infrastructure
- Include all important nodes (servers, devices)
- Show execution environments when relevant
- Include network topology if important
- Don't show every single device—focus on architecture
6.2 Organize Nodes
- Group related nodes together
- Use stereotypes to categorize nodes
- Show physical vs logical separation
- Keep diagrams readable and uncluttered
6.3 Document Artifacts
- Show key artifacts deployed to nodes
- Use clear, descriptive artifact names
- Show artifact dependencies
- Include version information if relevant
6.4 Show Communication
- Show important communication paths
- Document protocols and communication methods
- Indicate network boundaries (LAN, WAN, Internet)
- Show security boundaries (firewalls, DMZ)
6.5 Multiple Views
- Create different diagrams for different environments (dev, test, prod)
- Show different levels of detail
- Focus on specific aspects (security, scalability, availability)
- Keep diagrams up-to-date with actual deployment
0 Comments