Computational thinking
| English | Chinese | Pinyin |
|---|---|---|
| computational thinking | 计算思维 | jì suàn sī wéi |
| abstraction | 抽象 | chōu xiàng |
| decomposition | 分解 | fēn jiě |
| pattern recognition | 模式识别 | mó shì shí bié |
| algorithm | 算法 | suàn fǎ |
| function | 函数 | hán shù |
| module | 模块 | mó kuài |
| sub-problem | 子问题 | zi wèn tí |
| procedure | 过程 | guò chéng |
| structure chart | 结构图 | jié gòu tú |
A map that lies on purpose
- In 1931 Harry Beck, an out-of-work draughtsman, redrew the map of the London Underground.
- He threw away the real geography: every line became straight and every station evenly spaced.
- The map was "wrong", and it was instantly easier to use. Every metro map in the world now copies it.
- Beck kept only what a passenger needs: the stations and how they connect. That is computational thinking 计算思维 before computers existed.
What computational thinking is
- The set of mental tools for analysing a problem and designing a solution a computer can run.
- The syllabus names two of them: abstraction 抽象 and decomposition 分解.
- Two more support them: pattern recognition 模式识别 and designing algorithms 算法.
Abstraction
- Abstraction means keeping the essential features of a problem and ignoring irrelevant detail, giving a simpler model.
- The tube map keeps the stations and lines and drops the geography.
- A variable name hides a memory address; a function hides a block of code behind a name; a class keeps only the attributes the system needs.
Abstraction keeps only the essential features of a problem and drops the irrelevant detail
Abstraction means:
Abstraction simplifies a problem to its essentials. Breaking into parts is decomposition.
A train map that keeps the stations and lines but drops the real geography is an example of abstraction.
It keeps what matters (stations, connections) and discards the rest — exactly what abstraction does.
Purpose and benefits
- Purpose: to produce a simpler model of the problem that contains only the details needed to solve it.
- Benefits: the problem is easier to understand and to program; the program is smaller and quicker to write and test; the same model can be reused for a similar problem.
- The examiner asks for the purpose and the benefits separately. Learn both.
Select all the statements that are benefits of abstraction.
Abstraction drops detail, so keeping every detail is the opposite of it, and it says nothing about hardware. The three real benefits are understanding, size/speed of development, and reuse.
Worked example: an abstract model
- A coffee shop stores, for each loyalty-card customer: ID, name, home address, email, mobile number, date of birth, points, and date of last visit.
- A new module emails a voucher to customers who have not visited for 30 days. Which data does it need?
- Needed: ID (to look the customer up), email (to send to), name (to personalise the message), date of last visit (to select who gets one).
- Not needed: home address, mobile number, date of birth, points. Leaving them out is the abstraction.
The voucher-email module in the worked example needs which of these items? Select all that apply.
Email to send to, date of last visit to choose who qualifies, and the ID to look the customer up. The postal address and birthday play no part in an email voucher, so an abstract model of this module leaves them out.
Decomposition
- Decomposition means breaking a large problem into smaller sub-problems 子问题, each easier to solve.
- Find the main parts → split each into sub-tasks → stop when each is small enough to code directly → solve them and combine.
- Each sub-problem becomes a program module 模块: a procedure 过程 or a function 函数.
Decomposing a program into modules and sub-modules
Decomposition means:
Decomposition splits a big task into smaller, separately-solvable sub-tasks.
Each sub-problem produced by decomposition becomes a program module: a procedure or a ____.
The syllabus wording is exact: decomposition leads to the concept of a program module — a procedure or a function.
Worked example: a cinema booking program
- A cinema with several screens wants a program that lets customers book seats.
- ShowFilms() lists the films, their screens and their start times.
- ChooseSeats() shows the seating plan, takes the customer's choice and checks the seats are free.
- TakePayment() works out the price, processes the card payment and prints the ticket.
- Three modules, each small enough to design, code and test on its own.
Match each part of the cinema booking design to what it is.
Three modules, each doing one job, and a structure chart to show how they fit together.
Why decompose? The three-mark answer
- Each sub-problem is small enough to design, code and test on its own.
- Different programmers can work on different modules at the same time.
- A module that already exists, or a library routine, can be reused, and a fault is easier to find because it sits inside one module.
- The diagram of a decomposition is a structure chart 结构图 (topic 12).
The four cornerstones
- Decomposition: break the problem up. Pattern recognition: spot what repeats, so one solution serves several parts.
- Abstraction: strip away the detail that does not matter. Algorithm design: write the step-by-step solution.
- In practice you use them in roughly that order, and you go round more than once.
Solving a problem the computational way
Step through the four cornerstones in the order you'd use them — break the problem down, spot what repeats, strip it to essentials, then write the steps.
Match each cornerstone of computational thinking to what it means.
The four cornerstones — decompose, spot patterns, abstract, then design the algorithm.
Put the computational-thinking steps in a sensible order.
Break it down, find what repeats, strip to essentials, then write the steps.
Don't mix them up
- Abstraction removes detail; decomposition splits the problem. "Breaking it into smaller parts" is not a description of abstraction.
- A "describe" answer needs the how, not one word: say what is broken down, into what, and what each part becomes.
- Tie the answer to the scenario. A decomposition answer that never mentions the stock system, the cinema or the shop loses a mark.
In a "describe decomposition" question, an answer that never mentions the scenario (the shop, the cinema) can still earn full marks.
Mark schemes cap a generic answer: the recent stock-control question said "max 2 if no mention of stock control". Name the scenario's own modules and data.
You've got it
- abstraction = keep the essentials, ignore irrelevant detail → a simpler model
- decomposition = break a big problem into sub-problems → each becomes a procedure or function
- benefits of decomposition: design/code/test separately, share the work, reuse modules, find faults faster
- always describe with the scenario's own modules and data