Computer Science 9618/23 — May/June 2024

Background Concept

Built-in pseudocode functions save you from writing common operations yourself. This question uses several different kinds:

• string functions such as MID()
• date functions such as DAY()
• validation-style functions such as IS_NUM()
• arithmetic operators such as MOD

Key meanings:

• MID(String, Start, Length) returns a section from inside a string
• DAY(Date) returns the day part of a date
• IS_NUM(String) returns TRUE if the string contains a valid numeric value
• MOD returns the remainder after integer division

These functions and operators must come from the insert, so the task is to choose the correct one rather than invent your own.

Understanding the Question

You are given four incomplete pseudocode expressions and the value each one must produce. Your job is to fill each blank with one function or operator from the insert so that the whole expression evaluates correctly.

This is really a matching exercise:

• if the result is a piece of text from inside a word, think string extraction
• if the result needs part of a date, think date functions
• if the result is TRUE, think of a Boolean test function
• if the result depends on a remainder, think MOD

Approach

Take each row separately and ask:

1. what type of result is needed?
2. what built-in function or operator from the insert would produce that type of result?
3. does it fit the exact value shown?

That method avoids guessing.

Step-by-Step Reasoning

First row:
........("Random", 2, 3) must evaluate to "and".

We need a substring from the word "Random".
Using MID("Random", 2, 3) means start at position 2 and take 3 characters.
The characters are:

• position 1 = R
• position 2 = a
• position 3 = n
• position 4 = d

So the result is "and".
Therefore the correct function is MID.

Second row:
5 + ........(10/11/2023) must evaluate to 15.

The missing function must produce 10, because $5 + 10 = 15$.
From the date 10/11/2023, the day value is 10.
So the correct function is DAY.

Third row:
........("45000") must evaluate to TRUE.

The input is a string, not a number literal. We need a function that tests whether the string represents a number. "45000" is entirely numeric, so that test should return TRUE.
Therefore the correct function is IS_NUM.

Fourth row:
(20 ........ 3) + 1 must evaluate to 3.

The missing operator must make the bracket evaluate to 2, because $2 + 1 = 3$.

Now test the obvious arithmetic operator from the insert:

• 20 DIV 3 = 6, so $6 + 1 = 7$ which is wrong
• 20 MOD 3 = 2, so $2 + 1 = 3$ which is correct

Therefore the correct operator is MOD.

Key Takeaways

• MID() extracts characters from within a string.
• DAY() returns the day component of a date.
• IS_NUM() checks whether a string is numeric and returns a Boolean value.
• MOD gives the remainder, while DIV gives the integer quotient.
• Matching the required output is often enough to identify the correct function.

Common Mistakes

• Using LEFT or RIGHT instead of MID for the first row. Those do not extract the middle section "and" in the required way.
• Using MONTH instead of DAY in the second row. MONTH(10/11/2023) would give 11, so the total would be 16.
• Using STR_TO_NUM("45000") instead of IS_NUM("45000"). STR_TO_NUM gives a number, not the Boolean value TRUE.
• Confusing DIV and MOD in the last row. DIV gives the quotient; MOD gives the remainder.

Things to Be Careful About

• MID needs both a start position and a length.
• Read the date in the format given; here the day is 10.
• IS_NUM returns TRUE or FALSE, not a number.
• MOD is only correct because the required bracket value is 2.
• Use only functions and operators defined in the insert, exactly as named.

Background Concept

Stepwise refinement means starting with a broad description of a task and breaking it down into smaller, clearer steps that can later be turned into pseudocode. Instead of writing code immediately, you first decide the logical sequence of actions.

In this question, the task involves two important ideas:

• a text file, where data is read line by line
• a 1D array of strings, where each line is stored in a separate element

A sensible refined algorithm for copying file contents into an array usually includes:

• opening the file
• preparing any index or counter
• reading data
• storing data
• repeating until the end of the file
• closing the file

Because the question says not to use pseudocode statements, the answer should stay in plain English steps rather than formal statements such as OPENFILE, READFILE or WHILE.

Understanding the Question

You are given a high-level algorithm:

• first line goes into first array element
• second line goes into second array element
• continue until all lines are copied

You must outline five steps that could later be converted into pseudocode.

The important clues are:

• "Stepwise refinement" means break the task into smaller logical actions.
• "Do not use pseudocode statements" means write normal English descriptions, not formal code-like lines.
• "Assume there are more elements in the array than lines in the file" means you do not need to worry about the array becoming full.

So the answer should describe the process from opening the file through repeated reading and storing.

Approach

A good way to refine this algorithm is to think about what must happen in order:

1. The file must be available for reading.
2. The program needs to know where in the array to store the first line.
3. A line must be read.
4. That line must be placed into the correct array element.
5. The process must repeat for all remaining lines, then finish neatly.

That gives a natural set of five steps.

Step-by-Step Reasoning

A full copy process cannot begin until the text file is opened, so the first step is to open the file for reading.

Next, because the lines are going into different elements of the array, the program needs some way to track the current position. That is why a counter or index is set to the first element.

Once the setup is done, the program can read a line from the file. Since the file is text-based and the algorithm says "first line", "second line" and so on, the data is being processed one line at a time.

After reading a line, that line must be stored in the array element indicated by the current index. This matches the requirement that each line is copied into the next array position.

Then the index must move on so the next line is not written over the previous one. The reading and storing steps continue until there are no more lines left in the file. At the end, the file should be closed.

Although the answer is written in English, it is clearly preparing for later pseudocode using:

• file open and close operations
• an index variable
• repeated processing
• an end-of-file condition

Any wording that captures those logical stages in the correct order would gain credit.

Key Takeaways

• Stepwise refinement breaks a large task into smaller ordered actions.
• File-to-array copying usually needs setup, repeated read/store steps, and termination.
• When told not to use pseudocode, give logical English descriptions rather than formal syntax.
• An index or counter is needed to place each line into the next array element.

Common Mistakes

• Writing actual pseudocode such as OPENFILE or WHILE when the question specifically says not to.
• Forgetting to mention how the program knows which array element to use next.
• Describing only one read and one store, without making it clear that the process repeats.
• Omitting the end condition, so the algorithm does not explain when to stop.
• Forgetting to close the file after processing.

Things to Be Careful About

• Keep the answer in plain English, not code form.
• Make sure the steps are in a sensible processing order.
• Include the idea of repetition until end of file.
• Do not introduce unnecessary array-bound checking, because the question already says there are enough array elements.
• Since the array is global and of type string, each line can be stored directly as text without conversion.

Background Concept

The three basic programming constructs are:

• sequence — statements carried out one after another
• selection — a decision chooses between alternatives
• iteration — a set of steps is repeated

When a task must happen many times, iteration is usually needed. In file processing, repetition is very common because records or lines are read one by one until some stopping condition is met, such as end of file.

Understanding the Question

The question says sequence is already one construct. It asks for one other construct needed when the algorithm from part (a) is written as pseudocode, and you must explain what that construct does.

The algorithm reads a file line by line and keeps going until all lines have been copied into the array. That repeated action is the key clue.

Approach

Look for whether the task involves:

• doing something once only
• making a decision between alternatives
• repeating the same actions many times

Here, the same steps are repeated for every line in the file, so the needed construct is iteration.

Step-by-Step Reasoning

The program does not just read one line. It must:

1. read a line
2. store it in the array
3. move to the next position
4. do the same again for the next line

Because that cycle happens over and over, a loop is required. That is exactly what iteration is for.

The loop would continue until the stopping condition is true, which in this case is reaching the end of the file. So the explanation must mention both the repeated action and the condition for stopping.

A selection test may exist inside the logic in some solutions, but the main additional construct definitely required by this algorithm is iteration because the overall task depends on repetition.

Key Takeaways

• Iteration is used whenever a process must repeat.
• File-reading algorithms commonly use iteration until end of file.
• In short-answer questions, identify the construct and then state exactly what it repeats.

Common Mistakes

• Giving selection instead of iteration without explaining a genuine decision-making role.
• Naming iteration but not explaining what is being repeated.
• Saying only "to make a loop" without linking it to reading each line until end of file.
• Repeating sequence, even though the question asks for another construct.

Things to Be Careful About

• The answer needs both parts: the construct name and its use.
• The use should refer to this exact algorithm, not just a generic definition.
• Mention the stopping point clearly: until the end of the file is reached.
• Keep the explanation short and specific, because this is only a 2-mark item.

Background Concept

A flowchart shows an algorithm using standard symbols:

• oval for START/END
• rectangle for a process or assignment
• diamond for a decision
• parallelogram for input/output

This question tests how to represent sequence, selection and iteration in a flowchart.

The module BatchCheck() must process up to 1000 records. That means it needs:

• initial values before the loop starts
• repeated checking of each component
• a way to count failures
• an early exit if too many failures are found

A function such as InRange(Index) returns a Boolean value. In a flowchart, that fits naturally inside a decision diamond, because the answer is either TRUE or FALSE.

Understanding the Question

You are not being asked to write pseudocode here. You are being asked to complete the missing parts of a flowchart for BatchCheck().

From the stem, BatchCheck() must:

• examine component records in the Batch array
• use InRange() on each record
• count how many components fail
• stop immediately and output a warning if more than 5 fail

The incomplete flowchart already gives the overall shape and one decision: Is Index = 1001 ?. Your task is to supply the missing process boxes, decision boxes and output so that the flowchart matches the required algorithm.

Approach

Work through the algorithm in the order it would happen in a real program.

1. Initialise the variables.

   • Index must start before the first valid position.
   • Count must start at zero.

2. Move to the next component.

   • increment Index

3. Check whether all 1000 records have been processed.

   • if Index = 1001, stop

4. Check the current component.

   • use InRange(Index)
   • if it is TRUE, there is no failure, so go straight back for the next item

5. If the component is not in range, increment the failure count.

6. Check whether the number of failures is now too high.

   • if Count > 5, output Reject Batch and stop
   • otherwise continue looping

This is exactly the logic the completed flowchart must show.

Step-by-Step Reasoning

Start with the first blank process box after START.

This must initialise both control variables:

• Set Index to 0
• Set Count to 0

Why Index starts at 0:

• the next process box increments it first
• so the first actual record checked becomes Batch[1]
• this avoids skipping record 1

The second blank process box must therefore be:

• Set Index to Index + 1

After that comes the given decision Is Index = 1001 ?.

Interpret that carefully:

• if Index = 1001, all valid indices 1 to 1000 have already been handled
• so the flowchart should end
• therefore the Yes branch goes to END
• the No branch continues to the next test

The next blank decision must call the given Boolean function:

• Is InRange(Index) = TRUE ?

Why this is correct:

• the module description explicitly says BatchCheck() calls InRange() for each component
• InRange() returns TRUE if the component weight is acceptable and FALSE otherwise

Now follow each branch:

• if Yes, the component is acceptable, so no failure is counted
• the algorithm just loops back to process the next record
• if No, the component failed, so the failure count must increase

That makes the next blank process box:

• Set Count to Count + 1

Then the final blank decision checks whether the limit has been exceeded:

• Is Count > 5 ?

This must be > rather than >= because the requirement says to stop if the number of failed components exceeds 5. That means 6 or more.

Finally, if that decision is Yes, the output box must contain:

• OUTPUT "Reject Batch"

After the output, the flowchart ends immediately.

If the decision is No, the batch has not yet exceeded the failure limit, so the flowchart loops back to Set Index to Index + 1.

So the completed flow is:

• initialise Index and Count
• increment Index
• stop if all items have been checked
• call InRange(Index)
• if in range, continue
• if not in range, increment Count
• if Count > 5, output Reject Batch and stop
• otherwise continue

Key Takeaways

• Flowcharts must show the exact order of processing.
• Initial values are essential before a loop begins.
• A Boolean function can be placed directly in a decision diamond.
• Early termination is shown by sending a decision branch to output and then END.
• The wording of the condition matters: "exceeds 5" means > 5, not >= 5.

Common Mistakes

• Starting Index at 1 and then immediately incrementing it. That would skip the first record.
• Using Count >= 5 instead of Count > 5. That would reject the batch too early.
• Incrementing Count when InRange(Index) is TRUE. Only failures should be counted.
• Sending the wrong branch from Is Index = 1001 ? to END. The algorithm stops only after all 1000 positions have been considered.
• Forgetting the output message before ending when the failure count is too high.

Things to Be Careful About

• Keep the identifiers exactly as given: Index, Count, InRange(Index).
• The loop is controlled by incrementing first, then checking for 1001.
• InRange(Index) must be tested against TRUE in the flowchart, matching the function description.
• The two loop-back paths are different: one from a successful range check, and one from Count not exceeding 5.
• The output text should be exactly Reject Batch.

Background Concept

This is a sentinel-controlled input algorithm. A sentinel value is a special value that is not part of the real data and is used to mark a boundary or the end of input. Here, the sentinel is 0.

The sequence is divided into two sections:

• values before the first zero belong to the first part
• values after the first zero and before the second zero belong to the second part

To solve this in pseudocode, we normally:

1. initialise totals to zero
2. input a value
3. repeat processing while the value is not the sentinel
4. stop when the sentinel is reached

Because there are two parts, the same pattern is used twice.

This also tests use of a procedure. A procedure performs a task but does not return a value directly. That fits this question because TwoParts() is supposed to process input and output a result. The totals are also stated to be stored in the global variables TotalA and TotalB, so the procedure should update those global variables.

Understanding the Question

The question gives a precise sequence of actions:

• read real numbers one at a time
• add values into TotalA until the first 0
• then add values into TotalB until the second 0
• then output the average of the two totals with a suitable message

The important detail is that the zeros are separators, not values to be added. So neither zero is included in either total.

The wording "process the sequence in two parts" strongly suggests two separate stages. Since TotalA and TotalB already exist as global variables, the procedure should set them up and then fill them correctly.

Approach

The simplest approach is to use two WHILE loops:

• the first loop handles the first section and adds into TotalA
• the second loop handles the second section and adds into TotalB

Before each loop, input a value. Inside each loop:

• if the value is not zero, add it to the correct total
• input the next value

When the loop ends, the zero has been found, so we move on to the next part.

Finally, compute:

$$\text{Average} = \frac{\text{TotalA} + \text{TotalB}}{2}$$

and output it with a message.

Step-by-Step Reasoning

Start by declaring any local values needed. We need:

• Value to hold each input number
• Average to store the final result

Then initialise the global totals:

TotalA ← 0
TotalB ← 0

This is essential. If they are not reset, old values might remain from an earlier call.

Now process the first part.

INPUT Value
WHILE Value <> 0
   TotalA ← TotalA + Value
   INPUT Value
ENDWHILE

How this works:

• first number is read into Value
• as long as it is not zero, add it to TotalA
• read the next value and test again
• when a zero is entered, the loop stops

That first zero marks the end of part 1, so it is not added.

Now process the second part.

INPUT Value
WHILE Value <> 0
   TotalB ← TotalB + Value
   INPUT Value
ENDWHILE

This is the same logic again, but now the values belong to the second section and are added to TotalB. The second zero ends this loop.

Finally calculate and output the average of the two totals.

Average ← (TotalA + TotalB) / 2
OUTPUT "Average of totals = ", Average

This is the average of the two totals, not the average of all the input values.

For example, if the input sequence were:

4.5, 2.0, 0, 7.0, 1.0, 0

then:

• TotalA = 4.5 + 2.0 = 6.5
• TotalB = 7.0 + 1.0 = 8.0
• average of totals:

$$\frac{6.5 + 8.0}{2} = 7.25$$

So the output would report 7.25.

An alternative valid method would be to use one loop plus a flag or counter to track how many zeros have been seen, but the two-loop approach is clearer and matches the wording naturally.

Key Takeaways

• Use a sentinel value to divide or end input.
• Initialise totals before starting accumulation.
• Use separate loops when the data naturally has separate phases.
• Read a new value inside the loop so the condition can change.
• Be careful to calculate the average of totals, not the average of all items.

Common Mistakes

• Adding the zero into a total: zero is a separator here, so it must only stop the loop.
• Forgetting to initialise TotalA and TotalB: this can leave old values in the globals.
• Not inputting the next value inside the loop: this causes an infinite loop because Value never changes.
• Using only one total: the question specifically requires TotalA for the first part and TotalB for the second.
• Calculating the wrong average: some students divide by the number of values entered, but the task asks for the average of the two totals.
• Using = for assignment in pseudocode: CIE pseudocode uses ← for assignment and = for comparison.

Things to Be Careful About

• Value should be a REAL because the question says the inputs are real values.
• The first INPUT Value before each WHILE is important because this is a pre-condition loop.
• The second loop must start with a fresh input after the first zero has already been used as the split marker.
• Output needs a message as well as the calculated value.
• Keep the identifier names exactly as given: TwoParts(), TotalA, and TotalB.

Background Concept

A loop construct should match the way repetition works in the problem.

A WHILE loop is a pre-condition loop. It keeps repeating while a condition is true, so it is most suitable when the number of repetitions is not known in advance and the program must test whether it should continue.

A FOR loop is a count-controlled loop. It is most suitable when:

• the start value is known
• the end value is known
• the step is known

In that case, the loop variable changes automatically, which makes the pseudocode shorter, clearer and less error-prone.

Understanding the Question

The procedure ArrayInitialise() fills Data[1] to Data[1000]. The existing code starts at Index ← 1 and continues while Index <= 1000, adding 1 to Index each time through the loop.

That means the number of repetitions is completely fixed: exactly 1000 passes. The question asks which loop construct is more appropriate and why.

The key clue is that the loop is not waiting for some unpredictable event. It is simply counting through array positions from 1 to 1000.

Approach

To answer this, look at how the loop variable behaves:

1. It starts at a known value: 1.
2. It ends at a known value: 1000.
3. It changes by a known step: +1.

That is exactly the pattern for a FOR ... NEXT loop, so the best answer is to recommend a FOR loop and explain that it suits a known number of iterations.

Step-by-Step Reasoning

The original code does this:

• sets Index to 1
• checks Index <= 1000
• performs one of the two assignments depending on whether Index is odd or even
• increases Index by 1
• repeats

So although it is written as a WHILE, it is really just counting from 1 to 1000.

A FOR loop expresses that directly:

FOR Index ← 1 TO 1000

This is more appropriate because:

• the loop bounds are fixed
• the loop counter update is built into the construct
• the pseudocode becomes easier to read
• there is less risk of forgetting Index ← Index + 1 or placing it incorrectly

So the main reason is not that the WHILE loop is wrong, but that it is a less suitable choice for a fixed-count repetition.

Key Takeaways

• Use a FOR loop when the number of repetitions is known in advance.
• Use a WHILE loop when continuation depends on a condition that may vary unpredictably.
• Choosing the best construct improves clarity as well as correctness.

Common Mistakes

• Saying the WHILE loop is invalid. It is valid, just not the most appropriate.
• Naming a REPEAT ... UNTIL loop. That is not better here because the number of iterations is still fixed and known.
• Giving only the construct without explaining why it is better.
• Saying "because it is faster". The main advantage here is suitability and clarity, not execution speed.

Things to Be Careful About

• The array is declared from 1 to 1000, so the loop must match those bounds exactly.
• The explanation should mention the known fixed number of iterations.
• If writing the loop, keep CIE pseudocode style, for example FOR Index ← 1 TO 1000.

Background Concept

An algorithm is inefficient when it performs work repeatedly that does not need to be repeated.

A common source of inefficiency is recomputing the same result inside a loop. If the input to a function does not change, then the output will not change either. Calling that function again and again wastes processing time.

A standard optimisation is:

1. compute the result once
2. store it in a variable
3. reuse that stored value whenever needed

This is especially useful inside loops, because even a small unnecessary action becomes expensive when repeated many times.

Understanding the Question

Inside ArrayInitialise(), the parameter Label is passed to either FormatA() or FormatB() for every array position.

But Label itself never changes during the procedure.

So the procedure is effectively doing this again and again:

• for every odd position, calculate FormatB(Label)
• for every even position, calculate FormatA(Label)

Since the same input string is used each time, there are really only two distinct formatted results needed:

• one version produced by FormatA(Label)
• one version produced by FormatB(Label)

The question asks for two things:

• why the current method is inefficient
• what a more efficient solution would be

Approach

The best way to answer is to focus on repeated identical function calls.

Reasoning process:

1. Check whether the parameter passed to the functions changes. It does not.
2. Conclude that the functions will return the same outputs every time they are called with that parameter.
3. Identify that the loop is recalculating those same outputs repeatedly.
4. Improve the design by moving those function calls outside the loop.
5. Store the results and use the stored strings during the loop.

This is a classic "precompute once, reuse many times" improvement.

Step-by-Step Reasoning

The current procedure uses a loop that runs through the array positions.

For an even Index, it executes:

Data[Index] ← FormatA(Label)

For an odd Index, it executes:

Data[Index] ← FormatB(Label)

Now look carefully at the argument passed to each function: it is always Label.

Because Label does not change:

• FormatA(Label) returns the same formatted string every time
• FormatB(Label) returns the same formatted string every time

So if the loop runs 1000 times, the program is not creating 1000 different formatted results. It is just recalculating the same two results over and over.

That is inefficient because function calls take time. The formatting operation may involve examining characters, changing case, building a new string, and returning it. Doing that hundreds of extra times is unnecessary.

A better design is:

1. before the loop, calculate the two possible formatted versions once
2. store them, for example in two variables
3. in the loop, copy those stored strings into the array

For example, the improved idea would be:

FormattedA ← FormatA(Label)
FormattedB ← FormatB(Label)

Then inside the loop:

• if the index is even, assign FormattedA
• if the index is odd, assign FormattedB

This produces exactly the same final array contents, but with far fewer function calls.

Instead of calling formatting functions 1000 times, the program calls them only twice.

That is why the improved version is more efficient.

Key Takeaways

• If a function is called repeatedly with the same input, consider calculating the result once and storing it.
• Efficiency often comes from removing unnecessary repeated work inside loops.
• A loop should usually contain only the operations that genuinely need to vary from one iteration to the next.

Common Mistakes

• Saying it is inefficient just because functions are used. Functions themselves are not the problem; the issue is repeated calls with unchanged input.
• Saying the functions should be removed entirely. The formatting is still needed, just not repeated unnecessarily.
• Suggesting different loop constructs as the main answer here. This part is about repeated function calls, not loop selection.
• Forgetting to state the improved method clearly: call each formatting function once, store the results, then reuse them.

Things to Be Careful About

• The key fact is that Label stays the same throughout the procedure.
• The efficient version must still preserve the alternating pattern between odd and even indices.
• Do not claim the result changes; the optimisation improves efficiency while keeping the same output.
• In an exam answer, make sure both parts are present: the inefficiency and the suggested improvement.

Background Concept

In Paper 2, when a question asks you to write pseudocode for a module, you are being tested on how to translate a specification into a clear algorithm using standard CIE pseudocode conventions.

A procedure is used when a module performs an action but does not return a value directly. Here, Progress() creates a filename and then calls another procedure, Display(), so a procedure is the correct choice.

This task also uses:

• parameters to pass data into the procedure
• integer division to map a percentage to a step number
• string manipulation to build the filename
• a procedure call to pass the finished filename to another module

The key programming idea is that the percentage range is split into equal bands of 10:

• 0 to 9 maps to step 1
• 10 to 19 maps to step 2
• ...
• 90 to 99 maps to step 10
• 100 maps to step 11

Using DIV 10 is a neat way to do this because integer division removes the remainder.

Understanding the Question

You are given a description of how a progress bar image is chosen.

The procedure Progress() receives:

• an integer percentage from 0 to 100
• a string holding the filename root, such as BargraphA

It must then:

1. work out which step number should be used
2. generate the full filename such as BargraphA-3.bmp
3. call Display() with that full filename

The table in the question is the important clue. It shows that step numbers line up with percentage intervals of size 10, and that the filename is formed from:

root + "-" + step + ".bmp"

So the whole task is really a small module that converts a percentage into a filename.

Approach

A good strategy is:

1. Declare local variables for the step number and full filename.
2. Calculate the step from the percentage.
3. Convert the step number to text so it can be joined into the filename.
4. Concatenate the parts of the filename.
5. Pass the result to Display().

The crucial part is step calculation. Integer division by 10 gives:

• 0 DIV 10 = 0
• 9 DIV 10 = 0
• 10 DIV 10 = 1
• 99 DIV 10 = 9
• 100 DIV 10 = 10

If we then add 1, the answers become the required step numbers 1 to 11.

Step-by-Step Reasoning

We start with the procedure header:

PROCEDURE Progress(Percentage : INTEGER, FilenameRoot : STRING)

This matches the specification exactly:

• Percentage is the integer progress value
• FilenameRoot is the image filename root

Next, local variables are declared:

DECLARE Step : INTEGER
DECLARE FullFilename : STRING

Step stores which image number to use.

FullFilename stores the finished filename, for example BargraphA-7.bmp.

Now calculate the step:

Step ← Percentage DIV 10 + 1

Why this works:

• if Percentage = 0, then 0 DIV 10 = 0, so Step = 1
• if Percentage = 8, then 8 DIV 10 = 0, so Step = 1
• if Percentage = 10, then 10 DIV 10 = 1, so Step = 2
• if Percentage = 87, then 87 DIV 10 = 8, so Step = 9
• if Percentage = 100, then 100 DIV 10 = 10, so Step = 11

So it matches every row pattern in the table.

Then build the filename:

FullFilename ← FilenameRoot + "-" + NUM_TO_STR(Step) + ".bmp"

This joins four pieces:

1. the root, such as BargraphA
2. the hyphen -
3. the step converted to text
4. the extension .bmp

NUM_TO_STR(Step) is needed because Step is an integer, but filenames are strings.

Finally, call the display procedure:

CALL Display(FullFilename)

This satisfies the last requirement: the generated full filename is passed to Display().

The completed procedure therefore does exactly what the specification asks.

Key Takeaways

• Use a procedure when a module performs an action rather than returning a value.
• DIV is very useful for grouping values into fixed-size ranges.
• Build filenames or similar text values by concatenating strings.
• Convert numbers to strings before joining them into text.
• When a question gives a pattern in a table, look for a compact arithmetic rule instead of many IF statements.

Common Mistakes

• Using a function instead of a procedure. This part specifically asks for procedure Progress().
• Forgetting to call Display(). Generating the filename alone is not enough for part (a).
• Not converting the step number to a string before concatenation.
• Writing many separate IF statements for each percentage range. That is much longer and less elegant than using DIV.
• Getting the step numbering off by one, for example using Percentage DIV 10 without adding 1.
• Using = instead of ← for assignment in pseudocode.

Things to Be Careful About

• The allowed percentage range is 0 to 100 inclusive, so your logic must handle 100 correctly.
• The filename format must match the table exactly: root, hyphen, step, .bmp.
• DIV is integer division, not ordinary real division.
• Keep CIE pseudocode style: PROCEDURE, DECLARE, CALL, and the assignment arrow ←.
• Use sensible parameter names and keep the types consistent with the question.

Background Concept

A structure chart shows the relationship between modules in a program. It is not a flowchart of statements; instead, it shows:

• which module calls which other modules
• the hierarchy of modules
• whether calls happen in sequence, by selection, or by iteration
• the data passed between modules
• any return values from functions

Typical structure-chart conventions include:

• a rectangle for each module
• modules placed below the module that calls them
• a diamond to show a selection, meaning one of several modules is chosen at run time
• a curved loop mark to show repeated calls
• labelled data couples to show parameters being passed
• a return value shown back from a function to the calling module

This question also involves pass by reference. In a structure chart, that is commonly shown as data moving back as well as down, because the called module can modify the caller's variable.

Understanding the Question

You are given seven module descriptions and asked to draw one structure chart that shows:

• the top-level module
• which modules are called by each module
• the special control relationships:
  • Mod-B calls either Mod-D or Mod-E
  • Mod-C repeatedly calls Mod-F followed by Mod-G
• the parameters passed between modules
• the modules that return values

So this is not just a hierarchy question. You must combine several pieces of information from the table into one diagram.

Approach

A reliable method is:

1. Find the top-level module.
2. Put beneath it the modules it directly calls.
3. For each child module, add its own children.
4. Add the correct control notation:
   • diamond for a choice
   • loop mark for repetition
5. Label all passed parameters.
6. Add return values for function modules.
7. Pay attention to by-reference parameters, because those can be shown as two-way data flow.

Step-by-Step Reasoning

Start with the module descriptions.

1. Top level

Mod-A calls Mod-B followed by Mod-C, so Mod-A must be the top box.

Below Mod-A, place two child boxes:

• Mod-B on the left
• Mod-C on the right

This shows the first level of decomposition.

2. Parameters and return value between Mod-A and Mod-B

Mod-B is called with Par1 and Par2, so show those data couples from Mod-A down to Mod-B.

Mod-B returns a Boolean value, so show a return value from Mod-B back up to Mod-A.

3. Parameters between Mod-A and Mod-C

Mod-C is called with Par1 and Par3, so show both from Mod-A to Mod-C.

Because Par3 is passed by reference to Mod-C, it can be shown with data flowing back as well, indicating that the original value may be changed.

4. Children of Mod-B

Mod-B calls either Mod-D or Mod-E, determined when the program runs.

That means this is a selection, not a sequence. So place a diamond below Mod-B, then from that diamond branch to:

• Mod-D on the left
• Mod-E on the right

5. Parameters and return value under Mod-B

Mod-D is called with Par2, so label the link from Mod-B to Mod-D with Par2.

Mod-E is called with Par3, so label the link from Mod-B to Mod-E with Par3.

Mod-E returns an integer value, so show a return value from Mod-E back up to Mod-B.

6. Children of Mod-C

Mod-C repeatedly calls Mod-F followed by Mod-G.

So place Mod-F and Mod-G below Mod-C, with Mod-F to the left and Mod-G to the right.

Add the iteration mark above these calls to show that this pair of calls is repeated.

7. Parameters under Mod-C

Mod-F is called with Par3, so show Par3 from Mod-C to Mod-F.

Mod-G is called with Par3, and Par3 is passed by reference, so show Par3 on the link to Mod-G with data movement back as well, indicating that Mod-G may modify the original value.

8. Final structure

The completed chart therefore has:

• Mod-A at the top
• Mod-B and Mod-C underneath
• a selection diamond under Mod-B leading to Mod-D and Mod-E
• an iteration mark under Mod-C covering repeated calls to Mod-F then Mod-G
• all required parameter labels
• a return value from Mod-B to Mod-A
• a return value from Mod-E to Mod-B

Key Takeaways

• A structure chart shows module relationships, not line-by-line program logic.
• Selection is shown with a diamond.
• Repetition is shown with a loop mark.
• Parameters must be labelled on the links.
• Functions should show a return value back to the caller.
• By-reference parameters are important because the called module can alter the original variable.

Common Mistakes

• Drawing a flowchart instead of a structure chart.
• Putting all seven modules at the same level instead of showing hierarchy.
• Forgetting that Mod-B chooses either Mod-D or Mod-E, so missing the selection diamond.
• Forgetting that Mod-C repeatedly calls Mod-F and Mod-G, so missing the iteration mark.
• Omitting parameter labels such as Par1, Par2 and Par3.
• Forgetting return values from Mod-B and Mod-E.
• Connecting Mod-D and Mod-E directly under Mod-A instead of under Mod-B.

Things to Be Careful About

• Keep the hierarchy exact: Mod-A calls Mod-B and Mod-C; Mod-B owns the choice between Mod-D and Mod-E; Mod-C owns the repeated calls to Mod-F and Mod-G.
• Mod-D receives Par2 only.
• Mod-E receives Par3 and returns an integer.
• Mod-F receives Par3 by value, so a one-way data couple is enough.
• Mod-G receives Par3 by reference, so show the possibility of the changed value being passed back.
• Mod-B itself is a function because it returns a Boolean value to Mod-A, so do not miss that return path.

Background Concept

A function is used when a module must return a value. Here, Header() examines one line of pseudocode and returns either a tagged result or an empty string, so it is naturally a function rather than a procedure.

This question mainly tests string handling and selection. A common pattern is:

• first validate simple conditions such as minimum length
• then standardise the data for comparison
• then extract the required part of the string

For case-insensitive checks, a standard method is to convert the text to one case using TO_UPPER() and compare against uppercase constants. For prefix testing, LEFT() is useful because it checks the first fixed number of characters. For substring extraction, MID() is used to take the part after the keyword.

The rule about the keyword being followed by a space is important. Checking against "PROCEDURE " and "FUNCTION " includes that space, so headers like PROCEDUREX or FUNCTIONS are correctly rejected.

Understanding the Question

The input to Header() is one line of pseudocode, stored as a string.

The function must decide whether that line is a valid module header. A valid header must:

• be at least 13 characters long
• start with PROCEDURE or FUNCTION
• allow any mixture of upper/lower case in the keyword

If it is a procedure header, the function must return:

• "P" followed by the module description

If it is a function header, the function must return:

• "F" followed by the module description

Otherwise it must return an empty string.

The module description is the whole header line without the keyword. So:

• PROCEDURE MyProc(Z : CHAR) becomes MyProc(Z : CHAR)
• FUNCTION Zap(X : INTEGER) RETURNS CHAR becomes Zap(X : INTEGER) RETURNS CHAR

Approach

A good strategy is:

1. Reject lines that are too short.
2. Make a second version of the line in uppercase so the keyword test is case-insensitive.
3. Check whether the line starts with PROCEDURE .
4. If not, check whether it starts with FUNCTION .
5. If one of those matches, return the appropriate leading letter plus the बाकी of the original line after the keyword.
6. If neither matches, return "".

Using the original Line for the MID() extraction is better than using the uppercase version, because it preserves the student's original casing in the module description.

Step-by-Step Reasoning

The function header is:

FUNCTION Header(Line : STRING) RETURNS STRING

This says the module is a function called Header, it receives one string parameter called Line, and it returns a string.

A local variable is declared:

DECLARE UpperLine : STRING

This stores the uppercase copy used for comparison.

The first check is:

IF LENGTH(Line) < 13 THEN
   RETURN ""
ENDIF

This directly applies the rule in the question. If the line is too short, it cannot be valid, so the function finishes immediately with an empty string.

Next:

UpperLine ← TO_UPPER(Line)

Now a line such as function Zap(X : INTEGER) RETURNS CHAR becomes FUNCTION ZAP(X : INTEGER) RETURNS CHAR for checking purposes. This avoids writing separate tests for upper case, lower case and mixed case.

Then the procedure test:

IF LEFT(UpperLine, 10) = "PROCEDURE " THEN

This checks the first 10 characters exactly:

• 9 letters in PROCEDURE
• plus 1 space

If this matches, the description begins immediately after those 10 characters, so:

RETURN "P" & MID(Line, 11, LENGTH(Line) - 10)

Why character 11? Because characters 1 to 10 are PROCEDURE , so the description starts at the next character.

If the procedure test fails, the function test is tried:

IF LEFT(UpperLine, 9) = "FUNCTION " THEN

This checks:

• 8 letters in FUNCTION
• plus 1 space

If it matches, the description starts at character 10, so:

RETURN "F" & MID(Line, 10, LENGTH(Line) - 9)

Again, the MID() uses the original line so the returned description keeps its original case and punctuation.

If neither prefix matches, the line is not a valid module header, so the function returns "".

This satisfies all three required outputs:

• valid procedure header -> P<description>
• valid function header -> F<description>
• anything else -> empty string

Key Takeaways

• Use a function when a module must return a value.
• For case-insensitive keyword checking, convert to one case first.
• Include the trailing space in the prefix test when the question says the keyword must be followed by a space.
• Use MID() carefully with correct starting positions based on 1-based indexing.
• Returning an empty string is a useful way to signal "not valid".

Common Mistakes

• Checking only PROCEDURE or FUNCTION without the space. That would wrongly accept strings such as PROCEDUREX.
• Forgetting the minimum length test. The question explicitly states this rule.
• Extracting from the wrong position, such as starting at 10 instead of 11 for PROCEDURE.
• Using the uppercase copy for the returned description. That would change the original text unnecessarily.
• Writing a procedure instead of a function, even though a value must be returned.

Things to Be Careful About

• CIE pseudocode uses the assignment arrow ←, not =.
• Arrays and string positions are treated as 1-based in this style of pseudocode, so the starting positions in MID() matter.
• PROCEDURE is 10 characters, but FUNCTION is 9 characters.
• Return "" exactly for invalid lines, not a space and not a special word such as FALSE.
• Preserve the given identifier casing and built-in function names such as LENGTH, LEFT, MID and TO_UPPER.

Background Concept

This question combines several core Paper 2 ideas:

• text file handling
• iteration until end of file
• calling one module from another
• storing processed data in a 2D array

A procedure is appropriate here because FindModules() does not need to return a single value. Instead, it updates the global array ModInfo.

When reading a file line by line, the usual pattern is:

1. open the file for reading
2. repeat while not end of file
3. read one line
4. process that line
5. close the file

A 2D array stores data in rows and columns. In this question, each row represents one discovered module, and the columns hold:

• column 1: line number as a string
• column 2: module type, "P" or "F"
• column 3: module description

Understanding the Question

FindModules() receives the filename of a student project.

It must examine every line in that file and use the earlier function Header() to decide whether that line is a module header.

If Header() says the line is a valid header, FindModules() must add a row to ModInfo.

From the given example:

• ModInfo[10, 1] = "27" means the module header was on line 27
• ModInfo[10, 2] = "P" means it was a procedure
• ModInfo[10, 3] = "MyProc(Z : CHAR)" is the description

So the new procedure has to do two separate counts:

• the current file line number
• the current row number in ModInfo

Those are not the same thing, because most lines in the file will not be module headers.

Approach

The cleanest method is:

1. Open the project file.
2. Start LineNum at 0 and ModuleNum at 0.
3. Read each line until the file ends.
4. After each read, increase the line number.
5. Call Header() using that line.
6. If the returned string is not empty, a module has been found.
7. Increase the module counter and store the three required values into the next row of ModInfo.
8. Close the file.

Because Header() returns either:

• P<description>
• F<description>
• or ""

we can split the non-empty result very easily:

• first character -> column 2
• remaining characters -> column 3

Step-by-Step Reasoning

The procedure header is:

PROCEDURE FindModules(ProjectFileName : STRING)

This is a procedure because the task is to populate a global array, not return a single value.

Local variables are declared:

DECLARE ThisLine, Result : STRING
DECLARE LineNum, ModuleNum : INTEGER

• ThisLine stores the current line read from the file
• Result stores what Header() returns
• LineNum tracks the actual line number in the project file
• ModuleNum tracks how many valid module headers have been found so far, and therefore which row of ModInfo to use next

Initial values:

LineNum ← 0
ModuleNum ← 0

Both counters start at 0 before anything has been read.

The file is opened for reading:

OPENFILE ProjectFileName FOR READ

Then the main loop continues until the end of the file:

WHILE NOT EOF(ProjectFileName)

Inside the loop, one whole line is read:

READFILE ProjectFileName, ThisLine

After reading the next line, the line number becomes one higher:

LineNum ← LineNum + 1

Now the line can be checked:

Result ← Header(ThisLine)

There are two possibilities.

If Result = "", the line was not a valid module header, so nothing is stored.

If Result <> "", then a module declaration has been found. So:

ModuleNum ← ModuleNum + 1

This moves to the next free row in ModInfo.

Column 1 stores the line number as a string:

ModInfo[ModuleNum, 1] ← NUM_TO_STR(LineNum)

This conversion matters because ModInfo is a string array.

Column 2 stores the first character of the returned string, which is either P or F:

ModInfo[ModuleNum, 2] ← LEFT(Result, 1)

Column 3 stores the remaining characters, which are the module description:

ModInfo[ModuleNum, 3] ← MID(Result, 2, LENGTH(Result) - 1)

This starts at character 2 because character 1 is the type code.

Once all lines have been processed, the loop ends and the file is closed:

CLOSEFILE ProjectFileName

That completes the required behaviour.

Key Takeaways

• Use one counter for file position and another for the number of valid records found.
• A helper function can simplify a larger procedure by doing the validation separately.
• When a global array stores strings, numeric values may need converting with NUM_TO_STR().
• A 2D array row can represent one entity, with different columns storing different attributes.
• The standard file-processing pattern is open -> loop until EOF -> read/process -> close.

Common Mistakes

• Using only one counter for both line number and module row. These represent different things and will usually not match.
• Forgetting to increment ModuleNum only when a valid module is found. If it is incremented on every line, blank rows or wrong rows will be created.
• Storing the line number as an integer instead of converting it to a string for ModInfo.
• Writing the whole Result into column 3, which would wrongly include the leading P or F.
• Forgetting to close the file at the end.

Things to Be Careful About

• The order inside the loop matters: read the line, then increase the line count, then process it.
• EOF(ProjectFileName) must be used consistently with the same file identifier that was opened.
• LEFT(Result, 1) gives only the module type; MID(Result, 2, LENGTH(Result) - 1) gives the rest.
• Since the question says to assume enough rows exist, no extra bounds check on ModInfo is needed.
• Keep the module names and global array name exactly as given: Header(), FindModules() and ModInfo.