UML Deployment & Timing Diagrams: Infrastructure Design (Part 8)

UML Deployment & Timing Diagrams: Infrastructure Design (Part 8)

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 --> SQS

Timing 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, 150ms

Microservices 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 --> ProductSvc

Security 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 --> Backup

Implementation 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.

Written by:

339 Posts

View All Posts
Follow Me :

One thought on “UML Deployment & Timing Diagrams: Infrastructure Design (Part 8)

Comments are closed.