What is "UML Class Diagrams" about?

The industry standard for mapping code architecture. Learn class boxes, access modifiers, and technical notation to ace your next LLD interview.

What topics does "UML Class Diagrams" cover?

This article covers: UML, LLD, Class Diagram, Software Engineering, OOP.

UML Class Diagrams

In the previous post, we looked at Use Cases to map out features. But when it's time to actually write the code, we need to know exactly what attributes and methods each class has. This is where Class Diagrams come in - the blueprints for your code.

The Essentials

Class boxes use a 3-row layout: Name, Attributes, Methods.
Access modifiers (+, -, #) provide instant visibility context.
Relationships like Multiplicity and Composition define how objects live and die together.

ExpandA complete Class Diagram example showing inheritance and composition

The Three Perspectives of a Class Diagram

One thing that clicked for me is that you can draw a class diagram at different stages of the project. Depending on who you're talking to, you choose one of these three levels of detail:

Conceptual Perspective: You are describing entities in the real world. This is language-independent and focus on the "ideas" in the domain.
Specification Perspective: You are describing software abstractions (interfaces) but not how they are implemented. You see the "contract" but not the "code."
Implementation Perspective: This is the most detailed. It describes the actual implementation in a specific language (like Java or TypeScript). This is what you'll usually draw in a machine coding round.

Representing a Class

A class is a rectangle with three rows. Only the Class Name is mandatory - because without a name, even the best psychic can't guess what your box refers to!

Access Modifier Shorthand

UML uses short symbols that map directly to Encapsulation:

+ : public (visible to all)
- : private (visible only inside the class)
# : protected (visible to children)
~ : package local (visible to the same module)

Attributes & Methods

Attributes: [symbol] name : DataType. Example: - age : int
Methods: [symbol] name(params) : ReturnType. Example: + calculateBonus(int) : double

In the method signature, you can also specify the direction of parameters: in (input), out (output), or inout (both).

The 6 Main Relationships

This is where most engineers get confused. UML defines six ways classes can talk to each other.

1. Association (The Connection)

A simple line connecting two classes. It represents a relationship between instances (e.g., a Person works for a Company).

Multiplicity: You can specify how many objects participate (e.g., 1 to * for many).

2. Inheritance / Generalization

A solid line with a hollow arrow pointing to the parent. This maps directly to Inheritance in code.

If the parent is an Abstract Class, the name is written in italics.

3. Realization (The Interface)

A dashed line with a hollow arrow pointing to an interface. This is when a class implements a behavioral contract.

Interfaces are marked with <<InterfaceName>>.

4. Dependency (The Temporary Use)

A dashed line with a regular arrowhead. It means Class A uses Class B in a method (e.g., as a parameter), but doesn't store it in a field. If B changes, A might break.

5. Aggregation (The "Has-A")

A line with a hollow diamond at the aggregator end. It means Class A "has" Class B, but B can exist on its own.

Example: A Workstation has a Chair. If the workstation is deleted, the chair still exists.

6. Composition (The "Death Bond")

A line with a solid diamond. This is a stronger form of aggregation where the parts die when the whole is destroyed.

Example: A Body is made of Organs. They cannot function (or exist) by themselves.

Practical Advice: Clear Over Perfect

The goal of a class diagram is to remove ambiguity. If you're in an interview and can't remember if the diamond is hollow or solid, just write a comment. Your design choices (like choosing Composition over Inheritance) matter far more than your memorization of the 700-page UML spec.