📘 Comprehensive Guide: Class Diagrams Across Development Stages

📘 Introduction: From Isolated Components to Connected Systems — The Evolution of Class Diagrams

In the world of software development, class diagrams are more than just static illustrations — they are living blueprints that evolve alongside the system they represent. At every stage of development, from initial requirements to post-release maintenance, the level of detail, structure, and intent behind a class diagram shifts dramatically. Yet, one common pitfall persists: isolated components.

Consider the typical payment processor class — CreditCardProcessor, PayPalProcessor, and StripeProcessor — often modeled as standalone, disconnected entities in a class diagram. While this may suffice during early design, it reveals a deeper issue: a lack of integration and behavioral clarity. These classes exist in isolation, with no clear mechanism for selection, configuration, or runtime flexibility. As a result, the design becomes rigid, hard to extend, and difficult to test.

This article explores how class diagrams should evolve across development stages — from high-level conceptual models to detailed, implementation-ready designs — and how strategic connections between components can transform a fragmented system into a cohesive, scalable architecture. We’ll focus on a real-world example: the payment processing subsystem — and show how applying the Strategy Pattern, Factory Pattern, and dependency injection can bridge the gap between isolated classes and a truly dynamic, maintainable system.

Through PlantUML diagrams and practical design insights, you’ll learn how to:

• Move beyond static class relationships.
• Model real-world behavior and runtime dynamics.
• Design systems that are flexible, extensible, and easy to evolve.

By the end, you’ll see that a well-connected class diagram isn’t just a documentation tool — it’s a vision of how your software should work.

Class diagrams are one of the most powerful UML tools for modeling object-oriented systems. Their level of detail changes significantly depending on the development stage. This guide walks you through four key stages of software development and shows how class diagrams evolve accordingly.

---

🧩 1. Stage 1: Requirements & Conceptual Design (Early Phase)

🎯 Purpose:

• Capture high-level domain concepts.

• Identify key entities and their relationships.

• Facilitate communication between stakeholders and developers.

🔍 Characteristics:

• Focus on domain entities and relationships.

• No methods or attributes (or minimal).

• Use generalization, association, aggregation, and composition.

• Avoid implementation details (e.g., access modifiers, data types).

📌 Example: E-Commerce System (Conceptual Level)

@startuml
' Conceptual Class Diagram - Stage 1: Requirements

class Customer {
  +name: String
  +email: String
}

class Product {
  +name: String
  +price: Decimal
}

class Order {
  +orderDate: Date
  +status: String
}

Customer "1" -- "0..*" Order : places
Order "1" -- "1..*" Product : contains
Product "1" -- "0..*" Order : sold in

note right of Customer
  Represents a user buying products
end note

note right of Product
  Physical or digital item for sale
end note

note right of Order
  A transaction record
end note

@enduml

✅ Use Case: Present to stakeholders, refine domain model, validate with business analysts.

---

🧱 2. Stage 2: Analysis & High-Level Design (Mid-Phase)

🎯 Purpose:

• Refine domain model into a more structured design.

• Introduce attributes, basic operations, and associations.

• Begin to identify interfaces, abstract classes, and design patterns.

🔍 Characteristics:

• Add attributes and operations (with minimal types).

• Use abstract classes and interfaces.

• Introduce multiplicity and navigability.

• Start thinking about responsibilities and cohesion.

📌 Example: E-Commerce System (Analysis Level)

@startuml
' High-Level Class Diagram - Stage 2: Analysis

@startuml
' High-Level Class Diagram - Stage 2: Analysis

abstract class Order {
  - orderID: String
  - orderDate: Date
  - status: String
  +calculateTotal(): Decimal
  +validate(): Boolean
  +save(): void
}

class Customer {
  - customerID: String
  - name: String
  - email: String
  +addOrder(order: Order): void
  +getOrders(): List<Order>
}

class Product {
  - productID: String
  - name: String
  - price: Decimal
  - stockQuantity: Integer
  +isInStock(): Boolean
  +updateStock(amount: Integer): void
}

class OrderItem {
  - quantity: Integer
  - unitPrice: Decimal
  +getSubtotal(): Decimal
}

Customer "1" -- "0..*" Order : places
Order "1" -- "1..*" OrderItem : contains
OrderItem "1" -- "1" Product : references
Product "1" -- "0..*" OrderItem : appears in

interface PaymentProcessor {
  +processPayment(amount: Decimal): Boolean
}

Order "1" -- "1" PaymentProcessor : uses

@enduml

✅ Use Case: Design review, team alignment, initial architecture decisions.

---

🔧 3. Stage 3: Detailed Design & Implementation (Late Phase)

🎯 Purpose:

• Prepare for coding.

• Define exact attributes, methods, data types, access modifiers.

• Include constraints, dependencies, associations, and composition.

• Use design patterns (e.g., Factory, Strategy, Singleton).

🔍 Characteristics:

• Full method signatures and return types.

• Use of access modifiers (+, -, #).

• Dependencies, inheritance, interfaces are fully specified.

• May include constraints (e.g., <<constraint>>).

📌 Example: E-Commerce System (Detailed Design)

@startuml
' Detailed Class Diagram - Stage 3: Implementation

@startuml
' Detailed Class Diagram - Stage 3: Implementation

class Customer {
  - customerID: String
  - name: String
  - email: String
  - address: String
  +addOrder(order: Order): void
  +getOrders(): List<Order>
  +validateEmail(): Boolean
}

class Order {
  - orderID: String
  - orderDate: Date
  - status: OrderStatus
  - total: Decimal
  +calculateTotal(): Decimal
  +validate(): Boolean
  +save(): void
  +cancel(): void
}

class OrderItem {
  - quantity: Integer
  - unitPrice: Decimal
  +getSubtotal(): Decimal
}

class Product {
  - productID: String
  - name: String
  - price: Decimal
  - stockQuantity: Integer
  +isInStock(): Boolean
  +updateStock(amount: Integer): void
  +getPrice(): Decimal
}

class PaymentProcessor {
  +processPayment(amount: Decimal): Boolean
}

class CreditCardProcessor {
  +processPayment(amount: Decimal): Boolean
}

class Payment {
  - paymentID: String
  - amount: Decimal
  - method: String
  - timestamp: Date
  +confirm(): Boolean
}

' Inheritance
Customer <|-- PremiumCustomer

' Interfaces
PaymentProcessor <|-- CreditCardProcessor
PaymentProcessor <|-- PayPalProcessor

' Associations
Customer "1" -- "0..*" Order : places
Order "1" -- "1..*" OrderItem : contains
OrderItem "1" -- "1" Product : references
Order "1" -- "1" Payment : has
PaymentProcessor "1" -- "1" Payment : processes

' Constraints
note right of Order
  Status: [Pending, Confirmed, Shipped, Cancelled]
end note

note right of Product
  Stock must be > 0 to be sold
end note

@enduml

✅ Use Case: Developer handoff, code generation, design documentation.

---

🛠️ 4. Stage 4: Maintenance & Evolution (Post-Release)

🎯 Purpose:

• Reflect real-world changes in the system.

• Document refactoring, deprecations, new features.

• Support technical debt tracking and system understanding.

🔍 Characteristics:

• May include deprecated classes/methods.

• Show new classes, renamed elements, removed components.

• Use stereotypes (<<deprecated>>, <<singleton>>, <<factory>>).

• Often simplified for readability.

📌 Example: E-Commerce System (Maintenance Stage)

@startuml
‘ Revamped Payment System: Strategy + Factory Pattern

@startuml
‘ Revamped Payment System: Strategy + Factory Pattern

‘ Interface
class PaymentProcessor {
+processPayment(amount: Decimal): Boolean
}

‘ Concrete Strategies
class CreditCardProcessor {
+processPayment(amount: Decimal): Boolean
}

class PayPalProcessor {
+processPayment(amount: Decimal): Boolean
}

class StripeProcessor {
+processPayment(amount: Decimal): Boolean
}

‘ Factory Pattern
class PaymentProcessorFactory {
+createProcessor(type: String): PaymentProcessor
+getAvailableTypes(): List<String>
}

‘ Service that uses the strategy
class OrderService {
– processor: PaymentProcessor
+createOrder(customer: Customer, items: List<OrderItem>): Order
+setPaymentProcessor(processor: PaymentProcessor): void
}

‘ Payment entity
class Payment {
– paymentID: String
– amount: Decimal
– method: String
– timestamp: Date
+confirm(): Boolean
}

‘ Customer and Order (simplified)
class Customer {
– customerID: String
– name: String
– email: String
+addOrder(order: Order): void
+getOrders(): List<Order>
}

class Order {
– orderID: String
– orderDate: Date
– status: OrderStatus
– total: Decimal
+calculateTotal(): Decimal
+validate(): Boolean
+save(): void
+cancel(): void
}

‘ Stereotypes for clarity
PaymentProcessor <<interface>>
CreditCardProcessor <<strategy>>
PayPalProcessor <<strategy>>
StripeProcessor <<strategy>>
PaymentProcessorFactory <<factory>>
OrderService <<service>>

‘ Inheritance: Strategy Pattern
CreditCardProcessor <|– PaymentProcessor
PayPalProcessor <|– PaymentProcessor
StripeProcessor <|– PaymentProcessor

‘ Factory creates processors
PaymentProcessorFactory “1” — “1” PaymentProcessor : creates

‘ OrderService uses a processor (dependency injection)
OrderService “1” — “1” PaymentProcessor : uses

‘ OrderService uses the factory to set processor
OrderService “1” — “1” PaymentProcessorFactory : configures via

‘ Payment depends on processor
Payment “1” — “1” PaymentProcessor : uses

‘ Associations
Customer “1” — “0..*” Order : places
Order “1” — “1..*” OrderItem : contains
OrderItem “1” — “1” Product : references
Order “1” — “1” Payment : has

‘ Constraints
note right of Order
Status: [Pending, Confirmed, Shipped, Cancelled]
end note

note right of Payment
Method: “CreditCard”, “PayPal”, “Stripe”
end note

note right of PaymentProcessorFactory
Supported types: “CreditCard”, “PayPal”, “Stripe”
Can be extended without modifying OrderService
end note

@enduml

✅ Use Case: Onboarding new developers, system refactoring, audit trails.

---

🔄 Summary: Evolution of Class Diagrams

Stage	Focus	Detail Level	Key Elements
1. Requirements	Domain Concepts	High-Level	Entities, associations
2. Analysis	System Structure	Medium	Attributes, operations, interfaces
3. Implementation	Code Ready	High	Types, access modifiers, patterns
4. Maintenance	System Evolution	Adaptive	Stereotypes, deprecations, simplification

---

🛠️ Tips for Using PlantUML

• Use @startuml and @enduml to wrap diagrams.

• Use <<stereotype>> for design patterns or metadata.

• Use note right of for documentation.

• Use +, -, # for visibility (public, private, protected).

• Use <<interface>>, <<abstract>>, <<singleton>> for clarity.

• Generate images via PlantUML Online or IDE plugins (VS Code, IntelliJ).

---

📚 Final Thoughts

Class diagrams are not static — they evolve with the project. Use them strategically:

• Early: Communicate with non-technical stakeholders.

• Mid: Align developers on architecture.

• Late: Guide implementation and code quality.

• Post-Release: Maintain system knowledge.

✅ Pro Tip: Version-control your PlantUML files alongside code — they’re living documentation!

---

✅ Conclusion: Designing Not Just Classes, But Systems

Class diagrams are more than diagrams — they are maps of intent, blueprints of collaboration, and living records of architectural evolution. As we’ve seen, their value isn’t in their initial form, but in how they adapt across the development lifecycle — from the high-level abstractions of requirements to the precise, implementation-ready models of late-stage design.

The journey from isolated processor classes to a connected, strategy-driven system illustrates a fundamental truth: good design isn’t just about defining components — it’s about defining how they work together. When CreditCardProcessor, PayPalProcessor, and StripeProcessor are treated as interchangeable strategies — orchestrated by a factory and injected into services — the diagram ceases to be a static snapshot. It becomes a dynamic model of flexibility, scalability, and maintainability.

By using patterns like Strategy, Factory, and Dependency Injection, we transform isolated classes into a cohesive, extensible ecosystem. This isn’t just about better diagrams — it’s about building better software. It enables teams to:

• Add new payment methods without touching existing code.
• Test behavior in isolation.
• Evolve systems with confidence, even years after launch.

Ultimately, the most powerful class diagrams are not those that show every field and method in detail — but those that tell a story: a story of collaboration, adaptability, and forward-thinking design.

So as you sketch your next class diagram, ask yourself:

Are my classes just defined — or are they connected?
Are they isolated — or are they part of a system that can grow?

Because in the end, the best class diagrams don’t just describe what the system is — they inspire how it should become.