UML class diagrams basics in LLD - System Design Exercise

Design: UML Class Diagram Basics

Focus on static structure representation using UML class diagrams. Out of scope: detailed method implementations, dynamic interactions, deployment diagrams.

Functional Requirements

FR1: Show how to represent classes with attributes and methods

FR2: Illustrate relationships: association, inheritance, aggregation, composition

FR3: Include visibility indicators (public, private, protected)

FR4: Demonstrate multiplicity on relationships

FR5: Keep diagrams simple for beginners

Non-Functional Requirements

NFR1: Diagrams must be clear and easy to understand

NFR2: Use standard UML notation

NFR3: Support up to 10 classes per diagram

NFR4: No need for dynamic behavior or sequence diagrams

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Classes with name, attributes, methods

Relationships: association, inheritance, aggregation, composition

Visibility markers (+ public, - private, # protected)

Multiplicity indicators (1, 0..*, etc.)

Design Patterns

Inheritance for generalization

Aggregation vs composition for whole-part relationships

Association for simple links

Use of interfaces or abstract classes (optional)

Reference Architecture

 +----------------+       +----------------+       +----------------+
 |    Person      |<>-----|   Address      |       |   Employee     |
 |----------------|       |----------------|       |----------------|
 | -name: String  |       | -street: String|       | -employeeId: int|
 | -age: int      |       | -city: String  |       | +work(): void   |
 | +getName():Str |       | +getCity():Str |       |----------------|
 +----------------+       +----------------+       ^                
                                                      |                
                                              +----------------+     
                                              |   Manager      |     
                                              |----------------|     
                                              | +manage(): void |     
                                              +----------------+     

Components

Person

UML Class

Represents a person with attributes and methods

Address

UML Class

Represents an address linked to a person (aggregation)

Employee

UML Class

Inherits from Person and adds employee-specific details

Manager

UML Class

Specialized Employee with management responsibilities

Request Flow

1. 1. Identify classes and their attributes/methods

2. 2. Define visibility for each attribute and method

3. 3. Draw classes as boxes divided into name, attributes, methods

4. 4. Connect classes with lines showing relationships:

5. - Solid line with hollow diamond for aggregation

6. - Solid line with filled diamond for composition

7. - Solid line with hollow arrow for inheritance

8. - Simple solid line for association

9. 5. Add multiplicity near relationship ends if needed

10. 6. Review diagram for clarity and correctness

Database Schema

Not applicable for UML class diagrams basics as this focuses on static structure modeling, not database design.

Scaling Discussion

Bottlenecks

Diagrams become cluttered with many classes and relationships

Difficulty in showing complex relationships clearly

Limited expressiveness for dynamic behavior

Misinterpretation of relationship types by beginners

Solutions

Split large systems into multiple smaller diagrams

Use packages or modules to group related classes

Introduce other UML diagrams (sequence, activity) for behavior

Provide clear legends and documentation for relationship types

Interview Tips

Time: Spend 10 minutes explaining UML class diagram basics, 15 minutes drawing a simple example, 10 minutes discussing relationships and visibility, 10 minutes answering questions.

Explain the purpose of UML class diagrams as static structure models

Describe how classes are represented with attributes and methods

Clarify different relationship types and their notation

Discuss visibility and multiplicity importance

Mention limitations and when to use other UML diagrams