A-Level Computer Science / Unit 11: Structured Programming

11.1.1 Turning a Design into Pseudocode

🔒 Lesson slides are available to signed-in users. Sign in

11.1.1 Turning a Design into Pseudocode

A program design describes the logic that a solution must follow. Before that solution can be implemented, the design must be converted into precise pseudocode statements.

In this section, you will translate two common design representations: structured English and program flowcharts. The aim is not to invent a different algorithm. It is to preserve the supplied logic accurately.

By the end of this section, you should be able to:

  • Identify the inputs, processing and outputs specified by a design.
  • Recognise sequence, selection and repetition in a supplied design.
  • Translate structured English into equivalent pseudocode.
  • Translate flowchart symbols and paths into pseudocode statements.
  • Use suitable identifiers for the data represented in the design.
  • Check that every possible path has been implemented correctly.
Connection to Unit 9: Unit 9 introduced ways of representing and refining algorithms. This page concentrates on implementing a design whose required behaviour has already been decided.

From a Design to an Implementation

A design is a plan for solving a problem. It may use controlled sentences, diagram symbols or labelled paths, but it should already describe the essential behaviour of the algorithm.

Implementation: expressing a completed design in a precise form that can be followed, translated or executed.

When a design is translated into pseudocode, its representation changes. Its behaviour should not.

The design specifies The pseudocode must preserve
Values entering the algorithm The same input operations
Calculations and updates The same processing
Conditions and alternative paths The same decisions and branches
Steps that must be repeated The same loop body and stopping point
The order of operations The same sequence and nesting
Required results or messages The same outputs
Common misconception: implementing a design does not mean replacing it with a solution you prefer. Unless improvement is requested, the pseudocode should reproduce the supplied behaviour.

Analyse the Complete Design First

Translating the first instruction immediately can cause errors later. Read the complete design first so that you understand its data, paths and final result.

Find the input, process and output

Part Question to ask Typical pseudocode
Input What data must enter the algorithm? INPUT
Process What must be calculated, stored, changed or tested? Assignment, selection or repetition
Output What result or message must be produced? OUTPUT

Identify the data

Each important value should be represented by a meaningful identifier. At this stage, concentrate on what each identifier stores. Data-type selection is revised briefly on the next page.

Weak identifier Improved identifier Reason
x PacketCount Shows that the value is a number of packets
t TotalCost Shows that the value stores a calculated cost
a BatteryLevel Shows what the percentage represents

Look for control structures

Design clue Likely structure
One operation follows another Sequence
“If”, “otherwise”, or a decision diamond Selection
“For each”, “repeat”, “while”, or a returning arrow Repetition
Exam tip: annotate the design before writing pseudocode. Mark inputs with I, processing with P, outputs with O, and identify every decision or repeated path.

Translating Structured English

Structured English describes an algorithm using short, ordered instructions. It is more controlled than ordinary prose, but it does not always use formal pseudocode keywords.

Structured English: an algorithm description written using ordered statements and a limited, consistent vocabulary.

Example design: seed-order calculator

  1. Read the number of seed packets required.
  2. Each packet costs $3.
  3. Calculate the total amount due.
  4. Display the total amount.

Step 1: identify the data

Identifier Purpose
PacketCount Stores the number of packets entered
TotalCost Stores the calculated amount due

Step 2: translate the instructions

DECLARE PacketCount : INTEGER
DECLARE TotalCost : INTEGER

INPUT PacketCount
TotalCost ← PacketCount * 3
OUTPUT "Amount due: $", TotalCost

The pseudocode follows the same sequence as the design: input first, processing second and output last.

Common mistake: do not remove the assignment to TotalCost when the design explicitly requires the calculated amount to be stored.

Translating a Program Flowchart

A program flowchart represents operations using standard symbols connected by arrows. The arrows determine the order in which operations are followed.

Flowchart element Meaning Possible pseudocode
Start or end terminator Beginning or end of the algorithm Usually no separate statement
Input/output parallelogram Data enters or leaves the algorithm INPUT or OUTPUT
Process rectangle A calculation, assignment or update Total ← Price * Quantity
Decision diamond A condition divides execution into paths IF ... THEN ... ELSE
Arrow returning to an earlier symbol Part of the flowchart is repeated A suitable loop

Original flowchart scenario

Equivalent pseudocode

DECLARE SoilMoisture : INTEGER

INPUT SoilMoisture

IF SoilMoisture < 35
THEN
    OUTPUT "Start irrigation"
ELSE
    OUTPUT "Moisture sufficient"
ENDIF

The Yes path becomes the THEN branch. The No path becomes the ELSE branch.

Preserve the wording of the condition carefully. For example, below 35 means < 35, not <= 35.

Translating a Repeated Path

A returning flowchart arrow or an instruction such as “repeat five times” indicates that one or more operations belong inside a loop.

Example design: weekly packing total

  1. Set the weekly total to zero.
  2. For each of five working days:
  3. Input the number of orders packed that day.
  4. Add the daily number to the weekly total.
  5. After the repetition ends, display the weekly total.

Equivalent pseudocode

DECLARE Day : INTEGER
DECLARE OrdersPacked : INTEGER
DECLARE WeeklyTotal : INTEGER

WeeklyTotal ← 0

FOR Day ← 1 TO 5
    INPUT OrdersPacked
    WeeklyTotal ← WeeklyTotal + OrdersPacked
NEXT Day

OUTPUT WeeklyTotal

The input and update are inside the loop because they occur once for each day. The final output is outside the loop because it is required only after all five values have been processed.

Common mistake: placing WeeklyTotal ← 0 inside the loop would erase the previous total during every iteration.
At this stage, the design tells you that the repetition occurs five times. Choosing between different loop structures is studied in more depth in Section 11.2.

A Reliable Five-Stage Translation Method

Stage What to do Useful check
1. Read Read the complete design before translating it. Do you understand the intended result?
2. Identify List inputs, stored values, calculations and outputs. Are meaningful identifiers used consistently?
3. Map Mark sequence, decisions, branches and repeated paths. Does each design structure have a pseudocode equivalent?
4. Write Translate the design in the same logical order. Has any step been moved or omitted?
5. Check Trace the design and pseudocode with the same sample data. Do they follow the same paths and produce the same result?
One-to-one check: for every input, process, output, decision and repeated path in the design, find the corresponding pseudocode statement or structure.

Worked Example: Workshop Battery Check

Supplied structured-English design

  1. Input the battery percentage.
  2. If the percentage is below 28, display “Charge before use”.
  3. Otherwise, display “Ready for the workshop”.
  4. Display “Battery check complete”.

Analyse the design

Design feature Interpretation
Input the battery percentage One integer input is required
Below 28 A condition using <
Otherwise An alternative branch is required
Battery check complete This message occurs after either branch

Completed pseudocode

DECLARE BatteryLevel : INTEGER

INPUT BatteryLevel

IF BatteryLevel < 28
THEN
    OUTPUT "Charge before use"
ELSE
    OUTPUT "Ready for the workshop"
ENDIF

OUTPUT "Battery check complete"

The final output appears after ENDIF because it must occur regardless of which branch is followed.

Common mistake: placing the final message inside only one branch changes the behaviour of the supplied design.

Interactive: Design-to-Pseudocode Lab

Select a design and move through the translation stages. The widget reveals the input, processing, output and control structure before displaying the complete pseudocode.

Seed-order calculator Structured English
  1. Read the number of seed packets.
  2. Each packet costs $3.
  3. Calculate the amount due.
  4. Display the amount due.
Pseudocode under construction Stage 1 of 5 
// Read the complete design first.

Translation process

Read Identify Map Write Check

Read the complete design without translating individual lines yet.

Input Not identified yet
Process or decision Not identified yet
Output Not identified yet

Move through the method

Stage 1: understand the complete design.

Quick check

Choose an answer.

Use the same method on paper: read, identify, map, write and check.

Common Mistakes and Misconceptions

  • Redesigning the algorithm: adding calculations, validation or messages that were not requested.
  • Changing a condition: writing <= when the design says “below”.
  • Missing a branch: translating the Yes path but forgetting the No path.
  • Changing the order: producing output before its value has been calculated.
  • Incorrect nesting: putting a statement inside a selection or loop when the design shows it occurs afterward.
  • Wrong loop placement: initialising a total inside the repeated section.
  • Mixing notations: using programming-language syntax instead of the required pseudocode convention.

Practice

Question 1: Sequence

A school print station follows this design:

  1. Input the number of colour pages.
  2. Calculate the cost at $0.35 per page.
  3. Output the cost.

Write pseudocode that implements the design. Use meaningful identifiers.

Question 2: Decision path

A program flowchart performs these operations:

  1. Input RoomTemperature.
  2. Test whether RoomTemperature > 27.
  3. If Yes, output “Open the vents”.
  4. If No, output “Leave the vents closed”.
  5. End.

Write the equivalent pseudocode.

Question 3: Repetition

A design states:

  1. Set TotalDistance to zero.
  2. Repeat four times.
  3. Input a journey distance.
  4. Add the journey distance to TotalDistance.
  5. After the repetition, output TotalDistance.

Write pseudocode that implements the design.

Question 4: Find the implementation errors

The design states:

  1. Input a distance.
  2. If the distance is at least 12, output “Long route”.
  3. Otherwise, output “Short route”.
  4. Output “Route selected”.

A student writes:

INPUT Distance

IF Distance > 12
THEN
    OUTPUT "Long route"
    OUTPUT "Route selected"
ELSE
    OUTPUT "Short route"
ENDIF

Identify and correct two differences from the supplied design.

Show suggested answers

Question 1

DECLARE ColourPages : INTEGER
DECLARE PrintCost : REAL

INPUT ColourPages
PrintCost ← ColourPages * 0.35
OUTPUT PrintCost

Question 2

DECLARE RoomTemperature : INTEGER

INPUT RoomTemperature

IF RoomTemperature > 27
THEN
    OUTPUT "Open the vents"
ELSE
    OUTPUT "Leave the vents closed"
ENDIF

Question 3

DECLARE Journey : INTEGER
DECLARE JourneyDistance : REAL
DECLARE TotalDistance : REAL

TotalDistance ← 0

FOR Journey ← 1 TO 4
    INPUT JourneyDistance
    TotalDistance ← TotalDistance + JourneyDistance
NEXT Journey

OUTPUT TotalDistance

Question 4

  • “At least 12” requires >= 12, not > 12.
  • OUTPUT "Route selected" must appear after ENDIF so that it follows either branch.

Review

Check Question to ask yourself
Inputs Have all required values been read?
Identifiers Does each name communicate what the value represents?
Processes Are all calculations, assignments and updates present?
Conditions Are comparison operators and branches unchanged?
Repetition Are the correct statements inside and outside the loop?
Order Do the statements occur in the required sequence?
Outputs Are all required results and messages produced?
Final exam tip: do not judge the answer only by whether it looks plausible. Compare it directly with the supplied design and confirm that every possible path has an equivalent implementation.