4.13.1.3–4.13.1.4 - Implementing, debugging and testing a solution (Java)

Implementing models and algorithms

Implementation turns a model of a problem and its algorithms into data structures and instructions that a computer can execute.

A small venue has 12 places. A booking requests between 1 and 6 places and must not exceed the remaining capacity. The model keeps the number already booked as an integer. Its essential invariant is that this number stays between 0 and 12 inclusive. An algorithm checks a request before changing that state. Java implements the model with an int and the algorithm with selection and a method.

public class Main {
    private static final int CAPACITY = 12;

    static int reserve(int booked, int requested) {
        if (requested < 1 || requested > 6) {
            return booked;
        }
        if (booked + requested > CAPACITY) {
            return booked;
        }
        return booked + requested;
    }

    public static void main(String[] args) {
        int booked = 8;
        booked = reserve(booked, 3);
        System.out.println(booked);
        booked = reserve(booked, 2);
        System.out.println(booked);
        booked = reserve(booked, 1);
        System.out.println(booked);
    }
}

The predicted output is 11, 11, then 12, on separate lines. The first request fits. The second would make 13, so it returns the existing 11. The third exactly fills the venue and is accepted. Assigning each returned value to booked matters: returning a value does not itself change the caller's variable. The input state is assumed valid; this method is not a repair routine for a corrupt saved total.

A larger system might represent each booking with an identifier, a customer and a quantity, and store those records in a collection or file. Choose the representation that preserves the needed relationships and operations. Merely writing a screen does not implement the underlying booking rules.

Integer parameters cannot contain "three", but text from an input field can. Input conversion therefore belongs at an interface boundary. The following written task includes that boundary as well as the booking rule.

Critical-path prototyping

An early prototype should resolve the uncertainty that could prevent the whole solution from working.

For the venue, the critical path is the chain that accepts a request, checks the remaining places and records the correct new total. If two requests can oversell the venue, polished colours and a receipt layout will not make the solution useful. First build a small version of that chain with simple inputs and a visible total. Check the logic and get feedback on whether rejected requests are explained clearly. Add features such as customer details and receipt formatting after the core works.

An iterative process repeats implementation, testing, feedback and revision. An agile approach can organise this into small increments with priorities that are reviewed as evidence arrives. For example, a receptionist might explain that bookings must survive closing the application. The next increment can add persistent storage and test saving and loading before decorative changes. Requirements still matter: iteration does not mean changing the objective whenever a defect appears.

Record what a prototype demonstrated and what it did not. A version with one operator and an in-memory total may validate the booking rule but provide no evidence about simultaneous users or storage failures. A prototype may be refined into the final solution or replaced once it has answered its question.