4.13.1.3–4.13.1.4 - Implementing, debugging and testing a solution (C#)
Turn a design into C# data and instructions, develop the most important behaviour first, and use tests, logical reasoning and user feedback to judge the resulting solution.
This route uses native written-code practice with no Run. Its status is incomplete: runnable support pending; AQA Paper 1 itself is an onscreen practical examination. The original examples here are independent practice, rather than a live examination skeleton or a learner's assessed project.
Implementing models and algorithms
A design becomes a working implementation only when its data model and algorithms are expressed as data structures and instructions the computer can execute.
A venue has numbered rooms. Its model records the number of free places in each room; an int[] is suitable when room positions are fixed and each value is a whole number. Array index 0 represents the first room. A requirement such as “find the first room with a free place” becomes an algorithm that examines the array in order and returns the first suitable index. The method's interface states what it receives and what it returns; -1 represents “no suitable room”.
static int FirstAvailable(int[] freePlaces)
{
for (int room = 0; room < freePlaces.Length; room++)
{
if (freePlaces[room] > 0)
{
return room;
}
}
return -1;
}
Assume freePlaces is a non-null array of non-negative integers. With { 0, 0, 3, 2 }, the method checks indices 0 and 1, then returns 2. It does not inspect index 3. With { 0, 0 }, it reaches the return after the loop and returns -1. With an empty array, the loop runs zero times and also returns -1. Stating assumptions matters: this method does not validate a missing array or an impossible negative room capacity.
Debugging locates and corrects the cause of a defect. A syntax error, such as a missing semicolon, prevents compilation. A runtime error, such as accessing freePlaces[freePlaces.Length], occurs during execution. A logic error can execute without an exception but produce the wrong answer: returning a room number of room + 1 would violate an interface that promises an array index. Trace the values and control flow; change the identified cause; repeat the failing test and relevant earlier tests. An error message is a clue, rather than proof that the highlighted line is the original cause.
Critical-path prototyping
Iterative development builds and checks a solution in small revisions instead of assuming the first implementation is final.
Prototype
A prototype is an early, limited implementation used to investigate an idea, a risk or a requirement and obtain feedback before further development.
For the venue system, the critical path is the chain of essential behaviour that makes a booking possible: identify a room with sufficient capacity, reserve the places without double-booking, and retain the booking. Attractive colour themes do not help if two customers can reserve the same final place. Work on the essential behaviour and the largest uncertainty first; “critical” refers to dependencies and successful operation, rather than whichever feature is easiest to demonstrate.
An early prototype might use a fixed small array and a simple text interface. Trace the allocation algorithm and check capacity updates before adding file persistence. Then build and test saving/reloading, because losing bookings is a critical failure. Show the prototype to intended users: they may need the room name as well as its number, or a clear explanation when no room is available. Record what was learned, revise the requirements or design where justified, and implement the next small increment.
An agile approach emphasises repeated increments, testing and feedback, allowing priorities to change as understanding improves. It is not permission to omit design, tests or evidence. A disposable prototype may be replaced once the uncertainty is resolved; an evolutionary prototype may be carefully developed into the final system. In either case, temporary shortcuts must not silently become final assumptions. After adding persistence, repeat allocation tests as regression tests to check that earlier correct behaviour still works.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account