| English | 의미 |
|---|---|
| computational thinking/ˌkɒmpjuːˈteɪʃənl ˈθɪŋkɪŋ/ | 계산적 사고 |
| abstraction/əbˈstrækʃn/ | 추상화 |
| decomposition/ˌdiːkɒmpəˈzɪʃn/ | 분해 |
| pattern recognition/ˈpætn ˌrekəɡˈnɪʃn/ | 패턴 인식 |
| algorithm/ˈælɡərɪθəm/ | 알고리즘 |
| function/ˈfʌŋkʃn/ | 함수 |
| module/ˈmɒdjuːl/ | 모듈 |
| sub-problem/sʌb ˈprɒbləm/ | 하위 문제 |
| procedure/prəˈsiːdʒə/ | 절차 |
| structure chart/ˈstrʌktʃə tʃɑː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
추상화의 의미는:
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
추상화는 문제를 필수 요소로 단순화합니다. 부분으로 나누는 것은 분해입니다.
역사 지리 정보는 제외하고 역과 선만 유지하는 철도 노선도는 추상화의 예시입니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
중요한 것(역, 연결)은 유지하고 나머지는 버립니다 — 이것이 바로 추상화가 하는 일입니다.
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.
추상화의 이점이 되는 문장을 모든 해당 항목을 선택하십시오.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
추상화는 디테일을 배제하므로 모든 디테일을 유지하는 것은 그 반대이며, 하드웨어에 대해서는 언급하지 않습니다. 실제 이점은 이해, 개발 크기/속도, 재사용입니다.
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.
작은 예제(vouched example)의 보전-이메일 모듈에 다음 중 어떤 항목이 필요합니까? 선택 모든 해당 항목.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
보낼 이메일 주소, 자격 기준을 결정하기 위한 마지막 방문 날짜, 고객을 조회하기 위한 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
분해(Decomposition)의 의미는:
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
분해는 큰 작업을 개별적으로 해결 가능한 더 작은 하위 작업으로 나눕니다.
분해로 생성된 각 하위 문제는 프로그램 모듈이 됩니다: 프로시저 또는 ____.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
교수요법 wording은 정확합니다: 분해는 프로그램 모듈의 개념으로 이어지며 — 프로시저(procedure) 또는 함수(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.
영화관 예약 설계의 각 부분을 그것이 무엇인지와 매칭하십시오.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
세 개의 모듈, 각각 하나의 역할 수행, 그리고 이들이 어떻게 연결되는지 보여주는 구조 차트.
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.
컴퓨팅 방식으로 문제를 해결
네 가지 기둥을 사용할 순서에 따라 단계별로 진행하십시오 — 문제를 분해하고, 반복되는 부분을 찾아내며, 필수 요소만 남기고, سپس 단계를 작성하십시오.
컴퓨팅 사고의 각 기둥을 그것이 의미하는 것과 매칭하십시오.
난이도 2/5 · 140 코인 + 오늘 첫 완료 시 소액 보너스
네 가지 기둥 — 분해, 패턴 찾기, 추상화, 그리고 알고리즘 설계.
컴퓨팅 사고 단계를 합리적인 순서로 배치하십시오.
난이도 3/5 · 200 코인 + 오늘 첫 완료 시 소액 보너스
나눠서, 반복되는 것을 찾고, 필수 요소로 정리한 후, 단계를 작성하십시오.
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.
"분해 설명" 질문에 대한 답은 상점이나 영화관 같은 시나리오를 전혀 언급하지 않아도 만점을 받을 수 있습니다.
난이도 1/5 · 100 코인 + 오늘 첫 완료 시 소액 보너스
채점 기준은 일반적인 답에 상한선을 설정합니다. 최근 재고 관리 문제에서 "재고 관리 언급이 없을 경우 최대 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