UML Deployment Diagrams

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):

@startuml node "Web Server" as WebServer { artifact "web-app.war" } node "Application Server" as AppServer { artifact "app.jar" } database "Database Server" as Database WebServer --> AppServer AppServer --> Database note right of WebServer Device node end note note right of AppServer Execution environment node end note @enduml

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:

@startuml node "Web Server" as WebServer { node "Apache" as Apache { artifact "web-app.war" } } note right of WebServer Device node contains execution environment end note @enduml

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 <> stereotype and a document icon:

@startuml artifact "order-service.jar" as OrderServiceJar note right of OrderServiceJar Artifacts represent deployable units end note @enduml

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 <> stereotype or by placing the artifact inside the node.

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

7. Practical Examples

7.1 Three-Tier Web Application

@startuml node "Client Browser" as Client node "Web Server" as WebServer { artifact "web-app.war" } node "Application Server" as AppServer { artifact "app.jar" } database "Database Server" as Database Client --> WebServer : HTTP/HTTPS WebServer --> AppServer : HTTP AppServer --> Database : JDBC @enduml

7.2 Cloud Deployment

@startuml cloud "Cloud Provider" { node "Load Balancer" as LB node "Web Server 1" as WS1 { artifact "web-app.war" } node "Web Server 2" as WS2 { artifact "web-app.war" } node "App Server" as AppServer { artifact "app.jar" } database "Database (RDS)" as Database LB --> WS1 LB --> WS2 WS1 --> AppServer WS2 --> AppServer AppServer --> Database } @enduml

7.3 Microservices Deployment

@startuml node "API Gateway" as APIGateway { artifact "gateway.jar" } node "Order Service" as OrderService { artifact "order-service.jar" } node "Payment Service" as PaymentService { artifact "payment-service.jar" } node "Inventory Service" as InventoryService { artifact "inventory-service.jar" } database "Database Cluster" as Database APIGateway --> OrderService APIGateway --> PaymentService APIGateway --> InventoryService OrderService --> Database PaymentService --> Database InventoryService --> Database @enduml

8. Conclusion

Deployment diagrams are essential for planning and documenting the physical deployment of software systems. They bridge the gap between logical design (component diagrams) and physical reality, showing where software runs and how hardware is configured.

Effective deployment modeling requires understanding nodes, artifacts, communication paths, and deployment relationships. These diagrams help ensure that systems are deployed correctly, efficiently, and reliably.

Post a Comment

0 Comments