Deployment and Timing diagrams address the physical and temporal aspects of system design that other UML diagrams often overlook. While component diagrams show logical architecture and sequence diagrams model interactions, Deployment diagrams reveal how software maps to hardware infrastructure, and Timing diagrams capture precise temporal requirements critical for real-time and performance-sensitive systems.
In this eighth part of our UML series, we’ll master infrastructure modeling, performance analysis, and the critical timing considerations that separate theoretical designs from production-ready systems.
Deployment Diagrams: Mapping Software to Hardware
Deployment diagrams show the physical architecture of a system—how software components are distributed across hardware nodes and how these nodes communicate. They’re essential for understanding system topology, planning infrastructure, and documenting deployment strategies.
Simple Web Application Deployment
flowchart TD
Users[Users] --> LB[Load Balancer
Nginx
2 CPU, 4GB RAM]
LB --> Web1[Web Server 1
Apache + PHP
4 CPU, 8GB RAM]
LB --> Web2[Web Server 2
Apache + PHP
4 CPU, 8GB RAM]
Web1 --> App[App Server
Java Spring
8 CPU, 16GB RAM]
Web2 --> App
App --> DB[Database
PostgreSQL
16 CPU, 64GB RAM]
App --> Cache[Redis Cache
4 CPU, 16GB RAM]Cloud Infrastructure Deployment
flowchart TB
subgraph AWS["AWS Cloud"]
subgraph Public["Public Subnets"]
ALB[Application Load Balancer]
NAT[NAT Gateway]
end
subgraph Private["Private Subnets"]
ECS[ECS Fargate
Auto-scaling 2-10 instances]
RDS[RDS PostgreSQL
Multi-AZ deployment]
ElastiCache[ElastiCache Redis
Cluster mode]
end
subgraph Storage["Storage Services"]
S3[S3 Bucket
Static assets]
SQS[SQS Queue
Message processing]
end
end
Users[Users] --> ALB
ALB --> ECS
ECS --> RDS
ECS --> ElastiCache
ECS --> S3
ECS --> SQSTiming Diagrams: Performance Analysis
Timing diagrams help analyze system performance and identify bottlenecks:
gantt
title API Response Timeline
dateFormat X
axisFormat %L ms
section Request Processing
Authentication :auth, 0, 10ms
Business Logic :logic, 10ms, 40ms
Database Query :db, 40ms, 120ms
Response Format :format, 120ms, 130ms
section Performance Target
SLA Limit :milestone, sla, 150msMicroservices Deployment
flowchart TB
subgraph K8s["Kubernetes Cluster"]
subgraph Node1["Node 1"]
UserSvc[User Service
3 replicas]
OrderSvc[Order Service
2 replicas]
end
subgraph Node2["Node 2"]
ProductSvc[Product Service
3 replicas]
PaymentSvc[Payment Service
2 replicas]
end
subgraph Node3["Node 3"]
Database[PostgreSQL
Primary + Replica]
Cache[Redis Cluster
3 nodes]
end
Ingress[Ingress Controller]
end
Internet[Internet] --> Ingress
Ingress --> UserSvc
Ingress --> OrderSvc
Ingress --> ProductSvcSecurity and Network Architecture
flowchart TD
subgraph DMZ["DMZ Network"]
WAF[Web Application Firewall]
Proxy[Reverse Proxy
SSL Termination]
end
subgraph AppTier["Application Tier"]
API1[API Server 1
Port 8080]
API2[API Server 2
Port 8080]
end
subgraph DataTier["Data Tier"]
DB[Database
Port 5432
Encrypted storage]
Backup[Backup Server
Daily snapshots]
end
Client[Clients] --> WAF
WAF --> Proxy
Proxy --> API1
Proxy --> API2
API1 --> DB
API2 --> DB
DB --> BackupImplementation Best Practices
Deployment Guidelines
- Show Physical Constraints: Include CPU, memory, and network specifications
- Document Dependencies: Show all communication paths and protocols
- Include Security Boundaries: Show firewalls, VPNs, and trust zones
- Plan for Scale: Show auto-scaling and load distribution
Timing Guidelines
- Define SLAs: Include performance targets and constraints
- Show Critical Paths: Identify bottlenecks and optimization opportunities
- Model Real Scenarios: Use actual measured timings when possible
Infrastructure as Code Integration
# Deployment diagram to Docker Compose
version: '3.8'
services:
web:
image: nginx:alpine
ports:
- "80:80"
depends_on:
- api
networks:
- frontend
api:
image: myapp:latest
environment:
- DATABASE_URL=postgresql://user:pass@db:5432/myapp
depends_on:
- db
- cache
networks:
- frontend
- backend
db:
image: postgres:13
environment:
POSTGRES_DB: myapp
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
volumes:
- db_data:/var/lib/postgresql/data
networks:
- backend
cache:
image: redis:alpine
networks:
- backend
networks:
frontend:
backend:
volumes:
db_data:Conclusion: Infrastructure Meets Software Design
Deployment and Timing diagrams bridge the gap between software design and physical implementation. They ensure that elegant architectural designs actually work in the real world, with real hardware constraints, network latencies, and performance requirements.
These diagrams become increasingly important as systems move to cloud-native architectures, where understanding the infrastructure layer is crucial for performance, security, and cost optimization.
In our next post, we’ll explore UML Tools and Best Practices—comparing different tools for creating UML diagrams, integrating them into development workflows, and establishing team standards for consistent modeling.

One thought on “UML Deployment & Timing Diagrams: Infrastructure Design (Part 8)”
Comments are closed.