- 1Class Diagram in UML | Beginner-Friendly Guide with Examples
- 2Object Diagram in UML | Simple, Visual Examples for Beginners
- 3Component Diagram in UML | Beginner-Friendly Tutorial with Java Examples
- 4Deployment Diagram in UML | Beginner’s Guide with Examples and Java Use Cases
- 5Package Diagram in UML | Java-Focused Tutorial with Real Examples
- 6Composite Structure Diagram in UML | Java Examples & Complete Guide for Beginners
Deployment Diagram in UML
Introduction
When software comes to life, it doesn’t run in isolation. It runs on servers, devices, clouds, or networks — each with its own hardware and configuration. A Deployment Diagram in UML shows us exactly how and where software components get deployed in the physical world.
Think of it as a map — not of your codebase, but of your infrastructure. Whether it’s a student portal, an e-commerce app, or a banking system, deployment diagrams help explain how the system runs, which servers host which components, and how they interact over a network.
What is a Deployment Diagram?
A Deployment Diagram is a type of structural UML diagram that shows the physical deployment of artifacts (like applications, executables, databases) on nodes (like servers, devices, or cloud platforms).
It answers key questions like:
- Where is the software deployed?
- What hardware or virtual environments are involved?
- How do different nodes communicate?

Key Elements of Deployment Diagrams
1. Node
A physical or virtual hardware device where software runs. Represented as a 3D cube.
node SchoolServer
2. Artifact
A physical piece of software like a JAR file, web app, or database script. Deployed inside nodes.
artifact "StudentApp.war"
3. Communication Path
Represents how nodes talk to each other — usually over a network or API. Drawn as a solid line.

4. Dependencies
Dashed arrows from artifacts to others they rely on (like a service calling a database).
Why Use Deployment Diagrams?
- Visualize system architecture during deployment or scaling
- Plan infrastructure before buying servers or cloud resources
- Debug connectivity issues between components and environments
- Document deployment for DevOps and testing teams
Real-World Example: School Management System
System Overview
Let’s say we have a school web application. It contains:
Student Web App
: for students to view attendance and marksTeacher API
: used by teachers to enter dataDatabase
: stores student records and marks
Deployment Infrastructure
- WebServer: Hosts the Student Web App
- AppServer: Runs the Teacher API
- DatabaseServer: Hosts the MySQL database
Deployment Diagram
node "Web Server" {
artifact "StudentWebApp.war"
}
node "Application Server" {
artifact "TeacherAPI.jar"
}
node "Database Server" {
artifact "schoolDB.sql"
}
"Web Server" -- "Application Server"
"Application Server" -- "Database Server"

Step-by-Step: How to Create a Deployment Diagram
Step 1: Identify Nodes
List all the physical or virtual devices where software will run. This could include:
- Web server
- Application server
- Database server
- Mobile device
- Cloud instances (AWS EC2, GCP VMs)
Step 2: Identify Artifacts
Artifacts are the deployed elements like JARs, WARs, DB dumps, configuration files.
Step 3: Map Artifacts to Nodes
Decide which artifact runs on which node. For example:
StudentApp.war
on WebServerTeacherAPI.jar
on AppServer
Step 4: Define Communication Paths
Show how nodes interact (API calls, JDBC connections, REST endpoints).
Step 5: Add Notes (optional)
Document environment configurations, ports, or protocols as needed.
Java-Based Deployment Example
Consider this setup:
- Spring Boot Application deployed as a JAR on an EC2 instance
- MySQL Database on Amazon RDS
- React Frontend deployed to S3 and served via CloudFront
node "EC2 Java Server" {
artifact "SchoolApp.jar"
}
node "Amazon RDS" {
artifact "schoolDB"
}
node "AWS S3 + CloudFront" {
artifact "StudentPortal (React Build)"
}
"StudentPortal" --> "SchoolApp"
"SchoolApp" --> "schoolDB"

Best Practices
- Use clear naming for nodes and artifacts (no generic names like “Server1”)
- Group related artifacts under the same node
- Keep diagrams simple and high-level for better communication
- Include ports/protocols (HTTP, JDBC, etc.) where applicable
Common Use Cases
- DevOps: Planning deployment strategy and CI/CD pipelines
- Cloud Migration: Visualizing which components move to the cloud
- Security Planning: Understanding which nodes need firewalls or encryption
- Education: Teaching real deployment scenarios for student-built applications
Tools for Creating Deployment Diagrams
- StarUML: Drag-and-drop support for nodes and artifacts
- Lucidchart: Easy to use, ideal for cloud architecture visuals
- PlantUML: Great for text-based modeling and version control
- draw.io: Free and intuitive for quick deployment sketches
@startuml
node "Web Server" {
artifact "student.war"
}
node "App Server" {
artifact "teacher.jar"
}
node "Database" {
artifact "school.sql"
}
"Web Server" --> "App Server"
"App Server" --> "Database"
@enduml

Conclusion
Deployment diagrams bridge the gap between developers and operations teams. They provide the missing link between software design and real-world execution. Whether you’re building a Java-based school app or a large enterprise system, deployment diagrams help clarify where everything runs and how it all connects.
Use them during planning, deployment, and even documentation phases. In the next lesson, we’ll transition into behavioral diagrams, starting with Sequence Diagrams — which show how objects talk to each other over time.
Comments
Loading comments...