Design Patterns in UML

Complete guide to Modeling Design Patterns in UML: learn how to represent Gang of Four patterns, architectural patterns, and common design patterns using UML diagrams. Master pattern modeling techniques.

Table of Contents

1. What are Design Patterns?

Design patterns are reusable solutions to common problems in software design. They represent best practices evolved over time and provide a common vocabulary for discussing design solutions.

UML is an excellent tool for modeling design patterns because:

  • Patterns involve relationships between classes/components
  • UML diagrams clearly show pattern structure
  • Patterns can be documented and communicated effectively
  • UML helps teams understand and apply patterns consistently

The Gang of Four (GoF) patterns are categorized into:

  • Creational: Object creation patterns
  • Structural: Object composition patterns
  • Behavioral: Object interaction patterns

2. Creational Patterns

2.1 Singleton Pattern

Ensures a class has only one instance and provides global access.

@startuml class Singleton { - instance : Singleton {static} + getInstance() : Singleton {static} - Singleton() } note right of Singleton Private static instance variable Private constructor Public static getInstance() method end note @enduml

Key elements:

  • Private static instance variable
  • Private constructor
  • Public static getInstance() method

2.2 Factory Pattern

Creates objects without specifying the exact class.

@startuml abstract class Product class ProductA class ProductB class Factory { + create() : Product } Product <|-- ProductA Product <|-- ProductB Factory ..> Product : creates @enduml

2.3 Builder Pattern

Constructs complex objects step by step.

@startuml class Director { + construct() } abstract class Builder { + buildPart() } class ConcreteBuilder1 class ConcreteBuilder2 class Product Director --> Builder Builder <|-- ConcreteBuilder1 Builder <|-- ConcreteBuilder2 ConcreteBuilder1 ..> Product ConcreteBuilder2 ..> Product @enduml

3. Structural Patterns

3.1 Adapter Pattern

Allows incompatible interfaces to work together.

@startuml class Client interface Target { + request() } class Adapter { + request() } class Adaptee { + specificReq() } Client --> Target Target <|.. Adapter Adapter --> Adaptee @enduml

3.2 Decorator Pattern

Adds behavior to objects dynamically.

@startuml abstract class Component { + operation() } class ConcreteComponent { + operation() } abstract class Decorator { + operation() - component : Component } class ConcreteDecorator1 { + operation() } class ConcreteDecorator2 { + operation() } Component <|-- ConcreteComponent Component <|-- Decorator Decorator <|-- ConcreteDecorator1 Decorator <|-- ConcreteDecorator2 Decorator *-- Component @enduml

3.3 Facade Pattern

Provides a simplified interface to a complex subsystem.

@startuml class Client class Facade { + operation() } class Subsystem1 class Subsystem2 class Subsystem3 Client --> Facade Facade --> Subsystem1 Facade --> Subsystem2 Facade --> Subsystem3 @enduml

3.4 Proxy Pattern

Provides a surrogate or placeholder for another object.

@startuml class Client interface Subject { + request() } class Proxy { + request() - realSubject : RealSubject } class RealSubject { + request() } Client --> Subject Subject <|.. Proxy Subject <|.. RealSubject Proxy --> RealSubject @enduml

4. Behavioral Patterns

4.1 Observer Pattern

Defines a one-to-many dependency between objects.

@startuml class Subject { + attach(Observer) + detach(Observer) + notify() - observers : List } interface Observer { + update() } class ConcreteSubject { + getState() } class ConcreteObserver { + update() } Subject <|-- ConcreteSubject Observer <|.. ConcreteObserver Subject "1" o-- "*" Observer @enduml

4.2 Strategy Pattern

Defines a family of algorithms and makes them interchangeable.

@startuml class Context { + execute() - strategy : Strategy } interface Strategy { + algorithm() } class StrategyA { + algorithm() } class StrategyB { + algorithm() } Context --> Strategy Strategy <|.. StrategyA Strategy <|.. StrategyB @enduml

4.3 Command Pattern

Encapsulates a request as an object.

@startuml class Invoker { + execute() - command : Command } abstract class Command { + execute() } class ConcreteCommand { + execute() - receiver : Receiver } class Receiver { + action() } Invoker --> Command Command <|-- ConcreteCommand ConcreteCommand --> Receiver @enduml

4.4 Template Method Pattern

Defines the skeleton of an algorithm.

@startuml abstract class AbstractClass { + templateMethod() + step1() {abstract} + step2() {abstract} } class ConcreteClass1 { + step1() + step2() } class ConcreteClass2 { + step1() + step2() } AbstractClass <|-- ConcreteClass1 AbstractClass <|-- ConcreteClass2 @enduml

5. Architectural Patterns

5.1 MVC (Model-View-Controller)

Separates application into three interconnected components.

@startuml class View { + display() } class Controller { + handleInput() } class Model { + getData() + setData() } View --> Controller : uses Controller --> Model : manipulates View ..> Model : observes @enduml

5.2 Layered Architecture

Organizes system into layers with specific responsibilities.

@startuml package "Presentation Layer" { class Controller } package "Business Layer" { class Service } package "Data Layer" { class Repository } Controller ..> Service : depends on Service ..> Repository : depends on @enduml

5.3 Repository Pattern

Abstracts data access logic.

@startuml class BusinessLogic interface Repository { + findById() + save() } class DatabaseRepository { + findById() + save() } class InMemoryRepository { + findById() + save() } BusinessLogic --> Repository Repository <|.. DatabaseRepository Repository <|.. InMemoryRepository @enduml

6. Pattern Modeling Best Practices

6.1 Use Stereotypes

  • Mark pattern roles with stereotypes
  • Use <>, <>, etc.
  • Clarify pattern intent
  • Document pattern usage

6.2 Show Relationships

  • Clearly show inheritance, composition, dependencies
  • Use appropriate relationship types
  • Show pattern structure accurately
  • Include role names when helpful

6.3 Document Pattern Intent

  • Add notes explaining why the pattern is used
  • Document pattern benefits
  • Explain pattern-specific details
  • Reference pattern documentation

6.4 Show Pattern Variations

  • Model pattern variations when relevant
  • Show how patterns are adapted
  • Document pattern combinations
  • Illustrate pattern evolution

6.5 Sequence Diagrams for Behavioral Patterns

  • Use sequence diagrams to show pattern interactions
  • Illustrate how patterns work dynamically
  • Show message flow in patterns
  • Complement structural diagrams

7. Conclusion

Modeling design patterns in UML helps teams understand, communicate, and apply patterns consistently. UML diagrams make pattern structure clear and help ensure patterns are implemented correctly.

Whether modeling GoF patterns or architectural patterns, UML provides the notation needed to represent pattern structure, relationships, and behavior effectively. Combined with good documentation, UML pattern models become valuable design assets.

Next Topic: Code Generation - Learn about forward engineering, reverse engineering, and Model-Driven Architecture.

Post a Comment

0 Comments