Unit 4 Programming

Task 7 Study Notes

Build practical confidence in the order you will use during the test: read the scenario, plan the data, choose the control structures, test with evidence and debug accurately.

Practise scenarios Check with quizzes Timed mock

Test Routine

Use The Same Process Every Time

1

Annotate the scenario

2

Plan IPO and variables

3

Draft pseudocode

4

Build the simplest version

5

Test, trace and submit

scenario reading

Read The Scenario Like A Programmer

Most practical mistakes begin before coding. Students rush past the scenario and build the wrong thing.

What to know

  • Inputs are the values the program receives.
  • Processing is the calculation, comparison, counter update or decision.
  • Outputs are the messages, totals, recommendations or results shown to the user.
  • Every repeated action should be marked as a loop before coding starts.

Example

If a task says "enter three scores and display the average", the inputs are the three scores, the processing is total and average calculation, and the output is the average.

Do this in the practical

Spend the first five minutes circling inputs, underlining processing and boxing outputs.

Avoid

  • Starting with a decorated interface
  • Using variables before deciding what they store
  • Missing a repeated action in the scenario

Model Question

Identify the inputs, processing and outputs for a program that asks for three study times and displays the total.

Inputs are the three study times. Processing is adding the times to calculate a total. Output is the total study time displayed to the user.

data types

Data Types And Variables

A variable is only useful when its name and data type match the value it stores.

What to know

  • Integer stores whole numbers such as minutes, counts and scores.
  • Real stores decimal numbers such as averages or prices.
  • Boolean stores true/false conditions such as whether a session is balanced.
  • Character stores a single character such as Y or N; class tools may use string/text for names and longer labels.

Example

`balancedCount` should be an integer because it stores a whole-number count. `isBalanced` should be Boolean because it stores true or false.

Do this in the practical

Write a data plan before coding: value, variable name, data type and purpose.

Avoid

  • Using `x` and `y` when the task has meaningful values
  • Using a decimal type for a whole-number counter without reason
  • Confusing Boolean values with text values

Model Question

Choose a suitable data type for `totalMinutes` and justify your choice.

`totalMinutes` should be an integer because it stores a whole-number count of minutes calculated from the study session inputs.

control structures

Control Structures

The practical test will reward visible use of sequence, selection and iteration.

What to know

  • Sequence means instructions run in a logical order.
  • Selection means the program chooses a path based on a condition.
  • Iteration means part of the program repeats.
  • A fixed loop suits a known number of repeats; a while or repeat-until loop suits user-controlled repetition or validation.

Example

A program that checks three study sessions can use a fixed loop from 1 to 3, then use selection to classify each total as short, balanced or long.

Do this in the practical

Build one working path first, then add the decision, then add the loop.

Avoid

  • Using three copied blocks instead of a loop
  • Writing conditions that exclude boundary values
  • Putting the final output inside the loop when it should appear once at the end

Model Question

Which loop is suitable when a program must process exactly three sessions?

A fixed loop such as `FOR session <- 1 TO 3` is suitable because the number of repetitions is known before the loop starts.

testing

Testing And Boundary Data

Testing is not just running the program once. It should show whether the logic works for expected values and edge cases.

What to know

  • Normal data checks typical valid input.
  • Boundary data checks values at or near the edges of a rule.
  • Invalid data checks values that should be rejected or handled.
  • Expected and actual results should be compared.

Example

For a balanced session rule of 30 to 60 minutes, test 30, 60, 29 and 61.

Do this in the practical

Write the expected result before running the test.

Avoid

  • Only testing values that are obviously easy
  • Forgetting boundary values
  • Writing pass without recording the actual result

Model Question

Give two boundary tests for a program that accepts ratings from 1 to 5.

Boundary tests should include 1 and 5 because they are the lowest and highest valid ratings. It is also useful to test 0 and 6 to check just outside the valid range.

trace debug

Trace Tables And Debugging

Trace tables make logic visible. They are the best way to catch counter and comparison errors.

What to know

  • List the variables as columns.
  • Record starting values before the loop runs.
  • Update a value only when the algorithm changes it.
  • Use the trace to explain syntax, run-time or logical errors.

Example

If a counter stays at 1 instead of increasing to 2 or 3, the trace table shows that `balancedCount <- 1` should be `balancedCount <- balancedCount + 1`.

Do this in the practical

Trace one full loop iteration and one boundary decision before submitting.

Avoid

  • Changing every column on every row
  • Skipping the starting value row
  • Calling every error a syntax error

Model Question

A program should count passes, but the trace table shows the counter always returns to 1. Identify the likely error.

The likely error is a logical error. The code is probably setting the counter to 1 instead of increasing the existing value by 1.