aiMOOC

Writing algorithms with sequence and flowcharts - Computing Year 5

QR-Code

Introduction

Imagine a pretend museum ticket machine. A visitor enters how many tickets they want; the machine displays a total. It cannot guess a missing price, decide what a vague instruction means or calculate with an input it has not yet received. You will design instructions precise enough for a partner to follow, represent them in a flowchart and test their order.

You will learn to distinguish an algorithm from a running program, use sequence and common flowchart symbols, trace changing values, label decisions and improve a design using test evidence. Paper, a pencil and the supplied examples are enough. Any computer implementation is an optional later step.

This is an editorial Year 5 sequence within England's Key Stage 2 computing programme. The key-stage expectations are statutory for relevant schools; this particular annual sequence and fictional ticket system are teaching choices.

Make instructions that can be followed

An algorithm describes precise steps for solving a problem or completing a task. For the small tasks here, it should finish after a finite number of steps for the inputs we allow. A program expresses instructions in a language a computer system can execute. A list or flowchart can represent an algorithm without being a running program.

State the starting conditions

Our fictional museum charges £3 for each ticket, with no discounts or extra fees. The first version accepts a whole-number quantity from zero to ten. The input is already checked as suitable; later you will design a decision to reject an unsuitable quantity. These assumptions matter: an algorithm for this classroom model is not a complete real payment system.

“Work out the tickets” does not specify the input, operation or output. A clearer plan is: read the quantity; multiply it by three; display the total in pounds. The order is called a sequence. Different correct representations can express the same sequence.

Try it before reading on

Ask a partner to follow “draw a square beside the circle”. What must already exist? Where is beside? Replace it with a starting sheet, a stated position and four equal sides. The lesson is not that a human lacks common sense: a precise specification makes the intended result testable.

Sequence and the input-process-output pattern

An input supplies data to the algorithm. A process changes or uses the data. An output communicates a result. A variable is a named place for a value that may change. Use quantity for the number entered and total for the calculated price.

Our first algorithm

Start.
Read quantity as a whole number from zero to ten.
Set total to quantity multiplied by three.
Display total, labelled in pounds.
End.

For quantity four, the process calculates four times three, so the output is £12. For quantity seven, it is £21. The same instructions accept different allowed inputs; you do not rewrite the multiplication for each visitor.

Why order matters

Suppose you display total before calculating it. On paper its value has not yet been defined. In different programming environments that might cause an error or reveal an old or default value. None of those is a reliable display of the current visitor's price. Do not assume a particular computer error message without choosing and running an implementation.

Some independent actions can be rearranged without changing the result. However, calculating a total depends on knowing the quantity, and displaying this total depends on calculating it. Explain these dependencies rather than saying that changing any order always breaks every algorithm.

Watch, pause and predict

Code.org's paper-airplane lesson connects an everyday sequence with an algorithm. Before a fold, predict why it must occur before or after another step. You can discuss the demonstration without making or throwing a plane; follow your teacher's arrangements if doing the activity. Then explain which dependencies exist in the ticket sequence.

Read and draw a flowchart

A flowchart uses labelled shapes and arrows to represent the flow of instructions. Common conventions use a rounded start/end shape, a rectangle for an action, a parallelogram for input or output and a diamond for a decision. The text and arrows must still explain the algorithm; colour alone is not enough.

Common shape	Label for the ticket example	Next destination
Rounded start/end shape	Start	Read quantity
Input/output parallelogram	Read quantity	Calculate total
Process rectangle	Set total to quantity multiplied by three	Display total
Input/output parallelogram	Display total in pounds	End
Rounded start/end shape	End	No next step in this example

This table is a text equivalent of the one-way flowchart. Draw the five shapes on paper and join them with arrowheads. Give each action one clear meaning. You can draw the sequence horizontally or vertically: the arrows determine the order. Lines that cross should not accidentally imply a connection.

Add one clearly defined decision

A second version receives a whole-number quantity and asks, “Is quantity between zero and ten inclusive?” Put that yes/no question in a diamond. Label the outgoing arrows Yes and No. The Yes path calculates and displays the total; the No path displays “Enter a whole number from zero to ten” and ends. Both routes reach an end. This model deliberately does not keep asking forever.

Real software must also handle non-numeric text. Our classroom decision assumes that a whole number has already been read; it does not magically convert letters into numbers. Write assumptions beside your design so a later programmer can see what remains to be built.

Trace values and find the first wrong step

To trace an algorithm, follow its steps with a particular input and record what happens. Do not jump straight to the answer you expect. A trace table makes the state visible after each relevant step.

After this step	quantity	total	Output so far
Start	Not read	Not calculated	None
Read quantity	4	Not calculated	None
Calculate total	4	12	None
Display total	4	12	£12
End	4	12	No additional output

Predict first

Trace the same sequence for quantity zero and quantity ten. A hint: multiplication by three is still the same operation at the ends of the allowed range. The expected totals are £0 and £30. These are boundary tests because they use the limits of the stated range. They do not prove correctness for every possible input in a real system.

A bug to diagnose

A learner writes: read quantity; set total to quantity plus three; display total. For input four, the actual result is £7, although the expected result is £12. The first disagreement is in the calculation, not the display. Replace addition with multiplication, then retest several inputs. For input zero, the faulty design produces £3, making the same fault particularly clear.

For the decision version, test minus one, zero, ten and eleven. Expected routes are No, Yes, Yes and No respectively. Never insert a rejected quantity into the price calculation after taking the No path. Record expected and actual routes; an unexplained tick beside “tested” is weak evidence.

Improve a design and explain its limits

A good design meets a stated requirement. You can make the ticket algorithm clearer by including the currency in its output, keeping the quantity range beside the input and labelling both decision arrows. These improvements do not require decorative shapes or a longer program.

Transfer to a new price

A school event uses the same model but charges £4 per ticket. Change the price used in the calculation, then check inputs zero, one and five. Expected totals are £0, £4 and £20. Retain the order: read, calculate, display. The new setting is fictional; it does not describe a real school's prices.

Stretch: inspect the introductory diagram

The Commons diagram starts by setting i to one. It outputs i, asks whether i equals 39 and, on the true path, changes i to 61 before returning to the output. On the false path it increases i by one and checks whether i is at most 100. Here := means assign a value, whereas the question i = 39 compares values.

The visible output begins 1, 2, 3 and continues through 39; it then jumps to 61 and continues through 100. It omits 40 to 60. The final increase makes i equal 101, but that value is not output because the stopping decision then fails. This extension shows why following arrow directions and the order of output and update matters. You do not need to memorise this larger chart to design the simple ticket flowchart.

Evidence of improvement

Keep your first draft, an annotated trace identifying a fault, the corrected chart and new tests. If you implement it in a school-approved language, record the actual code and actual outputs separately from paper predictions. A successful paper trace supports the reasoning; it does not prove that an untested computer program runs.

Interactive Tasks

Quiz: Test Your Knowledge

Which description best fits an algorithm in this lesson? (Precise steps for completing a specified task.) (!Any attractive picture without instructions.) (!Only a program that is already running.) (!A guess about an unspecified result.)

Why must the quantity be read before the total is calculated? (The calculation depends on the current quantity.) (!Reading quantity changes the ticket price to zero.) (!A flowchart cannot contain input.) (!The display should always show an old result.)

What is the total for seven tickets at three pounds each? (Twenty-one pounds.) (!Ten pounds.) (!Four pounds.) (!Seventy-three pounds.)

Which common flowchart shape represents a decision? (A diamond containing a clear question.) (!An unlabelled decorative circle.) (!A photograph with no arrows.) (!A paragraph with no condition.)

What determines the order of a flowchart? (The directed arrows between its steps.) (!Only the colours chosen.) (!Always reading the rightmost box first.) (!The alphabetical order of labels.)

Which test uses a boundary of the first ticket model? (Entering ten tickets.) (!Entering five tickets only.) (!Changing the font of the title.) (!Deleting the input range.)

A faulty algorithm adds three to quantity four. What result does it produce? (Seven pounds.) (!Twelve pounds.) (!One pound.) (!Forty-three pounds.)

What should happen to quantity eleven in the decision version? (Follow the No path and display the stated input-range message.) (!Calculate the accepted ticket total anyway.) (!Pretend eleven is ten without explaining it.) (!Delete the decision from the test record.)

Which statement about a flowchart is accurate? (It can represent an algorithm without being a running program.) (!Drawing it proves every implementation works.) (!Its arrows never affect meaning.) (!It always handles every possible text input automatically.)

What is useful evidence after correcting the calculation? (A corrected chart and new expected-versus-actual traces.) (!A tick saying tested without any input or result.) (!Removing all failed tests from the record.) (!Assuming a new picture fixes the calculation.)

Memory Game

Algorithm	Precise steps for a specified task.
Sequence	The intended order of instructions.
Input	Data supplied to the process.
Output	A result communicated to a user or another process.
Trace	A step-by-step record for a particular input.
Boundary test	A check at a stated limit of an allowed range.

Drag and Drop

Rounded start shape	Marks the entry to the represented process.
Input parallelogram	Reads the ticket quantity.
Process rectangle	Calculates the ticket total.
Decision diamond	Checks whether the quantity lies in the allowed range.
Directed arrow	Identifies which step is followed next.

Crossword Puzzle

algorithm	A precise method for completing the specified task.
sequence	The intended order of steps.
input	Data supplied before the calculation.
output	The result displayed after processing.
diamond	The common shape for a yes-or-no decision.
trace	Follow the steps and record values for one case.

LearningApps

Optional extra practice. Choose an appropriate activity with your teacher. If the external collection is unavailable, use the native activities and independent tasks in this course.

Cloze Text

Open Tasks

Easy

Specify a ticket-machine task: Write the price, allowed input and required output for the fictional museum. Explain why leaving out the price makes the task ambiguous.
Order the ticket instructions: Write read quantity, calculate total and display total on separate cards. Arrange them and explain the two data dependencies.
Draw a five-step flowchart: Use the stated shape conventions for Start, input, calculation, output and End. Add arrowheads and a text equivalent.
Trace one ticket order: Make a table for quantity two. Include the state before input and after calculation; distinguish no value yet from zero.

Standard

Test ticket-range boundaries: Trace quantities zero and ten, predict both totals before checking, and explain why these are boundary tests.
Repair the addition bug: Compare expected and actual outputs for quantities zero, four and seven when the design adds three. Locate and correct the first wrong step.
Add a range decision: Draw the whole-number range decision with labelled Yes and No paths. Trace minus one and eleven as well as an accepted input.
Review a partner's flowchart: Follow only the written arrows and labels. Identify one ambiguity, explain its consequence and propose a precise revision.

Advanced

Change a ticket requirement: Adapt the algorithm to four pounds per ticket and show three new tests. Explain what changes and which dependencies remain.
Explain the skipped output values: Trace the introductory Commons diagram around values 38, 39, 61 and 100. Explain why 40 and 101 are not output.
Compare two valid flowcharts: Draw a horizontal and a vertical version of the same algorithm. Explain why the arrow-defined sequence, rather than page position, establishes equivalence.
Separate planning from implementation evidence: Describe how you would implement the design in a school-approved language. State the artefacts and actual test results needed before claiming that implementation works.

Learning Check

Design an input-process-output algorithm: Create a complete flowchart for a fictional event charging four pounds per ticket. State allowed inputs and output units.
Trace two current inputs: Trace the original three-pound design for quantities zero and six, showing values after every relevant step.
Diagnose an order fault: A design displays total before reading quantity and calculating. Explain the dependency fault without inventing a particular programming environment's error.
Evaluate both decision routes: For the range-checking version, give the expected route and output type for quantities minus one, zero, ten and eleven.
Justify an improvement with evidence: Show one corrected fault or clarified label, a before-and-after trace and a new test. Explain what the evidence does and does not establish.

Worked checks and assessment guidance

A suitable design reads the whole-number quantity, calculates total as quantity multiplied by four and displays total in pounds, between Start and End. The stated range and assumptions must agree with the tests.
Before reading, quantity is not supplied and total is not calculated. The two traces calculate zero and eighteen respectively; only the display step outputs £0 or £18.
The displayed result cannot reliably be this order's calculated total. Read quantity first, calculate the total next and display that result afterwards. A real language may signal an error or supply an old/default value; it must be tested.
The routes are No, Yes, Yes, No. The accepted cases display £0 and £30; the rejected cases display the input-range message and end. This design assumes a whole-number input has already been read.
For the addition fault, quantity four changes from £7 to the expected £12 after replacing addition with multiplication. Retest zero and another allowed quantity. Paper traces support the algorithm; actual code and execution results are still needed to establish that an implementation runs.

Learning evidence

Knowledge: Explain algorithm, program, sequence, input, process, output, variable, decision and boundary test in the ticket context.

Skills: Specify assumptions, draw directed flow, trace values, locate the first disagreement and justify a correction.

Products: Keep a labelled flowchart, its text equivalent, tests with expected and actual results, and a short explanation of a revision. Retain failed tests as useful evidence.

Transfer: Adapt the model to another fictional price or output requirement and explain the dependencies that remain.

Practical distinction: Mark paper traces as paper traces. To claim a program runs, provide the chosen implementation and reproducible execution evidence. Quiz points alone do not establish that practical outcome.

OER and Wikipedia

Department for Education: computing programmes of study. The Key Stage 2 programme addresses algorithms, sequence and reasoning about programs; placement in Year 5 here is editorial.

Code.org: Real-Life Algorithms, Paper Airplanes. The video supports discussion of order and precise instructions. The ticket example, traces, tests and assessment material in this course are original teaching examples.

Diagram: Flowchart en.svg, Erik Streb, CC BY-SA 3.0. Unmodified. The diagram's larger repeated process is explicitly treated as a stretch activity.

Photograph: Toy Blocks, ajay_suresh, CC BY 2.0. Unmodified.

Video: Unplugged - Real-Life Algorithms: Paper Airplanes, Code.org / CodeAI. Streamed through the original publisher's YouTube embed. The text provides an independent accessible route through the ideas.