In simple terms
A friendly intro before the formal notes — no formulas yet.
Program Design
This lesson explores the principles of program design, focusing on top-down design, stepwise refinement, and the use of structure diagrams. It equips students with the skills to plan and structure complex programs before writing a single line of code, a crucial practice for developing robust and maintainable software.
- 1
Manages Complexity: Large problems become a series of smaller, solvable ones.
- 2
Facilitates Teamwork: Different developers can be assigned different modules to work on concurrently.
- 3
Simplifies Testing & Debugging: Each module can be tested independently (unit testing). If a bug occurs, it's easier to isolate which module is at fault.
- 4
Promotes Reusability: A well-defined module, like 'CalculateVAT', can be reused in other programs.
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.
The Core Principles: Top-Down Design and Stepwise Refinement
At the heart of program design are two interconnected ideas: Top-Down Design and Stepwise Refinement. Top-down design is the philosophy of starting with the single, main task your program must accomplish. You then break that main task down into a small number of major sub-tasks. Each of these sub-tasks is then broken down further, and so on, creating a hierarchy of tasks.
Stepwise refinement is the active process of carrying this out. As you move down the hierarchy, you 'refine' the description of each task, adding more detail. You stop breaking down a task when it is simple enough to be expressed directly in a few lines of programming code. This combined approach prevents you from getting lost in the details too early and ensures all parts of the problem are considered.
Manages Complexity: Large problems become a series of smaller, solvable ones.
Facilitates Teamwork: Different developers can be assigned different modules to work on concurrently.
Simplifies Testing & Debugging: Each module can be tested independently (unit testing). If a bug occurs, it's easier to isolate which module is at fault.
Promotes Reusability: A well-defined module, like 'CalculateVAT', can be reused in other programs.
Visualising the Plan: Structure Diagrams
A structure diagram (or structure chart) is the primary tool for visualising a top-down design. It's a simple, hierarchical diagram that shows the different modules of a program and how they relate to one another. It is a tree-like structure where the root is the main program module.
Rectangles: Each rectangle represents a module (a procedure, a function, or the main program).
Lines: Lines connecting the rectangles show the calls. If a line goes from module 'A' down to module 'B', it means 'A' calls 'B'.
Hierarchy: The diagram clearly shows which modules are sub-tasks of others. It illustrates decomposition, not sequence.
Examiners frequently test the difference between structure diagrams and flowcharts. Remember: a structure diagram shows decomposition (what the program is made of). A flowchart shows flow of control (the sequence of steps, decisions, and loops). Your structure diagram should NEVER contain symbols for decisions (diamonds) or loops.
Translating Design into Code: Modules, Procedures, and Functions
A structure diagram is not just an abstract drawing; it's a direct blueprint for writing your program's code. Each rectangle in the diagram corresponds to a module. In high-level programming languages, modules are implemented as self-contained blocks of code, most commonly as procedures or functions.
A procedure is a subroutine that performs a specific task but does not return a value (e.g., DisplayResults). A function is a subroutine that performs a task and returns a single value (e.g., CalculateAverage). By defining these procedures and functions based on your structure diagram, you create a well-organized program that is easy to read, test, and maintain. The main program module will contain the calls to the top-level sub-modules, mirroring the top level of the structure diagram.
Worked examples
See the formulas applied — reveal one step at a time, like the exam.
A simple payroll program needs to get an employee's hours worked and rate of pay, calculate the gross pay, and display the result.
- Design a structure diagram for this program.
- Using your design, show the calculation for an employee who worked 37.5 hours at a rate of $20.00 per hour.
- 1
1. Design (Structure Diagram) The design process follows top-down decomposition:
- Top Level: The main module is 'Process Payroll'.
- First Breakdown: 'Process Payroll' is broken into three main steps: GetData, CalculateGrossPay, and DisplayGrossPay.
- Second Breakdown: The GetData module is refined into GetHoursWorked and GetRateOfPay.
A program is required to analyse a set of student exam scores. The program must read a list of scores from a file, calculate the average, find the highest and lowest scores, and display the results.
- Design a structure diagram for this system.
- Show the calculated results for the following list of scores: [85, 72, 94, 68, 72, 88, 94, 79].
- 1
1. Design (Structure Diagram) The top-down design is as follows:
- Top Level: AnalyseStudentScores
- First Breakdown: ReadScoresFromFile, ProcessScores, DisplayResults
- Second Breakdown: The ProcessScores module calls three sub-modules: CalculateAverage, FindHighestScore, FindLowestScore.
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 is Program Design?
The process of planning the structure and logic of a program before writing the code. It involves breaking down a problem and defining modules and their relationships.
Key takeaways
Review these before you close the topic — retrieval beats re-reading.
- ✓
Manages Complexity: Large problems become a series of smaller, solvable ones.
- ✓
Facilitates Teamwork: Different developers can be assigned different modules to work on concurrently.
- ✓
Simplifies Testing & Debugging: Each module can be tested independently (unit testing). If a bug occurs, it's easier to isolate which module is at fault.
- ✓
Promotes Reusability: A well-defined module, like 'CalculateVAT', can be reused in other programs.
Practice — then mark it
The whole point: a real Cambridge question, marked mark-by-mark.
Test your understanding of program design
Test your understanding of program design
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 Test your understanding of program design on paper, snap a photo, and get examiner-style feedback on exactly where you win and lose marks.