UML Design
UML (Unified Modeling Language) is the industry-standard language used in software engineering for Object-Oriented Analysis and Design (OOAD).
It acts as a blueprint for software systems, enabling developers, architects, and stakeholders to visualize, specify, construct, and document complex architectures before writing a single line of code.
Diagram Categories
Section titled “Diagram Categories”UML consists of over 13 diagram types, broadly categorized into two groups:
- Structural Diagrams: Visualize the static, architectural layout of the system (e.g., Class Diagram, Component Diagram).
- Behavioral Diagrams: Visualize the dynamic execution and flow of the system over time (e.g., Use Case, Sequence Diagram).
Hierarchy showing the split between static (Structural) and dynamic (Behavioral) modeling.
The Class Diagram
Section titled “The Class Diagram”A Class Diagram represents the static structure of an object-oriented system. It models the classes, their attributes (data), operations (methods), and the logical relationships between them.
Class diagrams translate almost perfectly into OOP code (Java, C++, TypeScript).
Anatomy of a Class Box
Section titled “Anatomy of a Class Box”| Element | Description | Code Equivalent |
|---|---|---|
| Class | The blueprint or template for objects. | class Car { ... } |
| Attribute | Properties, states, or data members. | private String color; |
| Method | Functions, behaviors, or operations. | public void start(); |
A standard class box showing visibility markers (+ for public, - for private).
Object Associations
Section titled “Object Associations”Understanding how objects relate to one another is the core of LLD. UML provides specific notations for different types of “Has-a” and “Knows-a” relationships.
1. Composition (Strong Containment)
Section titled “1. Composition (Strong Containment)”A “Has-a” relationship where the child object’s lifetime is tightly bound to the parent object.
If the parent is destroyed, the child is also destroyed. The child cannot exist independently.
- Notation: A solid, filled diamond on the parent’s side.
A House strictly owns its Rooms. You cannot have a Room floating in the void without a House.
2. Aggregation (Weak Containment)
Section titled “2. Aggregation (Weak Containment)”A “Has-a” relationship where the child has an independent lifecycle.
The parent contains the child, but if the parent is destroyed, the child objects continue to exist.
- Notation: A hollow diamond on the parent’s side.
A Team aggregates Players. If the Team disbands, the Players still exist and can join other teams.
3. Association (Unidirectional)
Section titled “3. Association (Unidirectional)”A “Knows-about” relationship. One class uses or interacts with another, but the interaction flows in one direction only.
- Notation: A solid line with an open arrow pointing to the known class.
A Customer places an Order. The Customer object maintains a reference to the Order, but the Order object has no programmatic link back to the Customer.
4. Association (Bidirectional)
Section titled “4. Association (Bidirectional)”Two classes are mutually aware of each other. Both classes maintain a reference to the other.
- Notation: A simple solid line without any arrows.
A Teacher knows their Students, and the Students know their Teacher. Modifying one side usually requires updating the other to maintain consistency.