aiMOOC

Computational thinking and decomposition - Computing Year 5

QR-Code

Introduction

How would you build a useful school app without trying to solve everything at once? Computational thinking helps us describe a problem, identify useful information and develop a method that can be checked. In this course you will plan a fictional library-return helper, then transfer your ideas to lost property. You can complete the planning on paper; no account, download or real pupil information is needed.

This is an editorial Year 5 sequence within England's Key Stage 2 computing programme. The statutory programme sets expectations for the key stage, not this particular Year 5 lesson order. This course develops planning and reasoning; later programming lessons put a design into working code.

Your goals

Break a goal into at least four meaningful, manageable subtasks.
Describe what each part receives and what it produces.
Distinguish decomposition, abstraction and an algorithm.
Test a plan with normal, missing and unexpected inputs.
Explain a design choice and improve it using evidence.

Starting point: You can follow a short set of instructions and read a simple table. If a computer is unavailable, use numbered paper cards as records and a partner as the user. All records and identifiers below are invented.

First prediction: Is “make a library app” a useful instruction for someone who needs to start work now? Keep your answer. You will improve that instruction during the course.

A big goal becomes smaller problems

Decomposition means breaking a problem or system into smaller parts that are easier to understand and work on. A part should have a clear purpose. “Do some work” is too vague. “Find the record matching this book code” is a useful subtask because we can say what information it needs and how to check its result.

Look at the opening photograph. You can name individual blocks, groups of blocks and the complete construction. This is an analogy, not a claim that software is literally made from wooden blocks. With software, the parts may be tasks, data and rules rather than physical pieces.

Imagine the school wants a helper that records when a book comes back. One possible decomposition is:

Read the book's code.
Find the matching book record.
Check whether that record says the book is on loan.
If the return is valid, change the record to available.
Show a confirmation, or explain why the record was not changed.

These are related parts. The search needs a code. The check needs the search result. The update needs the check result. A useful decomposition makes these relationships visible; it is more than a list of vaguely related words.

Try before reading on: Which part should deal with a code that is not in the catalogue? Explain why “just mark it available anyway” could cause trouble.

Feedback: The search should report “not found”. The following parts must recognise that result, avoid changing another book and tell the user to ask for help. There may be different sensible designs, but every design needs an explicit way to handle a missing record.

Decomposing a task does not mean that there is only one correct set of parts. You might combine the check and update in a small project. You should still be able to explain what that combined part does and how it avoids an incorrect change.

Keep the information that matters

Abstraction means selecting the details that matter for the question and leaving aside details that do not help answer it. It is not a licence to remove every detail. The right choice depends on the purpose.

For the return helper, a unique book code and the current loan status matter. A cover's decorative colour is normally unnecessary: two different books can have blue covers, while two copies of the same book can have different covers. A unique code identifies the particular copy we intend to update.

Copy code	Short title	Current status
B104	River Map	On loan
B105	Night Garden	Available
B106	River Map	On loan

B104 and B106 have the same title but identify different copies. Searching only for River Map would not tell us which copy has returned. This is why a detail that looks small can be essential.

A changed question changes the abstraction. If you are making an art display about book covers, cover colour may matter. If you are checking a return, it usually does not. “Always ignore colour” is therefore a poor rule. Ask: what does this particular task need?

Data choice challenge: A classmate suggests adding each borrower's full address and photograph to this practice table. Are those needed to learn how the return helper works?

Feedback: No. The fictional copy code and status let us model this task. Do not collect real personal information for a classroom demonstration. A genuine school system needs the school's approved procedures and access controls; this paper exercise does not replace them.

Give each part a clear job

An input is information a part receives. An output is a result it produces. The output of one part can become the input of another. Writing these down helps teammates agree how the parts fit together.

Part	Input	Output
Read code	A typed fictional code	A code such as B104, or an empty-input warning
Find record	Code and catalogue	One matching record, or not found
Check return	Matching record and status	Return accepted, or no update needed
Update record	Accepted return and matching record	That copy's status becomes available
Confirm	Result of the preceding parts	A clear message to the user

Notice that “not found” is a useful output. It tells the next part what happened. Silently producing nothing leaves the next part guessing. Equally, an update should change the chosen copy, not every book with the same title.

Worked trace: B104 is returned

The read-code part receives B104.
The search finds B104: River Map, on loan.
The check accepts a return because that copy is on loan.
The update changes B104 to available. It leaves B105 and B106 alone.
The confirmation says that copy B104 has been returned.

Worked trace: B999 is entered

The input is not empty, so the search starts.
No record has code B999.
The search returns not found.
There is no update; the catalogue stays the same.
The message asks the user to check the code or seek help.

Try tracing B105 before continuing. It is already available. A sensible result is “already available; no change”. That is different from a successful new return and different from “not found”. A clear design distinguishes all three.

From a decomposition to a precise method

A decomposition describes the parts of the job. An algorithm describes a precise method for doing a job. Both help, but they are not interchangeable. “Search catalogue” names a subtask; it does not yet explain how the search should work.

Here is one possible plain-language algorithm for the whole helper. It assumes that every catalogue code is unique and that a copy's status is either on loan or available.

Receive a code.
If no code was supplied, show “Enter a copy code” and finish.
Search the catalogue for a record with exactly that code.
If no matching record exists, show “Code not found” and finish.
If the matching copy is available, show “Already available” and finish.
Otherwise, change that matching copy from on loan to available.
Show “Return recorded” and finish.

The order matters. You cannot safely change the status of a matching record before finding a match. The decision “if no record exists” is a condition; different results lead to different next steps. Stopping after an error prevents an inappropriate update.

Watch and investigate

In this Code.org/CodeAI unplugged introduction, look for an example of dividing a problem and an example of spotting a pattern. Pause and explain each in your own words. Then compare that example with the library helper: what stays the same about the method, even though the subject is different? The written examples in this course remain available if you cannot play the video.

One frequent mistake: Dividing a project between friends does not automatically produce a useful decomposition. “Alex does everything difficult” has neither a clear boundary nor a checkable output. Agree a specific job, what it needs and what it must return.

Test, improve and transfer your design

Testing compares an expected result with what actually happens. Choose an input, predict the outcome, run the method step by step and record the actual result. If a test fails, locate the first point where the plan and the requirement disagree.

Use a fresh copy of the original catalogue for each independent test below. Otherwise returning B104 in an earlier test changes the starting conditions of the next test.

Test input	Expected message	Expected catalogue change
B104	Return recorded	Only B104 changes from on loan to available
B105	Already available	No change
B999	Code not found	No change
An empty input	Enter a copy code	No change

A separate sequence test uses the same catalogue twice: return B104, then enter B104 again. The first attempt records a return; the second should say already available. This test checks how the design handles its own earlier changes.

Find and fix a fault. A draft searches for a title instead of a copy code and marks both copies of River Map available. Why does the first test fail? The algorithm has lost the distinction between B104 and B106. Repair the search and update so that they use the unique code; repeat the test and verify that B106 is still on loan.

Your transfer task: lost property

Plan a fictional lost-property helper with at least four parts. For example: record an item, search for possible matches, check a claim through an adult and record collection. State the input and output of each part. Use invented item references, not real names or photographs of pupils. Colour may now be relevant: two coats of the same size may need a distinguishing feature. Explain why this differs from the library-return example.

There is no need to write a program yet. Your product is a design someone else can understand and test. When a later lesson turns that design into a program, run the code and compare it with the same requirements. A neat diagram alone does not prove that a program works.

Interactive Tasks

Quiz: Test Your Knowledge

What is decomposition in computational thinking? (Breaking a problem into manageable parts.) (!Deleting every detail from a problem.) (!Choosing a computer before defining a goal.) (!Giving every book the same code.)

Which subtask has the clearest purpose? (Find the record matching the supplied copy code.) (!Do something useful.) (!Make the whole system perfect.) (!Choose your favourite colour.)

Why does the return helper use a unique copy code? (It must distinguish different copies, including copies with the same title.) (!Every book has a different title.) (!The code makes testing unnecessary.) (!A code automatically proves a return happened.)

Which detail is usually unnecessary for checking this book return? (The decorative colour of the book cover.) (!The supplied copy code.) (!Whether a matching record exists.) (!Whether that copy is already available.)

What should happen when B999 has no matching record? (Report not found and leave the catalogue unchanged.) (!Change every record to available.) (!Guess which book the user meant.) (!Return the first record without checking.)

What is an output of the search part? (A matching record or a clear not-found result.) (!Only the user's favourite colour.) (!A promise that all records were updated.) (!The original task with no result.)

How does an algorithm differ from a decomposition? (It gives a precise method, rather than only identifying the parts of a job.) (!It must always be a photograph.) (!It cannot contain decisions.) (!It makes the purpose of a task irrelevant.)

Why must a record be found before its status is updated? (The update needs to identify which record it may change.) (!An update can safely choose any record.) (!The confirmation message replaces the search.) (!All records must have the same status.)

Starting with B104 on loan, what should happen if it is returned twice in sequence? (The first return is recorded and the second reports already available.) (!Both attempts must report code not found.) (!The second attempt changes B106.) (!The second attempt creates a new copy code.)

Why might colour matter in a lost-property helper? (It can help distinguish otherwise similar items for that purpose.) (!Abstraction always deletes colour.) (!Colour identifies every item uniquely.) (!Colour removes the need to check a claim.)

Memory Game

Match each term with its distinct purpose.

Decomposition	Divide a problem into manageable parts.
Abstraction	Select details relevant to the purpose.
Algorithm	Give a precise method for a task.
Input	Information received by a part.
Output	A result produced by a part.
Test	Compare an expected result with an actual result.

Drag and Drop

Match each project part with the job it performs.

Part	Job
Read code	Receive B104 or detect an empty entry.
Find record	Search the catalogue for the matching copy.
Check return	Decide whether that copy is on loan.
Update record	Change only the accepted copy's status.
Confirm	Show the result clearly to the user.

Crossword Puzzle

Each answer is one word.

decomposition	Splitting a problem into manageable parts.
abstraction	Selecting the information relevant to a purpose.
algorithm	A precise method used to carry out a task.
input	Information supplied to part of a system.
output	A result produced by part of a system.
testing	Checking expected results against actual results.

LearningApps

Optional further practice: look for decomposition activities. External activities vary; a teacher should choose an appropriate one. If this collection is unavailable, all core tasks and the independent cloze below work within the course.

Cloze Text

Open Tasks

Easy

Make a decomposition card set: Make cards for the five library-helper parts. On the back, explain each part's job in one sentence.
Label library inputs and outputs: Complete a two-column input/output table for reading a code and finding its record; include a missing-code result.
Choose relevant book data: Sort copy code, status, cover colour and cover texture by relevance to this return helper. Explain one choice.
Trace a missing book code: Trace B999 through the method. Show the message and explain why the catalogue must stay unchanged.

Standard

Design a classroom tidy-up decomposition: Propose at least four manageable parts with a purpose and a checkable outcome for each.
Test the library return helper: Run the four independent tests and the repeated-return test. Record starting data, expected result and actual result.
Repair a title-based book search: Explain why a search for River Map can update the wrong copies. Rewrite the search and update rules and test the repair.
Plan a lost-property helper: Use at least four parts with named inputs and outputs. Use fictional data and explain why one detail is included and another omitted.

Advanced

Compare two valid decompositions: Compare a five-part helper with a design combining check and update. Judge whether both still have clear responsibilities and testable outputs.
Investigate duplicate record codes: Suppose two records accidentally have code B104. Explain why the unique-code assumption fails and design a safe stop-and-check response.
Change a system requirement: Add a damaged-book report that must be checked by an adult. Revise the parts and messages, and propose two tests for this new requirement.
Evaluate a partner design: Give a partner unfamiliar test inputs, compare the results with the requirements and recommend one evidence-based improvement.

Learning Check

Explain decomposition with evidence: State the library helper's goal and give four meaningful parts. For each, name its purpose rather than only naming a teammate.
Justify an abstraction choice: Explain why copy code matters more than cover colour for a return, but colour may matter in lost property.
Trace a state change: Starting with B104 on loan and B106 on loan, return B104 twice. Record both messages and the final status of each copy.
Diagnose a failed test: A missing-code test changes B105. Locate the rule that must be repaired and state the expected behaviour.
Transfer and evaluate a plan: Present your lost-property decomposition, one normal test, one missing-input test and a limitation requiring human judgment.

Worked checks

A valid answer could include read code, find record, check return, update record and confirm. “Use a laptop” is not a replacement for a job with a clear output.
The copy code identifies the individual record. Cover colour is not needed for this return rule. A coat's colour can help distinguish lost items; relevance depends on the question.
First message: return recorded. Second message: already available. B104 ends available; B106 remains on loan. Only the matching copy may change.
A missing match must stop the update. Repair the not-found branch so it reports the problem and leaves all records unchanged; repeat the failed test.
A plausible design includes intake, search, adult claim check and collection logging. Test a known fictional reference and an empty reference. A matching description alone cannot prove ownership; accept alternative designs that meet the stated requirements safely.

If a result differs, explain the first disagreement and try again with a fresh test. It is more useful to understand and repair a mistake than to hide it.

Learning evidence

Knowledge: Explain decomposition, abstraction, algorithm, input, output and testing in your own words. Give a correct example and distinguish a clear result from an unexplained blank.

Skills: Construct manageable parts, identify dependencies, trace a condition and compare expected with actual outcomes. Explain why a chosen detail matters for a particular purpose.

Product: Keep a labelled decomposition, input/output table, tested method and revision note. Include the original requirement and fictional starting data so someone else can reproduce the tests.

Transfer: Apply the ideas to lost property or another classroom problem. Explain a changed data choice and one limitation of your model.

Review: A teacher or partner should follow the plan without relying on your unstated intentions. A quiz score alone does not establish that you can build software. If you later implement the design, retain the runnable project and real test results, recording what was actually executed.

OER and Wikipedia

Department for Education: computing programmes of study. Key Stage 2 includes solving problems through decomposition, designing and debugging programs, reasoning and responsible technology use. This course's Year 5 allocation is editorial.

Barefoot Computing: Animated Poem Decomposition. A primary-school example of planning and creating through smaller tasks; optional teaching extension.

Barefoot Computing: guide to computational thinking. Background on decomposition, abstraction, algorithms and evaluation. The library examples and test data here are original teaching examples.

Picture: Toy Blocks (50995087111).jpg, ajay_suresh, CC BY 2.0. The Commons file is displayed without modification. The blocks provide an analogy; they are not a diagram of this software design.

Second picture: International books at Kent Library.jpg, Roc0ast3r, CC0. This unmodified library photograph illustrates why a catalogue must distinguish individual copies.

Video: Unplugged - Computational Thinking, Code.org/CodeAI, streamed from the publisher's YouTube channel. Streaming permission is distinct from an open-content licence.

Use the background article to extend your vocabulary, then return to the concrete input/output and test examples.