Bird
Raised Fist0

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

LLDeasyInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
UML Class Diagrams - Reading and Drawing Relationships, Multiplicity, Notation
Master UML class diagram relationships, multiplicity, and notation with Java-specific OOP insights.
easyOOP Foundations for InterviewsFreq: common
Prerequisites:OOP Fundamentals
⚙️
Functional Requirements
  • Support representation of UML class relationships: inheritance, composition, aggregation, association, realization
  • Represent multiplicity on both ends of relationships (e.g., 1..*, 0..1)
  • Use correct UML notation for each relationship type
  • Allow reading and interpreting multiplicity and relationship direction
  • Explain Java-specific reasons for choosing abstract classes vs interfaces in UML
  • Demonstrate concurrency-safe updates to shared UML diagrams
  • Support extensibility adhering to SOLID principles
👤
Use Cases
  • Read UML class diagrams and identify relationships and multiplicities
  • Draw UML class diagrams with correct relationships and multiplicities
  • Explain Java-specific OOP decisions behind relationship choices
  • Discuss concurrency implications in shared class diagram editing
  • Extend existing UML diagrams without modifying original classes
🧑‍💻
Actors
  • Software Engineer (Candidate)
  • Interviewer
  • System Architect
❓
Clarifying Questions to Ask
  • How many concurrent users or threads will edit or read the UML diagrams simultaneously?
  • Is there a pricing or licensing strategy for UML diagram usage or editing?
  • Are there edge cases such as cyclic inheritance or multiple inheritance to consider?
  • Should the system support partial or incomplete diagrams during editing?
  • Is versioning or rollback of UML diagrams required?
Out of Scope
✗ Automatic UML diagram generation from code
✗ Graphical UI rendering of UML diagrams
✗ Persistence or database storage of UML diagrams
✗ Non-class UML diagrams (e.g., sequence, activity diagrams)
⚡
QPS Calculation
read qps100
write qps10
🖥️
Server Estimate
3
Estimates based on typical UML diagram editing and reading workloads in interview prep tools.
🔢
Enumerations
enum RelationshipType
INHERITANCE | COMPOSITION | AGGREGATION | ASSOCIATION | REALIZATION
Defines UML relationship types explicitly to prevent typo bugs and enable exhaustive switch statements in Java.
enum Multiplicity
ZERO_ONE | ONE | ZERO_MANY | ONE_MANY | UNSPECIFIED
Encapsulates multiplicity constraints to avoid string parsing errors and enforce valid UML multiplicity semantics.
enum Visibility
PUBLIC | PRIVATE | PROTECTED | PACKAGE_PRIVATE
Represents Java visibility modifiers to link UML visibility notation with Java access control.
📦
UMLClass
4 fields
private final String nameprivate final List<UMLAttribute> attributesprivate final List<UMLOperation> operationsprivate final Visibility visibility
Represents a UML class with attributes, operations, and visibility; encapsulates class-level details.
Key Methods
public String getName()Returns the name of the UML class.
public synchronized void addAttribute(UMLAttribute attribute)Thread-safe addition of an attribute to the class.
public synchronized void addOperation(UMLOperation operation)Thread-safe addition of an operation to the class.
📦
UMLAttribute
3 fields
private final String nameprivate final String typeprivate final Visibility visibility
Represents an attribute (field) of a UML class with type and visibility.
Key Methods
public String getName()Returns the attribute name.
public String getType()Returns the attribute type.
📦
UMLOperation
4 fields
private final String nameprivate final List<String> parameterTypesprivate final String returnTypeprivate final Visibility visibility
Represents an operation (method) of a UML class with parameters, return type, and visibility.
Key Methods
public String getSignature()Returns the full method signature as a string.
📦
UMLRelationship
6 fields
private final UMLClass fromprivate final UMLClass toprivate final RelationshipType typeprivate final Multiplicity fromMultiplicityprivate final Multiplicity toMultiplicityprivate final boolean navigableFromTo
Represents a UML relationship between two classes with type, multiplicity, and navigability.
Key Methods
public boolean isNavigableFromTo()Returns true if relationship is navigable from 'from' class to 'to' class.
public String getUmlNotation()Returns the UML notation string for this relationship.
📦
UMLDiagram
2 fields
private final List<UMLClass> classesprivate final List<UMLRelationship> relationships
Manages a collection of UML classes and relationships; supports adding and querying diagram elements.
Key Methods
public synchronized void addClass(UMLClass umlClass)Thread-safe addition of a UML class to the diagram.
public synchronized void addRelationship(UMLRelationship relationship)Thread-safe addition of a UML relationship to the diagram.
public List<UMLClass> getClasses()Returns the list of UML classes.
public List<UMLRelationship> getRelationships()Returns the list of UML relationships.
🔗
Relationships
UMLDiagram◆──►UMLClass[1..*]
compositionUMLClass instances cannot exist independently outside UMLDiagram
UMLDiagram◆──►UMLRelationship[0..*]
compositionUMLRelationship instances lifecycle bound to UMLDiagram
UMLRelationship──►UMLClass[1]
associationUMLRelationship references UMLClass but UMLClass exists independently
UMLClass◆──►UMLAttribute[0..*]
compositionUMLAttribute instances lifecycle bound to UMLClass
UMLClass◆──►UMLOperation[0..*]
compositionUMLOperation instances lifecycle bound to UMLClass
🗄️
uml_classes
PK: diagram_id
diagram_id UUIDclass_name TEXTvisibility TEXTattributes JSONoperations JSON
🗄️
uml_relationships
PK: diagram_id
diagram_id UUIDrelationship_id UUIDfrom_class TEXTto_class TEXTtype TEXTfrom_multiplicity TEXTto_multiplicity TEXTnavigable BOOLEAN
🔌
AddClass
Request
{
  "diagramId": "UUID",
  "className": "String",
  "visibility": "Visibility",
  "attributes": "List<UMLAttribute>",
  "operations": "List<UMLOperation>"
}
Response
{
  "success": "boolean",
  "message": "String"
}
Adds a new class to the specified UML diagram.
🔌
AddRelationship
Request
{
  "diagramId": "UUID",
  "fromClass": "String",
  "toClass": "String",
  "type": "RelationshipType",
  "fromMultiplicity": "Multiplicity",
  "toMultiplicity": "Multiplicity",
  "navigableFromTo": "boolean"
}
Response
{
  "success": "boolean",
  "message": "String"
}
Adds a new relationship between classes in a UML diagram.
🔌
GetDiagram
Request
{
  "diagramId": "UUID"
}
Response
{
  "umlClasses": "List<UMLClass>",
  "umlRelationships": "List<UMLRelationship>"
}
Retrieves the full UML diagram with classes and relationships.

Practice

(1/5)
1. In the auction system, should the Bid entity be designed as an abstract class or an interface? Consider that bids have state (amount, bidder) and behavior (validate, notify). Which is the best choice and why?
easy
A. Interface, because it allows multiple inheritance and enforces method signatures without state.
B. Interface, because bids only define behavior and state is stored externally in a database.
C. Abstract class, because it can hold common bid state and provide default behavior implementations.
D. Abstract class, because it forces all subclasses to implement all methods explicitly without defaults.

Solution

  1. Step 1: Analyze state and behavior needs

    Bids have shared state (amount, bidder) and common behavior (validation, notification), which benefit from code reuse and encapsulation.

  2. Step 2: Compare abstract class vs interface

    Abstract classes can hold state and provide default method implementations; interfaces cannot hold state and only define method signatures.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful entity with shared behavior -> abstract class [check]
Hint: State + behavior reuse -> abstract class, not interface [check]
Common Mistakes:
2. The Car Rental System currently uses a FeeStrategy interface for pricing. To add a WeekendFeeStrategy without modifying existing classes, which SOLID principle is being applied, and what is the minimum required change?
medium
A. Single Responsibility Principle; modify the existing FeeStrategy implementations to include weekend logic.
B. Open/Closed Principle; create a new WeekendFeeStrategy class implementing FeeStrategy without changing existing code.
C. Liskov Substitution Principle; override existing FeeStrategy methods to handle weekend fees.
D. Dependency Inversion Principle; inject WeekendFeeStrategy into existing classes by modifying their constructors.

Solution

  1. Step 1: Identify the SOLID principle for extensibility

    Open/Closed Principle (OCP) states software entities should be open for extension but closed for modification.

  2. Step 2: Determine minimal change to add WeekendFeeStrategy

    To avoid modifying existing classes, inject the new WeekendFeeStrategy via dependency injection, applying Dependency Inversion Principle (DIP) to depend on abstractions.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Inject new strategy without modifying existing classes -> DIP [check]
Hint: Add new strategy via injection, not modifying existing code [check]
Common Mistakes:
3. To add a WeekendFeeStrategy for weekend pricing in the current booking system design, which minimal change respects the Open-Closed Principle (OCP)?
medium
A. Modify the existing FeeCalculator class to add weekend logic with if-else conditions.
B. Create a new class implementing FeeStrategy interface for weekend fees and inject it without changing existing classes.
C. Add a boolean flag isWeekend in Booking and handle fees there.
D. Extend FeeCalculator with a subclass that overrides fee calculation for weekends.

Solution

  1. Step 1: Identify OCP requirement

    OCP requires adding new functionality without modifying existing tested code.

  2. Step 2: Evaluate options

    Add a boolean flag isWeekend in Booking and handle fees there. adds weekend flag in Booking, which violates OCP by modifying Booking class. Create a new class implementing FeeStrategy interface for weekend fees and inject it without changing existing classes. creates a new FeeStrategy class, respecting OCP by extension. Modify the existing FeeCalculator class to add weekend logic with if-else conditions. and D modify existing classes, violating OCP.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New FeeStrategy class -> extend without modifying existing code [check]
Hint: New strategy class -> extend, don't modify [check]
Common Mistakes:
4. In the Facebook design, the FriendRequestManager class has a sendRequest() method that checks if a friend request exists before creating one. Without synchronization, which exact thread interleaving causes duplicate friend requests?
medium
A. Thread 1 sends request, Thread 2 waits until Thread 1 finishes, then sends request.
B. Thread 1 and Thread 2 both block on a lock, preventing duplicate requests.
C. Thread 1 creates request, Thread 2 reads request and cancels its own creation.
D. Thread 1 checks no request exists, context switch; Thread 2 checks no request exists, both create requests.

Solution

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

    Both threads check for existing request before creation; without synchronization, both see none.

  2. Step 2: Trace thread interleaving

    Thread 1 checks and pauses before creating; Thread 2 checks and proceeds; both create duplicate requests.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Unsynchronized check-then-act -> duplicate friend requests [check]
Hint: Check-then-act without lock -> race condition [check]
Common Mistakes:
5. In a parking lot system, if parkVehicle() is not synchronized, which exact sequence of Thread 1 and Thread 2 causes double-booking of the same spot?
medium
A. Thread 1 parks vehicle, Thread 2 waits until Thread 1 finishes, then parks another vehicle.
B. Thread 1 and Thread 2 both crash due to simultaneous access.
C. Thread 1 checks spot availability -> true, context switch; Thread 2 checks spot availability -> true; both park simultaneously.
D. Thread 1 parks vehicle, Thread 2 reads spot as occupied and waits.

Solution

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

    Without synchronization, Thread 1 reads spot as available but before marking it occupied, context switches to Thread 2 which also reads it as available.

  2. Step 2: Both threads proceed to park, causing double-booking

    Because the state update is not atomic, both threads park vehicles in the same spot simultaneously.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Unsynchronized check-then-act -> double-booking race [check]
Hint: Check-then-act gap causes double-booking without synchronization [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