What is a Class Diagram?
A Class Diagram is the most commonly used UML diagram. It shows the classes in a system, their attributes, operations, and the relationships between them. It's a static structural diagram — it captures the architecture of the system at a point in time, not how it behaves over time.
Class diagrams serve as blueprints for developers. They document the system's structure and guide implementation. When someone reads your class diagram, they should understand the system's key entities and how they connect.
Class Notation
A class is represented as a rectangle divided into three compartments:
┌──────────────────────────────────┐
│ ClassName │ ← Name compartment
├──────────────────────────────────┤
│ - attribute: Type │ ← Attribute compartment
│ - anotherAttribute: Type │
│ + computedValue: Type │
├──────────────────────────────────┤
│ + operation(param): ReturnType │ ← Operation compartment
│ - helperMethod(): void │
│ # protectedMethod(): void │
└──────────────────────────────────┘
Visibility Symbols:
+ public — accessible from anywhere
- private — accessible only within the class
# protected — accessible within the class and subclasses
~ package — accessible within the same packageExample: Bank Account Class
┌──────────────────────────────────┐
│ BankAccount │
├──────────────────────────────────┤
│ - accountId: String │
│ - owner: String │
│ - balance: double │
│ - accountType: AccountType │
├──────────────────────────────────┤
│ + deposit(amount: double): void │
│ + withdraw(amount: double): void │
│ + getBalance(): double │
│ + getStatement(): List<Transaction>│
│ - validateAmount(amount): void │
│ - updateBalance(amount): void │
└──────────────────────────────────┘Relationship Types
Class diagrams show several types of relationships between classes:
1. Association (solid line)
────────────────────────
A general relationship. One class "knows about" another.
Customer ────────────── Order
(Customer places Orders)
2. Aggregation (hollow diamond)
─────────────────────────────
"Has-a" relationship where the part can exist independently.
Department ◇────────── Teacher
(Department has Teachers)
3. Composition (filled diamond)
─────────────────────────────
"Has-a" relationship where the part cannot exist without the whole.
Order ◆────────── OrderItem
(Order owns OrderItems)
4. Inheritance (hollow triangle arrow)
────────────────────────────────────
"Is-a" relationship — subclass inherits from superclass.
SavingsAccount ──────▷ BankAccount
(SavingsAccount is a BankAccount)
5. Realization (dashed line with hollow triangle)
──────────────────────────────────────────────
A class implements an interface.
- - - - - - - - - - - - ▷ Payable
(Payment implements Payable)
6. Dependency (dashed arrow)
─────────────────────────
A temporary relationship — one class uses another.
OrderHandler - - - - - ▷ EmailService
(OrderHandler uses EmailService temporarily)Multiplicity
Multiplicity indicates how many instances of one class can be associated with instances of another class. It's written as a number or range near the relationship line.
Multiplicity Notation:
1 — exactly one
0..1 — zero or one (optional)
* — zero or more (many)
1..* — one or more
0..* — zero or more
2..5 — between 2 and 5
Examples:
┌──────────────┐ 1 ┌──────────────┐
│ Customer │────────────────▶│ Account │
│ │ │ │
└──────────────┘ └──────────────┘
Customer has exactly 1 Account
┌──────────────┐ 1..* ┌──────────────┐
│ Customer │────────────────▶│ Order │
│ │ │ │
└──────────────┘ └──────────────┘
Customer has one or more Orders
┌──────────────┐ 0..* ┌──────────────┐
│ Order │────────────────▶│ OrderItem │
│ │ │ │
└──────────────┘ └──────────────┘
Order has zero or more OrderItemsComplete Class Diagram Example
Library Management System:
┌──────────────────┐ ┌──────────────────┐
│ Library │* 1│ Book │
├──────────────────┤──────────────├──────────────────┤
│ - name: String │ │ - title: String │
│ - address: String│ │ - author: String │
├──────────────────┤ │ - isbn: String │
│ + getCatalog() │ │ - isAvailable: │
│ : List<Book> │ │ boolean │
│ + addBook(book) │ ├──────────────────┤
└──────────────────┘ │ + checkOut(): │
│ boolean │
1 │ + returnBook(): │
│ │ void │
│ 1..* │ + reserve(): │
┌──────┴──────────┐ │ void │
│ Member │ └──────────────────┘
├─────────────────┤
│ - memberId: Str │ 1 ┌──────────────────┐
│ - name: String │──────────────│ Loan │
│ - email: String │ 0..* ├──────────────────┤
├─────────────────┤ │ - loanDate: Date │
│ + borrowBook() │ │ - dueDate: Date │
│ + returnBook() │ │ - returnDate:Date│
│ + getLoans() │ ├──────────────────┤
└─────────────────┘ │ + isOverdue(): │
│ boolean │
│ + calculateFine()│
│ : double │
└──────────────────┘Best Practices
Follow these guidelines when creating class diagrams:
DO:
✓ Show only classes relevant to the current design level
✓ Use meaningful names that match the domain
✓ Include multiplicities on associations
✓ Group related classes together
✓ Show key attributes and operations (not every field)
✓ Use inheritance to show "is-a" relationships
DON'T:
✗ Create diagrams with too many classes (aim for 10-15 max)
✗ Show every private attribute and method
✗ Use implementation-specific types (ArrayList instead of List)
✗ Mix design-level and code-level details
✗ Ignore visibility modifiers (+, -, #)