B3.1.2 · Fundamentals of OOP for a single class
Designing classes, and drawing them with UML
Before any code gets written: turning a plain description of a system into the classes, methods, and relationships it actually needs.
Explainer
Meridian Eats, a food delivery startup, hands you one paragraph and asks for a backend: "A customer places an order. Each order is made up of one or more items chosen from the menu. Once an order is ready, a courier delivers it to the customer and marks it as delivered." No classes, no code, just a description. Before writing a single line, that description has to become an actual design, and Unified Modelling Language (UML) is the standard way to draw it.
A UML class diagram is a standard diagrammatic notation for showing a system's classes, each one's attributes and methods, and how the classes relate to one another, so the design can be planned and checked before any code is written.
This statement asks for two separate skills, both tested: (1) deriving which classes, attributes, and methods a system actually needs from its written requirements, and (2) representing that design correctly using UML's own notation, boxes, visibility symbols, relationship lines, and multiplicity. A good design badly drawn, or a correct-looking diagram for the wrong design, both lose marks.
The visibility symbols inside each box (+ public, − private) were introduced when B3.1.5 covered encapsulation. This page's own focus is what sits between the boxes: how classes connect to each other, and what that connection is allowed to mean.
Explainer
Three relationship types, one question each
A line between two classes in a UML diagram is never just "these are related." It always answers one specific question: if the whole is deleted, does the part still make sense on its own?
Association
Two classes are linked, but each one exists completely independently of the other.
Later in this diagram: Order and Courier. An order can exist before any courier is assigned, and a courier keeps existing long after any one delivery finishes.
Aggregation
A "whole and part" link where the part can still exist on its own, and could even belong to a different whole instead.
A separate example, not in this diagram: a Restaurant has MenuItems, but a MenuItem's recipe still means something even if that restaurant closes, and the same dish could be listed by another restaurant entirely.
Composition
A stricter "whole and part" link. The part has no independent life of its own: it is created for one particular whole, and it stops being meaningful the moment that whole is gone.
Later in this diagram: Order and OrderItem. An OrderItem only ever means "one line of this specific order." Cancel the order, and its items are meaningless without it.
Explainer
Reading multiplicity: the numbers at each end of the line
Knowing two classes are associated still leaves the most useful question unanswered: how many? A number sits at each end of every relationship line, and it is not decoration, it is part of the design.
Multiplicity states how many instances of one class can take part in a relationship with a single instance of the class at the other end. It is written as a minimum and a maximum separated by two dots, and * means "no upper limit."
| Notation | Minimum | Maximum | Reads as |
|---|---|---|---|
1 | 1 | 1 | exactly one, never zero and never more |
0..1 | 0 | 1 | optional: either none or a single one |
1..* | 1 | no limit | at least one, possibly many |
0..* | 0 | no limit | any number at all, including none |
* on its own is a common shorthand for 0..*, and both are accepted.
Which end does a number describe? Read it by starting at the class on the opposite side. The number sitting next to a class tells you how many of that class go with one instance of the class across the line.
So in Customer 1 —— 0..* Order, the 0..* next to Order means one Customer can have any number of Orders, including none yet. Reading it back the other way, the 1 next to Customer means each Order belongs to exactly one Customer.
Every multiplicity choice is a real design decision that a later question can ask you to justify. Writing 1..* between Order and OrderItem, rather than 0..*, is a deliberate claim: an order with zero items is not a valid order at all.
Worked example
From requirements to classes: Meridian Eats
The same requirements paragraph from the top of the page, turned into a design one deliberate step at a time.
Step 1. Read the requirements, and mark the candidate nouns and verbs. Nouns tend to become classes. Verbs tend to become methods.
candidate class candidate method
Step 2. List the candidate classes, with just their attributes. No methods yet, just what data each class needs to hold.
| Attribute |
|---|
| name |
| Attribute |
|---|
| order_id |
| status |
| Attribute |
|---|
| name |
| price |
| quantity |
| Attribute |
|---|
| name |
| vehicle_type |
Step 3. Add the methods. Each verb from Step 1 becomes a method on whichever class is responsible for that behaviour.
| Member |
|---|
| name |
| + place_order() |
| Member |
|---|
| order_id |
| status |
| + add_item() |
| + calculate_total() |
| Member |
|---|
| name |
| price |
| quantity |
| Member |
|---|
| name |
| vehicle_type |
| + deliver_order() |
Notice OrderItem got no new methods. Not every class needs behaviour of its own, some exist purely to hold structured data.
Step 4. Identify how the classes relate, and what type each relationship is. This uses the same three types just covered above.
| Classes | Type | Multiplicity | Meaning |
|---|---|---|---|
Customer – Order | Association | 1 to 0..* | places |
Order – OrderItem | Composition | 1 to 1..* | made up of |
Order – Courier | Association | 0..1 to 0..1 | delivered by |
Worked example
The assembled diagram
Everything from the stepper above, drawn as one real UML class diagram. Click any class to see exactly how it connects.
Click a class box to highlight its relationships.
Check your understanding
An OrderItem only ever means "one line of this specific order," and is deleted the moment its order is cancelled. Which relationship type should connect Order and OrderItem?
Common mistake
B3.1.2RecurringCandidates frequently use aggregation and composition interchangeably, drawing whichever diamond they remember more easily rather than checking which one actually matches the existence-dependency described in the scenario.
Answer frame that scores: state whether the part can exist without the whole → name the matching relationship type → justify it using that existence rule specifically, not just "they are related."
What a weak answer looks like: “Order and OrderItem are composed together because they are related.” This never states the actual rule that separates composition from aggregation, so it would score the same even if the wrong diamond were drawn.
What it should say: “Order and OrderItem use composition, not aggregation, because an OrderItem cannot exist without its specific Order: deleting the Order deletes its OrderItems too. This differs from Restaurant and MenuItem, where a MenuItem can still exist even if that Restaurant closes.” Names the rule, applies it, and contrasts it against the other type.
Linking question
How this connects to the rest of the syllabus
In what ways can OOP be applied to database development? (A UML class diagram and a database schema describe almost the same shape from two different angles: a class's attributes become a table's fields, an association with multiplicity becomes a foreign key relationship, and composition, where the part cannot outlive the whole, becomes a cascading delete.)
Revision questions
Past-paper style. Write an answer, then reveal the marking points and mark yourself.
[2]Distinguish between aggregation and composition, using an example of each.
Marking points
评分要点
- Aggregation is a whole-part relationship where the part can exist on its own, for example a football team and its players (a player exists without the team).
- Composition is a stronger whole-part relationship where the part cannot exist without the whole and is destroyed with it, for example a house and its rooms.
- So composition implies ownership and a shared lifetime; aggregation does not.
- 聚合是一种整体-部分关系,部分可以独立存在,例如一支足球队和它的队员(队员离开球队仍然存在)。
- 组合是一种更强的整体-部分关系,部分离开整体就不能存在,并随整体一同销毁,例如一栋房子和它的房间。
- 所以组合意味着所有权和共同的生命周期;聚合则不然。
[3]A requirements document says: "A gym member can book multiple classes. Each class has one instructor." Identify the candidate classes and the relationship between them.
Marking points
评分要点
- Candidate classes: Member, Class (or Session), and Instructor.
- Member to Class: a many-to-many association (a member books many classes; a class has many members), or one-to-many from Member to Booking.
- Class to Instructor: a one-to-many association, each class has exactly one instructor, an instructor may take many classes.
- The multiplicities should be shown on the diagram (1 and many).
- 候选类:Member、Class(或 Session)和 Instructor。
- Member 到 Class:一个多对多关联(一个会员预订多个课程;一个课程有多个会员),或从 Member 到 Booking 的一对多。
- Class 到 Instructor:一个一对多关联,每个课程正好有一位教练,一位教练可以带多个课程。
- 多重性应标在图上(1 和多)。
[4]Construct a UML class diagram fragment showing Order and OrderItem, including multiplicity and the correct relationship notation.
Marking points
评分要点
- Two class boxes: Order and OrderItem, each with a name compartment and at least attributes.
- A line between them with a filled diamond at the Order end, showing composition (an order item does not exist without its order).
- Multiplicity: 1 at the Order end, and 1..* (or *) at the OrderItem end.
- A direction or role name is acceptable but not required.
- 两个类方框:Order 和 OrderItem,各有一个名称格,至少还有属性。
- 两者之间一条连线,Order 端为实心菱形,表示组合(订单项离开其订单就不存在)。
- 多重性:Order 端为 1,OrderItem 端为 1..*(或 *)。
- 方向或角色名可接受但非必需。
Flashcards
Active recall for this statement’s key terms.
Keep this statement’s practice with you
Free account: unlock every revision question and flashcard for B3.1.2, and every other IB CS 2027 statement.