logoNEURAL COOK
SearchAll PostsTagsNotesAuthor
instagramtwitterfacebookyoutubelinkedinmailgithubrss
Copyright © 2026 All rights reserved.
•
VIKI
Built with Vikramaditya Singh
Built with
VIKI - A posts created with Next.js and Tailwind.css
About
Composition, Asociation & Aggregation
Database locking / atomic updates
The Four Pillars of OOP
60-Day LLD & Machine Coding Mastery Roadmap
Class Design
Advanced Class Design & Robust Architecture
Clean Code
Don't Repeat Yourself (DRY) Principle
Keep it Simple, Stupid (KISS) Principle
You Aren't Gonna Need It (YAGNI) Principle
Design Patterns
Design pattern
Problems
Design a Library Management System (LMS)
Design a Parking Lot
Vending Machine
SOLID
D : Dependency Inversion
I : The Interface Segregation Principle
The SOLID Foundation
L : The Liskov Substitution Principle
O : The Open/Closed Principle
S : The Single Responsibility Principle
UML
UML Activity Diagrams: Modeling Process and Workflow
UML Class Diagrams: Static Structure Modeling
Unified Modeling Language (UML): Comprehensive Guide
UML Sequence Diagrams: Modeling Dynamic Interactions
Use Case Diagrams: Functional Requirement Modeling
Low Level Design›uml

UML Class Diagrams: Static Structure Modeling

summary

# 1. Overview

A Class Diagram is a structural UML diagram that describes the static structure of a system. It shows the classes, their attributes, operations (methods), and the relationships among objects.

  • Code Mapping: It is the only UML diagram that can be mapped directly to object-oriented (OO) languages (Java, C#, C++, etc.), making it the "blueprints" for software construction.
  • Purpose: To visualize the data model and the functional capabilities of the system's components.

image


# 2. Class Representation

A class is depicted as a rectangle divided into three horizontal sections:

  1. Top Section: The class name (e.g., Flight). It should be bold and centered.
  2. Middle Section: The class properties/attributes (data).
  3. Lower Section: The class operations/methods (functionality).

# Visibility (Access Modifiers)

In modern standards, you must denote the visibility of attributes and methods using these symbols:

  • + : Public (Visible to all)
  • - : Private (Visible only within the class)
  • # : Protected (Visible to the class and its subclasses)
  • ~ : Package/Internal (Visible within the same package)

# 3. Relationships and Navigation

Relationships define how classes interact and hold references to one another.

# Association

A solid line representing a structural link between two classes.

  • Bidirectional: A simple solid line. Both classes are aware of each other.
  • Unidirectional: A solid line with an open arrow. Only the "source" class knows about the "target."

# Multiplicity (Cardinality)

Multiplicity specifies the range of permitted instances that can participate in a relationship.

MultiplicityMeaning
1Exactly one
0..1Zero or one (Optional)
* or 0..*Zero to many
1..*One to many
2..4Specific range (Two to four)

# Aggregation vs. Composition

Both model a "Whole-to-Part" relationship, but their lifecycles differ significantly.

  • Aggregation (Weak "Has-A"): Denoted by a hollow diamond at the "whole" end. The part can exist independently of the whole (e.g., a Library and its Books). If the Library is deleted, the Books remain.
  • Composition (Strong "Has-A"): Denoted by a filled (black) diamond at the "whole" end. The part’s lifecycle is tied to the whole (e.g., a Room in a House). If the House is destroyed, the Rooms cease to exist.

# Generalization (Inheritance)

Denoted by a solid line with a hollow triangular arrowhead pointing to the superclass. This represents an "Is-A" relationship where a subclass inherits the state and behavior of a parent class.

# Dependency (Usage)

Denoted by a dashed line with an open arrowhead. It represents a "Uses" relationship. If the supplier class changes, the client class may be affected (e.g., a class using another as a temporary local variable or parameter).


# 4. Interfaces and Abstract Classes

# Abstract Classes

Identified by italicizing the class name or adding the <<abstract>> stereotype. Abstract classes cannot be instantiated.

# Interfaces

An interface defines a contract of behavior. Interfaces are implemented using Realization.

  • Notation: A dashed line with a hollow triangular arrowhead (Realization) or the "lollipop" notation.
  • Stereotype: The name is usually preceded by <<interface>>.

# 5. Advanced Annotations

  • Static Members: To denote a static attribute or method (one that belongs to the class itself rather than an instance), the text is underlined.
  • Derived Attributes: An attribute that can be calculated from other attributes (like age from birthDate) is prefixed with a forward slash (/age).
  • Notes/Comments: Represented as a rectangle with a folded corner, connected to the relevant class by a dashed line.
PreviousUML Activity Diagrams: Modeling Process and WorkflowNextUnified Modeling Language (UML): Comprehensive Guide
CONTENTS
1. Overview2. Class RepresentationVisibility (Access Modifiers)3. Relationships and NavigationAssociationMultiplicity (Cardinality)Aggregation vs. CompositionGeneralization (Inheritance)Dependency (Usage)4. Interfaces and Abstract ClassesAbstract ClassesInterfaces5. Advanced Annotations