2026 Cambridge IAS-Level Computer Science (9618) 模拟试题及答案详解

(a) (i)
+77 in 8-bit binary:
64 + 8 + 4 + 1 = 01001101
Invert all bits (one's complement): 10110010
Add 1: 10110011
(Verification: -128 + 32 + 16 + 2 + 1 = -77)

(ii)
Hexadecimal B4 to binary:
B = 1011, 4 = 0100
Binary value: 10110100
Since MSB is 1, the number is negative.
Method 1 (Place values):
-128 + 32 + 16 + 4 = -128 + 52 = -76
Method 2 (Invert and add 1):
Invert bits: 01001011
Add 1: 01001100 (= 64 + 8 + 4 = 76) => -76

(b) (i)
0101 1100 (92)
+ 0011 1010 (58)
-----------
1001 0110 (-106 in two's complement)
Working shown with carry bits: carry into bit 7.

(ii)
Yes, overflow occurred.
Justification: Two positive integers (MSB = 0) were added together and produced a negative result (MSB = 1), OR the denary sum 92 + 58 = 150 exceeds the maximum value that can be represented in an 8-bit signed two's complement register (+127).

(c) (i)
3 = 0011
8 = 1000
9 = 1001
BCD representation: 0011 1000 1001

(ii)
Each decimal digit can be directly converted and sent to display hardware (such as 7-segment displays) without requiring division or complex conversion algorithms.

(d) (i)
Gibi is a binary prefix representing 2^30 (1,073,741,824) bytes, whereas giga is a decimal (SI) prefix representing 10^9 (1,000,000,000) bytes.

(ii)
1 GiB = 1024 MiB (2^10 MiB)
4 GiB = 4 * 1024 = 4096 MiB

(a) (i) 1 mark for correct working (e.g. converting 77 to 01001101 and inverting/adding 1, or correct place value assignment); 1 mark for correct final binary: 10110011 [2]

(ii) 1 mark for converting B4 to 8-bit binary (10110100); 1 mark for calculating correct denary value: -76 [2]

(b) (i) 1 mark for carry bits/working shown; 1 mark for correct binary answer: 10010110 [2]

(ii) 1 mark for stating that overflow has occurred; 1 mark for a valid justification (e.g. addition of two positive numbers yields a negative result / 150 is outside the range -128 to +127 for 8-bit two's complement) [2]

(c) (i) 1 mark for 0011 1000 1001 (allow spaces or no spaces) [1]

(ii) 1 mark for valid benefit: easy/direct conversion to drive separate display digits / no need for complex arithmetic conversion [1]

(d) (i) 1 mark for explanation that gibi is base 2 / 2^30 while giga is base 10 / 10^9 [1]

(ii) 1 mark for 4096 (MiB) [1]

(a) (i)
Memory management is responsible for:
- Allocating and deallocating RAM/primary memory to active programs/processes.
- Protecting memory space so that running processes do not overwrite or interfere with each other's allocated memory.
- Managing virtual memory / paging when physical RAM is insufficient.

(a) (ii)
Advantage 1: Memory efficiency / shared RAM
- Explanation: Multiple programs can share a single copy of the DLL loaded in RAM simultaneously, reducing total memory usage.

Advantage 2: Independent updates / modular maintenance
- Explanation: The DLL file can be modified, bug-fixed, or upgraded independently without the need to recompile or relink the main executable application.

(Other valid advantage: Smaller executable file size because the code for the library functions does not need to be compiled directly into the binary file).

(b) (i)
An open-source licence gives users legal permission to access, view, modify, and redistribute the original source code.

(b) (ii)
Shareware is proprietary software provided free of charge for a limited trial period (or with limited functionality) and does not provide source code, whereas open-source software provides full access to the underlying source code and usually permits continuous use without licence expiry.

(b) (iii)
Two benefits to Dania:
1. Community contribution: Other developers can test the software, fix bugs, and contribute enhancements or new features.
2. Greater visibility/adoption: Users can freely try and trust the application, which may promote her reputation and drive sales of the commercial edition.

(a)(i) [Max 2 marks]
- MP1: Allocates/assigns blocks of primary memory (RAM) to running applications/processes.
- MP2: Protects memory spaces / prevents processes from overwriting each other's data/code.
- MP3: Frees up/deallocates memory when programs terminate.
- MP4: Manages virtual memory / swapping when RAM is full.

(a)(ii) [4 marks: 1 mark for each advantage identified, 1 mark for corresponding explanation, max 2 pairs]
- MP1: Reduced main memory / RAM usage...
- MP2: ...because one copy of the library can be shared across multiple applications running simultaneously.
- MP3: Independent maintenance / updates...
- MP4: ...because DLL files can be updated or patched without recompiling or relinking the main executable program.
- MP5: Smaller executable file size / saves secondary storage...
- MP6: ...because the library routines are not linked into the compiled binary at compile time.

(b)(i) [1 mark]
- MP1: Source code is made available to users (who are free to view/edit/redistribute it).

(b)(ii) [1 mark]
- MP1: Open-source provides source code whereas shareware is closed-source / Shareware is typically trial software requiring future payment whereas open-source does not expire in this way.

(b)(iii) [2 marks: 1 mark per valid benefit, max 2]
- MP1: Community contributions (developers can fix bugs, optimize code, add features).
- MP2: Increased adoption / user base / widespread testing across different platforms.
- MP3: Enhances developer reputation / acts as marketing for the commercial version.

Part (a)
- (i) `LDM #84` uses the `#` symbol to specify an actual numeric constant, which is Immediate addressing.
- (ii) `LDD 150` specifies a memory address directly where the operand is stored, which is Direct addressing.
- (iii) `LDX 200` calculates the effective address by adding the contents of the Index Register (`IX`) to the base address 200, which is Indexed addressing.

Part (b)
Step-by-step trace of the program:
1. First iteration (`IX = 0`, `[91] = 3`):
- `52: LDX 80` -> ACC = contents of `80 + 0` = 7
- `53: AND #1` -> ACC = `7 AND 1` = 1
- `54: CMI #0` -> Comparison result is FALSE (1 ≠ 0)
- `55: JPE SKIP` -> No jump
- `56: LDD 90` -> ACC = 0
- `57: INC ACC` -> ACC = 1
- `58: STO 90` -> Location 90 = 1
- `59: SKIP: INC IX` -> IX = 1
- `60: LDD 91` -> ACC = 3
- `61: DEC ACC` -> ACC = 2
- `62: STO 91` -> Location 91 = 2
- `63: CMI #0` -> Comparison result is FALSE (2 ≠ 0)
- `64: JPN LOOP` -> Jumps to LOOP (address 52)

2. Second iteration (`IX = 1`, `[91] = 2`):
- `52: LDX 80` -> ACC = contents of `80 + 1` = 4
- `53: AND #1` -> ACC = `4 AND 1` = 0
- `54: CMI #0` -> Comparison result is TRUE (0 = 0)
- `55: JPE SKIP` -> Jumps to address 59 (SKIP)
- `59: INC IX` -> IX = 2
- `60: LDD 91` -> ACC = 2
- `61: DEC ACC` -> ACC = 1
- `62: STO 91` -> Location 91 = 1
- `63: CMI #0` -> Comparison result is FALSE (1 ≠ 0)
- `64: JPN LOOP` -> Jumps to LOOP (address 52)

3. Third iteration (`IX = 2`, `[91] = 1`):
- `52: LDX 80` -> ACC = contents of `80 + 2` = 5
- `53: AND #1` -> ACC = `5 AND 1` = 1
- `54: CMI #0` -> Comparison result is FALSE (1 ≠ 0)
- `55: JPE SKIP` -> No jump
- `56: LDD 90` -> ACC = 1
- `57: INC ACC` -> ACC = 2
- `58: STO 90` -> Location 90 = 2
- `59: SKIP: INC IX` -> IX = 3
- `60: LDD 91` -> ACC = 1
- `61: DEC ACC` -> ACC = 0
- `62: STO 91` -> Location 91 = 0
- `63: CMI #0` -> Comparison result is TRUE (0 = 0)
- `64: JPN LOOP` -> Does not jump; falls through to `65: END`.

Part (c)
- (i) Bitwise AND with 1 checks the least significant bit (LSB). If LSB is 1, the number is odd; if 0, the number is even.
- (ii) Final value in Location 90 is 2. It represents the count of odd numbers found in the array across memory locations 80, 81, and 82 (7 and 5 are odd).

Part (a) [3 marks]
- (i) 1 mark for Immediate (addressing)
- (ii) 1 mark for Direct (addressing)
- (iii) 1 mark for Indexed (addressing)

Part (b) [4 marks]
- 1 mark for correct ACC and IX values during Iteration 1 (`ACC: 7 -> 1 -> 0 -> 1 -> 3 -> 2`, `IX: 1`, `[90] = 1`, `[91] = 2`).
- 1 mark for correct execution of Iteration 2 skipping the increment (`ACC: 4 -> 0 -> 2 -> 1`, `IX: 2`, `[91] = 1`, `[90]` unchanged).
- 1 mark for correct execution of Iteration 3 (`ACC: 5 -> 1 -> 1 -> 2 -> 1 -> 0`, `IX: 3`, `[90] = 2`, `[91] = 0`).
- 1 mark for terminating cleanly after 3 iterations with no extra lines traced.

Part (c) [2 marks]
- (i) 1 mark for stating that it masks/extracts the least significant bit (LSB) / tests if the number is odd or even.
- (ii) 1 mark for stating value is `2` AND explaining that it is the count/number of odd values in the array / memory locations 80 to 82.

(a) Disadvantages of flat-file approach:
1. Data Redundancy: Information such as owner names and contact details are stored multiple times for every vessel or service booking, wasting storage capacity and increasing input effort.
2. Data Inconsistency / Update Anomalies: If an owner changes their telephone number, updating it in one record but missing another leads to conflicting data.
(Accept: Program-data dependence, lack of concurrency/security controls, deletion/insertion anomalies).

(b) (i) Referential integrity means that every foreign key value in a child table must match a valid, existing primary key value in the referenced parent table, or be null.
(ii) The DBMS can prevent/reject the deletion of the parent record if matching child records exist, OR it can perform a cascading delete (automatically deleting all corresponding records in the child table).

(c) (i) A relation is in 2NF if it is in 1NF and contains no partial functional dependencies (all non-key attributes must be fully functionally dependent on the entire composite primary key). In `VESSEL_SERVICE`, attributes such as `VesselName`, `OwnerID`, `OwnerName`, and `OwnerPhone` depend only on `VesselID`, not on `ServiceDate`.

(ii) 3NF Relations:
- `OWNER(OwnerID, OwnerName, OwnerPhone)` where `OwnerID` is the primary key.
- `VESSEL(VesselID, VesselName, OwnerID*)` where `VesselID` is the primary key and `OwnerID` is a foreign key referencing `OWNER`.
- `SERVICE_TYPE(ServiceCode, ServiceDescription, ServiceCost)` where `ServiceCode` is the primary key.
- `SERVICE_BOOKING(VesselID*, ServiceDate, ServiceCode*)` where `(VesselID, ServiceDate)` forms the composite primary key, and `VesselID` and `ServiceCode` are foreign keys.
(Note: If `ServiceDescription` and `ServiceCost` are kept with `ServiceCode` in `SERVICE_BOOKING` without a separate lookup table, or if `SERVICE_TYPE` is normalized out due to transitive dependency `ServiceDate -> ServiceCode -> ServiceDescription, ServiceCost`, full 3NF requires isolating the transitive dependency).

(d) (i) SQL DDL:
```sql
CREATE TABLE VESSEL (
VesselID VARCHAR(6),
VesselName VARCHAR(40),
LengthMetres REAL,
BerthID INTEGER,
OwnerID VARCHAR(6),
PRIMARY KEY (VesselID),
FOREIGN KEY (OwnerID) REFERENCES OWNER(OwnerID)
);
```

(ii) SQL DML:
```sql
SELECT VESSEL.VesselName, VESSEL.LengthMetres, OWNER.FullName
FROM VESSEL
INNER JOIN OWNER ON VESSEL.OwnerID = OWNER.OwnerID
WHERE VESSEL.LengthMetres > 12.0
ORDER BY VESSEL.LengthMetres ASC;
```

Part (a) [Max 4 marks]:
- 1 mark for each disadvantage identified (max 2).
- 1 mark for accompanying expansion/consequence in context (max 2).
- Data redundancy (1): Duplicate data stored for multiple bookings/vessels, causing wasted storage (1).
- Data inconsistency / Update anomaly (1): Changing data in one file/record may leave outdated data in another (1).
- Program-data dependence (1): Changes to the file structure require modifications to all application programs accessing it (1).
- Poor security/access control (1): Cannot easily restrict access to specific fields or records for different users (1).

Part (b)(i) [2 marks]:
- Foreign key in a table must reference a valid/existing primary key in the related table (1).
- Ensures relationships between tables remain consistent / prevents orphaned records (1).

Part (b)(ii) [2 marks]:
- Rejects/blocks the deletion operation with an error message (1).
- OR implements cascading delete, removing matching records in the child table (1).
- (Accept: Sets foreign key to NULL if allowed by schema constraints) (1).

Part (c)(i) [2 marks]:
- Defines partial dependency / states non-key attributes depend on only part of the primary key (1).
- Identifies specific attributes (e.g., `VesselName`, `OwnerID`, `OwnerName`, `OwnerPhone`) that depend only on `VesselID` rather than `(VesselID, ServiceDate)` (1).

Part (c)(ii) [4 marks]:
- 1 mark for `OWNER` table correctly formed with `OwnerID` as primary key.
- 1 mark for `VESSEL` table correctly formed with `VesselID` as primary key and `OwnerID` as foreign key.
- 1 mark for `SERVICE_BOOKING` (or `VESSEL_SERVICE`) table correctly formed with composite key `(VesselID, ServiceDate)`.
- 1 mark for removing transitive dependency (`ServiceCode` -> `ServiceDescription`, `ServiceCost`) into a separate `SERVICE_TYPE` table with primary key `ServiceCode`.

Part (d)(i) [2 marks]:
- 1 mark for `CREATE TABLE VESSEL (...)` with correct column names and valid Cambridge data types (`VARCHAR(6)`, `VARCHAR(40)`, `REAL`, `INTEGER`).
- 1 mark for correct `PRIMARY KEY (VesselID)` and `FOREIGN KEY (OwnerID) REFERENCES OWNER(OwnerID)` syntax.

Part (d)(ii) [2 marks]:
- 1 mark for `SELECT VesselName, LengthMetres, FullName` and `FROM VESSEL INNER JOIN OWNER ON VESSEL.OwnerID = OWNER.OwnerID` (or `FROM VESSEL, OWNER WHERE VESSEL.OwnerID = OWNER.OwnerID`).
- 1 mark for correct `WHERE LengthMetres > 12.0` (or `AND LengthMetres > 12.0`) AND `ORDER BY LengthMetres [ASC]`.

(a)(i)
Image resolution is the total number of pixels that make up the image, commonly expressed as width × height (or pixels per unit of measurement).

(a)(ii)
Colour depth is the number of bits allocated to each pixel to represent its colour, determining the total number of distinct colours that can be displayed.

(b)
Step 1: Calculate total number of bits:
\(1024 \times 768 \times 16\text{ bits}\)

Step 2: Convert bits to bytes (divide by 8):
\((1024 \times 768 \times 16) / 8 = 1024 \times 768 \times 2 = 1\,572\,864\text{ bytes}\)

Step 3: Convert bytes to kibibytes (divide by 1024):
\(1\,572\,864 / 1024 = 768 \times 2 = 1536\text{ KiB}\)

(c)
Two items of metadata stored in a bitmap file header include:
1. Image dimensions (width and height in pixels)
2. Colour depth / bit depth (bits per pixel)
(Also acceptable: file size, compression method, file format signature / magic number).

(d)
- Flat-colour diagrams contain large contiguous areas where adjacent pixels have identical colour values. RLE compresses these by storing a single colour code and a count of repetitions (run length), significantly reducing the required data.
- Photographs feature subtle gradients and continuous variations in colour between adjacent pixels. Consequently, runs of identical pixels rarely occur (most run lengths are 1), meaning the overhead of storing counts along with pixel data can result in negligible compression or even an increase in overall file size.

(a)(i) 1 mark:
- Number of pixels in an image // image dimensions given as width × height (in pixels).
[Reject: vague answers like 'how clear the image is' without technical qualification]

(a)(ii) 1 mark:
- Number of bits used to represent each pixel // number of bits used per pixel to define colour.

(b) 3 marks:
- MP1: Correct multiplication of dimensions and colour depth (\(1024 \times 768 \times 16\)) [1]
- MP2: Correct division by 8 (to bytes) and division by 1024 (to KiB) [1]
- MP3: Correct final answer of 1536 (KiB) [1]
(Allow full 3 marks for correct answer with clear working)

(c) 2 marks (1 mark per valid item, max 2):
- Width / height / dimensions / resolution
- Colour depth / bit depth
- Total file size / header size
- Compression type / method used
- Offset to start of pixel data // file signature / identifier / 'BM'

(d) 2 marks (1 mark for each contrasting explanation):
- MP1 (Diagrams): Diagrams have long sequences of adjacent identical pixels / large areas of uniform colour, producing long runs that compress significantly. [1]
- MP2 (Photographs): Photographs have adjacent pixels with slight colour variations / few identical consecutive pixels, leading to run lengths of 1 which yields little compression / increases file size. [1]

Part (a)

Translate the scenario into Boolean logic components:
1. "air temperature does NOT exceed the safe limit AND grain moisture is detected":
$$\text{NOT } A \text{ AND } C$$
2. "air flow rate is adequate AND grain moisture is NOT detected":
$$B \text{ AND NOT } C$$
3. Combine both conditions with the OR operator:
$$X = (\text{NOT } A \text{ AND } C) \text{ OR } (B \text{ AND NOT } C)$$

---

Part (b)

Evaluate the expression for each row of the truth table:
- Row 1: \(A=0, B=0, C=0\) $\rightarrow (1 \text{ AND } 0) \text{ OR } (0 \text{ AND } 1) = 0 \text{ OR } 0 = \mathbf{0}$
- Row 2: \(A=0, B=0, C=1\) $\rightarrow (1 \text{ AND } 1) \text{ OR } (0 \text{ AND } 0) = 1 \text{ OR } 0 = \mathbf{1}$
- Row 3: \(A=0, B=1, C=0\) $\rightarrow (1 \text{ AND } 0) \text{ OR } (1 \text{ AND } 1) = 0 \text{ OR } 1 = \mathbf{1}$
- Row 4: \(A=0, B=1, C=1\) $\rightarrow (1 \text{ AND } 1) \text{ OR } (1 \text{ AND } 0) = 1 \text{ OR } 0 = \mathbf{1}$
- Row 5: \(A=1, B=0, C=0\) $\rightarrow (0 \text{ AND } 0) \text{ OR } (0 \text{ AND } 1) = 0 \text{ OR } 0 = \mathbf{0}$
- Row 6: \(A=1, B=0, C=1\) $\rightarrow (0 \text{ AND } 1) \text{ OR } (0 \text{ AND } 0) = 0 \text{ OR } 0 = \mathbf{0}$
- Row 7: \(A=1, B=1, C=0\) $\rightarrow (0 \text{ AND } 0) \text{ OR } (1 \text{ AND } 1) = 0 \text{ OR } 1 = \mathbf{1}$
- Row 8: \(A=1, B=1, C=1\) $\rightarrow (0 \text{ AND } 1) \text{ OR } (1 \text{ AND } 0) = 0 \text{ OR } 0 = \mathbf{0}$

(a) 1 mark for each correct clause, maximum 2 marks:
- MP1: \((\text{NOT } A \text{ AND } C)\)
- MP2: \((B \text{ AND NOT } C)\) with correct final \(\text{OR}\) joining the two terms
*(Accept equivalent standard Boolean notation, e.g., \(\overline{A} \cdot C + B \cdot \overline{C}\) or \((\neg A \wedge C) \vee (B \wedge \neg C)\))*

(b) 2 marks for truth table output column \(X\):
- 2 marks for all 8 rows correct (0, 1, 1, 1, 0, 0, 1, 0)
- 1 mark for 6 or 7 rows correct
- 0 marks for fewer than 6 rows correct
(Allow follow-through from an incorrect expression in part (a))

(a)
- When two or more devices transmit simultaneously, a collision is detected via signal voltage change.
- A jamming signal / collision signal is transmitted across the bus to inform all connected nodes.
- Data transmission is aborted / ceased immediately.
- Each station waits a random (or pseudo-random) time period before listening to the medium again to retransmit.

(b)(i)
- The subnet mask defines the boundary between the network portion (Network ID / prefix) and the host portion (Host ID) of an IP address.
- When applied via a bitwise AND logic operation to an IP address, it allows the device/router to determine if the destination IP address belongs to the same local subnet or needs to be forwarded to a default gateway/router.

(b)(ii)
- Exhaustion of available unique 32-bit IPv4 addresses (due to the exponential growth of internet-connected devices), whereas IPv6 provides 128-bit addresses giving a vastly larger address space.

(c)(i)
- Real-time bit streaming broadcasts live media content as it occurs (cannot be paused, rewound, or fast-forwarded beyond the live edge).
- On-demand bit streaming delivers pre-recorded media files stored on a server, allowing user control (play, pause, rewind, fast-forward) and retrieval at any requested time.

(c)(ii)
- The buffer acts as a temporary memory store for incoming streaming data packets to smooth out jitter / network transmission speed fluctuations and maintain continuous playback.
- If the transmission bit rate falls below the playback bit rate and the buffer runs out of data, playback stalls / pauses / freezes (rebuffering occurs).

(d)
- The client browser queries a DNS resolver / local DNS server with the domain name `www.swifthaul-logistics.com`.
- The DNS resolver queries hierarchical DNS servers (Root DNS server, `.com` Top-Level Domain (TLD) server, and authoritative name server) to locate the domain record.
- The authoritative DNS server returns the associated IP address to the DNS resolver, which sends it back to the client's web browser (and caches it) so the browser can connect directly to the web server.

(a) Maximum 3 marks:
- 1 mark: Jamming signal is broadcast / sent to notify all devices on the network.
- 1 mark: Transmission is immediately halted / aborted.
- 1 mark: Devices wait for a random / pseudo-random period of time before attempting retransmission / checking if the line is idle.

(b)(i) Maximum 2 marks:
- 1 mark: Identifies/separates the Network ID and Host ID within an IP address.
- 1 mark: Used (via bitwise AND) to determine whether the destination host is on the same local subnet or an external/remote network.

(b)(ii) 1 mark:
- 1 mark: Running out of available IPv4 addresses / IPv6 provides a substantially larger address pool (128 bits vs 32 bits).

(c)(i) Maximum 2 marks:
- 1 mark: Real-time bit streaming is for live broadcasts / cannot be paused or fast-forwarded to future points.
- 1 mark: On-demand streaming uses pre-recorded media stored on a server / allows full user playback controls (e.g. pause, fast-forward, rewind).

(c)(ii) Maximum 2 marks:
- 1 mark: Buffer stores incoming media data ahead of playback to prevent interruptions from variations in network transmission rate / jitter.
- 1 mark: If the buffer empties (download rate < playback rate), video playback pauses/freezes/rebuffers.

(d) Maximum 3 marks:
- 1 mark: Browser/resolver queries DNS server hierarchy (e.g. Root, TLD, authoritative DNS servers).
- 1 mark: DNS server maps/translates the domain name (`www.swifthaul-logistics.com`) into its corresponding IP address.
- 1 mark: IP address is returned to the client browser to establish the direct connection to the host server.

1. A post-condition loop (`REPEAT ... UNTIL`) always executes its loop body at least once before evaluating the condition.
2. In an input validation routine, the user must be prompted and provide an initial value before any validation check can occur. Using a pre-condition loop (`WHILE ... ENDWHILE`) would require an extra input statement outside and before the loop to initialise the variable, resulting in duplicate code.

1 mark per point (max 2 marks):
- MP1: A post-condition loop always executes the loop body / statements at least once before evaluating the condition.
- MP2: The input / value must be entered/obtained at least once before it can be validated // avoids duplicate prompt/input code before the loop.

(a) (i)
`IsExpress <- (DeliveryType = "NextDay" OR Weight <= 2.5) AND NOT (Destination = "Remote")`
Alternative for condition: `AND Destination <> "Remote"`

(a) (ii)
Evaluation:
- `DeliveryType = "NextDay"` evaluates to `FALSE`
- `Weight <= 2.5` evaluates to `FALSE` (since 3.2 > 2.5)
- `(FALSE OR FALSE)` evaluates to `FALSE`
- `Destination <> "Remote"` evaluates to `TRUE`
- `FALSE AND TRUE` evaluates to `FALSE`.
Result: `FALSE`

(b) (i)
- Breakpoint: A point set by the programmer where program execution temporarily halts/pauses.
- Watch window: Allows the developer to inspect and monitor the current values/states of specific variables at that paused point (or as the code is stepped through line by line) to detect when an unexpected value is generated.

(b) (ii)
- Code presentation feature:
- Syntax highlighting / Colour coding: Displays keywords, strings, variables, and comments in distinct colours to make code structure clear and spot unclosed strings or misspelled keywords.
- Automatic indentation / Pretty printing: Automatically aligns blocks of code (such as IF blocks or loops) to visually distinguish nesting and improve readability.
- Code writing feature:
- Auto-completion / IntelliSense: Automatically suggests or autocompletes keyword, variable, or function names as the user types, speeding up coding and reducing syntax/spelling mistakes.
- Auto-brackets / Delimiter matching: Automatically closes opened parentheses/quotes or highlights matching pairs, preventing missing closing delimiter syntax errors.

(a) (i) 1 mark per bullet point (max 2):
- `(DeliveryType = "NextDay" OR Weight <= 2.5)` (correct bracketed condition / relational operators)
- `... AND (Destination <> "Remote")` OR `... AND NOT (Destination = "Remote")` with complete correct assignment to `IsExpress <-`

(a) (ii) 1 mark:
- `FALSE`

(b) (i) 1 mark per bullet point (max 2):
- Breakpoint stops / pauses execution at a designated line/point.
- Watch window displays the value/state of chosen variables at runtime / during stepping to see where values change incorrectly.

(b) (ii) 1 mark per bullet point (max 2):
- Presentation feature: 1 mark for naming an appropriate feature (e.g. Syntax highlighting, Auto-indentation) AND describing its benefit (e.g. visual distinction of keywords/scope, easier readability).
- Writing feature: 1 mark for naming an appropriate feature (e.g. Auto-complete/IntelliSense, Bracket matching) AND describing its benefit (e.g. reduces spelling/syntax errors, faster typing).

(a)
- Normal: e.g. 20.0 (or any value strictly between 5.0 and 32.0). Expected outcome: Data accepted / processed normally.
- Boundary (extreme): 5.0 or 32.0 (or 4.9 / 32.1 if treated as just outside boundary). Expected outcome: Data accepted (for 5.0 or 32.0) or rejected (for 4.9 or 32.1).
- Abnormal: e.g. 1.5, 45.0, -5.0, or "abc". Expected outcome: Data rejected / error message displayed.

(b)
- Black-box testing examines the functionality and outputs based on the software specifications/inputs without inspecting or having knowledge of the internal program structure or source code.
- White-box testing examines the internal structure and logic of the source code to ensure that every logical path and branch is executed and tested.

(c)
- A stub is a temporary, dummy subroutine / placeholder function with simple/fixed return values.
- It is used during testing to simulate the interface and behavior of a module that has not yet been written or fully integrated, allowing higher-level modules to be tested independently.

(d)
- Task 1: Perfective maintenance (accept Adaptive maintenance if justified as adapting to a new business policy).
- Task 2: Corrective maintenance.

(a) 1 mark per correct row (value + valid expected outcome matched): [Max 3]
- Normal: 1 mark for any valid number in the range 5.1 to 31.9 (or within 5.0 to 32.0) AND expected outcome is Accepted / Valid.
- Boundary: 1 mark for 5.0 or 32.0 AND expected outcome is Accepted / Valid (also accept 4.9 or 32.1 if outcome is Rejected / Error).
- Abnormal: 1 mark for any value < 5.0, > 32.0, negative number, or non-numeric input AND expected outcome is Rejected / Error message.

(b) 1 mark per point: [Max 2]
- MP1: Black-box testing tests functionality / input-output against specification without access to / knowledge of the internal code structure.
- MP2: White-box testing uses knowledge of the internal code / algorithms to test every path / branch / condition.

(c) 1 mark per point: [Max 2]
- MP1: A dummy / placeholder module / routine that contains minimal or predetermined code/output.
- MP2: Allows calling / dependent modules to be tested before the called module has been implemented / written.

(d) 1 mark per point: [Max 2]
- Task 1: Perfective (maintenance) [Also accept: Adaptive (maintenance)] (1 mark)
- Task 2: Corrective (maintenance) (1 mark)

An example Structured English algorithm:

1. Initialise `VacantCount` to 0 and `FaultyCount` to 0.
2. FOR each locker from index 1 to 50:
- IF `LockerStatus[index]` = "VACANT" THEN
- Increment `VacantCount` by 1
- ELSE IF `LockerStatus[index]` = "FAULTY" THEN
- Increment `FaultyCount` by 1
- ENDIF
3. IF `VacantCount` < 5 THEN
- OUTPUT "Low Availability"
4. OUTPUT `VacantCount` and `FaultyCount`.

1 mark for each of the following points (Max 4):
- MP1: Initialise both counting variables to 0 before the loop.
- MP2: Loop iterating through all 50 elements of the array (e.g., FOR 1 to 50 / for each element in `LockerStatus`).
- MP3: Correctly checking locker status for `"VACANT"` and `"FAULTY"` and incrementing the corresponding count.
- MP4: Conditional check for vacant count < 5 with output of alert message AND outputting the final counts of vacant and faulty lockers.

A complete pseudocode solution in standard Cambridge 9618 format:

```text
FUNCTION ValidateParcelCode(ParcelCode : STRING) RETURNS BOOLEAN
DECLARE Index : INTEGER
DECLARE NextChar : CHAR

IF LENGTH(ParcelCode) <> 9 THEN
RETURN FALSE
ENDIF

FOR Index <- 1 TO 2
NextChar <- MID(ParcelCode, Index, 1)
IF NextChar < 'A' OR NextChar > 'Z' THEN
RETURN FALSE
ENDIF
NEXT Index

FOR Index <- 3 TO 8
NextChar <- MID(ParcelCode, Index, 1)
IF NextChar < '0' OR NextChar > '9' THEN
RETURN FALSE
ENDIF
NEXT Index

NextChar <- MID(ParcelCode, 9, 1)
IF NextChar <> 'X' AND NextChar <> 'Y' THEN
RETURN FALSE
ENDIF

RETURN TRUE
ENDFUNCTION
```

Alternative approaches using a single Boolean flag variable initialized to `TRUE` and set to `FALSE` upon any failed check are equally acceptable.

1 mark for each of the following points (Max 5):
- MP1: Correct `FUNCTION` header and `ENDFUNCTION` / `RETURN` (function name `ValidateParcelCode`, parameter `ParcelCode : STRING` or `BYVAL ParcelCode : STRING`, and `RETURNS BOOLEAN`).
- MP2: Check that `LENGTH(ParcelCode)` is equal to 9 (or handles length <> 9 correctly by returning / setting `FALSE`).
- MP3: Valid iteration or explicit checks testing that characters at positions 1 and 2 are each between 'A' and 'Z'.
- MP4: Valid iteration (e.g. `FOR Index <- 3 TO 8`) or equivalent checks testing that characters at positions 3 to 8 are each between '0' and '9'.
- MP5: Check that character at position 9 is either 'X' or 'Y', AND returning `TRUE` only if all validation rules are satisfied.

(a) (i) "08"
(ii) "8841"

(b)
```text
FUNCTION ExtractField(RecordText : STRING, Delimiter : CHAR, FieldIndex : INTEGER) RETURNS STRING
DECLARE CurrentField : INTEGER
DECLARE ResultString : STRING
DECLARE Index : INTEGER
DECLARE NextChar : CHAR

CurrentField <- 1
ResultString <- ""

FOR Index <- 1 TO LENGTH(RecordText)
NextChar <- MID(RecordText, Index, 1)
IF NextChar = Delimiter THEN
CurrentField <- CurrentField + 1
ELSE
IF CurrentField = FieldIndex THEN
ResultString <- ResultString & NextChar
ENDIF
ENDIF
NEXT Index

RETURN ResultString
ENDFUNCTION
```

(c)
```text
PROCEDURE ProcessDeliveries()
DECLARE LineData : STRING
DECLARE ItemStatus : STRING
DECLARE ItemWeightStr : STRING
DECLARE ItemWeight : REAL
DECLARE TotalCount : INTEGER
DECLARE TotalWeight : REAL

TotalCount <- 0
TotalWeight <- 0.0

OPENFILE "Deliveries.txt" FOR READ
WHILE NOT EOF("Deliveries.txt") DO
READFILE "Deliveries.txt", LineData
ItemStatus <- ExtractField(LineData, '', 4)
IF ItemStatus = "D" THEN
ItemWeightStr <- ExtractField(LineData, '', 3)
ItemWeight <- STRING_TO_NUM(ItemWeightStr)
TotalCount <- TotalCount + 1
TotalWeight <- TotalWeight + ItemWeight
ENDIF
ENDWHILE
CLOSEFILE "Deliveries.txt"

OUTPUT "Total delivered packages: ", TotalCount
OUTPUT "Total delivered weight: ", TotalWeight
ENDPROCEDURE
```

(a)(i) 1 mark for:
- "08"

(a)(ii) 1 mark for:
- "8841"

(b) 1 mark for each of the following up to max 5:
- MP1: Correct function header with all 3 parameters and return type `STRING` + `ENDFUNCTION`
- MP2: Initialising current field counter (e.g. to 1) and result string (e.g. to empty string)
- MP3: Loop iterating through each character of `RecordText` from 1 to `LENGTH(RecordText)`
- MP4: Checking if current character equals `Delimiter` and incrementing field counter
- MP5: Appending character to result string when current field matches `FieldIndex` AND returning the result

(c) 1 mark for each of the following up to max 5:
- MP1: Opening `"Deliveries.txt"` for `READ` AND closing file with `CLOSEFILE`
- MP2: Initialising `TotalCount` to 0 and `TotalWeight` to 0.0 before file loop
- MP3: Loop reading lines until `EOF("Deliveries.txt")`
- MP4: Calling `ExtractField` for status and weight AND checking if status is `"D"`
- MP5: Converting weight to numeric, updating running count and total weight, and outputting totals with suitable messages

### Part (a)
- In a FIFO structure, the first element added is the first one processed and removed.
- New items enter at the tail (rear) and are accessed/removed from the head (front).

### Part (b)
Step-by-step trace:
- Initial state: `HeadPointer` = 4, `TailPointer` = 1, `QueueLength` = 4. Queue contains elements at indices 4 ("P41"), 5 ("P62"), 6 ("P75"), 1 ("P88").
1. Dequeue: Item at index 4 ("P41") is removed. `HeadPointer` becomes 5, `QueueLength` becomes 3.
2. Enqueue "P94": `TailPointer` moves from 1 to 2. `DispatchQueue[2]` = "P94", `QueueLength` becomes 4.
3. Dequeue: Item at index 5 ("P62") is removed. `HeadPointer` becomes 6, `QueueLength` becomes 3.
4. Enqueue "P12": `TailPointer` moves from 2 to 3. `DispatchQueue[3]` = "P12", `QueueLength` becomes 4.

Final values:
- `HeadPointer` = 6
- `TailPointer` = 3
- `QueueLength` = 4
- Elements in array: Index 1 = "P88", Index 2 = "P94", Index 3 = "P12", Index 6 = "P75" (Indices 4 and 5 are empty / inactive).

### Part (c)
```
FUNCTION Enqueue(NewParcel : STRING) RETURNS BOOLEAN
IF QueueLength = MAX_SIZE THEN
OUTPUT "Queue is full"
RETURN FALSE
ELSE
IF TailPointer = MAX_SIZE THEN
TailPointer <- 1
ELSE
TailPointer <- TailPointer + 1
ENDIF
DispatchQueue[TailPointer] <- NewParcel
QueueLength <- QueueLength + 1
RETURN TRUE
ENDIF
ENDFUNCTION
```

Part (a) [2 Marks]
- MP1: State that the first element added to the data structure is the first one to be removed / processed. [1]
- MP2: Addition/insertion occurs at the rear/tail and removal/deletion occurs at the front/head. [1]

Part (b) [4 Marks]
- MP1: `HeadPointer = 6` [1]
- MP2: `TailPointer = 3` [1]
- MP3: `QueueLength = 4` [1]
- MP4: Array contents correctly showing `"P88"` at 1, `"P94"` at 2, `"P12"` at 3, and `"P75"` at 6 (slots 4 and 5 empty or marked inactive). [1]

Part (c) [6 Marks]
- MP1: Correct `FUNCTION` header with parameter `NewParcel : STRING` and `RETURNS BOOLEAN` (and corresponding `ENDFUNCTION`). [1]
- MP2: Check for full queue condition (`QueueLength = MAX_SIZE` or `QueueLength = 6`). [1]
- MP3: Output error message and `RETURN FALSE` when full. [1]
- MP4: Correctly update `TailPointer` using wrap-around logic (checking `TailPointer = MAX_SIZE` or using `MOD`). [1]
- MP5: Assign `NewParcel` to `DispatchQueue[TailPointer]` and increment `QueueLength <- QueueLength + 1`. [1]
- MP6: `RETURN TRUE` after successful insertion. [1]

Step-by-step trace of the algorithm:

1. Initialisation (lines 01–03):
- `Total` is set to `0`
- `Count` is set to `0`
- `Index` is set to `1`

2. Iteration 1 (`Index = 1`):
- Condition `Index <= 6` (1 <= 6) is `TRUE`
- `Value <- DataList[1] = 12`
- `12 MOD 2 = 0` is `TRUE` (THEN branch)
- `Total <- 0 + 12 = 12`
- `Count <- 0 + 1 = 1`
- `Index <- 1 + 1 = 2`

3. Iteration 2 (`Index = 2`):
- Condition `Index <= 6` (2 <= 6) is `TRUE`
- `Value <- DataList[2] = 5`
- `5 MOD 2 = 0` is `FALSE` (ELSE branch)
- `Total <- 12 - 5 = 7`
- `Count` remains unchanged
- `Index <- 2 + 2 = 4`

4. Iteration 3 (`Index = 4`):
- Condition `Index <= 6` (4 <= 6) is `TRUE`
- `Value <- DataList[4] = 14`
- `14 MOD 2 = 0` is `TRUE` (THEN branch)
- `Total <- 7 + 14 = 21`
- `Count <- 1 + 1 = 2`
- `Index <- 4 + 1 = 5`

5. Iteration 4 (`Index = 5`):
- Condition `Index <= 6` (5 <= 6) is `TRUE`
- `Value <- DataList[5] = 7`
- `7 MOD 2 = 0` is `FALSE` (ELSE branch)
- `Total <- 21 - 7 = 14`
- `Count` remains unchanged
- `Index <- 5 + 2 = 7`

6. Loop Termination and Output:
- Condition `Index <= 6` (7 <= 6) is `FALSE`
- Loop terminates
- `OUTPUT "Result: ", Total, " Items: ", Count` produces `Result: 14 Items: 2`

Completed Trace Table:

| Total | Count | Index | Value | OUTPUT |
| :---: | :---: | :---: | :---: | :---: |
| 0 | 0 | 1 | | |
| 12 | 1 | 2 | 12 | |
| 7 | | 4 | 5 | |
| 21 | 2 | 5 | 14 | |
| 14 | | 7 | 7 | |
| | | | | Result: 14 Items: 2 |

1 mark per correct row / functional component (Max 6 marks):
- MP1: Correct initial values entered (`Total = 0`, `Count = 0`, `Index = 1`).
- MP2: Correct trace for 1st iteration (`Value = 12`, `Total = 12`, `Count = 1`, `Index = 2`).
- MP3: Correct trace for 2nd iteration (`Value = 5`, `Total = 7`, `Index = 4`, `Count` not changed / left blank).
- MP4: Correct trace for 3rd iteration (`Value = 14`, `Total = 21`, `Count = 2`, `Index = 5`).
- MP5: Correct trace for 4th iteration (`Value = 7`, `Total = 14`, `Index = 7`, `Count` not changed / left blank).
- MP6: Correct final output string (`Result: 14 Items: 2`).

(a) Record Definition:
```
TYPE SensorReading
DECLARE SampleID : STRING
DECLARE Temperature : REAL
DECLARE Salinity : REAL
DECLARE Status : CHAR
ENDTYPE
```

(b) 2D Array Declaration:
```
DECLARE GridReadings : ARRAY[1:8, 1:5] OF SensorReading
```

(c) Procedure `InitialiseGrid`:
```
PROCEDURE InitialiseGrid()
DECLARE Sector : INTEGER
DECLARE Depth : INTEGER
FOR Sector <- 1 TO 8
FOR Depth <- 1 TO 5
GridReadings[Sector, Depth].SampleID <- ""
GridReadings[Sector, Depth].Temperature <- -99.0
GridReadings[Sector, Depth].Salinity <- -99.0
GridReadings[Sector, Depth].Status <- 'F'
NEXT Depth
NEXT Sector
ENDPROCEDURE
```

(d) Function `CalculateSectorAverage`:
```
FUNCTION CalculateSectorAverage(BYREF GridReadings : ARRAY, BYVAL SectorNum : INTEGER) RETURNS REAL
DECLARE Depth : INTEGER
DECLARE ActiveCount : INTEGER
DECLARE TempSum : REAL

ActiveCount <- 0
TempSum <- 0.0

FOR Depth <- 1 TO 5
IF GridReadings[SectorNum, Depth].Status = 'A' THEN
TempSum <- TempSum + GridReadings[SectorNum, Depth].Temperature
ActiveCount <- ActiveCount + 1
ENDIF
NEXT Depth

IF ActiveCount > 0 THEN
RETURN TempSum / ActiveCount
ELSE
RETURN -1.0
ENDIF
ENDFUNCTION
```

(e) Procedure `GenerateReport`:
```
PROCEDURE GenerateReport()
DECLARE Sector : INTEGER
DECLARE ValidCount : INTEGER
DECLARE AvgTemp : REAL
DECLARE DailyAverages : ARRAY[1:8] OF REAL

ValidCount <- 0

FOR Sector <- 1 TO 8
AvgTemp <- CalculateSectorAverage(GridReadings, Sector)
DailyAverages[Sector] <- AvgTemp

IF AvgTemp <> -1.0 THEN
ValidCount <- ValidCount + 1
IF AvgTemp > 21.5 THEN
OUTPUT "Sector exceeding threshold: ", Sector
ENDIF
ENDIF
NEXT Sector

OUTPUT "Total sectors with valid data: ", ValidCount
ENDPROCEDURE
```

(a) [3 marks]
- 1 mark: `TYPE SensorReading` and `ENDTYPE` keywords used correctly.
- 1 mark: `SampleID : STRING` and `Status : CHAR` correctly typed.
- 1 mark: `Temperature : REAL` and `Salinity : REAL` correctly typed.

(b) [2 marks]
- 1 mark: `DECLARE GridReadings : ARRAY[1:8, 1:5]` (correct dimensions and lower/upper bounds).
- 1 mark: `OF SensorReading` (correct type specifier).

(c) [4 marks]
- 1 mark: Correct procedure header `PROCEDURE InitialiseGrid()` and `ENDPROCEDURE`.
- 1 mark: Nested loops iterating over sectors (1 to 8) and depth levels (1 to 5).
- 1 mark: Correct dot notation targeting array elements (e.g. `GridReadings[Sector, Depth].`).
- 1 mark: All four fields initialised to specified values (`""`, `-99.0`, `-99.0`, `'F'`).

(d) [5 marks]
- 1 mark: Correct function header with parameters (array and integer `SectorNum`) and return type `RETURNS REAL`.
- 1 mark: Initialisation of running sum (to `0.0`) and active count (to `0`).
- 1 mark: Loop through depths 1 to 5 checking condition `Status = 'A'`.
- 1 mark: Accumulating `Temperature` and incrementing active count within selection construct.
- 1 mark: Checking if `ActiveCount > 0`, returning calculated mean (`TempSum / ActiveCount`), otherwise returning `-1.0`.

(e) [4 marks]
- 1 mark: Loop from 1 to 8 calling `CalculateSectorAverage(GridReadings, Sector)` and assigning to `DailyAverages[Sector]`.
- 1 mark: Correctly checking for valid average (`AvgTemp <> -1.0` or `DailyAverages[Sector] <> -1.0`) and incrementing counter.
- 1 mark: Comparing valid average to `> 21.5` and outputting the sector number.
- 1 mark: Outputting the total count of valid sectors outside the loop with a descriptive message.