Translating UML to Code - From Design to Code | OneNoughtOne

Low-Level DesignFrom Design to Code

From Design to Code

LevelAdvanced

Duration75 mins

TopicFrom Design to Code

1 / 4

Translating UML to Code

The Bridge Between Design and Reality

You've spent 20 minutes in an LLD interview carefully designing a system. Your class diagram is elegant—clean hierarchies, well-defined relationships, appropriate use of design patterns. The interviewer nods approvingly and says: "Great design. Now implement it."

This is where many candidates falter. The transition from visual notation to executable code isn't merely typing what you see. It requires understanding how each UML element maps to language constructs, the order in which to implement components, and how to adapt abstract designs to concrete programming language idioms.

This page provides a systematic, repeatable methodology for translating any UML design into production-quality code. By mastering this translation process, you'll be able to confidently move from whiteboard diagrams to working implementations—whether in an interview setting or real-world software development.

What You Will Learn

By the end of this page, you will understand how to systematically translate UML class diagrams to code, map associations, aggregations, and compositions to object relationships, implement inheritance hierarchies and interface contracts, and handle visibility modifiers and cardinality constraints. You'll leave with a mental checklist that makes UML-to-code translation mechanical rather than ad-hoc.

Why UML-to-Code Translation Matters

UML diagrams serve as a communication and planning tool—they capture design decisions in a language-agnostic visual notation. But diagrams don't run. Eventually, every design must become code.

The translation process is where design intent meets implementation reality. Done poorly, the resulting code may technically work but miss the design's purpose—creating tight coupling where the diagram specified loose coupling, or using concrete classes where interfaces were intended.

The cost of poor translation:

Common Translation Failures

•Lost flexibility — Associations become hard-coded dependencies, losing the runtime configurability the design intended
•Broken encapsulation — Visibility modifiers (private, protected) are ignored, exposing internal state that should be hidden
•Incorrect cardinality — One-to-many relationships implemented as one-to-one, or vice versa, causing data integrity issues
•Missing polymorphism — Abstract classes and interfaces reduced to concrete implementations, eliminating extensibility
•Inverted control — Dependency directions flipped, creating circular dependencies or violating dependency inversion

When done well, UML-to-code translation preserves the design's qualities:

Modularity — Each class remains a cohesive unit with a single responsibility
Flexibility — Interfaces and abstract classes enable extension without modification
Testability — Dependencies are injectable, enabling mock substitution in tests
Readability — Code structure mirrors diagram structure, making the design visible in the implementation

The goal isn't blind, mechanical copying. It's faithful translation that adapts to language idioms while preserving the design's architectural properties.

The Principal Engineer's Perspective

Senior engineers treat UML diagrams as specifications, not suggestions. Every arrow, every visibility modifier, every cardinality annotation was chosen deliberately. Ignoring these details during implementation is equivalent to ignoring requirements—it creates technical debt that compounds over time.

UML Class Diagram Elements and Their Code Mappings

Before we translate, let's establish a comprehensive mapping between UML notation and code constructs. Each element in a class diagram has a direct, systematic translation.

The Class Box:

A UML class is represented as a three-compartment rectangle:

Top compartment: Class name (italic for abstract classes, «interface» stereotype for interfaces)
Middle compartment: Attributes (fields/properties)
Bottom compartment: Operations (methods)

UML Visibility Modifiers to Code
UML Symbol	Visibility	Java/C#/TypeScript	Access Level
`+`	Public	`public`	Accessible from anywhere
`-`	Private	`private`	Accessible only within the class
`#`	Protected	`protected`	Accessible in class and subclasses
`~`	Package/Internal	`internal` (C#) / default (Java)	Accessible within same package/assembly

Attribute Syntax:

UML attributes follow the pattern: visibility name : type [multiplicity] = defaultValue

UML Notation	Code Translation
`- balance : decimal`	`private decimal balance;`
`+ name : string = ""`	`public string name = "";`
`# items : Product [*]`	`protected List<Product> items;`
`- createdAt : DateTime [0..1]`	`private DateTime? createdAt;` (nullable)

Operation (Method) Syntax:

UML operations follow: visibility name(parameters) : returnType

UML Notation	Code Translation
`+ calculateTotal() : decimal`	`public decimal CalculateTotal() { }`
`- validate(input : string) : bool`	`private bool Validate(string input) { }`
`# onStateChanged() : void`	`protected void OnStateChanged() { }`
`+ findById(id : int) : User [0..1]`	`public User? FindById(int id) { }`

UML Class Translation Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// UML Class:
// ┌────────────────────────────────────┐
// │         «abstract» Account          │
// ├────────────────────────────────────┤
// │ - accountId: string                │
// │ - balance: decimal                 │
// │ # transactions: Transaction [*]   │
// ├────────────────────────────────────┤
// │ + deposit(amount: decimal): void   │
// │ + withdraw(amount: decimal): bool  │
// │ # recordTransaction(t: Trans): void│
// │ + getBalance(): decimal            │
// └────────────────────────────────────┘
 
abstract class Account {
    // Private attributes - dash (-) in UML
    private readonly accountId: string;
    private balance: number;
    
    // Protected attribute - hash (#) in UML, [*] means collection
    protected transactions: Transaction[] = [];
 
    constructor(accountId: string, initialBalance: number = 0) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
 
    // Public methods - plus (+) in UML
    public deposit(amount: number): void {
        if (amount <= 0) {
            throw new Error("Deposit amount must be positive");
        }
        this.balance += amount;
        this.recordTransaction(new Transaction("DEPOSIT", amount));
    }
 
    public withdraw(amount: number): boolean {
        if (amount <= 0 || amount > this.balance) {
            return false;
        }
        this.balance -= amount;
        this.recordTransaction(new Transaction("WITHDRAWAL", amount));
        return true;
    }
 
    // Protected method - hash (#) in UML
    protected recordTransaction(transaction: Transaction): void {
        this.transactions.push(transaction);
    }
 
    public getBalance(): number {
        return this.balance;
    }
 
    // Abstract method (from abstract class)
    public abstract calculateInterest(): number;
}
 
// Concrete implementation
class SavingsAccount extends Account {
    private readonly interestRate: number;
 
    constructor(accountId: string, initialBalance: number, interestRate: number) {
        super(accountId, initialBalance);
        this.interestRate = interestRate;
    }
 
    public calculateInterest(): number {
        return this.getBalance() * this.interestRate;
    }
}

Translating UML Relationships to Code

Relationships between classes are the heart of any design. UML defines several relationship types, each with distinct implementation semantics.

The Five Core Relationships:

UML Relationship Types and Implementation
Relationship	UML Symbol	Meaning	Code Pattern
Association	Solid line	Uses or knows about	Field reference
Aggregation	Open diamond	Has-a (shared lifecycle)	Field reference (nullable)
Composition	Filled diamond	Has-a (owned lifecycle)	Field reference (created internally)
Inheritance	Open arrow (to parent)	Is-a	`extends` / `:`
Realization	Dashed open arrow	Implements interface	`implements` / `:`
Dependency	Dashed line with arrow	Temporarily uses	Parameter or local variable

Deep Dive: Association vs. Aggregation vs. Composition

These three relationships are frequently confused, but have distinct implementation implications:

Association (simple solid line): Two classes are related and can interact. Neither owns the other.

Aggregation (open diamond ◇): "Has-a" relationship where the part can exist independently of the whole. The whole doesn't control the part's lifecycle.

Composition (filled diamond ◆): "Has-a" relationship where the part cannot exist without the whole. The whole creates and destroys the part.

Relationship Implementations
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
// ================================================
// ASSOCIATION: Simple "knows about" relationship
// UML: Order ───────────> Customer
// ================================================
 
class Order {
    // Association: Order knows about Customer
    // Customer exists independently, passed in from outside
    private customer: Customer;
    
    constructor(customer: Customer) {
        this.customer = customer;
    }
    
    getCustomerEmail(): string {
        return this.customer.getEmail();
    }
}
 
// ================================================
// AGGREGATION: "Has-a" with independent lifecycle
// UML: Department ◇───────> Employee [*]
// Diamond on Department side, employees can exist without dept
// ================================================
 
class Department {
    private name: string;
    // Aggregation: Department has Employees
    // Employees exist independently and can belong to other departments
    private employees: Employee[] = [];
    
    constructor(name: string) {
        this.name = name;
    }
    
    // Employees are added/removed, not created/destroyed
    addEmployee(employee: Employee): void {
        this.employees.push(employee);
    }
    
    removeEmployee(employee: Employee): void {
        const index = this.employees.indexOf(employee);
        if (index > -1) {
            this.employees.splice(index, 1);
        }
        // Note: employee continues to exist after removal
    }
}
 
// ================================================
// COMPOSITION: "Has-a" with owned lifecycle
// UML: House ◆───────> Room [1..*]
// Filled diamond on House side, rooms can't exist without house
// ================================================
 
class House {
    private address: string;
    // Composition: House owns Rooms
    // Rooms are created by House and can't exist independently
    private readonly rooms: Room[] = [];
    
    constructor(address: string, roomCount: number) {
        this.address = address;
        // House creates its rooms - they can't exist without the house
        for (let i = 0; i < roomCount; i++) {
            this.rooms.push(new Room(`Room ${i + 1}`, this));
        }
    }
    
    getRooms(): ReadonlyArray<Room> {
        return this.rooms;
    }
    
    // When house is destroyed, rooms are automatically destroyed
    // (no explicit cleanup needed in garbage-collected languages)
}
 
class Room {
    private name: string;
    private readonly house: House; // Back-reference to parent
    
    constructor(name: string, house: House) {
        this.name = name;
        this.house = house;
    }
}
 
// ================================================
// INHERITANCE: "Is-a" relationship
// UML: SavingsAccount ──────▷ Account
// Open arrow pointing to parent class
// ================================================
 
abstract class Account {
    protected balance: number;
    
    constructor(initialBalance: number) {
        this.balance = initialBalance;
    }
    
    abstract calculateInterest(): number;
}
 
class SavingsAccount extends Account {
    private interestRate: number;
    
    constructor(initialBalance: number, interestRate: number) {
        super(initialBalance);
        this.interestRate = interestRate;
    }
    
    calculateInterest(): number {
        return this.balance * this.interestRate;
    }
}
 
// ================================================
// REALIZATION: Implementing an interface
// UML: EmailNotifier - - - - -▷ «interface» NotificationService
// Dashed line with open arrow to interface
// ================================================
 
interface NotificationService {
    send(recipient: string, message: string): Promise<void>;
    validateRecipient(recipient: string): boolean;
}
 
class EmailNotifier implements NotificationService {
    async send(recipient: string, message: string): Promise<void> {
        // Implementation details
        console.log(`Sending email to ${recipient}: ${message}`);
    }
    
    validateRecipient(recipient: string): boolean {
        return recipient.includes('@');
    }
}
 
// ================================================
// DEPENDENCY: Temporary usage
// UML: ReportGenerator - - - -> DataFormatter
// Dashed line with arrow (weakest relationship)
// ================================================
 
class ReportGenerator {
    // No field reference to DataFormatter
    
    generateReport(data: object[]): string {
        // Dependency: uses DataFormatter temporarily
        // Formatter is a parameter, not a stored reference
        const formatter = new DataFormatter();
        return formatter.format(data);
    }
}

Navigability Matters

In UML, an arrow on an association indicates navigability—which direction the relationship can be traversed. A unidirectional arrow means only one class holds a reference to the other. A bidirectional association (or no arrows) means both classes hold references. This affects your implementation: unidirectional is simpler but sometimes bidirectional is required for certain operations.

Handling Multiplicity and Cardinality

Multiplicity in UML specifies how many instances of one class relate to instances of another class. Getting this wrong causes runtime errors or data integrity issues.

Common Multiplicity Notations:

UML Multiplicity to Code Mapping
Multiplicity	Meaning	Code Structure	Validation Required
`1`	Exactly one	Required field reference	Non-null check
`0..1`	Zero or one (optional)	Nullable field	Null handling
`` or `0..`	Zero or more	Collection/List	Empty collection OK
`1..*`	One or more	Collection (non-empty)	At least one element
`n..m`	Range (n to m)	Collection with size validation	Min/max size checks

Multiplicity Implementation Patterns
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
// ================================================
// MULTIPLICITY: [1] - Exactly one (required)
// UML: Order ──────────[1]──> PaymentMethod
// ================================================
 
class Order {
    // Multiplicity [1]: Exactly one, cannot be null
    private readonly paymentMethod: PaymentMethod;
    
    constructor(paymentMethod: PaymentMethod) {
        // Enforce multiplicity constraint
        if (!paymentMethod) {
            throw new Error("PaymentMethod is required");
        }
        this.paymentMethod = paymentMethod;
    }
}
 
// ================================================
// MULTIPLICITY: [0..1] - Zero or one (optional)
// UML: User ──────────[0..1]──> ProfilePhoto
// ================================================
 
class User {
    private name: string;
    // Multiplicity [0..1]: Optional, can be null
    private profilePhoto: ProfilePhoto | null = null;
    
    constructor(name: string) {
        this.name = name;
    }
    
    setProfilePhoto(photo: ProfilePhoto | null): void {
        this.profilePhoto = photo;
    }
    
    hasProfilePhoto(): boolean {
        return this.profilePhoto !== null;
    }
}
 
// ================================================
// MULTIPLICITY: [*] or [0..*] - Zero or more
// UML: ShoppingCart ──────────[*]──> CartItem
// ================================================
 
class ShoppingCart {
    // Multiplicity [*]: Zero or more
    private items: CartItem[] = [];
    
    addItem(item: CartItem): void {
        this.items.push(item);
    }
    
    removeItem(itemId: string): boolean {
        const index = this.items.findIndex(i => i.getId() === itemId);
        if (index > -1) {
            this.items.splice(index, 1);
            return true;
        }
        return false;
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
}
 
// ================================================
// MULTIPLICITY: [1..*] - One or more (non-empty)
// UML: Playlist ──────────[1..*]──> Song
// ================================================
 
class Playlist {
    private name: string;
    // Multiplicity [1..*]: At least one required
    private readonly songs: Song[];
    
    constructor(name: string, initialSong: Song) {
        this.name = name;
        // Enforce at least one song
        if (!initialSong) {
            throw new Error("Playlist must have at least one song");
        }
        this.songs = [initialSong];
    }
    
    addSong(song: Song): void {
        this.songs.push(song);
    }
    
    removeSong(songId: string): boolean {
        // Maintain [1..*] constraint
        if (this.songs.length <= 1) {
            return false; // Cannot remove the last song
        }
        
        const index = this.songs.findIndex(s => s.getId() === songId);
        if (index > -1) {
            this.songs.splice(index, 1);
            return true;
        }
        return false;
    }
}
 
// ================================================
// MULTIPLICITY: [2..5] - Specific range
// UML: Team ──────────[2..5]──> Player
// ================================================
 
class Team {
    private static readonly MIN_PLAYERS = 2;
    private static readonly MAX_PLAYERS = 5;
    
    private name: string;
    private readonly players: Player[];
    
    constructor(name: string, initialPlayers: Player[]) {
        // Enforce range constraint
        if (initialPlayers.length < Team.MIN_PLAYERS) {
            throw new Error(`Team requires at least ${Team.MIN_PLAYERS} players`);
        }
        if (initialPlayers.length > Team.MAX_PLAYERS) {
            throw new Error(`Team cannot have more than ${Team.MAX_PLAYERS} players`);
        }
        
        this.name = name;
        this.players = [...initialPlayers];
    }
    
    addPlayer(player: Player): boolean {
        if (this.players.length >= Team.MAX_PLAYERS) {
            return false; // At maximum capacity
        }
        this.players.push(player);
        return true;
    }
    
    removePlayer(playerId: string): boolean {
        if (this.players.length <= Team.MIN_PLAYERS) {
            return false; // At minimum capacity
        }
        
        const index = this.players.findIndex(p => p.getId() === playerId);
        if (index > -1) {
            this.players.splice(index, 1);
            return true;
        }
        return false;
    }
    
    canAddPlayer(): boolean {
        return this.players.length < Team.MAX_PLAYERS;
    }
    
    canRemovePlayer(): boolean {
        return this.players.length > Team.MIN_PLAYERS;
    }
}

Multiplicity Validation Is Not Optional

In interviews and production code alike, ignoring multiplicity constraints is a red flag. If a UML diagram shows [1..*], your code must enforce that the collection is never empty. If it shows [1], the reference must never be null. Failing to implement these constraints means the code doesn't match the design.

Translating Interfaces and Abstract Classes

Interfaces and abstract classes are the cornerstones of flexible design. They define contracts that concrete classes must fulfill, enabling polymorphism and dependency injection.

The Key Distinction:

Aspect	Interface	Abstract Class
UML Notation	«interface» stereotype	Italic class name
Methods	All abstract (traditionally)	Mix of abstract and concrete
State	No instance fields (traditionally)	Can have fields
Inheritance	Multiple implementation allowed	Single inheritance only
Purpose	Define contract (what)	Provide partial implementation (how)

Modern Considerations:

TypeScript interfaces can have optional methods
Java 8+ interfaces can have default implementations
C# 8+ interfaces can have default implementations

These blur the traditional distinction, but the conceptual difference remains: interfaces define contracts; abstract classes provide skeletal implementations.

Interface and Abstract Class Patterns
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
// ================================================
// INTERFACE (from UML «interface» stereotype)
// Defines pure contract - what operations are available
// ================================================
 
// UML:
// ┌──────────────────────────────────┐
// │     «interface» PaymentGateway   │
// ├──────────────────────────────────┤
// │ + processPayment(amt): Result    │
// │ + refund(txnId): Result          │
// │ + validateCard(card): bool       │
// └──────────────────────────────────┘
 
interface PaymentGateway {
    processPayment(amount: number, cardToken: string): Promise<PaymentResult>;
    refund(transactionId: string, amount?: number): Promise<RefundResult>;
    validateCard(cardToken: string): Promise<boolean>;
}
 
// Multiple implementations of the interface
class StripeGateway implements PaymentGateway {
    async processPayment(amount: number, cardToken: string): Promise<PaymentResult> {
        // Stripe-specific implementation
        return { success: true, transactionId: `stripe_${Date.now()}` };
    }
    
    async refund(transactionId: string, amount?: number): Promise<RefundResult> {
        return { success: true };
    }
    
    async validateCard(cardToken: string): Promise<boolean> {
        return cardToken.startsWith('tok_');
    }
}
 
class PayPalGateway implements PaymentGateway {
    async processPayment(amount: number, cardToken: string): Promise<PaymentResult> {
        // PayPal-specific implementation
        return { success: true, transactionId: `paypal_${Date.now()}` };
    }
    
    async refund(transactionId: string, amount?: number): Promise<RefundResult> {
        return { success: true };
    }
    
    async validateCard(cardToken: string): Promise<boolean> {
        return cardToken.startsWith('pp_');
    }
}
 
// ================================================
// ABSTRACT CLASS (from UML italic class name)
// Provides partial implementation - template method pattern
// ================================================
 
// UML:
// ┌────────────────────────────────────────┐
// │    «abstract» NotificationSender       │
// ├────────────────────────────────────────┤
// │ - recipientValidator: Validator        │
// │ # retryCount: int = 3                  │
// ├────────────────────────────────────────┤
// │ + send(msg): void                      │
// │ # formatMessage(msg): string    (abs)  │
// │ # doSend(formatted): bool      (abs)   │
// │ - logAttempt(success): void            │
// └────────────────────────────────────────┘
 
abstract class NotificationSender {
    private recipientValidator: RecipientValidator;
    protected retryCount: number = 3;
    
    constructor(validator: RecipientValidator) {
        this.recipientValidator = validator;
    }
    
    // Template method - defines algorithm skeleton
    public async send(message: NotificationMessage): Promise<void> {
        // Validate recipient (concrete implementation)
        if (!this.recipientValidator.validate(message.recipient)) {
            throw new Error("Invalid recipient");
        }
        
        // Format message (subclass responsibility)
        const formatted = this.formatMessage(message);
        
        // Attempt to send with retries
        let lastError: Error | null = null;
        for (let attempt = 0; attempt < this.retryCount; attempt++) {
            if (await this.doSend(formatted)) {
                this.logAttempt(true);
                return;
            }
            lastError = new Error(`Send attempt ${attempt + 1} failed`);
        }
        
        this.logAttempt(false);
        throw lastError || new Error("Send failed");
    }
    
    // Abstract methods - subclasses must implement
    protected abstract formatMessage(message: NotificationMessage): string;
    protected abstract doSend(formattedMessage: string): Promise<boolean>;
    
    // Private helper - not overridable
    private logAttempt(success: boolean): void {
        console.log(`Notification send ${success ? 'succeeded' : 'failed'}`);
    }
}
 
// Concrete implementations
class EmailSender extends NotificationSender {
    private smtpClient: SMTPClient;
    
    constructor(validator: RecipientValidator, smtpClient: SMTPClient) {
        super(validator);
        this.smtpClient = smtpClient;
    }
    
    protected formatMessage(message: NotificationMessage): string {
        return `Subject: ${message.subject}
 
${message.body}`;
    }
    
    protected async doSend(formattedMessage: string): Promise<boolean> {
        return this.smtpClient.send(formattedMessage);
    }
}
 
class SMSSender extends NotificationSender {
    private smsProvider: SMSProvider;
    
    constructor(validator: RecipientValidator, smsProvider: SMSProvider) {
        super(validator);
        this.smsProvider = smsProvider;
        this.retryCount = 5; // Override default retry count
    }
    
    protected formatMessage(message: NotificationMessage): string {
        // SMS has character limits - truncate if needed
        const content = message.body.substring(0, 160);
        return content;
    }
    
    protected async doSend(formattedMessage: string): Promise<boolean> {
        return this.smsProvider.sendSMS(formattedMessage);
    }
}

When to Use Each

Use interfaces when you want to define a contract that multiple unrelated classes can implement. Use abstract classes when you have common behavior to share among related classes, especially when you want to use the Template Method pattern. In modern TypeScript, favor interfaces unless you need constructor logic, protected fields, or shared method implementations.

Translating Sequence Diagrams to Method Implementations

While class diagrams show static structure, sequence diagrams show dynamic behavior—how objects interact over time. Translating sequence diagrams reveals method bodies and call chains.

Reading a Sequence Diagram:

Participants (boxes at top) become the objects you'll call methods on
Messages (arrows) become method calls
Lifelines (vertical dashed lines) show when objects are active
Return arrows (dashed) show return values
Activation bars (rectangles on lifelines) show method execution duration

Key Translation Principles:

Each message arrow → A method call
Self-referencing arrow → A private method call
Return arrow → Return statement
Alt/Opt fragments → If/else statements
Loop fragments → For/while loops

Sequence Diagram to Code
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
// ================================================
// SEQUENCE DIAGRAM: Order Placement Flow
// ================================================
// 
// Customer        OrderService       Inventory       PaymentService       EmailService
//    |                 |                 |                 |                   |
//    |  placeOrder()   |                 |                 |                   |
//    |---------------->|                 |                 |                   |
//    |                 |  checkStock()   |                 |                   |
//    |                 |---------------->|                 |                   |
//    |                 |   stockResult   |                 |                   |
//    |                 |<- - - - - - - - |                 |                   |
//    |                 |                 |                 |                   |
//    |                 |  [if stock available]             |                   |
//    |                 |                 |                 |                   |
//    |                 |                 |  processPayment()|                  |
//    |                 |---------------------------------------->|             |
//    |                 |                 |   paymentResult  |                  |
//    |                 |<- - - - - - - - - - - - - - - - - -|                  |
//    |                 |                 |                 |                   |
//    |                 |                 |  [if payment successful]            |
//    |                 |                 |                 |                   |
//    |                 |  reserveStock() |                 |                   |
//    |                 |---------------->|                 |                   |
//    |                 |                 |                 |                   |
//    |                 |                 |                 | sendConfirmation()|
//    |                 |------------------------------------------------->|    |
//    |                 |                 |                 |                   |
//    |   orderResult   |                 |                 |                   |
//    |<- - - - - - - - |                 |                 |                   |
 
// The above diagram translates to:
 
interface OrderResult {
    success: boolean;
    orderId?: string;
    error?: string;
}
 
interface StockResult {
    available: boolean;
    quantity: number;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    error?: string;
}
 
class OrderService {
    private inventory: Inventory;
    private paymentService: PaymentService;
    private emailService: EmailService;
    
    constructor(
        inventory: Inventory,
        paymentService: PaymentService,
        emailService: EmailService
    ) {
        this.inventory = inventory;
        this.paymentService = paymentService;
        this.emailService = emailService;
    }
    
    // Main method from sequence diagram
    async placeOrder(order: Order): Promise<OrderResult> {
        // Step 1: Check stock (message to Inventory)
        const stockResult = await this.inventory.checkStock(order.items);
        
        // Alt fragment: [if stock available]
        if (!stockResult.available) {
            return {
                success: false,
                error: "Insufficient stock"
            };
        }
        
        // Step 2: Process payment (message to PaymentService)
        const paymentResult = await this.paymentService.processPayment(
            order.customerId,
            order.totalAmount
        );
        
        // Alt fragment: [if payment successful]
        if (!paymentResult.success) {
            return {
                success: false,
                error: paymentResult.error || "Payment failed"
            };
        }
        
        // Step 3: Reserve stock (message to Inventory)
        await this.inventory.reserveStock(order.items);
        
        // Step 4: Send confirmation (message to EmailService)
        await this.emailService.sendConfirmation(order);
        
        // Return result (dashed return arrow to Customer)
        return {
            success: true,
            orderId: this.generateOrderId()
        };
    }
    
    private generateOrderId(): string {
        return `ORD-${Date.now()}`;
    }
}
 
// Supporting classes (from the participant boxes)
class Inventory {
    async checkStock(items: OrderItem[]): Promise<StockResult> {
        // Implementation
        return { available: true, quantity: 100 };
    }
    
    async reserveStock(items: OrderItem[]): Promise<void> {
        // Implementation
    }
}
 
class PaymentService {
    async processPayment(customerId: string, amount: number): Promise<PaymentResult> {
        // Implementation
        return { success: true, transactionId: "TXN-123" };
    }
}
 
class EmailService {
    async sendConfirmation(order: Order): Promise<void> {
        // Implementation
    }
}

Fragment Notation Translation

UML sequence diagram fragments map directly to control flow: alt → if/else, opt → if (no else), loop → for/while, par → parallel execution (Promise.all, threads), break → early return or exception. Look for fragment boxes in the diagram to understand conditional logic.

Common Translation Pitfalls and How to Avoid Them

Even experienced developers make predictable mistakes when translating UML to code. Understanding these pitfalls helps you avoid them.

Common Mistakes

•Ignoring visibility modifiers — Making everything public 'for convenience'
•Flattening inheritance — Skipping abstract classes and implementing everything concrete
•Wrong relationship type — Using composition when aggregation is specified
•Ignoring navigability — Adding bidirectional references when only one direction is needed
•Missing multiplicity validation — Not enforcing [1..*] or [0..1] constraints
•Concrete class dependencies — Depending on implementations instead of interfaces

Correct Approach

•Follow visibility exactly — Private means private, protected means protected
•Preserve abstraction layers — Implement all abstract classes and interfaces as designed
•Match relationship semantics — Use constructor-created fields for composition
•Respect navigability — Only add references where arrows exist
•Validate at construction and mutation — Throw errors when constraints are violated
•Depend on abstractions — Use interfaces/abstract classes as field types

Pitfall Examples
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
// ================================================
// PITFALL: Ignoring Visibility
// ================================================
 
// ❌ WRONG: Everything public
class BadAccount {
    public balance: number = 0;  // Should be private!
    public transactions: Transaction[] = [];  // Should be protected!
    
    public setBalanceDirectly(amount: number) {
        this.balance = amount;  // Bypasses all validation!
    }
}
 
// ✅ CORRECT: Respecting visibility modifiers
class GoodAccount {
    private balance: number = 0;
    protected transactions: Transaction[] = [];
    
    public deposit(amount: number): void {
        if (amount <= 0) throw new Error("Invalid amount");
        this.balance += amount;
        this.recordTransaction("DEPOSIT", amount);
    }
    
    protected recordTransaction(type: string, amount: number): void {
        this.transactions.push(new Transaction(type, amount));
    }
}
 
// ================================================
// PITFALL: Concrete Class Dependencies
// ================================================
 
// ❌ WRONG: Depending on concrete implementation
class BadOrderProcessor {
    private gateway: StripePaymentGateway;  // Concrete type!
    
    constructor() {
        this.gateway = new StripePaymentGateway();  // Hard-coded!
    }
    
    async process(order: Order): Promise<void> {
        await this.gateway.charge(order.total);
    }
}
 
// ✅ CORRECT: Depending on abstraction (interface)
class GoodOrderProcessor {
    private gateway: PaymentGateway;  // Interface type!
    
    constructor(gateway: PaymentGateway) {  // Injected!
        this.gateway = gateway;
    }
    
    async process(order: Order): Promise<void> {
        await this.gateway.processPayment(order.total, order.paymentToken);
    }
}
 
// ================================================
// PITFALL: Wrong Relationship Implementation
// ================================================
 
// ❌ WRONG: Composition implemented as aggregation
class BadCar {
    private engine: Engine;
    
    setEngine(engine: Engine): void {
        this.engine = engine;  // Engine passed in = aggregation behavior
    }
}
 
// ✅ CORRECT: Composition - Car creates and owns its Engine
class GoodCar {
    private readonly engine: Engine;
    
    constructor(engineType: string) {
        this.engine = new Engine(engineType);  // Created internally
    }
    
    // Engine cannot be changed or removed
    getHorsepower(): number {
        return this.engine.getHorsepower();
    }
}
 
// ================================================
// PITFALL: Missing Multiplicity Validation
// ================================================
 
// ❌ WRONG: No constraint enforcement
class BadTeam {
    private players: Player[] = [];
    
    addPlayer(player: Player): void {
        this.players.push(player);  // No limit!
    }
    
    removePlayer(index: number): void {
        this.players.splice(index, 1);  // Can remove all players!
    }
}
 
// ✅ CORRECT: Enforcing [2..11] multiplicity
class GoodTeam {
    private static readonly MIN_PLAYERS = 2;
    private static readonly MAX_PLAYERS = 11;
    private players: Player[];
    
    constructor(initialPlayers: Player[]) {
        if (initialPlayers.length < GoodTeam.MIN_PLAYERS ||
            initialPlayers.length > GoodTeam.MAX_PLAYERS) {
            throw new Error(
                `Team requires ${GoodTeam.MIN_PLAYERS}-${GoodTeam.MAX_PLAYERS} players`
            );
        }
        this.players = [...initialPlayers];
    }
    
    addPlayer(player: Player): boolean {
        if (this.players.length >= GoodTeam.MAX_PLAYERS) {
            return false;
        }
        this.players.push(player);
        return true;
    }
    
    removePlayer(playerId: string): boolean {
        if (this.players.length <= GoodTeam.MIN_PLAYERS) {
            return false;
        }
        const index = this.players.findIndex(p => p.id === playerId);
        if (index > -1) {
            this.players.splice(index, 1);
            return true;
        }
        return false;
    }
}

Summary: UML-to-Code Translation Checklist

We've covered the comprehensive methodology for translating UML designs into production code. Here's a checklist to use during implementation:

UML-to-Code Checklist

•Classes — Create all classes, interfaces, and abstract classes from the diagram
•Visibility — Apply correct visibility modifiers (public, private, protected) exactly as specified
•Attributes — Implement all fields with correct types and default values
•Operations — Implement all methods with correct signatures and return types
•Inheritance — Implement extends and implements relationships correctly
•Associations — Add field references for associations, following navigability arrows
•Composition — Create composed objects in the constructor; ensure they can't be replaced
•Aggregation — Accept aggregated objects via constructor or setter; allow null
•Multiplicity — Validate cardinality constraints at construction and mutation
•Dependencies — Use interface types for fields, not concrete implementations

Page Complete

You now have a systematic approach to translating any UML diagram into code. The key is treating UML annotations as requirements, not suggestions. Every visibility modifier, every relationship type, and every multiplicity constraint carries meaning that must be preserved in the implementation. Next, we'll explore the optimal order for implementing classes to maximize productivity and minimize rework.

What's next:

Now that we can translate individual UML elements to code, the next page addresses Class Implementation Order—determining which classes to implement first to minimize dependencies, enable incremental testing, and maximize productivity during implementation.

1 / 4

Loading learning content...

Low-Level DesignFrom Design to Code

From Design to Code

LevelAdvanced

Duration75 mins

TopicFrom Design to Code

1 / 4

Translating UML to Code

The Bridge Between Design and Reality

What You Will Learn

Why UML-to-Code Translation Matters

UML diagrams serve as a communication and planning tool—they capture design decisions in a language-agnostic visual notation. But diagrams don't run. Eventually, every design must become code.

The cost of poor translation:

Common Translation Failures

•Lost flexibility — Associations become hard-coded dependencies, losing the runtime configurability the design intended
•Broken encapsulation — Visibility modifiers (private, protected) are ignored, exposing internal state that should be hidden
•Incorrect cardinality — One-to-many relationships implemented as one-to-one, or vice versa, causing data integrity issues
•Missing polymorphism — Abstract classes and interfaces reduced to concrete implementations, eliminating extensibility
•Inverted control — Dependency directions flipped, creating circular dependencies or violating dependency inversion

When done well, UML-to-code translation preserves the design's qualities:

Modularity — Each class remains a cohesive unit with a single responsibility
Flexibility — Interfaces and abstract classes enable extension without modification
Testability — Dependencies are injectable, enabling mock substitution in tests
Readability — Code structure mirrors diagram structure, making the design visible in the implementation

The goal isn't blind, mechanical copying. It's faithful translation that adapts to language idioms while preserving the design's architectural properties.

The Principal Engineer's Perspective

UML Class Diagram Elements and Their Code Mappings

Before we translate, let's establish a comprehensive mapping between UML notation and code constructs. Each element in a class diagram has a direct, systematic translation.

The Class Box:

A UML class is represented as a three-compartment rectangle:

Top compartment: Class name (italic for abstract classes, «interface» stereotype for interfaces)
Middle compartment: Attributes (fields/properties)
Bottom compartment: Operations (methods)

UML Visibility Modifiers to Code
UML Symbol	Visibility	Java/C#/TypeScript	Access Level
`+`	Public	`public`	Accessible from anywhere
`-`	Private	`private`	Accessible only within the class
`#`	Protected	`protected`	Accessible in class and subclasses
`~`	Package/Internal	`internal` (C#) / default (Java)	Accessible within same package/assembly

Attribute Syntax:

UML attributes follow the pattern: visibility name : type [multiplicity] = defaultValue

UML Notation	Code Translation
`- balance : decimal`	`private decimal balance;`
`+ name : string = ""`	`public string name = "";`
`# items : Product [*]`	`protected List<Product> items;`
`- createdAt : DateTime [0..1]`	`private DateTime? createdAt;` (nullable)

Operation (Method) Syntax:

UML operations follow: visibility name(parameters) : returnType

UML Notation	Code Translation
`+ calculateTotal() : decimal`	`public decimal CalculateTotal() { }`
`- validate(input : string) : bool`	`private bool Validate(string input) { }`
`# onStateChanged() : void`	`protected void OnStateChanged() { }`
`+ findById(id : int) : User [0..1]`	`public User? FindById(int id) { }`

UML Class Translation Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// UML Class:
// ┌────────────────────────────────────┐
// │         «abstract» Account          │
// ├────────────────────────────────────┤
// │ - accountId: string                │
// │ - balance: decimal                 │
// │ # transactions: Transaction [*]   │
// ├────────────────────────────────────┤
// │ + deposit(amount: decimal): void   │
// │ + withdraw(amount: decimal): bool  │
// │ # recordTransaction(t: Trans): void│
// │ + getBalance(): decimal            │
// └────────────────────────────────────┘
 
abstract class Account {
    // Private attributes - dash (-) in UML
    private readonly accountId: string;
    private balance: number;
    
    // Protected attribute - hash (#) in UML, [*] means collection
    protected transactions: Transaction[] = [];
 
    constructor(accountId: string, initialBalance: number = 0) {
        this.accountId = accountId;
        this.balance = initialBalance;
    }
 
    // Public methods - plus (+) in UML
    public deposit(amount: number): void {
        if (amount <= 0) {
            throw new Error("Deposit amount must be positive");
        }
        this.balance += amount;
        this.recordTransaction(new Transaction("DEPOSIT", amount));
    }
 
    public withdraw(amount: number): boolean {
        if (amount <= 0 || amount > this.balance) {
            return false;
        }
        this.balance -= amount;
        this.recordTransaction(new Transaction("WITHDRAWAL", amount));
        return true;
    }
 
    // Protected method - hash (#) in UML
    protected recordTransaction(transaction: Transaction): void {
        this.transactions.push(transaction);
    }
 
    public getBalance(): number {
        return this.balance;
    }
 
    // Abstract method (from abstract class)
    public abstract calculateInterest(): number;
}
 
// Concrete implementation
class SavingsAccount extends Account {
    private readonly interestRate: number;
 
    constructor(accountId: string, initialBalance: number, interestRate: number) {
        super(accountId, initialBalance);
        this.interestRate = interestRate;
    }
 
    public calculateInterest(): number {
        return this.getBalance() * this.interestRate;
    }
}

Translating UML Relationships to Code

Relationships between classes are the heart of any design. UML defines several relationship types, each with distinct implementation semantics.

The Five Core Relationships:

UML Relationship Types and Implementation
Relationship	UML Symbol	Meaning	Code Pattern
Association	Solid line	Uses or knows about	Field reference
Aggregation	Open diamond	Has-a (shared lifecycle)	Field reference (nullable)
Composition	Filled diamond	Has-a (owned lifecycle)	Field reference (created internally)
Inheritance	Open arrow (to parent)	Is-a	`extends` / `:`
Realization	Dashed open arrow	Implements interface	`implements` / `:`
Dependency	Dashed line with arrow	Temporarily uses	Parameter or local variable

Deep Dive: Association vs. Aggregation vs. Composition

These three relationships are frequently confused, but have distinct implementation implications:

Association (simple solid line): Two classes are related and can interact. Neither owns the other.

Aggregation (open diamond ◇): "Has-a" relationship where the part can exist independently of the whole. The whole doesn't control the part's lifecycle.

Composition (filled diamond ◆): "Has-a" relationship where the part cannot exist without the whole. The whole creates and destroys the part.

Relationship Implementations
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
// ================================================
// ASSOCIATION: Simple "knows about" relationship
// UML: Order ───────────> Customer
// ================================================
 
class Order {
    // Association: Order knows about Customer
    // Customer exists independently, passed in from outside
    private customer: Customer;
    
    constructor(customer: Customer) {
        this.customer = customer;
    }
    
    getCustomerEmail(): string {
        return this.customer.getEmail();
    }
}
 
// ================================================
// AGGREGATION: "Has-a" with independent lifecycle
// UML: Department ◇───────> Employee [*]
// Diamond on Department side, employees can exist without dept
// ================================================
 
class Department {
    private name: string;
    // Aggregation: Department has Employees
    // Employees exist independently and can belong to other departments
    private employees: Employee[] = [];
    
    constructor(name: string) {
        this.name = name;
    }
    
    // Employees are added/removed, not created/destroyed
    addEmployee(employee: Employee): void {
        this.employees.push(employee);
    }
    
    removeEmployee(employee: Employee): void {
        const index = this.employees.indexOf(employee);
        if (index > -1) {
            this.employees.splice(index, 1);
        }
        // Note: employee continues to exist after removal
    }
}
 
// ================================================
// COMPOSITION: "Has-a" with owned lifecycle
// UML: House ◆───────> Room [1..*]
// Filled diamond on House side, rooms can't exist without house
// ================================================
 
class House {
    private address: string;
    // Composition: House owns Rooms
    // Rooms are created by House and can't exist independently
    private readonly rooms: Room[] = [];
    
    constructor(address: string, roomCount: number) {
        this.address = address;
        // House creates its rooms - they can't exist without the house
        for (let i = 0; i < roomCount; i++) {
            this.rooms.push(new Room(`Room ${i + 1}`, this));
        }
    }
    
    getRooms(): ReadonlyArray<Room> {
        return this.rooms;
    }
    
    // When house is destroyed, rooms are automatically destroyed
    // (no explicit cleanup needed in garbage-collected languages)
}
 
class Room {
    private name: string;
    private readonly house: House; // Back-reference to parent
    
    constructor(name: string, house: House) {
        this.name = name;
        this.house = house;
    }
}
 
// ================================================
// INHERITANCE: "Is-a" relationship
// UML: SavingsAccount ──────▷ Account
// Open arrow pointing to parent class
// ================================================
 
abstract class Account {
    protected balance: number;
    
    constructor(initialBalance: number) {
        this.balance = initialBalance;
    }
    
    abstract calculateInterest(): number;
}
 
class SavingsAccount extends Account {
    private interestRate: number;
    
    constructor(initialBalance: number, interestRate: number) {
        super(initialBalance);
        this.interestRate = interestRate;
    }
    
    calculateInterest(): number {
        return this.balance * this.interestRate;
    }
}
 
// ================================================
// REALIZATION: Implementing an interface
// UML: EmailNotifier - - - - -▷ «interface» NotificationService
// Dashed line with open arrow to interface
// ================================================
 
interface NotificationService {
    send(recipient: string, message: string): Promise<void>;
    validateRecipient(recipient: string): boolean;
}
 
class EmailNotifier implements NotificationService {
    async send(recipient: string, message: string): Promise<void> {
        // Implementation details
        console.log(`Sending email to ${recipient}: ${message}`);
    }
    
    validateRecipient(recipient: string): boolean {
        return recipient.includes('@');
    }
}
 
// ================================================
// DEPENDENCY: Temporary usage
// UML: ReportGenerator - - - -> DataFormatter
// Dashed line with arrow (weakest relationship)
// ================================================
 
class ReportGenerator {
    // No field reference to DataFormatter
    
    generateReport(data: object[]): string {
        // Dependency: uses DataFormatter temporarily
        // Formatter is a parameter, not a stored reference
        const formatter = new DataFormatter();
        return formatter.format(data);
    }
}

Navigability Matters

Handling Multiplicity and Cardinality

Multiplicity in UML specifies how many instances of one class relate to instances of another class. Getting this wrong causes runtime errors or data integrity issues.

Common Multiplicity Notations:

UML Multiplicity to Code Mapping
Multiplicity	Meaning	Code Structure	Validation Required
`1`	Exactly one	Required field reference	Non-null check
`0..1`	Zero or one (optional)	Nullable field	Null handling
`` or `0..`	Zero or more	Collection/List	Empty collection OK
`1..*`	One or more	Collection (non-empty)	At least one element
`n..m`	Range (n to m)	Collection with size validation	Min/max size checks

Multiplicity Implementation Patterns
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
// ================================================
// MULTIPLICITY: [1] - Exactly one (required)
// UML: Order ──────────[1]──> PaymentMethod
// ================================================
 
class Order {
    // Multiplicity [1]: Exactly one, cannot be null
    private readonly paymentMethod: PaymentMethod;
    
    constructor(paymentMethod: PaymentMethod) {
        // Enforce multiplicity constraint
        if (!paymentMethod) {
            throw new Error("PaymentMethod is required");
        }
        this.paymentMethod = paymentMethod;
    }
}
 
// ================================================
// MULTIPLICITY: [0..1] - Zero or one (optional)
// UML: User ──────────[0..1]──> ProfilePhoto
// ================================================
 
class User {
    private name: string;
    // Multiplicity [0..1]: Optional, can be null
    private profilePhoto: ProfilePhoto | null = null;
    
    constructor(name: string) {
        this.name = name;
    }
    
    setProfilePhoto(photo: ProfilePhoto | null): void {
        this.profilePhoto = photo;
    }
    
    hasProfilePhoto(): boolean {
        return this.profilePhoto !== null;
    }
}
 
// ================================================
// MULTIPLICITY: [*] or [0..*] - Zero or more
// UML: ShoppingCart ──────────[*]──> CartItem
// ================================================
 
class ShoppingCart {
    // Multiplicity [*]: Zero or more
    private items: CartItem[] = [];
    
    addItem(item: CartItem): void {
        this.items.push(item);
    }
    
    removeItem(itemId: string): boolean {
        const index = this.items.findIndex(i => i.getId() === itemId);
        if (index > -1) {
            this.items.splice(index, 1);
            return true;
        }
        return false;
    }
    
    isEmpty(): boolean {
        return this.items.length === 0;
    }
}
 
// ================================================
// MULTIPLICITY: [1..*] - One or more (non-empty)
// UML: Playlist ──────────[1..*]──> Song
// ================================================
 
class Playlist {
    private name: string;
    // Multiplicity [1..*]: At least one required
    private readonly songs: Song[];
    
    constructor(name: string, initialSong: Song) {
        this.name = name;
        // Enforce at least one song
        if (!initialSong) {
            throw new Error("Playlist must have at least one song");
        }
        this.songs = [initialSong];
    }
    
    addSong(song: Song): void {
        this.songs.push(song);
    }
    
    removeSong(songId: string): boolean {
        // Maintain [1..*] constraint
        if (this.songs.length <= 1) {
            return false; // Cannot remove the last song
        }
        
        const index = this.songs.findIndex(s => s.getId() === songId);
        if (index > -1) {
            this.songs.splice(index, 1);
            return true;
        }
        return false;
    }
}
 
// ================================================
// MULTIPLICITY: [2..5] - Specific range
// UML: Team ──────────[2..5]──> Player
// ================================================
 
class Team {
    private static readonly MIN_PLAYERS = 2;
    private static readonly MAX_PLAYERS = 5;
    
    private name: string;
    private readonly players: Player[];
    
    constructor(name: string, initialPlayers: Player[]) {
        // Enforce range constraint
        if (initialPlayers.length < Team.MIN_PLAYERS) {
            throw new Error(`Team requires at least ${Team.MIN_PLAYERS} players`);
        }
        if (initialPlayers.length > Team.MAX_PLAYERS) {
            throw new Error(`Team cannot have more than ${Team.MAX_PLAYERS} players`);
        }
        
        this.name = name;
        this.players = [...initialPlayers];
    }
    
    addPlayer(player: Player): boolean {
        if (this.players.length >= Team.MAX_PLAYERS) {
            return false; // At maximum capacity
        }
        this.players.push(player);
        return true;
    }
    
    removePlayer(playerId: string): boolean {
        if (this.players.length <= Team.MIN_PLAYERS) {
            return false; // At minimum capacity
        }
        
        const index = this.players.findIndex(p => p.getId() === playerId);
        if (index > -1) {
            this.players.splice(index, 1);
            return true;
        }
        return false;
    }
    
    canAddPlayer(): boolean {
        return this.players.length < Team.MAX_PLAYERS;
    }
    
    canRemovePlayer(): boolean {
        return this.players.length > Team.MIN_PLAYERS;
    }
}

Multiplicity Validation Is Not Optional

Translating Interfaces and Abstract Classes

Interfaces and abstract classes are the cornerstones of flexible design. They define contracts that concrete classes must fulfill, enabling polymorphism and dependency injection.

The Key Distinction:

Aspect	Interface	Abstract Class
UML Notation	«interface» stereotype	Italic class name
Methods	All abstract (traditionally)	Mix of abstract and concrete
State	No instance fields (traditionally)	Can have fields
Inheritance	Multiple implementation allowed	Single inheritance only
Purpose	Define contract (what)	Provide partial implementation (how)

Modern Considerations:

TypeScript interfaces can have optional methods
Java 8+ interfaces can have default implementations
C# 8+ interfaces can have default implementations

These blur the traditional distinction, but the conceptual difference remains: interfaces define contracts; abstract classes provide skeletal implementations.

Interface and Abstract Class Patterns
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
// ================================================
// INTERFACE (from UML «interface» stereotype)
// Defines pure contract - what operations are available
// ================================================
 
// UML:
// ┌──────────────────────────────────┐
// │     «interface» PaymentGateway   │
// ├──────────────────────────────────┤
// │ + processPayment(amt): Result    │
// │ + refund(txnId): Result          │
// │ + validateCard(card): bool       │
// └──────────────────────────────────┘
 
interface PaymentGateway {
    processPayment(amount: number, cardToken: string): Promise<PaymentResult>;
    refund(transactionId: string, amount?: number): Promise<RefundResult>;
    validateCard(cardToken: string): Promise<boolean>;
}
 
// Multiple implementations of the interface
class StripeGateway implements PaymentGateway {
    async processPayment(amount: number, cardToken: string): Promise<PaymentResult> {
        // Stripe-specific implementation
        return { success: true, transactionId: `stripe_${Date.now()}` };
    }
    
    async refund(transactionId: string, amount?: number): Promise<RefundResult> {
        return { success: true };
    }
    
    async validateCard(cardToken: string): Promise<boolean> {
        return cardToken.startsWith('tok_');
    }
}
 
class PayPalGateway implements PaymentGateway {
    async processPayment(amount: number, cardToken: string): Promise<PaymentResult> {
        // PayPal-specific implementation
        return { success: true, transactionId: `paypal_${Date.now()}` };
    }
    
    async refund(transactionId: string, amount?: number): Promise<RefundResult> {
        return { success: true };
    }
    
    async validateCard(cardToken: string): Promise<boolean> {
        return cardToken.startsWith('pp_');
    }
}
 
// ================================================
// ABSTRACT CLASS (from UML italic class name)
// Provides partial implementation - template method pattern
// ================================================
 
// UML:
// ┌────────────────────────────────────────┐
// │    «abstract» NotificationSender       │
// ├────────────────────────────────────────┤
// │ - recipientValidator: Validator        │
// │ # retryCount: int = 3                  │
// ├────────────────────────────────────────┤
// │ + send(msg): void                      │
// │ # formatMessage(msg): string    (abs)  │
// │ # doSend(formatted): bool      (abs)   │
// │ - logAttempt(success): void            │
// └────────────────────────────────────────┘
 
abstract class NotificationSender {
    private recipientValidator: RecipientValidator;
    protected retryCount: number = 3;
    
    constructor(validator: RecipientValidator) {
        this.recipientValidator = validator;
    }
    
    // Template method - defines algorithm skeleton
    public async send(message: NotificationMessage): Promise<void> {
        // Validate recipient (concrete implementation)
        if (!this.recipientValidator.validate(message.recipient)) {
            throw new Error("Invalid recipient");
        }
        
        // Format message (subclass responsibility)
        const formatted = this.formatMessage(message);
        
        // Attempt to send with retries
        let lastError: Error | null = null;
        for (let attempt = 0; attempt < this.retryCount; attempt++) {
            if (await this.doSend(formatted)) {
                this.logAttempt(true);
                return;
            }
            lastError = new Error(`Send attempt ${attempt + 1} failed`);
        }
        
        this.logAttempt(false);
        throw lastError || new Error("Send failed");
    }
    
    // Abstract methods - subclasses must implement
    protected abstract formatMessage(message: NotificationMessage): string;
    protected abstract doSend(formattedMessage: string): Promise<boolean>;
    
    // Private helper - not overridable
    private logAttempt(success: boolean): void {
        console.log(`Notification send ${success ? 'succeeded' : 'failed'}`);
    }
}
 
// Concrete implementations
class EmailSender extends NotificationSender {
    private smtpClient: SMTPClient;
    
    constructor(validator: RecipientValidator, smtpClient: SMTPClient) {
        super(validator);
        this.smtpClient = smtpClient;
    }
    
    protected formatMessage(message: NotificationMessage): string {
        return `Subject: ${message.subject}
 
${message.body}`;
    }
    
    protected async doSend(formattedMessage: string): Promise<boolean> {
        return this.smtpClient.send(formattedMessage);
    }
}
 
class SMSSender extends NotificationSender {
    private smsProvider: SMSProvider;
    
    constructor(validator: RecipientValidator, smsProvider: SMSProvider) {
        super(validator);
        this.smsProvider = smsProvider;
        this.retryCount = 5; // Override default retry count
    }
    
    protected formatMessage(message: NotificationMessage): string {
        // SMS has character limits - truncate if needed
        const content = message.body.substring(0, 160);
        return content;
    }
    
    protected async doSend(formattedMessage: string): Promise<boolean> {
        return this.smsProvider.sendSMS(formattedMessage);
    }
}

When to Use Each

Translating Sequence Diagrams to Method Implementations

While class diagrams show static structure, sequence diagrams show dynamic behavior—how objects interact over time. Translating sequence diagrams reveals method bodies and call chains.

Reading a Sequence Diagram:

Participants (boxes at top) become the objects you'll call methods on
Messages (arrows) become method calls
Lifelines (vertical dashed lines) show when objects are active
Return arrows (dashed) show return values
Activation bars (rectangles on lifelines) show method execution duration

Key Translation Principles:

Each message arrow → A method call
Self-referencing arrow → A private method call
Return arrow → Return statement
Alt/Opt fragments → If/else statements
Loop fragments → For/while loops

Sequence Diagram to Code
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
// ================================================
// SEQUENCE DIAGRAM: Order Placement Flow
// ================================================
// 
// Customer        OrderService       Inventory       PaymentService       EmailService
//    |                 |                 |                 |                   |
//    |  placeOrder()   |                 |                 |                   |
//    |---------------->|                 |                 |                   |
//    |                 |  checkStock()   |                 |                   |
//    |                 |---------------->|                 |                   |
//    |                 |   stockResult   |                 |                   |
//    |                 |<- - - - - - - - |                 |                   |
//    |                 |                 |                 |                   |
//    |                 |  [if stock available]             |                   |
//    |                 |                 |                 |                   |
//    |                 |                 |  processPayment()|                  |
//    |                 |---------------------------------------->|             |
//    |                 |                 |   paymentResult  |                  |
//    |                 |<- - - - - - - - - - - - - - - - - -|                  |
//    |                 |                 |                 |                   |
//    |                 |                 |  [if payment successful]            |
//    |                 |                 |                 |                   |
//    |                 |  reserveStock() |                 |                   |
//    |                 |---------------->|                 |                   |
//    |                 |                 |                 |                   |
//    |                 |                 |                 | sendConfirmation()|
//    |                 |------------------------------------------------->|    |
//    |                 |                 |                 |                   |
//    |   orderResult   |                 |                 |                   |
//    |<- - - - - - - - |                 |                 |                   |
 
// The above diagram translates to:
 
interface OrderResult {
    success: boolean;
    orderId?: string;
    error?: string;
}
 
interface StockResult {
    available: boolean;
    quantity: number;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    error?: string;
}
 
class OrderService {
    private inventory: Inventory;
    private paymentService: PaymentService;
    private emailService: EmailService;
    
    constructor(
        inventory: Inventory,
        paymentService: PaymentService,
        emailService: EmailService
    ) {
        this.inventory = inventory;
        this.paymentService = paymentService;
        this.emailService = emailService;
    }
    
    // Main method from sequence diagram
    async placeOrder(order: Order): Promise<OrderResult> {
        // Step 1: Check stock (message to Inventory)
        const stockResult = await this.inventory.checkStock(order.items);
        
        // Alt fragment: [if stock available]
        if (!stockResult.available) {
            return {
                success: false,
                error: "Insufficient stock"
            };
        }
        
        // Step 2: Process payment (message to PaymentService)
        const paymentResult = await this.paymentService.processPayment(
            order.customerId,
            order.totalAmount
        );
        
        // Alt fragment: [if payment successful]
        if (!paymentResult.success) {
            return {
                success: false,
                error: paymentResult.error || "Payment failed"
            };
        }
        
        // Step 3: Reserve stock (message to Inventory)
        await this.inventory.reserveStock(order.items);
        
        // Step 4: Send confirmation (message to EmailService)
        await this.emailService.sendConfirmation(order);
        
        // Return result (dashed return arrow to Customer)
        return {
            success: true,
            orderId: this.generateOrderId()
        };
    }
    
    private generateOrderId(): string {
        return `ORD-${Date.now()}`;
    }
}
 
// Supporting classes (from the participant boxes)
class Inventory {
    async checkStock(items: OrderItem[]): Promise<StockResult> {
        // Implementation
        return { available: true, quantity: 100 };
    }
    
    async reserveStock(items: OrderItem[]): Promise<void> {
        // Implementation
    }
}
 
class PaymentService {
    async processPayment(customerId: string, amount: number): Promise<PaymentResult> {
        // Implementation
        return { success: true, transactionId: "TXN-123" };
    }
}
 
class EmailService {
    async sendConfirmation(order: Order): Promise<void> {
        // Implementation
    }
}

Fragment Notation Translation

Common Translation Pitfalls and How to Avoid Them

Even experienced developers make predictable mistakes when translating UML to code. Understanding these pitfalls helps you avoid them.

Common Mistakes

•Ignoring visibility modifiers — Making everything public 'for convenience'
•Flattening inheritance — Skipping abstract classes and implementing everything concrete
•Wrong relationship type — Using composition when aggregation is specified
•Ignoring navigability — Adding bidirectional references when only one direction is needed
•Missing multiplicity validation — Not enforcing [1..*] or [0..1] constraints
•Concrete class dependencies — Depending on implementations instead of interfaces

Correct Approach

•Follow visibility exactly — Private means private, protected means protected
•Preserve abstraction layers — Implement all abstract classes and interfaces as designed
•Match relationship semantics — Use constructor-created fields for composition
•Respect navigability — Only add references where arrows exist
•Validate at construction and mutation — Throw errors when constraints are violated
•Depend on abstractions — Use interfaces/abstract classes as field types

Pitfall Examples
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
// ================================================
// PITFALL: Ignoring Visibility
// ================================================
 
// ❌ WRONG: Everything public
class BadAccount {
    public balance: number = 0;  // Should be private!
    public transactions: Transaction[] = [];  // Should be protected!
    
    public setBalanceDirectly(amount: number) {
        this.balance = amount;  // Bypasses all validation!
    }
}
 
// ✅ CORRECT: Respecting visibility modifiers
class GoodAccount {
    private balance: number = 0;
    protected transactions: Transaction[] = [];
    
    public deposit(amount: number): void {
        if (amount <= 0) throw new Error("Invalid amount");
        this.balance += amount;
        this.recordTransaction("DEPOSIT", amount);
    }
    
    protected recordTransaction(type: string, amount: number): void {
        this.transactions.push(new Transaction(type, amount));
    }
}
 
// ================================================
// PITFALL: Concrete Class Dependencies
// ================================================
 
// ❌ WRONG: Depending on concrete implementation
class BadOrderProcessor {
    private gateway: StripePaymentGateway;  // Concrete type!
    
    constructor() {
        this.gateway = new StripePaymentGateway();  // Hard-coded!
    }
    
    async process(order: Order): Promise<void> {
        await this.gateway.charge(order.total);
    }
}
 
// ✅ CORRECT: Depending on abstraction (interface)
class GoodOrderProcessor {
    private gateway: PaymentGateway;  // Interface type!
    
    constructor(gateway: PaymentGateway) {  // Injected!
        this.gateway = gateway;
    }
    
    async process(order: Order): Promise<void> {
        await this.gateway.processPayment(order.total, order.paymentToken);
    }
}
 
// ================================================
// PITFALL: Wrong Relationship Implementation
// ================================================
 
// ❌ WRONG: Composition implemented as aggregation
class BadCar {
    private engine: Engine;
    
    setEngine(engine: Engine): void {
        this.engine = engine;  // Engine passed in = aggregation behavior
    }
}
 
// ✅ CORRECT: Composition - Car creates and owns its Engine
class GoodCar {
    private readonly engine: Engine;
    
    constructor(engineType: string) {
        this.engine = new Engine(engineType);  // Created internally
    }
    
    // Engine cannot be changed or removed
    getHorsepower(): number {
        return this.engine.getHorsepower();
    }
}
 
// ================================================
// PITFALL: Missing Multiplicity Validation
// ================================================
 
// ❌ WRONG: No constraint enforcement
class BadTeam {
    private players: Player[] = [];
    
    addPlayer(player: Player): void {
        this.players.push(player);  // No limit!
    }
    
    removePlayer(index: number): void {
        this.players.splice(index, 1);  // Can remove all players!
    }
}
 
// ✅ CORRECT: Enforcing [2..11] multiplicity
class GoodTeam {
    private static readonly MIN_PLAYERS = 2;
    private static readonly MAX_PLAYERS = 11;
    private players: Player[];
    
    constructor(initialPlayers: Player[]) {
        if (initialPlayers.length < GoodTeam.MIN_PLAYERS ||
            initialPlayers.length > GoodTeam.MAX_PLAYERS) {
            throw new Error(
                `Team requires ${GoodTeam.MIN_PLAYERS}-${GoodTeam.MAX_PLAYERS} players`
            );
        }
        this.players = [...initialPlayers];
    }
    
    addPlayer(player: Player): boolean {
        if (this.players.length >= GoodTeam.MAX_PLAYERS) {
            return false;
        }
        this.players.push(player);
        return true;
    }
    
    removePlayer(playerId: string): boolean {
        if (this.players.length <= GoodTeam.MIN_PLAYERS) {
            return false;
        }
        const index = this.players.findIndex(p => p.id === playerId);
        if (index > -1) {
            this.players.splice(index, 1);
            return true;
        }
        return false;
    }
}

Summary: UML-to-Code Translation Checklist

We've covered the comprehensive methodology for translating UML designs into production code. Here's a checklist to use during implementation:

UML-to-Code Checklist

•Classes — Create all classes, interfaces, and abstract classes from the diagram
•Visibility — Apply correct visibility modifiers (public, private, protected) exactly as specified
•Attributes — Implement all fields with correct types and default values
•Operations — Implement all methods with correct signatures and return types
•Inheritance — Implement extends and implements relationships correctly
•Associations — Add field references for associations, following navigability arrows
•Composition — Create composed objects in the constructor; ensure they can't be replaced
•Aggregation — Accept aggregated objects via constructor or setter; allow null
•Multiplicity — Validate cardinality constraints at construction and mutation
•Dependencies — Use interface types for fields, not concrete implementations

Page Complete

What's next:

1 / 4