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 3: The Skeleton – The 7 Structural UML Diagrams

Module 3: The Skeleton – The 7 Structural UML Diagrams

Welcome to Module 3, where we build the static backbone of the system—the unchanging (or slowly changing) structure that defines what the system is composed of, how its parts are organized, and how they relate to each other. While Module 2 focused on use cases (the “what the system does” from the user’s view), this module shifts to the structural view: the classes, components, packages, and physical deployment that realize those use cases.

These 7 structural diagrams in UML 2.5 provide the skeleton—a clear, visual map of the system’s architecture at different abstraction levels (conceptual, logical, physical). In Agile contexts, structural models are kept lightweight and purposeful: created just-in-time to clarify domain concepts, organize large codebases, communicate architecture decisions, support code generation/reverse engineering, and reduce risks around modularity, scalability, and maintainability.

Key benefits in Agile & use-case-driven development:

  • Traceability — Structural elements realize use cases (e.g., classes implement use case flows).
  • Risk mitigation — Early visualization of dependencies, coupling, and layering prevents architectural technical debt.
  • Incremental refinement — Start with high-level domain models in early iterations, add detail (e.g., deployment topology) as architecture solidifies.
  • Communication — Non-technical stakeholders grasp domain vocabulary via class diagrams; architects & devs use component/deployment for infrastructure planning.
  • Code alignment — Forward/reverse/round-trip engineering in Visual Paradigm keeps models and code in sync across sprints.

The 7 Structural UML Diagrams – Quick Overview with Practical Purpose

  1. Class Diagram Models the vocabulary of the system: classes, attributes, operations, interfaces, and relationships (inheritance, association, aggregation, etc.). Most common structural diagram.
  2. Object Diagram Snapshot of instances (objects) and links at a specific moment—useful for illustrating examples or debugging runtime states.
  3. Package Diagram Organizes large models into hierarchical packages (namespaces) for modularity, configuration management, and dependency control.
  4. Component Diagram Shows software components (modules, libraries, microservices), their interfaces, and dependencies—ideal for modular/monolithic vs. microservices design.
  5. Composite Structure Diagram Details the internal structure of complex classes/components via parts, ports, and connectors—great for subsystems or collaborations.
  6. Deployment Diagram Maps software artifacts to hardware nodes (servers, devices, cloud instances) and communication paths—essential for deployment topology and scaling.
  7. Profile Diagram Defines custom extensions (stereotypes, tagged values, constraints) to tailor UML for domains (e.g., Agile stereotypes like «UserStory», «Epic»).

Lots of Practical Examples Across Domains

  • E-commerce Platform
    • Class Diagram: Domain model with Order, OrderItem, Product, Customer, Payment, ShippingAddress. Relationships: Order aggregates OrderItems, Customer places Order.
    • Component Diagram: Microservices like CatalogService, CartService, PaymentService, OrderService—showing provided/required interfaces.
    • Deployment Diagram: Frontend (React app) on CDN nodes, backend services on Kubernetes pods, database on cloud RDS instance.
    • Benefit: Early class diagram reveals missing DiscountRule class → added before implementation drift.
  • Mobile Banking App
    • Class Diagram: Account, Transaction, UserProfile, AuthenticationToken. Generalization: SavingsAccount, CheckingAccount inherit from Account.
    • Composite Structure Diagram: Internal parts of “MobileApp” component (UI Layer, Business Logic, Data Access) with ports to backend APIs.
    • Package Diagram: Packages like “com.bank.auth”, “com.bank.transactions”, “com.bank.ui” to manage dependencies.
    • Outcome: Prevents tight coupling between auth and transaction logic.
  • Healthcare Patient Management System
    • Class Diagram: Patient, Appointment, Doctor, MedicalRecord, Prescription. Associations: Patient has-many Appointments, Doctor treats Patient.
    • Profile Diagram: Custom «PHI» stereotype on sensitive classes with tagged value {confidentiality=high} for HIPAA compliance.
    • Deployment Diagram: On-prem hospital servers vs. cloud-hosted portal, showing secure connections (HTTPS, VPN).
    • Practical: Models ensure privacy constraints are architectural, not bolted on later.
  • IoT Smart Home System
    • Composite Structure Diagram: “SmartHub” with parts (SensorArray, Controller, NetworkInterface) connected via ports.
    • Component Diagram: Reusable components like “TemperatureSensor”, “LightController” with required interfaces to cloud gateway.
    • Deployment Diagram: Edge devices (Raspberry Pi nodes) connected to cloud backend.
    • Benefit: Visualizes hardware-software boundaries early.
  • Legacy Monolith to Microservices Migration
    • Package Diagram: Before/after views showing extraction of “Billing” package into separate service.
    • Component Diagram: Old monolithic JAR → new independent BillingService with REST API.
    • Class Diagram: Reverse-engineered from legacy code to understand domain before refactoring.
    • Real impact: Guides safe incremental migration without big-bang rewrite.
  • Task Management SaaS
    • Class Diagram: Board, List, Card, User, Label, Comment. Aggregation: Board contains Lists, List contains Cards.
    • Object Diagram: Example snapshot: “ProjectX Board” with specific “To Do List” containing “Implement Login” Card assigned to “John”.
    • Deployment Diagram: Multi-region cloud deployment for low-latency global access.
  • Agile Team in Visual Paradigm
    • Use Profile Diagram to create «Sprint», «BacklogItem» stereotypes.
    • Package Diagram organizes by release/sprint: “Iteration-1-Core”, “Iteration-2-Enhancements”.
    • Models evolve incrementally: start with conceptual class diagram from use cases, refine to design-level with operations.

In this module’s Practical 3, you’ll:

  • Build a logical database schema using class diagrams (entities, relationships, multiplicities).
  • Map components to nodes in deployment views.
  • Use Visual Paradigm’s semantic backplane to keep elements consistent across diagrams.

By mastering these structural diagrams, you’ll create a solid, evolvable foundation that supports use-case realization, architectural decisions, and Agile iteration—preparing for the dynamic heartbeat of behavioral diagrams in Module 4.

Articles