{"title":"Class Diagram","description":null,"content":"**Unified Modeling Language (UML)** is a standard way to visualize the design of a software system.\n\nAmong the many diagrams offered by UML, **class diagrams** are perhaps the most widely used.\n\nUML class diagram provides a static view of an object oriented system, showcasing its **classes, attributes, methods, and the relationships among objects.**\n\nIn this article, we will explore the building blocks of UML class diagram, how to represent them, different types of class relationships and provide real-world examples for each representation.\n\n---\n\n# 1. Anatomy of a Class\n\nThe most basic element in a class diagram is, unsurprisingly, a class. In UML, a class is drawn as a rectangle divided into three compartments: the class name at the top, attributes in the middle, and methods at the bottom.\n\n\n```mermaid\nclassDiagram\n class BankAccount {\n -accountNumber: String\n -ownerName: String\n -balance: double\n +deposit(amount: double): void\n +withdraw(amount: double): boolean\n +getBalance(): double\n }\n\n style BankAccount fill:#00ceff,stroke:#000,color:#000\n```\n\n\nLet's walk through each compartment.\n\n#### **Name compartment (top)**\n\nThis holds the class name, always in PascalCase. It's the identity of the class.\n\n#### **Attributes compartment (middle)**\n\nThese are the data fields the class holds. Each attribute follows the format: \n\n- `visibility name: type`\n\nIn the diagram above, `-accountNumber: String` means a private field named `accountNumber` of type `String`. The minus sign (`-`) is the visibility marker for private.\n\nYou can optionally add multiplicity and default values to make the attribute more precise:\n\n- `visibility name: type [multiplicity] = defaultValue`\n\nFor example, `-transactions: List [0..*]` tells you the field holds zero or more items.\n\n#### **Methods compartment (bottom)**\n\nThese are the operations the class can perform. The format is:\n\n- `visibility name(parameterList): returnType`\n\nSo `+deposit(amount: double): void` is a public method named `deposit` that takes a double parameter and returns nothing. Parameters are written as `name: type`, separated by commas if there are multiple.\n\n### Visibility Markers\n\nEvery attribute and method is prefixed with a visibility marker that controls who can access it.\n\n\n| Marker | Access Level | Meaning |\n| --- | --- | --- |\n| `+` | Public | Accessible from any class |\n| `-` | Private | Accessible only within the same class |\n| `#` | Protected | Accessible within the class and its subclasses |\n| `~` | Package | Accessible within the same package (Java-specific) |\n\n\n---\n\n# 2. Special Class Types\n\nNot everything in your design is a concrete class. Interfaces define contracts without implementation. Abstract classes provide partial implementations. Enumerations define fixed sets of values. Each has its own UML notation.\n\n## Interfaces\n\nAn interface specifies what a class must do, without saying how. In UML, an interface looks like a class rectangle with the `<>` stereotype above the name. Since interfaces have no state, the attributes compartment is usually empty.\n\n\n```mermaid\nclassDiagram\n class Payable {\n <>\n +calculateAmount(): double\n +processPayment(method: String): boolean\n }\n\n style Payable fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe `<>` label is the key visual signal. When you see this in a diagram, you know that any class connected to `Payable` with a dashed arrow must implement `calculateAmount()` and `processPayment()`. \n\n## Abstract Classes\n\nAn abstract class sits between a concrete class and an interface. It can have both implemented methods (shared behavior) and abstract methods (behavior that subclasses must define). In UML, abstract classes are marked with the `<>` stereotype, and abstract method names are written in italics.\n\n\n```mermaid\nclassDiagram\n class Shape {\n <>\n #color: String\n +getArea(): double*\n +getPerimeter(): double*\n +getColor(): String\n }\n\n style Shape fill:#9775fa,stroke:#000,color:#000\n```\n\n\nThe `<>` stereotype tells you this class can't be instantiated directly. Looking at the methods, `getArea()` and `getPerimeter()` are abstract (shown in italics), meaning `Shape` declares them but provides no implementation. \n\nAny subclass, say a `Circle` or a `Rectangle`, must override these with its own logic. `getColor()`, on the other hand, is a concrete method. Since all shapes retrieve their color the same way, it's implemented once in `Shape` and inherited by every subclass.\n\nUse abstract classes when subclasses share common state (like `color`) or behavior (like `getColor()`) but differ in specific operations. Use interfaces when unrelated classes need to support the same contract without sharing any state or implementation.\n\n## Enumerations\n\nAn enumeration defines a fixed set of named constants. In UML, enums use the `<>` stereotype, and the values are listed in the attributes compartment.\n\n\n```mermaid\nclassDiagram\n class OrderStatus {\n <>\n PENDING\n CONFIRMED\n PREPARING\n SHIPPED\n DELIVERED\n CANCELLED\n }\n\n style OrderStatus fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nEnums are useful for representing states, types, or categories that have a fixed number of values. In the parking lot example, `VehicleType` might be an enum with `CAR`, `MOTORCYCLE`, and `TRUCK`. In an e-commerce system, `PaymentMethod` could be `CREDIT_CARD`, `DEBIT_CARD`, `UPI`, `WALLET`.\n\n---\n\n# 3. Relationships\n\nClasses rarely exist in isolation. The real power of a class diagram is in the lines connecting the boxes. UML defines six types of relationships, each with its own arrow style and meaning. These range from the weakest coupling (dependency) to the strongest (inheritance and realization).\n\n## 1. Dependency (Weakest)\n\nA dependency means one class temporarily uses another, typically as a method parameter, a local variable, or a return type. The dependent class doesn't store a reference to the other class as a field. It just needs it for a specific operation.\n\n\n```mermaid\nclassDiagram\n class OrderService {\n +placeOrder(order: Order): void\n }\n class EmailService {\n +sendConfirmation(to: String): void\n }\n OrderService ..> EmailService : uses\n\n style OrderService fill:#00ceff,stroke:#000,color:#000\n style EmailService fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe **dashed arrow** (`..>`) is the UML notation for dependency. `OrderService` depends on `EmailService` because it calls `EmailService.sendConfirmation()` inside the `placeOrder()` method.\n\nBut `OrderService` doesn't hold an `EmailService` field. It might receive it as a parameter, or create it locally, or look it up from a service locator. The relationship exists only during that method call.\n\n**When to use dependency:** When class A calls a method on class B, but doesn't store B as a field. If the reference lives only inside a method body, it's a dependency.\n\n## 2. Association\n\nAssociation means one class knows about another and holds a reference to it as a field. This is the most common relationship in OOP. It models a \"has-a\" or \"uses-a\" relationship where the connection is persistent, not just for a single method call.\n\n\n```mermaid\nclassDiagram\n class Student {\n -name: String\n -teacher: Teacher\n }\n class Teacher {\n -name: String\n -students: List~Student~\n }\n Student \"*\" --> \"1..*\" Teacher : learns from\n\n style Student fill:#00ceff,stroke:#000,color:#000\n style Teacher fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe **solid arrow** (`->`) is the UML notation for association. `Student` holds a reference to `Teacher` as a field. The multiplicity labels tell you that many students can be associated with one or more teachers. Both objects exist independently: a student doesn't cease to exist if the teacher is removed, and vice versa.\n\n**When to use association:** When class A stores a reference to class B as a field, and both objects have independent lifecycles.\n\n## 3. Aggregation\n\nAggregation is a specialized form of association that models a \"whole-part\" relationship with weak ownership. The whole contains the parts, but the parts can exist independently. If the whole is destroyed, the parts survive.\n\n\n```mermaid\nclassDiagram\n class Playlist {\n -name: String\n -songs: List~Song~\n +addSong(song: Song): void\n +removeSong(song: Song): void\n }\n class Song {\n -title: String\n -artist: String\n -duration: int\n }\n Playlist \"1\" o-- \"*\" Song : contains\n\n style Playlist fill:#00ceff,stroke:#000,color:#000\n style Song fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe **hollow diamond** on the `Playlist` side is the UML notation for aggregation. `Playlist` is the \"whole\" and `Song` is the \"part.\" \n\nThe critical point: if you delete the playlist, the songs still exist in the music library. A song can belong to multiple playlists simultaneously. The parts are passed into the whole from outside, not created internally.\n\n**When to use aggregation:** When one class contains another, but the contained objects have their own independent lifecycle and can be shared across multiple containers.\n\n## 4. Composition\n\nComposition is the stronger version of aggregation. It's a \"whole-part\" relationship with strong ownership. The whole creates, manages, and destroys the parts. If the whole is destroyed, the parts go with it.\n\n\n```mermaid\nclassDiagram\n class Order {\n -orderId: String\n -lineItems: List~LineItem~\n +addItem(name: String, qty: int, price: double): void\n +getTotal(): double\n }\n class LineItem {\n -productName: String\n -quantity: int\n -unitPrice: double\n +getSubtotal(): double\n }\n Order \"1\" *-- \"*\" LineItem : contains\n\n style Order fill:#00ceff,stroke:#000,color:#000\n style LineItem fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe **filled diamond** on the `Order` side is the UML notation for composition. `Order` owns its `LineItem` objects completely. Line items are created inside order methods, not passed in from outside. They have no meaning without their parent order. When the order is deleted, the line items are deleted too.\n\n**When to use composition:** When the part has no independent identity or purpose outside the whole, and the whole controls the part's entire lifecycle.\n\n## 5. Inheritance (Generalization)\n\nInheritance represents an \"is-a\" relationship where a subclass extends a superclass, inheriting its attributes and methods. The subclass can add its own fields and methods, and can override inherited behavior.\n\n\n```mermaid\nclassDiagram\n class Animal {\n #name: String\n #age: int\n +makeSound(): String\n +move(): void\n }\n class Dog {\n -breed: String\n +makeSound(): String\n +fetch(): void\n }\n class Cat {\n -indoor: boolean\n +makeSound(): String\n +purr(): void\n }\n Animal <|-- Dog\n Animal <|-- Cat\n\n style Animal fill:#38d9a9,stroke:#000,color:#000\n style Dog fill:#00ceff,stroke:#000,color:#000\n style Cat fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe **solid line with a hollow triangle** pointing at the superclass is the UML notation for inheritance. `Dog` and `Cat` both inherit `name`, `age`, and `move()` from `Animal`. Each overrides `makeSound()` to provide its own implementation and adds its own unique methods (`fetch()` for `Dog`, `purr()` for `Cat`).\n\n**When to use inheritance:** When there's a genuine \"is-a\" relationship with shared state and behavior. A `Dog` is an `Animal`. A `SavingsAccount` is a `BankAccount`. Don't use inheritance just to reuse code. If the \"is-a\" relationship doesn't hold naturally, prefer composition.\n\n## 6. Realization (Implementation)\n\nRealization is the relationship between a class and an interface it implements. The class promises to provide concrete implementations of all methods declared in the interface.\n\n\n```mermaid\nclassDiagram\n class Flyable {\n <>\n +fly(): void\n +getAltitude(): double\n }\n class Bird {\n -species: String\n +fly(): void\n +getAltitude(): double\n }\n class Airplane {\n -model: String\n -engineCount: int\n +fly(): void\n +getAltitude(): double\n }\n Flyable <|.. Bird\n Flyable <|.. Airplane\n\n style Flyable fill:#38d9a9,stroke:#000,color:#000\n style Bird fill:#00ceff,stroke:#000,color:#000\n style Airplane fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe **dashed line with a hollow triangle** pointing at the interface is the UML notation for realization. `Bird` and `Airplane` are completely unrelated classes, one is biological, the other is mechanical, but both implement the `Flyable` interface. This is why interfaces are so powerful: they let unrelated classes share a contract without forcing them into the same inheritance hierarchy.\n\n**Inheritance vs Realization:** Inheritance says \"I am a type of you and I get your code.\" Realization says \"I can do what you describe, but I implement it my own way.\" Inheritance uses a solid line (the subclass gets actual code). Realization uses a dashed line (the class only gets a contract to fulfill).\n\n## Relationship Strength Spectrum\n\nAll six relationships fall on a spectrum from weakest to strongest coupling. This is worth memorizing because interviewers often ask you to rank them.\n\n\n```mermaid\nflowchart LR\n A[Dependency]:::red --> B[Association]:::orange --> C[Aggregation]:::yellow --> D[Composition]:::green --> E[Inheritance]:::teal --> F[Realization]:::purple\n\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\n**Weakest to strongest:** Dependency (temporary use) < Association (persistent reference) < Aggregation (weak whole-part) < Composition (strong whole-part) < Inheritance (structural \"is-a\") < Realization (contractual \"can-do\")\n\nThe general design principle: prefer weaker relationships when possible. Dependency is better than association if you don't need a persistent reference. Association is better than composition if the part doesn't need lifecycle binding. Weaker coupling means more flexible, maintainable code.\n\n---\n\n# 4. Combined Example: Online Bookstore\n\nLet's put everything together with a realistic example. Imagine you're asked to design the core domain model for an online bookstore. Here's the class diagram.\n\n\n```mermaid\nclassDiagram\n class Book {\n -isbn: String\n -title: String\n -author: String\n -price: double\n }\n class Customer {\n -customerId: String\n -name: String\n -email: String\n }\n class Order {\n -orderId: String\n -status: OrderStatus\n -orderItems: List~OrderItem~\n +calculateTotal(): double\n }\n class OrderItem {\n -quantity: int\n -unitPrice: double\n +getSubtotal(): double\n }\n class PaymentProcessor {\n <>\n +charge(amount: double): boolean\n +refund(orderId: String): boolean\n }\n class CreditCardProcessor {\n -cardNumber: String\n +charge(amount: double): boolean\n +refund(orderId: String): boolean\n }\n class PayPalProcessor {\n -email: String\n +charge(amount: double): boolean\n +refund(orderId: String): boolean\n }\n class OrderStatus {\n <>\n PENDING\n CONFIRMED\n SHIPPED\n DELIVERED\n CANCELLED\n }\n\n Customer \"1\" --> \"*\" Order : places\n Order \"1\" *-- \"1..*\" OrderItem : contains\n OrderItem \"*\" --> \"1\" Book : references\n Order --> OrderStatus : has status\n Order ..> PaymentProcessor : uses\n PaymentProcessor <|.. CreditCardProcessor\n PaymentProcessor <|.. PayPalProcessor\n\n style Book fill:#69db7c,stroke:#000,color:#000\n style Customer fill:#f783ac,stroke:#000,color:#000\n style Order fill:#00ceff,stroke:#000,color:#000\n style OrderItem fill:#69db7c,stroke:#000,color:#000\n style PaymentProcessor fill:#9775fa,stroke:#000,color:#000\n style CreditCardProcessor fill:#ffa94d,stroke:#000,color:#000\n style PayPalProcessor fill:#ffa94d,stroke:#000,color:#000\n style OrderStatus fill:#ffd43b,stroke:#000,color:#000\n```\n\n\nLet's trace through the diagram: \n\n- **Composition**: `Order` owns its `OrderItem` objects. They're created when the order is placed, belong to exactly one order, and are deleted if the order is deleted. Filled diamond on the `Order` side.\n- **Association**: `Customer` --> `Order` is a persistent reference, but both exist independently. `OrderItem` --> `Book` is similar: the item references a book but doesn't own it.\n- **Dependency**: `Order` uses `PaymentProcessor` during checkout but doesn't store it as a field. The relationship is temporary.\n- **Realization**: `CreditCardProcessor` and `PayPalProcessor` both implement the `PaymentProcessor` interface, providing different payment strategies behind the same contract.\n- **Enumeration**: `Order` --> `OrderStatus` uses a fixed set of values to track order state.","pageType":"lld-interviews"}

Get Premium