Bird
Raised Fist0

UML Class Diagrams - Reading and Drawing Relationships, Multiplicity, Notation

LLDeasyInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Class Trace
Step 1/4
UMLClass

UMLClass is an abstract class holding state like name, attributes, and operations lists.

🎯 Tests understanding that UMLClass must be abstract class (not interface) because it holds instance state like lists of attributes and operations which interfaces cannot hold in Java.
public abstract class UMLClass {
    private String name;
    private List<UMLAttribute> attributes = new ArrayList<>();
    private List<UMLOperation> operations = new ArrayList<>();
    public synchronized void addAttribute(UMLAttribute attr) {
        attributes.add(attr);
    }
    public synchronized void addOperation(UMLOperation op) {
        operations.add(op);
    }
}
UMLDiagram composition

UMLDiagram composes UMLClass and UMLRelationship with composition, owning their lifecycle.

🎯 Tests whether candidate knows composition means UMLDiagram controls lifecycle of UMLClass and UMLRelationship instances, enforcing strong ownership and encapsulation.
public class UMLDiagram {
    private List<UMLClass> classes = new ArrayList<>();
    private List<UMLRelationship> relationships = new ArrayList<>();
    public synchronized void addClass(UMLClass cls) {
        classes.add(cls);
    }
    public synchronized void addRelationship(UMLRelationship rel) {
        relationships.add(rel);
    }
}
UMLRelationship realization

UMLRelationship realizes an interface or abstract concept of relationship type, linking source and target UMLClass.

🎯 Tests if candidate understands realization means UMLRelationship implements or realizes an abstract contract, and that source and target are associations with independent lifecycle.
public class UMLRelationship {
    private UMLClass source;
    private UMLClass target;
    private String type;
    public UMLRelationship(UMLClass src, UMLClass tgt, String type) {
        this.source = src;
        this.target = tgt;
        this.type = type;
    }
    public String getType() {
        return type;
    }
}
UMLAttribute association

UMLAttribute is associated with UMLClass but has independent lifecycle, shown by association arrow.

🎯 Tests candidate's knowledge that UMLAttribute is not composed by UMLClass but associated, so it can exist independently and be reused or shared.
public class UMLAttribute {
    private String name;
    private String type;
    public UMLAttribute(String name, String type) {
        this.name = name;
        this.type = type;
    }
    public String getName() {
        return name;
    }
}
📐
Class Diagram
Class Diagram
       +----------------+
       | <<Abstract>>   |
       | UMLClass       |
       +----------------+
       | -name: String  |
       | -attributes:   |
       |  List<UMLAttribute> |
       | -operations:   |
       |  List<UMLOperation> |
       +----------------+
       | +addAttribute()|
       | +addOperation()|
       +----------------+
              │ extends
       +----------------+
       | UMLDiagram     |
       +----------------+
       | -classes: List |
       |  <UMLClass>    |
       | -relationships:|
       |  List<UMLRelationship> |
       +----------------+
       | +addClass()    |
       | +addRelationship() |
       +----------------+
              ◆ composition
       +----------------+
       | UMLRelationship|
       +----------------+
       | -source: UMLClass|
       | -target: UMLClass|
       | -type: String   |
       +----------------+
       | +getType()     |
       +----------------+
              ── ─► realization
       +----------------+
       | UMLAttribute   |
       +----------------+
       | -name: String  |
       | -type: String  |
       +----------------+
       | +getName()     |
       +----------------+
              ──► association
Design Rationale

This UML class diagram illustrates key Java OOP design decisions for a UML diagram system. UMLClass is an abstract class because it holds mutable state like attribute and operation lists, which interfaces cannot hold in Java. UMLDiagram composes UMLClass and UMLRelationship, enforcing strong lifecycle ownership per composition semantics. UMLRelationship realizes an abstract relationship concept, linking UMLClass instances via association, showing independent lifecycle. UMLAttribute is associated with UMLClass but not composed, allowing independent existence. These decisions enforce SOLID principles: Single Responsibility by separating diagram and class concerns, Open-Closed by using abstract UMLClass for extensibility, and Dependency Inversion by depending on abstractions for relationships. The concurrency is handled by synchronized methods on collections to avoid thread interleaving bugs when modifying lists.

Primary Focus

✓ Composition vs Association lifecycle + Abstract class state vs Interface + Realization vs Inheritance

Practice

(1/5)
1. A class has a private constructor and a static synchronized getInstance() method returning a single instance. Which pattern is applied and why is this the CORRECT use case?
easy
A. Factory Method pattern, because it controls object creation with a static method.
B. Prototype pattern, to clone existing instances instead of creating new ones.
C. Builder pattern, to construct complex objects step-by-step.
D. Singleton pattern, ensuring only one instance exists and is thread-safe.

Solution

  1. Step 1: Identify the pattern from constructor and method

    The private constructor prevents external instantiation, and the static synchronized getInstance() method ensures a single shared instance with thread safety.

  2. Step 2: Eliminate other creational patterns

    Factory Method creates objects but doesn't enforce single instance; Builder constructs complex objects but not singleton; Prototype clones instances, not restricts to one.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Private constructor + synchronized static getter -> Singleton pattern [check]
Hint: Private constructor + static synchronized getter -> Singleton [check]
Common Mistakes:
2. In LinkedIn's ConnectionManager, the method addConnection(User a, User b) checks if users are already connected before adding. Without synchronizing this method, what exact thread interleaving causes a double connection to be created?
medium
A. Thread 1 checks isConnected(a,b) -> false, context switch; Thread 2 checks isConnected(a,b) -> false; both add connections.
B. Thread 1 and Thread 2 both call addConnection simultaneously, but one fails due to a database constraint.
C. Thread 1 adds connection, then Thread 2 removes it before Thread 1 commits.
D. Thread 1 and Thread 2 both read connection list after addition, causing stale cache.

Solution

  1. Step 1: Identify the check-then-act race condition

    Without synchronization, both threads can see no existing connection and proceed to add, causing duplicates.

  2. Step 2: Trace exact thread interleaving

    Thread 1 calls isConnected(a,b) and gets false, then context switches before adding. Thread 2 also calls isConnected(a,b) and gets false, then both add connections concurrently.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Check-then-act gap causes double connection addition [check]
Hint: Check-then-act without sync -> double add race [check]
Common Mistakes:
3. To support ElectricCar needing ChargingSpot in the vending machine parking design, what is the minimum change that respects extensibility without modifying existing classes?
hard
A. Create a new ChargingSpot class extending Spot and modify ParkingLot to handle it specially.
B. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.
C. Modify existing Vehicle and Spot classes to add electric-specific fields and logic.
D. Add a boolean isElectric flag to Vehicle and Spot classes and add conditional logic everywhere.

Solution

  1. Step 1: Identify extensibility requirements

    Adding new vehicle and spot types without modifying existing classes preserves OCP and avoids class explosion.

  2. Step 2: Evaluate options for minimal invasive change

    Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly. adds new enum values and a subclass, updating compatibility map without changing existing classes. Others modify existing classes or add flags causing complexity.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    New enums and subclass extend design without modifying existing classes [check]
Hint: Add enums + subclass + compatibility map, no existing class changes [check]
Common Mistakes:
4. You need to add support for ElectricCar and ChargingSpot in the existing parking system using the Iterator pattern. What is the minimum change to the current design to support this without modifying existing classes?
hard
A. Modify Vehicle and Spot classes to include electric-specific fields and logic, then update iterators accordingly.
B. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map; existing classes remain unchanged.
C. Create a new ElectricVehicle interface extending Vehicle and a ChargingSpot class, then modify existing iterators to handle them.
D. Add a flag isElectric to Vehicle class and modify SpotCompatibility to check this flag during iteration.

Solution

  1. Step 1: Identify extensibility requirements

    Adding ElectricCar and ChargingSpot should not require modifying existing classes to respect OCP.

  2. Step 2: Evaluate options

    Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility map; existing classes remain unchanged. adds new enums and classes without modifying existing ones, preserving OCP. Modify Vehicle and Spot classes to include electric-specific fields and logic, then update iterators accordingly. modifies existing classes, violating OCP. Create a new ElectricVehicle interface extending Vehicle and a ChargingSpot class, then modify existing iterators to handle them. adds interfaces but requires modifying iterators, violating OCP. Add a flag isElectric to Vehicle class and modify SpotCompatibility to check this flag during iteration. modifies Vehicle class, violating OCP.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Adding new enums and subclasses without changing existing classes respects OCP [check]
Hint: Add new types via enums and subclasses, no existing class changes [check]
Common Mistakes:
5. To add ElectricCar needing ChargingSpot support, what is the minimum change to the current design without modifying existing classes?
hard
A. Add ELECTRIC_CAR to VehicleType, CHARGING to SpotType, create ElectricCar extending Vehicle, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.
B. Modify Vehicle and ParkingSpot classes to include electric-specific fields and logic.
C. Create a new ElectricVehicleManager class handling electric cars and charging spots, modifying parking logic.
D. Add conditional logic in ParkingLot to handle electric cars and charging spots explicitly.

Solution

  1. Step 1: Identify extensibility requirements

    Adding ElectricCar and ChargingSpot support must avoid modifying existing classes to comply with OCP and maintain code modularity.

  2. Step 2: Evaluate options for minimal invasive change

    Add ELECTRIC_CAR to VehicleType, CHARGING to SpotType, create ElectricCar extending Vehicle, and update SpotCompatibility.COMPATIBILITY_MAP accordingly. extends enums and adds new classes, updating compatibility map without changing existing classes. Options B, C, and D modify existing classes or add god-class logic, violating OCP and increasing complexity.

  3. Step 3: Confirm Java-specific implementation details

    Updating enums and compatibility map is idiomatic in Java for extensibility without class explosion.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Extend enums + new class + compatibility map update -> minimal change [check]
Hint: Extend enums + new class + compatibility map -> minimal invasive change [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard