Code, Explanations and Solutions Companion

Companion to Object Oriented Development and Agile Practices

This section contains the official code companions, lab walkthroughs, and verified solutions for each chapter of Object Oriented Development and Agile Practices.

Companion Content Structure

Every chapter’s companion provides:

1. Executable Java Code Listings: Production-quality Java classes and suites conforming to the running Campus Equipment Lending System.
2. Step-by-Step Code Walkthroughs: Line-by-line analyses of design decisions, type safety, invariants, and exception handling.
3. Lab Solutions & Exercises: Model answers for both required core labs and optional team extensions.
4. Verification Records & Fault Experiments: Documented test suite outputs (mvn verify), mutation/fault analysis records, and reproducible compiler checks.
5. Delta Versions: Clear listings of new or modified files built on top of preceding chapter versions.

Select a chapter or appendix companion from the sidebar or table of contents to view its complete code listings and solutions.

📘 Note on Appendices: Code companions are provided for Appendices A, B, C, and F (which contain runnable listings, diagnostic code, and validation tools). Appendix D (Project Versions and Glossary) and Appendix E (Critical Reading and Project Evidence) are comprehensive non-code reference guides contained directly within the main textbook.

Chapter 1 Companion: Code, Explanations and Solutions

Companion to Chapter 1: Developing Software That Can Change
OO Development and Agile Practices

This file brings together the chapter’s Java code, explanations, suggested solutions and teaching notes. All code is included directly below; no archive or separate source files are needed to read it. To run an example, copy each complete listing into the filename shown above it.

The solutions are intended for the instructor or for students after attempting the activities. They support the existing chapter and do not introduce a new assessment. The Java examples are small orientation exercises, not the complete Campus Equipment Lending System.

1 Java code and explanations

1.1 The reservation rule

Filename: ReservationRules.java

public final class ReservationRules {
    public boolean mayRequest(int activeReservations, int requestedDays) {
        return activeReservations >= 0
                && activeReservations < 3
                && requestedDays >= 1
                && requestedDays <= 7;
    }
}

The method answers whether two supplied numbers satisfy the initial student policy. The count is measured before adding a proposed reservation. A maximum of three active reservations therefore requires the existing count to be less than three.

For mayRequest(2, 7), all four conditions hold. For mayRequest(3, 7), the second condition fails. The method has no fields to modify and makes no database or service calls. It does not identify a borrower, check equipment availability or record a reservation.

1.2 Calling the rule

Filename: Chapter01Demo.java

public class Chapter01Demo {
    public static void main(String[] args) {
        ReservationRules rules = new ReservationRules();
        System.out.println(rules.mayRequest(2, 7));
        System.out.println(rules.mayRequest(3, 7));
    }
}

new ReservationRules() creates the object on which the method is called. The first call uses a permitted count and the maximum permitted duration. The second call uses an existing count that has already reached the limit. Printing the returned values makes the difference visible without building a user interface.

From a directory containing both files, use a Java Development Kit:

javac ReservationRules.java Chapter01Demo.java
java Chapter01Demo

Expected output:

true
false

The first call does not increase any count. Each call evaluates only its own supplied arguments. Consequently, calling mayRequest(2, 7) repeatedly returns the same result; the complete application would have to update its reservation records separately.

1.3 Repeatable checks

Filename: Chapter01Checks.java

This instructor example makes the expected results explicit. It needs no testing library and is not intended to teach the full testing approach introduced in Chapter 7.

public class Chapter01Checks {
    public static void main(String[] args) {
        ReservationRules rules = new ReservationRules();
        // Explicit expected results derived from the chapter's initial rules.
        int[][] cases = {
            {0, 1, 1},
            {2, 7, 1},
            {3, 1, 0},
            {1, 8, 0},
            {-1, 1, 0},
            {1, 0, 0},
            {3, 7, 0},
            {0, 7, 1},
            {2, 1, 1},
            {4, 2, 0},
            {1, -1, 0},
            {0, 14, 0}
        };
        for (int[] example : cases) {
            boolean expected = example[2] == 1;
            boolean actual = rules.mayRequest(example[0], example[1]);
            if (actual != expected) {
                throw new AssertionError(
                    "mayRequest(" + example[0] + ", " + example[1]
                    + ") expected " + expected + " but got " + actual);
            }
        }
        System.out.println("All " + cases.length + " chapter checks passed.");
    }
}

Each row contains an existing count, a requested duration and an expected result. In this small data table, 1 means expected true and 0 means expected false. The last value is converted to a Boolean before comparison; this is a convenience for the example, not a general domain-modelling recommendation.

The loop calls the rule for each row and compares the actual result with the expectation. If they differ, it throws an AssertionError with the input and both results. This explicit exception works without enabling Java’s optional assert statements. The runner stops at the first mismatch.

Compile and run all three files:

javac ReservationRules.java Chapter01Demo.java Chapter01Checks.java
java Chapter01Demo
java Chapter01Checks

The check runner’s successful output is:

All 12 chapter checks passed.

These checks cover the diagnostic cases and several nearby boundaries. They do not prove that the larger application is correct, and they do not test the future staff policy, which the original class does not implement.

2 A deliberate fault and its correction

Make a temporary copy of the source before trying this example. Inside mayRequest, change only the final comparison:

// Deliberately faulty replacement expression, not a complete class.
&& requestedDays < 7;

The modified class still compiles, but it rejects a seven-day request. For an existing count of two and a requested duration of seven, the original returns true while the faulty version returns false.

Recompile the temporary copy and run Chapter01Checks. Its first failing case reports:

mayRequest(2, 7) expected true but got false

The correction is to restore requestedDays <= 7. The requirement includes seven days, so the expectation comes from the stated policy. A check using only a two-day request would not distinguish the two versions.

An additional count-boundary example

Consider a different edit: replacing activeReservations < 3 with activeReservations <= 3. A borrower who already has three active reservations would then be permitted to request another. Running Chapter01Checks against this version stops at the first affected row:

mayRequest(3, 1) expected false but got true

The case mayRequest(3, 7) would also fail, but the runner stops at the first mismatch, and (3, 1) appears earlier in the table. This illustrates why we test the point where a new request would exceed the total allowance.

3 Suggested solutions and teaching notes

Suggested facilitation

Start by asking students to explain what “the program works” means in the opening scenario. Ask for one successful case, then one case that should be rejected. Reveal the staff change and let students identify what information is missing from the method.

Use paper tracing or a short live demonstration for the code. Give students time to predict the output before running it. Ask a second student to review the reason for the answer rather than merely announce agreement.

Complete the AI critique using the supplied teaching response, which is constructed for the exercise and labelled as such in the chapter. Live AI access is optional and unnecessary. Do not present the example data as evidence about a real model’s measured performance. Finish by asking each student for one specific next learning action.

Use the Common mistakes table in Section 1.8 of the chapter as a debrief: ask students which row they were closest to making during the diagnostic.

Diagnostic answers

Task A

The class is ReservationRules; the method is mayRequest; both parameters are int; the return type is boolean. There are no fields, assignments to shared state, storage calls or reservation creation operations. Calling the method neither increments a count nor reserves equipment. Its returned value is narrower than overall eligibility or confirmation.

Avoid teaching that final makes all Java objects immutable. Here it prevents subclassing. The absence of mutable state and the body of the method explain the relevant absence of state changes.

Task B

mayRequest(2, 7) distinguishes the implementations. The original returns true; the faulty < 7 implementation returns false. The original agrees with the explicit inclusive maximum of seven days. Any input using seven days and a valid count from zero to two is an acceptable counterexample.

The supplied checks also catch an accidental < 3 to <= 3 change, through the cases with three existing reservations. A passing check suite is evidence for these selected cases, not proof of every aspect of a future reservation application.

Task C

Students should preserve a maximum of three active reservations and seven requested days for students, while supporting five and fourteen for staff. Counts are measured before the new reservation is added. Some trustworthy representation of borrower category is required; an additional Boolean or category parameter can demonstrate the idea, but real callers must not grant privileges merely because a user claims a category.

Suitable unresolved questions include the treatment of unknown categories, how category is obtained, or whether someone holding both roles uses one particular policy. Do not require students to guess the institution’s policy.

Useful acceptance examples for the changed rule include:

Four well-chosen examples are enough for the student task; they should cover both categories and meaningful limits. Negative counts and non-positive durations remain invalid for both. These decisions still do not establish availability.

The evidence statement should name checks that could fail, not only reassurance. A strong answer might read: “I would need the six acceptance examples to give the expected results, the original student checks to still pass unchanged, and a reviewer to confirm from the diff that student limits were not edited. This would not show that the category is trustworthy, that availability is checked, or that the examples match the equipment officer’s intent.” Weak answers say only that the code works or that all tests pass.

A small conditional with an explicit category is an acceptable initial approach. Its advantage is directness; a cost is that repeated category conditions may spread if more policy decisions appear. Passing limits into a shared calculation can also be reasonable, but moves the obligation to select and validate those limits to a caller. Accept either with a coherent rationale. Do not reward early creation of an interface hierarchy just for using patterns.

AI activity answers

The numeric comparisons and Boolean result in the supplied explanation are supported by the code. The database claim is false as a claim about this method: its body has only comparisons and a return expression. It receives neither an item identifier nor a period, and performs no call to any database or availability service.

The larger application’s availability behaviour is unknown from this class. Strong answers distinguish “this method does not query a database” from “the whole application never queries a database.”

An acceptable corrected explanation is: “The method returns true when the supplied count is non-negative and below three, and the requested duration is from one to seven days inclusive. It does not change state or create a reservation. Availability and the accuracy of the supplied count must be handled elsewhere.”

Review-question guidance

1. A rule duplicated across several screens and services may pass today’s examples but require coordinated edits tomorrow. Name the risk of inconsistent copies rather than simply calling the code ugly.
2. An iteration is a repeated period of development and feedback. An increment adds usable capability, such as a reservation flow. One iteration might refine that flow without adding a new feature, so the terms are not interchangeable.
3. Tests cover selected expectations. A test that incorrectly expects students to borrow for fourteen days could pass alongside an equally incorrect implementation. Compare expectations with the clarified policy.
4. Allowing staff fourteen days adds behaviour. Reorganising the same rule without changing its observable outcomes is refactoring. Knowing the intention helps a reviewer decide whether a changed result is a defect or an intended feature.
5. A student with zero active reservations requesting eight days should still be rejected. Replacing all limits with staff limits would accept that request. Staff-only checks do not protect student behaviour.
6. Tests and implementation may share the same misunderstood requirement. Review expected results independently against agreed examples, especially category distinctions and boundaries, then execute the relevant checks.

Transfer-challenge guidance

One acceptable assumption is that durations are supplied as positive whole hours and counts refer to active confirmed bookings before adding another. Other clearly stated duration models are acceptable. Students should raise the policy for unknown groups and define what “active” means.

A society with two active bookings requesting one hour must be rejected; a department with the same count and duration may be allowed under the numeric rules. A society with zero bookings requesting three hours provides another useful distinction. Checks of room availability need a room identity and a requested time interval; count and duration alone cannot establish that a room is free.

Readiness and feedback

Do not convert the checklist into an unannounced assessment. A syntax gap suggests focused Java revision. Correct tracing with weak explanations suggests peer walkthroughs. A tendency to infer database behaviour from a name suggests more exercises separating local behaviour from system assumptions.

Useful feedback names the reasoning gap: “You used the staff limit for the student case” is more actionable than “Your answer lacks understanding.” Ask students to revise one answer after feedback so the chapter’s feedback loop becomes an experienced practice.

Scope and continuity checks

• The orientation example is intentionally smaller than the complete project. It introduces no full reservation storage or date model.
• The student edition contains no unseen assessment change variant. The staff variation is an introductory worked teaching case.
• Full TDD belongs in Chapter 7, SOLID in Chapters 5–6, and systematic refactoring in Chapter 11.
• The critical review remains governed by the current module brief. No new AI-use policy or grading rubric is introduced.

4 Use in later chapters

Chapter 1 asks students to plan the staff change, not implement a complete redesign. Suggested acceptance examples and design alternatives therefore appear in the solutions without adding a premature implementation. Later chapters will develop the running system, introduce more explicit responsibilities, and test the resulting changes.

Chapter 2 Companion: Code, Explanations and Solutions

Companion to Chapter 2: Object-Oriented Development Beyond Syntax
OO Development and Agile Practices

This file contains the complete Java examples, instructions, explanations, suggested solutions and instructor notes. Read Sections 1–3 to assemble and run the starting version. Attempt the student chapter’s activity before reading Section 4 onwards.

All source code is included below. Copy each complete listing into the stated filename. The two coordinator listings are alternatives: keep only one ReservationCoordinator.java in a given working directory. The deliberate fault fragments are labelled and are not additional source files.

1 Starting point and execution

Create a new working directory and save these six files in it:

Use a JDK 17 or newer capable of compiling the Java 17 language/API baseline. No preview feature, external library or build-tool installation is required here. Use plain text filenames with the exact capitalisation shown.

For this small version, the files use Java’s unnamed package so they can be compiled together in one directory. This is a teaching setup, not the proposed organisation of the complete application. Later application-structure work will introduce named packages and a standard project layout.

Compile in that directory:

javac --release 17 -d out ReservationRules.java LoanPeriod.java Reservation.java ReservationCoordinator.java Chapter02Demo.java Chapter02Checks.java
java -cp out Chapter02Demo
java -cp out Chapter02Checks

The demonstration should print:

Confirmed: R1 for B1 on CAM1 [2026-10-20, 2026-10-22).
Rejected: item unavailable.
Confirmed: R2 for B2 on CAM1 [2026-10-22, 2026-10-23).
Stored: 2

The checks should print:

All 34 chapter checks passed.

After changing the source, compile again before rerunning. Otherwise, the JVM may execute old class files and give misleading evidence about the new source. For a fresh output directory, choose a new directory name with -d and use that same name with -cp.

This is an orientation toolchain, not a complete release process. The later build and CI chapters will establish automated project-wide commands. The code here uses no database, network access, AI account or real university data.

2 Complete starting source

2.1 ReservationRules.java

This is exactly the class used in Chapter 1. It has no mutable instance state. Its inputs are the existing active count and requested number of days. The coordinator supplies the count; the rule does not retrieve it.

The staff-policy variation is not implemented in this version. Applying the same rule to every supplied borrower identifier is intentional and must remain clear when demonstrating the program.

public final class ReservationRules {
    public boolean mayRequest(int activeReservations, int requestedDays) {
        return activeReservations >= 0
                && activeReservations < 3
                && requestedDays >= 1
                && requestedDays <= 7;
    }
}

2.2 LoanPeriod.java

The constructor establishes a local invariant: both dates exist and the end is strictly after the start. Objects.requireNonNull throws NullPointerException on missing dates; a zero-length or reversed interval throws IllegalArgumentException.

The two comparisons in overlaps implement the stated half-open interval convention. Both must hold. Returning the dates is safe because LocalDate is immutable. A general getter returning a mutable object would require a different analysis.

import java.time.LocalDate;
import java.util.Objects;

public final class LoanPeriod {
    private final LocalDate start;
    private final LocalDate endExclusive;

    public LoanPeriod(LocalDate start, LocalDate endExclusive) {
        this.start = Objects.requireNonNull(start, "start");
        this.endExclusive = Objects.requireNonNull(endExclusive, "endExclusive");
        if (!start.isBefore(endExclusive)) {
            throw new IllegalArgumentException("End must be after start.");
        }
    }

    public LocalDate start() {
        return start;
    }

    public LocalDate endExclusive() {
        return endExclusive;
    }

    public boolean overlaps(LoanPeriod other) {
        Objects.requireNonNull(other, "other");
        return start.isBefore(other.endExclusive)
                && other.start.isBefore(endExclusive);
    }
}

2.3 Reservation.java

The identifiers must be non-null and non-blank, and the period must be non-null. The class does not verify that an identifier exists in a university catalogue. It preserves identifier text exactly, including case and any non-blank surrounding whitespace.

All fields are final, and their reachable values are immutable in this example. There are no setters. final on the class prevents subclassing but does not, by itself, create immutability. Equality by reservation identifier has not been implemented; inherited equals still uses object identity.

import java.util.Objects;

public final class Reservation {
    private final String id;
    private final String borrowerId;
    private final String itemId;
    private final LoanPeriod period;

    public Reservation(String id, String borrowerId, String itemId,
                       LoanPeriod period) {
        this.id = requireText(id);
        this.borrowerId = requireText(borrowerId);
        this.itemId = requireText(itemId);
        this.period = Objects.requireNonNull(period, "period");
    }

    private static String requireText(String value) {
        if (value == null || value.isBlank()) {
            throw new IllegalArgumentException("Identifiers must not be blank.");
        }
        return value;
    }

    public String id() { return id; }
    public String borrowerId() { return borrowerId; }
    public String itemId() { return itemId; }
    public LoanPeriod period() { return period; }
}

2.4 ReservationCoordinator.java starting version

The public method validates its arguments, counts this borrower’s records, applies the numeric policy, checks conflicts for the requested item and finally stores a successful reservation. It constructs a confirmation message; it does not send it.

Every stored record is considered active. The class has no cancellation, completion or expiry operation. R1, R2 and later identifiers are unique only within this coordinator while its append-only list is retained. A new coordinator starts again at R1; this is not a globally unique identifier strategy.

A policy rejection is returned before an availability rejection when both conditions would fail. The refactoring must preserve that order. Validation exceptions and rejections occur before adding a record. An unrepresentable end date, such as one day after LocalDate.MAX, also fails before storage. Date exceptions should be handled appropriately if a later user interface accepts arbitrary dates.

import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public final class ReservationCoordinator {
    private final List<Reservation> reservations = new ArrayList<>();
    private final ReservationRules rules = new ReservationRules();

    public String reserve(String borrowerId, String itemId,
                          LocalDate start, int requestedDays) {
        if (borrowerId == null || borrowerId.isBlank()
                || itemId == null || itemId.isBlank()) {
            throw new IllegalArgumentException("Identifiers must not be blank.");
        }
        Objects.requireNonNull(start, "start");

        int activeCount = 0;
        for (Reservation existing : reservations) {
            if (existing.borrowerId().equals(borrowerId)) {
                activeCount++;
            }
        }
        if (!rules.mayRequest(activeCount, requestedDays)) {
            return "Rejected: borrower limit or duration.";
        }

        LoanPeriod requested = new LoanPeriod(
                start, start.plusDays(requestedDays));
        for (Reservation existing : reservations) {
            if (existing.itemId().equals(itemId)
                    && existing.period().overlaps(requested)) {
                return "Rejected: item unavailable.";
            }
        }

        Reservation reservation = new Reservation(
                "R" + (reservations.size() + 1), borrowerId, itemId, requested);
        reservations.add(reservation);
        return "Confirmed: " + reservation.id()
                + " for " + reservation.borrowerId()
                + " on " + reservation.itemId()
                + " [" + reservation.period().start()
                + ", " + reservation.period().endExclusive() + ").";
    }

    public List<Reservation> reservations() {
        return List.copyOf(reservations);
    }
}

2.5 Chapter02Demo.java

The first request occupies CAM1 on 20 and 21 October. The second intersects that period and is rejected. The third begins on the exclusive end date and is accepted. The different borrower identifiers ensure that this demonstration examines equipment availability rather than reaching one borrower’s reservation limit.

import java.time.LocalDate;

public class Chapter02Demo {
    public static void main(String[] args) {
        ReservationCoordinator coordinator = new ReservationCoordinator();
        LocalDate start = LocalDate.of(2026, 10, 20);
        System.out.println(coordinator.reserve("B1", "CAM1", start, 2));
        System.out.println(coordinator.reserve("B2", "CAM1", start.plusDays(1), 1));
        System.out.println(coordinator.reserve("B2", "CAM1", start.plusDays(2), 1));
        System.out.println("Stored: " + coordinator.reservations().size());
    }
}

3 Supplied checks

This runner makes expectations explicit without introducing a test framework before Chapter 7. You may use it without understanding every helper immediately. The check helper throws on a false condition. The expect helper verifies that an operation throws the expected exception type or a subtype. It uses explicit AssertionError instances rather than Java’s optional assert statements.

The checks cover interval relationships, constructor validity, exact confirmations, failed requests, counts, snapshots and selected exceptional inputs. Inspect the expected values against the requirements; the mere existence of a runner does not establish that its expectations are correct.

3.1 Chapter02Checks.java

The counter measures successful checks for this supplied example. It is not a design-quality score, a coverage percentage or a measure of a student’s contribution.

import java.time.DateTimeException;
import java.time.LocalDate;
import java.util.List;

public class Chapter02Checks {
    private static int checks;

    public static void main(String[] args) {
        LocalDate day = LocalDate.of(2026, 10, 20);
        LoanPeriod first = new LoanPeriod(day, day.plusDays(2));
        LoanPeriod overlapping = new LoanPeriod(day.plusDays(1), day.plusDays(3));
        LoanPeriod adjacent = new LoanPeriod(day.plusDays(2), day.plusDays(3));
        check(first.overlaps(overlapping), "overlap detected");
        check(overlapping.overlaps(first), "overlap is symmetric");
        check(!first.overlaps(adjacent), "adjacent periods allowed");
        check(!adjacent.overlaps(first), "adjacency symmetric");
        check(first.overlaps(new LoanPeriod(day, day.plusDays(2))), "equal periods overlap");
        check(first.overlaps(new LoanPeriod(day.minusDays(1), day.plusDays(4))),
                "containment overlaps");
        expect(IllegalArgumentException.class, () -> new LoanPeriod(day, day),
                "zero-length period");
        expect(IllegalArgumentException.class, () -> new LoanPeriod(day, day.minusDays(1)),
                "reversed period");
        expect(NullPointerException.class, () -> new LoanPeriod(null, day), "null start");
        expect(NullPointerException.class, () -> new LoanPeriod(day, null), "null end");

        ReservationCoordinator c = new ReservationCoordinator();
        check(c.reserve("B1", "CAM1", day, 2).equals(
                "Confirmed: R1 for B1 on CAM1 [2026-10-20, 2026-10-22)."),
                "exact first confirmation");
        check(c.reservations().size() == 1, "one success stored");
        check(c.reserve("B2", "CAM1", day.plusDays(1), 1).equals(
                "Rejected: item unavailable."), "overlapping same item rejected");
        check(c.reservations().size() == 1, "conflict stores nothing");
        check(c.reserve("B2", "CAM1", day.plusDays(2), 1).equals(
                "Confirmed: R2 for B2 on CAM1 [2026-10-22, 2026-10-23)."),
                "adjacent request and identifier after rejection");
        check(c.reserve("B1", "MIC1", day, 7).equals(
                "Confirmed: R3 for B1 on MIC1 [2026-10-20, 2026-10-27)."),
                "different item and seven-day limit allowed");
        check(c.reserve("B1", "TRI1", day, 1).startsWith("Confirmed:"),
                "third active reservation allowed");
        check(c.reserve("B1", "CAM2", day, 1).equals(
                "Rejected: borrower limit or duration."), "fourth rejected");
        check(c.reservations().size() == 4, "borrower-limit rejection stores nothing");

        List<Reservation> snapshot = c.reservations();
        expect(UnsupportedOperationException.class, snapshot::clear, "snapshot unmodifiable");
        check(c.reservations().size() == 4, "failed clear preserves coordinator state");
        check(c.reserve("B3", "CAM2", day, 1).startsWith("Confirmed:"),
                "another borrower unaffected by B1 limit");
        check(snapshot.size() == 4 && c.reservations().size() == 5,
                "old snapshot does not track later additions");
        check(snapshot.get(0).period().start().equals(day), "stored period preserved");

        ReservationCoordinator invalid = new ReservationCoordinator();
        check(invalid.reserve("B1", "CAM1", day, 0).equals(
                "Rejected: borrower limit or duration."), "zero duration rejected");
        check(invalid.reserve("B1", "CAM1", day, -1).equals(
                "Rejected: borrower limit or duration."), "negative duration rejected");
        check(invalid.reserve("B1", "CAM1", day, 8).equals(
                "Rejected: borrower limit or duration."), "eight-day duration rejected");
        expect(IllegalArgumentException.class, () -> invalid.reserve(" ", "CAM1", day, 1),
                "blank borrower");
        expect(IllegalArgumentException.class, () -> invalid.reserve("B1", null, day, 1),
                "null item");
        expect(NullPointerException.class, () -> invalid.reserve("B1", "CAM1", null, 1),
                "null request date");
        expect(DateTimeException.class, () -> invalid.reserve("B1", "CAM1", LocalDate.MAX, 1),
                "unrepresentable end date");
        check(invalid.reservations().isEmpty(), "invalid requests store nothing");
        expect(IllegalArgumentException.class,
                () -> new Reservation("", "B1", "CAM1", first), "blank reservation identifier");
        expect(NullPointerException.class,
                () -> new Reservation("R1", "B1", "CAM1", null), "null reservation period");
        System.out.println("All " + checks + " chapter checks passed.");
    }

    private static void check(boolean condition, String label) {
        if (!condition) {
            throw new AssertionError(label);
        }
        checks++;
    }

    private static void expect(Class<? extends Throwable> type, Runnable action,
                               String label) {
        try {
            action.run();
        } catch (Throwable error) {
            check(type.isInstance(error), label + ": wrong exception " + error);
            return;
        }
        throw new AssertionError(label + ": expected " + type.getSimpleName());
    }
}

4 Worked refactoring solution

4.1 The intended change

Extract the successful confirmation-string assembly into a private method. Pass the already-created reservation to that helper. Keep the storage statement before the call. Do not change the text, public API, policy, conflict calculation, validation order or identifier allocation.

This improves the readability of the request method by naming one step. It does not separate presentation into another component or eliminate the coordinator’s storage responsibility. A separate formatter class is possible future work, but it adds a collaborator and is unnecessary for the stated exercise.

Replace only ReservationCoordinator.java with the version below, then compile and run both programs again. All common files remain unchanged.

4.2 ReservationCoordinator.java completed version

This is the complete replacement file, not an additional class to place alongside the starting version.

import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public final class ReservationCoordinator {
    private final List<Reservation> reservations = new ArrayList<>();
    private final ReservationRules rules = new ReservationRules();

    public String reserve(String borrowerId, String itemId,
                          LocalDate start, int requestedDays) {
        if (borrowerId == null || borrowerId.isBlank()
                || itemId == null || itemId.isBlank()) {
            throw new IllegalArgumentException("Identifiers must not be blank.");
        }
        Objects.requireNonNull(start, "start");

        int activeCount = 0;
        for (Reservation existing : reservations) {
            if (existing.borrowerId().equals(borrowerId)) {
                activeCount++;
            }
        }
        if (!rules.mayRequest(activeCount, requestedDays)) {
            return "Rejected: borrower limit or duration.";
        }

        LoanPeriod requested = new LoanPeriod(
                start, start.plusDays(requestedDays));
        for (Reservation existing : reservations) {
            if (existing.itemId().equals(itemId)
                    && existing.period().overlaps(requested)) {
                return "Rejected: item unavailable.";
            }
        }

        Reservation reservation = new Reservation(
                "R" + (reservations.size() + 1), borrowerId, itemId, requested);
        reservations.add(reservation);
        return confirmationFor(reservation);
    }

    private String confirmationFor(Reservation reservation) {
        return "Confirmed: " + reservation.id()
                + " for " + reservation.borrowerId()
                + " on " + reservation.itemId()
                + " [" + reservation.period().start()
                + ", " + reservation.period().endExclusive() + ").";
    }

    public List<Reservation> reservations() {
        return List.copyOf(reservations);
    }
}

4.3 What the reviewer should inspect

The structural change is one call plus one private method. reservations.add(reservation) remains in the successful path. The helper only reads the already-created immutable record. Both rejection strings and their positions are unchanged. The confirmation still uses the same identifiers, dates, spaces and punctuation.

In Git, the extraction appears as four added lines and no removed lines, because the existing return "Confirmed: "... expression is kept and now sits inside the new method. Point this out to reviewers: a diff showing only additions still moves behaviour, so the reviewer must read where the retained lines ended up.

The expected output is identical to Section 1. The same 34 checks should pass. This evidence is stronger than inspecting only the helper’s text, because it also examines the stored state and rejection paths. It remains limited to the supplied cases and operating assumptions.

5 Git exercise and review record

5.1 Establish a baseline

Use a new local directory containing the starting six source files. Do not run git init inside an unrelated existing project. If working in an instructor-provided repository, use its established baseline instead of initialising another repository.

Create a file called .gitignore containing:

out/
*.class

This prevents generated files from being selected as new tracked files. It does not remove files that have already been committed. Compile the starter, run the checks, then initialise and record it:

git init -b main
git status
git add .gitignore ReservationRules.java LoanPeriod.java Reservation.java ReservationCoordinator.java Chapter02Demo.java Chapter02Checks.java
git diff --staged
git commit -m "Add chapter 2 reservation starter"
git switch -c refactor/confirmation-text

Git needs a configured author identity to create commits. If none is configured, use your own appropriate name and email according to your course workflow. Do not copy another person’s identity. No remote repository or network operation is required here.

5.2 Make and inspect the edit

Perform the extraction, then rerun the compilation and both Java programs from Section 1. Inspect the working change before staging:

git status
git diff

Ask a peer to inspect the change and evidence. Address any relevant concern, then stage the exact file and inspect again:

git add ReservationCoordinator.java
git diff --staged
git commit -m "Extract reservation confirmation formatting"
git log --oneline -2
git status

An empty ordinary git diff after staging is expected when all tracked modifications have been staged. git diff --staged shows the proposed commit content. After the commit, a clean status means the working directory matches the recorded state; it does not prove that the code is correct.

A useful review record contains the change or commit identifier, reviewer, evidence inspected, findings and response. If you worked alone, label the review as a self-review. Creating a commit does not create a hosted pull request or establish that another person reviewed it.

5.3 Example review description

Problem: the request method contains message formatting alongside the request workflow.

Change: move only the confirmation-string construction into confirmationFor, retaining the existing record creation and storage order.

Evidence: original and revised demonstrations print identical output; the supplied 34 checks pass for both versions; the diff changes only the coordinator’s internal organisation.

Limits: persistence, concurrent booking, lifecycle operations and message delivery remain outside this version.

This is an example of what a review description can contain. Students must record their own observed results and actual review, not copy a claim that they did not verify.

6 Practical activity solutions

6.1 Part A Request trace

The rejection occurs before reservation creation and before add. Identifiers derive from the number of stored records, so the rejected request consumes no identifier. Do not infer that this allocation strategy is suitable once deletion, persistence or multiple coordinators are introduced.

6.2 Diagram and invariants

One suitable compact diagram is:

classDiagram
    direction TB
    ReservationCoordinator "1" --> "1" ReservationRules : uses
    ReservationCoordinator "1" --> "0..*" Reservation : stores
    Reservation "0..*" --> "1" LoanPeriod : refers to

A local invariant is that a period’s end follows its start. The LoanPeriod constructor enforces it. The condition that confirmed reservations for the same item do not overlap requires comparing a requested period with existing records; the coordinator performs that check in this sequential version.

The links are associations, not inheritance. A caller can share an immutable LoanPeriod between reservations, so the diagram need not assert exclusive ownership through a composition diamond. Other diagrams are acceptable if their labels, direction and multiplicities are explained and agree with the code.

6.2a Scenario-modelling exercise (equipment kits)

One suitable model:

classDiagram
    direction LR
    class EquipmentKit {
        -String name
        +summary(Exporter exporter) String
    }
    class EquipmentItem {
        -String itemId
    }
    class MaintenanceRecord {
        -LocalDate performedOn
        -String note
    }
    class Exporter {
        <<interface>>
        +format(List~String~ lines) String
    }
    class CsvExporter
    EquipmentKit "0..1" o-- "1..*" EquipmentItem : groups
    EquipmentItem "1" *-- "0..*" MaintenanceRecord : keeps
    EquipmentKit ..> Exporter : uses
    Exporter <|.. CsvExporter : implements

What a strong answer shows:

Accept diagrams that add a separate export service class if the dependency and the interface realisation are still drawn correctly. Common errors are: drawing the interface realisation as inheritance with a solid line, reversing the diamond, putting 1..* at the wrong end, and making the kit depend directly on CsvExporter. The assumption can be anything stated and consistent, for example that an item with no kit is allowed, or that a record’s date is required. Do not credit extra classes for their own sake.

6.2b Answers to the “Try it” tasks in Section 2.6

Try it 1: reading Figure 2.1 from both ends.

A strong answer separates “enforced by the code” from “true of how the code happens to be used”.

Try it 2: details in the Java but absent from Figure 2.1. Any two of these, with a reason:

• The constructors of all four classes, including the validation in LoanPeriod and Reservation. The figure is about which classes collaborate, not how they are built.
• The accessors id(), borrowerId(), itemId(), start() and endExclusive(). They expose data and add nothing to the collaboration.
• Reservation’s period field. The association line to LoanPeriod already states it, and showing both would say the same thing twice.
• The coordinator’s private fields reservations and rules, and the private confirmationFor method in the completed version. The two fields appear as lines, and a private helper is not part of what other classes can see.
• The order of the checks and the exceptions thrown. A class diagram does not show sequence or behaviour.

Try it 3: mistakes in Figure 2.4.

The corrected diagram is Figure 2.3 in the student chapter. Mistakes 2 and 3 sit on the same line, and some students will list them as one; count them as two ideas if both are explained. Minor omissions, such as missing attributes on Tool or InspectionEntry, are not errors, because the scenario does not require them.

Marking and feedback for diagram answers. Use the module leader’s assessment criteria and decide tolerances before marking. For the workshop scenario, the technician’s name, the tool’s name and the single print operation on the printer are design assumptions, not facts stated in the description; accept other justified attributes or operations, and judge the relationships and multiplicities, which the description does determine.

Ask students for the decision behind each relationship, not only the symbol. “I chose composition because an entry cannot exist without its locker” earns more than a correct diamond with no reason.

6.3 Part B Responsibility diagnosis

The coordinator validates request inputs, counts stored records, invokes policy, checks item availability, allocates an identifier, stores a record and formats a message. Two distinct reasons it could change are a new storage mechanism and changed confirmation wording.

LoanPeriod is cohesive because construction rules and overlap concern one period concept. The coordinator depends on both reservation representation and message wording; changing wording requires editing a class that also mutates storage. Simply counting lines does not explain that consequence.

6.4 Part C Refactoring acceptance

Use the complete solution in Section 4 as one model. Accept alternative private-method names with a clear purpose if the requested behaviour is preserved. A new interface or formatter class is not needed for this lab. If a student chooses one, ask for evidence that its additional boundary addresses a current need rather than awarding credit for extra structure.

Review returned text and stored records, not merely whether the program compiles. There should be one focused source change in the final commit. Do not require an exact commit hash, which depends on the local history.

6.5 Part D Team arrangement

There is no unique answer. The team should contain three or four members as directed, name one of the module’s provided starter domains, and make the next author, reviewer and demo responsibilities explicit. A useful issue-board item has a concrete completion condition, such as “extract confirmation formatting with unchanged output and checks,” rather than “improve OO.” Look for three such cards, columns that the team can explain, and a written branch policy with a reason. Either a short-lived-branch or a feature-branch policy is acceptable; the reason matters more than the choice. Rotate roles and preserve evidence of review and reasoning.

7 AI activity solution

The supplied response is a teaching example constructed for this exercise. It is not evidence about the observed performance of a real AI model. The student chapter deliberately does not name the three faulty areas (email delivery, durable storage and concurrency or immutability claims); students should find them by tracing control flow, state changes and side effects.

An acceptable corrected four-sentence explanation is:

The coordinator rejects missing or blank identifiers and requires a start date, then counts the borrower’s stored records and applies the numeric rule. It checks overlapping periods for the same item before recording a successful reservation and returning confirmation text. Policy and availability rejections do not add a record, and the returned reservation list is an unmodifiable snapshot containing immutable elements. The implementation has in-memory storage only, sends no email, and is intended for sequential use rather than concurrent booking.

A student may mention the date-range exception or missing lifecycle support as further qualifications. They should not invent an external application’s behaviour from this isolated code.

8 Review-question solutions

1. Identity: a reference identifies a Java object instance; id represents domain identity in the teaching model. Two separately constructed reservations can contain the same identifier text yet remain distinct objects under the inherited equals. Identifier-based equality would require an explicit contract and implementation.
2. Invariants: LoanPeriod protects its own valid date relationship. Conflict prevention needs other reservations and the requested item, so it belongs at a boundary with that information. Local validation cannot ensure consistency across independent coordinators.
3. Cohesion and coupling: changed message wording affects presentation but currently requires editing the coordinator. A private helper makes that purpose easier to locate; it does not remove the class-level dependency. Zero dependencies would prevent meaningful collaboration, while extra classes can add indirection without solving a problem.
4. Composition and inheritance: a reservation has or refers to a period. It is not a period subtype. Inheriting from a period would conflate reservation identity and borrower/item details with an interval, and suggest inappropriate substitutability. The actual final LoanPeriod class also prohibits subclassing.
5. Leaking state: returning the mutable internal list allows clear or add outside the coordinator’s validation. List.copyOf blocks structural mutation and isolates later additions to the source list. It does not deep-copy mutable elements. This starter’s element types are separately immutable.
6. Missing storage: a success string is now returned for a reservation that the coordinator does not retain. The next request can incorrectly find no conflict, and the stored count does not increase. The one success stored check exposes the fault immediately, before relying on a second request.

9 Transfer-challenge solution

One reasonable model uses RoomBookingCoordinator, RoomBooking, BookingPeriod and BookingRules. The coordinator holds records and uses rules; a booking refers to a period. A diagram may omit a separate rules class if no relevant policy behaviour exists yet.

State an explicit convention, for example start-inclusive/end-exclusive periods in local building time with a stated time granularity. If using times rather than dates, specify how time zones or daylight-saving transitions are handled or excluded from the exercise. The four-class suggestion is not an instruction to implement a production scheduling system.

Protect the stored booking collection from callers. A formatting-method extraction can be sufficient for a wording-related area of code, but distinguish the extraction from the wording change itself: first preserve the old output while extracting, then make the requested text change as a separate behaviour change with updated expectations.

Two observations for the extraction are identical confirmation text and identical stored records for the same successful input. Also checking that a conflicting request still adds nothing strengthens the evidence. A remaining limitation might be that a single process’s list cannot coordinate bookings from multiple application instances.

A review description should identify which commit merely extracts formatting and which later change intentionally alters wording. This distinction is an important part of a strong answer to a scenario whose eventual goal changes visible text.

10 Additional fault demonstrations

Use disposable copies and never retain the faulty version as your next project version.

10.1 Exposing the mutable collection

Replace only the getter body with the following fragment:

// Deliberately unsafe method replacement.
public List<Reservation> reservations() {
    return reservations;
}

Recompile and rerun the checks. snapshot::clear now succeeds instead of throwing. The runner reports that snapshot unmodifiable expected an UnsupportedOperationException. Records have become externally mutable even though the original field remains private and final.

10.2 Omitting the storage operation

In another disposable copy, remove this line from the successful request path:

// Line to remove only for the deliberate fault exercise.
reservations.add(reservation);

The first confirmation can still look correct, but the checks fail with one success stored. A demonstration that inspects only printed text would miss the changed state.

Both faults were actually introduced in separate temporary copies during verification. Neither is present in the complete starting or completed listings above.

11 Instructor guidance and version record

For the UML work, spend class time on reading before drawing. A useful warm-up is to put Figure 2.1 on screen and have students read one line aloud in both directions, then ask where the code enforces each number. Next let them hand-draw the workshop scenario using the six steps, and compare their drawings with Figure 2.3 by asking why each line differs, not whether it matches. Finish with the flawed Figure 2.4 as a pair exercise. Hand drawing is worth the class time because it makes students decide each relationship deliberately; the module leader has not stated how diagrams are produced in the midterm, so do not tell students that hand drawing, or any particular tool, will be required.

Ask students to trace one request before discussing any principle names. Have one learner identify the successful path and another inspect what a failed path leaves behind. Use the adjacency example to expose hidden date assumptions before drawing the diagram.

Do not require full understanding of every line in the check runner this week. Its role is to supply behavioural protection while students learn a small refactoring. Teach the relevant check invocation if a learner needs to understand a failure; the full testing discipline comes later.

Keep the code change small. Review can reveal further design opportunities, but adding lifecycle states, repositories, factories and notification infrastructure would obscure this chapter’s learning goal. Ask students to record those opportunities rather than implement all of them.

The starting state is Chapter 2 before extraction. The completed state is Chapter 2 after confirmation extraction. They use the same five common files and alternative coordinator versions. Later chapters should continue from the completed version. The isolated faults are teaching experiments, not running project changes.

The original Chapter 1 rule is reused without alteration. The date convention is now explicit. The early system still lacks staff policies, borrower/item catalogues, authentication, cancellation/completion, durable storage, notification delivery and concurrency control. These are scope facts, not hidden promises that the program already meets.

The Java 17 baseline and the plain javac workflow are working choices. The sequence is deliberate: Chapter 2 uses flat files compiled by javac; Chapter 4 moves them into conventional source folders with a plain-Java Bash gate; Chapter 7 introduces Maven and JUnit. Chapter 4 explains the migration. Which Java idioms are permitted in assessments is for the module leader to decide.

12 Sources

Technical source references are in the student chapter. The examples and suggested solutions here are original teaching material.

Chapter 3 Companion: Code, Explanations and Solutions

Companion to Chapter 3: Agile Development and the Nature of Change
OO Development and Agile Practices

This chapter’s main outputs are stories, acceptance examples, a backlog, completion conditions and workflow policies. This file provides worked versions and suggested answers, followed by an optional Java demonstration of how acceptance examples connect to the existing code.

The examples are proposals for the controlled teaching project. They do not establish new university assessment rules or claim that planned features have been built. Keep this file separate from the student chapter until learners have attempted its activities.

1 Project baseline and a proposed goal

Continue from the completed confirmation-extraction version of Chapter 2. The code supports the initial numeric student policy, sequential conflict checks, storing confirmed reservations in memory and returning a snapshot of all stored records. It does not provide a dedicated availability query, cancellation, catalogue validation or durable storage.

A suitable proposed Product Goal is:

Enable an equipment officer, in a controlled demonstration, to create and inspect student reservations with clear eligibility decisions and no overlapping reservations for the same item within one coordinator.

This is a future outcome to work toward, not a declaration that the whole goal is achieved. It explicitly bounds the demonstration. A different goal is acceptable if the team explains its audience, benefit and scope.

A candidate next-iteration goal is “Let the officer inspect an item’s availability without changing reservations.” This is an example for discussion; Chapter 4 will perform actual iteration planning. Neither statement chooses a new assessment date or fixes a Sprint duration.

2 A worked six-item backlog

The order below is one defensible teaching choice, not the only correct ordering. We review the inherited reservation flow first, then make an availability enquiry possible, and prepare repeatable checks before expanding the lifecycle.

Rationale and dependencies

US-01 prevents the team from building on a falsely reported baseline. Its remaining work should be recorded explicitly; do not recreate existing logic or claim it as newly developed. If the team verifies that it already meets the agreed delivery conditions, move it to completed history with evidence and select remaining work.

US-02 answers the workflow gap discovered at demonstration. It depends on understanding the existing records and period convention, but it need not wait for a production database. EN-01 supports reliable repeated work and should be coordinated with Chapter 4’s kickoff requirements; its place here does not forbid parallel preparation when capacity permits.

US-03 may be a small useful improvement, although access rules matter outside the controlled officer-operated demonstration. US-04 changes the meaning of “active” and therefore affects counts and availability. US-05 matters before accepting arbitrary identifiers in a broader deployment. Its lower position assumes that early demonstrations use controlled sample identifiers; change that ordering if real users or uncontrolled input enter scope.

The backlog order is not a calendar schedule. Some items need policy decisions, and the six items are not a promise that all can be completed in one Sprint.

3 Refined story cards

3.1 US-01 Record a reservation

Actor and outcome: as an equipment officer, I want to record an eligible, non-conflicting student reservation so that the selected item is allocated for the requested period.

Scope: one item per request, controlled non-blank sample identifiers, whole-day durations and representable calendar dates. The initial student rules apply. Requests are processed sequentially by one coordinator. No real catalogue, identity provider, database, payment or email service is implied.

Decisions carried from earlier chapters: at most three active reservations; duration from one to seven days inclusive; start-inclusive/end-exclusive periods; all stored records remain active until a later lifecycle feature changes that assumption.

Further clarification: whether past start dates are allowed; what the agreed user interaction should be; how future cancellation affects the active count. The first two need explicit treatment when preparing a complete user-facing flow. Cancellation policy belongs to US-04 unless the stakeholder changes current scope.

Existing evidence: Chapter 2 contains checks for the core behaviour. Section 8 supplies an additional direct mapping from these acceptance examples to the current coordinator. Neither check set alone establishes that a peer review, shared integration or usable input interaction has happened.

3.2 US-02 Inspect availability

Actor and outcome: as an equipment officer, I want to inspect whether a known item is available for a proposed period without reserving it, so that I can discuss options with a borrower.

Scope: enquiry against the current coordinator’s records for controlled sample identifiers. It does not promise that the physical item is operational, not under maintenance, or available in another application instance.

Core distinction: a successful enquiry never confirms a reservation and never guarantees that a later request will succeed. The later request must perform its own checks against its then-current state.

AQ-05 intentionally states the user-observable meaning without prescribing an exception class or interface design. The team must make that technical contract explicit during implementation. It must not silently return “available” for an invalid period.

Unknowns: the future behaviour for catalogue identifiers outside the controlled examples; maintenance rules; restrictions on past dates. Record these as questions or related work. Do not add a hidden maintenance buffer: the present interval convention allows adjacency.

Status: this query is not implemented by the Chapter 2 code. reserve cannot be reused as an enquiry by calling it and undoing the result; that would introduce a mutation and does not satisfy the story.

4 INVEST reasoning and completion conditions

4.1 INVEST applied to US-02

• Independent: the enquiry can be demonstrated with existing records without implementing cancellation. It still depends on the agreed period convention.
• Negotiable: the input mechanism and presentation can be discussed while preserving non-mutation and a clear result.
• Valuable: the officer can compare periods without creating speculative reservations.
• Estimable: a query against a controlled local list is sufficiently bounded for discussion. A live inventory integration would add uncertainty and belongs in separate scope.
• Small: one item and one period avoid a full multi-item scheduling interface.
• Testable: compare the result and the complete relevant record state before and after the enquiry.

This reasoning is more useful than marking six boxes without explanation. A student can challenge the story’s scope or dependency assumptions and still provide a strong answer.

4.2 A proposed Definition of Done

For the controlled teaching increment, the team proposes:

1. Applicable acceptance examples are verified, including important rejection paths and state effects.
2. Source compiles and executes using the documented environment and commands.
3. A peer review has occurred and findings that prevent acceptance are resolved.
4. Work is integrated into the shared codebase, and existing checks still pass.
5. Usage notes, domain decisions and known limitations are updated where needed.
6. Another team member can reproduce the intended demonstration within its stated scope.

This is an agreement to adopt or refine, not a claim that inherited work already satisfies all six items. Independent study can use a clearly labelled self-review for practice, but should not falsely record peer approval. A future CI gate must be introduced explicitly rather than claimed before it exists.

4.3 Distinguishing the three questions

A Ready policy should help a conversation, not become a ritual that demands every detail months in advance. It is not a fourth Scrum artefact. Equally, no amount of formatting can make an unresolved cancellation-authority rule disappear.

5 A complete example workflow policy

Work item: a small user story or an explicitly identified technical enabler. Do not mix large epics and tiny subtasks into the same WIP count without explaining how they are treated.

States: Backlog, Ready, Building, Review and Done.

Start and finish: work starts on entering Building and finishes on entering Done. Ready items are not yet started. Building and Review both contribute to WIP.

WIP control: at most two items across Building and Review combined. This number is invented for the classroom exercise, not claimed to be optimal for every team.

Movement rules: an item enters Ready when its outcome, scope and useful examples are understood well enough to start. It enters Building when the team has capacity under the limit. It enters Review when the change and checking evidence can be inspected. It enters Done only when the applicable acceptance conditions and agreed DoD have been met. A failed review returns the item to Building and it remains within WIP.

Blocked work: retain the item in its actual workflow state, mark its blocker and who is investigating it, and keep it within WIP. Do not hide it in an excluded column or mark it Done to free capacity. If the team explicitly abandons an item, record that disposition separately from completed value and preserve the reason.

Service-level expectation: provisionally, 85% of these small work items within five working days from Building to Done. No historical evidence supports that number yet; it is a working hypothesis to revise, not a promise to users or a grading target. State how working days are counted before collecting timing data.

Inspection: when meeting to coordinate, first inspect blocked or waiting active work and agree a concrete next action. Later flow analysis should use consistent start/finish definitions. Detailed metrics and forecasting are deferred to Chapter 12.

Board exercise solution

In the supplied hypothetical snapshot, US-02 is in Building and EN-01 is blocked in Review. Two items have started and neither has finished, so the limit is reached. The team should investigate the setup blocker, help review or complete the existing feature before pulling another ordinary item from Ready.

If the blocker genuinely prevents progress, discuss and record the trade-off instead of silently changing the count. A WIP policy can be revised deliberately, but an invisible exception destroys the information needed to evaluate it. US-01’s Done position belongs only to the hypothetical board simulation; it is not an assertion about the actual project.

6 Relative estimation example

The following numbers are invented for a discussion; no empirical velocity or delivery forecast is being claimed.

Include implementation, meaningful checking, review and needed documentation in the estimate. Different values are acceptable when assumptions and comparison logic are clear. These numbers must not be converted to hours or used to rank students.

A useful investigation for US-05 would ask whether an authorised read-only sample catalogue can be obtained and what identifier fields it contains. Specify a bounded effort and a written result, including failure to obtain access. Do not claim such access already exists or ask students to probe systems without authorisation.

Critiquing the two process recommendations

Advice A tries to avoid ambiguity but assumes that all relevant detail can be known before implementation. In this project, the availability enquiry itself emerged from demonstration. Freezing every detail could prevent useful learning or preserve a mistaken assumption.

Advice B tries to encourage fast feedback but leaves the team unable to distinguish successful behaviour from a persuasive demonstration. Without prior examples, a query that mutates state might look acceptable.

A stronger agreement is to clarify the next small outcome and its key examples before implementation, then revise the backlog and decisions as new evidence appears. Keep later work less detailed until it approaches selection. This does not mean ignoring major dependencies or domain rules.

7 AI activity decision log

The student chapter words the suggestions with “refused” and “specify” so that they do not echo the classification labels (accept, reject for this story, clarify).

No suggestion becomes a rule merely because AI produced it. The correction may be to preserve an accurate observation, narrow its claim, record a question or keep a possible future feature outside the current story.

A sufficient student record gives the suggestion, classification, relevant source of authority and next action. “AI is wrong” without identifying the conflicting rule is not enough.

8 Java bridge from acceptance examples to code

8.1 Purpose and prerequisites

The full source below runs AC-01 through AC-05 against the completed Chapter 2 coordinator. It introduces no new application behaviour and makes no claim to implement US-02. Plain Java checks are used so the relation between an example and an observation remains visible before formal testing techniques in Chapter 7.

Copy these four inherited files from the Chapter 2 code-and-solutions file: ReservationRules.java, LoanPeriod.java, Reservation.java, and the completed ReservationCoordinator.java. Put them in one directory with the new file below. Preserve their content; the example data rules and message contract have not changed.

Filename: Chapter03AcceptanceExamples.java

import java.time.LocalDate;

public class Chapter03AcceptanceExamples {
    public static void main(String[] args) {
        LocalDate day = LocalDate.of(2026, 10, 20);
        ReservationCoordinator coordinator = new ReservationCoordinator();

        // AC-01: an eligible request is stored once and confirmed.
        String accepted = coordinator.reserve("B1", "CAM1", day, 2);
        require(accepted.equals(
                "Confirmed: R1 for B1 on CAM1 [2026-10-20, 2026-10-22)."),
                "AC-01 confirmation");
        require(coordinator.reservations().size() == 1, "AC-01 one record");
        System.out.println("AC-01 passed");

        // AC-02: an overlapping request for the same item changes no records.
        String conflict = coordinator.reserve("B2", "CAM1", day.plusDays(1), 1);
        require(conflict.equals("Rejected: item unavailable."), "AC-02 rejection");
        require(coordinator.reservations().size() == 1, "AC-02 unchanged count");
        require(coordinator.reservations().get(0).borrowerId().equals("B1"),
                "AC-02 original borrower preserved");
        System.out.println("AC-02 passed");

        // AC-03: a booking may start at an existing exclusive end,
        // or end exactly where an existing booking starts.
        String adjacent = coordinator.reserve("B2", "CAM1", day.plusDays(2), 1);
        require(adjacent.equals(
                "Confirmed: R2 for B2 on CAM1 [2026-10-22, 2026-10-23)."),
                "AC-03 adjacent confirmation");
        require(coordinator.reservations().size() == 2, "AC-03 second record");
        String before = coordinator.reserve("B3", "CAM1", day.minusDays(1), 1);
        require(before.equals(
                "Confirmed: R3 for B3 on CAM1 [2026-10-19, 2026-10-20)."),
                "AC-03 request ending at an existing start");
        require(coordinator.reservations().size() == 3, "AC-03 third record");
        System.out.println("AC-03 passed");

        // AC-04: count limits span items, not just one equipment item.
        ReservationCoordinator limits = new ReservationCoordinator();
        for (String item : new String[] {"CAM1", "MIC1", "TRI1"}) {
            require(limits.reserve("B1", item, day, 1).startsWith("Confirmed:"),
                    "AC-04 establish three valid reservations");
        }
        require(limits.reserve("B1", "CAM2", day, 1).equals(
                "Rejected: borrower limit or duration."), "AC-04 fourth rejected");
        require(limits.reservations().size() == 3, "AC-04 unchanged count");
        System.out.println("AC-04 passed");

        // AC-05: one and seven days are allowed; zero, negative and eight are not.
        ReservationCoordinator durations = new ReservationCoordinator();
        require(durations.reserve("B1", "CAM1", day, 1).startsWith("Confirmed:"),
                "AC-05 one day");
        require(durations.reserve("B1", "MIC1", day, 7).startsWith("Confirmed:"),
                "AC-05 seven days");
        for (int days : new int[] {0, -1, 8}) {
            require(durations.reserve("B1", "TRI1", day, days).equals(
                    "Rejected: borrower limit or duration."), "AC-05 invalid duration");
            require(durations.reservations().size() == 2, "AC-05 unchanged count");
        }
        System.out.println("AC-05 passed");
        System.out.println("All 5 acceptance examples passed.");
    }

    private static void require(boolean condition, String description) {
        if (!condition) {
            throw new AssertionError(description);
        }
    }
}

8.2 Compile and run

Use the same Java 17 language/API baseline as Chapter 2:

javac --release 17 -d out ReservationRules.java LoanPeriod.java Reservation.java ReservationCoordinator.java Chapter03AcceptanceExamples.java
java -cp out Chapter03AcceptanceExamples

Expected output:

AC-01 passed
AC-02 passed
AC-03 passed
AC-04 passed
AC-05 passed
All 5 acceptance examples passed.

8.3 What the code demonstrates

Each labelled group corresponds to a criterion, with setup, action and observations. AC-01 through AC-03 intentionally use one coordinator to inspect a sequence. AC-04 and AC-05 use fresh coordinators so existing state from another scenario does not accidentally decide their outcomes.

AC-04 uses different item identifiers, ensuring that the fourth refusal comes from the borrower’s total count rather than a conflict on one item. AC-05 uses two valid requests and then invalid durations while the borrower remains below the count limit. That makes the duration rule the relevant reason for rejection.

The require helper throws AssertionError on a mismatch. It does not depend on the JVM’s optional assertion flag. Some observations compare exact strings because the current public method returns strings. This couples those checks to the current message contract; a later typed outcome could separate a business decision from its wording. Do not redesign that API merely to complete this planning chapter.

AC-03 includes a request that ends exactly where an existing reservation begins because verification showed a gap without it. Changing the first overlap comparison in LoanPeriod from start.isBefore(other.endExclusive) to !start.isAfter(other.endExclusive) passed all five groups when AC-03 covered only a request starting at an existing end. Chapter 2’s adjacency symmetric check caught that change, which is a useful illustration of why example sets are chosen to expose specific faults, not merely to be numerous.

These five groups are examples, not exhaustive proofs. They do not check catalogue membership, concurrent access, durable storage or a real user’s entire interaction. A passing run does not automatically satisfy the team’s Definition of Done: review, integration, reproducibility and the agreed delivery scope still matter.

9 Review-question solutions

1. Iteration and increment: revising the reservation messages after feedback is an iteration on an existing capability. Adding an integrated, usable enquiry that leaves records untouched is an increment. A cycle can produce an increment, but the words do not mean the same thing.
2. Agile values: favouring usable software over exhaustive documents still permits a short written period convention. The documentation makes behaviour and tests understandable; it should support the outcome rather than become a substitute for examining it. Equivalent reasoned examples are acceptable.
3. Events: a Review examines product outcomes with stakeholders and influences next product choices. A Retrospective selects improvements in how the team works. A Daily Scrum helps Developers adapt their near-term plan toward the Sprint Goal. A status report to the lecturer does not automatically fulfil all of those purposes.
4. Conditions: acceptance criteria are item-specific behavioural expectations; DoD is the shared quality standard for the increment; Ready is this team’s local policy for starting work. The latter is not another formal Scrum artefact.
5. False Done claim: the enquiry violates its non-mutation acceptance condition, and missing review violates the example DoD. Inspect records before and after the enquiry, repeat relevant examples, and obtain an actual review. A correct answer for one date is insufficient evidence for either issue.
6. Hidden WIP: the blocked review item remains unfinished, so starting a third item exceeds the stated combined limit. Help investigate or resolve the blockage and finish existing work. If changing policy is necessary, record the change and its reason rather than relabelling the item to hide it.

10 Transfer-challenge solution

Candidate stories and enabler

RB-01: as a laboratory coordinator, I want to inspect availability for one known room and period without booking it, so that I can offer an appropriate slot.

RB-02: as a laboratory coordinator, I want to confirm an eligible, non-conflicting booking, so that the room is allocated for an agreed session.

RE-01: make the room-booking project’s existing build and checks reproducible in its shared workflow, reducing dependence on one developer’s environment. This is a justified enabler, not a fictional room user’s request for a build tool.

RB-01 acceptance examples

For the exercise, assume known example room identifiers and a declared start-inclusive/end-exclusive convention:

• With no existing booking, a valid enquiry reports available and creates no booking.
• With a booking from 10:00 to 11:00, an enquiry for the same room from 10:30 to 11:30 reports unavailable and preserves the existing record.
• An enquiry starting at 11:00 may report available when there is no other conflict, and it changes no records.
• An invalid interval with end before start produces an identifiable invalid-input result and does not change records.

These are proposed rule invented for this books, not a claim about institutional room policy. Confirm whether a cleaning or preparation buffer is required before accepting adjacency for a real system.

Completion, flow and uncertainty

A reasonable DoD includes checked acceptance examples, a reproducible build, actual review, integration and updated decisions or usage notes. A simple workflow can limit the combined Building and Review states to two items, counting blocked work until it is finished or explicitly withdrawn.

A stakeholder question is whether room capacity or organiser authority restricts booking. A technical question is whether an approved read-only room catalogue can be obtained. Investigate the latter with a bounded task; do not invent an API.

A small demonstration with synthetic room records can elicit feedback before these wider integrations exist. Present the limitations explicitly and ask the stakeholder to examine the intended interaction, not to assume a production service is already operating.

11 Reusable working templates

Story card

Decision record for a proposed criterion

Peer story review

Ask another team to describe the story’s outcome, choose an ordinary case and a failure case, and identify the expected state afterwards. If they must invent a cancellation policy, duration convention or catalogue assumption, refine the story or explicitly defer the missing decision. Record the actual reviewer and questions; a template is not evidence that review occurred.

12 Instructor guidance

Start with the equipment officer’s enquiry request. Ask students to find the exact difference between the current reserve operation and a non-mutating question. This connects process work to a real behaviour gap rather than beginning with meeting names.

Use a short role-play to clarify the story: one learner represents the officer, another asks about boundaries, and another records examples and open questions. Label this as a classroom arrangement, not a redefinition of Scrum accountabilities. Keep the critical-reading exercise focused on assumptions and consequences instead of choosing a slogan.

The six backlog items, top-story criteria, board snapshot and AI classifications are consistent with the student chapter. Proposed or hypothetical states are identified; no claim is made that US-02 through US-05 or EN-01 are implemented. The period convention and numeric rules match Chapter 2, and the example DoD does not pretend that an automated pipeline already exists.

12.1 Do the acceptance examples detect faults?

Each change below was made on its own to a copy of LoanPeriod or ReservationRules, and the Chapter 3 acceptance runner was run. Where the Chapter 2 runner is named, it was run as well.

Suppose AC-03 contained only a request that starts at an existing end. The first change would then pass every Chapter 3 acceptance example. The extra request in AC-03, one that ends exactly where an existing reservation begins, closes that gap.

Martin (2002) and Rubin (2012) are cited in the student chapter; this book treats Agile practices and Scrum in Chapter 3 and sprint planning in Chapter 4.

The practical activity runs on your team’s project, with the lending backlog as the worked model and a transfer note for other provided domains. The process note asks teams to separate Scrum as defined from classroom adaptations and optional practices. When marking the process note, accept any honest statement. A team that uses stories, points and a board but no designated Scrum Master has described a legitimate adaptation, whereas a team that calls an academic deadline a Sprint without naming that adaptation has not.

This chapter adds planning documents and acceptance examples. The running application code remains at the completed Chapter 2 version. Keep these backlog decisions available for Chapter 4’s kickoff planning, and revise them explicitly when stakeholder answers arrive.

Authoritative concept references are provided in the student chapter. All worked project material and suggested solutions here are original examples.

Chapter 4 Companion: Code, Explanations and Solutions

From Requirements to an Iteration
OO Development and Agile Practices

How to use this file

This file accompanies Chapter 4, From Requirements to an Iteration. It contains the complete starter listings, build instructions, a hosted-workflow template, explanations, model planning artefacts, exercise solutions and teaching notes. Read the student chapter before using the solutions.

Version: Java 17; Campus Equipment Lending System; unchanged Chapter 2–3 reservation rules. New material organises the starter and makes verification repeatable. US-02 availability enquiry remains planned and is not implemented here. No catalogue, persistence, cancellation, email or concurrent reservation protection has been added.

All people, workload figures and review scenarios in the model answers are fictional.

1. Reconstructing the starter

Create one directory, such as equipment-lending, and save each listing below at its labelled relative path. A heading gives the filename; do not copy that heading into the file. Create intermediate directories as required.

Application and check classes still use the unnamed package. The directory names separate source roles without changing the class design. Named packages and broader application structure will be introduced deliberately later. This is not a Maven build: there is no pom.xml, and the check classes use main methods rather than JUnit discovery. Do not expect mvn test to discover them automatically. Maven and JUnit remain the planned fuller toolchain for the testing stage.

1.1 Requirements and commands

Use a Java 17 JDK and Bash. Check that both java -version and javac -version identify the intended installation. A runtime without a compiler is insufficient for the ordinary command. On Windows, use a Bash environment with the JDK on its path, such as Git Bash or WSL; native PowerShell cannot interpret this Bash script. Section 10 records runs on Linux and in Git Bash on Windows.

From the project root:

bash scripts/check.sh
java -cp build/classes Chapter04Demo

The workflow also invokes bash scripts/check.sh, so no executable permission bit is required for that file. Store it with ordinary UTF-8 text and LF line endings. Do not copy Markdown fence markers into the script or YAML file.

The gate prints Java version information, then these success lines:

All 34 chapter checks passed.
AC-01 passed
AC-02 passed
AC-03 passed
AC-04 passed
AC-05 passed
All 5 acceptance examples passed.
BUILD AND CHECKS PASSED

The five acceptance groups contain multiple assertions; do not add 34 and 5 and describe the total as 39 individual assertions. They are two differently organised sets of checks.

The demonstration prints:

Confirmed: R1 for B1 on CAM1 [2026-10-20, 2026-10-22).
Rejected: item unavailable.
Confirmed: R2 for B2 on CAM1 [2026-10-22, 2026-10-23).
Stored reservations: 2

The second request must not consume a reservation identifier or create a record. The third request receives R2 and starts exactly at the earlier exclusive end. All three calls run in the same coordinator; rerunning the program creates a new empty coordinator.

2. Complete Java listings

These listings preserve the existing baseline. Repetition makes this Markdown file independently reconstructable and prevents accidental mixing of earlier coordinator versions.

2.1 src/main/java/ReservationRules.java

public final class ReservationRules {
    public boolean mayRequest(int activeReservations, int requestedDays) {
        return activeReservations >= 0
                && activeReservations < 3
                && requestedDays >= 1
                && requestedDays <= 7;
    }
}

2.2 src/main/java/LoanPeriod.java

import java.time.LocalDate;
import java.util.Objects;

public final class LoanPeriod {
    private final LocalDate start;
    private final LocalDate endExclusive;

    public LoanPeriod(LocalDate start, LocalDate endExclusive) {
        this.start = Objects.requireNonNull(start, "start");
        this.endExclusive = Objects.requireNonNull(endExclusive, "endExclusive");
        if (!start.isBefore(endExclusive)) {
            throw new IllegalArgumentException("End must be after start.");
        }
    }

    public LocalDate start() {
        return start;
    }

    public LocalDate endExclusive() {
        return endExclusive;
    }

    public boolean overlaps(LoanPeriod other) {
        Objects.requireNonNull(other, "other");
        return start.isBefore(other.endExclusive)
                && other.start.isBefore(endExclusive);
    }
}

2.3 src/main/java/Reservation.java

import java.util.Objects;

public final class Reservation {
    private final String id;
    private final String borrowerId;
    private final String itemId;
    private final LoanPeriod period;

    public Reservation(String id, String borrowerId, String itemId,
                       LoanPeriod period) {
        this.id = requireText(id);
        this.borrowerId = requireText(borrowerId);
        this.itemId = requireText(itemId);
        this.period = Objects.requireNonNull(period, "period");
    }

    private static String requireText(String value) {
        if (value == null || value.isBlank()) {
            throw new IllegalArgumentException("Identifiers must not be blank.");
        }
        return value;
    }

    public String id() { return id; }
    public String borrowerId() { return borrowerId; }
    public String itemId() { return itemId; }
    public LoanPeriod period() { return period; }
}

2.4 src/main/java/ReservationCoordinator.java

import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import java.util.Objects;

public final class ReservationCoordinator {
    private final List<Reservation> reservations = new ArrayList<>();
    private final ReservationRules rules = new ReservationRules();

    public String reserve(String borrowerId, String itemId,
                          LocalDate start, int requestedDays) {
        if (borrowerId == null || borrowerId.isBlank()
                || itemId == null || itemId.isBlank()) {
            throw new IllegalArgumentException("Identifiers must not be blank.");
        }
        Objects.requireNonNull(start, "start");

        int activeCount = 0;
        for (Reservation existing : reservations) {
            if (existing.borrowerId().equals(borrowerId)) {
                activeCount++;
            }
        }
        if (!rules.mayRequest(activeCount, requestedDays)) {
            return "Rejected: borrower limit or duration.";
        }

        LoanPeriod requested = new LoanPeriod(
                start, start.plusDays(requestedDays));
        for (Reservation existing : reservations) {
            if (existing.itemId().equals(itemId)
                    && existing.period().overlaps(requested)) {
                return "Rejected: item unavailable.";
            }
        }

        Reservation reservation = new Reservation(
                "R" + (reservations.size() + 1), borrowerId, itemId, requested);
        reservations.add(reservation);
        return confirmationFor(reservation);
    }

    private String confirmationFor(Reservation reservation) {
        return "Confirmed: " + reservation.id()
                + " for " + reservation.borrowerId()
                + " on " + reservation.itemId()
                + " [" + reservation.period().start()
                + ", " + reservation.period().endExclusive() + ").";
    }

    public List<Reservation> reservations() {
        return List.copyOf(reservations);
    }
}

2.5 src/main/java/Chapter04Demo.java

import java.time.LocalDate;

public final class Chapter04Demo {
    public static void main(String[] args) {
        ReservationCoordinator coordinator = new ReservationCoordinator();
        LocalDate start = LocalDate.of(2026, 10, 20);
        System.out.println(coordinator.reserve("B1", "CAM1", start, 2));
        System.out.println(coordinator.reserve("B2", "CAM1", start.plusDays(1), 1));
        System.out.println(coordinator.reserve("B2", "CAM1", start.plusDays(2), 1));
        System.out.println("Stored reservations: " + coordinator.reservations().size());
    }
}

2.6 src/test/java/Chapter02Checks.java

import java.time.DateTimeException;
import java.time.LocalDate;
import java.util.List;

public class Chapter02Checks {
    private static int checks;

    public static void main(String[] args) {
        LocalDate day = LocalDate.of(2026, 10, 20);
        LoanPeriod first = new LoanPeriod(day, day.plusDays(2));
        LoanPeriod overlapping = new LoanPeriod(day.plusDays(1), day.plusDays(3));
        LoanPeriod adjacent = new LoanPeriod(day.plusDays(2), day.plusDays(3));
        check(first.overlaps(overlapping), "overlap detected");
        check(overlapping.overlaps(first), "overlap is symmetric");
        check(!first.overlaps(adjacent), "adjacent periods allowed");
        check(!adjacent.overlaps(first), "adjacency symmetric");
        check(first.overlaps(new LoanPeriod(day, day.plusDays(2))), "equal periods overlap");
        check(first.overlaps(new LoanPeriod(day.minusDays(1), day.plusDays(4))),
                "containment overlaps");
        expect(IllegalArgumentException.class, () -> new LoanPeriod(day, day),
                "zero-length period");
        expect(IllegalArgumentException.class, () -> new LoanPeriod(day, day.minusDays(1)),
                "reversed period");
        expect(NullPointerException.class, () -> new LoanPeriod(null, day), "null start");
        expect(NullPointerException.class, () -> new LoanPeriod(day, null), "null end");

        ReservationCoordinator c = new ReservationCoordinator();
        check(c.reserve("B1", "CAM1", day, 2).equals(
                "Confirmed: R1 for B1 on CAM1 [2026-10-20, 2026-10-22)."),
                "exact first confirmation");
        check(c.reservations().size() == 1, "one success stored");
        check(c.reserve("B2", "CAM1", day.plusDays(1), 1).equals(
                "Rejected: item unavailable."), "overlapping same item rejected");
        check(c.reservations().size() == 1, "conflict stores nothing");
        check(c.reserve("B2", "CAM1", day.plusDays(2), 1).equals(
                "Confirmed: R2 for B2 on CAM1 [2026-10-22, 2026-10-23)."),
                "adjacent request and identifier after rejection");
        check(c.reserve("B1", "MIC1", day, 7).equals(
                "Confirmed: R3 for B1 on MIC1 [2026-10-20, 2026-10-27)."),
                "different item and seven-day limit allowed");
        check(c.reserve("B1", "TRI1", day, 1).startsWith("Confirmed:"),
                "third active reservation allowed");
        check(c.reserve("B1", "CAM2", day, 1).equals(
                "Rejected: borrower limit or duration."), "fourth rejected");
        check(c.reservations().size() == 4, "borrower-limit rejection stores nothing");

        List<Reservation> snapshot = c.reservations();
        expect(UnsupportedOperationException.class, snapshot::clear, "snapshot unmodifiable");
        check(c.reservations().size() == 4, "failed clear preserves coordinator state");
        check(c.reserve("B3", "CAM2", day, 1).startsWith("Confirmed:"),
                "another borrower unaffected by B1 limit");
        check(snapshot.size() == 4 && c.reservations().size() == 5,
                "old snapshot does not track later additions");
        check(snapshot.get(0).period().start().equals(day), "stored period preserved");

        ReservationCoordinator invalid = new ReservationCoordinator();
        check(invalid.reserve("B1", "CAM1", day, 0).equals(
                "Rejected: borrower limit or duration."), "zero duration rejected");
        check(invalid.reserve("B1", "CAM1", day, -1).equals(
                "Rejected: borrower limit or duration."), "negative duration rejected");
        check(invalid.reserve("B1", "CAM1", day, 8).equals(
                "Rejected: borrower limit or duration."), "eight-day duration rejected");
        expect(IllegalArgumentException.class, () -> invalid.reserve(" ", "CAM1", day, 1),
                "blank borrower");
        expect(IllegalArgumentException.class, () -> invalid.reserve("B1", null, day, 1),
                "null item");
        expect(NullPointerException.class, () -> invalid.reserve("B1", "CAM1", null, 1),
                "null request date");
        expect(DateTimeException.class, () -> invalid.reserve("B1", "CAM1", LocalDate.MAX, 1),
                "unrepresentable end date");
        check(invalid.reservations().isEmpty(), "invalid requests store nothing");
        expect(IllegalArgumentException.class,
                () -> new Reservation("", "B1", "CAM1", first), "blank reservation identifier");
        expect(NullPointerException.class,
                () -> new Reservation("R1", "B1", "CAM1", null), "null reservation period");
        System.out.println("All " + checks + " chapter checks passed.");
    }

    private static void check(boolean condition, String label) {
        if (!condition) {
            throw new AssertionError(label);
        }
        checks++;
    }

    private static void expect(Class<? extends Throwable> type, Runnable action,
                               String label) {
        try {
            action.run();
        } catch (Throwable error) {
            check(type.isInstance(error), label + ": wrong exception " + error);
            return;
        }
        throw new AssertionError(label + ": expected " + type.getSimpleName());
    }
}