Mastering UML 2.5: A Use Case Driven Approach to Agile Modeling

⌘K
  2. Home
  4. Docs
  6. Mastering UML 2.5: A Use ...
  8. Module 5: Agile Architect...
  10. Architecture-Centric Development:

Architecture-Centric Development:

Using the five views of architecture (Use Case, Design, Process, Implementation, Deployment) as primary artifacts for system evolution

Architecture-centric development places the system architecture at the heart of the project—not as a static blueprint created once at the beginning, but as a living, evolving set of artifacts that guide every iteration, reduce risk, enable parallel work, and keep models, code, and reality in alignment. In an Agile, use-case-driven approach, architecture is treated as the primary mechanism for conceptualizing, constructing, validating, managing, and evolving the system incrementally.

UML 2.5 supports this through the well-known 4+1 views model (originally proposed by Philippe Kruchten), which organizes architectural description into five interlocking views. Each view is a projection of the system tailored to the concerns of specific stakeholders, and together they form a coherent, traceable whole. These views are not separate documents—they are overlapping, interconnected perspectives of the same underlying model (the semantic backplane in tools like Visual Paradigm). Changes in one view propagate consistently to others.

The Five Views and Their Roles

  1. Use Case View Describes system behavior as seen by external actors — the functional requirements, goals, and value delivered. It is the driver of the entire architecture. Primary audience: End users, product owners, analysts, testers.
  2. Design View (also called Logical View) Captures the vocabulary of the problem and solution spaces: classes, interfaces, collaborations, subsystems, and mechanisms that realize use cases. Focuses on functional structure. Primary audience: Developers, architects.
  3. Process View Addresses concurrency, threads, processes, synchronization, and runtime flows — how the system behaves dynamically under load. Tackles non-functional requirements such as performance, scalability, throughput, and fault tolerance. Primary audience: Performance engineers, DevOps, architects.
  4. Implementation View (Component View) Describes the physical organization of software: components, libraries, executables, files, modules, and their assembly into releasable units. Focuses on configuration management, build, and release. Primary audience: Developers, build engineers, configuration managers.
  5. Deployment View Maps software artifacts to hardware topology: nodes (servers, devices, containers, cloud instances), communication paths, and distribution strategy. Addresses deployment, installation, scalability, and operational concerns. Primary audience: DevOps, infrastructure teams, operations, security.

These five views interact continuously: a change in the Use Case View ripples through Design → Process → Implementation → Deployment. In Agile, the views evolve incrementally — starting lightweight in early sprints and gaining fidelity as risks are addressed and understanding deepens.

Practical Examples of Using the Five Views for System Evolution

Here are numerous real-world-inspired examples showing how the five views serve as primary artifacts across different projects:

  • E-commerce Platform – Black Friday Scaling
    • Use Case View: Core use cases “Browse Products”, “Add to Cart”, “Checkout” prioritized for MVP.
    • Design View: Class diagram + component diagram show CartService, OrderService, CatalogService.
    • Process View: Sequence + timing diagrams reveal concurrency bottlenecks in checkout under load.
    • Implementation View: Microservices components (Spring Boot JARs) versioned separately.
    • Deployment View: Kubernetes cluster with horizontal pod autoscaling for CartService; CDN for static assets. Evolution: After load testing (Process View), add Redis cache component (Implementation) → deploy to additional nodes (Deployment) → update use cases to include “Fast Checkout”.
  • Mobile Banking App – Regulatory Compliance Refactoring
    • Use Case View: “Transfer Funds”, “View Balance” require MFA and audit logging.
    • Design View: Introduce «SecureToken» class and AuthService component.
    • Process View: State machine + activity diagram model token lifecycle and concurrency in transaction processing.
    • Implementation View: Extract AuthService into separate library/module.
    • Deployment View: Place AuthService on isolated secure nodes with HSM; add audit logging to centralized SIEM. Evolution: Compliance audit flags missing audit trail → new use case “Log Sensitive Action” → realized in Design/Process → new component in Implementation → deployed with logging agents.
  • Healthcare Telemedicine Platform – PHI Protection
    • Use Case View: “Video Consultation”, “View Medical Record” marked as high-risk PHI flows.
    • Design View: Profile with «PHI» stereotype on PatientRecord, Consultation classes.
    • Process View: Activity diagram with swimlanes shows data flow; timing diagram enforces <5s latency for video.
    • Implementation View: Encrypted FHIR components isolated from non-PHI services.
    • Deployment View: HIPAA-compliant VPC; separate nodes for PHI vs. non-PHI workloads. Evolution: New regulation requires end-to-end encryption → update Process View → add encryption library in Implementation → deploy updated pods with TLS 1.3 enforcement.
  • Task Management SaaS – Real-Time Collaboration
    • Use Case View: “Real-time Card Update”, “Notify Watchers”.
    • Design View: Collaboration «WebSocketSync» pattern realizes pub/sub.
    • Process View: Sequence + timing diagrams show message latency <500ms.
    • Implementation View: Node.js + Socket.IO component + Redis pub/sub.
    • Deployment View: Multi-region Kubernetes with Redis cluster for low-latency replication. Evolution: User feedback on lag → Process View identifies jitter → add edge caching → Implementation View updates → deploy new Helm chart.
  • Legacy ERP Modernization (Strangler Fig)
    • Use Case View: “Process Invoice” initially points to legacy.
    • Design View: Reverse-engineered legacy classes → new BillingService classes.
    • Process View: Sequence shows legacy vs. new flow comparison.
    • Implementation View: Strangler adapter component bridges old/new.
    • Deployment View: New microservice on cloud; legacy remains on-prem with VPN tunnel. Evolution: Each sprint shrinks legacy footprint → new use case realizations → updated views → incremental releases.
  • IoT Smart Home Platform – Firmware Update Campaign
    • Use Case View: “Update Device Firmware”.
    • Design View: State machine + collaboration for secure update protocol.
    • Process View: Timing diagram enforces <30s handshake.
    • Implementation View: OTA Service component + embedded firmware package.
    • Deployment View: Edge gateways + cloud OTA server with CDN for large payloads. Evolution: Security vulnerability discovered → update Process/Design → new signed firmware component → staged rollout via Deployment View.

In Visual Paradigm:

  • Organize views as packages (e.g., “Use Case View”, “Design View”) with traceability links.
  • Use hyperlinks and semantic backplane to navigate between views.
  • Apply stereotypes and profiles across views for consistency.
  • Version packages or create baselines at each release milestone.
  • Generate architecture decision records or view summaries from model.

By treating these five views as primary artifacts, teams front-load risk reduction, maintain a single source of truth, enable parallel development, support incremental releases, and ensure the system evolves predictably toward stakeholder value—all while keeping modeling lightweight and directly tied to working software.

This sets the foundation for realizing use cases through collaborations and mechanisms in the next section.