Computer Science 9618/22 — October/November 2024

Background Concept

The program development life cycle describes the stages a program goes through, from the initial idea to use and later changes. Typical stages include analysis, design, coding, testing, implementation and maintenance.

Once a program has been released for general use, any later changes are usually part of the maintenance stage. Maintenance includes correcting faults, adapting the program to new requirements, or improving its performance.

A detected error after release is normally dealt with by corrective maintenance, but if the question asks for the life cycle stage, the expected stage name is usually just maintenance.

Understanding the Question

The key clue is that the program has already been developed, released and used for a few months. That means the program is no longer in analysis, design, coding or testing as its main stage.

Now an error has been found and needs correcting. The question asks for the stage of the program development life cycle where this correction happens.

Approach

Use the timeline in the question:

1. The program was developed.
2. It was released.
3. It has been in use for months.
4. A fault is now discovered.

Any correction at that point belongs to maintenance.

Step-by-Step Reasoning

Because the software is already in general use, the main development stages have already happened.

The fault is being found after release, not during initial testing before release.

Therefore the correction is carried out during the maintenance stage.

If a student knows the more specific term corrective maintenance, that explains the kind of maintenance, but the life cycle stage itself is maintenance.

Key Takeaways

• Errors found after release are handled in the maintenance stage.
• Maintenance happens after implementation and use.
• Corrective maintenance is the type used to fix faults.

Common Mistakes

• Writing testing: testing usually happens before release as part of development, whereas this question says the software has already been released and used.
• Writing coding: coding is the act of writing the original program, not the life cycle stage for post-release correction.
• Giving only corrective without recognising maintenance: corrective is a maintenance type, not usually the named stage itself.

Things to Be Careful About

• Read the timeline carefully. “Released for general use” is the strongest clue.
• If the question asks for the stage, give maintenance. If it asked for the type of maintenance, then corrective maintenance would be the more exact answer.

Background Concept

An IDE provides debugging tools to help a programmer find logic errors and run-time problems. Three common debugging features are breakpoints, single stepping and watch windows.

A breakpoint is a marker placed on a line of code. When the program reaches that line during execution, it pauses automatically.

Single stepping means executing the program one statement at a time. This lets the programmer see exactly what each line does.

A watch window displays the current values of selected variables or expressions while the program is paused or being stepped through. This is useful for spotting where data becomes wrong.

These tools are especially useful for logic errors, where the program runs but sometimes gives the wrong result.

Understanding the Question

The question already tells us that the incorrect result comes from the function Lookup(). So the aim is not to search the whole program randomly, but to focus on that function.

It also asks for the features and the order they will be used in. That means a good answer must do more than define the features separately. It should describe a sensible debugging sequence.

Approach

The sensible order is:

1. Put a breakpoint in Lookup() so execution stops there.
2. Run the program until that breakpoint is reached.
3. Step through the code line by line using single stepping.
4. Watch the important variables in the watch window to see when one changes incorrectly or when the returned value becomes wrong.

This order is logical because you first get to the suspicious location, then inspect it closely.

Step-by-Step Reasoning

First, the programmer places a breakpoint in Lookup(), usually at the start of the function or just before the suspected section. A breakpoint avoids having to manually trace all earlier code.

Next, the program is run with the usual test data that causes the error. When execution reaches the breakpoint, the IDE pauses the program automatically.

Now the programmer uses single stepping. Each click or command executes one line only, so the programmer can follow the path taken through Lookup().

At the same time, the watch window is used to track the values of variables involved in the lookup process, and possibly the function result as well. As each line runs, the programmer observes whether:

• a variable gets an unexpected value,
• a condition goes the wrong way,
• the wrong array element or item is used,
• or the function is about to return the wrong value.

The line after which the watched value becomes wrong is usually where the bug is, or very near it.

That is why the tools work together: the breakpoint gets you to the right place, single stepping reveals the control flow, and the watch window reveals the data values.

Key Takeaways

• Breakpoints pause execution at a chosen line.
• Single stepping lets you follow the program one statement at a time.
• Watch windows let you observe variable values during debugging.
• For a known faulty function, use these tools together in a clear sequence.

Common Mistakes

• Describing the features but not giving the order: the question specifically asks for the order of use.
• Saying the watch window changes variables: it does not change them; it displays their values.
• Confusing a breakpoint with single stepping: a breakpoint pauses at a chosen location, while single stepping executes one line at a time.
• Talking about syntax errors: syntax errors are usually found before the program can run, but this question is about a function that sometimes returns an incorrect value, which suggests a logic error.

Things to Be Careful About

• The answer should refer specifically to Lookup() because the question identifies that function as the source of the problem.
• Do not imply that the breakpoint is used after stepping. Normally it is set first so execution stops in the right place.
• Mention watched variables or expressions, not just “the code”, because the watch window is about values.
• The word “sometimes” suggests the programmer should run the program using data that reproduces the fault.

Background Concept

An IDE does more than debug programs. It also provides tools that help during coding, making it faster and reducing mistakes.

Coding support features typically include syntax highlighting, auto-completion, automatic indentation, bracket matching, code formatting and syntax error indication.

Syntax highlighting displays different parts of the code in different colours or styles, for example keywords, identifiers and strings. This makes the program easier to read and helps the programmer notice mistakes.

Code completion, also called auto-complete, suggests or fills in keywords, procedure names, variable names or method names as the programmer types. This speeds up coding and reduces typing errors.

Understanding the Question

The question says the new module has already been designed and is now being coded. So it is not asking about design tools or debugging tools for finding the existing fault. It is asking for features that help while writing the new code.

Because it says “identify two features”, brief feature names are enough.

Approach

Choose two standard IDE features that directly support entering code correctly and efficiently.

Good answers are features such as:

• syntax highlighting,
• code completion / auto-complete,
• automatic indentation,
• bracket matching,
• syntax error alerts.

Any two valid features would usually gain the marks.

Step-by-Step Reasoning

A strong pair of answers is:

1. Syntax highlighting.
   This helps by showing keywords, strings and identifiers clearly, making the code easier to read and making mistakes more visible.

2. Code completion / auto-complete.
   This helps by suggesting or completing keywords and identifier names, saving time and reducing spelling mistakes in names.

These are clearly coding aids rather than testing or maintenance activities.

Key Takeaways

• IDEs support both coding and debugging.
• Syntax highlighting improves readability and helps spot errors.
• Code completion speeds up typing and reduces identifier mistakes.

Common Mistakes

• Repeating breakpoint, watch window or single stepping from part (b): those are debugging features, but this part focuses on coding the new module.
• Giving vague answers such as “it helps you code faster” without naming a feature.
• Naming non-IDE items such as “compiler” or “keyboard shortcuts” unless the question specifically accepts them as IDE features.

Things to Be Careful About

• The question asks for features, not explanations, so keep the solution concise.
• Choose features clearly associated with the IDE itself.
• Do not confuse general software development stages with specific IDE tools.

Background Concept

A data type tells the program what kind of value a variable stores and what operations are suitable for it. Choosing the right data type matters because it affects memory use, valid operations and the accuracy of results.

Common pseudocode data types at this level include:

• STRING for text,
• INTEGER for whole numbers,
• REAL for numbers that may include a fractional part,
• BOOLEAN for TRUE or FALSE values,
• CHAR for a single character.

An array index is normally an integer because positions in an array are counted in whole-number steps.

A division result may be fractional, so if the question says it is the result of dividing any two non-zero numbers, the safe type is REAL rather than INTEGER.

Understanding the Question

You are given three variables and a description of what each stores. You must match each one to the most suitable data type.

The descriptions are:

• Name: a customer name,
• Index: an array index,
• Result: the result of dividing any two non-zero numbers.

The task is about the meaning of the data, not about writing code.

Approach

For each variable, ask:

1. Is it text, a whole number, or a value that may be fractional?
2. What kind of operations will normally be performed on it?
3. What is the safest type that fits all valid values described?

Step-by-Step Reasoning

For Name, the stored value is a customer name. Names are text, possibly with multiple characters, so the correct type is STRING.

For Index, the stored value is an array index. Array positions are counted using whole numbers such as 0, 1, 2 or 1, 2, 3 depending on the language or pseudocode system. Therefore the correct type is INTEGER.

For Result, the stored value is the result of division of any two non-zero numbers. Division does not always give a whole number. For example, $5 \div 2 = 2.5$. Because the value may contain a decimal or fractional part, the correct type is REAL.

So the completed table is:

• Name → STRING
• Index → INTEGER
• Result → REAL

Key Takeaways

• Use STRING for text values.
• Use INTEGER for whole-number counters and indexes.
• Use REAL when a calculation may produce a fractional value.
• Always choose a type that can hold every valid value described.

Common Mistakes

• Writing CHAR for Name: a name is usually more than one character, so STRING is needed.
• Writing REAL for Index: array positions are whole numbers, not decimal values.
• Writing INTEGER for Result: division can produce values like 2.5, so integer is too restrictive.

Things to Be Careful About

• Focus on what the variable is used to store, not just the variable name.
• The phrase “any two non-zero numbers” matters because it includes divisions that do not divide exactly.
• Use the pseudocode type names expected by the syllabus, such as STRING, INTEGER and REAL.

Background Concept

A function is used when a section of code takes some input, processes it, and returns a value. In this question, the returned value is another string.

String manipulation means working with whole strings or parts of strings. Common built-in operations in CIE pseudocode include LENGTH() to find how many characters are in a string and RIGHT() to extract characters from the end of a string.

This task also uses iteration. A count-controlled loop is appropriate when you know exactly how many times something must happen. Here, the number of asterisks needed is the length of the card number minus 4, because the last four characters must remain visible.

Understanding the Question

The question gives a card number as a string and wants a function called Conceal() that returns a new string. Every character except the last four must be replaced by *.

So if the original string has length 10, the first 6 characters become * and the last 4 stay the same. If the length is 16, the first 12 become * and the last 4 stay the same.

The key clues are:

• it says function, so the routine must return a string
• card numbers are stored as strings, so string functions should be used
• all except the last four are replaced, so the loop should run LENGTH(CardNum) - 4 times

Approach

A simple way to solve this is:

1. Create an empty string to hold the result.
2. Add one * for every character except the final four.
3. Take the last four characters from the original string.
4. Join those last four characters onto the end of the asterisks.
5. Return the completed string.

This is better than replacing characters one by one across the whole string because the unchanged part is already available directly with RIGHT().

Step-by-Step Reasoning

The function header is written first:

• FUNCTION Conceal(CardNum : STRING) RETURNS STRING
• This shows the routine name, the parameter, and that the function returns a string.

Local variables are then declared:

• Concealed stores the new masked string.
• Count controls the loop.

Concealed ← ""

• The result string must start empty.
• If it is not initialised, concatenation later would be unreliable.

FOR Count ← 1 TO LENGTH(CardNum) - 4

• LENGTH(CardNum) gives the number of characters in the card number.
• Subtracting 4 gives the number of characters that must be hidden.
• For example, if the card number is length 13, the loop runs 9 times.

Concealed ← Concealed & "*"

• Each pass adds one asterisk to the result.
• After the loop finishes, Concealed contains exactly the correct number of * characters.

Concealed ← Concealed & RIGHT(CardNum, 4)

• RIGHT(CardNum, 4) extracts the last four characters unchanged.
• These are added to the end of the concealed prefix.

RETURN Concealed

• Because this is a function, the final string must be returned.

For example, with "1234567890":

• LENGTH(CardNum) - 4 = 6
• loop builds "******"
• RIGHT(CardNum, 4) gives "7890"
• result becomes "******7890"

Key Takeaways

• Use a function when a value needs to be returned.
• Use LENGTH() to determine how many iterations are needed for string processing.
• Use a count-controlled loop when the number of repetitions is known.
• Use RIGHT() to keep the final characters unchanged.
• Build result strings by initialising an empty string and concatenating to it.

Common Mistakes

• Returning nothing from the function: a function must return the concealed string.
• Looping to LENGTH(CardNum) instead of LENGTH(CardNum) - 4: this would hide the last four as well.
• Using LEFT(CardNum, 4) instead of RIGHT(CardNum, 4): this keeps the wrong part visible.
• Replacing the first four characters instead of all except the last four: the question is about the final four characters, not the first four.
• Forgetting to initialise Concealed: concatenation onto an undefined value is incorrect.

Things to Be Careful About

• Keep the identifier name consistent, for example CardNum throughout the function.
• Use the assignment arrow ←, not =.
• Write valid CIE pseudocode keywords in upper case: FUNCTION, DECLARE, FOR, NEXT, RETURN, ENDFUNCTION.
• The parameter is a string, even though it represents a numeric card number.
• The question says strings are between 10 and 20 characters long, so RIGHT(CardNum, 4) is always safe here.

Background Concept

A PUSH operation adds an item to the top of a stack. In an array-based stack, the implementation must do three main things:

1. check whether the stack is full
2. place the new value into the correct array position
3. update the control variables so the stack state remains correct

This question uses two control variables:

• SP points to the next available stack location
• OnStack stores how many items are currently on the stack

That means this design does not use SP as the position of the top value. After inserting into ThisStack[SP], the pointer must move on to the next free slot.

Because the array has 60 elements, the maximum number of values the stack can hold is 60. If there are already 60 items, a PUSH must fail.

Understanding the Question

You are given a partially completed pseudocode function Push(ThisValue : REAL) RETURNS BOOLEAN.

The function must:

• add ThisValue to the stack if there is room
• return a Boolean to show success or failure

The gaps correspond to:

• the test for a full stack
• the returned value if it is already full
• the statement that stores the new value
• the update to SP

The stem tells you exactly how to interpret SP, OnStack, and the array indexing, so the missing lines must match that representation.

Approach

Use the stack rules in order:

1. If the stack already contains 60 items, it is full, so return FALSE immediately.
2. Otherwise store the value in the next free slot, which is ThisStack[SP].
3. Move SP up by 1, because the next free slot is now the following array position.
4. Increase OnStack by 1.
5. Return TRUE to show the push worked.

This is a standard array-stack PUSH pattern.

Step-by-Step Reasoning

Start with the full-stack test.

The array has indices 1 to 60, so it can hold 60 values. OnStack tells us exactly how many values are currently stored.

• If OnStack = 60, the stack is full.
• In that case the function must not try to write into the array.
• So it should return FALSE immediately.

That gives:

IF OnStack = 60 THEN
    RETURN FALSE
ENDIF

Next, store the new value.

SP points to the next available stack location, so the new item goes into:

ThisStack[SP] ← ThisValue

Then update SP.

Because the current free slot has now been used, the next free location is one higher:

SP ← SP + 1

Then increase the count:

OnStack ← OnStack + 1

Finally, because the operation succeeded, return TRUE.

A useful check is to test the final slot.

Suppose before the push:

• SP = 60
• OnStack = 59

The stack is not full yet, so the push should be allowed.

The function does this:

• stores the value in ThisStack[60]
• sets SP to 61
• sets OnStack to 60
• returns TRUE

Now the stack is full. On the next call, OnStack = 60, so the function returns FALSE before trying to store anything. That confirms the logic is correct.

Key Takeaways

• In a stack implemented with an array, PUSH must check for overflow before storing.
• Always use the definition of the pointer given in the question; here SP means next free slot.
• After a successful push, both the pointer and the item count must be updated.
• Boolean return values are a common way to report whether an operation succeeded.

Common Mistakes

• Using IF SP = 60 THEN as the full test. That is wrong here because index 60 is still available for use.
• Writing to ThisStack[SP + 1]. Since SP already points to the next free location, that would skip a cell.
• Forgetting to increment SP after the store. Then the next push would overwrite the same value.
• Returning TRUE when the stack is full. That would report success even though no value was added.
• Using = instead of ← for assignment in CIE pseudocode.

Things to Be Careful About

• The array is 1-indexed, not 0-indexed.
• SP points to the next available slot, not the top item.
• The order matters: check full first, then store, then update SP, then update OnStack.
• A full-stack condition based on OnStack = 60 is clear and safe for this representation.
• Keep the function return type consistent: it must return Boolean values only.

Background Concept

A run-time error happens while the program is executing, not when it is being typed and not just because the logic is wrong. Typical run-time errors in pseudocode/programming questions include division by zero, array index out of bounds, and calling a function with an invalid argument.

In this function, the parameter Number is used in more than one way: it is used as a divisor in 100 / Number, and it is also used as an array index in Data[Number]. That means one bad input value can cause different failures in different statements.

Understanding the Question

The question gives the function Process(Number, Label) and asks for three statements from that code that could cause run-time errors. So the task is not to rewrite the function, but to inspect the existing statements and identify where execution could fail.

The important clues are:

• Number is a parameter, so invalid input values are possible.
• Data has 100 elements, so subscripts must stay within its valid range.
• RIGHT(Label, Count) is a function call, so its argument Count must also be valid.

Approach

Go through the executable statements one by one and ask: "Could this fail for some input while the program is running?" If yes, identify the statement and the exact reason.

A good way to do this is:

1. Check arithmetic operations.
2. Check array access.
3. Check built-in function calls.

Step-by-Step Reasoning

The first risky statement is:

Count ← INT(100 / Number)

Here, Number is the divisor. If Number = 0, the program attempts to divide by zero. Division by zero is a standard run-time error.

The second risky statement is:

Index ← Data[Number]

Data has 100 elements. If Number is less than the first valid index or greater than the last valid index, then Data[Number] refers to an array element that does not exist. That causes an out-of-bounds array access at run time.

The third risky statement is:

ReturnValue ← TO_UPPER(RIGHT(Label, Count))

The inner function RIGHT(Label, Count) must be given a valid number of characters to take from the right-hand end of the string. If Count is invalid, then the function call can fail. One clear example is when Count is negative. Since Count comes from INT(100 / Number), a negative value of Number could make Count negative.

TO_UPPER(...) itself is not the main problem here; the risk is the invalid argument being passed into RIGHT(...).

Key Takeaways

• Run-time errors happen during execution.
• Always check divisors for zero.
• Always check array indices stay within bounds.
• When a built-in function is called, its parameters must be valid.

Common Mistakes

• Saying a statement is a logic error instead of a run-time error. A logic error gives the wrong result; a run-time error causes execution failure.
• Naming the wrong statement, for example writing just CASE OF even though the real risk is elsewhere.
• Forgetting that Number is reused in different places, so one invalid value can cause multiple problems.
• Giving vague explanations such as "it may crash" without stating why, for example division by zero or invalid array index.

Things to Be Careful About

• Do not assume every invalid input causes the same error; different statements fail for different reasons.
• Be precise about the cause: "division by zero", "array index out of bounds", and "invalid parameter to RIGHT()" are the kinds of explanations examiners want.
• The exact lower bound of the array is not shown in the stem, so the safest wording is that Number must be within the valid range for Data.
• INT(...) is not itself the error; the dangerous part is the calculation or parameter value used inside or before it.

Background Concept

A program can appear to freeze when it gets stuck repeating the same instructions forever. This is usually caused by an infinite loop, which is a run-time problem involving an iteration construct.

Iteration constructs include FOR, WHILE and REPEAT ... UNTIL loops. They are meant to repeat until a condition changes, but if that condition never becomes false or never becomes true, the loop never ends.

Understanding the Question

The question asks for a particular type of programming construct that can cause a program to stop responding. The key phrase is "freezing", which strongly suggests that the program is still running but trapped in endless repetition.

So the required construct is a loop, and the explanation must say why that loop never terminates.

Approach

Identify the construct as iteration, then explain the specific reason: the stop condition is never satisfied. A strong answer also mentions that this often happens because the loop variable is not updated correctly.

Step-by-Step Reasoning

A loop repeats a block of statements.

For example, in a WHILE loop, the condition is checked before each repetition. If that condition always remains true, the loop body keeps running forever.

This can happen if:

• the loop control variable is never changed
• the wrong variable is changed
• the condition is written incorrectly

Because the loop never finishes, the rest of the program is never reached. To the user, this looks like the computer or the program has frozen.

Key Takeaways

• Freezing is commonly caused by an infinite loop.
• Infinite loops come from iteration constructs.
• Correct loop control depends on both a valid condition and correct updating of the control variable.

Common Mistakes

• Naming selection (IF) instead of iteration. Selection does not repeat by itself.
• Saying only "loop" without explaining why it freezes.
• Describing a syntax error instead of a run-time behaviour.

Things to Be Careful About

• The question asks for a construct and an explanation, so both parts are needed.
• "Infinite loop" is the effect; the construct is an iteration structure such as WHILE or REPEAT.
• Make sure the explanation refers to the terminating condition not being reached, not just "the program is wrong".

Background Concept

A CASE structure is used for multi-way selection: one expression is evaluated, and different actions happen for different values. When there are only two outcomes, an IF ... ELSE structure is often the simplest equivalent.

In this function, the expression being tested is Index MOD 2. For integers, checking modulo 2 is a standard way to test parity: 0 means even, and 1 means odd.

Understanding the Question

The original pseudocode uses:

• 0 to assign the uppercase right-hand part of Label
• 1 to assign "****"

The question asks for the same behaviour using a single selection construct and specifically says not to use CASE. That means the intended replacement is one IF ... ELSE block.

Approach

Take the condition that matters most: whether Index MOD 2 equals 0. If it does, perform the first assignment. Otherwise, perform the second assignment.

Because there are only two outcomes, a single IF ... ELSE exactly matches the original functionality.

Step-by-Step Reasoning

The original CASE is:

• if Index MOD 2 is 0, then ReturnValue ← TO_UPPER(RIGHT(Label, Count))
• if Index MOD 2 is 1, then ReturnValue ← "****"

To convert this into one selection construct, write:

IF Index MOD 2 = 0 THEN
   ReturnValue ← TO_UPPER(RIGHT(Label, Count))
ELSE
   ReturnValue ← "****"
ENDIF

Why this works:

• The IF handles the 0 case directly.
• The ELSE handles the other outcome from the original two-case structure.
• The assignments are unchanged, so the behaviour remains the same.

Key Takeaways

• CASE and IF ... ELSE can often be converted into each other.
• MOD 2 is a standard even/odd test.
• When only two outcomes exist, a single IF ... ELSE is usually the clearest replacement.

Common Mistakes

• Writing two separate IF statements instead of one selection construct.
• Forgetting THEN or ENDIF in CIE pseudocode.
• Using = for assignment instead of ←.
• Changing the original actions instead of only changing the selection structure.

Things to Be Careful About

• The question asks for pseudocode, so use CIE pseudocode conventions: IF, THEN, ELSE, ENDIF, and ←.
• Keep the original identifiers exactly: Index, ReturnValue, Label, Count.
• Do not introduce a CASE again or add unnecessary extra conditions.

Background Concept

A 1D array stores multiple items of the same data type in indexed positions. In this question, Filling stores up to 35 strings and Bread stores up to 10 strings. Some positions may be unused, and an unused position contains the empty string "".

When a program must choose random items from arrays like this, it cannot just pick any index once and use it immediately, because the chosen position might be unused. A common solution is to keep generating a random index until a valid value is found.

This question also needs two different fillings. That means after choosing the first filling, the second choice must be checked so that it is both:

• not an empty string
• not the same selection as the first one

A PROCEDURE is suitable because the task is to perform an action and output a result, not to return a value.

Understanding the Question

You are asked to complete the pseudocode for Special(). The arrays already exist globally, so the procedure can use them directly and does not need them as parameters.

Important details in the stem are:

• Filling has indexes 1 to 35
• Bread has indexes 1 to 10
• some elements in either array may be unused
• unused elements contain ""
• the sandwich must use two fillings
• the two fillings must be different
• one bread must also be chosen

So the procedure must not simply do three random array accesses. It must validate each choice before using it.

Approach

The simplest valid design is:

1. Randomly choose an index for the first filling until it points to a non-empty element.
2. Randomly choose an index for the second filling until it points to a non-empty element and is different from the first filling choice.
3. Randomly choose an index for the bread until it points to a non-empty element.
4. Output the finished sentence using the selected array values.

REPEAT ... UNTIL is a very good fit here because the program must generate at least one random index before it can test whether that choice is acceptable.

Step-by-Step Reasoning

First, local variables are needed to store the chosen indexes:

• Filling1
• Filling2
• BreadChoice

They are all integers because they hold array positions, not the text itself.

The first loop is:

REPEAT
   Filling1 ← RANDOM(1, 35)
UNTIL Filling[Filling1] <> ""

This means:

• generate an index between 1 and 35
• look at Filling[Filling1]
• if that array element is empty, try again
• stop only when the chosen element contains a real filling name

The second loop is:

REPEAT
   Filling2 ← RANDOM(1, 35)
UNTIL Filling[Filling2] <> "" AND Filling2 <> Filling1

This adds one extra rule compared with the first loop. The second filling must not come from the same array position as the first. So both conditions must be true:
- the element is not empty
- the index is different from `Filling1`

The bread selection uses the same pattern as the first filling, but with the bread array bounds:

```pseudocode
REPEAT
   BreadChoice ← RANDOM(1, 10)
UNTIL Bread[BreadChoice] <> ""

Finally, the output uses the chosen array elements, not the index numbers:

OUTPUT "The daily special is ", Filling[Filling1], " and ", Filling[Filling2], " on ", Bread[BreadChoice], " bread."

So if:

• Filling[Filling1] is "Cheese"
• Filling[Filling2] is "Onion"
• Bread[BreadChoice] is "Brown"

then the output becomes:

The daily special is Cheese and Onion on Brown bread.

That satisfies every requirement in the question.

Key Takeaways

• When arrays contain unused elements, random selection must include a validity check.
• REPEAT ... UNTIL is useful when at least one attempt must be made before checking.
• To ensure two chosen items are different, compare the second choice against the first before accepting it.
• Global arrays can be used directly inside a procedure when the question states this.

Common Mistakes

• Choosing a random index once and not checking whether the array element is empty.
• Allowing both fillings to be the same by forgetting the second validation condition.
• Using the wrong array bounds, such as choosing bread from 1 to 35 instead of 1 to 10.
• Outputting the index numbers instead of the actual array contents.
• Writing real programming-language syntax instead of CIE-style pseudocode.

Things to Be Careful About

• The arrays are indexed from 1, not 0.
• The empty string must be checked as "".
• The procedure should declare only its local variables; the arrays are already global.
• The condition for the second filling needs AND, because both rules must be satisfied.
• The exact random function name can vary in different pseudocode styles, but it must clearly mean a random integer within the required bounds.

Background Concept

When a program has extra rules about which data values may appear together, the design should include a way to store those rules. This is a form of validation: the program does not just check that each single value is valid on its own, it also checks that the combination is valid.

A good design often uses a lookup structure. For pairings, a 2D array works well because it lets the program test one item against another quickly. Each cell can store something like:

• TRUE if the pair is allowed
• FALSE if the pair is forbidden

Understanding the Question

The question is not asking for full code. It asks how the design should be changed so that certain filling combinations, such as anchovies with peanut butter, can never be chosen.

So the key idea is that the original design only stores a list of fillings. That is enough to choose random fillings, but not enough to know whether a particular pair is acceptable.

Approach

The design needs one extra part:

1. A data structure that records which combinations are allowed or forbidden.
2. A check after selecting a pair of fillings.
3. If the pair is forbidden, the program must reject it and choose again.

The clearest design is a 2D lookup table using filling indexes.

Step-by-Step Reasoning

Suppose filling 4 is Anchovies and filling 5 is Peanut Butter.

A 2D array such as Allowed[1:35, 1:35] could be added. Then:

• Allowed[4,5] ← FALSE
• Allowed[5,4] ← FALSE

Both directions should usually be stored because the pair Anchovies + Peanut Butter is the same bad pairing whichever one was chosen first.

When the program picks the two fillings, it would then test the table entry for those two indexes. If the table says the pair is not allowed, the program discards that second choice and picks again.

That means the program now checks two things for the second filling:

• it must not be empty
• it must not create a forbidden pair with the first filling

Another acceptable design would be to store only valid pairs in a separate list and choose from that list instead. But the central idea is the same: store pairing rules explicitly and check them before output.

Key Takeaways

• Some problems need validation of combinations, not just single values.
• A 2D Boolean lookup table is a strong design for checking whether two indexed items may appear together.
• Good design changes add data structures that represent the real-world rules clearly.

Common Mistakes

• Saying only "use IF statements" without explaining what data would be stored or checked.
• Forgetting that the invalid pair may occur in either order.
• Detecting a bad combination but not explaining that the program must choose again.
• Suggesting removal of fillings from the main array, which would stop them being used in all combinations rather than only the bad ones.

Things to Be Careful About

• The question asks for a design change, so the answer should mention an added data structure or lookup method, not just vague checking.
• If using a 2D array, the filling indexes must match the indexes used in the original Filling array.
• The program must reject only forbidden pairs, not the individual fillings themselves.
• If the check is done after selection, the algorithm must loop until an allowed combination is found.

Background Concept

This part is about abstraction in problem-solving. Abstraction means focusing only on the information that matters for a particular task and ignoring data that is not needed.

In many data-processing questions, you are given a large record containing many fields. The skill is to decide which fields are actually required by the new module being described. A good answer does not just name a field; it also explains exactly what the module uses that field for.

Understanding the Question

The question gives a customer record containing:

• ID
• name
• home address
• email address
• mobile phone number
• date of birth
• number of points
• date of last visit
• amount spent at last visit

The new module must:

• generate a personalised email
• send it to customers who have not visited in the last three months
• include a unique voucher code

So we need to choose three pieces of customer data that help the module do those jobs.

Approach

Match each requirement of the module to a field in the record:

• To send an email, the module needs the customer's email address.
• To decide whether the customer qualifies, the module needs the date of last visit.
• To ensure the voucher code is unique or tied to the correct person, the module can use the customer ID.

A field such as name could also be justified because the email is personalised, but only three items are needed, so it is sensible to choose the fields most directly required for delivery, selection and uniqueness.

Step-by-Step Reasoning

1. Look at what the module must output: a personalised email with a voucher code.
2. Ask what information is needed to carry out each part of that task.
3. For sending the email, email address is essential.
4. For selecting which customers should receive it, date of last visit is essential because the condition is "not visited in the last three months".
5. For making the voucher unique and linked to the correct customer, ID is a strong choice because the question states that it is unique.

That leads to these three well-justified answers:

• email address → send the message
• date of last visit → test the three-month condition
• customer ID → uniquely identify customer / generate unique voucher code

Key Takeaways

• Abstraction means choosing only the data relevant to the current task.
• In record-based questions, always link each chosen field to a specific requirement.
• A justification should explain the use of the field, not just repeat its name.

Common Mistakes

• Choosing irrelevant fields such as home address or date of birth when the module does not need them.
• Giving three items but no justifications.
• Giving vague justifications such as "it is useful" instead of saying exactly how the module uses the data.
• Choosing fields that are possible but not clearly linked to the stated task.

Things to Be Careful About

• The question asks for items used by the new module, not all useful customer details in general.
• Make sure each justification matches the module description.
• Only one valid set of three is needed, but each choice must be defensible from the scenario.

Background Concept

Computational thinking includes skills such as abstraction, decomposition, algorithmic thinking and pattern recognition.

• Abstraction means selecting the important details and ignoring irrelevant ones.
• Decomposition means breaking a large problem into smaller parts.
• Algorithmic thinking means working out a sequence of steps.
• Pattern recognition means spotting similarities or repeated structure.

Understanding the Question

Part (b) asks which computational thinking skill was needed in part (a).

In part (a), you had a long list of customer data items and had to decide which ones were relevant to the new module. That means you were filtering information.

Approach

Ask: what did part (a) involve?

• It did not mainly involve writing steps for a solution.
• It did not mainly involve splitting the problem into modules.
• It did involve choosing only the important data from a larger set.

That matches abstraction.

Step-by-Step Reasoning

In part (a), the record contained many fields, but only some were needed for the email module. Selecting those relevant fields and ignoring the rest is exactly the definition of abstraction.

So the correct computational thinking skill is:

• Abstraction

Key Takeaways

• If a question asks you to focus on relevant information and ignore the rest, the skill is usually abstraction.
• Learn to distinguish abstraction from decomposition and algorithm design.

Common Mistakes

• Answering decomposition because the question mentions a module.
• Answering algorithmic thinking because a computer system is involved.
• Naming a general study skill instead of a computational thinking skill.

Things to Be Careful About

• Read what you actually did in the previous part.
• If the task is about selecting relevant data from a larger description, the safest answer is usually abstraction.

Background Concept

In the program development life cycle (PDLC), the design stage turns the results of analysis into a detailed plan for how the system will be built.

Typical design-stage items include:

• algorithms
• module designs
• data structures
• file/database structures
• input and output formats
• screen/report layouts
• validation rules
• error handling methods

The key idea is that design describes how the system will work, before full implementation starts.

Understanding the Question

The question says that analysis is complete and the project has moved to design. It also already tells you that during design:

• algorithms will be defined
• module designs will be defined

It then asks for three other items that will be defined. So you must avoid repeating those two and give three different design outputs.

Approach

Think of common deliverables from the design stage and choose three that are clearly different from algorithms and module designs.

Strong, standard choices are:

• input/output formats
• data structures or file structures
• validation rules and error handling

These are all specific design decisions made before coding.

Step-by-Step Reasoning

1. The question rules out algorithms and module designs, so do not use them.
2. Consider what still needs to be specified before programming starts.
3. The programmer needs to know:
   • what data will come in and what output must be produced
   • how the data will be stored and organised
   • what checks will be made on data and what happens if something is wrong
4. That gives three valid design-stage items:
   1. Input and output formats / layouts
   2. Data structures / file or record structures
   3. Validation rules and error handling

Other valid answers may exist, but these are clear and standard.

Key Takeaways

• The design stage produces a detailed blueprint for implementation.
• Good design answers usually name specific artefacts, not vague statements.
• Always notice when the question says other and avoid repeating given examples.

Common Mistakes

• Repeating algorithms or module designs even though the question says other.
• Naming items from a different stage, such as maintenance tasks.
• Giving vague answers like "coding" or "testing" instead of specific design outputs.

Things to Be Careful About

• Design is before implementation, so answers should describe planning and specification.
• Use precise terms such as data structures, validation rules, or input/output formats.
• If you mention testing, be careful: detailed test execution belongs to the testing stage, although some test planning may be prepared earlier.

Background Concept

A structure chart shows the relationship between modules in a program.

It usually shows:

• the calling hierarchy: which module controls or calls which other modules
• data couples: values passed between modules, such as parameters and return values
• iteration where a module or sequence of modules is called repeatedly

A structure chart is not the same as a flowchart:

• a flowchart shows the steps in an algorithm
• a structure chart shows how the program is divided into modules and how they interact

Understanding the Question

We are told:

• Init() has no parameters and returns a Boolean
• Reset() takes a string parameter and returns an Integer
• Check() repeatedly calls Init() followed by Reset()

So the chart must show three things clearly:

1. Check() is the top-level controlling module.
2. Init() and Reset() are called by Check().
3. The calls are repeated, and the parameter/return values must be shown in the correct direction.

Approach

Start by placing Check at the top because it controls the others.

Then place Init and Reset below it because they are subordinate modules.

Next, add the data flow:

• Init() returns a Boolean to Check().
• Check() passes a String to Reset().
• Reset() returns an Integer to Check().

Finally, add iteration notation around the calls because Check() does this repeatedly.

Step-by-Step Reasoning

1. Draw a module box labelled Check at the top.
2. Draw two lower module boxes labelled Init and Reset.
3. Connect Check to both lower modules to show they are called from Check.
4. Because Init() has no parameters, do not show any parameter passed down to Init.
5. Show a return value from Init back to Check, labelled Boolean.
6. Show a parameter from Check down to Reset, labelled String.
7. Show a return value from Reset back up to Check, labelled Integer.
8. Add an iteration symbol or loop around the calls from Check to indicate that Check() repeatedly calls Init() followed by Reset().

This captures both the module hierarchy and the information flowing between the modules.

Key Takeaways

• The module that controls the others goes at the top of a structure chart.
• Parameters flow to a module; return values flow back from a module.
• Repetition should be shown when the calls occur repeatedly.
• Structure charts show module organisation, not detailed logic.

Common Mistakes

• Putting Init or Reset at the top instead of Check.
• Showing a parameter going into Init() even though it has none.
• Omitting the return values.
• Reversing the direction of the parameter or return arrows.
• Forgetting to show that the calls are repeated.
• Drawing a flowchart instead of a structure chart.

Things to Be Careful About

• Match each module signature exactly:
  • Init() → no parameters, returns Boolean
  • Reset(String) → takes String, returns Integer
• The sequence is Init() followed by Reset().
• Make sure the repetition applies to the calling pattern from Check().
• Use labels for the data being passed so the examiner can see both the parameter type and the return type.

Background Concept

A record lets a program store several related values together under one name. Here, each element of the global Character array is a CharacterType record with fields Player, Role, Name and Level. To find one specific record, a common technique is a linear search: start at the first array element, test each record in turn, and stop when a suitable one is found or when the end of the array is reached.

This question also uses a procedure. A procedure is appropriate when a module performs an action, such as changing data or displaying a message, rather than calculating and returning a single value. The procedure here takes two inputs: a player number and a required role.

Understanding the Question

The task is to write pseudocode for Assign(). The procedure must search the 45-element global Character array for a character that satisfies two conditions at the same time:

• the character is unassigned, so Player = 0
• the character has the required role

If such a character is found, the procedure must assign that character to the given player by changing the Player field and then output a confirmation message such as Bill the Builder has been assigned to player 3.

If no suitable unassigned character exists, the procedure must output a suitable alternative message.

Approach

The cleanest method is a linear search with a Boolean flag such as Found. The flag starts as FALSE. As the array is scanned from index 1 to 45, each record is checked. When the first matching record is found:

1. set its Player field to the given player number
2. output the confirmation message
3. set Found to TRUE so the search stops

After the loop, if Found is still FALSE, output the failure message.

A WHILE loop is a good fit because it can stop early once the character has been found.

Step-by-Step Reasoning

First, declare the local variables needed for the search:

• Index to move through the array
• Found to remember whether a suitable record has been found

Found is initialised to FALSE because before the search starts, nothing has been found. Index is initialised to 1 because the array is declared as ARRAY[1:45], so this is a 1-based array.

The loop condition is Index <= 45 AND Found = FALSE. This means the search continues only while:

• the index is still inside the array bounds, and
• no match has yet been found

Inside the loop, the key test is:

Character[Index].Player = 0 AND Character[Index].Role = RequiredRole

Both parts matter. Checking only the role would allow already-assigned characters to be reused, which is wrong. Checking only Player = 0 would allow the wrong role to be assigned.

When the condition is true, the procedure performs the assignment:

Character[Index].Player ← GivenPlayer

That updates the record in the global array, which is the main purpose of the procedure.

Then it outputs a message built from the character's Name, the text the, the Role, and the player number converted to a string using NUM_TO_STR. The conversion is important because the message is a string, but GivenPlayer is an integer.

Finally, Found ← TRUE is set. That prevents any later matching characters from being assigned as well.

The index is then incremented so the loop can move on if needed. After the loop, a final IF Found = FALSE handles the case where no suitable character existed anywhere in the array.

A FOR loop with a flag would also be a valid idea, but a WHILE loop expresses early termination more directly.

Key Takeaways

• Use a procedure when the module performs an action rather than returns a value.
• Use a linear search to scan an array of records one element at a time.
• When searching records, test all required fields, not just one.
• A Boolean flag is a standard way to stop searching once a match is found and to detect the no-match case afterwards.

Common Mistakes

• Forgetting to test Player = 0. That would allow already-assigned characters to be reassigned.
• Forgetting to set Found ← TRUE. Then the loop may continue and assign more than one character.
• Using the wrong array bounds, such as starting at 0. The array is declared from 1 to 45.
• Outputting only the role or only the name instead of the full confirmation message.
• Writing GivenPlayer directly into a concatenated string without converting it with NUM_TO_STR.

Things to Be Careful About

• Keep the identifier names consistent with the stem, especially Character, Player, Role and Name.
• Use the assignment arrow ←, not =.
• Make sure the procedure changes the record field in the array, not just a temporary variable.
• Do not forget the failure message after the loop; the question explicitly requires output if no unassigned character with the role is found.

Background Concept

A text file stores data as characters. When a program wants to save several fields from one record onto one line, a common method is to create a delimited string. A delimiter is a special separator character placed between fields so that the line can later be split back into its original parts. In this question, the delimiter is ^.

Because text files store characters, any numeric values such as integers usually need to be converted into strings before they are joined with string fields.

Understanding the Question

The new Save() procedure must take the contents of the global Character array and write them to a new text file called SaveFile.txt.

The instructions give two precise requirements:

• form a string from each record with the fields separated by ^
• write each string to a separate line of the file

Each Character[Index] record has four fields to save in the current version of the question:

• Player
• Role
• Name
• Level

So the output for one record should look like a single line such as 0^Builder^Bill^14.

Approach

The method is straightforward:

1. open SaveFile.txt for writing
2. loop through all 45 elements of the Character array
3. build one string from the four fields, inserting ^ between them
4. convert integer fields to strings before concatenation
5. write that string as one line in the file
6. close the file at the end

A FOR loop is the natural choice because every record from 1 to 45 must be saved.

Step-by-Step Reasoning

Index is needed to move through the array, and OneLine stores the finished text for the current record.

The procedure starts with:

OPENFILE "SaveFile.txt" FOR WRITE

This creates the new file for output. Then the loop runs from 1 to 45 because the array bounds are ARRAY[1:45].

Inside the loop, the program constructs a delimited string. The order should match the field order being saved. The expression is:

NUM_TO_STR(Character[Index].Player) & "^" & Character[Index].Role & "^" & Character[Index].Name & "^" & NUM_TO_STR(Character[Index].Level)

The two numeric fields are Player and Level, so each is converted using NUM_TO_STR. The Role and Name fields are already strings, so they can be joined directly.

That completed string is then written to the file with WRITEFILE. Because this is done once per loop iteration, each record goes to a separate line.

After all 45 records have been written, CLOSEFILE is used to finish the save operation properly.

Key Takeaways

• Saving records to a text file usually means turning each record into a delimited string.
• Numeric data must be converted to string form before concatenation.
• Use a count-controlled loop when every array element must be processed.
• Always close a file after writing.

Common Mistakes

• Forgetting to open the file in write mode.
• Omitting one of the fields when forming the line.
• Forgetting the ^ separators, which would make the file hard to reconstruct later.
• Trying to concatenate integers directly with strings without conversion.
• Forgetting to close the file after writing.

Things to Be Careful About

• The array is 1-based, so the loop must run from 1 to 45.
• The filename must match the question exactly: SaveFile.txt.
• The question says each record must go on a separate line, so there should be one WRITEFILE call per record.
• Keep the field order consistent, because changing the order would make later reading and restoring more difficult.

Background Concept

A text file stores characters, not native Boolean values. So when a record contains a Boolean field, the program must choose a text representation for that value. Common choices are the words TRUE and FALSE, or coded values such as 1 and 0.

When a record is being stored as one line in a text file, each field is usually separated with the same delimiter so the line can later be split back into separate fields during loading.

Understanding the Question

The record type has been extended with a new field:

DECLARE Status : BOOLEAN

The question asks how this extra Boolean value could be stored on the same line as the other fields in the text file. So the important idea is not changing the file structure completely, but extending the existing delimited-line method to include one more field.

Approach

Use the same delimiter-based format as before. Represent the Boolean in text form and place it after the existing fields, separated by ^.

So the line simply becomes one field longer.

Step-by-Step Reasoning

Originally, a line might contain:

Player^Role^Name^Level

After adding Status, the line format becomes:

Player^Role^Name^Level^Status

Because Status is Boolean, it must be saved in text form. A clear method is to store either TRUE or FALSE. For example, if Bill is assigned to player 3, has level 14 and the status is true, a line could be:

3^Builder^Bill^14^TRUE

This works well because:

• the delimiter still separates fields clearly
• the load process can read the final field and interpret it as Boolean again

Key Takeaways

• Text files require non-text types to be represented as text.
• A Boolean field can be stored as TRUE/FALSE or another agreed code.
• When a record structure changes, the text-file format usually changes by adding another delimited field.

Common Mistakes

• Saying the Boolean can be stored directly as a Boolean without any text representation.
• Forgetting to mention the separator character ^.
• Replacing an existing field rather than adding the new field as an extra one.

Things to Be Careful About

• Whatever representation is chosen, it must be used consistently when saving and loading.
• The extra field should be in a fixed position so the restore process knows where to find it.
• If TRUE/FALSE is used, keep the spelling consistent throughout the program.

Background Concept

When a program needs to keep several saved versions of data, each save must have a unique filename. A simple and reliable method is sequential naming: keep a counter and include its value in the filename. This makes the order of saves obvious and prevents one file from overwriting another.

Understanding the Question

The question says that multiple save files must be possible as the game progresses, and the filename must reflect the sequence in which the files are saved. That means the filename should show first save, second save, third save, and so on.

The answer needs two things:

• a method for how the filenames are produced
• two example filenames that are consecutive in the sequence

Approach

Use a variable such as SaveNumber. Each time the save operation happens:

1. use the current number in the filename
2. save the file
3. increment the number for the next save

The filename can be built from a base part such as SaveFile, then the number, then .txt.

Step-by-Step Reasoning

Suppose the program starts with SaveNumber ← 1.

On the first save, the filename becomes:

SaveFile1.txt

After saving, the program increments the counter to 2.

On the next save, the filename becomes:

SaveFile2.txt

This method works because each filename is different, and the number also tells the user the order in which the saves were made.

Other equivalent naming styles would also work, such as Game1.txt, Game2.txt or versions with leading zeros like SaveFile01.txt, SaveFile02.txt, provided the sequence is clear.

Key Takeaways

• Multiple save files need unique filenames.
• A counter is a simple way to generate unique names in sequence.
• Embedding the sequence number in the filename also helps users identify save order.

Common Mistakes

• Giving two identical filenames, which would overwrite the earlier save.
• Using unrelated names that do not show a sequence.
• Describing only the examples and not the method.

Things to Be Careful About

• The numbering must increase every time a save is made.
• The sequence number should be part of the filename itself, not only stored elsewhere.
• The examples must be consecutive, not just any two filenames.