Computational thinking · 计算思维
| English | 中文 | Pinyin · 拼音 |
|---|---|---|
| computational thinking/ˌkɒmpjuːˈteɪʃənl ˈθɪŋkɪŋ/ | 计算思维 | jì suàn sī wéi |
| abstraction/əbˈstrækʃn/ | 抽象 | chōu xiàng |
| decomposition/ˌdiːkɒmpəˈzɪʃn/ | 分解 | fēn jiě |
| pattern recognition/ˈpætn ˌrekəɡˈnɪʃn/ | 模式识别 | mó shì shí bié |
| algorithm/ˈælɡərɪθəm/ | 算法 | suàn fǎ |
| function/ˈfʌŋkʃn/ | 函数 | hán shù |
| module/ˈmɒdjuːl/ | 模块 | mó kuài |
| sub-problem/sʌb ˈprɒbləm/ | 子问题 | zi wèn tí |
| procedure/prəˈsiːdʒə/ | 过程 | guò chéng |
| structure chart/ˈstrʌktʃə tʃɑːt/ | 结构图 | 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.
一张故意"画错"的地图
- 1931 年,失业的绘图员 Harry Beck 重新绘制了伦敦地铁图。
- 他丢掉了真实的地理:每条线都画成直线,每个车站等距排列。
- 这张图是"错"的,却立刻更好用了。如今全世界的地铁图都在模仿它。
- Beck 只保留乘客需要的东西:车站,以及它们怎样连接。这就是计算机出现之前的计算思维(computational thinking)。
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)和分解(decomposition)。
- 另外两个为它们提供支持:模式识别(pattern recognition)和设计算法(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.
例题:一个抽象模型
- 一家咖啡店为每位会员卡顾客存储:ID、姓名、家庭地址、电子邮件、手机号、出生日期、积分,以及上次到店日期。
- 一个新模块给 30 天没来的顾客发送优惠券邮件。它需要哪些数据?
- 需要:ID(用来查找顾客)、电子邮件(发送对象)、姓名(让信息更个性化)、上次到店日期(用来选出谁能收到)。
- 不需要:家庭地址、手机号、出生日期、积分。把它们去掉,就是抽象。
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. · 电子邮件用来发送,上次到店日期用来选出谁符合条件,ID 用来查找顾客。邮寄地址和生日在邮件优惠券里不起作用,所以这个模块的抽象模型把它们去掉。
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
分解
- 分解意味着把一个大问题拆成更小的子问题(sub-problem),每个都更容易解决。
- 找到主要部分 → 把每个拆成子任务 → 直到每个都小到能直接编码 → 解决并组合。
- 每个子问题成为一个程序模块(module):一个过程(procedure)或一个函数(function)。
把一个程序分解成模块和子模块
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.
例题:一个电影院订票程序
- 一家有多个放映厅的电影院想要一个让顾客订座位的程序。
- ShowFilms() 列出电影、放映厅和开场时间。
- ChooseSeats() 显示座位图,接收顾客的选择,并检查座位是否空闲。
- TakePayment() 计算价格,处理刷卡付款,并打印票。
- 三个模块,每一个都小到可以独立设计、编码和测试。
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).
为什么要分解?三分的答案
- 每个子问题都小到可以独立设计、编码和测试。
- 不同的程序员可以同时处理不同的模块。
- 已经存在的模块或库例程可以复用;错误更容易找到,因为它只在一个模块里。
- 一次分解的图就是结构图(structure chart)(主题 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.
别把它们弄混
- 抽象去掉细节;分解拆开问题。"拆成更小的部分"不是对抽象的描述。
- 一个"描述"(describe)题需要怎么做,而不是一个词:说清拆的是什么、拆成什么、每个部分变成什么。
- 把答案和情境绑在一起。一个从不提到库存系统、电影院或商店的分解答案会丢一分。
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. · 评分标准会限制泛泛的答案:最近那道库存控制题写着"不提库存控制最多 2 分"。要说出情境自己的模块和数据。
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
你掌握了
- 抽象 = 保留本质,忽略无关细节 → 一个更简单的模型
- 分解 = 把大问题拆成子问题 → 每个成为一个过程或函数
- 分解的好处:分开设计/编码/测试、分担工作、复用模块、更快找到错误
- 永远用情境自己的模块和数据来描述