Computer Science 9618/23 — October/November 2024

Background Concept

This question is about recognising common programming constructs in CIE pseudocode.

• Selection means making a decision between alternatives or deciding whether a block of code runs. Typical selection keywords are IF ... THEN, ELSE, and CASE OF.
• Iteration means repetition. Typical iteration keywords are FOR, WHILE, and REPEAT UNTIL.
• A subroutine is a named block of code that can be used from elsewhere. In this syllabus, that means a procedure or a function. A function call often appears as an identifier followed by brackets, such as Name() or Name(3).

A single pseudocode example can belong to more than one category. For example, a loop might contain an IF, so it is both iteration and selection.

Understanding the Question

You are given four pseudocode fragments and must decide which programming ideas appear in each one.

The key point is that you are not being asked what the code does overall. You are only being asked whether each example contains:

• a decision
• a repetition structure
• a procedure or function call

Because the table says "one or more ticks", some rows need more than one tick.

Approach

For each row:

1. Look for loop keywords such as FOR, WHILE, or REPEAT UNTIL to spot iteration.
2. Look for decision keywords such as IF or CASE OF to spot selection.
3. Look for a named call with brackets, such as Compound(3) or AllDone(), to spot a subroutine.

Then tick every category that applies.

Step-by-Step Reasoning

Row 1

FOR Index ← 1 TO 3 ... NEXT Index

• FOR ... NEXT is a count-controlled loop, so this is iteration.
• Inside the loop there is IF Safe[Index] = TRUE THEN, which is selection.
• There is no procedure or function call here, so subroutine is not ticked.

So row 1 gets Selection and Iteration.

Row 2

CASE OF Compound(3)

• CASE OF is a multi-way decision, so this is selection.
• Compound(3) is a function call because it is a named item with brackets and an argument.
• There is no loop structure, so it is not iteration.

So row 2 gets Selection and Subroutine.

Row 3

REPEAT UNTIL AllDone() = TRUE

• REPEAT UNTIL is a post-condition loop, so this is iteration.
• AllDone() is a function call, so this is also subroutine.
• The condition is checked for loop termination, but the main structure is not an IF or CASE OF, so this is not classified as selection here.

So row 3 gets Iteration and Subroutine.

Row 4

WHILE Result[3] <> FALSE

• WHILE is a pre-condition loop, so this is iteration.
• Result[3] is just an array element, not a function call.
• There is no IF or CASE OF, so no selection tick.

So row 4 gets Iteration only.

Key Takeaways

• Learn the signature keywords for each construct: IF and CASE OF for selection, FOR/WHILE/REPEAT UNTIL for iteration.
• A function or procedure call is usually recognised by a name followed by brackets.
• One piece of pseudocode can contain more than one construct, so always check the whole fragment.

Common Mistakes

• Ticking only one box per row: the question explicitly allows more than one tick.
• Treating any condition as selection: a condition inside WHILE or REPEAT UNTIL is still part of an iteration structure.
• Missing a function call: Compound(3) and AllDone() are subroutine calls because of the brackets.
• Thinking array indexing is a subroutine: Result[3] is an array access, not a function.

Things to Be Careful About

• Read the exact keyword, not just the line quickly. CASE OF is selection, while WHILE is iteration.
• Do not confuse a loop condition with an IF statement.
• In CIE pseudocode, brackets after an identifier are a strong clue that it is a procedure or function call.
• Check the entire example before deciding; a loop may also contain a selection statement inside it.

Background Concept

A data type tells the program what kind of value a variable stores and what operations are valid for it.

Common basic data types in this syllabus include:

• BOOLEAN: only TRUE or FALSE
• INTEGER: whole numbers such as 0, 17, 100, -4
• REAL: numbers with a fractional part such as 3.5
• CHAR: a single character
• STRING: a sequence of characters, usually shown in quotes

The example value often gives the answer immediately.

Understanding the Question

You are given three variables and one sample value for each. You must name the appropriate data type.

The important clue is the form of the value:

• whether it is TRUE/FALSE
• whether it is surrounded by quotation marks
• whether it is a whole number

You are not being asked what the variable name suggests. You are being asked what type fits the given value.

Approach

Look at each example value and classify it by its form:

1. Boolean literal?
2. Quoted text?
3. Whole number?

Then write the standard CIE pseudocode type name in uppercase.

Step-by-Step Reasoning

Available = TRUE

TRUE is one of the two Boolean values: TRUE or FALSE.

So the data type is BOOLEAN.

Received = "18/04/2021"

Even though it looks like a date to a human, it is written inside quotation marks. In this pseudocode context, quoted data is treated as text.

So the data type is STRING.

Index = 100

100 is a whole number with no decimal point.

So the data type is INTEGER.

Key Takeaways

• TRUE and FALSE are BOOLEAN values.
• Anything in quotation marks is normally a STRING in this syllabus.
• Whole numbers are INTEGER values.
• Always classify the actual value shown, not what you think the variable might represent in real life.

Common Mistakes

• Calling "18/04/2021" a date type: date is not the expected basic answer here; because it is quoted, it is treated as a string.
• Calling 100 a real number: it has no fractional part, so INTEGER is the best answer.
• Writing BOOL or INT instead of full type names: exam answers should use the standard type names such as BOOLEAN and INTEGER.

Things to Be Careful About

• Quotation marks are a major clue: quoted values are strings.
• Do not let the variable name mislead you. For example, Received sounds like a date field, but the example value shown determines the type.
• Use the exact type vocabulary expected in pseudocode: BOOLEAN, STRING, INTEGER.

Background Concept

An expression is a combination of values, variables, operators, and sometimes function calls that produces a result.

This question uses three important ideas:

• Boolean logic: operators such as AND and NOT work with Boolean values.
• Arithmetic operators: MOD gives the remainder after division.
• Type checking: some operations are invalid if the data types do not match.

From part (b), the values are:

• Available = TRUE
• Index = 100

Also remember:

• Index > 100 produces a Boolean value.
• NOT reverses a Boolean value.
• MOD means remainder.
• NUM_TO_STR(...) converts a number to a string, but the expression inside it must first be valid.

Understanding the Question

You must evaluate each expression using the values already identified in part (b). If an expression is not valid, you must write ERROR.

So there are really two tasks for each row:

1. Work out the value if the expression is valid.
2. Check whether the types used in the expression make sense.

The third expression is designed to test whether you notice a type mismatch before the conversion function is applied.

Approach

For each expression:

1. Substitute the known variable values.
2. Evaluate inner parts first, such as comparisons in brackets.
3. Apply the operators in a sensible order.
4. Check that each operation uses compatible data types.

If any operation is invalid, the whole expression becomes ERROR.

Step-by-Step Reasoning

1. Available AND NOT(Index > 100)

Substitute the values:

• Available is TRUE
• Index is 100

So the expression becomes:

TRUE AND NOT(100 > 100)

Now evaluate the comparison:

• 100 > 100 is FALSE because 100 is not greater than 100

So now we have:

TRUE AND NOT(FALSE)

Apply NOT:

• NOT(FALSE) is TRUE

Now the expression is:

TRUE AND TRUE

And that evaluates to TRUE.

2. Index MOD 30

Substitute Index = 100:

100 MOD 30

MOD gives the remainder after division.

• $100 \div 30 = 3$ remainder $10$

So the result is 10.

3. NUM_TO_STR(Index + "33")

Substitute Index = 100:

NUM_TO_STR(100 + "33")

Now look at the expression inside the function first:

• 100 is an INTEGER
• "33" is a STRING

Using + between an integer and a string is not valid in this pseudocode context. The problem occurs before NUM_TO_STR can do anything.

So the correct result is ERROR.

A common trap is to think the function will somehow fix the mixed types, but it only converts a valid numeric result into a string. It does not make an invalid addition legal.

Key Takeaways

• Always substitute known values carefully before evaluating.
• Comparison expressions such as Index > 100 produce Boolean results.
• NOT reverses a Boolean value, and AND combines Boolean values.
• MOD returns the remainder, not the quotient.
• A conversion function does not rescue an invalid inner expression.

Common Mistakes

• Saying 100 > 100 is true: it is false, because greater than does not include equality.
• Giving 3 for 100 MOD 30: 3 is the quotient, not the remainder; the remainder is 10.
• Writing 10033 for the third expression: that would be string concatenation, but the operator shown is not valid here because the types do not match.
• Thinking NUM_TO_STR makes the whole line valid automatically: the inside of the brackets must still be a valid numeric expression first.

Things to Be Careful About

• Evaluate the bracketed comparison before applying NOT.
• Keep track of data types from part (b): Available is Boolean, Index is integer, and "33" is string.
• MOD only works as intended with integer arithmetic in this kind of question.
• When the instruction says write ERROR if the expression contains an error, do not try to force a value anyway.

Background Concept

This question is about writing an algorithm in CIE-style pseudocode using the three basic programming constructs:

• sequence: statements happen one after another in order
• selection: a decision is made, usually with IF ... THEN
• iteration: a set of statements repeats, usually with FOR, WHILE or REPEAT

It also uses a very common programming pattern called an accumulator. An accumulator is a variable, often called something like Total or Sum, that starts at an initial value and is updated repeatedly. Here, the algorithm must add only the positive integers, so the accumulator starts at 0 and only changes when the input value is greater than 0.

Because the algorithm must process exactly 100 values, a count-controlled loop is the most suitable form of iteration. In CIE pseudocode, that is usually written with FOR Count ← 1 TO 100.

Understanding the Question

The question gives the algorithm in words:

1. input 100 integer values, one at a time
2. sum the positive integers
3. output the sum

It also adds an important rule: zero is neither positive nor negative. That means a value of 0 must not be added to the total.

So the pseudocode must do all of these things:

• declare every variable used
• repeat the input process exactly 100 times
• check each value
• add it to the running total only if it is positive
• output the final total after all 100 values have been processed

The clue that helps choose the loop is the phrase sequence of 100 integer values. Since the number of repetitions is fixed, a FOR loop is the natural choice.

Approach

A good way to build this algorithm is:

1. Declare the variables.
   • one variable for the current input value
   • one variable for the loop counter
   • one variable for the running total
2. Set the running total to 0.
3. Use a FOR loop from 1 to 100.
4. Inside the loop, input one integer.
5. Use an IF statement to test whether it is greater than 0.
6. If it is, add it to the sum.
7. After the loop ends, output the sum.

This is efficient and matches the specification exactly.

Step-by-Step Reasoning

Start with the declarations:

DECLARE Number, Count, Sum : INTEGER

• Number stores each integer as it is entered.
• Count controls the loop and makes sure the algorithm runs exactly 100 times.
• Sum stores the running total.

Next, initialise the accumulator:

Sum ← 0

This is essential. If Sum is not set before being used, the total would be undefined.

Now create the count-controlled loop:

FOR Count ← 1 TO 100

This means the block inside the loop will execute exactly 100 times, once for each value in the sequence.

Inside the loop, prompt and input a value:

   OUTPUT "Enter value"
   INPUT Number

The prompt is optional in some mark schemes, but it matches the wording of the task because the user is being prompted before input.

Then test whether the number is positive:

   IF Number > 0 THEN

This uses the definition of positive correctly:

• positive means greater than 0
• 0 is not positive, so it must not be included
• negative values must not be included either

If the condition is true, update the running total:

      Sum ← Sum + Number

This is the accumulator step. Each positive number is added onto the total already stored in Sum.

Close the selection and loop:

   ENDIF
NEXT Count

Finally, when all 100 values have been processed, output the result:

OUTPUT Sum

That final output must come after the loop. If it were inside the loop, the program would output the running total 100 times instead of outputting the final answer once.

Key Takeaways

• Use a count-controlled FOR loop when the number of repetitions is known in advance.
• Use an accumulator to keep a running total.
• Use selection with IF to include only values that meet a condition.
• In CIE pseudocode, always declare variables and use the assignment arrow ←.
• A test of Number > 0 correctly excludes both negative numbers and zero.

Common Mistakes

• Forgetting to initialise Sum: if Sum does not start at 0, the total will be wrong.
• Using Number >= 0 instead of Number > 0: this would wrongly include zero, but the question says zero is neither positive nor negative.
• Putting OUTPUT Sum inside the loop: this would output after every input, not once at the end.
• Using the wrong loop type badly: a WHILE loop could work, but if the counter is not updated correctly it may not run exactly 100 times.
• Not declaring variables: the question explicitly requires all variables to be declared.
• Using = for assignment: in CIE pseudocode, assignment must use ←, while = is for comparison.

Things to Be Careful About

• The loop must process exactly 100 values, no more and no fewer.
• Keep the IF statement inside the loop so each input is tested as it is entered.
• The variable types should be INTEGER, because the question specifies integer values.
• If you include a prompt, keep it simple; the exact wording of the message is usually not important.
• Make sure the structure is fully closed with ENDIF and NEXT Count.
• Match CIE pseudocode style: upper-case keywords, proper indentation, and the assignment arrow ←.

Background Concept

The three basic programming constructs are:

• sequence: instructions carried out in order
• selection: choosing between alternatives based on a condition
• iteration: repeating a set of instructions

Most algorithms use more than one of these. In exam questions, when you are asked to identify a construct, you should name one clearly and then explain exactly where it appears in the algorithm.

Understanding the Question

The question already tells you that sequence is one construct used. It asks for one other construct required by the algorithm and a description of how it is used.

This algorithm must handle 100 values, so some form of repetition is definitely needed. That makes iteration an easy and correct choice.

You could also choose selection, because the algorithm has to decide whether each number is positive before adding it. But only one construct is needed for the answer.

Approach

Choose the construct that is most obviously necessary from the description. Then describe its job in the context of the algorithm, not just as a definition.

A strong answer does two things:

1. names the construct correctly
2. explains how the construct is used in this specific algorithm

So instead of just writing "iteration repeats instructions", it is better to say that a count-controlled loop repeats the input and processing for all 100 integers.

Step-by-Step Reasoning

Why is iteration required?

• The algorithm does not input just one number.
• It must input a sequence of 100 numbers.
• That means the same actions must happen again and again:
  • input a value
  • test whether it is positive
  • add it if appropriate

Because the number of repetitions is known in advance, the most suitable form is a count-controlled loop.

A good description therefore links iteration directly to the 100 repeated inputs. That is why the answer says a loop repeats the input and processing until all 100 integers have been entered.

If a student chose selection instead, a correct explanation would be that an IF statement is used to test whether the input is greater than zero before adding it to the total.

Key Takeaways

• Be able to recognise sequence, selection and iteration in an algorithm description.
• When asked to describe use, explain the construct in context.
• Fixed repetition usually suggests iteration with a count-controlled loop.

Common Mistakes

• Naming sequence again: the question asks for one other construct, so sequence would not gain credit.
• Giving only a definition: for example, writing just "iteration means repetition" is too vague.
• Not linking the construct to this algorithm: the answer must mention the 100 values or the repeated processing.
• Choosing a construct that is not basic: only sequence, selection and iteration are the standard basic constructs here.

Things to Be Careful About

• Read the wording carefully: "identify" plus "describe how it is used" means two parts are needed.
• If you choose iteration, mention that it repeats the steps for 100 values.
• If you choose selection, mention that it checks whether the number is positive before adding it.
• Keep the answer specific and brief; one precise construct and one precise use is enough.

Background Concept

A flowchart is a visual way to represent an algorithm. Different shapes have standard meanings:

• start/end terminal for beginning or stopping
• process box for an action such as assignment
• decision diamond for a true/false test
• arrows for control flow

This question uses a linked-list initialisation routine. Because the list is stored in an array, each node's Pointer field must hold the index of the next node. To create a simple free list or sequential chain:

• node 1 points to 2
• node 2 points to 3
• and so on
• node 200 points to 0 because it is the last one

That means the algorithm needs repetition, so a loop is required.

Understanding the Question

You are told to initialise the whole List array so that each node points to the following node, and the last node contains the null pointer.

So the flowchart must show:

1. start with the first index
2. repeatedly assign each node's Pointer to the next index
3. stop when the final node is reached
4. assign 0 to the final node's pointer

The mark scheme shows that the expected flowchart is a loop built around the test Index = 200 ?.

Approach

Use a control variable, Index, starting at 1.

At each stage, check whether Index is the last valid position.

• If it is not the last position, set List[Index].Pointer to Index + 1, then increase Index.
• If it is the last position, set List[Index].Pointer to 0 and finish.

This works because every node before the end should point forward by one place, while the final node must point nowhere.

Step-by-Step Reasoning

First, the flowchart needs a process box to initialise the control variable:

• SET Index TO 1

Then it needs a decision diamond asking whether the final node has been reached:

• IS Index = 200 ?

If the answer is NO:

• assign the pointer of the current node to the next index: SET List[Index].Pointer TO Index + 1
• then move to the next node position: SET Index TO Index + 1
• then loop back to the decision diamond

If the answer is YES:

• this means the current node is the last one in the array
• so it cannot point to 201
• instead, set List[Index].Pointer TO 0
• then end the algorithm

This is the complete loop structure needed.

Key Takeaways

• A flowchart for repetition needs initialisation, a decision, loop actions and a return path.
• In an array-based linked list, a node's pointer often stores the next index.
• The final node must store the null pointer instead of pointing past the array.

Common Mistakes

• Setting every node, including node 200, to point to Index + 1. That would try to create a pointer value of 201, which is invalid.
• Forgetting to initialise Index to 1. Without that, the loop has no correct starting point.
• Incrementing Index before storing the pointer, which would make the pointer assignments wrong.
• Using the wrong test, such as Index > 200, which changes when the last pointer gets assigned.

Things to Be Careful About

• The array bounds are 1 to 200, so 200 is a real node and must still be processed.
• The test must allow the last node to be set to 0 before ending.
• Make sure the NO branch loops back to the decision, not to the start terminal.
• In a drawn flowchart, decision branches should be clearly labelled YES and NO.

Background Concept

To output the contents of a linked list in the correct order, you do not scan the whole array from 1 to 200. That would only give array order, not linked-list order.

Instead, you traverse the list. Traversal means:

• begin at the first node, found using HeadPointer
• process that node
• follow its pointer to the next node
• keep going until a null pointer is reached

In an array-based linked list, the Pointer field stores the index of the next node. The null pointer value 0 means there is no next node, so the traversal must stop there.

Understanding the Question

The question says an algorithm must output the Data field from all nodes in List, but in the same order as the linked list stores them.

That wording is crucial. The list order is determined by following pointers, not by the physical positions of nodes in the array.

It also says not to use pseudocode statements. So your answer should be written as plain English steps, not lines such as WHILE or OUTPUT written in formal pseudocode style.

Approach

Think of the list as a chain.

First, find the start of the chain using HeadPointer.
Then, at each node:

• read and output the data
• move to the next node by following the pointer
  Continue until the pointer says there is no next node.

To turn that into four steps, separate the ideas into start, output, move, repeat/stop.

Step-by-Step Reasoning

Step 1 must identify where traversal begins. In a linked list, you cannot assume the first item is at List[1]. The correct starting place is the value stored in HeadPointer. So a current pointer variable is set to HeadPointer.

Step 2 is to process the current node. The task specifically asks to output the Data field, so you output the data stored in the node whose index is the current pointer.

Step 3 is to move through the list. You do that by taking the Pointer field from the current node and making that the new current pointer.

Step 4 is the repetition rule. If the current pointer is not 0, there is another node to visit, so you go back and output again. When the current pointer becomes 0, that means the end of the list has been reached, so the algorithm stops.

This gives the correct linked-list order because each node tells you which node comes next.

Key Takeaways

• Traversing a linked list means following pointers, not scanning array positions.
• HeadPointer gives the first node.
• The null pointer marks the end of the list.
• When asked for structured steps rather than pseudocode, explain the same logic in plain language.

Common Mistakes

• Saying to output List[1], List[2], List[3] and so on. That ignores the linked structure and may give the wrong order.
• Forgetting to start from HeadPointer. Without that, you may not begin at the first node in the list.
• Forgetting the stopping condition. A traversal must stop when the pointer becomes 0.
• Writing formal pseudocode keywords such as WHILE or OUTPUT when the question explicitly says not to use pseudocode statements.

Things to Be Careful About

• Distinguish between array order and linked-list order.
• Make sure the movement step uses the current node's Pointer field, not simply current pointer + 1.
• Mention the null pointer clearly, because that is what controls termination.
• Since the question asks for four steps, keep the answer neatly separated into four ordered actions.

Background Concept

This question is about processing values stored in a 1D array and using selection inside a loop. A 1D array stores a list of related items, and each item is accessed by its index. Here, the array GB stores the five grade boundaries.

To decide whether a mark is within 2 marks of a boundary, we form an inclusive range around each boundary:

• boundary - 2
• boundary + 2

A value is inside that range if it is greater than or equal to the lower limit and less than or equal to the upper limit. In pseudocode, that is tested using AND.

Understanding the Question

You are given an incomplete loop that checks each grade boundary in turn. The missing parts are:

• how many array elements must be processed
• how to calculate the upper limit
• how to write the comparison in the IF statement

Because there are five grade boundaries, the algorithm must examine all five elements of GB.

Approach

The method is:

1. Loop through each element of GB.
2. For each boundary, calculate the lower and upper permitted values.
3. Compare Mark with those two limits.
4. If Mark lies between them, output the message.

This is a standard array-processing pattern: traverse the array, derive values from each element, then test a condition.

Step-by-Step Reasoning

The array has five entries, so the loop must run from index 1 to index 5:

FOR Index ← 1 TO 5

The lower limit is already given as 2 less than the boundary:

Lower ← GB[Index] - 2

The upper limit must therefore be 2 more than the boundary:

Upper ← GB[Index] + 2

Now we test whether Mark is within the range. Because marks exactly 2 away still count, the comparison must be inclusive:

IF Mark >= Lower AND Mark <= Upper THEN

If the condition is true, the required output is produced:

OUTPUT "Check this paper"

Then the loop continues to the next boundary:

NEXT Index

So the completed pseudocode checks every grade boundary and outputs the message whenever the mark falls in one of those 5-mark windows.

Key Takeaways

• Use a FOR loop to process every element in a fixed-size array.
• To test whether a value is within a range, use two comparisons joined by AND.
• Inclusive boundaries require >= and <=, not > and <.

Common Mistakes

• Using the wrong loop limit, such as 4 or 75, instead of the five elements in GB.
• Writing Upper ← GB[Index] - 2 instead of + 2.
• Using OR instead of AND, which would make the condition true for almost every mark.
• Using strict comparisons such as > and <, which would wrongly exclude marks exactly 2 away from the boundary.

Things to Be Careful About

• The array indices in the question start at 1, not 0.
• The phrase "within 2 marks" includes the boundary itself and marks exactly 2 away.
• In CIE pseudocode, assignment must use ←, while comparison uses = or relational operators such as >= and <=.
• Complete only the missing logic asked for; there is no need to add extra variables or control structures here.

Background Concept

The program development life cycle breaks software creation into stages so that the work is organised and controlled. In Cambridge 9618, the key stages commonly used are:

• Analysis: finding out what the problem is and what the user needs.
• Design: planning the solution, including program structure, modules, algorithms, data structures and interfaces.
• Implementation: writing the actual program code.
• Testing: checking that the program works correctly and finding errors.
• Maintenance: changing the program after release, for example to fix faults or improve features.

Questions like this test whether you can recognise the stage from an activity rather than just memorise the stage names.

Understanding the Question

You are given four activities and must write the matching life cycle stage for each one.

The clue words are important:

• compiler suggests program code is being translated, so coding has already happened.
• released for general use means the system is already in use, so later changes belong to maintenance.
• dry run is a testing technique used to trace logic.
• program structure is specified means the solution is being planned, not yet coded.

So this is really a matching exercise between activities and stages.

Approach

For each activity:

1. Decide whether it belongs to planning, coding, checking, or changing after release.
2. Match that idea to the formal life cycle stage name.
3. Use the standard stage labels expected in the syllabus: Design, Implementation, Testing, Maintenance.

Step-by-Step Reasoning

1. A compiler is used.

   • A compiler translates source code into machine code or object code.
   • That means the program has been written and is in the coding stage.
   • So the correct stage is Implementation.

2. A program that has been released for general use is modified.

   • Once software has been released, later corrections or improvements are no longer part of initial development.
   • These changes are part of looking after the software after delivery.
   • So the correct stage is Maintenance.

3. The dry run method is used.

   • A dry run means tracing through an algorithm or program step by step using test data.
   • This is done to check correctness and find logic errors.
   • So the correct stage is Testing.

4. The program structure is specified.

   • Deciding modules, structure, and how the solution will be organised happens before coding.
   • This is part of planning the solution.
   • So the correct stage is Design.

Key Takeaways

• Be able to identify life cycle stages from activities, not just definitions.
• Design is about planning the structure and algorithms.
• Implementation is writing the code.
• Testing is checking the program with methods such as dry runs.
• Maintenance is changing software after release.

Common Mistakes

• Writing analysis for “program structure is specified”. Analysis is about requirements; structure belongs to design.
• Writing implementation for “dry run”. A dry run checks logic, so it is testing.
• Writing testing for “a compiler is used”. Compilation happens while implementing code, not as a test method itself.
• Confusing maintenance with further implementation. Once the software is already released, changes are maintenance.

Things to Be Careful About

• Use the stage name, not a description of the activity.
• Keep the answers in the same order as the rows in the table.
• Do not overcomplicate the wording; standard single-word stage names are what examiners expect.
• If your course materials use slightly different stage labels, choose the conventional 9618 wording that best fits the activity.

Background Concept

During testing, a program is often built from modules. Sometimes not all modules are ready, or some modules contain errors. To keep testing moving, developers can use test support code.

Two important terms are:

• Stub: a temporary module that stands in for a called module. It is used when the higher-level program or calling module needs to be tested, but the lower-level called module is missing or faulty.
• Driver: a temporary module that calls another module. It is used when the module being tested does not yet have its normal calling program.

So the distinction is:

• If the missing/faulty code is called by the part you want to test, use a stub.
• If the missing/faulty code would normally call the part you want to test, use a driver.

Understanding the Question

The question says:

• Test_A() and Test_B() have been written but contain errors.
• They are called from several places in the main program.
• Testing of the main program has to continue.

That means the main program depends on these modules. Since the main program is the part we want to continue testing, and the faulty modules are below it, we need a way to replace those called modules temporarily.

That points directly to stubs.

Approach

The correct method is chosen by looking at the direction of the call.

1. Identify whether the missing/faulty module is the caller or the called module.
2. Since Test_A() and Test_B() are called by the main program, they should be replaced by temporary stand-ins.
3. These stand-ins must look enough like the real modules for the main program to run.
4. They can return fixed values, sample outputs, or do minimal processing so integration testing of the main program can continue.

Step-by-Step Reasoning

• The main program is already written to call Test_A() and Test_B().
• Because those modules have errors, using the real versions would stop or disrupt integration testing.
• To avoid this, the developer writes stub versions of those modules.
• Each stub should:
  • have the same name or be used in place of the original module,
  • accept the same parameters if needed,
  • return a sensible dummy value or produce simple placeholder behaviour.
• When the main program calls the stub, the call still succeeds.
• This lets the developer test:
  • whether the main program makes the calls correctly,
  • whether data is passed correctly,
  • whether the rest of the integration works.
• Later, when the real Test_A() and Test_B() modules are fixed, the stubs are removed and the real modules are used instead.

A short description that would score well is therefore: use stubs, meaning temporary dummy versions of the faulty called modules, with matching parameters, that return preset values so the main program can still be tested.

Key Takeaways

• Use a stub when a called module is unavailable or faulty.
• Use a driver when the calling module is unavailable.
• In integration testing, temporary replacement code helps progress continue even when some modules are not ready.
• Good answers must name the method and explain how it works in the context given.

Common Mistakes

• Writing driver instead of stub. A driver calls a module under test; here the problem modules are themselves being called by the main program.
• Saying only “use dummy data” without naming the method. The mark scheme usually expects the testing method to be identified explicitly.
• Giving a vague description like “ignore those modules”. The main program still needs something to call, so the replacement must act like the module interface.
• Describing full correction of the faulty modules. The question asks how testing can continue before those errors are fixed.

Things to Be Careful About

• Read the direction of the call carefully: the phrase called from the main program is the key clue.
• The stub should match the real module's expected interface closely enough for integration testing to proceed.
• The stub does not need the full real logic; simple preset values or placeholder output are enough.
• Do not confuse this with unit testing terminology alone; the question is specifically about allowing integration testing of the main program to continue.

Background Concept

The program development life cycle breaks software creation into stages so that the problem is understood before a solution is built. One important early stage is analysis. In analysis, the developer finds out exactly what the user or client needs the system to do.

Typical analysis activities include meeting the client, asking questions, identifying inputs, outputs and processing, and clarifying constraints or special rules. A common document produced at this stage is a requirements specification. This records what the finished system must do.

Understanding the Question

The question says that a programmer discusses the details of the loyalty card system with the shop owner. That tells us the programmer is still finding out the user's needs rather than coding or testing.

So the task is to name:

• the stage of the program development life cycle this belongs to
• one document created during that stage

The key clue is the word discussion with the owner. That points to gathering requirements.

Approach

First identify what kind of activity is happening. If the programmer is talking to the user to understand the problem, that is analysis.

Then think of a document created during analysis. The best standard answer is requirements specification, because it records the user's needs clearly and is the normal output of this stage.

Step-by-Step Reasoning

The scenario is not about writing algorithms, drawing flowcharts, coding or testing. It is about understanding the system that the coffee shop wants.

That means the stage is analysis.

During analysis, the programmer would produce a document describing what the system must do. A suitable document is the requirements specification.

So the complete answer is:

• Stage: Analysis
• Document: Requirements specification

Key Takeaways

• Client discussions to find out system needs belong to the analysis stage.
• A requirements specification is a standard document produced during analysis.
• In life cycle questions, match the activity in the scenario to the stage name.

Common Mistakes

• Giving design instead of analysis. Design happens after the requirements have been gathered.
• Naming a testing document, such as a test plan. That belongs later in development.
• Giving a vague document name such as notes without linking it to a recognised life cycle document.

Things to Be Careful About

Be careful to choose the stage that matches the evidence in the question. A discussion with the owner is about discovering requirements, not building the program. Also make sure the document named is one that would reasonably be produced during that same stage, such as a requirements specification.

Background Concept

Decomposition means breaking a large problem into smaller sub-problems, often called modules or sub-modules. Each sub-module should do one clear job. This makes the system easier to design, code, test and maintain.

In program design, a good decomposition often separates:

• input tasks
• processing tasks
• storage or update tasks
• output tasks

A module should be focused and purposeful. For example, one module might read data, another might calculate a value, and another might update stored data.

Understanding the Question

The overall task is a loyalty card system used when a customer makes a purchase. From the description, the system must:

• scan the bar code on the card
• identify the customer
• calculate points
• add points to the customer's total
• possibly exchange points for a discount on the next purchase

The question asks for four sub-modules that could be used when designing this new module, and a description of what each one does.

So you are not writing code here. You are showing sensible decomposition of the system into smaller units.

Approach

Look at the full process in the order it would happen during a transaction.

A good way to decompose it is:

1. get the customer ID from the card
2. get the customer's existing data
3. calculate points for the purchase
4. deal with redemption and update the stored total

These choices are strong because each sub-module has one main responsibility, and together they cover the whole loyalty-card process.

Step-by-Step Reasoning

Start with the first action in the scenario: the card is presented and scanned. That naturally suggests a sub-module such as scan bar code. Its job is simply to read the customer ID.

Next, once the ID is known, the system needs the customer's current information. That gives a retrieve customer record sub-module. It would look up the customer using the ID and obtain the current points total.

Then the system must award points for the current purchase. That suggests a calculate points earned sub-module. Its role is to take the purchase amount or transaction details and work out how many points should be added.

Finally, the question mentions that on a later purchase the customer may exchange points for a discount. That means there needs to be logic for checking whether points are being redeemed, reducing the total if necessary, adding any newly earned points, and saving the revised total. That can be described as a redeem points and update record sub-module.

Other valid decompositions could also earn credit, for example a separate discount calculation module or a separate output module to display the new balance. The important point is that the sub-modules must be sensible and their uses must match the system description.

Key Takeaways

• Decomposition breaks a larger system into manageable sub-modules.
• Good sub-modules each have one clear purpose.
• A realistic transaction system can often be divided into input, lookup, calculation and update stages.
• In design questions, clear module names plus a clear use statement are usually enough.

Common Mistakes

• Giving four steps that are too vague, such as process data or handle system, without saying what each one does.
• Repeating the same idea in different words, for example calculate points and work out points, which do not really form separate sub-modules.
• Naming a sub-module without describing its use.
• Describing whole-system behaviour instead of one specific module's role.

Things to Be Careful About

Make sure each sub-module is distinct. The examiner is looking for separate parts of the design, not one long description split across four lines. Also keep the uses tied closely to the loyalty-card scenario: customer ID, points total, discount redemption and record updating are the key elements given in the question.

Background Concept

A record lets one item store several related fields together. Here, each element of the Character array is a CharacterType record containing Player, Role, Name and SkillLevel. To answer a query such as "how many Teachers does player 3 have?", the standard pattern is:

1. initialise variables for the result
2. loop through every array element
3. test whether the current record matches the required conditions
4. if it matches, update the result variables
5. after the loop, output a message based on whether anything was found

This is a common searching-and-counting task. It is not just finding one match; it must examine all 45 records because several characters may match the same player and role.

Understanding the Question

You are given a global array:

• Character[1:45]
• each element is a record
• the procedure Count() receives two inputs:
  • ThisPlayer as an integer
  • ThisRole as a string

The procedure must search the whole array and find records where both of these are true:

• Player = ThisPlayer
• Role = ThisRole

For those matching records, it must:

• count how many there are
• add together their SkillLevel values

Then it must output one of two messages:

• the full summary message if at least one match exists
• the "No characters..." message if none exist

The key clue is that the module description says it "counts" and "sums", so you need accumulator variables, not just a simple found flag.

Approach

Use a count-controlled loop from 1 to 45 because the array bounds are fixed and known.

Inside the loop:

• inspect Character[Index]
• check both the player and the role
• if both match, increase the count by 1 and add that record's SkillLevel to the total

After the loop:

• if the count is greater than 0, output the detailed sentence
• otherwise output the "No characters..." message

This is better than outputting during the loop, because the question wants one final result after the search is complete.

Step-by-Step Reasoning

PROCEDURE Count(ThisPlayer : INTEGER, ThisRole : STRING)

• This defines the module with the two required parameters.
• ThisPlayer is the player number being searched for.
• ThisRole is the role being searched for.

DECLARE Index, NumCharacters, TotalSkill : INTEGER

• Index is the loop counter.
• NumCharacters stores how many matches have been found.
• TotalSkill stores the running total of matching skill levels.

NumCharacters ← 0

• Before searching, no matching characters have been found yet.

TotalSkill ← 0

• Before searching, the total of skill levels must start at 0.

FOR Index ← 1 TO 45

• The array was declared as ARRAY[1:45], so the correct bounds are 1 to 45.
• Every record must be checked because matches could appear anywhere.

IF Character[Index].Player = ThisPlayer AND Character[Index].Role = ThisRole THEN

• This is the key condition.
• Both conditions must be true at the same time.
• If only one is true, it is not a valid match.

NumCharacters ← NumCharacters + 1

• Each time a valid match is found, increase the count.

TotalSkill ← TotalSkill + Character[Index].SkillLevel

• Add that matching character's skill level to the running total.

After the loop finishes, all records have been checked.

IF NumCharacters > 0 THEN

• If at least one matching record was found, output the detailed message.

OUTPUT "Player ", ThisPlayer, ...

• The output includes the player number, the count, the role, and the total skill level.

ELSE

• If NumCharacters is still 0, no matching records were found.

OUTPUT "No characters with that role are assigned to this player"

• This matches the required alternative output.

This structure guarantees exactly one output message, and it is based on the final result of the search.

Key Takeaways

• When a question asks for both a count and a total, use two accumulator variables.
• When searching an array of records, access the correct field using dot notation such as Character[Index].Role.
• If there may be multiple matches, you must search the entire array, not stop after the first one.
• A final IF/ELSE after the loop is a standard way to choose between "found" and "not found" output.

Common Mistakes

• Forgetting to initialise NumCharacters or TotalSkill to 0. This gives incorrect results.
• Checking only Role or only Player instead of both. The question requires both conditions.
• Putting the output statement inside the loop. That would produce repeated output instead of one final summary.
• Using Character[Index].Name by mistake. The search is by role, not by name.
• Writing NumCharacters = 0 for assignment. In CIE pseudocode, assignment must use ←.

Things to Be Careful About

• The array is 1-indexed, not 0-indexed, because it is declared as ARRAY[1:45].
• Role is a string, so compare it with ThisRole; SkillLevel is the integer that must be added.
• The Player field can be 0 for unassigned characters, but those only count if ThisPlayer is also 0. The question context suggests real players are 1 to 6, so the normal use is searching assigned players.
• The required message says "if characters with the given role are found". That means you decide after the full search, not record by record.
• Keep the parameter names and field names exactly correct so the pseudocode is clear and consistent.

Background Concept

Restoring data from a text file means rebuilding the program's in-memory data structures from values stored on secondary storage. This is important because variables and arrays in memory are lost when a program closes, but a file remains available for later use.

Here, each line of the file represents one record. So the restore process is:

1. open the file for reading
2. read a line
3. split the line into its fields
4. convert each field to the correct data type
5. store the values into the correct array element
6. repeat until all records are restored
7. close the file

The question says the helper function Extract() already exists. That means you should not write your own parsing logic. You simply call Extract(Line, FieldNumber) to get the required field as a string.

Understanding the Question

The Character array has 45 elements, and each line of SaveFile.txt contains one complete record for one array element.

Each record has four fields:

1. Player as an integer
2. Role as a string
3. Name as a string
4. SkillLevel as an integer

The task is to write Restore() so that it reads the file and rebuilds the Character array. The important instruction is: "You must use the module Extract()". So the mark-worthy method is to read the whole line first, then call Extract() four times for field numbers 1 to 4.

Also notice that Extract() returns a string, so numeric fields must be converted using STR_TO_NUM() before storing them in integer fields.

Approach

Because the file contains one line for each of the 45 array elements, a simple count-controlled loop from 1 to 45 is a neat solution.

For each loop iteration:

• read one line from the file into a string variable
• extract field 1 and convert it to an integer for Player
• extract field 2 and store it directly as Role
• extract field 3 and store it directly as Name
• extract field 4 and convert it to an integer for SkillLevel

Finally, close the file.

This approach matches the record structure exactly and guarantees that file line 1 goes into Character[1], line 2 into Character[2], and so on.

Step-by-Step Reasoning

PROCEDURE Restore()

• This defines the new module.
• It takes no parameters because it always restores the same global array from the same file.

DECLARE Line : STRING

• This variable stores one whole line from the file.
• You need this because Extract() works on a complete line.

DECLARE Index : INTEGER

• This is used to step through the array positions from 1 to 45.

OPENFILE "SaveFile.txt" FOR READ

• The file must be opened before any attempt to read from it.
• FOR READ is correct because the task is to load existing data, not to write new data.

FOR Index ← 1 TO 45

• There are 45 characters in the array.
• The array declaration is ARRAY[1:45], so these are the correct bounds.

READFILE "SaveFile.txt", Line

• This reads the next full record from the file into Line.

Character[Index].Player ← STR_TO_NUM(Extract(Line, 1))

• Field 1 is Player.
• Extract() returns text, but Player is an integer field, so conversion is required.

Character[Index].Role ← Extract(Line, 2)

• Field 2 is Role.
• Role is a string, so no conversion is needed.

Character[Index].Name ← Extract(Line, 3)

• Field 3 is Name.
• Again, this is already a string.

Character[Index].SkillLevel ← STR_TO_NUM(Extract(Line, 4))

• Field 4 is SkillLevel.
• This must be converted from string to integer before storage.

NEXT Index

• This repeats the same process for all 45 records.

CLOSEFILE "SaveFile.txt"

• The file should be closed once reading is complete.
• This is good practice and is usually expected in file-handling questions.

ENDPROCEDURE

• This ends the module.

A WHILE NOT EOF(...) approach could also work in principle, but with a fixed 45-element array and one line per record, the FOR loop is simple and directly matches the data structure.

Key Takeaways

• A restore routine rebuilds RAM data structures from persistent file storage.
• When a helper function is provided, use it rather than inventing a different parsing method.
• Always convert extracted strings to integers before storing them in integer fields.
• A count-controlled loop is appropriate when the number of records is known in advance.
• Open files before reading and close them afterwards.

Common Mistakes

• Forgetting to use Extract(), even though the question explicitly requires it.
• Storing Extract(Line, 1) or Extract(Line, 4) directly into integer fields without STR_TO_NUM().
• Mixing up the field numbers, for example placing field 3 into Role or field 2 into Name.
• Using the wrong array bounds, such as 0 to 44 instead of 1 to 45.
• Forgetting to close the file.
• Reading the file outside the loop only once, which would restore only one record.

Things to Be Careful About

• Extract() returns strings for every field, even when the actual record field should be an integer.
• The array element and the file line should stay aligned: first line to Character[1], second line to Character[2], and so on.
• Use the exact field order given in the question:
  1. Player
  2. Role
  3. Name
  4. SkillLevel
• The question says each line contains one element of the array, so one READFILE happens for each loop cycle.
• In CIE pseudocode, keep keywords in upper case and use ← for assignment, not =.

Background Concept

Data held in variables and arrays during program execution is stored in main memory. Main memory is temporary, so when the program closes or the computer is turned off, that data is lost. A text file stored on secondary storage is persistent, which means the data remains available after the program ends.

In games, this is the basis of a save-and-restore system. The program writes the current state to a file, and later reads it back so the user can continue from the same point.

Understanding the Question

The question says the game may last several days, and users may need to close and rerun the program many times. That means the current state of the game must survive between program runs.

The file SaveFile.txt stores the Character array data. So the benefit being asked for is not just "files store data" in general; it is specifically that the game state can be saved and later restored.

Approach

A good answer needs the benefit in the game context:

• data is kept after the program closes
• users can reopen the game and continue without starting again or typing everything again

Those two linked ideas are usually enough for full credit in a short explain question.

Step-by-Step Reasoning

When the program is closed, the array in memory disappears. Without a save file:

• all player assignments would be lost
• all roles, names and skill data loaded during the game would need to be recreated
• the users could not easily continue a long game

By storing the data in SaveFile.txt:

• the current character information is kept on secondary storage
• the Restore() module can rebuild the array next time the game starts
• the players can continue from where they stopped
• this avoids re-entering or recreating the game state

So the real benefit is continuity of progress across multiple sessions.

Key Takeaways

• Main memory is temporary; files provide permanent storage.
• A save file lets a long-running task or game continue over multiple sessions.
• "Restore" works only because the data was first stored persistently.

Common Mistakes

• Saying only "it stores data" without explaining why that matters in this game.
• Claiming it makes the game faster, which is not the main benefit described here.
• Confusing saving to a file with keeping data in RAM; RAM contents are lost when the program closes.

Things to Be Careful About

• The answer should be about persistence between separate runs of the program.
• Mention the user benefit clearly: progress is not lost and the game can continue later.
• Keep the explanation tied to the scenario of a multi-day game, not just a vague statement about files.