Computer Science 9618/23 — October/November 2025

Background Concept

A library routine is a pre-written piece of code that a programmer can use instead of creating that functionality themselves. Libraries are useful because they provide routines that are already available, usually standardised, and often written by experienced developers.

In programming, reuse is important. If a routine already exists and is suitable, using it can improve efficiency in development and reduce the amount of new code that needs to be created.

Understanding the Question

The question already gives one benefit: a library routine may perform a function the programmer cannot write themselves. You must not repeat that idea. Instead, you need three different benefits of using library routines while developing this encryption program.

So the task is pure theory recall: list three valid advantages other than the one already stated.

Approach

Think about what happens when code is reused instead of written from scratch:

1. development is faster
2. reliability is better because the code is already tested
3. support such as documentation and maintenance is usually better

Any three distinct benefits along these lines are suitable.

Step-by-Step Reasoning

A good first point is about time. If a routine is already available, the programmer does not need to design and code that part from the beginning. That reduces development time.

A strong second point is about correctness. Library routines are usually used by many people and have already been tested and debugged. That means they are less likely to contain errors than brand-new code written under exam conditions or time pressure.

A good third point is about maintenance and support. Many library routines come with documentation, version updates, and sometimes vendor support. That makes them easier to understand, use correctly, and maintain in the future.

These are all different from the given point about the programmer being unable to write the routine themselves.

Key Takeaways

• Library routines save time because code is reused.
• Pre-tested code is usually more reliable.
• Standard library code is often easier to maintain because it is documented and supported.

Common Mistakes

• Repeating the benefit already given in the question. That would not gain credit.
• Giving the same idea twice, such as "saves time" and "faster to develop" as separate points.
• Writing vague answers like "it is better" without saying why it is better.

Things to Be Careful About

• Make sure each benefit is distinct.
• Keep answers specific to software development benefits, not general comments about encryption.
• Short, clear statements are enough; long explanations are not needed in the exam.

Background Concept

This question tests evaluation of expressions using built-in functions. A built-in function is a standard routine provided by the language or pseudocode system.

The key functions here are:

• NUM_TO_STR(x) converts a number to a string
• LENGTH(s) returns the number of characters in a string
• MONTH(date) extracts the month number from a date
• MID(s, start, length) returns part of a string
• STR_TO_NUM(s) converts a numeric string into a number

In CIE pseudocode, string positions are counted from 1, not 0.

Understanding the Question

You are given three variables and example values:

• DoB = 23/6/2011
• Multiplier = 2.5
• AddressLine[1] = "35 Lincoln Avenue"

You must substitute those values into each expression and work out the final result exactly.

This is not about writing code. It is about reading each function carefully and evaluating from the inside out.

Approach

For each expression:

1. replace the variable with its given value
2. evaluate the innermost function first
3. continue outward until the whole expression becomes a final value

That is especially important when functions are nested, such as LENGTH(NUM_TO_STR(Multiplier)) and STR_TO_NUM(MID(AddressLine[1], 2, 1)).

Step-by-Step Reasoning

First expression: LENGTH(NUM_TO_STR(Multiplier))

Replace Multiplier with 2.5.

NUM_TO_STR(2.5) converts the number into the string "2.5".

Now apply LENGTH.

The string "2.5" has three characters:

• 2
• .
• 5

So the result is 3.

Second expression: MONTH(DoB) > 4

Replace DoB with 23/6/2011.

MONTH(23/6/2011) extracts the month part, which is 6.

Now compare: 6 > 4.

That statement is true, so the expression evaluates to TRUE.

Third expression: 15 + STR_TO_NUM(MID(AddressLine[1], 2, 1))

Replace AddressLine[1] with "35 Lincoln Avenue".

Now evaluate the innermost function:

MID("35 Lincoln Avenue", 2, 1) means start at position 2 and take 1 character.

Because positions start at 1:

• position 1 is 3
• position 2 is 5

So the substring returned is "5".

Next, STR_TO_NUM("5") converts the string into the number 5.

Finally, calculate 15 + 5 = 20.

So the three answers are 3, TRUE, and 20.

Key Takeaways

• Evaluate nested functions from the inside outward.
• LENGTH counts characters in a string, including symbols like the decimal point.
• MONTH returns the month number from a date.
• MID uses 1-based indexing in CIE pseudocode.
• STR_TO_NUM changes a numeric string into a number so arithmetic can be performed.

Common Mistakes

• Forgetting that the decimal point in "2.5" counts as a character.
• Writing 6 instead of TRUE for the comparison MONTH(DoB) > 4.
• Using 0-based indexing for MID, which would pick the wrong character.
• Forgetting to convert "5" into the number 5 before adding to 15.

Things to Be Careful About

• Keep strings and numbers separate: "5" is not the same as 5.
• For Boolean expressions, give TRUE or FALSE, not just the extracted value.
• Read MID(string, start, length) carefully: the third value is how many characters to take, not the finishing position.
• Use the exact example values given rather than making assumptions about other formats.

Background Concept

Stepwise refinement means taking a complete problem and breaking it into smaller, clearer actions until each action is simple enough to turn into pseudocode directly. Instead of writing code immediately, you first describe the algorithm at a high level.

For this question, the important ideas are:

• there is a 1D array with 65 STRING elements
• the data must be stored in a text file
• only non-blank elements are written
• each written element must go on its own line

A good refined algorithm usually includes:

• preparation steps, such as opening a file
• processing steps, such as visiting each array element
• decision steps, such as checking whether an element is blank
• finishing steps, such as closing the file

Because the question says not to use pseudocode statements, the answer should be written as plain English actions, not with keywords like IF, FOR, or WHILE.

Understanding the Question

You are not being asked to write the final pseudocode yet. You are being asked to describe sensible intermediate steps that could later be converted into pseudocode.

The given information tells you:

• the array is global, so it already exists
• it has 65 elements, so all 65 positions must be considered
• blank elements contain the empty string and must not be written
• the output file already exists, but it still needs to be opened before writing
• every item written must appear on a separate line

So the algorithm must do more than just loop through the array. It must also make a decision about each element and handle the file correctly.

Approach

A sensible refinement for this task is:

1. prepare the file
2. begin at the first array element
3. inspect the current element
4. write it only if it is not blank
5. move on and repeat for the rest of the array
6. finish by closing the file

This matches the structure of the actual program that would later be written in pseudocode:

• sequence for setup and finish
• iteration for visiting all 65 elements
• selection for deciding whether to write the current value

Step-by-Step Reasoning

A strong answer should describe the task in ordered stages.

Step 1: Open the text file ready for writing

Before any data can be stored, the file must be opened. This is one of the setup actions.

Step 2: Start at the first element of the array

The algorithm needs a way to know which element is currently being processed. In plain English, this can be described as starting at the first element.

Step 3: Check whether the current element is blank or non-blank

This is essential because the question states that only non-blank elements are written to the file. So each element must be tested.

Step 4: If it is non-blank, write it to the text file on a new line

This step explains exactly what happens when the condition is satisfied. The reference to a new line is important because the question says each element must be written on a separate line.

Step 5: Move to the next element and repeat until all 65 elements have been processed

This is the iteration part. The algorithm must continue through the whole array, not stop after the first item. Even blank elements must still be checked, although they are skipped rather than written.

Step 6: Close the text file

After all elements have been processed, the file should be closed properly.

Other wording could still gain marks if it expresses the same logic clearly. For example, “continue until the end of the array” is acceptable if it clearly means all 65 elements are processed.

Key Takeaways

• Stepwise refinement breaks a problem into clear, manageable actions before pseudocode is written.
• A file-processing algorithm usually has setup, processing and finishing stages.
• When only some data items should be written, the algorithm needs a decision step.
• When every array element must be checked, the algorithm needs repetition.

Common Mistakes

• Writing pseudocode instead of describing steps: the question explicitly says not to use pseudocode statements.
• Forgetting the blank-element check: this misses the rule that only non-blank strings are written.
• Not mentioning movement through the array: the algorithm must process all 65 elements, not just the first one.
• Forgetting to close the file: file handling normally includes both opening and closing.
• Saying all elements are written: blank elements should be skipped.

Things to Be Careful About

• Make sure the answer is in plain English, not formal pseudocode.
• Mention that each written item goes on a new line.
• Show that all 65 elements are considered.
• Distinguish between checking an element and writing an element; every element is checked, but only non-blank ones are written.
• Keep the steps in a logical order: open first, process next, close last.

Background Concept

The three basic programming constructs are:

• sequence: statements happen one after another in order
• selection: the program chooses between alternatives depending on a condition
• iteration: a set of statements is repeated

The question already names iteration, because the algorithm must go through many array elements. The other construct that is clearly needed here is selection, because the program must decide whether each element should be written.

Selection is typically used when a condition is either true or false. In this case, the condition is whether the current array element is blank.

Understanding the Question

The question asks for one programming construct other than iteration and then asks how it is used in this specific algorithm.

The key clue is the sentence:

• only non-blank elements are written to the text file

That means the program cannot write every element automatically. It must check each one first. That checking-and-deciding is selection.

Approach

Look for a place in the algorithm where the program has to make a decision.

Here, for each array element, the algorithm must decide:

• if the element is not empty, write it
• otherwise, do not write it

That is exactly what selection does, so the correct answer is to name selection and explain that it controls whether the current element is written or skipped.

Step-by-Step Reasoning

Why is iteration not enough on its own?

Iteration only lets the program repeat actions for all 65 elements. If the program only had iteration, it would process every element in turn, but it would still need a way to choose whether to write the current one.

That choice is made using selection.

For each element:

1. the loop reaches the current array position
2. the program checks whether that element is blank
3. if it is non-blank, it is written to the file
4. if it is blank, nothing is written and the loop continues

So the selection construct is used inside the repeated processing of the array.

Although sequence is also present in any algorithm, it is not the best answer here because the question asks for a construct that will be required, and the blank/non-blank rule makes selection the clear required one.

Key Takeaways

• Use iteration when you must process many items.
• Use selection when you must decide whether an action should happen.
• In array-processing questions, iteration and selection are often used together.
• A condition such as “only non-blank elements” is a strong clue that selection is needed.

Common Mistakes

• Answering sequence: sequence exists in all algorithms, but it does not address the specific need to test for blank values.
• Naming selection without explaining its use: the question needs both the construct and its role.
• Saying selection chooses the next array element: iteration controls movement through the array, not selection.
• Forgetting the empty-string condition: the explanation should refer to blank versus non-blank elements.

Things to Be Careful About

• The construct must be one of the standard programming constructs.
• The explanation should be tied directly to this algorithm, not just a generic definition.
• Make clear that selection is used to decide whether to write or skip the current element.
• Do not confuse the loop that visits all elements with the condition that filters out blank ones.

Background Concept

A trace table is used to dry run an algorithm without executing it on a computer. You follow the pseudocode line by line and record the values of important variables after each significant change. In this question, the key features are:

• a WHILE loop, so the condition Count <= 20 must be checked before each iteration
• a CASE OF selection, so the value stored in CaseVar determines which clause runs
• a 1D array Num, so Num[Index] means "look at the element whose position is given by Index"
• modular arithmetic in Index ← (Index MOD 4) + 1, which wraps the index around the four-element array

The MOD operator gives the remainder after division. For example:

• 2 MOD 4 = 2
• 3 MOD 4 = 3
• 4 MOD 4 = 0
• 7 MOD 4 = 3

So adding 1 after MOD 4 makes the index cycle through values 1 to 4.

Understanding the Question

You are given the starting contents of the global array:

• Num[1] = 1
• Num[2] = 2
• Num[3] = 5
• Num[4] = 3

The procedure is called with CALL Process(1), so the parameter Start is 1. That means Index begins at 1.

You must complete the trace table by following exactly what happens as the procedure runs. The important things to watch are:

• which CASE clause is chosen from the current Num[Index]
• how Num[Index] may change
• how Index changes twice in each loop iteration: once inside the chosen clause, then again at the end with MOD
• how Count changes, because it controls when the loop stops

Approach

The safest approach is:

1. Write down the initial values of Index, Count, and the whole Num array.
2. At the start of each loop, find CaseVar ← Num[Index].
3. Choose the correct CASE clause.
4. Apply every assignment in that clause in order.
5. Then apply the final line Index ← (Index MOD 4) + 1.
6. Repeat until Count becomes greater than 20.

A common reason students lose marks here is forgetting that the Index is changed inside the clause and then changed again afterwards by the MOD line.

Step-by-Step Reasoning

Start of procedure:

• Index ← Start, so Index = 1
• Count ← 0
• Num = [1, 2, 5, 3]

This gives the first row of the trace table.

First loop iteration

Check condition:

• Count <= 20 gives 0 <= 20, so the loop runs.

Set case variable:

• CaseVar ← Num[Index] = Num[1] = 1

CaseVar = 1, so clause one runs:

• Num[Index] ← Num[Index] + Index becomes Num[1] ← 1 + 1 = 2
• Index ← Index + 1 gives Index = 2
• Count ← Count + 1 gives Count = 1

Now apply the line after the CASE:

• Index ← (Index MOD 4) + 1
• Index ← (2 MOD 4) + 1 = 2 + 1 = 3

Second loop iteration

Check condition:

• 1 <= 20, so continue.

Set case variable:

• CaseVar ← Num[3] = 5

There is no clause for 5, so OTHERWISE runs:

• Count ← 20

The array does not change here.

Now update index:

• Index ← (3 MOD 4) + 1 = 3 + 1 = 4

Third loop iteration

Check condition:

• 20 <= 20, so the loop still runs.

Set case variable:

• CaseVar ← Num[4] = 3

CaseVar = 3, so clause three runs:

• Num[4] ← Num[4] * 2 = 3 * 2 = 6
• Index ← Index + 3 = 4 + 3 = 7
• Count ← Count - 1 = 20 - 1 = 19

Now update index:

• Index ← (7 MOD 4) + 1 = 3 + 1 = 4

Notice that even though Index temporarily became 7, the final MOD line wraps it back into the 1 to 4 range.

Fourth loop iteration

Check condition:

• 19 <= 20, so continue.

Set case variable:

• CaseVar ← Num[4] = 6

There is no clause for 6, so OTHERWISE runs:

• Count ← 20

Update index:

• Index ← (4 MOD 4) + 1 = 0 + 1 = 1

Fifth loop iteration

Check condition:

• 20 <= 20, so continue.

Set case variable:

• CaseVar ← Num[1] = 2

CaseVar = 2, so clause two runs:

• Num[1] ← Num[1] + Index = 2 + 1 = 3
• Index ← Index + 2 = 1 + 2 = 3
• Count ← Count + 2 = 20 + 2 = 22

Update index:

• Index ← (3 MOD 4) + 1 = 3 + 1 = 4

Loop ends

Now test the condition again:

• 22 <= 20 is false
• the loop stops

So the final trace table entries are exactly those shown in the answer.

Key Takeaways

• In a trace table, follow the pseudocode in the exact order written.
• For a CASE statement, the current value of the selector variable decides the clause.
• Array elements can change during the trace, so later CaseVar values may be different from the originals.
• MOD is often used to wrap an index around a fixed-size array.
• In a WHILE loop, the condition is checked before each iteration.

Common Mistakes

• Forgetting to update Num[Index] before changing Index. The order matters.
• Ignoring the final line Index ← (Index MOD 4) + 1. This causes the later rows to be wrong.
• Treating OTHERWISE as if nothing happens. It does change Count to 20.
• Stopping when Count = 20. The loop condition is Count <= 20, so 20 still allows one more iteration.
• Using the old value of Num[4] after clause three. Once clause three runs, Num[4] becomes 6.

Things to Be Careful About

• The array is 1-indexed, not 0-indexed.
• Index may briefly become a value like 7 inside a clause, but the final MOD statement brings it back into range.
• CaseVar is taken from the array before any clause code runs in that iteration.
• Count can increase or decrease depending on the clause.
• In trace tables, examiners often accept blanks for unchanged values, but the changes must appear in the correct rows and columns.

Background Concept

A test plan is a set of chosen inputs together with the expected outputs and the reason for choosing each one. In Paper 2, a good test plan usually shows coverage of different categories of data, especially normal data and boundary data. If the question says to assume the parameter is valid, then you do not need erroneous or abnormal inputs.

For this function, the output is a single check digit. The check digit is found by adding all digits of the original number and taking the remainder when that total is divided by 10. So the tests should cover different kinds of totals and the valid size limit given in the question.

Understanding the Question

The function Generate() takes an original number and returns the check digit only. You are asked to outline a test plan to fully test that function.

The key clues are:

• the original number is always valid
• the original number is always at least 3 digits long
• the function returns a check digit from 0 to 9

So you should not test invalid inputs such as letters or 2-digit numbers. Instead, you should choose valid cases that exercise the important situations in the calculation.

Approach

A sensible full test plan here is to include:

• a valid boundary case at the minimum length
• a normal case where the digit sum is less than 10
• a case where the check digit is 0
• a case where the digit sum is greater than 10, so the remainder idea is definitely being tested

For each test, you should give the original number, work out the expected check digit, and state why that test is useful.

Step-by-Step Reasoning

100 is the smallest valid original number because the question says the original number is at least three digits. Its digit sum is 1 + 0 + 0 = 1, so the expected check digit is 1.

123 is a straightforward normal case. Its digit sum is 1 + 2 + 3 = 6, so the expected check digit is 6. This checks that the function works in a simple case where no wrap-around from dividing by 10 is needed.

190 gives a useful case where the result should be 0. Its digit sum is 1 + 9 + 0 = 10, and the remainder when dividing by 10 is 0. This is worth testing because 0 is an output boundary and is sometimes mishandled.

999 checks a case where the digit sum is greater than 10. The sum is 9 + 9 + 9 = 27, so the expected check digit is 7. This confirms that the function is using the remainder, not the whole total.

Other equivalent valid test plans could also score well, provided they clearly cover the key situations and include expected results.

Key Takeaways

• A test plan should include input, expected output, and reason.
• If the question restricts inputs to valid data, do not waste marks on abnormal cases.
• Good tests cover boundaries and different behaviours of the algorithm, not just random values.
• For this algorithm, important behaviours are minimum valid length, totals below 10, totals above 10, and a remainder of 0.

Common Mistakes

• Giving invalid test data even though the question says the parameter is valid.
• Listing test inputs without the expected check digits.
• Choosing several tests that all behave in the same way, so the function is not fully exercised.
• Forgetting that the minimum valid original number is 3 digits.
• Confusing the check digit with the full new number after appending it.

Things to Be Careful About

• Make sure every expected result is calculated correctly from the sum of digits.
• Use the original number as the test input, not the new number with the check digit already appended.
• Include at least one valid boundary case based on the information in the question.
• A result of 0 is important to test because it is a valid check digit and a common edge case.

Background Concept

A check digit is an extra digit added to data so that the data can later be checked for correctness. Validation works by separating the stored check digit from the original value, recalculating what the check digit should be, and comparing the two.

In pseudocode, two operators are especially useful here:

• MOD 10 gives the last digit of an integer
• DIV 10 removes the last digit of an integer

For example, if the new number is 41623:

• 41623 MOD 10 gives 3, which is the stored check digit
• 41623 DIV 10 gives 4162, which is the original number

A function returns a single value. Here, CheckNumber() must return TRUE or FALSE, so it is naturally written as a Boolean function.

Understanding the Question

You are given that a function Generate() already exists and returns the correct check digit for an original number. Your task is to write a second function, CheckNumber(), which takes the full new number, including its appended check digit, and decides whether that final digit is correct.

The question says the input parameter is valid, so you do not need extra validation for data type or length. The important task is the logic:

1. separate the final digit from the rest of the number
2. generate the correct check digit from the original part
3. compare the two digits
4. return TRUE if they match, otherwise FALSE

Approach

The cleanest method is to reuse Generate() rather than rewriting the digit-summing process inside CheckNumber(). That is good decomposition: one function generates a check digit, and the other function uses it for validation.

So the algorithm is:

• take the last digit as the given check digit
• remove the last digit to recover the original number
• call Generate() on the original number
• compare the calculated check digit with the given one
• return the Boolean result

Step-by-Step Reasoning

Start by declaring the local integer variables needed:

• OriginalNumber
• GivenCheckDigit
• CalculatedCheckDigit

Next, extract the check digit already stored in the input number:

• GivenCheckDigit ← NewNumber MOD 10
  This works because the check digit was appended to the end.

Then remove that last digit to recover the original number:

• OriginalNumber ← NewNumber DIV 10
  Integer division by 10 discards the final digit.

Now calculate what the check digit should be:

• CalculatedCheckDigit ← Generate(OriginalNumber)
  This reuses the function described earlier in the question.

Finally, compare the two digits:

• if GivenCheckDigit = CalculatedCheckDigit, return TRUE
• otherwise return FALSE

Using the example 41623:

• GivenCheckDigit ← 41623 MOD 10 = 3
• OriginalNumber ← 41623 DIV 10 = 4162
• Generate(4162) returns 3
• 3 = 3, so the function returns TRUE

If the number were 41624 instead:

• GivenCheckDigit = 4
• OriginalNumber = 4162
• Generate(4162) = 3
• 4 ≠ 3, so the function returns FALSE

That is exactly the validation process the question requires.

Key Takeaways

• MOD 10 is the standard way to get the last digit of an integer.
• DIV 10 is the standard way to remove the last digit.
• A Boolean function should return TRUE or FALSE directly from the comparison logic.
• Reusing Generate() is a good example of modular design and decomposition.

Common Mistakes

• Using DIV 10 when you mean MOD 10, or vice versa.
• Comparing the full number with the generated check digit instead of comparing just the last digit.
• Recalculating from the full new number without removing the appended check digit first.
• Writing a procedure instead of a function, even though a Boolean value must be returned.
• Using = for assignment instead of the pseudocode assignment arrow ←.

Things to Be Careful About

• The check digit is the final digit only, so it must be extracted before anything else.
• The original number must exclude the check digit before being passed to Generate().
• Keep the parameter and variable names consistent throughout the pseudocode.
• Because the question assumes a valid parameter, no extra error handling is needed here.
• Use correct CIE pseudocode syntax: FUNCTION ... RETURNS BOOLEAN, declared variables, IF ... THEN ... ELSE ... ENDIF, and explicit RETURN statements.

Background Concept

A state-transition diagram shows how a system moves between states when particular inputs occur. Each state is drawn as a circle. A directed arrow shows a change from one state to another. The label on the arrow shows what input causes that transition, and if the system produces an output at the same time, that output is written on the same arrow.

A self-loop means the system stays in the same state after receiving that input. A start arrow shows the state where processing begins.

This is a visual form of the same information held in a state table. So the skill being tested is converting from table form to diagram form without losing any transitions.

Understanding the Question

You are given a transition table with four pieces of information in each row:

• current state
• input
• output
• next state

You must complete the incomplete state-transition diagram so that it matches that table. The positions of some circles and one self-loop are already drawn in the figure, so the task is mainly to place the correct state names on the blank circles and add the missing arrows and labels.

The important clue is that every row in the table represents exactly one transition on the diagram.

Approach

The safest method is:

1. identify which blank circles must be S2, S3, S4 and S5
2. take each row of the table one at a time
3. draw an arrow from the current state to the next state
4. label that arrow with the input and, if present, the output
5. if current state and next state are the same, draw a self-loop instead of a normal arrow

This avoids missing transitions or attaching a label to the wrong arrow.

Step-by-Step Reasoning

Start with the state already given:

• START points to S1

Now use the rows of the table.

• S1, input A1, no output, next state S2
  So draw an arrow from S1 to S2 labelled A1.

• S2, input A2, output X4, next state S3
  So draw an arrow from S2 to S3 labelled A2 | X4.

• S3, input A1, output X1, next state S3
  Because the next state is the same as the current state, this is a self-loop on S3, labelled A1 | X1.

• S3, input A2, output X1, next state S3
  This is another self-loop on S3, labelled A2 | X1.

• S3, input A3, output X3, next state S4
  Draw an arrow from S3 to S4 labelled A3 | X3.

• S3, input A4, no output, next state S2
  Draw an arrow from S3 back to S2 labelled A4.

• S4, input A3, output X4, next state S5
  Draw an arrow from S4 to S5 labelled A3 | X4.

• S4, input A4, output X4, next state S5
  Draw another arrow from S4 to S5 labelled A4 | X4.

• S4, input A1, no output, next state S2
  Draw an arrow from S4 to S2 labelled A1.

That gives the completed diagram.

Key Takeaways

• A state table and a state-transition diagram contain the same information in different forms.
• Each row in the table becomes one arrow on the diagram.
• If current state equals next state, draw a self-loop.
• Outputs are written on the transition where they occur, not inside the state.

Common Mistakes

• Putting the output inside the state circle instead of on the arrow.
• Forgetting that two different inputs can produce two different self-loops on the same state.
• Reversing an arrow, especially for transitions such as S3 back to S2.
• Missing transitions with no output because the output column is blank. A blank output does not mean no arrow.

Things to Be Careful About

• Keep the arrow direction correct: it must go from current state to next state.
• Write labels exactly as input first, then output if there is one, for example A2 | X4.
• Do not invent extra states or extra transitions.
• Make sure both transitions from S4 to S5 are shown separately, because they are caused by different inputs.

Background Concept

A structure chart shows the modular design of a program. Each box is a module. Lines show which module calls another module. Extra notation is used to show:

• selection: one of several modules is called
• iteration: a module or group of modules is called repeatedly
• parameters: data passed into a module
• return values: data sent back from a module

A parameter passed by reference means the called module can change the original value, so the effect flows back to the calling module. In a structure chart this is usually shown as data moving both ways on that connection.

Understanding the Question

There are five modules:

• Setup
• Restart
• Confirm
• Update
• Modify

You are told how they are related:

• Setup calls either Restart or Confirm, so selection is needed under Setup
• Confirm takes a string and returns an integer
• Restart repeatedly calls Update then Modify, so iteration is needed under Restart
• Update takes a string parameter
• Modify returns a Boolean and has no parameters
• Restart itself takes a string parameter passed by reference

So the question is not asking for pseudocode. It is asking for the design diagram that shows both control relationships and data flow.

Approach

Start by placing the top-level module, then add its children. After that, add the notation for control structures, and finally add the data couples for parameters and return values.

For this question:

1. put Setup at the top
2. place Restart and Confirm below it as children
3. show that only one of those two is chosen with a selection symbol
4. place Update and Modify under Restart
5. show that Restart repeats calls to those two modules with an iteration symbol
6. add the parameter and return arrows exactly as described in the notes

Step-by-Step Reasoning

Setup is the top box because the notes describe it as the module that calls others.

Since Setup calls either Restart or Confirm, not both at the same time, put a selection symbol beneath Setup and branch from it to those two modules.

Now consider the data flows:

• Confirm takes a string parameter, so draw a parameter arrow from Setup to Confirm.
• Confirm returns an integer, so draw a return-value arrow from Confirm back to Setup.

For Restart:

• Restart takes a string parameter passed by reference, so show the parameter connection between Setup and Restart as bidirectional data flow.

Now place the children of Restart:

• Restart repeatedly calls Update followed by Modify
• so both Update and Modify sit below Restart
• and there must be an iteration symbol covering those calls

Then add the data flow for these child modules:

• Update takes a string parameter, so draw a parameter arrow from Restart to Update
• Modify returns a Boolean, so draw a return-value arrow from Modify back to Restart
• Modify has no parameters, so do not add a parameter arrow into Modify

That produces the required completed structure chart.

Key Takeaways

• A structure chart shows module relationships, not the internal logic of each module.
• Selection means one of several child modules is called.
• Iteration means a child module or set of child modules is called repeatedly.
• Parameters move into a module; return values move back out.
• A by-reference parameter must be shown so that its effect can return to the caller.

Common Mistakes

• Drawing a flowchart instead of a structure chart.
• Forgetting the selection symbol under Setup and making it look as if both Restart and Confirm are always called.
• Forgetting the iteration symbol under Restart.
• Giving Modify a parameter even though the notes say it has none.
• Missing the return value from Confirm or from Modify.

Things to Be Careful About

• Keep the hierarchy correct: Setup at the top, Restart and Confirm below it, then Update and Modify below Restart.
• Show Update before Modify, because the notes say Update is called followed by Modify.
• Make sure Restart is the module with the by-reference string parameter, not Confirm.
• Distinguish clearly between a parameter passed in and a value returned back.

Background Concept

A record stores several related data items together, so here each element of the global array Loan contains a StudentID, a BookID and an OnLoan value. When we need to find one specific record in an unsorted array, the standard method is a linear search: check each element in turn until either the record is found or the end of the array is reached.

This question also tests procedure design. A procedure is used when the module performs an action such as displaying output, rather than returning a value. Because LoanStatus() must output a message, a procedure is the correct choice.

Efficiency matters too. Since the question says each StudentID + BookID combination can occur only once, once that one matching record has been found there is no need to continue searching. That means an efficient solution should stop early.

Understanding the Question

You are given a global array Loan with 8000 loan records. Some array elements are unused, and an unused element has StudentID = "". A key detail is that these unused elements may occur anywhere in the array, not just at the end.

The module LoanStatus() is called with two strings: a StudentID and a BookID. It must:

• search for the loan record with that exact student-book combination
• if found, output whether the book has been returned
• if no such record exists, output a warning message

Because unused elements can appear anywhere, you must not stop just because you find an empty StudentID. The only safe early stop is when the required record itself has been found.

Approach

The best approach is:

1. Use a procedure with two string parameters.
2. Set up a loop to scan the array from element 1 to element 8000.
3. Use a Boolean flag such as Found to record whether a match has been located.
4. At each array element, compare both fields:
   • Loan[Index].StudentID
   • Loan[Index].BookID
5. If both match, use the OnLoan field to decide which message to output.
6. Set Found to TRUE so the loop ends early.
7. After the loop, if Found is still FALSE, output the warning.

That gives both correctness and efficiency.

Step-by-Step Reasoning

First, define the procedure header with two string parameters, because the module is called using a student ID and a book ID.

Next, declare local variables:

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

Then initialise them:

• Index ← 1 because the search starts at the first array element
• Found ← FALSE because nothing has been found yet

The loop condition is important:

• Index <= 8000 means do not go past the last element
• Found = FALSE means keep searching only while no match has been found

So the loop is both safe and efficient.

Inside the loop, check whether the current record matches both search values:

• the StudentID must match the parameter SearchStudentID
• the BookID must match the parameter SearchBookID

Both are needed because the loan is identified by the combination of the two values.

If the match is found:

• set Found ← TRUE
• inspect Loan[Index].OnLoan

Remember the meaning of OnLoan:

• TRUE means the book has not been returned
• FALSE means the book has been returned

So the output must reflect that meaning exactly. A common misunderstanding is to reverse it.

After the IF, increment Index. Even if Found has just been set to TRUE, this is still acceptable, because the loop condition is checked next and the loop ends.

Finally, after the loop, check whether Found is still FALSE. If so, no matching record exists anywhere in the array, so output the warning message.

This handles all cases:

• loan found and still on loan
• loan found and returned
• loan record not found at all

Key Takeaways

• Use a procedure when the task is to perform output rather than return a value.
• Search an unsorted array with a linear search.
• Compare all key fields needed to identify a record uniquely.
• Use a Boolean flag to control early exit efficiently.
• Do not assume empty elements are grouped at the end unless the question says so.

Common Mistakes

• Stopping when StudentID = "": this is wrong because unused records may occur anywhere, so a valid record could still appear later.
• Checking only StudentID or only BookID: this is wrong because the question identifies a loan by the combination of both.
• Reversing the meaning of OnLoan: TRUE means not returned, not the other way around.
• Writing a function instead of a procedure: the module is specified to output messages, not return a value.
• Forgetting the warning message when no record is found.

Things to Be Careful About

• Use the exact array bound 8000.
• Keep the loop condition safe: Index <= 8000 must be checked before accessing the array beyond its limit.
• Make sure Found is initialised before the loop.
• Match the field names correctly: Loan[Index].StudentID, Loan[Index].BookID, Loan[Index].OnLoan.
• Use the assignment arrow ← in pseudocode, not =.
• The exact wording of the output message may vary, but the logic must clearly distinguish returned, not returned and not found.

Background Concept

A function is used when a module must calculate and return a value. Here the required result is an integer: the number of books currently on loan for students with a particular tutor.

This also uses counting through an array. The standard pattern is:

• start a counter at 0
• examine each element
• if the element matches the required condition, increase the counter by 1
• return the final counter value

Because the tutor ID is stored inside the first three characters of StudentID, string handling is needed too. In CIE pseudocode, LEFT(String, n) returns the first n characters of a string.

Understanding the Question

The function LoansPerTutor() receives one string parameter: a tutor ID. It must return how many books are currently on loan to students whose StudentID begins with that tutor ID.

The key conditions are:

• only loans for the given tutor should be counted
• only books currently on loan should be counted, so OnLoan must be TRUE
• unused array elements must be ignored
• unused elements may appear anywhere, so the whole array must be scanned

Unlike part (a), there is no early exit here, because more than one matching record may exist.

Approach

Use a function because the module returns an integer. Then:

1. Declare a counter variable and set it to 0.
2. Loop through all 8000 array elements.
3. Ignore unused records.
4. Extract the first three characters of StudentID using LEFT(..., 3).
5. If that tutor code matches the parameter and OnLoan = TRUE, increment the counter.
6. After the loop, return the counter.

A full scan is necessary because loans for the same tutor can appear anywhere in the array.

Step-by-Step Reasoning

Start with the function header:

• the module name is LoansPerTutor
• it takes one string parameter, TutorID
• it returns an integer value

Then declare local variables:

• Index to move through the array
• Count to store how many matching loans have been found

Initialise Count ← 0, because before searching, no matches have been counted.

Use a FOR loop from 1 to 8000. This is suitable because every element may need to be checked.

Inside the loop, first check whether the record is unused:

• Loan[Index].StudentID <> ""

This prevents processing empty records. Even if LEFT("", 3) might simply give an empty string, explicitly skipping unused records makes the logic clearer.

For a used record, apply the two required tests:

1. LEFT(Loan[Index].StudentID, 3) = TutorID
   • this checks whether the student belongs to the specified tutor
2. Loan[Index].OnLoan = TRUE
   • this checks whether the book has not yet been returned

Only if both are true should the counter increase.

So the counting statement is:

• Count ← Count + 1

After the loop finishes, the function returns Count.

The reason a full scan is necessary is that you are not looking for just one record. You are counting all matching current loans across the entire array. Since unused elements can appear anywhere, finding one empty element tells you nothing about later positions.

Key Takeaways

• Use a function when a module must return a value.
• Use a counter pattern to count matching records.
• For embedded codes inside strings, extract the relevant substring before comparing.
• When multiple matches are possible, scan the whole array.
• Ignore unused records explicitly when processing a partly filled array.

Common Mistakes

• Using a procedure instead of a function: this loses the returned integer result.
• Stopping at the first empty StudentID: this is incorrect because unused elements may occur anywhere.
• Forgetting to test OnLoan = TRUE: that would count returned books as well.
• Comparing the whole StudentID with the tutor ID: only the first three characters represent the tutor.
• Forgetting to initialise Count to 0.

Things to Be Careful About

• Use LEFT(Loan[Index].StudentID, 3) exactly, because the tutor ID is the first three characters.
• Scan all 8000 records; there is no valid early exit here.
• Return the counter at the end with RETURN Count.
• Keep the test for unused records separate and clear.
• Preserve the meaning of OnLoan: TRUE means the book is still out on loan.