Design Patterns UML Basics
UML stands for Unified Modeling Language. It is a standard way to draw diagrams that describe how software is structured and how its parts interact. Before learning individual design patterns, understanding basic UML notation helps you read pattern diagrams without confusion.
You do not need to memorise every UML symbol. Knowing six core notations covers everything used in design pattern diagrams.
What a UML Class Diagram Shows
A class diagram is the most common diagram type used with design patterns. It shows classes (blueprints for objects), their data and actions, and the relationships between them.
┌─────────────────────┐ │ ClassName │ ← Class name (top section) ├─────────────────────┤ │ - privatefield │ ← Fields / properties (middle section) │ + publicfield │ ├─────────────────────┤ │ + publicMethod() │ ← Methods / actions (bottom section) │ - privateMethod() │ └─────────────────────┘
Visibility Symbols
- + means public — any class can see and use it.
- - means private — only the class itself can use it.
- # means protected — only the class and its children can use it.
Six Core UML Relationships
1. Inheritance (Generalisation)
One class extends another. The child class gets all the parent's features and can add its own.
┌──────────────┐
│ Animal │
│ + speak() │
└──────┬───────┘
│ ◁───── hollow triangle arrow = "extends"
┌──────┴───────┐
│ Dog │
│ + fetch() │
└──────────────┘
Dog inherits speak() from Animal and adds its own fetch() method.
2. Interface Implementation (Realisation)
A class promises to provide the methods defined in an interface.
«interface»
┌──────────────┐
│ Printable │
│ + print() │
└──────┬───────┘
╎ ◁─── dashed line + hollow triangle = "implements"
┌──────┴───────┐
│ Invoice │
│ + print() │
└──────────────┘
Invoice must provide a real print() method to fulfil the Printable contract.
3. Association
One class uses or knows about another class. A solid line connects them.
┌──────────┐ ┌──────────┐ │ Driver │──────────│ Car │ └──────────┘ └──────────┘ A Driver is associated with a Car. They are independent — one can exist without the other.
4. Aggregation (Has-A, weak)
One class contains references to other objects, but those objects can live on their own.
┌──────────┐ ◇─────┌──────────┐ │ Playlist │ │ Song │ └──────────┘ └──────────┘ A Playlist has Songs, but a Song can exist without any Playlist. ◇ = hollow diamond on the "owner" side
5. Composition (Has-A, strong)
One class owns another so completely that when the owner is destroyed, the owned part is destroyed too.
┌──────────┐ ◆─────┌──────────┐ │ House │ │ Room │ └──────────┘ └──────────┘ A Room only exists as part of a House. If the House is demolished, the Rooms disappear too. ◆ = filled diamond on the "owner" side
6. Dependency (Uses)
One class temporarily uses another, usually as a method parameter or local variable.
┌──────────┐ - - - → ┌──────────┐ │ Report │ │ Printer │ └──────────┘ └──────────┘ Report uses Printer momentarily to print itself. It does not hold on to it permanently. Dashed arrow = dependency
All Six Relationships in One Reference Diagram
RELATIONSHIP ARROW STYLE MEANING ───────────────── ────────────────────── ─────────────────────────── Inheritance ───────▷ "is a" (child extends parent) Implementation - - - -▷ "fulfils" (class implements interface) Association ────────── "knows about" Aggregation ◇────────── "has, but can share" Composition ◆────────── "owns completely" Dependency - - - - → "uses temporarily"
Reading Multiplicity Labels
Numbers on relationship lines show how many objects are involved on each side.
┌──────────┐ 1 * ┌──────────┐ │ Order │──────────────│OrderItem │ └──────────┘ └──────────┘ 1 = exactly one * = zero or more 1..* = one or more 0..1 = zero or one One Order contains zero or more OrderItems.
Interfaces and Abstract Classes in UML
«interface» Abstract class
┌──────────────────┐ ┌──────────────────┐
│ Serialisable │ │ AbstractLogger │
├──────────────────┤ ├──────────────────┤
│ + serialise() │ │ + log() │ ← italic = abstract method
└──────────────────┘ │ + formatMsg() │
└──────────────────┘
«interface» label → pure contract, no code inside
Italic method name → must be overridden by child class
A Complete Mini-Diagram to Practice Reading
«interface»
┌────────────────┐
│ PaymentMethod │
│ + pay(amount) │
└───────┬────────┘
╎
╎ implements
╎
┌───────┴────────┐ ┌────────────────┐
│ CreditCard │◆────────│ CardDetails │
│ + pay(amount) │ owns │ - number │
│ - cardDetails │ │ - expiry │
└───────┬────────┘ └────────────────┘
│
│ uses (dependency)
▼
┌───────────────┐
│ PaymentGateway│
│ + charge() │
└───────────────┘
Reading this diagram: CreditCard implements the PaymentMethod interface. It owns a CardDetails object (composition — details belong to the card). To process a payment, it temporarily uses PaymentGateway (dependency).
Notes and Stereotypes
┌──────────────┐ ┌─────────────────────────────┐
│ Customer │────┤ Note: VIP customers get │
└──────────────┘ │ priority queue assignment │
└─────────────────────────────┘
Notes are rectangular boxes with folded corners — they add comments to a diagram.
Stereotypes like «interface» or «abstract» label a class's role.
Key Takeaways
- A class box has three sections: name, fields, and methods.
- Visibility symbols (+, -, #) show who can access each member.
- Six relationships cover almost everything: inheritance, implementation, association, aggregation, composition, and dependency.
- Multiplicity numbers tell you how many objects participate on each side.
- Reading a UML diagram from top to bottom follows the hierarchy from parent to child.