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

Practice

1. What does a UML class diagram primarily represent in system design?

easy

A. The structure of classes and their relationships

B. The sequence of operations in a process

C. The deployment of hardware components

D. The flow of data between systems

Solution

1. Step 1: Understand UML class diagram purpose

   A UML class diagram shows how classes are organized and connected in a system.

2. Step 2: Compare options to definition

   Only The structure of classes and their relationships describes structure of classes and relationships, which matches UML class diagrams.

3. Final Answer:

   The structure of classes and their relationships -> Option A

4. Quick Check:

   UML class diagram = class structure [OK]

Hint: Class diagrams show classes and links, not processes or hardware [OK]

Common Mistakes:

• Confusing class diagrams with sequence diagrams
• Thinking class diagrams show hardware layout
• Mixing data flow diagrams with class diagrams

2. Which of the following is the correct way to show a class attribute in a UML class diagram?

easy

A. * attributeName -> Type

B. - attributeName = Type

C. # attributeName - Type

D. + attributeName : Type

Solution

1. Step 1: Recall UML attribute notation

   Attributes use visibility (+ public, - private, # protected), name, colon, and type.

2. Step 2: Match options to notation

   + attributeName : Type matches correct format: '+ attributeName : Type'. Others use wrong symbols or separators.

3. Final Answer:

   + attributeName : Type -> Option D

4. Quick Check:

   Attribute syntax = + name : Type [OK]

Hint: Attributes use visibility + name : Type format [OK]

Common Mistakes:

• Using '=' instead of ':' to separate name and type
• Confusing visibility symbols
• Using arrows or dashes incorrectly

3. Given this UML class snippet:
+ name : String
- age : int
Which statement is true about the attributes?

medium

A. 'name' is private and 'age' is public

B. 'name' is public and 'age' is private

C. Both 'name' and 'age' are public

D. Both 'name' and 'age' are private

Solution

1. Step 1: Interpret visibility symbols

   '+' means public, '-' means private in UML.

2. Step 2: Apply to attributes

   'name' has '+', so public; 'age' has '-', so private.

3. Final Answer:

   'name' is public and 'age' is private -> Option B

4. Quick Check:

   + = public, - = private [OK]

Hint: Plus means public, minus means private [OK]

Common Mistakes:

• Mixing up '+' and '-' meanings
• Assuming all attributes are public by default
• Ignoring visibility symbols

4. Identify the error in this UML class attribute declaration:
- salary = float

medium

A. Visibility symbol '-' is incorrect

B. Type 'float' should be capitalized

C. The '=' sign should be ':' to separate name and type

D. Attribute name 'salary' is invalid

Solution

1. Step 1: Check UML attribute syntax

   Attributes use visibility, name, colon ':', then type. '=' is not used.

2. Step 2: Identify incorrect symbol

   The '=' sign is wrong; it should be ':' to separate attribute name and type.

3. Final Answer:

   The '=' sign should be ':' to separate name and type -> Option C

4. Quick Check:

   Use ':' not '=' in attributes [OK]

Hint: Use ':' not '=' between name and type [OK]

Common Mistakes:

• Using '=' instead of ':'
• Thinking visibility symbols are wrong
• Assuming type names must be capitalized

5. You want to model a simple library system with classes Book and Author. Each book has one author, and an author can write many books. Which UML relationship best represents this?

hard

A. Aggregation from Author to Book (one-to-many)

B. Composition from Book to Author (one-to-one)

C. Inheritance from Book to Author

D. Association from Book to Author (many-to-many)

Solution

1. Step 1: Understand relationship types

   Aggregation means a whole-part with shared lifecycle; composition means strong ownership; inheritance means 'is-a' relation; association is a general link.

2. Step 2: Apply to library example

   Author writes many books (one-to-many). Books can exist without author object lifecycle tightly bound, so aggregation fits best.

3. Final Answer:

   Aggregation from Author to Book (one-to-many) -> Option A

4. Quick Check:

   One author, many books = aggregation [OK]

Hint: One-to-many ownership without strong lifecycle = aggregation [OK]

Common Mistakes:

• Confusing composition with aggregation
• Using inheritance for unrelated classes
• Choosing many-to-many when one-to-many fits