In simple terms
A friendly intro before the formal notes — no formulas yet.
From Idea to Code: The Architect's Blueprint
Just as an architect designs a detailed blueprint before building a house, a programmer uses computational thinking to design a program before writing code. This design process ensures the final software is logical, efficient, and solves the problem correctly.
Imagine building a complex LEGO spaceship. You wouldn't just start randomly connecting bricks. First, you'd look at the overall design and break it down into smaller parts like the cockpit, wings, and engines (decomposition). You'd notice that both wings are identical, so you can build one and just copy the pattern (pattern recognition). You might use a pre-made engine piece without needing to know how the LEGO company moulded it (abstraction). Finally, you would follow the step-by-step instruction booklet to assemble everything in the correct order (algorithm). This is exactly how computational thinking guides program design.
- 1
Decompose the Problem: Break the main challenge into smaller, self-contained sub-tasks or modules.
- 2
Identify Patterns & Abstract: Look for repeating logic or data structures. Hide complex details behind simple interfaces, like functions with clear inputs and outputs.
- 3
Design Algorithms: Create step-by-step instructions, using pseudocode or flowcharts, to solve each individual sub-task.
- 4
Structure the Program: Organise the modules and their algorithms into a coherent program structure, using a structure chart to visualise how they interact and pass data.
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 Four Pillars of Computational Thinking in Design
You have already encountered the four pillars of computational thinking: decomposition, pattern recognition, abstraction, and algorithms. In program design, we move from defining these concepts to actively applying them. They become our primary tools for transforming a vague problem statement into a concrete, implementable plan. Each pillar plays a distinct but interconnected role in shaping the final program structure.
1. Decomposition and Modular Design
Decomposition is the cornerstone of 'top-down design'. We start with the main goal and break it into smaller, more specific sub-tasks. Each sub-task can then be implemented as a separate module, such as a function or a procedure. For example, designing a simple ATM program would involve decomposing the main task 'Perform Transaction' into sub-tasks like displayMenu, getPIN, checkBalance, withdrawCash, and depositCash. This modularity makes the code easier to write, test, and debug.
Manageability: Smaller modules are easier to understand and work on than a single monolithic program.
Reusability: A well-designed module (e.g., validateInput) can be reused in different parts of the program or even in other projects.
Easier Testing: Each module can be tested independently (unit testing) before being integrated into the main system.
Collaboration: Different programmers can work on different modules simultaneously, speeding up development.
Representing the Decomposition: Structure Charts
A structure chart is a powerful diagrammatic tool for visualising the decomposition of a system. It shows the hierarchy of modules, how they are related, and what data is passed between them. Modules are represented by rectangles, a line connecting two modules indicates a call, and small arrows with circles indicate data parameters being passed. An arrow with an empty circle means a control flag (like a boolean true/false) is passed, while a filled circle indicates data (like a number or string).
2. Pattern Recognition & 3. Abstraction
Pattern recognition and abstraction work hand-in-hand. By recognising a repeating pattern of logic, we can create a function to encapsulate it. This function is an abstraction. For example, in a graphics program, you might notice that drawing a square, a triangle, and a star all involve setting a colour, moving a pen, and drawing lines. The pattern is 'draw a shape'. We can abstract this into a drawShape(points) function. Now, we can use drawShape without worrying about the low-level details of pixel manipulation. This is procedural abstraction and it makes our main code simpler and more readable.
In IB exams, when asked to design a solution, explicitly look for opportunities to create functions for repeated tasks. For example, if you need to validate user input in multiple places, create a single validateInput(input, min, max) function. This demonstrates your understanding of both pattern recognition and abstraction, and will likely earn you higher marks for design quality.
4. Algorithms: The Step-by-Step Plan
Once we have decomposed the problem into modules, we need to design an algorithm for each one. This is the detailed, step-by-step logic that the module will execute. Pseudocode and flowcharts are the two primary tools for representing these algorithms. For the IB exam, you must be proficient in writing and interpreting the approved IB pseudocode. This algorithm design phase is where you make critical decisions about efficiency, such as choosing between a linear search and a binary search if the data is sorted.
Worked examples
See the formulas applied — reveal one step at a time, like the exam.
A teacher needs a simple program to analyse student test scores. The program must read a list of integer scores from a file, calculate the average score, and find the highest score. The program should then display the list of scores, the calculated average, and the highest score. Design the system using a structure chart and provide pseudocode for the main modules.
- 1
1. Structure Chart Design
A library's software needs a function to handle book returns. The function receives the unique ISBN (International Standard Book Number) of the returned book. The system stores book information in an array of Book objects, where each object has properties ISBN, title, and onLoan (a boolean). Design an algorithm in pseudocode that finds the book with the matching ISBN in the array and updates its onLoan status to false. The function should return true if the book was found and updated, and false otherwise. The array of books is not sorted.
- 1
- Iterate through each Book in the bookList from the first to the last.
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 the relationship between Computational Thinking and Program Design?
Computational Thinking is the thought process used to formulate a problem and its solution. Program Design is the practical application of these thoughts to structure and plan the software solution before coding begins.
Key takeaways
Review these before you close the topic — retrieval beats re-reading.
- ✓
Manageability: Smaller modules are easier to understand and work on than a single monolithic program.
- ✓
Reusability: A well-designed module (e.g., validateInput) can be reused in different parts of the program or even in other projects.
- ✓
Easier Testing: Each module can be tested independently (unit testing) before being integrated into the main system.
- ✓
Collaboration: Different programmers can work on different modules simultaneously, speeding up development.
Practice — then mark it
The whole point: a real Cambridge question, marked mark-by-mark.
Practice Problems
Practice Problems
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 Problems on paper, snap a photo, and get examiner-style feedback on exactly where you win and lose marks.