In simple terms
A friendly intro before the formal notes — no formulas yet.
Blueprints for Code
UML class diagrams are the architect's blueprints for software. They provide a standard visual way to design the structure of an object-oriented program before writing any code.
Imagine building a large, complex house without any architectural plans. It would be chaotic! UML is like those plans; it allows a team of builders (programmers) to understand the structure, what each room (class) contains, and how they are all connected, ensuring everyone is working from the same design.
- 1
Analyse the problem description to identify the main entities, which will become your classes.
- 2
For each class, define its properties (attributes) and behaviours (methods), assigning appropriate visibility (public, private).
- 3
Determine how the classes relate to each other: is it an 'is-a' (inheritance), 'has-a' (aggregation/composition), or 'uses-a' (dependency) relationship?
- 4
Draw the diagram using standard UML notation, connecting classes and specifying multiplicities to show how many objects are involved in each relationship.
Explore the concept
Use the live diagram and synced steps — play it or tap a step card to walk through.
Full topic notes
Formal explanation with the rigour you need for the exam.
Understanding the UML Class Diagram
A class diagram is a static, structural diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. It is the most common and fundamental type of UML diagram used in OOP. Think of it as a detailed blueprint for the classes you will eventually code.
Each class is represented by a rectangle divided into three compartments.
Top compartment: Class Name (in bold).
Middle compartment: Attributes (variables), written as visibility name: type.
Bottom compartment: Methods (functions), written as visibility name(parameters): returnType.
Visibility Modifiers: + for public, - for private, # for protected, ~ for package (default).
Key Relationships Between Classes
Classes in an OOP system rarely exist in isolation. They interact and relate to each other in various ways. UML provides specific notation to model these relationships, which is crucial for understanding the system's architecture.
Inheritance (Generalisation): An 'is-a' relationship. A subclass inherits properties and methods from a superclass. Notation: A solid line with a hollow triangular arrowhead pointing from the child to the parent class. Example: A Car and a Truck are both types of Vehicle.
Association: Represents a relationship where objects of one class are connected to objects of another. It's the most general relationship. Notation: A solid line between classes. You can add multiplicity and role names.
Aggregation: A 'has-a' relationship, representing a whole-part connection where the part can exist independently. Notation: A solid line with a hollow diamond on the side of the 'whole' class. Example: A University has Departments.
Composition: A strong 'owns-a' relationship where the part cannot exist without the whole. Its lifecycle is dependent on the whole. Notation: A solid line with a filled diamond on the side of the 'whole' class. Example: A Book has Pages.
Dependency: A 'uses-a' relationship, where one class depends on another (e.g., as a method parameter), but not as an instance variable. Notation: A dashed line with an open arrowhead pointing to the class being depended upon.
Designing a System with Multiple Relationships
Real-world systems involve a network of interacting classes. A single UML diagram can capture multiple types of relationships simultaneously, providing a holistic view of the system's architecture. The key is to break down the problem description sentence by sentence to identify each class and its connections.
Worked examples
See the formulas applied — reveal one step at a time, like the exam.
A school management system needs to model Students and Lockers. Each student is assigned exactly one locker. A locker is assigned to at most one student. A locker cannot exist without being part of the school, but a student can. Model the relationship between a Student and a Locker. Include attributes: studentID: int, name: String for Student; and lockerNumber: int, location: String for Locker. Both classes have a getDetails() method.
- 1
1. Identify Classes: Student and Locker.
Design a UML class diagram for a simple online shopping system. The system has Customers. Each Customer has a unique ShoppingCart. The ShoppingCart contains multiple Items. An Item has a price and name. When a Customer account is deleted, their ShoppingCart is also deleted. However, the Items themselves still exist in the system's product catalogue. A Customer also has an Address. The Address is part of the Customer's profile.
- 1
1. Identify Classes: Customer, ShoppingCart, Item, Address.
How it all connects
The big idea sits in the middle — tap a linked idea to explore the link.
Tap a linked idea to see how it connects back to the main topic — that connection is what examiners reward.
Glossary
Try to recall each definition before you reveal it.
Quick check
Answer in your head first — then tap to check. No pressure.
Revision flashcards
Flip the card. Test yourself before the exam.
What does UML stand for?
Unified Modeling Language. It's a standardised graphical notation used for designing and documenting object-oriented software systems.
Key takeaways
Review these before you close the topic — retrieval beats re-reading.
- ✓
Each class is represented by a rectangle divided into three compartments.
- ✓
Top compartment: Class Name (in bold).
- ✓
Middle compartment: Attributes (variables), written as visibility name: type.
- ✓
Bottom compartment: Methods (functions), written as visibility name(parameters): returnType.
- ✓
Visibility Modifiers: + for public, - for private, # for protected, ~ for package (default).
Practice — then mark it
The whole point: a real Cambridge question, marked mark-by-mark.
Practice Exam Questions
Practice Exam Questions
Extra simulations & links
PhET, GeoGebra and other curated tools — open in a new tab.
Frequently asked
Checkpoint
One marked question is worth ten re-reads — close the loop before you move on.
Reading it isn’t knowing it — prove it.
Before you move on: do Practice Exam Questions on paper, snap a photo, and get examiner-style feedback on exactly where you win and lose marks.