← QCE Digital Solutions Unit 3

Why programs are divided into modules

A self-contained part of a program that does one job, so it can be built, tested on its own, reused in other places and changed without breaking the rest of the solution.

Part of: QCE Digital Solutions Unit 3 — Real-World Problems and Solution Requirements — Module 45

Understanding Why programs are divided into modules in QCE Digital Solutions Unit 3

What it does: The one calculateGST module is called twice, so the code is written once and reused. Each call is a separate module with its own single job, so changing one does not break the others. A module should have one clear job. This keeps it easy to understand, test and change. Modules can be tested separately. You can check one small part works before joining it to the rest. Reusing one module avoids repeated code. If the rule changes, you fix it in only one place. A self-contained module can be changed without breaking the rest of the solution. A name that describes one job shows the module has a clear purpose. A name like doEverything suggests the module is doing too much.

Common mistakes: The module getTotal has one job: multiply the price by the quantity. Adding them gives the wrong result. It should be 'return price * qty'. Testing the module on its own with 18 should give true, but 'age > 18' gives false. The test exposes the boundary error. It should be 'return age >= 18'.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Why programs are divided into modules to a class →

This module's key terms are also in a printable crossword (Modules 194–250) and word search (Modules 194–337).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which describes a well-designed program module?
It does many unrelated jobs in one blockIt does one job and is self-contained
Matches
define doEverything() read input check input calculate total print receipt
↓
One module does many jobs. It should be split into smaller modules (validate, calculate, display) so each can be tested and changed alone.
Applying
Meanings
Term
module
Meaning
A self-contained part of a program that does one job, so it can be built, tested on its own, reused in other places and changed without breaking the rest of the solution.
Practice
define calcGST(price)
Testing
Gaps
calculateTotal(price, qty)
Check Answer
Spots
1define getTotal(price, qty)
2 return price + qty

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Walrus' badge — Method Master, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Which describes a well-designed program module?
A. It does one job and is self-contained ✓
B. It does many unrelated jobs in one block
A module should have one clear job. This keeps it easy to understand, test and change.
2. A student's program has a module that calculates GST. Why is this useful when testing?
A. The GST module can be tested on its own ✓
B. The whole program must be finished before any testing
Modules can be tested separately. You can check one small part works before joining it to the rest.
3. A shop app needs to validate a phone number on three different screens. What is the best approach?
A. Copy and paste the same code onto each screen
B. Write one validation module and reuse it on each screen ✓
Reusing one module avoids repeated code. If the rule changes, you fix it in only one place.
4. The tax rate changes and you edit the calculateTax module. In a well-modularised solution, what happens to the other modules?
A. Every module must be rewritten
B. They keep working without changes ✓
A self-contained module can be changed without breaking the rest of the solution.
5. Which module name best shows a single job?
A. calculateTotalPrice ✓
B. doEverything
A name that describes one job shows the module has a clear purpose. A name like doEverything suggests the module is doing too much.

Match the Pairs

calculateGST(price) → A module with one job: it only works out the GST for a price and does nothing else
assert calculateGST(100) == 10 → A test that checks one module on its own, without running the rest of the program
Reusing a module: the same module is called from different places instead of rewriting the code → total ← calculateGST(cartPrice) + calculateGST(deliveryFee)
One module, one job: each module does a single task and a main program joins them together → validateInput() processOrder() showReceipt()
define doEverything() read input check input calculate total print receipt → One module does many jobs. It should be split into smaller modules (validate, calculate, display) so each can be tested and changed alone.
price ← price * 1.1 ... same line copied into 6 places → The same code is copied in many places instead of being placed in one reusable module that is called when needed.

Key Term

module
A self-contained part of a program that does one job, so it can be built, tested on its own, reused in other places and changed without breaking the rest of the solution.

Fill in the Blanks

1. define calculateTotal(price, qty) return price * qty
Hint: Type the keyword that creates a new module (function) that does one job.
2. define addGST(price) return price * 1.1
Hint: Type the keyword that sends the module's result back to the part of the program that called it.
3. total1 ← calculateTotal(5, 2) total2 ← calculateTotal(8, 3)
Hint: Type the name of the module being reused a second time instead of rewriting its code.
4. if addGST(100) = 110 then print "Test passed" end if
Hint: Type the comparison operator that checks the module's output equals the expected value when testing it on its own.
5. marks ← getMarks() avg ← calculateAverage(marks) print avg
Hint: Type the variable that holds the data produced by one module and passed into the next module.

Spot the Error

Question 1
A define getTotal(price, qty)
B return price + qty
C total <- getTotal(5, 3)
D print total
Line B — The module getTotal has one job: multiply the price by the quantity. Adding them gives the wrong result. It should be 'return price * qty'.
Question 2
A define isAdult(age)
B return age > 18
C print isAdult(18) // true
D print isAdult(17) // false
Line B — Testing the module on its own with 18 should give true, but 'age > 18' gives false. The test exposes the boundary error. It should be 'return age >= 18'.
Question 3
A define square(n)
B return n * n
C area <- square(side, side)
D print area
Line C — The square module takes one input, n. Calling it with two arguments does not match its header. Reusing the module means calling it as 'square(side)'.
Question 4
A define average(a, b)
B total <- a + b
C print total / 2
D print average(4, 8)
Line C — A module that does a calculation should return its result so other code can reuse it. Printing inside the module gives the caller no value. It should be 'return total / 2'.
Question 5
A define greet(name)
B print "Hello " + userName
C greet("Ava")
D greet("Liam")
Line B — The module uses userName, a variable from outside, instead of its parameter name. This makes it depend on the rest of the program and so it cannot be reused or tested alone. It should use 'name'.

Student with a class code? Join your class →