Class diagrams in LLD - System Design Exercise

Design: Class Diagram Design

Focus on designing class diagrams for object-oriented systems. Out of scope are dynamic diagrams like sequence or activity diagrams.

Functional Requirements

FR1: Represent the static structure of a system using classes

FR2: Show class attributes and methods

FR3: Illustrate relationships between classes such as inheritance, association, aggregation, and composition

FR4: Support visibility indicators (public, private, protected)

FR5: Allow modeling of interfaces and abstract classes

Non-Functional Requirements

NFR1: Diagram must be clear and easy to understand for beginners

NFR2: Must follow UML standard notation

NFR3: Should be scalable to model small to medium systems

NFR4: Must be technology-agnostic

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Classes with attributes and methods

Relationships: inheritance, association, aggregation, composition

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

Interfaces and abstract classes

Design Patterns

Inheritance for code reuse

Composition to model strong ownership

Aggregation for weak ownership

Interface implementation for polymorphism

Reference Architecture

  +----------------+        +----------------+
  |    Animal      |<-------|    Dog         |
  +----------------+        +----------------+
  | - name: String |        |                |
  | + eat(): void  |        | + bark(): void |
  +----------------+        +----------------+
          ^                          
          |                          
  +----------------+                
  |    Cat         |                
  +----------------+                
  | + meow(): void |                
  +----------------+                

  +----------------+        +----------------+
  |    Person      |<>------|    Car         |
  +----------------+        +----------------+
  | - name: String |        | - model: String |
  | + drive(): void|        +----------------+
  +----------------+

Components

Class

UML notation

Represents an entity with attributes and methods

Inheritance

UML arrow with hollow triangle

Shows 'is-a' relationship for code reuse

Association

UML solid line

Represents a relationship between classes

Aggregation

UML line with hollow diamond

Represents a whole-part relationship with weak ownership

Composition

UML line with filled diamond

Represents a whole-part relationship with strong ownership

Visibility

Symbols +, -, #

Indicates access level of attributes and methods

Interface

UML interface notation

Defines a contract for classes to implement

Request Flow

1. Identify key entities in the system and define them as classes

2. Add relevant attributes and methods to each class

3. Determine relationships between classes and represent them using appropriate UML connectors

4. Mark visibility for each attribute and method

5. Use inheritance to model shared behavior

6. Use interfaces to define common contracts

7. Review diagram for clarity and completeness

Database Schema

Not applicable for class diagrams as they model system structure, not data storage.

Scaling Discussion

Bottlenecks

Diagram becomes cluttered and hard to read with many classes

Complex relationships can confuse beginners

Maintaining diagram consistency as system evolves

Solutions

Use packages or modules to group related classes

Limit diagram scope to key classes for clarity

Use layering to separate concerns

Employ tools that support zoom and filtering

Regularly update diagrams to reflect system changes

Interview Tips

Time: Spend 10 minutes understanding the system entities, 15 minutes drawing classes and relationships, 10 minutes reviewing and explaining the diagram, 10 minutes answering questions.

Explain how classes represent real-world entities

Describe relationships and why chosen (inheritance, association, etc.)

Discuss visibility and encapsulation

Mention use of interfaces and abstract classes for flexibility

Highlight clarity and maintainability of the diagram