Class Diagram in UML

Introduction

At the core of object-oriented design lies a simple question: What are the things in the system and how do they relate? Class diagrams answer that question. They are one of the most powerful — and frequently used — diagrams in UML.

In this tutorial, we’ll break down the class diagram for absolute beginners. You’ll learn what a class diagram is, why it matters, how to read and draw one, and how to use it to model real-world systems like a school management system.

What is a Class Diagram?

A Class Diagram represents the structure of a system by showing its classes, their attributes and methods (also called operations), and the relationships between them.

Think of it as the architectural blueprint of your software. It tells you:

• What objects exist in the system (classes like Student, Teacher, Course)
• What data they hold (attributes like name, ID, subject)
• What they can do (methods like enroll(), assignGrade())
• How they relate to each other (associations like Student enrolled in Course)

Class Diagram Syntax and Notation

In UML, a class is represented as a rectangle divided into three parts:

• Top: Class Name
• Middle: Attributes (fields or properties)
• Bottom: Operations (methods)

+ Student
-------------------------
- name : String
- rollNumber : int
-------------------------
+ enroll(subject : String) : void
+ viewMarks() : void

Visibility Markers

• + Public
• - Private
• # Protected

Attributes follow the format: visibility name : type
Methods follow: visibility name(parameters) : returnType

Types of Relationships

Class diagrams are as much about relationships as they are about the classes themselves. Let’s walk through the key types:

1. Association

Represents a basic relationship between two classes.

Student ----------------- Course

Meaning: A student is enrolled in courses.

2. Multiplicity

Defines how many instances of a class can be associated with another.

• 1 = exactly one
• 0..* = zero or more
• 1..* = at least one
• 0..1 = zero or one

Student 1 -------- 0..* Course

3. Aggregation

A “has-a” relationship. Denoted by a hollow diamond.

Teacher ◇----------- Class

Meaning: A Teacher “has” multiple classes, but classes can exist independently of the teacher.

4. Composition

Stronger than aggregation. Denoted by a filled diamond.

School ◆----------- ClassRoom

Meaning: ClassRoom cannot exist without the School.

5. Inheritance (Generalization)

One class inherits from another. Denoted by a triangle arrow.

Person △--------- Student
        |
        |
        └--------- Teacher

Real-World Example: School Management System

Classes to Model

• Person: Superclass for common attributes like name, email
• Student: Inherits from Person; has attributes like roll number
• Teacher: Inherits from Person; teaches multiple subjects
• Subject: Linked to both Students and Teachers

+ Person
-----------------------
- name : String
- email : String

+ Student extends Person
-----------------------
- rollNumber : int
- classLevel : String

+ Teacher extends Person
-----------------------
- employeeId : String
- subjectsTaught : List<Subject>

+ Subject
-----------------------
- title : String
- code : String

Step-by-Step: Creating a Class Diagram

Step 1: Identify Classes

List all key entities. For a school system, these might include: Student, Teacher, Subject, Admin.

Step 2: Define Attributes

What data does each class hold?

• Student: name, rollNumber
• Subject: title, code

Step 3: Define Methods

What can each class do?

• Student: enroll(), viewMarks()
• Teacher: assignMarks(), uploadMaterial()

Step 4: Establish Relationships

Use associations, inheritance, and multiplicity to connect the dots.

Step 5: Apply UML Notation

Use the correct symbols and follow visibility rules to sketch your diagram.

Best Practices

• Keep diagrams clean: Don’t overload with too many classes in one view.
• Use abstraction: Group common features in superclasses.
• Be consistent: Use clear and descriptive class names.
• Add multiplicity: Don’t leave relationships ambiguous.
• Document assumptions: Add notes where needed for clarity.

Common Pitfalls to Avoid

• Forgetting method return types
• Omitting multiplicity on relationships
• Using inconsistent visibility (e.g., mixing public/private haphazardly)
• Trying to model everything at once (break it into smaller parts)

Using Tools to Draw Class Diagrams

You can draw UML class diagrams by hand, but tools make it more efficient. Popular options:

• StarUML: Excellent for Java modeling
• Lucidchart: Great for team collaboration
• PlantUML: For text-to-diagram modeling
• draw.io: Easy and free, browser-based

Conclusion

Class diagrams are a developer’s map to understanding a system’s backbone. They tell you what exists and how it's structured — much like the table of contents of a textbook. Mastering them allows you to design, explain, and evolve your software with confidence.

As you work with Java and other object-oriented languages, you’ll see how naturally class diagrams translate into code. In our next tutorial, we’ll explore how to move from a UML class diagram to actual Java classes — bridging design and implementation.