B1.1: Approaches to computational thinking

Subjects

Features

Master IB Computer Science B1.1: Approaches to computational thinking with notes created by examiners and strictly aligned with the syllabus.

This content can't be printed from the browser. Use Export PDF with Pro for an offline copy.

IB Syllabus Requirements for Approaches to computational thinking

B1.1.1

Constructing a problem specification

B1.1.2

Fundamental concepts of computational thinking

B1.1.3

Applying computational thinking to problems

B1.1.4

Tracing flowcharts

B1.1.1

CONSTRUCTING A PROBLEM SPECIFICATION

To construct a problem specification, turn a need into a precise description of the problem, where its boundaries lie and what a successful solution must produce. Set out what must be achieved before deciding how to implement it.

From a vague need to a precise specification

“Make equipment lending easier” is too vague. What information is available? Which decisions need to be made, and what counts as success? Identify the current difficulty first, then describe the required behaviour in terms that can be checked.

A specification can include the elements below. Choose the detail relevant to the problem; other elements may be appropriate too.

Element	What it establishes
Problem statement	The situation that needs to change and the difficulty to resolve.
Constraints and limitations	Restrictions the solution must obey and boundaries on what it will handle.
Objectives and goals	The improvements or outcomes the solution should achieve.
Input specifications	The data supplied: what it means, its type and its permitted values.
Output specifications	The information or results the solution must produce.
Evaluation criteria	Observable conditions for judging whether the solution succeeds.

Worked specification: a school tool-lending desk

Staff at the desk currently check each request manually. The proposed solution decides whether the available stock is enough to fulfil a single request.

Element	Specification
Problem statement	Staff need a consistent way to decide whether enough tools are available and to calculate the stock remaining after a request.
Constraints and limitations	Handle one tool type and one request at a time. Do not include reservations or return dates. Assume that inputs satisfy the stated input specifications.
Objectives and goals	Accept requests that can be fulfilled and reject those that cannot. Report the correct remaining stock.
Input specifications	Available stock is a non-negative whole number. Requested quantity is a positive whole number. Both quantities refer to the same tool type.
Output specifications	Report either “Request accepted” or “Not enough tools”, together with the remaining stock. Accept when the requested quantity is no greater than the available stock. Subtract the request only when it is accepted.
Evaluation criteria	With stock 6 and request 4, accept and report 2 remaining. With stock 4 and request 6, reject and report 4 remaining. With stock 4 and request 4, accept and report 0 remaining.

In the figure, the problem statement leads to objectives and goals, then to input specifications and output specifications. Constraints and limitations restrict the solution. Evaluation criteria check whether the required outcomes have been achieved.

Making the specification checkable

“Produce the correct remaining stock” is useful only if the expected behaviour is clear. The worked specification separates acceptance from rejection. It also includes the boundary case where requested quantity equals available stock.

There’s no prescribed programming language or screen layout: neither is needed to explain this problem's required behaviour.

Terms to use: problem statement, constraints and limitations, objectives and goals, input specifications, output specifications, evaluation criteria.

B1.1.2

FUNDAMENTAL CONCEPTS OF COMPUTATIONAL THINKING

Computational thinking can be described through four complementary concepts: abstraction, algorithmic design, decomposition and pattern recognition. Each addresses a different part of understanding and solving a problem.

Abstraction

Abstraction means keeping the details relevant to a purpose and leaving out those that do not affect it.

When deciding whether a tool request can be fulfilled, the available stock and requested quantity matter. The colour of the storage cupboard doesn't. Leaving out that detail makes the problem easier to represent without changing the decision.

The purpose determines what to leave out. A detail that is irrelevant to a stock decision might matter in a different problem.

Algorithmic design

Algorithmic design means developing a precise, ordered set of steps that produces the required result.

For the lending decision, first compare the requested quantity with the available stock. If sufficient stock exists, subtract the request and report acceptance. Otherwise, leave stock unchanged and report rejection. Before translating these steps into code, make sure their order and the alternatives are unambiguous.

Decomposition

Decomposition means breaking a complex problem into smaller, more manageable parts.

A lending system can be split into parts: recording a request, checking availability, calculating remaining stock and reporting the result. Giving each part a clear responsibility makes it easier to understand and work on that part without considering the entire system at once.

Pattern recognition

Pattern recognition means identifying similarities, repeated structures or regularities within problems or data.

Requests for different tool types follow the same stock-checking structure. Once this pattern is recognised, one decision method can be reused with different quantities. There is no need to design a separate method for every tool.

How the concepts differ

The figure places the tool-lending problem at the centre. It shows how each concept contributes: abstraction selects relevant details, decomposition separates parts, pattern recognition finds similarities, and algorithmic design orders the steps.

Concept	Main question it answers
Abstraction	Which details matter for this purpose?
Algorithmic design	What steps and decisions will produce the result?
Decomposition	What smaller parts make up the problem?
Pattern recognition	What similarities or repeated structures can be used?

You don't have to use these concepts in a fixed sequence. Decomposing a problem, for example, may reveal repeated parts. Recognising those patterns may then help refine the algorithm.

Terms to use: abstraction, algorithmic design, decomposition, pattern recognition.

B1.1.3

APPLYING COMPUTATIONAL THINKING TO PROBLEMS

To explain the value of computational thinking, connect each technique to how it makes a problem easier to understand or solve. Simply naming it doesn't explain what it contributes.

Computational thinking brings together problem-solving techniques; it doesn't require writing a program. You can develop a solution first using written rules, diagrams or a manual procedure. Programming may then automate it.

Software development: a tool-lending solution

A lending desk offers a small example of how these concepts work together in software development.

Technique	Application	Why it helps
Decomposition	Separate request recording, availability checking, stock calculation and result reporting.	Each part can be understood and checked on its own, so fewer concerns need attention at once.
Abstraction	Represent the lending decision using available stock and requested quantity.	Removing irrelevant details keeps attention on the comparison that determines the result.
Pattern recognition	Notice that requests for different tool types follow the same decision structure.	The same method can be reused rather than creating nearly identical solutions.
Algorithmic design	Specify the comparison, the acceptance and rejection branches, and the stock calculation.	This makes the procedure precise enough to follow consistently or implement in code.

The figure shows how each technique contributes to the solution: separate the tasks, select relevant details, recognise a reusable structure and specify precise steps. Its arrows trace a useful route through this example. They don't set a fixed order for every problem.

A member of staff could follow the resulting procedure on paper, or a program could follow it automatically. Both use the reasoning developed through computational thinking.

Network security: recognising traffic patterns

In network security, a task might be to decide which traffic records deserve investigation. Decomposition separates the work into collecting records, grouping similar activity and reviewing unusual groups. Abstraction keeps attention on details relevant to the decision, such as the source and timing of connection attempts.

Repeated similar connection attempts may emerge through pattern recognition. Spotting that pattern helps identify a group of records for closer inspection, rather than treating every record independently. Algorithmic design then sets out a consistent procedure for grouping records and flagging activity for review.

A repeated pattern alone doesn't prove harmful activity. It helps organise the evidence and direct attention, but what the pattern means still depends on the problem and its context.

Software development and network security are two application areas. Computational thinking can support other areas too: selecting information, breaking down tasks, recognising similarities and specifying procedures are general problem-solving activities.

Terms to use: computational thinking, abstraction, algorithmic design, decomposition, pattern recognition, software development, network security.

B1.1.4

TRACING FLOWCHARTS

To trace a flowchart, follow its execution path and record variable changes and output as you go. Use the flowlines to guide you. At each decision, check the current values; don't assume every symbol is visited once.

Standard flowchart symbols

A flowchart represents an algorithm as a diagram, with arrows connecting its symbols.

Symbol	Standard shape	Meaning
Start/End	Oval or rounded terminator	Marks where execution begins or finishes.
Process/Operation	Rectangle	Carries out an action, such as a calculation or assignment.
Input/Output	Parallelogram	Receives data or produces output.
Decision	Diamond	Tests a condition and selects an outgoing path, usually labelled Yes and No.
Flowline	Arrowed line	Shows the direction in which execution continues.
Connector	Small labelled circle	Links separated parts of a flowchart; matching labels show where to continue.

A reliable tracing method

Begin at Start and carry out each input or process you reach. Update the relevant variables straight away. When you reach a decision, test the condition using the latest values, then follow only the matching branch. Record output only when you reach an output symbol. Keep going until End.

An assignment replaces a variable's previous value. When a process increases a total, use its current value, not the original one. A dash in the tables below means either that no value has yet been assigned or that no output has occurred.

Sequence: combining two stock counts

The first flowchart takes firstCount and secondCount as inputs. It adds them to calculate total, then outputs total. The path is Start → Input firstCount → Input secondCount → total = firstCount + secondCount → Output total → End.

With inputs 3 and 2, the trace is:

Action reached	firstCount	secondCount	total	Output
Input firstCount	3	—	—	—
Input secondCount	3	2	—	—
Calculate total	3	2	5	—
Output total	3	2	5	5

There is no branch or loop here, so execution reaches every operation once.

Selection: accepting or rejecting a request

The second flowchart inputs available and requested, then checks whether requested is less than or equal to available. If the result is Yes, it subtracts requested from available and outputs “Request accepted”. The No branch leaves available unchanged and outputs “Not enough tools”. Both branches then output available before reaching End.

For available stock 4 and requested quantity 6:

Action reached	available	requested	Decision result	Output
Input available	4	—	—	—
Input requested	4	6	—	—
Test requested ≤ available	4	6	No	—
Output rejection message	4	6	—	Not enough tools
Output available	4	6	—	4

Execution skips the subtraction because it lies on the other branch. In a separate run with available stock 4 and requested quantity 3, the condition gives Yes. Here, available becomes 1, and the outputs are “Request accepted” followed by 1.

Repetition: totalling three requests

The third flowchart sets total to 0 and processed to 0, then checks whether processed is less than 3. The Yes branch inputs quantity and adds quantity to total. It then increases processed by 1 and returns to the decision. On the No branch, execution outputs total and ends. A Connector labelled A marks the return to the decision.

The quantities supplied, in order, are 2, 1 and 3. Track each update and check every decision:

Action reached	processed	quantity	total	Decision result	Output
Set total to 0	—	—	0	—	—
Set processed to 0	0	—	0	—	—
Test processed < 3	0	—	0	Yes	—
Input quantity	0	2	0	—	—
Add quantity to total	0	2	2	—	—
Increase processed by 1	1	2	2	—	—
Test processed < 3	1	2	2	Yes	—
Input quantity	1	1	2	—	—
Add quantity to total	1	1	3	—	—
Increase processed by 1	2	1	3	—	—
Test processed < 3	2	1	3	Yes	—
Input quantity	2	3	3	—	—
Add quantity to total	2	3	6	—	—
Increase processed by 1	3	3	6	—	—
Test processed < 3	3	3	6	No	—
Output total	3	3	6	—	6

Execution reaches the decision four times, although the repeated body runs three times. The final No result takes execution out of the loop. Passing through Connector A only redirects the flow; it does not change any variable.

Terms to use: Connector, Decision, Flowline, Input/Output, Process/Operation, Start/End, execution flow, variables, output.

The Ultimate All-in-One
IB Platform

All content on this website has been developed independently from and is not endorsed by the International Baccalaureate Organization. International Baccalaureate and IB are registered trademarks owned by the International Baccalaureate Organization.