Introduction to UML Class Diagrams

Imagine you are an architect. Before you start laying bricks or pouring concrete, you need a blueprint. In the world of Object Oriented Programming (OOP), we use UML (Unified Modeling Language) Class Diagrams as our blueprints. They allow us to visualize the structure of our program, showing which classes exist, what data they hold, and how they interact with each other before we write a single line of code in Java or Python.

In this chapter, we will learn how to read and draw these diagrams, which is a vital skill for both Paper 2 and your Internal Assessment (the computational solution).

1. The Class Box: The Building Block

Every class in a UML diagram is represented by a rectangle divided into three horizontal sections. Think of it like a business card for a piece of code.

Section 1: The Class Name
This is at the very top. It is usually bold and starts with a capital letter (e.g., Car or Student).

Section 2: Attributes (Data)
This middle section lists what the object "knows." These are the variables or fields. We list them as name : type.

Section 3: Methods (Behaviors)
This bottom section lists what the object "does." These are the functions or procedures. We list them as name(parameters) : returnType.

Example of a "Student" Class Box:

Student
- name : String
- studentID : Integer
+ getGrades() : Array
+ setID(newID : Integer) : void

Key Takeaway:

A class box tells you the identity (Name), the state (Attributes), and the behavior (Methods) of an object in a single glance.

2. Visibility Modifiers: Access Control

In OOP, we care deeply about Encapsulation (keeping data safe). In UML, we use symbols to show who can see specific data or methods. Don't worry if this seems like a lot of symbols; there are really only two main ones you need to master:

  • \( - \) (Minus sign): Represents Private. This means the item can only be accessed within its own class. Most attributes should be private!
  • \( + \) (Plus sign): Represents Public. This means the item can be accessed by any other class. Most methods are public so they can be "called" by other parts of the program.

Quick Tip: If you see a \(\#\) symbol, it stands for Protected, which relates to inheritance (data shared only with "child" classes). However, focus on \( + \) and \( - \) first!

3. Representing Relationships

Classes rarely exist in isolation. They need to talk to each other. We draw lines between class boxes to show these connections.

A. Inheritance (Generalization)

When one class is a "type of" another class (like a Dog is a type of Animal), we use a solid line with a hollow arrow pointing toward the parent class. (Cross-reference: See the "Inheritance and polymorphism" chapter for more on how this works in code).

B. Association

This is a simple relationship where one class "uses" or "has" an instance of another. We represent this with a simple solid line. For example, a Teacher might be associated with a Classroom.

C. Multiplicity (Cardinality)

Multiplicity tells us how many objects are involved in the relationship. We write these numbers near the ends of the association lines:

  • \( 1 \): Exactly one.
  • \( 0..* \): Zero or more (many).
  • \( 1..* \): One or more (at least one).
  • \( 5 \): Exactly five.

Example: A University might have an association with Student. At the Student end of the line, you might see \( 1..* \), because a university must have at least one student to exist!

Key Takeaway:

Lines show connections. The shape of the arrow tells you the kind of connection, and the numbers tell you how many objects are talking to each other.

4. How to Design a Diagram (Step-by-Step)

If you are given a scenario and asked to design a UML diagram, follow these steps:

Step 1: Identify the "Nouns"
Read the problem description. Words like "Customer," "Order," and "Product" are usually your Classes.

Step 2: Identify the "Adjectives"
What details do we need to store? "Price," "Name," or "Date" become your Attributes in the middle section.

Step 3: Identify the "Verbs"
What actions happen? "CalculateTotal," "Register," or "Cancel" become your Methods in the bottom section.

Step 4: Determine Relationships
Ask: "Is a Product a type of something else?" (Inheritance). Ask: "Does a Customer have an Order?" (Association). Draw your lines accordingly.

Did you know?
UML isn't just for Computer Scientists! Systems engineers and business analysts use similar diagrams to map out complex business processes. It's a universal language for logic.

5. Common Mistakes to Avoid

  • Wrong Arrowheads: Using a filled-in arrow for inheritance is a common mistake. It must be a hollow triangle.
  • Forgetting Visibility: Always check if your attributes have a \( - \) and your methods have a \( + \). In IB exams, marks are often lost for missing these signs.
  • Over-complicating: Don't list every possible method. Focus on the ones necessary to solve the specific problem described in the question.

Quick Review Box

UML Basics:
1. Class Box: Name (Top), Attributes (Middle), Methods (Bottom).
2. Visibility: \( + \) is public, \( - \) is private.
3. Inheritance: Solid line with a hollow triangle arrow pointing to the Parent.
4. Multiplicity: Numbers like \( 1..* \) show how many objects are linked.