Computer Science 9618/21 — October/November 2024

Background Concept

A logic error happens when a program runs, but produces the wrong result because the method is incorrect. In arithmetic questions, a very common logic error is using a percentage as though it were already a multiplier.

For example:

• 5.23% means 5.23 per 100
• as a calculation factor, that is 5.23 / 100 = 0.0523

So if an item costs $100, then tax at 5.23% is:

If you forget the division by 100, you get:

which is clearly wrong.

Understanding the Question

The question gives pseudocode where TaxRate is chosen correctly using a CASE OF statement. It also clearly tells you that values such as 3.75, 5.23 and 6.25 represent percentages.

You are asked to:

• identify the logical error
• give a correction

So the key is not the CASE selection itself. The problem is in the final line where TaxPayable is calculated.

Approach

Read the description carefully and compare it with the arithmetic used in the pseudocode.

The description says TaxRate values are percentages. Therefore, when calculating tax, the rate must be converted from a percentage into its fractional form by dividing by 100.

So the approach is:

1. Spot where TaxRate is used in a calculation.
2. Check whether that use matches the meaning of a percentage.
3. Replace it with a correct percentage calculation.

Step-by-Step Reasoning

The relevant line is:

TaxPayable ← ItemCost * TaxRate

Now test it mentally using the example given in the question:

• ItemCost = 100
• TaxRate = 5.23

Substituting into the pseudocode gives:

But the question explicitly says the tax on $100 at 5.23% should be $5.23, not $523.

That proves the expression is logically wrong.

To fix it, divide the percentage by 100 during the calculation:

TaxPayable ← ItemCost * TaxRate / 100

Now the same example gives:

which matches the intended result.

An alternative design would be to store the tax rates as 0.0375, 0.0523, and 0.0625 instead, but this part specifically asks for the correction to the shown pseudocode, so the direct correction is to divide by 100.

Key Takeaways

• A percentage must be converted to a fraction before using it as a multiplier.
• Logic errors often appear in formulas even when the program structure is correct.
• Testing with a known example is a good way to spot this kind of mistake.

Common Mistakes

• Writing that the error is in the CASE statement when the selection of bands is actually fine.
• Saying only “the calculation is wrong” without explaining that the rate is a percentage.
• Correcting it to TaxPayable ← ItemCost / TaxRate, which does not represent percentage tax.
• Changing the stored values instead of correcting the shown line, when the question asks for a correction to the pseudocode.

Things to Be Careful About

• The question defines the meaning of the tax rate values very precisely. You must use that wording: they are percentages, not decimal multipliers.
• In CIE pseudocode, assignment uses ←, not =.
• If you describe the correction in words, make sure it is unambiguous: divide the tax rate by 100 or divide the whole product by 100.

Background Concept

Choosing the correct data type means matching the type to the kind of value a variable stores.

Common basic data types in pseudocode include:

• BOOLEAN: stores TRUE or FALSE
• INTEGER: stores whole numbers only
• REAL: stores numbers with a fractional part
• STRING: stores text

To identify a type, look at how the variable is assigned and used.

Understanding the Question

You are given two variable names from the pseudocode:

• HighRate
• TaxPayable

You must give the most appropriate data type for each.

The question says “as used in the pseudocode”, so the answer must come from the values assigned in the given code, not from guessing other possible designs.

Approach

For each variable:

1. find where it is assigned
2. see what kind of value it holds
3. choose the matching data type

Step-by-Step Reasoning

HighRate

In the pseudocode:

HighRate ← FALSE

and later:

HighRate ← TRUE

So HighRate only stores TRUE or FALSE. That makes it a BOOLEAN.

TaxPayable

TaxPayable is calculated from:

TaxPayable ← ItemCost * TaxRate / 100

The tax rates include values such as 3.75, 5.23, and 6.25, which are not whole numbers. Therefore the result can include a fractional part.

A variable that may contain decimal values should be REAL.

So the completed table is:

• HighRate → BOOLEAN
• TaxPayable → REAL

Key Takeaways

• A variable storing TRUE/FALSE is BOOLEAN.
• A variable storing a value that may have decimals should be REAL.
• Data types are identified from actual use in the code.

Common Mistakes

• Writing INTEGER for TaxPayable; tax amounts can include decimal values.
• Writing STRING because the variable name looks descriptive; names do not determine type.
• Writing “logical” instead of BOOLEAN if the exam expects standard pseudocode data types.

Things to Be Careful About

• Use the exact data type names expected in CIE-style pseudocode: BOOLEAN, INTEGER, REAL, STRING.
• TaxPayable is not guaranteed to be a whole number, so REAL is safer and more accurate than INTEGER.
• Base your choice on the pseudocode shown, especially the literal values and expressions.

Background Concept

A CASE OF statement is a selection structure used when one variable or expression is being compared against several possible cases.

In CIE pseudocode, the final branch can use the keyword OTHERWISE to mean:

• if none of the earlier cases matched
• do this instead

This is the CASE equivalent of a default or catch-all branch.

Understanding the Question

The original pseudocode ends with:

> 200 : TaxRate ← 6.25
        HighRate ← TRUE

The question says this final condition could be replaced with a keyword. That tells you the earlier cases already cover all smaller values, so the last branch is simply the “everything else” case.

Approach

Look at the earlier branches:

• <= 50
• <= 200

Anything not matched by those must fall into the last case. That means the last case does not need an explicit comparison; it can use the default CASE keyword.

Step-by-Step Reasoning

The CASE OF checks ItemCost.

• If ItemCost <= 50, first branch is used.
• Otherwise, if ItemCost <= 200, second branch is used.
• If neither of those is true, the only remaining possibility is the final branch.

So instead of writing > 200, the final branch can be written using the default keyword:

OTHERWISE

That is the standard pseudocode term expected here.

Key Takeaways

• OTHERWISE is the default branch in a CASE OF statement.
• Use it when the final case means “all remaining values”.
• It can make selection logic clearer and simpler.

Common Mistakes

• Writing ELSE, which belongs to IF statements, not CASE OF in CIE pseudocode.
• Writing DEFAULT, which may be used in some programming languages but is not the CIE pseudocode keyword expected here.
• Keeping > 200 when the question specifically asks for the keyword replacement.

Things to Be Careful About

• Use the exact keyword expected by the pseudocode guide: OTHERWISE.
• Do not mix syntax from real programming languages with CIE pseudocode.
• This works here because the earlier conditions already cover the other possibilities.

Background Concept

When a text file is processed sequentially, the program reads one line at a time from the start of the file to the end. The usual pattern is:

• open the file for reading
• repeat until end of file
• read the next line
• process it
• close the file

This question uses a common technique for keeping the last few items seen so far. Instead of storing the whole file, the algorithm keeps only three variables. Each time a new line is read, the older saved lines are shifted along:

• the previous middle line becomes the oldest
• the previous newest line becomes the middle
• the line just read becomes the newest

After the whole file has been read, those three variables hold the last three lines in the same order they appeared in the file.

Understanding the Question

You are given an incomplete eight-step algorithm. The file is called Result.txt, and it is guaranteed to contain at least three lines. The variables LineX, LineY and LineZ already exist and start as empty strings.

You need to complete the missing steps so that, after reading the whole file, the algorithm outputs the final three lines in the correct order.

The important clue is the word last. Because the algorithm needs the final three lines, it cannot stop early. It must read all the way to the end of the file.

Approach

The correct strategy is a one-pass scan through the file:

1. Open Result.txt for input.
2. Keep reading until there are no more lines.
3. For each new line, shift the stored values along.
4. Put the newly read line into the newest variable.
5. When the loop finishes, close the file.
6. Output the three saved lines.

This avoids needing an array or storing the entire file.

Step-by-Step Reasoning

Step 1 must open the file Result.txt for reading, because the algorithm needs to get data from the file.

Step 2 must loop until the end of the file. That is the normal condition for sequential file reading, and it is essential here because the last three lines are not known until the file has been fully read.

Step 3 must read the next line and place it into ThisLine. That gives the algorithm the current line to process.

Steps 4, 5 and 6 perform the rolling update:

• LineY is copied to LineX
• LineZ is copied to LineY
• ThisLine is copied to LineZ

Suppose the current stored values are the three most recent lines seen so far. When a new line arrives, the oldest one is discarded, the other two move one position left, and the new line becomes the newest.

For example, if the variables currently hold:

• LineX = line 4
• LineY = line 5
• LineZ = line 6

and the next line read is line 7, then after steps 4 to 6 they become:

• LineX = line 5
• LineY = line 6
• LineZ = line 7

So the variables still hold the latest three lines in the correct order.

Step 7 closes the file after the reading loop ends. This is standard file-handling practice.

Step 8 outputs LineX, LineY and LineZ. Because of the shifting process, these are now the last three lines from the file in the same order as in the file.

Key Takeaways

• To get the last few records from a sequential file, read the whole file.
• A rolling set of variables can store the most recent values without needing an array.
• End-of-file is the standard loop condition for reading all lines of a text file.
• The order of the shift matters if you want to preserve the original sequence.

Common Mistakes

• Stopping after reading only three lines. That would give the first three lines, not the last three.
• Outputting LineZ, LineY, LineX. That would reverse the required order.
• Forgetting to close the file after the loop.
• Using the wrong shift direction, such as assigning LineX to LineY. That would overwrite useful data and break the rolling update.
• Reading outside the loop or after end of file.

Things to Be Careful About

• The loop must continue until end of file, not until three lines have been read.
• The assignments in steps 4 to 6 must happen in the given order so earlier values are preserved correctly.
• ThisLine should store the line just read before it is copied into LineZ.
• The question states the file has at least three lines, so you do not need extra handling for shorter files in this part.

Background Concept

A rolling update is used when a program only needs the most recent few values from a sequence. Instead of storing everything read so far, the algorithm keeps a small fixed number of variables and updates them each time a new value arrives.

In this question, there are three variables for three lines:

• oldest of the current three
• middle of the current three
• newest of the current three

Whenever a new line is read, the old values must be shifted to make space for it.

Understanding the Question

This part does not ask you to rewrite the algorithm. It asks for the purpose of steps 4, 5 and 6.

So you should explain what those assignments achieve overall, not just repeat them line by line.

Approach

Look at what each assignment does to the stored lines:

• LineY moves into LineX
• LineZ moves into LineY
• the newly read line moves into LineZ

That tells you these steps are maintaining a sliding set of the three most recent lines.

Step-by-Step Reasoning

Before a new line is read, suppose the variables already store the last three lines seen so far.

When another line is read:

1. The value in LineY is copied into LineX, so the previous middle line becomes the oldest stored line.
2. The value in LineZ is copied into LineY, so the previous newest line becomes the middle stored line.
3. The new line in ThisLine is copied into LineZ, so it becomes the newest stored line.

This means the previous oldest line is discarded, and the variables now hold the newest set of three lines. That is exactly what is needed if the final aim is to output the last three lines in the file.

Key Takeaways

• A rolling set of variables can keep track of the most recent items.
• Shifting values is a way to discard the oldest item and include a new one.
• The overall purpose is more important here than repeating the assignments.

Common Mistakes

• Saying the steps sort the lines. They do not sort anything.
• Saying they read the file. The reading happens in step 3, not steps 4 to 6.
• Saying they reverse the lines. They preserve the original order of the most recent three lines.

Things to Be Careful About

• Mention both ideas: keeping the last three lines and keeping them in the correct order.
• Do not describe them as storing the first three lines.
• Keep the answer focused on purpose, since this is only a one-mark explanation question.

Background Concept

A function is used when an algorithm must produce a result back to the caller. In this case, the result is Boolean:

• TRUE means the function successfully output three lines
• FALSE means it could not, usually because the file did not contain enough lines from the requested starting point onward

When reading from a text file starting at a given line number, the algorithm usually needs:

• a counter for the current line number being read
• logic to decide whether the current line is one of the required lines
• a way to stop once enough lines have been output or when the file ends

This is different from the original problem. The original problem needed the last three lines, so it had to keep shifting values and read the entire file. The new problem needs three lines starting at a known line number, so the algorithm can use counting instead.

Understanding the Question

The original steps 2 to 8 were designed for a different requirement. Now the function is called with a given starting line number, and it must:

• output exactly three lines starting from that line
• return TRUE if that succeeds
• return FALSE if there are not enough lines available

The question asks you to describe changes to steps 2 to 8, not rewrite step 1. So the file is still opened in the same way, but the loop and processing logic must change.

Approach

The best approach is:

1. Count lines as they are read.
2. When the current line number reaches the given line number, start outputting lines.
3. Keep outputting until three lines have been output.
4. If end of file is reached before three lines are output, return FALSE.
5. Otherwise return TRUE.

Because the required lines are known by position, the shifting variables LineX, LineY and LineZ are no longer needed for this version.

Step-by-Step Reasoning

In the original version, step 2 was simply to loop until end of file. That made sense because the algorithm needed the final three lines.

In the new version, the loop should still check for end of file, but it can also stop early once three lines have been output. So the loop condition becomes effectively:

• not end of file
• and fewer than three required lines output so far

Next, after each line is read, the algorithm must know which line number it is currently processing. So a current-line counter is needed and must be incremented for each line read.

Then the algorithm compares the current line number with the given starting line number:

• if current line number is less than the given line number, ignore the line
• if current line number is the given line number, output it
• also output the next two lines after that

Each time one of these required lines is output, the algorithm should increase a second counter that records how many lines have been output.

Once that counter reaches 3, the function has done its job.

This means steps 4, 5 and 6 from part (a) are no longer appropriate. Those steps were only for keeping the last three lines seen in the file. Here, we are not interested in the last three lines at all; we are interested in three specific lines based on position.

After the loop, the file should still be closed.

Finally, the function must return a Boolean result:

• if the number of lines output is 3, return TRUE
• otherwise return FALSE

For example, if the caller requests line 10:

• line 10 is output when reached
• line 11 is output next
• line 12 is output next
• if all three are found, return TRUE
• if the file ends at line 11, only two lines can be output, so return FALSE

Key Takeaways

• Changing the requirement often means changing the whole algorithm strategy, not just a small detail.
• For line-position problems, counters are more useful than rolling storage variables.
• A function should return a value that tells the caller whether it succeeded.
• Combining loop conditions can make file processing more efficient by stopping as soon as enough data has been found.

Common Mistakes

• Keeping steps 4, 5 and 6 unchanged. Those are only for finding the last three lines.
• Forgetting to count line numbers. Without that, the algorithm cannot tell when to start outputting.
• Returning TRUE just because the starting line exists, even if fewer than three lines were available.
• Looping only until the given line number is reached, instead of continuing until all three lines are output.
• Forgetting to close the file before returning.

Things to Be Careful About

• The function must output three lines starting from the given line, not just the one matching the given line number.
• You need two separate counts: current line number and number of required lines output.
• If the file ends before three lines are output, the correct return value is FALSE.
• Since the question asks for changes to steps 2 to 8, step 1 remains the file-open step from part (a).
• Be clear that the output may now happen during the loop rather than only after it.

Background Concept

A run-time error is an error that happens while a program is executing. The program may have been written with correct syntax, but when it actually runs it attempts an invalid operation.

Typical examples include:

• dividing by zero
• reading a file that does not exist
• using an array index outside its valid range
• converting data into an invalid type

That is different from:

• a syntax error, which stops the program from being translated correctly
• a logic error, where the program runs but produces the wrong result

In this question, x and y are strings, so before arithmetic can happen they must first be converted into numbers.

Understanding the Question

The statement is:

Result ← STR_TO_NUM(x) / STR_TO_NUM(y)

So the program is doing two conversions from string to number, then a division. The question says two checks are needed first:

1. both strings must represent valid numbers
2. the numeric value of y must not be zero

If those checks are skipped, the program may fail during execution. The task is to name the type of error and give a cause.

Approach

First, decide whether the failure would happen before running or while running. Here, the statement itself is syntactically valid, so the problem appears only when the program tries to execute it with unsuitable data.

Then give one valid cause from the information in the stem:

• invalid numeric conversion, or
• division by zero

Either is enough as the cause.

Step-by-Step Reasoning

STR_TO_NUM(x) means "convert the string in x into a number".

If x contains something like "abc" or any non-numeric text, that conversion cannot be completed properly. The program reaches that line, tries to convert the value, and fails there. That is a run-time error.

Similarly, even if both strings are valid numeric strings, there is still the division:

number / STR_TO_NUM(y)

If STR_TO_NUM(y) gives 0, the program attempts division by zero. That is also a run-time error because it happens when the program is executing the statement.

So the correct error type is run-time error, and a correct cause is either invalid numeric conversion or division by zero.

Key Takeaways

• Run-time errors happen during execution, not during translation.
• Converting a string to a number is only safe if the string is a valid numeric value.
• Division must always be protected against a zero divisor.

Common Mistakes

• Writing "logic error": that would mean the program runs but gives a wrong answer, not that it crashes on invalid data.
• Writing "syntax error": the statement is syntactically valid, so translation is not the issue.
• Giving a vague cause such as "bad data" without saying why it causes failure.

Things to Be Careful About

• The cause must match the statement given. The risky operations here are STR_TO_NUM() and division.
• The question asks for a type of error and a cause, so both parts are needed.
• If you give the cause as division by zero, make it clear that it is the numeric value of y that becomes zero after conversion.

Background Concept

A module is a self-contained section of a program that performs one task. In this syllabus, that usually means a procedure or a function.

Using modules is part of decomposition: breaking a larger problem into smaller manageable parts. Good modular design gives several benefits, such as:

• easier testing
• easier debugging
• easier maintenance
• clearer program structure
• less duplicated code

A function is especially suitable when a task produces and returns a value.

Understanding the Question

The question already gives one reason for using a module: the same checks and calculation happen in several places in the program. That is the reuse reason.

You are asked for another reason, so you should not just repeat "it can be reused". You also need to say what is avoided by using the module approach.

Approach

Choose one standard advantage of modular programming other than reuse. The safest choices are:

• easier to test
• easier to debug
• easier to maintain
• easier to understand

Then state what is avoided. Since one module replaces multiple copied sections, what is avoided is duplicated or repeated code.

Step-by-Step Reasoning

If the checking and calculation code is placed in one module, the programmer can focus on that one section separately.

For example:

• it can be tested independently with different values of x and y
• if there is a bug, the programmer knows exactly where to look
• if the rule changes later, only one module needs to be edited

That is why "easier testing/debugging/maintenance" is a valid reason.

What does this approach avoid? Without a module, the programmer may write the same checking and calculation statements in several places. That leads to repeated code. So the avoided issue is code duplication.

Key Takeaways

• Modules help organise programs into clear, separate tasks.
• A good reason for using a module is often easier testing, debugging, or maintenance.
• One major thing avoided by modules is duplicated code.

Common Mistakes

• Repeating the reason already given in the question, such as "because it is used several times".
• Giving something vague like "it is better" without saying why.
• Saying "errors are avoided" as the avoided point. That is too general; the expected idea is duplicated code.

Things to Be Careful About

• The question asks for another reason, so do not restate reuse.
• Make sure the two parts are distinct: one is a benefit, the other is what is avoided.
• Keep the answer tied to modules, not to general programming quality with no explanation.

Background Concept

A function is used when a module must return a value. Normally a function returns one value, but sometimes a task naturally produces more than one result. In this question, the function must return:

• whether the calculation was completed successfully
• the calculated real value if it was successful

A common way to return both pieces of information is to define a record type. A record groups related fields together under one data type.

Here the record type is:

TYPE Result
   DECLARE Done : BOOLEAN
   DECLARE Value : REAL
ENDTYPE

So the function can return one Result record containing both fields.

The logic also needs validation before calculation:

• check both strings are valid numeric values
• check the divisor is not zero
• only then perform the division

Understanding the Question

You must write the function Evaluate().

It takes two string parameters, representing the values to be used in the calculation. The function must return a variable of type Result.

The rules are precise:

• if either string is not numeric, return a Result record with Done ← FALSE
• if the numeric value of y is zero, return a Result record with Done ← FALSE
• otherwise set Done ← TRUE and set Value to the result of:
  STR_TO_NUM(x) / STR_TO_NUM(y)

So this is a selection problem: do the calculation only if both checks pass.

Approach

A neat structure is:

1. declare a local variable of type Result
2. assume failure first by setting Done ← FALSE
3. test whether both strings are numeric
4. convert them to real values only after that check passes
5. test whether the second numeric value is not zero
6. if safe, perform the division and set Done ← TRUE
7. return the record

Setting Done to FALSE at the start is useful because then every invalid case is already handled. You only change it to TRUE in the success case.

Step-by-Step Reasoning

Start the function header:

FUNCTION Evaluate(BYVAL x : STRING, BYVAL y : STRING) RETURNS Result

This states the function name, its two string parameters, and its return type.

Next, declare the local variables:

DECLARE TempResult : Result
DECLARE NumX, NumY : REAL

TempResult is the record that will eventually be returned. NumX and NumY store the converted numeric values.

Now initialise the Boolean field:

TempResult.Done ← FALSE

This is a good default. If anything goes wrong, the returned record already shows that the calculation was not completed.

Next, validate the inputs:

IF IsNumeric(x) AND IsNumeric(y) THEN

The important idea is that both strings must be valid numbers before STR_TO_NUM() is used. The exact validation function name may vary, but the logic must clearly test that both values are numeric.

Only after that should conversion happen:

NumX ← STR_TO_NUM(x)
NumY ← STR_TO_NUM(y)

This order matters. If you convert before checking, you are back to risking the run-time error from part (a).

Then check the divisor:

IF NumY <> 0 THEN

This prevents division by zero.

If the divisor is safe, perform the calculation and mark success:

TempResult.Done ← TRUE
TempResult.Value ← NumX / NumY

Notice that Value only needs to be assigned in the valid case. The question only requires Done ← FALSE when the calculation cannot be completed.

Finally, return the record:

RETURN TempResult
ENDFUNCTION

That completes the function.

Key Takeaways

• A record is useful when a function needs to return more than one related value.
• Validation should happen before conversion and before arithmetic.
• A safe pattern is to assume failure first, then change the success flag only when all checks pass.
• Nested IF statements are often the clearest way to protect a calculation step.

Common Mistakes

• Performing STR_TO_NUM() before checking that the string is numeric.
• Forgetting to test whether y is zero before dividing.
• Returning a real value directly instead of returning a Result record.
• Not setting Done correctly for the failure case.
• Writing a procedure instead of a function, even though the question explicitly asks for a function.
• Using = for assignment instead of the pseudocode assignment arrow ←.

Things to Be Careful About

• The return type must be Result, not REAL or BOOLEAN.
• The function needs two parameters, both of type STRING.
• Use CIE-style pseudocode: FUNCTION, DECLARE, IF, ENDIF, RETURN, ENDFUNCTION.
• Make sure the division only happens in the success branch.
• The exact name of the numeric-validation routine can vary, but the check itself must be present clearly in the logic.

Background Concept

The program development life cycle breaks software creation into stages so that the work is organised and checked systematically. Common stages include:

• Analysis: finding out what the user needs and what problems exist with the current system.
• Design: planning the solution, including algorithms, data structures, records and file layouts.
• Coding: translating the design into a programming language.
• Testing: checking that the system works correctly and finding errors.
• Maintenance: changing the program after release, for example to fix faults or adapt it to new conditions.

A question like this tests whether you can recognise a stage from a short description of an activity.

Understanding the Question

You are given five separate development activities and must name the life cycle stage that each one belongs to. The key is to focus on what the activity is trying to achieve:

• gathering requirements points to analysis
• planning structures points to design
• writing code points to coding
• checking correctness points to testing
• changing an existing system after delivery points to maintenance

Approach

For each row, ask: "What is the developer doing here?"

• If they are talking to the client to find out needs, that is analysis.
• If they are deciding how data will be stored or how the program will be structured, that is design.
• If they are writing the actual program, that is coding.
• If they are using a method to check for errors, that is testing.
• If they are altering an existing system to cope with change, that is maintenance.

Step-by-Step Reasoning

1. The walkthrough method is used.
   A walkthrough is a way of checking a proposed or written solution step by step to detect errors. That belongs to testing.

2. An algorithm is implemented in a programming language.
   "Implemented" means turned into actual program statements. That is the coding stage.

3. The client is interviewed about problems with the current system.
   Interviewing the client is done to gather requirements and understand what is wrong now. That is analysis.

4. The program is modified to run on new hardware.
   This means an existing program is being changed after it has already been developed. That is maintenance.

5. Records and file structures are defined.
   Deciding what records exist and how files are organised is part of planning the solution before full coding starts. That is design.

Key Takeaways

• Analysis is about understanding the problem and requirements.
• Design is about planning data, structures and algorithms.
• Coding is writing the program.
• Testing is checking that it works correctly.
• Maintenance is modifying software after release.

Common Mistakes

• Writing design instead of analysis for interviewing the client. Interviewing is about gathering requirements, not planning the solution.
• Writing implementation instead of coding for translating an algorithm into a programming language. In this context, the activity is specifically writing code.
• Writing testing instead of maintenance for modifying software to run on new hardware. The key clue is that the software already exists and is being adapted.
• Confusing records and file structures with coding. These are design decisions made before or alongside coding.

Things to Be Careful About

• Use standard stage names exactly: Analysis, Design, Coding, Testing, Maintenance.
• Read the activity carefully for clue words such as interviewed, implemented, modified, and defined.
• Do not choose a stage based on one familiar keyword alone; think about the purpose of the activity.

Background Concept

An array is often used when one input value needs to match one stored result from a list of possible values. This is called a data-driven approach: the data is stored in a structure, and the program uses an index to retrieve the correct value.

Multiple selection statements, such as long nested IF statements or a large CASE structure, can also solve this kind of problem, but they place the values directly inside the program logic. That usually makes the program longer and harder to change.

For month lengths, an array is a natural fit because month number 1 maps to 31, month number 2 maps to 28, and so on.

Understanding the Question

The question already tells you one advantage: using an array can be faster than checking many selection statements. So you must not repeat speed.

You need two other advantages of using DaysInMonth rather than writing a large set of selection statements such as:

• if month = 1 then 31
• else if month = 2 then 28
• and so on.

The best answers focus on software design benefits such as maintenance, clarity, reduced repetition, or reduced error risk.

Approach

Think about what arrays do well here:

1. They store related values together.
2. They allow the same retrieval method for every case.
3. They separate the data from the decision logic.

Then turn those ideas into practical advantages a programmer or maintainer would care about.

Step-by-Step Reasoning

The month number can be used directly as the array index, so one access gives the correct number of days.

Compared with many selection statements:

• You do not need one separate branch for every month.
• The program is therefore shorter and easier to follow.
• If one stored value changes, you edit the array entry rather than changing the logic structure.
• Because there is less repeated code, there is less opportunity to make mistakes such as missing a month or typing the wrong value in one branch.

So two strong credited points are:

• easier to maintain or amend
• shorter, clearer code with less repetition and fewer logic errors

Key Takeaways

• Arrays are useful when a value can be found by position or index.
• A data-driven solution is often easier to maintain than a long selection-based solution.
• Good answers to comparison questions should avoid repeating a point already given in the question.

Common Mistakes

• Repeating "faster" or "better performance" even though the question already gives that advantage.
• Giving vague answers such as "it is better" without saying why.
• Describing how arrays work instead of stating an actual advantage.

Things to Be Careful About

• The question asks for advantages "for this type of operation", so keep your points relevant to lookup/matching tasks.
• Make sure each point is distinct; for example, "shorter code" and "less repetition" are closely related, so phrase them as one clear advantage rather than trying to count them as two separate points unless you clearly separate readability from maintenance.

Background Concept

A function is used when a program needs to calculate and return a single result. Here, the result is a DATE, so GetDate() must take the inputs, process them, and return the computed use-by date.

This question combines several Paper 2 ideas:

• using parameters in a function
• extracting parts of a date using built-in date functions
• looking up data in an array
• using selection to deal with overflow into the next month or year

The global array DaysInMonth stores how many days each month contains. Because the month number is already in the range 1 to 12, it can be used directly as the index into the array.

The date functions from the insert are intended to avoid manual string processing. Typical helpers are:

• DAY(DateValue)
• MONTH(DateValue)
• YEAR(DateValue)
• SETDATE(Day, Month, Year)

These let you break a date into parts, adjust those parts, then build a new date to return.

Understanding the Question

You must complete the function GetDate(ProductionDate, ShelfLife).

The function must:

• take a production date
• take an integer shelf life
• calculate the corresponding use-by date
• return that new date

You are told to use the date functions from the insert, so the expected method is not string slicing or manual formatting. You should work with day, month and year separately.

The important extra information is that:

• shelf life is always from 1 to 21 inclusive
• leap years are ignored
• DaysInMonth is already available globally

That means February is always 28 days, and the array lookup can be trusted.

Approach

The clean approach is:

1. Extract the day, month and year from ProductionDate.
2. Add ShelfLife to the day.
3. Check whether the new day value is now too large for that month.
4. If it is, subtract the number of days in that month and move to the next month.
5. If moving past December, wrap the month back to January and add 1 to the year.
6. Rebuild the final date and return it.

Because shelf life is at most 21 days, one month adjustment is enough for this question. A more general solution could use a WHILE loop, but an IF is sufficient here and is neatly matched to the given constraints.

Step-by-Step Reasoning

Start by declaring the local variables:

• DayNumber, MonthNumber, YearNumber as INTEGER
• UseByDate as DATE

These hold the date parts while you do the calculation.

Then extract the date parts:

• DayNumber ← DAY(ProductionDate) + ShelfLife
• MonthNumber ← MONTH(ProductionDate)
• YearNumber ← YEAR(ProductionDate)

Notice that the shelf life is added immediately to the day number. For example, if the production date is 25 March and the shelf life is 10, then DayNumber becomes 35.

Now check whether that day value still fits in the original month:

• IF DayNumber > DaysInMonth[MonthNumber] THEN

This is where the array is used. If MonthNumber is 3, DaysInMonth[3] is 31. If DayNumber is 35, then it is too large for March.

If the day is too large:

• subtract the length of the current month
• move to the next month

So:

• DayNumber ← DayNumber - DaysInMonth[MonthNumber]
• MonthNumber ← MonthNumber + 1

Using the example above, 35 in March becomes 4 in April.

Next, handle the special case where the current month was December. After adding 1, the month would become 13, which is invalid. So you must wrap around:

• IF MonthNumber > 12 THEN
• MonthNumber ← 1
• YearNumber ← YearNumber + 1
• ENDIF

This changes dates like late December plus shelf life into the correct January date in the next year.

Finally, rebuild the date and return it:

• UseByDate ← SETDATE(DayNumber, MonthNumber, YearNumber)
• RETURN UseByDate

That completes the function.

Key Takeaways

• Use a function when one calculated value needs to be returned.
• Arrays are very useful for month-length lookup because the month number can act as the index.
• Date arithmetic often works by splitting a date into day, month and year, adjusting them, then rebuilding the final date.
• End-of-month and end-of-year cases must always be checked explicitly.

Common Mistakes

• Forgetting to return a DATE at the end of the function.
• Adding the shelf life but not checking whether the day now exceeds the month length.
• Incrementing the month without handling December rolling over to January.
• Using = instead of the assignment arrow ← in pseudocode.
• Writing the answer in a real programming language instead of CIE pseudocode.
• Ignoring the given DaysInMonth array and hard-coding month lengths with many IF statements.

Things to Be Careful About

• DaysInMonth is indexed from 1 for January, so use the month number directly as given.
• Leap years are not considered, so February must remain 28 days.
• Keep the function name and parameter names exactly as shown: GetDate(ProductionDate : DATE, ShelfLife : INTEGER).
• Make sure the year only changes when the month moves past 12.
• The insert's date functions should be used exactly as required by the paper.
• Even though a WHILE loop is a more general approach, this question's limit of 21 days means a single IF adjustment is sufficient and efficient.

Background Concept

A structure chart shows the modular structure of a program. Each rectangle is a module, and the lines show which module calls which other module.

Important ideas used here are:

• A procedure performs a task but does not return a function value.
• A function returns a value.
• A data couple shows data being passed between modules.
• A control couple shows a control flag or decision value being passed.
• A selection symbol shows that one of several modules is chosen at run-time.
• An iteration symbol shows that one or more module calls are repeated.
• A BYVAL parameter is passed in only.
• A BYREF parameter can be changed by the called module and the changed value is available to the caller.

So, when reading module headers, you should look for:

• the module names
• whether they are procedures or functions
• their parameters
• whether a value is returned
• whether any parameter is BYREF

Understanding the Question

You are given six module headers and an incomplete structure chart. You must fill in the missing module names and the missing parameter/return labels so that the chart matches the headers.

The key clue is this sentence:

• Connect() will call either Activate() or Sync() at run-time.

That immediately tells you that Connect is the top module and there must be a selection between Activate and Sync underneath it.

You then use the remaining headers to decide:

• which module goes on the left and which goes on the right
• which lower-level modules belong under each one
• which arrows carry parameters downwards
• which arrows carry returned values or BYREF values upwards

Approach

A good method is:

1. Put the top-level caller first.
2. Use the question statement to place the two alternative modules directly below it.
3. Match each incomplete branch to the header that fits its shape.
4. Use the parameter names from the headers to label the arrows.
5. Use function return types and BYREF parameters to decide which arrows go back up.
6. Add the special symbols already implied by the chart: selection at the top and iteration lower down.

The incomplete chart already helps a lot:

• the left middle module has two children, so it must be the module that calls two others
• the right middle module has one child and a two-way connection, which matches a procedure with a BYREF parameter

Step-by-Step Reasoning

Start with the top module:

• Connect() is already at the top.

Now use the statement "either Activate() or Sync()":

• directly below Connect, place Sync on one branch and Activate on the other
• add the selection symbol under Connect because only one of these two is called at run-time

Decide which side is which:

• the left middle box must be Sync because it has two child modules beneath it
• the right middle box must be Activate because it has only one child beneath it

Label the Connect to Sync branch:

• Sync(T1 : BOOLEAN, S2 : REAL) RETURNS INTEGER
• so T1 and S2 must go from Connect down to Sync
• Sync also returns an integer back up to Connect

Label the Connect to Activate branch:

• Activate(H1 : STRING, Code : INTEGER) RETURNS BOOLEAN
• so H1 and Code go from Connect down to Activate
• Activate returns a Boolean value back up to Connect

Now fill the modules below Sync:

• the two remaining functions that sensibly fit here are Reset and Enable
• so the lower left box is Reset
• the lower middle box is Enable

Add their parameter/return links:

• Reset(RA : STRING) RETURNS INTEGER
  • RA goes down from Sync to Reset
  • the integer return value goes back up from Reset to Sync
• Enable(SA : INTEGER) RETURNS BOOLEAN
  • SA goes down from Sync to Enable
  • the Boolean return value goes back up from Enable to Sync

The curved loop under Sync means these lower calls are repeated, so keep the iteration symbol across those child calls.

Now fill the module below Activate:

• the only remaining module is Initialise
• so the lower right box is Initialise

Add its parameter links using the header:

• Initialise(BYREF ID : INTEGER, BYVAL CC : INTEGER)
• CC is BYVAL, so it is passed down from Activate to Initialise
• ID is BYREF, so it is passed to Initialise and the updated value is available back in Activate
• that is why the chart shows a two-way vertical data flow for ID

This completes the structure chart consistently with all six headers.

Key Takeaways

• Read structure charts from the top module downwards.
• Use the module header to determine parameters and return values.
• A function returns a value; a procedure does not.
• A BYREF parameter must allow the changed value to be available to the caller.
• Selection means one branch is chosen; iteration means calls are repeated.

Common Mistakes

• Putting Activate and Sync under the wrong parent. They must both be called by Connect.
• Forgetting the selection symbol between Sync and Activate. The question explicitly says either one is called at run-time.
• Treating Initialise like a function return. It is a procedure, so there is no function result.
• Forgetting that ID is BYREF. That value must be shown as available back to the caller.
• Omitting return arrows for functions such as Reset, Enable, Sync or Activate.

Things to Be Careful About

• Use the module names exactly as given: Connect, Sync, Activate, Reset, Enable, Initialise.
• Match parameter names exactly: T1, S2, H1, Code, RA, SA, CC, ID.
• Do not invent extra modules or extra parameters.
• Keep the hierarchy correct: Reset and Enable are below Sync; Initialise is below Activate.
• Distinguish carefully between a returned function value and a changed BYREF parameter.

Background Concept

In a structure chart, special symbols show how modules are called.

One important symbol is the iteration symbol. This means a module call, or a group of module calls, is repeated in a loop rather than being executed just once.

This is different from:

• sequence: modules are called in order once
• selection: one of several alternatives is chosen

So if you see the curved loop-like symbol across module connections, it means repeated execution.

Understanding the Question

The question asks for the meaning of the curved arrow symbol shown in the structure chart from part (a).

In that diagram, the curved symbol appears around the calls from one module to lower modules. You are not being asked to redraw anything, only to explain what that symbol means.

Approach

To answer this, name the symbol first, then explain its effect on program flow.

A complete answer should say:

1. it means iteration or repetition
2. the module or modules under that symbol are called repeatedly, not just once

Step-by-Step Reasoning

The curved symbol in a structure chart is used to show looping behaviour.

So the first marking point is:

• it represents iteration

Then explain what iteration means in this context:

• the subordinate module calls are repeated
• they may be called several times until some condition causes the loop to stop

That is enough for full credit.

Key Takeaways

• A curved loop symbol in a structure chart means iteration.
• Iteration means one or more lower-level modules are called repeatedly.
• Do not confuse iteration with selection.

Common Mistakes

• Saying it means selection. Selection is choosing one branch from alternatives, not repeating calls.
• Saying it just means "the modules are connected". The question asks for the special meaning of the symbol.
• Describing the order of execution without mentioning repetition.

Things to Be Careful About

• Use the term iteration or repetition explicitly.
• Make clear that the lower module calls can happen more than once.
• Do not mix this up with the decision/selection symbol used where one of two modules is chosen.

Background Concept

A function is used when a module must return a single value. Here, CheckMark() returns a Boolean value: TRUE if the mark is close enough to any grade boundary, otherwise FALSE.

The key idea is an inclusive range check. If a boundary is, for example, 43, then marks from 41 to 45 inclusive are within 2 marks of that boundary. In general, for any boundary value B, the valid range is from B - 2 to B + 2.

Because there are exactly five grade boundaries, a simple count-controlled loop is a good solution. Each boundary is stored in the global array GradeBoundary, so the function can inspect each one in turn.

Understanding the Question

The question gives you:

• a global 1D integer array GradeBoundary[1..5]
• one candidate mark passed into the module
• the rule that a paper must be checked if its mark is within 2 marks of any boundary

You are asked to write pseudocode for CheckMark() only. That means this module must:

• take one integer parameter
• compare it with all five boundaries
• return TRUE if any comparison matches
• return FALSE if none match

It does not need to work out the actual grade letter. It only decides whether the mark is near a boundary.

Approach

The simplest method is:

1. Look at each of the five boundaries in turn.
2. For each one, test whether the mark is between boundary - 2 and boundary + 2 inclusive.
3. If that condition is true for any boundary, return TRUE immediately.
4. If the loop finishes without finding any match, return FALSE.

Returning immediately is efficient because once one matching boundary has been found, there is no need to keep checking.

Step-by-Step Reasoning

The function header must show that:

• the module name is CheckMark
• it has one parameter, CandidateMark, of type integer
• it returns a Boolean value

So the header is:

FUNCTION CheckMark(BYVAL CandidateMark : INTEGER) RETURNS BOOLEAN

A loop variable is needed, so we declare Boundary as an integer.

DECLARE Boundary : INTEGER

There are five boundaries, so the loop runs from 1 to 5.

FOR Boundary ← 1 TO 5

Inside the loop, compare the candidate mark with the current boundary. The condition must be inclusive, because marks exactly 2 below or 2 above still count.

IF CandidateMark >= GradeBoundary[Boundary] - 2 AND CandidateMark <= GradeBoundary[Boundary] + 2 THEN

If this is true, the function can immediately return TRUE.

RETURN TRUE

If the loop finishes and no boundary matched, the mark is not within 2 of any boundary, so the function returns FALSE.

RETURN FALSE

This gives the correct Boolean result for every mark.

Key Takeaways

• Use a function when a module must return one value.
• A mark is within 2 of a boundary if it lies in the inclusive range boundary - 2 to boundary + 2.
• A count-controlled loop is suitable when the number of items is known in advance.
• Returning as soon as a match is found is a standard and efficient pattern.

Common Mistakes

• Using OR instead of AND in the range check. A value must satisfy both limits, not just one.
• Forgetting the range is inclusive. Marks exactly 2 away must still count.
• Checking only one boundary instead of all five.
• Writing a procedure instead of a function, even though the module must return TRUE or FALSE.
• Returning a grade letter such as A or B, which is not what the module is supposed to do.

Things to Be Careful About

• The array is indexed from 1 to 5 in the question's example, so the loop bounds must match that.
• GradeBoundary is global, so it does not need to be passed as a parameter.
• Use the assignment arrow ← only for assignment; use comparison operators inside the IF condition.
• Keep the module name and identifier casing exactly as given: CheckMark and GradeBoundary.

Background Concept

A procedure is used when a module performs actions rather than returning a single value. In this question, CheckAll() does several actions:

• processes all candidate records
• uses another module, CheckMark(), to test each mark
• writes certain candidate IDs to a file
• counts how many papers need checking
• outputs a message

The Result array is 2D:

• column 1 stores the mark
• column 2 stores the candidate ID

Because the array has unused rows at the end, the procedure must not scan the whole array blindly. It must only process the number of actual candidates passed in as a parameter.

For file handling, opening a file FOR WRITE creates a new output file for this task. Each time a candidate needs checking, the corresponding ID is written to the file.

Understanding the Question

The question asks for pseudocode for CheckAll().

You are told that this module:

• receives the number of candidate marks in Result
• must use CheckMark() for each mark
• must write each relevant candidate ID to a new file called GRList.txt
• must output how many papers need to be checked

Important clues from the stem:

• only the first NumberCandidates rows are valid
• Result[Row, 1] is the mark
• Result[Row, 2] is the candidate ID
• the file required here is a new file, so write mode is appropriate

Approach

The overall pattern is:

1. Open GRList.txt for writing.
2. Set a counter to 0.
3. Loop through rows 1 to NumberCandidates.
4. For each row, pass the mark from column 1 into CheckMark().
5. If CheckMark() returns TRUE, write the ID from column 2 to the file and increase the counter.
6. After the loop, close the file.
7. Output the counter in a message.

This uses modular design correctly because CheckAll() does not repeat the boundary-checking logic; it delegates that task to CheckMark().

Step-by-Step Reasoning

The header must define CheckAll() as a procedure with one integer parameter.

PROCEDURE CheckAll(BYVAL NumberCandidates : INTEGER)

We need:

• Row to move through the array
• Count to record how many papers need checking

So both are declared as integers.

DECLARE Row, Count : INTEGER

The counter starts at 0 because no papers have been identified yet.

Count ← 0

The file must be created as a new file named GRList.txt, so it is opened for writing.

OPENFILE "GRList.txt" FOR WRITE

Now loop through the valid candidate rows only.

FOR Row ← 1 TO NumberCandidates

The mark is stored in column 1, so that is the value passed to CheckMark().

IF CheckMark(Result[Row, 1]) = TRUE THEN

If the function says the paper needs checking, write the candidate ID from column 2 to the file.

WRITEFILE "GRList.txt", Result[Row, 2]

Then increment the count.

Count ← Count + 1

After all rows are processed, close the file.

CLOSEFILE "GRList.txt"

Finally, output a message containing the number of papers needing checks.

OUTPUT Count, " papers need to be checked"

This satisfies every requirement in the question:

• it uses CheckMark()
• it writes only candidate IDs, not marks
• it writes one ID for each flagged paper
• it counts them
• it outputs the count

Key Takeaways

• Use a procedure when a module performs actions rather than returning one value.
• When a 2D array stores different fields in different columns, read the correct column for each task.
• If unused rows exist, loop only over the valid row count provided.
• File handling usually follows the pattern: open, write/read inside a loop, then close.
• A counter accumulator must be initialised before the loop and updated only when the condition is met.

Common Mistakes

• Looping through every row in the array instead of only the first NumberCandidates rows.
• Writing Result[Row, 1] to the file instead of Result[Row, 2], which would write marks instead of IDs.
• Rewriting the boundary logic inside CheckAll() instead of calling CheckMark() as required.
• Forgetting to increment the counter when a paper is written to the file.
• Forgetting to close the file after finishing.
• Opening the file for read mode or append mode when this part specifically asks for a new file.

Things to Be Careful About

• Column 1 is the mark; column 2 is the candidate ID. Mixing these up loses marks.
• The parameter is the number of candidates, not the maximum possible size of the array.
• Count ← 0 must come before the loop.
• The WRITEFILE statement should be inside the IF block, not outside it.
• Keep the file name exactly as GRList.txt.
• Since this is Paper 2, the answer must be in CIE pseudocode, not a real programming language.

Background Concept

When writing to a text file, the file mode matters:

• WRITE creates a new output file or overwrites the existing contents.
• APPEND keeps the existing contents and adds new data at the end.

So the difference is whether old data is preserved.

Understanding the Question

In part (b), the file was supposed to be a new file, so WRITE was correct.

In this part, the requirement changes: the file already exists, and the new candidate IDs must be added to it. That means the old contents must not be lost.

So the question is really asking: what one change is needed so the program adds data to an existing file instead of replacing it?

Approach

The only required change is to alter the file-opening mode.

Where CheckAll() previously opened GRList.txt for writing, it must now open it for appending. The rest of the logic can stay the same.

Step-by-Step Reasoning

In part (b), the file statement would have been something like:

OPENFILE "GRList.txt" FOR WRITE

If that remains unchanged, the existing contents of the file could be overwritten.

To keep the existing file data and add more candidate IDs after it, the open mode must become append mode:

OPENFILE "GRList.txt" FOR APPEND

That is the change the examiner is looking for.

Key Takeaways

• WRITE is for creating a new output file or replacing contents.
• APPEND is for adding data to the end of an existing file.
• Small wording changes in a question can require a specific change in file mode.

Common Mistakes

• Saying only that the file should be opened, without stating the new mode.
• Using WRITE, which would risk deleting existing contents.
• Using READ, which would not allow the program to add data.

Things to Be Careful About

• The key point is not just that the file exists, but that its current contents must be preserved.
• For a 1-mark explain question, the answer must be precise: mention append mode and why it is needed.
• Do not suggest rewriting the whole procedure; only the file-opening method needs to change.