Computer Science 9618/22 — May/June 2025

Background Concept

A program development life cycle is the overall model used to organise how software is planned, designed, coded, tested and maintained. Common life cycles include waterfall, iterative and prototyping approaches. The key idea is that different projects do not all behave in the same way.

Some projects have fixed requirements from the start, while others change frequently. Some are safety-critical, some are small and quick to build, and some need frequent user feedback. Because of that, software teams choose different life cycles to match the situation.

Understanding the Question

This question is asking for the reason why there is more than one possible program development life cycle. It is not asking you to name life cycles or describe all their stages. It wants the general idea that different development situations need different approaches.

The context is a factory production-line program, but the answer is still broad: software projects vary, so the life cycle chosen must fit the project.

Approach

For a 1-mark "explain the need" question, the safest approach is to make one clear point:

• projects differ in requirements or circumstances
• therefore one single life cycle cannot suit them all

That directly answers both parts of the idea: why there are different models, and why they are needed.

Step-by-Step Reasoning

A strong answer begins with the fact that software projects are not identical. They may differ in:

• size
• complexity
• urgency
• how stable the requirements are
• how much user feedback is needed
• how much testing and documentation are required

Once you state that projects differ, the conclusion follows: a single life cycle would not be appropriate for every project. For example, a rigid stage-by-stage model may be suitable when requirements are fixed, but not when they are likely to change.

So the mark-winning point is that different requirements lead to different suitable development models.

Key Takeaways

• A program development life cycle is chosen to fit the project.
• There is no universal best life cycle for all software.
• When requirements or conditions differ, the development model may also need to differ.

Common Mistakes

• Naming a life cycle only, such as "waterfall". That does not explain why different ones are needed.
• Talking about coding or testing stages instead of the reason for choosing different models.
• Giving a vague answer such as "because programs are different" without linking it to suitability of the life cycle.

Things to Be Careful About

• This is a general software-development question, not a question about maintenance.
• For 1 mark, keep the answer short but complete: different project requirements mean different life cycles are needed.
• Make sure the answer explains need, not just lists examples.

Background Concept

During the coding stage, developers choose a programming language in which to implement the design. That choice matters because languages differ in speed, available libraries, hardware support, portability, ease of development and suitability for particular kinds of problem.

A language that works well for one project may be a poor choice for another. For example, a language used for web development may not be the best choice for low-level device control.

Understanding the Question

The question asks for one consideration that affects the choice of programming language. Because it says "State one consideration", only one valid factor is needed.

The program controls a factory production line, so a very sensible consideration is whether the language is suitable for real-time or hardware-interfacing tasks.

Approach

Pick one strong, specific factor that clearly affects the decision. Good examples include:

• suitability for the application
• speed of execution
• available libraries
• programmer expertise
• compatibility with existing hardware or operating system

For this context, suitability for real-time control is especially relevant.

Step-by-Step Reasoning

A production-line control system often has to react to inputs quickly and reliably. For example, it may read sensors, operate machinery or respond within strict time limits. Therefore, when choosing a language, the development team must consider whether that language can support these needs.

So an answer such as "the language must be suitable for real-time control" is strong because it connects the language choice to the task the program must perform.

Other answers could also be valid, but in an exam you only need one correct consideration.

Key Takeaways

• Language choice is influenced by the program's requirements.
• A good answer states one factor and, if possible, ties it to the context.
• Suitability for the task is one of the most reliable exam answers.

Common Mistakes

• Giving a life-cycle stage instead of a consideration.
• Naming a programming language without saying why it was chosen.
• Giving a very vague answer such as "because it is better".

Things to Be Careful About

• The question asks for one consideration, not several.
• Keep the answer focused on the choice of language, not on testing or maintenance.
• If you use the factory context, make sure the factor really relates to control software, such as real-time performance or hardware compatibility.

Background Concept

Adaptive maintenance means changing a program so that it continues to work in a changed environment. The key word is adaptive: the software is being adjusted to fit something external that has changed.

This is different from:

• corrective maintenance, which fixes faults
• perfective maintenance, which improves or extends the system
• preventive maintenance, which reduces the risk of future problems

Adaptive maintenance is about responding to change around the software, such as hardware, operating systems or business procedures.

Understanding the Question

The question says the program has already been in use for months and adaptive maintenance is required. It then asks for three reasons why this type of maintenance may be needed.

So you should not give reasons like "there is a bug" because that would be corrective maintenance. Instead, you need three examples of changes in the environment that force the software to be altered.

Approach

Think: what has changed around the software rather than inside the software?

Typical adaptive triggers are:

• new hardware
• a new operating system or updated system software
• changes to working practices, procedures or external conditions

Choose three clearly different examples.

Step-by-Step Reasoning

Reason 1: new hardware or devices.
If the factory adds new sensors, robots or input devices, the software may need new drivers, new input handling or revised control logic.

Reason 2: changed operating system or system software.
If the computers running the production line are upgraded, the existing program may no longer run correctly without modification.

Reason 3: changed production process or working procedures.
If the factory changes how items move through the production line, or changes timings, limits or rules, the software must be adapted to match the new environment.

These are all adaptive because the software is being changed to fit external changes, not because the original code was necessarily wrong.

Key Takeaways

• Adaptive maintenance responds to environmental change.
• Good examples usually involve hardware, system software or operating conditions.
• Do not confuse adaptive maintenance with fixing errors.

Common Mistakes

• Writing "fixing bugs". That is corrective maintenance, not adaptive.
• Writing "making the program faster" without context. That is usually perfective, not adaptive.
• Giving three versions of the same idea, such as three different ways to say "hardware changed".

Things to Be Careful About

• You need three separate reasons.
• Each reason should imply a changed environment.
• Because the system is a factory control program, practical examples like sensors, machines or production procedures are especially appropriate.

Background Concept

Software maintenance is usually divided into categories:

• corrective maintenance: fixing errors or faults
• adaptive maintenance: changing software because the environment has changed
• perfective maintenance: improving performance or adding enhancements
• preventive maintenance: restructuring or updating to reduce future problems

Exams often test whether you can recognise these categories and tell them apart.

Understanding the Question

This question already mentions adaptive maintenance and asks you to identify one other type. Because it says "Identify one", any one valid maintenance type other than adaptive would gain the mark.

Approach

The safest strategy is to give a standard textbook category, such as:

• corrective
• perfective
• preventive

A single word or short phrase is enough.

Step-by-Step Reasoning

Since adaptive maintenance has already been named, we choose another recognised category. "Corrective maintenance" is a clear valid answer because it refers to fixing faults found after deployment.

That satisfies the question fully.

Key Takeaways

• Learn the main maintenance categories by name.
• Be able to match each category to its purpose.
• For "identify" questions, a brief accurate term is enough.

Common Mistakes

• Repeating "adaptive maintenance", which does not answer "one other type".
• Giving a stage of development, such as testing or coding, instead of a maintenance type.
• Describing the type without naming it when the question specifically says identify.

Things to Be Careful About

• Only one other type is required.
• Use the standard category name exactly.
• Do not mix up maintenance with development models such as waterfall or iterative.

Background Concept

An array dimension tells you how many indices are needed to access one element.

• A 1D array uses one index, for example Scores[5].
• A 2D array uses two indices, for example Scores[5, 3].
• A 3D array would use three indices, and so on.

A 2D array is often thought of as rows and columns.

Understanding the Question

The array element is shown as:

Product[x, y] ← 23

The question asks for the number of dimensions of Product. So you simply need to count how many index positions appear inside the brackets.

Approach

Count the subscripts separated by commas in the array reference.

• one subscript means 1 dimension
• two subscripts mean 2 dimensions

Step-by-Step Reasoning

Product[x, y] has two index values:

• x
• y

Because two separate subscripts are needed to locate one element, Product is a two-dimensional array.

Key Takeaways

• The number of dimensions equals the number of indices used.
• Array[a, b] is 2D because it uses two subscripts.

Common Mistakes

• Saying the answer is 100 or 1000 because the question mentions bounds. That is about size, not dimensions.
• Confusing variables x and y with stored data values. Here they are indices.

Things to Be Careful About

• This question asks only for dimensions, not total elements.
• A comma inside the brackets is the clue that there is more than one dimension.

Background Concept

The total number of elements in an array depends on how many valid index positions there are in each dimension. When bounds are inclusive, the count is:

The + 1 matters because both the lower and upper bound are included.

For a multi-dimensional array, multiply the number of positions in each dimension.

Understanding the Question

The array Product uses two dimensions with these bounds:

• x: 0 to 99
• y: 0 to 9

The question asks for the total number of elements, so you must work out how many possible x values there are, how many possible y values there are, and then multiply them.

Approach

Use this method:

1. Find the number of valid x indices.
2. Find the number of valid y indices.
3. Multiply the two counts.

This is the standard method for any 2D array.

Step-by-Step Reasoning

For x, the lower bound is 0 and the upper bound is 99.
Because the bounds are inclusive:

So there are 100 possible x positions.

For y, the lower bound is 0 and the upper bound is 9.
Again using inclusive counting:

So there are 10 possible y positions.

Now multiply the size of each dimension:

So the array contains 1000 elements in total.

Key Takeaways

• Always use inclusive counting for array bounds unless told otherwise.
• The formula is upper minus lower plus one.
• For 2D arrays, multiply the size of one dimension by the size of the other.

Common Mistakes

• Forgetting the + 1, giving 99 instead of 100 or 9 instead of 10.
• Adding the two dimension sizes instead of multiplying them.
• Confusing total elements with number of dimensions.

Things to Be Careful About

• Bounds from 0 to 99 still give 100 values, not 99.
• Check whether the question gives inclusive bounds, which is the normal interpretation here.
• Keep the dimensions separate until the final multiplication.

Background Concept

In CIE pseudocode, an array declaration must show:

• the identifier name
• that it is an ARRAY
• the bounds for each dimension
• the data type stored in each element

The general pattern is:

DECLARE ArrayName : ARRAY[lower:upper, lower:upper] OF DataType

The data type should match what the array stores.

Understanding the Question

The question tells you that Product stores the number of rejected items each day. It also gives the index ranges:

• x from 0 to 99
• y from 0 to 9

So you must write the full pseudocode declaration for a two-dimensional array with those exact bounds.

Approach

Build the declaration in parts:

1. Start with DECLARE Product.
2. Show that it is an ARRAY.
3. Insert both dimensions with their exact bounds: [0:99, 0:9].
4. Choose the data type stored in each element.

Because the array stores counts of rejected items, INTEGER is the appropriate data type.

Step-by-Step Reasoning

The identifier is Product.

The array has two dimensions because elements are accessed with x and y, so both ranges must appear inside the brackets.

From the table:

• first dimension is 0:99
• second dimension is 0:9

Now decide the element type. The description says the array stores the number of rejected items each day. A number of items is a whole-number count, so INTEGER is suitable.

Putting it together gives:

DECLARE Product : ARRAY[0:99, 0:9] OF INTEGER

That is a complete CIE-style declaration.

Key Takeaways

• Array declarations need name, bounds and element type.
• Multi-dimensional bounds are written in the same bracket list, separated by commas.
• Counts are normally stored as INTEGER.

Common Mistakes

• Omitting one dimension.
• Using round brackets instead of square brackets.
• Writing the bounds incorrectly, for example 1:100 instead of 0:99.
• Leaving out OF INTEGER.
• Using REAL even though the values are counts.

Things to Be Careful About

• Copy the identifier exactly as given: Product.
• Use CIE pseudocode syntax, including DECLARE and ARRAY[...] OF ....
• Bounds must match the question exactly; do not convert them to a size only.
• Since this is Paper 2, write pseudocode, not a declaration from a real programming language.

Background Concept

White-box testing tests the internal paths and logic of a program. The tester uses knowledge of the program structure and chooses data that will make the program follow particular branches.

Here, the bonus module depends on two conditions:

• whether hours worked is between 1 and 40 inclusive, or above 40
• whether value of sales is 2000 or less, or above 2000

These two decisions create four possible logical paths through the module. White-box testing aims to choose inputs that make the program follow selected paths so that the conditions are actually executed.

Understanding the Question

The question gives a decision table for weekly bonus pay and asks for two tests using valid data that will test different paths through the program.

"Valid data" means the values must fit the input rules. For example, hours worked should be sensible positive values, and sales values should be valid numbers.

"Different paths" means your two tests must not both land in the same row of the table. Each test should trigger a different outcome branch.

Approach

Use the bonus table as a set of decision branches. Pick one valid pair of values from one row and another valid pair from a different row.

Then work out the expected bonus from that row.

There are four possible branches:

• 1 to 40 hours and sales 2000 or less gives 0
• 1 to 40 hours and sales above 2000 gives 50
• above 40 hours and sales 2000 or less gives 10
• above 40 hours and sales above 2000 gives 100

Any two different branches would be acceptable.

Step-by-Step Reasoning

For Test One, choose a value that fits the first branch:

• Hours worked = 20, which is between 1 and 40 inclusive
• Value of sales = 1500, which is 2000 or less

Looking at the table, that combination gives:

• Bonus pay = 0

For Test Two, choose a value that fits a different branch, for example the fourth branch:

• Hours worked = 45, which is above 40
• Value of sales = 2500, which is above 2000

Looking at the table, that combination gives:

• Bonus pay = 100

These are both valid inputs, and they make the program follow two different decision paths.

Many other correct answers are possible. For example:

• 35 hours and 2500 sales gives 50
• 50 hours and 1800 sales gives 10

As long as the data is valid and the two tests exercise different rows, the tests are suitable.

Key Takeaways

• White-box testing is about covering internal program paths.
• Use the program logic or decision table to choose test data.
• Each test should be linked to an expected output.
• Different branches need different input combinations.

Common Mistakes

• Giving two tests that follow the same row of the table. That does not test different paths.
• Forgetting to include the expected bonus pay. Test data alone is incomplete.
• Using invalid data when the question explicitly asks for valid data.
• Misreading "2000 or less" and treating 2000 as if it were in the "above 2000" group.

Things to Be Careful About

• "Between 1 and 40 inclusive" means both 1 and 40 are included in that branch.
• "Above 40" means strictly greater than 40.
• "2000 or less" includes exactly 2000.
• Make sure each chosen input pair matches the bonus you state.

Background Concept

When a program is made of several modules, it is often useful to test some parts before the whole program is finished. If one module depends on another unfinished module, the missing part can be simulated.

A stub is a simple temporary module written to stand in for a real module that does not yet exist or is not yet complete. It usually has the same name, parameters, and expected return behaviour as the real module, but instead of carrying out full processing it may simply return a fixed value or display a message.

This allows integration or module testing to begin earlier.

Understanding the Question

The question says that the pay program has several modules and not all of them are complete yet. It asks you to describe stub testing.

So you need to explain:

• what a stub is
• why it is used

The key idea is that unfinished modules are temporarily replaced so testing can still go ahead.

Approach

A good two-mark description needs two points:

1. A stub is a dummy or temporary replacement for a missing module.
2. It allows the rest of the completed program or module to be tested before every part has been finished.

That is enough for full credit.

Step-by-Step Reasoning

Suppose one payroll module calls another module to calculate tax, but the tax module has not been written yet.

Without a replacement, testing the calling module would stop at that point because the required module does not exist.

So a stub can be written instead. The stub would:

• accept the same inputs as the real tax module
• possibly return a simple fixed value
• allow the rest of the program flow to continue

This means the completed parts of the payroll program can be tested now, even though some modules are still missing.

The real module is later substituted for the stub once it has been completed.

Key Takeaways

• A stub is a temporary dummy module.
• It replaces an unfinished called module.
• It helps testing start before the full system is complete.
• It usually mimics the real module's interface and returns simple test data.

Common Mistakes

• Confusing a stub with a driver. A stub stands in for a called module; a driver is used to call the module being tested.
• Saying only that it is used for testing, without explaining that it replaces an unfinished module.
• Describing black-box or white-box testing instead of the specific role of a stub.

Things to Be Careful About

• Use the word "temporary" or "dummy" to show the module is not the final one.
• Mention that the stub allows testing before the whole program is complete.
• If comparing with a driver, keep the roles separate so you do not lose marks through confusion.

Background Concept

Black-box testing checks a program by supplying inputs and comparing the actual outputs with the expected outputs. The tester does not need to know the internal code structure.

Different types of errors exist:

• Syntax errors: mistakes in the language rules, usually found by the compiler or interpreter.
• Logic errors: mistakes in the algorithm or conditions, so the program runs but gives wrong results.
• Run-time errors: errors that happen during execution, such as dividing by zero or using invalid data.

Because the question says the program compiles successfully, syntax errors have already been removed. Black-box testing is especially good at revealing logic problems by showing that outputs do not match what they should be.

Understanding the Question

The program has compiled, and then black-box testing is used. You must identify one type of error that black-box testing could detect and describe it.

Since the program already compiles, the safest answer is a logic error. A black-box tester can enter test values and see that the answer produced is wrong even though the program runs.

Approach

Choose one suitable error type and explain how it would appear from the outside.

The best fit here is:

• logic error

Then describe it as a case where the program executes but produces the wrong pay or bonus for given inputs.

Step-by-Step Reasoning

In this payroll context, black-box testing would involve choosing hours worked and sales values, then checking whether the calculated bonus or total pay matches the expected result from the specification.

If the program compiles and runs, but for a test such as more than 40 hours and more than 2000 sales it outputs 50 instead of 100, that shows a logic error.

The error is not a syntax error, because syntax errors stop successful compilation.

The error is visible purely from the behaviour of the program:

• input is entered
• program runs
• output is compared with expected output
• mismatch shows the logic is wrong

That is why black-box testing can detect this type of error.

Key Takeaways

• Black-box testing checks outputs against expected results.
• If a compiled program gives the wrong answer, the problem is often a logic error.
• Syntax errors are usually found before black-box testing because the program would not compile.
• In real test cases, the specification is used to decide what the output should be.

Common Mistakes

• Saying syntax error. The question says the program compiles successfully, so syntax errors should already have been found.
• Naming a logic error but not describing it. You need both the type and what it means.
• Giving a vague description such as "the program is wrong" without explaining that it runs but gives incorrect output.
• Confusing black-box testing with white-box testing by talking about paths through the code.

Things to Be Careful About

• Link the description to observable behaviour, because black-box testing judges outputs, not code structure.
• Use an error type from the syllabus wording: syntax, logic, or run-time.
• Since the program compiles successfully, logic error is usually the clearest and strongest answer.

Background Concept

This question uses an array-based linked list. Instead of storing each node as a separate dynamic object, two parallel arrays are used:

• Data[Index] stores the value in a node.
• Pointer[Index] stores the index of the next node.

A special value such as -1 is used as a null pointer to mean "there is no next node".

The variable Start tells us where the active list begins. From there, we follow the chain using Pointer[Current].

This procedure is performing a sorted insertion. That means it moves along the linked list until it finds the first value that is not less than the new value. It keeps two positions:

• Current = the node being examined now
• Last = the node just before Current

That pair is very important in linked-list insertion, because when the correct position is found, the new node must be linked between Last and Current.

Understanding the Question

You are given the full contents of the two global arrays and the procedure Place().

You must dry run the call:

CALL Place(1043, 2, 8)

So the starting values are:

• Value = 1043
• Start = 2
• Unused = 8

The trace table only asks for these variables:

• Value
• Start
• Unused
• New
• Last
• Current

That means you trace how those variables change as the procedure runs. You do not need to trace Data and Pointer yet in this part.

Approach

The best way is:

1. Write in the parameter values from the procedure call.
2. Apply the three initial assignments:
   • New ← Unused
   • Last ← NullPointer
   • Current ← Start
3. Follow the WHILE loop step by step.
4. At each loop pass, compare Data[Current] with Value.
5. If the condition is true, update:
   • Last ← Current
   • Current ← Pointer[Current]
6. Stop when Data[Current] is no longer less than Value.

The active linked list starts at index 2, not index 1, so we must follow the list from Start.

Step-by-Step Reasoning

First, identify the active list from Start = 2:

• index 2 has data 1007, pointer 3
• index 3 has data 1010, pointer 1
• index 1 has data 1018, pointer 7
• index 7 has data 1034, pointer 4
• index 4 has data 1056, pointer 6
• index 6 has data 1062, pointer 5
• index 5 has data 1092, pointer -1

So the ordered list is:

1007 -> 1010 -> 1018 -> 1034 -> 1056 -> 1062 -> 1092

Now dry run the procedure.

1. Parameters from the call

Value = 1043, Start = 2, Unused = 8

2. Initialisation

New ← Unused so New = 8

Last ← NullPointer so Last = -1

Current ← Start so Current = 2

3. First loop test

Check:

• Current <> -1 is true because Current = 2
• Data[2] < 1043 means 1007 < 1043, which is true

So the loop runs.

Inside the loop:

• Last ← Current gives Last = 2
• Current ← Pointer[2] gives Current = 3

4. Second loop test

Check Data[3] < 1043:

• 1010 < 1043 is true

So:

• Last = 3
• Current = Pointer[3] = 1

5. Third loop test

Check Data[1] < 1043:

• 1018 < 1043 is true

So:

• Last = 1
• Current = Pointer[1] = 7

6. Fourth loop test

Check Data[7] < 1043:

• 1034 < 1043 is true

So:

• Last = 7
• Current = Pointer[7] = 4

7. Fifth loop test

Check Data[4] < 1043:

• 1056 < 1043 is false

So the loop stops.

The final traced values are therefore:

• New = 8
• Last = 7
• Current = 4

That means the new value will be inserted between node 7 and node 4.

Key Takeaways

• In an array-based linked list, the order of the list is determined by the Pointer array, not by the physical order of indices.
• Current moves through the list; Last stays one node behind.
• For sorted insertion, the loop continues while the current data value is still less than the new value.
• Always begin tracing from Start, then follow Pointer[Current].

Common Mistakes

• Starting at index 1 just because it is the first row of the table. The correct start node is Start = 2.
• Reading the next node from Data[Current] instead of Pointer[Current].
• Forgetting that Last must be updated before Current moves on.
• Continuing past index 4. The loop stops there because 1056 is not less than 1043.
• Treating -1 as a valid array index instead of the null pointer marker.

Things to Be Careful About

• The arrays are 1-indexed here.
• Only the nodes reachable from Start are part of the active linked list.
• The loop condition has two parts joined by AND; both must be true for another iteration.
• This particular procedure works here because the new value is not inserted before the first node. If the new value were smaller than the first item, Last would still be -1, which would need special handling in a full implementation.

Background Concept

To insert a new node into an array-based linked list, three things usually matter:

1. The index of the new unused node
2. The node that comes before the insertion point
3. The node that comes after the insertion point

Those are exactly the roles of:

• New
• Last
• Current

The insertion is done by changing pointers, not by shifting all the later values as you would in a normal array.

For insertion between two existing nodes:

• the new node's pointer should point to the next node
• the previous node's pointer should point to the new node
• the data value is stored in the new node

This preserves the chain of the linked list.

Understanding the Question

This part asks for the contents of the global arrays after the procedure finishes.

So you must use the final values found in part (a)(i), then apply the last three statements of the procedure:

Pointer[New] ← Pointer[Last]
Pointer[Last] ← New
Data[New] ← Value

You are not re-tracing the whole loop here. You are updating the arrays using the result of the trace.

Approach

Use the final position found from the dry run:

• Last = 7
• Current = 4
• New = 8

That means the new node at index 8 must be inserted between index 7 and index 4.

So:

1. Make node 8 point where node 7 used to point.
2. Make node 7 point to node 8.
3. Store 1043 in Data[8].
4. Leave every other entry unchanged.

Step-by-Step Reasoning

From part (a)(i), the loop stopped with:

• Last = 7
• Current = 4
• New = 8

Before insertion:

• Pointer[7] = 4

This means node 7 currently points directly to node 4.

Now apply the statements.

1. Pointer[New] ← Pointer[Last]

Substitute the values:

Pointer[8] ← Pointer[7]

Since Pointer[7] = 4, this gives:

Pointer[8] = 4

So the new node will point to index 4.

2. Pointer[Last] ← New

Substitute the values:

Pointer[7] ← 8

Now node 7 points to node 8.

3. Data[New] ← Value

Substitute the values:

Data[8] ← 1043

So index 8 now stores the new data item.

4. Check the updated chain

The relevant part of the list changes from:

7 -> 4

into:

7 -> 8 -> 4

Since:

• Data[7] = 1034
• Data[8] = 1043
• Data[4] = 1056

this keeps the list in ascending order.

5. Unchanged entries

No other Data or Pointer entries are modified by the procedure, so all remaining rows stay as they were.

Key Takeaways

• In linked-list insertion, you usually change pointers rather than move many data values.
• The order of updates matters conceptually: the new node must point to the next node, then the previous node is redirected to the new node.
• Last, Current, and New together tell you exactly where the insertion happens.
• After insertion, the logical list order may change even though most array rows stay the same.

Common Mistakes

• Setting Pointer[8] to 7 instead of 4. The new node should point forward to the next node, not backward to the previous one.
• Changing Pointer[4]. Node 4 is after the insertion point and does not need to change.
• Forgetting to update Data[8] to 1043.
• Altering rows 9 and 10 even though they are unaffected in the given procedure.
• Thinking the list must be physically rearranged in the array. It is the pointers that create the order.

Things to Be Careful About

• Use the values from the end of part (a)(i), not from the start of the trace.
• Pointer[New] ← Pointer[Last] must use the old value of Pointer[Last] before Pointer[Last] is changed.
• Only indices 7 and 8 change in the Pointer array, and only index 8 changes in the Data array.
• In a full implementation, the head of the unused list would also normally need updating after node 8 is taken, but this question only asks for the effects of the given procedure on Data and Pointer.

Background Concept

Standard arrays are homogeneous data structures. That means every element in the array must have the same data type. If an array is declared as INTEGER, every stored item must be an integer. If an array is declared as STRING, every stored item must be a string.

A 2D array is still just an array. The fact that it has rows and columns does not change the rule: all entries must have the same type.

Understanding the Question

Originally, the Loyalty array was a 2D array of type INTEGER:

• column 1 stored customer IDs
• column 2 stored loyalty points

That worked when customer IDs were integers.

Now the programmer changes the customer ID so that it is stored as a STRING. The question asks why the existing 2D array can no longer be used.

Approach

The answer depends on one key rule: arrays store one data type only. Once customer IDs become strings, the array would need to hold:

• STRING values in column 1
• INTEGER values in column 2

That mixture is not allowed in a normal array of type INTEGER.

Step-by-Step Reasoning

The current array is declared as an integer array. That means every element such as Loyalty[1, 1], Loyalty[1, 2], Loyalty[2, 1], and so on must store integers.

After the change:

• customer ID is a STRING
• loyalty points are still INTEGER

So the array would need mixed data types across its columns. A simple 2D array cannot do that because it is homogeneous.

That is why the existing 2D INTEGER array can no longer be used.

Key Takeaways

• Arrays are homogeneous: all elements must have the same type.
• Changing one field to a different data type can make a previous array design unsuitable.
• Mixed-type records usually need a record-based structure rather than a plain array.

Common Mistakes

• Saying a 2D array cannot store strings at all. It can, but only if the whole array is declared as STRING.
• Saying the problem is the number of columns. The real issue is the mixed data types.
• Forgetting that the original array was specifically an INTEGER array.

Things to Be Careful About

• The important idea is not just that customer IDs changed, but that they changed to a different type from the loyalty points.
• A column-based mental model can be misleading: although we talk about columns, the whole array still has one declared type.
• Use the term STRING and INTEGER clearly because the mark depends on identifying the type mismatch.

Background Concept

When related data items have different types but belong together, a record is a suitable structure. A record groups fields under one name, and each field can have its own data type.

For example, one customer might need:

• CustomerID as a STRING
• Points as an INTEGER

A 1D array can then be used to store many of these records. Each position in the array stores one complete record.

Understanding the Question

The question asks how a 1D array could be used to store both the amended customer ID and the loyalty points.

Because the customer ID is now a string while the points remain integers, a plain numeric 2D array is no longer suitable. The answer needs a structure that can store both values together for each customer.

Approach

Use two levels of structure:

1. A record type for one customer.
2. A 1D array where each element is one customer record.

This keeps the same idea of one stored item per customer, but now each stored item can contain mixed data types.

Step-by-Step Reasoning

First, define a record type such as:

• CustomerID : STRING
• Points : INTEGER

That creates a single structure representing one customer.

Then declare a 1D array of this record type. Conceptually, it would work like this:

• Loyalty[1] stores the first customer's full record
• Loyalty[2] stores the second customer's full record
• and so on up to the limit of 1000 customers

Each array element contains both fields. So for one customer you could access:

• Loyalty[Row].CustomerID
• Loyalty[Row].Points

This solves the mixed-type problem because the array stores records, and each record field can have its own type.

Key Takeaways

• A record groups related fields of different data types.
• A 1D array of records is a common way to store many similar entities.
• Each array element can represent one real-world object, such as one customer.

Common Mistakes

• Suggesting two separate 1D arrays without explaining how they stay linked. That can work in some designs, but this question strongly points toward storing both values together.
• Saying a 1D array alone can directly store both strings and integers. It cannot unless each element is a record or similar composite type.
• Forgetting to state the types of the two fields.

Things to Be Careful About

• Make it clear that the 1D array stores records, not raw values of mixed types.
• Each element represents one customer, so both pieces of data must be in the same record.
• The customer limit still applies, so the array would still need space for up to 1000 records.