Lecture Slides

• 1: Chapter 1: Developing Software That Can Change
• 2: Chapter 2: Object-Oriented Development Beyond Syntax
• 3: Chapter 3: Agile Development and the Nature of Change
• 4: Chapter 4: From Requirements to an Iteration
• 5: Chapter 5: Responsibilities, Extension, and Substitutability
• 6: Chapter 6: Interfaces, Dependencies, and Composition
• 7: Chapter 7: Testing as a Design Practice
• 8: Chapter 8: Creating and Connecting Objects
• 9: Chapter 9: Designing Changing Behaviour
• 10: Chapter 10: From Classes to Application Structure
• 11: Chapter 11: Refactoring and Legacy Code
• 12: Chapter 12: Measuring Progress, Flow and Technical Health
• 13: Chapter 13: Integration, Delivery and Feedback
• 14: Chapter 14: Responding to Change and Handing Over
• 15: Chapter 15: AI as a Software Engineering Assistant

1 - Chapter 1: Developing Software That Can Change

Chapter 1: Developing Software That Can Change

SE506: Object Oriented Development and Agile Practices

Dr. Polla Abdulhamid Fattah
Department of Computer Science & Artificial Intelligence
University of Kurdistan Hewlêr (UKH)

Chapter Roadmap (1 of 3)

• 1.1 When a working program meets a new request
  • One small Java rule, and a change that the rule cannot absorb by editing numbers.
• 1.2 What does “it works” actually mean?
  • What “it works” leaves out, and the kinds of change a team makes.
• 1.3 How design and delivery fit together
  • Responsibilities, iterations, increments, and how design meets process.
• 1.4 How do we know a change is right?
  • Acceptance examples, regressions and the evidence a reviewer can use.

Chapter Roadmap (2 of 3)

• 1.5 Working with an AI assistant without giving up your judgement
  • Activity 1A: separating the claims a code explanation gets right from the one it invents.
• 1.6 The project we will build, and the road ahead
  • The Campus Equipment Lending System, its vocabulary and how the chapters build on each other.
• 1.7 How to read this book, and any other
  • Predicting before running, keeping a learning record, reading advice as a claim.
• 1.8 Easy mistakes, and how to spot them
  • Five mistakes, each exposed by a small counterexample.

Chapter Roadmap (3 of 3)

• 1.9 Try it yourself: a readiness check
  • Tasks A, B and C: predict, find a fault, plan the staff change.
• 1.10 Questions to think with
  • Six questions, then a room-booking change in a different domain.
• What to take away, and what comes next
  • What to carry into Chapter 2, which examines how objects protect their state.

Learning Outcomes

After working through this chapter, you should be able to:

1. Explain why a functioning program may still be difficult to maintain.
2. Describe how object-oriented design, iterative delivery, testing and review contribute to a controlled change.
3. Read a small Java class and distinguish its actual behaviour from assumptions about the larger system.
4. Identify evidence needed to evaluate a proposed change or an AI-generated explanation.
5. Use the book’s learning route and a readiness diagnostic to plan your study.

How to Use This Chapter

• Core reading: Sections 1.1 to 1.8.
• What you must do: Task A, Task B (the paper part), Task C and Activity 1A.
  • Together they produce every item in “What to produce”.
  • Everything can be done by tracing the code on paper.
• If you want more: run the program and the deliberate fault (needs a Java Development Kit), then answer the questions and the transfer challenge.

Prerequisites and Status of This Chapter

• Prerequisites: basic familiarity with variables, conditions, methods and classes.
• Not needed yet: design patterns, a testing framework or an Agile project-management tool.
• If Java syntax is unfamiliar, read the explanation beside each example, then the Java reading in the sources. Appendix A has a short Java refresher and a readiness diagnostic.
• This is an orientation chapter. It adds no teaching week and previews ideas that later chapters teach in full.
• Its code is an orientation example for the book’s project: ReservationRules stays outside the running Campus Equipment Lending code, which starts with the Chapter 2 starter.

Opening Scenario: A Program That Works

• A university lends cameras, microphones and other equipment to students.
• Your team has written a small program that decides whether a student may request another reservation.
• It checks two things: the number of active reservations and the requested duration.
• The examples you tried produce the expected answers.
• So far, nothing is wrong.

Then the Equipment Officer Asks for a Change

Staff should also be able to borrow equipment, but their reservation limits will be different. The existing student limits should stay the same.

• The change sounds simple. Perhaps one more condition and two new numbers.

The Questions the Change Raises

• Where do the current limits appear?
• How will the program know whether a borrower is a student or a staff member?
• Which existing behaviours must be preserved?
• What evidence will show that the new rule works?
• None of these can be answered by looking only at the new numbers.

Why This Book Starts Here

• We will build software, and we will also examine how it is understood, tested, reviewed and changed.
• The goal is to make decisions that:
  • another developer can inspect, and
  • the team can revise when requirements develop.
• Every chapter returns to the same habit: state a claim, then name the check that could show it to be wrong.

1.1 When a Working Program Meets a New Request

One small rule and a change it cannot absorb

The Initial Rules

The equipment office gives us three rules:

• A student may have at most three active reservations.
• A requested loan lasts from one to seven days, inclusive.
• A request is rejected if the supplied active-reservation count is negative.

These are fictional rule invented for this books for our project, not university policy.

What the Count Means

• Active reservation: a confirmed reservation that has not been cancelled or completed.
• The count passed to the method is the count before the proposed reservation is added.
• The caller must obtain that count correctly.
• The method receives two integers. It never sees a borrower, an item or a calendar.

The Class: ReservationRules

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

• A complete class: one method, two integer inputs, one Boolean result.

Reading the Class

• Neither public nor final proves that the rule is correct.

One Boundary Deserves Attention

• activeReservations < 3: a borrower with two active reservations may request a third.
• A borrower who already has three may not request a fourth.
• Writing <= 3 would allow one reservation too many if the successful request were then confirmed.
• The count is measured before adding the new reservation. That is why the test is “less than three”.

Five Calls, Traced

What true Does and Does Not Mean

• A larger application must perform the other checks before confirming a reservation.

The Risk of a Suggestive Name

• Method names can suggest more than their implementations establish.
• A developer who reads true as “the reservation is confirmed” may introduce a defect.
• The class itself behaves exactly as written. The defect lives in the reader’s assumption.
• Habit for the whole book: state what a result does and does not establish.

A Deliberate Simplification

• Returning false for a negative count treats an impossible input like an ordinary refusal.
• A caller bug can then look like a policy decision.
• We accept this here to keep the example small.
• Chapter 5 returns to contracts, and to how code should respond when a caller breaks them.

The Changed Requirement, Clarified

Students keep three active reservations and seven days. Staff may have up to five active reservations and request up to fourteen days.

• Students: 3 reservations, 7 days (unchanged).
• Staff: 5 reservations, 14 days (new).

Why Editing the Numbers Fails

• Replacing 3 with 5 and 7 with 14 makes the method more permissive for everyone.
• A student with zero reservations requesting eight days is now accepted. That is a regression.
• Student with four reservations requesting one day: also accepted, and wrongly.
• The method receives no borrower category, so it cannot tell students from staff by its inputs.

Before Editing: Three Questions

1. How is the borrower category established?
2. What should happen if the category is missing or unknown?
3. Which student behaviours must be checked again after the change?

• The answers come from the requirement, not from the original code.

Do Not Guess the Unknown Case

• Do not silently decide that every unrecognised borrower receives the staff allowance.
• That is a requirements decision, not a fact we can infer from the original code.
• Related questions to raise with the equipment officer:
  • How is the category obtained?
  • What if someone holds both roles?
• Ask, and record the answer.

Several Possible Implementations

• Each approach creates different obligations for callers and different places for mistakes.

A Proportionate Choice

• At this stage we do not need to select a design pattern.
• We need to:
  • understand the rule,
  • preserve student behaviour, and
  • choose a proportionate implementation.
• Chapters 5 and 6 return to this kind of problem with more precise design tools.

Discussion: What Would You Ask the Equipment Officer?

• Write down three questions before any code is changed.
• Prompts:
  • Where does the category come from, and can a caller simply claim it?
  • What happens to a request whose category is unknown?
  • Is there anyone who is both student and staff?
• Real callers must not grant privileges merely because a user claims a category.

1.2 What Does “It Works” Actually Mean?

Does it work, and how hard will it be to change?

“Does It Work?” Needs a Condition

• To answer usefully we must say what behaviour is expected and under which conditions.
• For the reservation rule: an expected result for a seven-day student request.
• For the complete application we also need expectations about:
  • equipment availability,
  • recording reservations,
  • reporting failures.
• A successful demonstration of one request does not answer all of those questions.

Maintainability

• A further question: how difficult will the software be to change correctly?
• Maintainability is our ability to understand, diagnose, test and modify software over its useful life.
• In this book we look for practical evidence of that ability.
• It is not a label attached to a diagram.

One Decision, Three Places

• The seven-day limit appears in:
  • a command-line screen,
  • a reservation service,
  • a report generator.
• A developer updates two locations and misses the third.
• Each expression may be easy to read, yet the system is difficult to change consistently.
• The problem lies in how one decision is represented across the codebase.

The Codebase Is More Than Source Code

• A codebase is the body of source code and supporting material that the team maintains together.
• Its tests, build instructions and configuration affect whether another person can work with it.
• A clear method inside a project that no one else can build is only part of a maintainable solution.

Making Quality Claims Concrete (1 of 2)

Making Quality Claims Concrete (2 of 2)

• These concerns interact.
• Moving a rule into its own component can ease testing; many tiny components can make navigation harder.
• Explain a design choice by the problem it solves and the cost it introduces.

Kinds of Change

• Keeping these intentions separate makes review easier.
• A reviewer should know whether a changed result is deliberate or accidental.

What Is Expected of You

• You will not be expected to make the project ready for every possible future.
• You will be expected to:
  • state its assumptions, and
  • respond thoughtfully when a relevant assumption changes.

1.3 How Design and Delivery Fit Together

Where design and process meet

Objects and Responsibilities

• Object-oriented development organises software around objects with state, behaviour and responsibilities.
• A responsibility is an obligation assigned to part of the system. For example:
  • representing a loan period,
  • deciding whether a borrower is eligible,
  • recording a confirmed reservation.

A Class Is Not Automatically a Good Design

• Putting code inside a class does not create a useful design. A class can still:
  • contain unrelated decisions,
  • expose information that callers can misuse,
  • depend on details scattered through the application.
• Chapter 2 examines these problems through encapsulation, cohesion and coupling.

Keeping Meanings Clear

• In the equipment-lending domain, an equipment item and a reservation are different things.
• The item is something the university owns.
• The reservation is an arrangement concerning that item for a period.
• Keeping these meanings clear helps the team discuss requirements before it decides which fields or methods are needed.

Iteration and Increment

• An iteration is a repeated period of work and feedback.
• An increment adds usable capability to what already exists.
• A team can improve a reservation workflow over several iterations while delivering successive increments of functionality.
• One iteration might refine a flow without adding a new feature, so the terms are not interchangeable.

Agile Principles in One Sentence

• The Agile principles connect frequent delivery and adaptation with continuing attention to technical quality.
• They also call for teams to reflect and adjust their way of working.
• The implication for our project is practical:
  • feedback should influence what we build and how we build it.
• This chapter does not yet teach a complete Agile framework (Chapter 3 does).

A Demonstration Reveals a Mismatch

• Suppose an early demonstration shows that the equipment officer uses “reservation” to mean a confirmed allocation.
• The team has used it for an unapproved request.
• The feedback can change names, states and user messages.
• Found in a small working increment, the mismatch gives a concrete example and a bounded amount of code to revise.

Design and Process Meet at the Change

• Planning decides which behaviour the team intends to deliver.
• Design decides where its decisions belong.
• Tests and review help determine whether the implementation matches those intentions.
• Feedback may revise the intentions, or reveal a weakness in the structure.

Figure 1.1: A Change Moves Through a Cycle

Reading the Figure

• A mismatch may reveal a defect, a mistaken expectation or an unclear requirement.
• User feedback can begin another cycle after the increment is accepted.
• The diagram is a learning model, not a mandatory sequence where each activity happens once.
• In practice a developer may clarify a detail while writing a test, or revisit design during review.

1.4 How Do We Know a Change Is Right?

What would make us willing to accept the change?

Acceptance Examples

• Acceptance examples are concrete situations with expected outcomes, agreed from the requirement.
• Examples are agreed before the change is trusted.
• They make the distinction between categories visible.
• They stop us validating the change using only staff cases and forgetting existing student behaviour.

Acceptance Examples for the Staff Change

• They do not resolve an unknown borrower category. That still needs clarification.

Automated Tests and Regressions

• An automated test performs a check repeatedly and compares observed behaviour with an expected result.
• A regression is an unintended loss or alteration of behaviour that previously worked.
• Regression checks help reveal such changes.
• Their usefulness depends on what they examine and whether their expectations are correct.

A Test That Misses the Boundary

// original
&& requestedDays <= 7;

// accidental change
&& requestedDays < 7;

• A test of a two-day request passes with both versions.
• A seven-day request exposes the difference: true becomes false.
• Both versions compile.

Compiling Is Not Checking Policy

• The compiler checks language rules.
• It does not know that the equipment office permits seven days.
• So a successful compile tells us the source is well formed, nothing more.
• Which brings us to the question: what evidence do we have?

Several Kinds of Evidence (1 of 2)

Several Kinds of Evidence (2 of 2)

• No row is a guarantee beyond its scope.
• Strong decisions combine several kinds.

A Review Connects the Evidence

• A reviewer might ask:
  • Why is the staff category trusted?
  • Does the student boundary remain covered?
  • Does the explanation match the actual diff?
• A diff is a comparison showing changes between versions of files.
• It gives the discussion a concrete object: precisely what is being proposed.

Useful Feedback

• Feedback should lead to an action or a justified decision.
• Good feedback names a problem and its consequence.

How the Evidence Will Grow

• Chapter 7 develops automated testing and test-driven development.
• Chapter 11 examines safe changes to unfamiliar code.
• Chapter 13 checks interactions between components and introduces delivery pipelines.
• Here the essential habit is: match each claim with a check that could reveal it to be wrong.

1.5 Working with an AI Assistant Without Giving Up Your Judgement

Candidate contributions to examine

AI Output Is a Candidate Contribution

• An AI coding assistant may:
  • offer an explanation,
  • suggest an implementation,
  • propose test cases,
  • review a change.
• These are useful candidates to examine.
• They do not automatically settle what the system should do, or whether an answer is correct.

What a Vendor’s Own Documentation Says

• GitHub’s documentation for Copilot inline suggestions warns that a suggestion can look valid and still be incorrect.
• It says users are responsible for reviewing and validating suggestions before accepting them.
• This is guidance about one tool, not evidence that every model behaves identically.
• In this book we apply the same review discipline to any candidate output.

Activity 1A: Evaluate a Candidate Explanation (1 of 2)

Activity 1A: Evaluate a Candidate Explanation (2 of 2)

What Kind of Output Is This?

• The candidate output on the next slide is an author-written teaching example of a plausible AI response.
• It was constructed for this exercise. It is not a recorded output from a particular model.
• Do not present it as evidence about any real model’s performance.

The Candidate Output

The method permits a request only when the active-reservation count is non-negative and below three, and the requested duration is between one and seven days inclusive. It returns a Boolean result. Before returning true, it consults the equipment database to confirm that the requested item is available.

Break It into Claims

For each claim, record:

1. Whether the code supports it, contradicts it, or provides insufficient information.
2. The expression, input or operation that justifies your decision.
3. Any further information needed to make a broader claim about the application.

• Then write a corrected explanation in two or three sentences.
• Preserve the accurate parts. Do not reject everything because one part is wrong.

Worked Answer: Claim Classification

Why the Database Claim Fails

• The method receives neither an item identifier nor a period.
• It performs no call to any database or availability service.
• The larger application’s availability behaviour is unknown from this class.
• Keep the scope precise:
  • “this method does not query a database” is true;
  • “the whole application never queries a database” is not established.

A Corrected Explanation

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.

The Key Skill Is Locating Evidence

• The presence of a database elsewhere in a real application would not establish that this method consults it.
• A missing database call in this class would not prove that no other component ever checks availability.
• Strong answers separate local behaviour from system assumptions.

Optional: Using a Live Assistant

• The supplied example is sufficient. If live AI use is permitted and available, an optional prompt is:

Explain only the behaviour visible in this Java class. Identify its inputs, returned result and any state changes. Separate facts visible in the code from assumptions about its caller. Do not invent surrounding services or rewrite the program.

Checking a Live Response

• Provide the class and compare the response with your own trace.
• A confident explanation still needs checking.
• A careful prompt does not guarantee a correct answer.
• Record:
  • the tool used,
  • the claim you accepted or rejected,
  • the evidence behind that decision.

The Shared-Misunderstanding Danger

• If the same misunderstood requirement influences both an implementation and its tests, they may agree with each other.
• They can then both disagree with the intended policy.
• Reviewing expected results against a clarified requirement is necessary even when all generated tests pass.

Rules for AI Use in This Book

• Use synthetic project data.
• Follow the module leader’s current rules for permitted AI use in assessments.
• Every AI exercise has a route that does not require a paid service.
• Chapter 15 collects the recurring workflows and is meant to be consulted alongside any chapter.
• This chapter’s activity is self-contained.

1.6 The Project We Will Build, and the Road Ahead

The Campus Equipment Lending System

The Running Example

• Throughout the book we develop the Campus Equipment Lending System in Java.
• The first useful system supports a small set of activities:
  1. inspect availability,
  2. request a reservation,
  3. confirm an eligible request,
  4. issue the equipment,
  5. record its return.

Starting Simple

• We begin with a simple interface and data held in memory.
• This keeps early examples focused on domain behaviour.
• Later chapters introduce the boundaries needed to work with storage and external services.
• The opening ReservationRules is a small orientation example, not the completed application and not a promise that its structure will remain unchanged.

Orientation Code vs. the Running Project

• ReservationRules is a separate teaching example.
• The running project begins with the Chapter 2 starter.
• Each later chapter states whether its code joins that project or stays on a separate teaching branch.
• Appendix D lists, for every chapter:
  • where the project stands,
  • which count a build should report,
  • the rules of the domain.

Domain Vocabulary

Reservation vs. Loan

• A reservation and a loan are related but distinct.
• A confirmed reservation can exist before the borrower collects the equipment.
• Cancelling a reservation is different from returning an item already issued.
• Confusing the two is the kind of mismatch a demonstration should expose early.

Initial Scope

• One item per reservation.
• Explicit periods.
• Synthetic borrowers.
• Once we represent actual dates and times, we must define:
  • when periods overlap, and
  • whether one period can begin exactly when another ends.
• The integer duration in Section 1.1 does not settle those calendar rules.

Invariants

• We will preserve invariants: conditions the domain requires to remain true during valid operation.
• Examples:
  • a valid loan period,
  • no conflicting confirmed reservations for the same item and period,
  • no return operation on an inactive loan.
• These guide the evolving implementation. The small rule class has not already implemented all of them.

How the Chapters Build on One Another (1 of 2)

How the Chapters Build on One Another (2 of 2)

Project Versions

• Chapters 2 to 14 follow the thirteen teaching weeks. This introduction and Chapter 15 add none.
• Versions for the team project:
  • Week 3: kickoff.
  • Week 6: a minimum viable product.
  • Week 9: patterns and application structure.
  • Week 12: a verified response to changed requirements.
• The later assessment change is introduced in Week 11.

The Book’s Project and Your Team’s Project

• The book’s worked system provides shared examples.
• Each practical activity says whether it runs on the book’s project or on your team’s project.
• Teams choose a domain the module provides. Equipment lending and an ML model-serving tool are examples.
• If your team uses another domain its change requests will differ, so each chapter ends with a transfer note.

Transfer, Not Copying

• Learn the reasoning well enough to apply it elsewhere.
• Copying an equipment-related class name into another project does not establish that the responsibility belongs there.
• The question to ask each time: what problem made this structure useful?

AI and Data Components

• The module aims to prepare you to build reliable software around AI and data components.
• The running project reflects that. It does not require training a model.
• The book takes the data-backed route. Its collaborator is the equipment directory.
• The directory answers: “who is this borrower, and which category are they in?” from outside the application.
• The domain code depends on it only through a contract.

Meeting the Equipment Directory in Steps

What the Book Is Not

• If your project uses a model-serving domain, the same questions apply to the component that calls the model.
• Using AI to help write software is a different topic. Chapter 15 covers it.
• Neither turns this book into a machine-learning implementation course.

1.7 How to Read This Book, and Any Other

Predict, record, evaluate

Predict Before You Execute

1. Select one ordinary case and one case near a limit.
2. Trace the decisions.
3. Write the expected result.
4. Only then compare it with the program’s output.

• A mismatch is an opportunity to find out whether your understanding, the code or the requirement needs correction.

Reading a Worked Design

• Ask what problem made the additional structure useful.
• If the chapter introduces a new class, identify the responsibility it receives.
• If it introduces an interface, identify the caller that benefits from it.
• If you cannot name the benefit, reread the problem before copying the solution.

Keep a Learning Record

For each practical session, three entries:

1. The decision you made.
2. The evidence you used.
3. The uncertainty that remains.

Reading Software-Engineering Advice

• Technical books recommend practices for particular circumstances.
• Read recommendations as claims to understand and evaluate.
• Hypothetical statement: “Give every class an interface.” Ask:
  • Which callers need interchangeable behaviour?
  • What coupling does the interface reduce?
  • Does the extra file make this example easier to understand?
• Criticise the strongest reasonable interpretation, not an exaggerated version.

The Reading Record (1 of 2)

The Reading Record (2 of 2)

The Critical Review Assignment

• The module includes an individual critical review of a book from the approved software-design and Agile-engineering list, due in Week 8.
• It asks you to:
  • evaluate the book’s principles and examples,
  • discuss their trade-offs and limits,
  • consider how they apply to engineering AI-enabled systems, supported by additional sources.
• Follow the current assignment brief for exact requirements. Appendix E develops the review method.

What This Textbook Does Not Replace

• This textbook does not replace the book you select.
• An AI summary of a book you have not read is not evidence about it.
• Begin reading early.
• The reading record above is enough to start a useful record now.

1.8 Easy Mistakes, and How to Spot Them

Each exposed by a small counterexample

Mistake 1: Reading true as “Confirmed”

• Mistake: reading true as “the reservation is confirmed”.
• Counterexample: mayRequest(0, 1) returns true even if the camera is already reserved for that day.
• Better habit: state what a result does and does not establish.

Mistake 2: Changing the Numbers

• Mistake: changing the numbers to add the new behaviour.
• Counterexample: replacing 3 and 7 with 5 and 14 accepts a student request for eight days.
• Better habit: preserve existing cases while adding the new ones.

Mistake 3: Treating Passing Tests as Proof

• Mistake: treating passing tests as proof.
• Counterexample: a test that expects students to borrow for fourteen days passes beside an implementation with the same error.
• Better habit: check expected results against the clarified requirement.

Mistake 4: Trusting a Fluent Explanation

• Mistake: trusting a fluent explanation.
• Counterexample: Activity 1A’s explanation mixes accurate claims with an invented database call.
• Better habit: locate the code or requirement behind each claim.

Mistake 5: Assuming the Edit Is Local

• Mistake: assuming the edit is local.
• Counterexample: the seven-day limit may also appear in a screen and a report.
• Better habit: search for where each decision is represented before editing.

1.9 Try It Yourself

A readiness check

What the Diagnostic Is

• It helps identify what you need to practise.
• It is not a new graded assessment.
• It runs on the book’s project: the Java class in Section 1.1, its stated rules and the staff change are your materials.
• No team code is needed.

Task A: Predict the Results

Without running the code, predict each result and name the condition that explains it.

Task A: Also Identify

• The class name, method name, parameter types and return type.
• Whether a call modifies a reservation count or records a new reservation.
• If a keyword is unfamiliar, distinguish that syntax gap from a difficulty understanding the rule.

Task A: Answers

Task A: Reading the Class

• Class: ReservationRules. Method: mayRequest.
• Both parameters are int; the return type is boolean.
• There are no fields, no assignments to shared state, no storage calls and no reservation creation.
• Calling the method neither increments a count nor reserves equipment.
• Its result is narrower than overall eligibility or confirmation.

A Caution About final

• Do not teach that final makes all Java objects immutable.
• Here it only prevents subclassing.
• The relevant absence of state changes is explained by the absence of mutable state and by the body of the method.

Task B: Examine One Small Fault

• A developer changes requestedDays <= 7 to requestedDays < 7.
• Provide one input that distinguishes the original and the modified version.
• State both results.
• Explain which result agrees with the initial requirement.

Task B: Answer

• mayRequest(2, 7) distinguishes them.
• Original: true. Faulty < 7 version: false.
• The original agrees with the explicit inclusive maximum of seven days.
• Any input with seven days and a valid count from zero to two works as a counterexample.

Optional Execution: The Demo Class

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));
    }
}

• Save the rule as ReservationRules.java and this as Chapter01Demo.java.
• new ReservationRules() creates the object on which the method is called.

Compile and Run

javac ReservationRules.java Chapter01Demo.java
java Chapter01Demo

true
false

• Run from the directory containing both files, using a Java Development Kit.
• Appendix B gives a full, reproducible development setup. Installing tools is not required for the paper diagnostic.

Each Call Evaluates Only Its Arguments

• The first call does not increase any count.
• Calling mayRequest(2, 7) repeatedly returns the same result.
• The complete application would have to update its reservation records separately.
• Printing the returned values makes the difference visible without building a user interface.

Repeatable Checks: The Runner

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);
    }
}

Repeatable Checks: The Data

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}
};

• Each row: existing count, requested days, expected result (1 means true).
• The conversion to Boolean is a convenience for the example, not a modelling recommendation.
• Expected output: All 12 chapter checks passed.

Running the Checks Needs No Library

• AssertionError is thrown explicitly, so it works without enabling Java’s optional assert statements.
• The runner stops at the first mismatch.
• It is not meant to teach the full testing approach. That is Chapter 7.
• The 12 checks cover the diagnostic cases and several nearby boundaries.

Two Deliberate Faults, Two Failure Messages

• The (3, 7) case would also fail, but (3, 1) appears earlier in the table.
• Make a temporary copy first, and restore the original expression afterwards.

Task C: Plan the Staff Change

Write a short change note (no complete redesign). Include:

• The behaviour that must remain unchanged for students.
• The new staff behaviour and the extra information needed to select it.
• One unresolved question to clarify rather than guess.
• At least four acceptance examples covering both categories and their limits.
• One simple implementation approach and one trade-off.
• An evidence statement of two or three sentences.

Task C: Suggested Acceptance Examples

Task C: What the Examples Leave Open

• Four well-chosen examples are enough. They must cover both categories and meaningful limits.
• Negative counts and non-positive durations stay invalid for both.
• None of these decisions establishes availability.
• Counts are measured before the new reservation is added.

Task C: A Strong Evidence Statement

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.

Task C: What Makes a Weak Answer

• Weak answers say only that “the code works” or that “all tests pass”.
• A good evidence statement names checks that could fail.
• It also says what the evidence would still not show.

Task C: Choosing an Implementation Approach

• A small conditional with an explicit category is an acceptable initial approach.
  • Advantage: directness.
  • Cost: repeated category conditions may spread if more policy decisions appear.
• Passing limits into a shared calculation can also be reasonable.
  • It moves the obligation to select and validate limits to a caller.
• Accept either with a coherent rationale. Do not reward an early interface hierarchy just for using patterns.

What to Produce

Submit or retain, as your instructor directs:

• your completed prediction table,
• your fault-revealing input,
• the short change note with its evidence statement,
• the AI claim analysis,
• the readiness checklist.

If you run the program, include the observed result and say which version produced it.

The Task Is Complete When

• Your predictions follow the code.
• Your proposed change preserves the original student rule.
• Your acceptance examples could reveal a boundary error.
• Your evidence statement names checks that could show the change to be wrong.
• You can explain why the method alone cannot confirm equipment availability.

Readiness Checklist

Choose Your Next Action

Pick one item marked “Need practice” and state your next action:

• Syntax: use the relevant Java tutorial (Appendix A has a refresher).
• Tracing: work through another input with a partner.
• Requirements: rewrite the rule as concrete examples and identify what remains unanswered.
• If you want more: once your team has chosen its domain, repeat Task C for one numeric limit in that domain.

1.10 Questions to Think with

Concept, diagnosis, transfer

Concept Questions

1. Give an example of software that produces the expected result today but is difficult to maintain. What makes the next change risky?
2. Explain the difference between an iteration and an increment using the equipment-lending project.
3. Why does passing a set of tests provide useful but limited evidence? Include an example of an incorrect expectation.
4. Distinguish a behaviour change from a refactoring. Why should a reviewer know which one is intended?

Diagnosis Questions

5. A developer replaces the student limits of three reservations and seven days with five and fourteen. Staff examples now pass. Explain why this is insufficient evidence that the requested change is correct, and give a student example that exposes the problem.
6. An AI assistant writes a method and tests for it. Every test passes, so the team accepts the change without comparing it with the equipment officer’s rules. Identify the gap in the reasoning and propose a check that addresses it.

Guidance: Questions 1 and 2

1. A rule duplicated across several screens and services may pass today’s examples yet need coordinated edits tomorrow. Name the risk of inconsistent copies, not just “ugly code”.
2. An iteration is a repeated period of development and feedback. An increment adds usable capability, such as a reservation flow. An iteration might refine a flow without adding a feature, so the terms are not interchangeable.

Guidance: Questions 3 and 4

3. Tests cover selected expectations. A test that wrongly expects students to borrow for fourteen days can pass beside an equally wrong implementation. Compare expectations with the clarified policy.
4. Allowing staff fourteen days adds behaviour. Reorganising the same rule without changing outcomes is refactoring. Knowing the intention helps a reviewer decide whether a changed result is a defect or a feature.

Guidance: Questions 5 and 6

5. A student with zero active reservations requesting eight days should still be rejected. Replacing all limits with staff limits would accept it. 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: Room Booking

A room-booking application allows each student society up to two active bookings, each lasting at most two hours. University departments now need up to four active bookings, each at most three hours. The society rules stay unchanged.

• Prepare a change note using the method from Task C.
• State assumptions about duration values and booking status.
• Give one example that must remain rejected for a society but is allowed for a department.
• Identify one fact about room availability that these numeric rules cannot establish.

Transfer Challenge: Guidance

• One acceptable assumption: durations are positive whole hours, and counts refer to active confirmed bookings before adding another.
• Raise the policy for unknown groups and define what “active” means.
• A society with two active bookings requesting one hour is rejected. A department with the same count and duration may be allowed.
• Checking a room needs a room identity and a requested time interval. Count and duration alone cannot establish that a room is free.

What to Take Away, and What Comes Next

What to carry forward

Summary: A Working Program Is a Starting Point

• To change a program responsibly we need to:
  • understand the requested behaviour,
  • locate the decisions that implement it,
  • identify what must remain true.
• In the reservation example, the new requirement could not be met by editing numbers.

Summary: Design, Delivery and Evidence

• Object-oriented design helps organise responsibilities.
• Iterative delivery creates opportunities to inspect useful increments and revise understanding.
• Tests, reviews, demonstrations and version history each contribute a different kind of evidence.
• None should be mistaken for a guarantee beyond its scope.

Summary: AI-Assisted Work Needs Judgement

• A plausible explanation can combine accurate observations with an invented operation.
• Evaluate individual claims against the code and the requirements.
• Record why a contribution was accepted or rejected.

Next: Chapter 2

• Chapter 2: Object-Oriented Development Beyond Syntax.
• How objects protect their state.
• How responsibilities are assigned.
• How cohesion and coupling affect the changes we make.
• The equipment-lending project gives those ideas a concrete setting, starting from the Chapter 2 starter.

Sources and Further Reading

1. Dev.java. Classes and Objects. Official Java learning material on classes, methods, constructors and objects.
2. Authors of the Agile Manifesto. Principles behind the Agile Manifesto, 2001.
3. Fowler, Martin. Definition of Refactoring, 2004.
4. GitHub Docs. Application card: GitHub Copilot inline suggestions.

• Full references and links are in the chapter text.

2 - Chapter 2: Object-Oriented Development Beyond Syntax

Chapter 2: Object-Oriented Development Beyond Syntax

SE506: Object Oriented Development and Agile Practices

Dr. Polla Abdulhamid Fattah
Department of Computer Science & Artificial Intelligence
University of Kurdistan Hewlêr (UKH)

Chapter Roadmap (1 of 3)

• 2.1 Objects: their knowledge, behaviour and identity
  • Four small classes, three kinds of identity, mutable and immutable objects.
• 2.2 Who is responsible for keeping things true?
  • The half-open period convention and who protects which condition.
• 2.3 Keeping state safe: encapsulation and information hiding
  • Why private is not enough, and what List.copyOf does.
• 2.4 Is a long method the problem? Cohesion and coupling
  • Diagnosing a method by its reasons to change, then one modest refactoring.

Chapter Roadmap (2 of 3)

• 2.5 Has-a or is-a? Composition and inheritance
  • Use versus subtype, and why a hierarchy is not the default.
• 2.6 Drawing the design: UML class diagrams to read, write and check
  • The notation the midterm assesses, so it gets the most time.
• 2.7 Making a change someone else can review
  • A small, reviewable change and the commands that inspect it.
• 2.8 Checking an AI’s explanation of the coordinator
  • Classifying the claims of a plausible but flawed explanation.

Chapter Roadmap (3 of 3)

• 2.9 Mistakes that look like good design
  • Eight misconceptions, each with a better question.
• 2.10 Try it yourself: improve the design, with evidence
  • Parts A to D: trace, diagnose, change, organise the team.
• 2.11 Questions to think with
  • Room-booking coordinator in a different domain.
• What to take away, and what comes next
  • What carries into Chapter 3 (Agile development and the nature of change).

Learning Outcomes (1 of 2)

By the end of the chapter, you should be able to:

1. Assign responsibilities to objects and explain the state they protect.
2. Distinguish encapsulation and information hiding from mechanically adding getters and setters.
3. Diagnose cohesion and coupling problems using concrete change scenarios.

Learning Outcomes (2 of 2)

4. Compare composition with inheritance and justify a modest design choice.
5. Draw and interpret a small UML class diagram that matches the code, using associations, multiplicity, aggregation, composition, inheritance and interface realisation appropriately.
6. Make a behaviour-preserving improvement and present it as a reviewed Git change.

How to Use This Chapter

• Core reading: Sections 2.1 to 2.9.
  • Section 2.6 (UML class diagrams) is the notation the midterm assesses, so give it the most time.
• What you must do: the Section 2.8 AI activity and Parts A to D of Section 2.10.
  • Parts A to C run on the book’s project; Part D concerns your team’s project.
• If you want more: the optional investigation at the end of 2.10, then the questions and the transfer challenge.

Build on Chapter 1, Use the Companion

• This chapter builds on Chapter 1’s reservation-rule example.
• You should be able to trace conditions, call methods and explain a returned value.
• Java’s official class tutorial gives targeted syntax revision. Appendix A has a short refresher.
• The companion holds every complete source file, a starting version, a completed refactoring, checks and suggested answers.
• Use its starting listings first. Consult solutions after attempting the activity.

Toolchain Baseline

• Java 17 language and API baseline. No preview features, no external dependencies.
• A JDK is required to compile the examples.
• JUnit, Maven and CI configuration are not prerequisites for this first design exercise.
• They are introduced with the relevant later work. Appendix B records the toolchain and commands for the whole book.

Weekly Reading and the Project Version

• Reading: Martin, Agile Software Development: Principles, Patterns, and Practices. The Part I introduction and the object-oriented design fundamentals. Sections 2.1 to 2.5 are the practical counterpart.
• Starting version: the Chapter 2 starter in the companion.
• Resulting version: the same code after the confirmation extraction. It becomes the running baseline for later chapters.
• The fault demonstrations and the notation examples in 2.6 are separate teaching material. They do not join the project.

Opening Scenario: A Demonstration That Works

• The equipment officer can now try a small reservation application.
• It checks a borrower’s limit, looks for a conflicting reservation, records a successful request and returns a confirmation message.
• The demonstration works.
• But the developer who wrote it is absent when another team member is asked to change the message.

The New Developer Opens ReservationCoordinator

• One method does all of this:
  • counts reservations,
  • applies a borrowing rule,
  • searches for date conflicts,
  • creates a record,
  • assembles the confirmation text.
• Which lines may be changed safely?

Three Questions to Carry Through the Chapter

1. Why is the conflict check concerned with an equipment item while the count is concerned with a borrower?
2. Could the list of stored reservations be changed from outside the class?
3. Which responsibilities belong together, and how should other code be allowed to use them?

• Knowing how to declare a class is necessary. It does not answer these.

2.1 Objects

Their knowledge, behaviour and identity

Class and Object

• A class defines a type and its implementation.
• An object is an instance created at run time.
• Two objects from the same class can represent different things and hold different state.
• Java gives us fields, constructors and methods to express these distinctions.

The Reservation Record

• A Reservation records an arrangement involving a borrower, an equipment item and a period.
• Its state:
  • an identifier such as R1,
  • a borrower identifier such as B1,
  • an item identifier such as CAM1,
  • a LoanPeriod.

Identifiers Are Different Kinds of Identity

• Two physical cameras may share a model name but need different item identifiers.
• Two reservations for the same camera on different dates are still separate reservations.
• A borrower’s name is a poor identifier: names can change or be shared by different people.
• The identifiers stand in for borrower and equipment records. A non-blank identifier does not prove a real person or item exists.

Java Object Identity

• Two references can point to the same instance, or to distinct instances that represent the same domain identifier.
• == on references checks whether they refer to the same object.
• Domain equality needs a deliberate definition. It is not automatically established by matching fields.
• Our Reservation does not override equals. Do not assume identifier-based equality.

State and Behaviour

• State is information an object holds.
• Behaviour is what it can do through its operations.
• A reservation can expose its identifier and period without letting callers replace them.
• A coordinator can add a new record after checking the request.
• A period can answer whether it overlaps another period.

Not Everything Needs to Be Mutable

• In the starter, Reservation and LoanPeriod are immutable after construction:
  • their fields cannot be reassigned,
  • their referenced values are immutable,
  • their operations do not modify state.
• The coordinator is different. It accumulates reservations in a private list.

Why the Same Request Can Give a Different Answer

• Chapter 1’s mayRequest only examined supplied numbers.
• A call to the coordinator may change the state that the next call examines.
• After one successful reservation, the same request can be rejected as unavailable.

From the Numeric Rule to a Small System

• ReservationRules stays unchanged: at most three active reservations, one to seven days.
• The staff variation remains a future design exercise.
• This version applies the student policy to every borrower identifier.
• The starter has four domain and application classes.

The Four Starter Classes

The Starter Files

2.2 Who Is Responsible for Keeping Things True?

Who protects which condition?

Responsibility vs. Data

• A responsibility is an obligation assigned to part of the system.
• “Hold two dates” describes data.
• “Represent a period whose end follows its start” describes an obligation that gives the data meaning.

Invariants Belong at Different Boundaries

• An invariant is a condition that must hold for valid objects or valid system states.
• One LoanPeriod can ensure its end is after its start.
• It cannot, by itself, ensure that another reservation has not already claimed the same equipment.
• Local invariants and system-level conditions need different enforcement points.

A Period Convention We Can Test

• Dates are calendar dates with no time of day.
• A period is start inclusive, end exclusive: [start, end).
• 20 October to 22 October covers the 20th and 21st. Another period may begin on the 22nd.
• This is an explicit teaching policy. A real service might require a cleaning or inspection interval, which would need another rule.

LocalDate and the Convention

• Java’s LocalDate is immutable and represents a date without a time or time zone.
• We use isBefore and plusDays to express the convention.
• We do not interpret these dates as UTC instants or fixed numbers of elapsed hours.
• The exclusive-end convention is a project decision, not a rule LocalDate imposes.

The LoanPeriod Constructor

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.");
    }
}

• Missing date: NullPointerException. Zero-length or reversed interval: IllegalArgumentException.

The overlaps Operation

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

• Two periods overlap when each begins before the other ends.
• Both comparisons are strict, so adjacent periods do not overlap.
• requireNonNull throws for a null argument. It does not fabricate a replacement period.

Four Overlap Examples on a Timeline

The Same Examples as a Table

• Comparing start dates alone would miss some of these relationships.

Who Protects Which Condition?

• The constructor protects the local validity of a period.
• ReservationRules protects the numeric policy, only when given an accurate count.
• The coordinator counts its records and checks item conflicts before storing.
• No one class can enforce all of these without information from the others.

Operating Assumptions of the Starter (1 of 2)

• All stored records are confirmed and remain active: no cancellation, completion or expiry.
• Calls occur sequentially in one process.
• Data disappear when the process ends.
• Identifiers are matched exactly, with no normalisation or authentication.

Operating Assumptions of the Starter (2 of 2)

• The coordinator checks availability only against its own stored records.
• Maintenance schedules and other coordinators are outside this version.
• Within one sequential coordinator, checking conflicts before adding prevents the demonstrated overlap.
• It does not establish safe concurrent booking by multiple processes. Later integration work revisits that boundary.

2.3 Keeping State Safe

Encapsulation and information hiding

Three Related Ideas

• Encapsulation groups state with the operations that govern its use, and controls access to that state.
• Information hiding concerns which implementation decisions callers should not need to know.
• Abstraction presents what is relevant to a caller and leaves out unnecessary detail.
• None is achieved simply by writing private before every field.

Abstraction Through an Ordinary Method

• A caller can ask a period whether it overlaps another without repeating the date comparisons.
• That abstraction exists through an ordinary public method.
• It does not need Java’s abstract keyword or a separate interface.
• A useful abstraction still needs a clear contract, including our decision that adjacent periods do not overlap.

Setters Can Defeat Private Fields

• Suppose a class exposes separate setters for a period’s start and end.
• A caller could move the start beyond the current end.
• If each setter merely assigns a field, making the fields private has not protected the relationship between them.

How LoanPeriod Avoids This

• The constructor requires both dates together and validates the relationship.
• It provides readers but no setters.
• To express another period, a caller creates another valid object.
• No invalid intermediate state enters the public protocol.
• In another domain a controlled mutation operation could be right. Immutability is a design choice, not a rule.

A Getter Can Expose a Mutation Path

// Unsafe alternative for diagnosis; not the starter implementation.
public List<Reservation> reservations() {
    return reservations;
}

• The field is private. The caller still receives a reference to the mutable list.

The Attack: clear()

• A caller can invoke coordinator.reservations().clear().
• That erases records without passing through the coordinator’s request checks.
• The next request finds no conflicts.
• “My fields are private” does not mean the state is protected.

The Starter’s Protection

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

• List.copyOf returns an unmodifiable list whose contents are not updated by later changes to the source.
• It protects the list structure and provides a snapshot.

What List.copyOf Does Not Do

• It does not deep-copy the elements.
• It does not make mutable elements immutable.
• Here, Reservation, LoanPeriod, String and LocalDate already provide the immutability needed for the values we expose.
• Be able to explain the protection without claiming all copies are deep copies.

final Does Not Help

• private final List<Reservation> alone would be insufficient.
• final prevents reassignment of the field to another list.
• It does not prohibit add or clear on that list.
• Reference fixed, object immutable, or both? Always ask which.

What Remains Exposed

• The coordinator still exposes more representation than a mature system might require: callers know stored reservations can be inspected as a list.
• That is acceptable for a small teaching version.
• If a caller later needs only a count or an availability answer, a narrower operation may reduce what the caller must understand.

2.4 Is a Long Method the Problem?

Cohesion and coupling

Cohesion

• Cohesion concerns how closely the responsibilities within a component belong together.
• LoanPeriod has a focused purpose: its validation and overlap calculation concern the same period concept.
• A coordinator that also knows message wording, storage details and borrowing policy has more varied responsibilities.

Coupling

• Coupling concerns the dependencies between components.
• A component depends on another when it relies on its type, operations, data format or behaviour.
• Some dependency is necessary: software works because components collaborate.
• The question: does the dependency express a useful relationship, or let unrelated changes spread?

The reserve Method: Validate and Count

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++; }
    }

The reserve Method: Policy and Conflict

    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.";
        }
    }

• Policy is rejected before availability; keep that order.

The reserve Method: Store and Confirm

    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() + ").";
}

• It creates and stores a reservation, then assembles its confirmation. It does not send it.

The Request as a Flow

Not Wrong Merely Because It Has Several Steps

• Coordination often involves several collaborators.
• “The method is long” is not a diagnosis.
• The useful question is: which decisions have independent reasons to change?

Diagnosis by Change Scenario (1 of 2)

Diagnosis by Change Scenario (2 of 2)

• This identifies which changes currently require editing the coordinator, and why.
• A future database is a possible boundary. It is not a reason to build a repository framework now.

A Small Improvement with a Limited Claim

• Extract the confirmation expression into a private method confirmationFor.
• The request method still adds the record first, then returns the helper’s result.
• The helper receives the existing reservation and returns exactly the same text.
• This is a modest refactoring: it gives the formatting a name.

What the Extraction Does Not Do

• It does not create a separate presentation component.
• It does not remove storage coupling.
• It does not make the coordinator thread-safe.
• A private helper changes readability inside the class. A new component would change the collaboration between classes.
• If translation later needs collaborators, a separate formatting responsibility may become justified.

Preserving Behaviour: Text and State

• The supplied checks examine both returned messages and stored state.
• After the extraction both must remain the same.
• Preserving the success string while forgetting to store the reservation would not preserve behaviour.

2.5 Has-A or Is-A?

Composition and inheritance

Composition

• Composition, in the broad programming sense: building behaviour by giving an object collaborators or component objects.
• A Reservation has a LoanPeriod and delegates the overlap question through it.
• A coordinator has a ReservationRules object. It does not inherit from it.

It Fits the Domain Meanings

• A coordinator is not a kind of borrowing rule.
• A reservation is not a kind of period.
• Their relationships concern what they use or contain, not a subtype relationship.

Inheritance

• Inheritance defines a derived class in relation to a superclass.
• Java supports inherited members, method overriding and run-time selection of overridden instance methods.
• These mechanisms can express a useful family of related behaviours.
• They also establish expectations that callers may rely on.

A Hypothetical SpecialReservation

• Suppose a subclass is introduced only because some borrowers have longer limits.
• Is the difference really a new kind of reservation, or a policy governing whether one may be created?
• If staff status can change while an existing reservation keeps its identity, forcing that distinction into a hierarchy may be awkward.

Not a Verdict Against Inheritance

• This does not prove inheritance is always unsuitable.
• Ask: what varies, what remains stable, and what a caller expects from the base type.
• Chapter 5 develops behavioural substitutability more formally.
• For this version, constructors, fields and collaborators already express the relationships without a custom hierarchy.

Composition vs. Inheritance: Questions

Composition Has Costs Too

• Too many small collaborators make a request harder to follow.
• Avoid replacing one readable expression with several classes unless that organisation solves an actual problem.
• The design goal is understandable responsibility boundaries, not the maximum number of objects.

2.6 Drawing the Design

UML class diagrams to read, write and check

What a Class Diagram Is

• A class diagram is a selective explanation of a design.
• It answers one question for one audience: for example, “which objects take part in a reservation request, and how are they related?”
• It is not a copy of the source code. A diagram showing every field and method answers no question well.
• Class diagrams are the only UML notation used in this chapter.

Three Skills in This Section

1. Read a diagram.
2. Draw one from a written description.
3. Check one against code.

• Hand-drawn diagrams use the same symbols as the ones in this book.
• The book’s diagrams are written as text (Mermaid) so they can be kept beside the code. Appendix A shows the syntax.

Figure 2.1: The Starter’s Collaborators

Reading the Boxes

• Each box is a class with up to three compartments:
  • top: the class name,
  • middle: the attributes (data the class keeps),
  • bottom: the operations (methods other code can call).
• A label in double angle brackets above the name, such as <<interface>>, says what kind of class it is.
• + marks a public member and - a private one.

A Box and the Java It Describes

// Excerpt from LoanPeriod.java; method bodies omitted.
public final class LoanPeriod {
    private final LocalDate start;
    private final LocalDate endExclusive;

    public LoanPeriod(LocalDate start, LocalDate endExclusive) { ... }
    public LocalDate start() { ... }
    public LocalDate endExclusive() { ... }
    public boolean overlaps(LoanPeriod other) { ... }
}

Mapping Box Parts to Source

• Type comes before the name, as in Java. The return type comes after the parameter list.

What a Box Leaves Out

• The constructor and the accessors start() and endExclusive() exist in the code but not in the box.
• The explanation does not need them.
• You can trust a diagram for what it shows.
• You cannot assume that what it omits does not exist.

Attribute or Line, Not Both

• A field whose type is a plain value (String, int, LocalDate) is normally an attribute.
• A field whose type is another class of your design is normally a line to that class’s box.
• Do not show it both ways. A -LoanPeriod period attribute beside a line to LoanPeriod says one thing twice.

Reading Multiplicity

• The number at each end of a line is a multiplicity: how many objects take part.
• Stand at one class and read the number at the far end.
• That is how many objects of the far class one object of your class is linked to.

Reading One Line in Both Directions

ReservationCoordinator "1" --> "0..*" Reservation : stores

• From the coordinator: “each coordinator stores zero or more reservations.”
• From a reservation: “each reservation is stored by exactly one coordinator.”
• The arrowhead shows which object holds the reference.

Try It 1: The Other Two Lines

• Write one sentence for each of the other two lines in Figure 2.1, reading from both ends.
• For each number, find where the Java code enforces it and where the model merely assumes it.
• A strong answer separates “enforced by the code” from “true of how the code happens to be used”.

Try It 1: Answers (1 of 2)

Try It 1: Answers (2 of 2)

• Only assumed:
  • that a rules object is never shared,
  • that a reservation is held by only one coordinator (the constructor is public; snapshots hold the same objects),
  • the 0..* on periods (nothing prevents sharing, though each reservation currently gets its own).

The Relationships You Need to Read and Draw

Relationships: When to Use Each (1 of 2)

Relationships: When to Use Each (2 of 2)

Figure 2.2: A Notation Sampler

Reading the Sampler

• A pack owns its pages: a page has no meaning without its pack (composition).
• A pack only collects articles, which exist independently and can appear in many packs (aggregation).
• Articles and authors: a plain association, no arrowheads, because the description does not say who holds the reference.
• This is a notation sampler for a course-pack printing service. It is not part of the reservation project.

Reading the Sampler, Continued

• A research article is a kind of article (inheritance).
• A pack uses a printer only while printing (dependency).
• PdfPrinter implements the Printer interface (realisation).

Choosing a Relationship by Meaning

Choose by what it means, not how it looks. For each pair of classes, ask in order:

1. Does one class implement a contract that other classes rely on? Realisation.
2. Is A a kind of B, so a client of B could be handed an A without noticing? Inheritance (Chapter 5 tests this with the Liskov Substitution Principle).
3. Does A keep a lasting reference to B in a field? If not, and A only uses B as a parameter, local variable or short-lived object: dependency.

Choosing a Relationship, Continued

4. If A keeps the reference, does B belong to A so completely that it has no meaning without A and is discarded with it? Composition.
5. Does A group Bs that exist independently and could be shared or removed? Aggregation, but only if you can say what the grouping adds. Otherwise a plain association.

Aggregation and Composition Are Claims

• Aggregation is often indistinguishable from association in code.
• Composition describes a lifetime the Java types do not enforce.
• Both are claims about meaning.
• Figure 2.1 uses plain associations: periods can be shared by reference, and the code enforces no lifetime.
• Do not confuse “composition” as a programming idea (building from collaborators) with the filled diamond, a stronger ownership claim.

From Code to Diagram (1 of 2)

From Code to Diagram (2 of 2)

• Caution 1: the Java type does not settle the meaning. A List<Reservation> might be an association or a composition. Only the design decides.
• Caution 2: a field that can be null is 0..1, not 1.

A Worked Example: From Scenario to Diagram

The workshop keeps tools in numbered lockers.

• A locker holds at most one tool, and a tool sits in at most one locker.
• A technician looks after any number of lockers; each locker has exactly one technician at a time, and can be reassigned.
• Every inspection of a locker is logged as an entry with a date and a note; an entry is meaningless without its locker.
• Reports are printed as plain text now; other formats are expected later.

Steps 1 and 2: Nouns, Then Classes

• Step 1: find the nouns. Workshop, tools, lockers, technician, inspection, entry, date, note, report, plain text, formats.
• Step 2: decide which become classes. Keep a noun as a class when it has data or rules the description needs.
• The table on the next slides records each decision and its reason.

Step 2: Candidates and Decisions (1 of 2)

Step 2: Candidates and Decisions (2 of 2)

Step 3: Attributes and Operations

• Separate what the description states from what you assume.
• Stated: a locker’s number and report; an entry’s date and note.
• Assumptions, which you should label as assumptions:
  • a technician’s name and a tool’s name as identifying attributes,
  • a single print operation on the printer, one reasonable way to give the report a format-independent contract.
• A different, justified choice is acceptable.

Step 4: Choose a Relationship for Each Pair

Step 5: Write Each Multiplicity as a Sentence

• Each locker is looked after by exactly one technician: 1 at the Technician end.
• A technician looks after any number of lockers: 0..* at the Locker end.
• A locker holds at most one tool and a tool sits in at most one locker: 0..1 at both ends.
• A locker has any number of entries; an entry belongs to exactly one locker.

Step 6: Read It Aloud and Delete

• Read every line in both directions against the description.
• Remove anything the description does not say.
• Then compare with the model on the next slide: ask why each line differs, not whether it matches.

Figure 2.3: The Resulting Model

Reading Figure 2.3

• The two plain associations have no arrowheads: the description does not say which object holds the reference.
• A model should record what the description says and no more.
• Other answers are defensible: Tool only as an attribute, or a Workshop class if the task were scheduling.

Checking a Diagram Against the Code

A diagram that disagrees with its code is worse than no diagram, because readers trust it.

• For every box, find the class. For every attribute, find the field with that name and type.
• For every line, find the field, parameter or extends/implements clause that creates it. If you cannot, remove the line or fix the code.

Checking Multiplicities and Omissions

• For every multiplicity, find where the code enforces it: a constructor check, a final field, a collection type. If nothing does, mark it as an assumption.
• List what the diagram leaves out, and decide whether each omission is deliberate.

Try It 2: What Figure 2.1 Leaves Out

• Find two details present in the Java but absent from Figure 2.1.
• Say why leaving each out is acceptable.
• Examples of acceptable answers: the constructors and their validation; the accessors id(), borrowerId(), itemId(); the period field (the association line already says it); the private reservations and rules fields; the order of the checks and the exceptions thrown.

What the Diagram Cannot Tell You

• It omits standard library classes and some accessors.
• It does not establish the order of operations, display every validation, or prove overlapping bookings are rejected.
• Read the method body and the period convention for those questions.
• After extracting a private formatting method, the relationships in Figure 2.1 are unchanged: useful evidence about the scale of the edit.

Spot the Errors: Figure 2.4

Try It 3

• Another student’s first attempt at the workshop model (Figure 2.4) contains at least five mistakes.
• List every mistake you can find.
• For each, say why it is wrong using the description.
• Say what the correct notation is.
• Then redraw the diagram.

Try It 3: Answers (1 of 2)

Try It 3: Answers (2 of 2)

• Mistakes 2 and 3 sit on the same line. Count them as two ideas if both are explained.

Common Drawing Mistakes (1 of 3)

Common Drawing Mistakes (2 of 3)

Common Drawing Mistakes (3 of 3)

2.7 Making a Change Someone Else Can Review

A change a team can inspect

Version Control Is Not Evidence of Good Design

• A codebase becomes a shared piece of work when the team can inspect its changes, reproduce its behaviour and explain its decisions.
• Version control supports that work.
• A commit alone is not evidence of a good design.

Working Files, Staging, Commits

Why the Staging Area Matters

• You edit working files, select content for the next commit, and record that selected state.
• The staging area matters when unrelated edits are present.
• The next commit should contain the change you intend to explain.

Branches and Pull Requests

• A branch names a line of development. For the lab, use a short-lived branch containing the confirmation extraction.
• A pull request (or merge request) is a hosting-platform review proposal. It is not the same as a local commit.
• A local peer review can still serve the learning objective when no hosting account is available.

Trunk-Based or Feature Branches?

• Trunk-based development: integrate small changes frequently into a main line, sometimes through very short-lived branches.
• Feature-branch workflow: group a feature’s work on a branch before integration.
• The approaches overlap: a short reviewed branch can be part of frequent integration.
• For this course: keep changes small, reviewable and integrated regularly.

A Reviewable Change: The Sequence

1. Begin with the supplied starting files and a recorded baseline.
2. Confirm that the checks pass before editing.
3. Create a branch.
4. Perform only the extraction.
5. Rerun the checks and inspect the diff.

• The companion contains the complete setup commands.

The Inspection Commands

git status
git diff
git diff --staged

• git status reports file state.
• git diff normally shows tracked changes not yet staged.
• git diff --staged shows staged changes against the current commit.

Reading the Output Correctly

• An empty git diff after staging does not mean there is nothing to commit.
• Untracked files also need attention in git status.
• Keep compiled class files out of commits: the companion’s .gitignore handles generated files.
• Appendix B collects the Git commands and the pull-request workflow (B.8).

Commit Messages

• A useful message: Extract reservation confirmation formatting.
• Many teams adopt a written convention. Conventional Commits puts a type before a short description: refactor: extract reservation confirmation formatting
• Use whichever convention your team agrees, and apply it consistently.

A Useful Review Description

• State the problem, the limited change, and the checks performed.
• Example: “The request method interleaves storage and confirmation text. This change moves the text assembly into a private helper. The existing messages and stored records remain unchanged in the supplied checks.”
• Add limits: persistence, concurrent booking, lifecycle operations and message delivery remain outside this version.

What the Reviewer Inspects

• Inspect the diff.
• Verify that the helper adds no state changes.
• Check that the record is still added before confirmation is returned.
• “Looks cleaner” is weaker than an explanation of what was inspected and why it matters.

A Diff With Only Additions Still Moves Behaviour

• In Git, the extraction appears as four added lines and no removed lines.
• The existing return "Confirmed: "... expression is kept and now sits inside the new method.
• The reviewer must read where the retained lines ended up.

One Change at a Time

• Do not combine this refactoring with changed limits, renamed identifiers or new message punctuation.
• Each may be legitimate work.
• Combining them makes it harder to determine why a result changed.

2.8 Checking an AI’s Explanation of the Coordinator

Classifying claims against the code

Ground Rules for the Activity (1 of 2)

Ground Rules for the Activity (2 of 2)

• Chapter 15 collects the recurring AI workflows. This activity is self-contained.

The Ready-Made Example (1 of 2)

An ready-made example written by the author imitating a plausible AI explanation. Not a captured response from a real model.

The coordinator validates identifiers, counts the borrower’s stored reservations and checks the numeric rule. It tests availability using existing reservations for the same item. On success, it adds a reservation before returning a confirmation.

The Ready-Made Example (2 of 2)

It sends that confirmation by email and persists the reservation to a database. Because the list field is final, callers receive a deeply immutable copy and booking is safe under concurrent requests.

• Classify each claim as supported, contradicted or not established.
• Cite the relevant operation, or the absence of one.

Claim Classification (1 of 2)

Claim Classification (2 of 2)

A Corrected Four-Sentence Explanation

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.

A Corrected Four-Sentence Explanation, Continued

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.

Optional Live Assistant

Trace this coordinator and its supplied collaborators. Identify inputs, returned values and state changes on success and rejection. State what is established about storage, notifications and concurrency. Separate facts visible in the code from assumptions. Do not change the code.

• Record one accepted claim and one rejected or qualified claim with evidence.
• A second model’s agreement is not a substitute for tracing the operations.

2.9 Mistakes That Look Like Good Design

Eight misconceptions, eight better questions

Mistakes 1 and 2

• “Private fields mean the object is safely encapsulated.”
  • A returned mutable list can still expose a modification path.
  • Better question: what can callers change through the references they receive?
• “A final field makes the referenced object immutable.”
  • The coordinator can still add to its final list.
  • Better question: is the reference fixed, the object immutable, or both?

Mistakes 3 and 4

• “Every noun should immediately become a class.”
  • Several concepts have no behaviour or state we need yet.
  • Better question: what responsibility would that class own now?
• “More interfaces automatically mean less harmful coupling.”
  • An interface can repeat an unstable contract without solving a caller’s problem.
  • Better question: which dependency would this interface improve?

Mistakes 5 and 6

• “Calling another class means inheriting from it.”
  • The coordinator uses a policy; it is not a policy subtype.
  • Better question: is the relationship use, containment or substitution?
• “A filled diamond just means ‘has a’.”
  • Composition claims the part cannot outlive its owner; LoanPeriod objects can be shared by reference.
  • Better question: does the code enforce this lifetime, and would the domain agree?

Mistakes 7 and 8

• “A formatting refactoring fixes the whole design.”
  • The helper leaves storage and other responsibilities in the coordinator.
  • Better question: which improvement did this edit actually make?
• “Green checks prove the application is production-ready.”
  • The starter omits lifecycle, persistence, catalogue validation and concurrency.
  • Better question: which claims have we tested, under which assumptions?

2.10 Try It Yourself

Improve the design, with evidence

Inputs and Starting Point

• Parts A to C use the book’s project; Part D concerns your team’s project.
• Use the companion’s common source files and the starting ReservationCoordinator.java.
• Save all six Java files in one directory; compile and run them using the companion’s instructions.
• The check runner should report 34 passing checks before you begin.
• Read the checks as provided evidence. You need not master the runner yet.

Compile and Run

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

• Recompile after every source change. Otherwise the JVM may run old class files and give misleading evidence.

Expected Output

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

All 34 chapter checks passed.

Part A: Understand the Request

Trace the three requests in Chapter02Demo.

• Record the returned message and the number of stored records after each call.
• Identify the first condition that rejects the overlapping request.
• Explain why the adjacent request is accepted.
• Explain why the rejected request does not consume a reservation identifier.

Part A: The Trace

• Identifiers derive from the number of stored records, so a rejection consumes none. That may not suit deletion, persistence or several coordinators.

Part A: Diagram and Invariants

• Draw a small class diagram of the starter without copying Figure 2.1.
  • Use the “From code to diagram” table, then run the four checking steps on your own drawing.
• Annotate one local invariant and one condition that needs information from multiple objects.
• A local invariant: a period’s end follows its start (the LoanPeriod constructor).
• A multi-object condition: confirmed reservations for the same item do not overlap (the coordinator checks it).

Part A: A Separate Modelling Exercise

Equipment kits. It does not extend the project.

• A kit has a name and holds one or more equipment items.
• Removing a kit does not delete its items; an item belongs to at most one kit.
• Each item keeps any number of maintenance records; a record belongs to exactly one item and has no meaning without it.
• A kit summary is produced through an exporter: CSV now, other formats later.

Part A: What to Draw

• A class diagram with the classes, their key attributes and multiplicities.
• Include at least one aggregation, one composition, one interface realisation and one dependency.
• State one assumption you had to make.
• For each relationship, write the Section 2.6 question that decided it.
• Then read every line aloud in both directions against the scenario.

One Suitable Model: Equipment Kits

What a Strong Kit Answer Shows

Common Kit Errors

• Interface realisation drawn as inheritance with a solid line.
• The diamond reversed.
• 1..* at the wrong end.
• The kit depending directly on CsvExporter.
• An assumption can be anything stated and consistent: for example, that an item with no kit is allowed.
• Do not credit extra classes for their own sake.

Part B: Diagnose the Design

• Write a short responsibility inventory for the coordinator.
• Identify two distinct reasons it might change.
• Explain one cohesive collaborator and one dependency that deserves attention.
• Avoid judging quality by method length alone.

Part B: A Model Answer

• The coordinator validates inputs, counts records, invokes policy, checks availability, allocates an identifier, stores a record and formats a message.
• Two reasons to change: a new storage mechanism and changed confirmation wording.
• LoanPeriod is cohesive: construction rules and overlap concern one concept.
• The coordinator depends on both reservation representation and message wording.

Part C: Make the Change

• On a short-lived branch, move only the confirmation-string expression into a private confirmationFor(Reservation reservation) method.
• Keep unchanged: output, validation order, identifier allocation, storage effects.
• Do not add a new interface or change public method signatures.
• Run the checks again, inspect the diff, ask a peer to review.

Part C: The Completed Method

        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() + ").";
    }

Part C: Git Baseline Commands

git init -b main
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

• .gitignore contains out/ and *.class.

Part C: Commit the Extraction

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

• Produce one focused commit after addressing relevant feedback.
• In independent study, perform a self-review and label it honestly as such.

Part C: A Review Record

• Problem: the request method contains message formatting alongside the request workflow.
• Change: move only the confirmation-string construction into confirmationFor, keeping record creation and storage order.
• Evidence: identical demonstration output; the same 34 checks pass; the diff changes only internal organisation.
• Limits: persistence, concurrent booking, lifecycle operations and message delivery remain outside this version.

Part C: What the Review Record Needs

• The change or commit identifier.
• The reviewer.
• The evidence inspected.
• The findings and the response.
• Creating a commit does not create a hosted pull request or establish that anyone reviewed it.
• Record your own observed results. Do not copy a claim you did not verify.

Part D: Organise Collaboration

• Form teams of three or four as directed by the module leader.
• Confirm which provided starter domain your assessed project uses. If it is not equipment lending, use each chapter’s transfer note.
• Set up an issue board with columns that match how your team will work.
• Add three cards with concrete completion conditions.

Part D: Cards and Branch Policy

• A good card: “extract confirmation formatting with unchanged output and checks”. Not: “improve OO”.
• Agree a branch policy:
  • very short-lived branches integrated into a main line often, or
  • one feature branch per story.
• Write down your reason. The reason matters more than the choice.
• Agree who prepares the next demonstration and who reviews the next change. Rotate roles.

Evidence to Retain

• The annotated diagram and the scenario model.
• The responsibility diagnosis.
• Before-and-after check results.
• The commit identifier and the review note.
• Your AI claim analysis.
• Your team’s issue board and branch-policy note.
• A short limitation statement: which risks remain after the extraction?

The Activity Is Complete When

• The diagram matches the code.
• The extraction preserves the checked behaviour.
• Your review explains both the improvement and its limits.
• You can explain the returned list’s protection without claiming all copies are deep copies.

Optional Investigation: Break It on Purpose

• In a temporary copy, replace List.copyOf(reservations) with reservations.
• Predict the effect of an external clear() call, then run the checks.
• Result: snapshot::clear succeeds; the runner reports that snapshot unmodifiable expected an UnsupportedOperationException.
• Restore the original before continuing. This is a fault demonstration, not an improvement.

A Second Fault: Omit the Storage

• In another disposable copy, remove reservations.add(reservation);.
• The first confirmation can still look correct.
• The checks fail with one success stored.
• A demonstration that inspects only printed text would miss the changed state.

2.11 Questions to Think with

Concept, diagnosis, transfer

Concept Questions

1. Distinguish a Java object reference from a reservation’s domain identifier. Why are equal identifier strings not sufficient to make two Reservation instances equal through equals in this starter?
2. Explain one local invariant and one system-level condition in the project. Why do they need different enforcement points?
3. Explain cohesion and coupling using one likely change to the coordinator. Why is reducing the total number of dependencies not a sufficient design goal?
4. Compare composition and inheritance for a reservation and its loan period. What would inheritance incorrectly suggest?

Diagnosis Questions

5. A developer adds a getter returning the private mutable list and claims the coordinator is still encapsulated because the field is private. Give a concrete counterexample and explain the limits of the proposed correction using List.copyOf.
6. A refactoring returns the same confirmation text but omits reservations.add(reservation). The developer demonstrates the printed text and declares success. Explain the behavioural change and identify evidence that would expose it.

Guidance: Questions 1 and 2

1. A reference identifies a Java object instance; id represents domain identity in the teaching model. Two separately constructed reservations can hold the same identifier text yet remain distinct under the inherited equals. Identifier-based equality needs an explicit contract and implementation.
2. LoanPeriod protects its own date relationship. Conflict prevention needs other reservations and the requested item, so it belongs at a boundary with that information.

Guidance: Questions 3 and 4

3. Changed message wording affects presentation but currently requires editing the coordinator. A private helper makes the purpose easier to locate; it does not remove the class-level dependency. Zero dependencies would prevent collaboration; extra classes can add indirection without solving a problem.
4. A reservation has a period. It is not a period subtype. Inheriting would conflate reservation identity and borrower/item details with an interval, and suggest inappropriate substitutability. LoanPeriod is also final.

Guidance: Questions 5 and 6

5. Returning the mutable internal list allows clear or add outside the coordinator’s validation. List.copyOf blocks structural mutation and isolates later additions, but does not deep-copy mutable elements. This starter’s elements are separately immutable.
6. A success string is returned for a reservation the coordinator does not retain. The next request can wrongly find no conflict. The one success stored check exposes the fault immediately.

Transfer Challenge: Room Booking

A university room-booking coordinator stores bookings, checks room conflicts and constructs confirmation text. Its users now request a wording change only.

• Propose a responsibility diagram with at most four domain or application classes.
• State a period convention.
• Identify the state that callers must not modify directly.
• Describe one small behaviour-preserving improvement and two before-and-after observations to accept it.
• Include a brief review description and one remaining limitation.

Transfer Challenge: Guidance

• One reasonable model: RoomBookingCoordinator, RoomBooking, BookingPeriod, BookingRules.
• State an explicit convention, for example start-inclusive, end-exclusive periods in local building time.
• Extract first, change the wording second: preserve the old output while extracting; then change the text as a separate behaviour change with updated expectations.
• Two observations: identical confirmation text and identical stored records; a conflicting request still adds nothing.
• A limitation: one process’s list cannot coordinate several application instances.

What to Take Away, and What Comes Next

What to carry forward

Summary: Objects as Design Units

• Objects become useful design units when their responsibilities and permitted interactions are clear.
• Constructors and controlled operations protect invariants.
• Immutable values and careful collection access stop callers bypassing intended boundaries.

Summary: Cohesion, Coupling and the Limited Claim

• Cohesion and coupling help us discuss the consequences of change.
• The formatting extraction makes one operation easier to follow without resolving every responsibility the coordinator holds.
• Explaining that limited improvement is part of sound design reasoning.

Summary: Evidence Should Agree

• Diagrams, checks, diffs and review notes describe different aspects of the same codebase.
• They should agree with the implementation.
• An AI explanation is another candidate description to check against that evidence.

Next: Chapter 3

• Chapter 3: Agile Development and the Nature of Change.
• Turn project needs into an ordered backlog.
• Write useful stories and acceptance criteria.
• Examine how a team plans and learns through feedback.

Sources and Further Reading

1. Dev.java: Classes and Objects; Inheritance.
2. Oracle: Java SE 17 API for LocalDate, Objects and List.
3. Chacon and Straub: Pro Git: Recording Changes; Branching Workflows.
4. Git documentation: git diff and git switch.
5. Conventional Commits 1.0.0.
6. Martin, Robert C.: Agile Software Development: Principles, Patterns, and Practices, 2002.

• Full references and links are in the chapter text.

3 - Chapter 3: Agile Development and the Nature of Change

Chapter 3: Agile Development and the Nature of Change

SE506: Object Oriented Development and Agile Practices

Dr. Polla Abdulhamid Fattah
Department of Computer Science & Artificial Intelligence
University of Kurdistan Hewlêr (UKH)

Chapter Roadmap (1 of 3)

• 3.1 What do we not know yet? Uncertainty and feedback
  • Four kinds of uncertainty, and the evidence that reduces each.
• 3.2 What the Agile values mean for real project decisions
  • Preferences, not prohibitions, applied to project decisions.
• 3.3 Iteration or increment? Two kinds of progress
  • Related but different, and neither is a public release.
• 3.4 Scrum: who is accountable, what happens when, what it produces
  • The November 2020 Scrum Guide, and what a classroom adapts.

Chapter Roadmap (2 of 3)

• 3.5 Kanban: making the workflow visible
  • A five-column board, a combined WIP limit, a provisional expectation.
• 3.6 From “manage equipment” to a story: epics, user stories and INVEST
  • From “manage equipment” to a small, testable story and an ordered backlog.
• 3.7 Is the story finished? Acceptance criteria and Definition of Done
  • Behaviour of one item versus the standard for every increment.
• 3.8 Estimating without pretending to know: relative estimation
  • Story points as a conversation, not a guarantee.

Chapter Roadmap (3 of 3)

• 3.9 Challenging a story with AI without letting it invent policy
  • Seven suggestions: accept, reject for this story, or clarify.
• 3.10 Try it yourself: build a draft backlog
  • Parts A to C on your team’s project.
• 3.11 Habits that sound agile but are not and 3.12 Questions to think with
• What to take away, and what comes next
  • Into Chapter 4: from requirements to an iteration.

Learning Outcomes (1 of 2)

After completing this chapter, you should be able to:

1. Distinguish iterative development from incremental delivery.
2. Explain Agile values through concrete project decisions.
3. Compare Scrum’s framework with Kanban’s attention to workflow and flow.

Learning Outcomes (2 of 2)

4. Develop small user stories and evaluate them using INVEST.
5. Write acceptance criteria and distinguish them from a Definition of Done.
6. Discuss relative estimates and uncertainty without treating estimates as guarantees.

How to Use This Chapter

• Core reading: Sections 3.1 to 3.9.
• What you must do: Parts A to C of Section 3.10, on your team’s project.
  • The equipment-lending backlog in this chapter is the worked model, not your evidence.
  • Evidence needs no code or tools beyond a text editor or a board.
• If you want more: the plain-Java acceptance check at the end of 3.10, then the questions and the transfer challenge.

Readings and Scope

• Readings: the Agile practices and planning chapters of Martin, the Scrum Guide, and selected chapters of Rubin.
• The chapter assumes Chapter 2’s objects, date convention and basic review workflow.
• It needs no project-management platform and no new Java framework.
• The companion holds worked backlog items, board policies, exercise solutions and an optional executable bridge from acceptance examples to the existing Java.
• The running application stays at Chapter 2’s completed version. This chapter plans future work; it does not claim features already exist.

Opening Scenario: The Demonstration

• The team demonstrates the reservation coordinator from Chapter 2.
  • A student request succeeds.
  • A conflicting request is rejected.
  • A booking can begin on the exclusive end date of another.
• The program behaves as its developers expected.

The Officer’s Question

Can I check whether a camera is available before I create a reservation?

• The team can inspect the stored list, but there is no dedicated availability query.
• The demonstration revealed a distinction: checking a rule during a request versus supporting the officer’s actual workflow.

More Requests Follow

• The next conversation raises:
  • cancellation,
  • displaying one borrower’s reservations,
  • rejecting an equipment identifier that does not exist.
• The team cannot implement every suggestion immediately.
• It needs a way to clarify requests, compare their value, expose uncertainty and decide what useful work to finish next.

What This Chapter Produces

• An ordered backlog.
• Testable stories.
• Shared completion conditions.
• A visible workflow.
• All developed on the same small codebase from Chapter 2.

3.1 What Do We Not Know Yet?

Uncertainty and feedback

Uncertainty Takes Several Forms

• We may not understand:
  • what a user needs,
  • how a rule should behave,
  • whether an integration is feasible,
  • how much work a change will require.
• Treating all of these as “requirements problems” hides useful distinctions.

Four Uncertainties and Their Next Actions

Different Questions Need Different Evidence

• A larger estimate will not determine the cancellation policy.
• More conversation will not prove that an unavailable service can be accessed.
• Naming the uncertainty helps the team choose an action that can actually reduce it.

Feedback Also Varies

• A user can expose a missing workflow.
• A compiler can identify an invalid program.
• A test can show that an observed result differs from an expectation.
• A reviewer can identify a dependency that makes the next change harder.
• None of these observers has complete authority over every question.

A Discovery Is Not Automatically a Defect

• The implementation currently allows adjacent bookings. That matches our rule invented for this book.
• If the officer asks for an inspection day between loans, the team has found a possible policy change, not a defect in the original comparison.
• Record: who proposed it, why it matters, and which examples would differ if it were adopted.

What Short Feedback Cycles Do

• They make discoveries while there is still a manageable amount of work to revise.
• They do not make change free: tests, documentation and stored data may also need to change.
• The team should expose those consequences rather than accept every request without discussion.

3.2 What the Agile Values Mean for Real Project Decisions

Preferences, not prohibitions

The Manifesto, Paraphrased

• The Agile Manifesto gives greater emphasis to:
  • human collaboration,
  • usable software,
  • ongoing customer involvement,
  • adaptation,
• than to relying primarily on tools, exhaustive documents, contractual positions or a fixed plan.
• It explicitly retains value in those latter activities.

Applying the Values to Our Project

Principles: Delivery and Technical Quality

• The accompanying principles connect regular delivery with technical quality, a sustainable pace and reflection on team effectiveness.
• In this course the connection matters because poorly understood code makes a small request expensive.
• The design and testing work from earlier chapters supports the team’s ability to respond.

“Check Availability” Is Two Different Requests

• Option 1: merely inspect the coordinator’s current in-memory records. A small teaching increment.
• Option 2: include an authoritative inventory and maintenance schedule. Substantially more work.
• Calling both “check availability” does not make them equivalent.
• Clarify which one is meant.

Agile Still Needs Commitments

• Agile work still needs commitments, boundaries and evidence.
• What changes is the expectation that every detail can be settled correctly at the beginning.
• We maintain an explicit record of:
  • what we know,
  • what we intend to deliver,
  • what still needs a decision.

3.3 Iteration or Increment?

Two kinds of progress

Definitions

• An iteration is a repeated cycle of work and feedback.
• An increment adds integrated, usable capability.
• The terms describe related but different aspects of development.

One Example of Each

• The team revises its reservation messages after a demonstration: it has iterated on the implementation.
• It then adds an availability enquiry that works with the existing records and can be used through the agreed interface: it has added an increment of capability.

Effort Is Not an Increment

• An isolated database table or a collection of unfinished screens may represent effort without a usable increment.
• Technical tasks can be necessary.
• The team should explain how they contribute to a result someone can inspect and use.

A Small Route Through the Project

1. Make the current reservation flow reproducible.
2. Add an enquiry that does not change records.
3. Support a borrower’s list of active reservations.
4. Cancellation follows once its policy and state transitions are understood.

• A proposed learning route, not a new assessment schedule.

Each Addition Must Still Work With What Came Before

• If the enquiry answers correctly but creates a reservation as a side effect, it has not delivered the intended capability.
• If cancellation removes an unrelated record, a successful cancellation message is insufficient evidence.
• Check the whole relevant state, not only the message.

An Increment Is Not a Public Release

• A bounded teaching application can be demonstrated to its intended reviewers while remaining unsuitable for institutional deployment.
• Its scope and limitations must be explicit.
• Releasing to real users involves further considerations beyond completing a classroom exercise.
• Chapter 4 turns the selected work into an iteration plan.

3.4 Scrum

Who is accountable, what happens when, what it produces

Scrum Is a Framework With Defined Elements

• The November 2020 Scrum Guide is the formal reference used here.
• Basic structure: accountabilities, events, artefacts.
• Terminology should clarify responsibilities and decisions.
• User-story templates and story points are optional practices, not required Scrum elements.

Accountabilities

The Sprint and Its Events (1 of 2)

The Sprint and Its Events (2 of 2)

The Sprint Contains All the Events

Artefacts and Their Commitments

The Sprint Backlog

• The Sprint Backlog includes the goal, the selected work and the delivery plan.
• Each artefact is tied to a commitment that makes its purpose explicit.
• The Definition of Done is the commitment for the Increment.

A Product Goal

Enable the equipment office to manage a small set of student reservations with visible rules and reliable records.

• It expresses a useful future state.
• It does not specify every screen or method.

A Sprint Goal

• A possible Sprint Goal is narrower: “Let the officer check availability without changing reservations.”
• It tells the team why its selected work belongs together.
• Compare: “Finish US-02, update the README and edit three classes” lists work but does not explain the outcome that connects it.

A Daily Scrum Contribution

• A developer might say: “The enquiry works, but its result depends on a date convention we have not documented. I will pair with the reviewer to resolve that before adding another feature.”
• This focuses on the team’s progress.
• The Scrum Guide defines the Daily Scrum as a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt their plan.
• It is not a status report to a supervisor.

A Sprint Review

• The equipment officer tries the enquiry and asks whether a damaged item should ever appear available.
• That discussion concerns the product and possible next work.
• The Scrum Guide describes the Sprint Review as a working session, not limited to a presentation.

A Sprint Retrospective

• The team notices that reviews consistently arrived too late.
• It agrees to request review when a small behaviour first works, then inspects whether that agreement helps.
• The retrospective concerns increasing quality and effectiveness, including how the team collaborated and verified work.

Classroom Adaptations Must Be Named

• The module leader may provide stakeholder answers; teams may rotate facilitation; reviews may happen within teaching sessions.
• These are course arrangements. They do not redefine Scrum’s accountabilities or turn every classroom meeting into a formal Scrum event.
• An academic submission date is not automatically a Sprint boundary.

“Sprint 0”

• The descriptor’s later “Sprint 0” label refers to kickoff work.
• Treat it as a local preparation convention, not another formal Scrum event.
• Keep the distinction visible when you write reports about the process your team actually followed.

3.5 Kanban

Making the workflow visible

What Kanban Focuses On

• Kanban focuses on the flow of value through work.
• The May 2025 Kanban Guide describes:
  • defining and visualising a workflow,
  • managing work within it,
  • improving that workflow.

What a Workflow Definition Includes

• Work items.
• Start and finish points.
• States.
• Work-in-progress controls.
• Movement policies.
• A service-level expectation: elapsed time combined with a probability. Historical evidence should inform it when available.

Our Five Columns

• These columns are our example, not mandatory names.

Start, Finish and the Combined Limit

• Start point: entry into Building.
• Finish point: entry into Done.
• Limit the combined number of items in Building and Review to two.
• Blocked work stays within that count. An uncounted “Blocked” column would hide unfinished work rather than finish it.

A Hypothetical Snapshot

The Limit Is Reached: What Now?

• One item is in Building and another is waiting in Review.
• Before starting a third, investigate what would help an existing item finish:
  • review together,
  • resolve a question,
  • make a smaller change.
• A limit is useful only when it affects decisions.

A Board Alone Is Incomplete

• A team also needs workflow policies, active management and evidence for improvement.
• For practice: provisionally expect 85% of small items to finish within five working days after starting.
• Without historical data that is an explicitly unvalidated hypothesis, not a measured promise.
• Chapter 12 develops flow measures and forecasting. We do not derive a delivery guarantee from an invented example.

Comparing Scrum and Kanban (1 of 2)

Comparing Scrum and Kanban (2 of 2)

• Not: “Scrum has meetings; Kanban has none”. Not: “Scrum is planned; Kanban is unplanned.”
• The chosen approach should help the team make decisions, not merely supply labels.

3.6 From “Manage Equipment” to a Story

Epics, user stories and INVEST

“Manage Equipment” Is Too Broad

• It may refer to stock records, borrowing, maintenance, losses, reporting or purchasing.
• To guide the next implementation we must identify a particular actor, outcome and reason.

Epic and User Story

• An epic is a label for a large area of work that needs further division.
  • Here: “Manage student equipment reservations”.
• A user story expresses a smaller user-centred need.

As an equipment officer, I want to record an eligible, non-conflicting reservation so that the selected item is allocated for the borrower’s requested period.

A Story Opens a Discussion

• The sentence does not define eligibility, conflicts, dates or failure behaviour by itself.
• Ron Jeffries connects a short written reminder with conversation and confirmation.
• We keep a card, record the relevant decisions and attach observable examples.

Stories and Implementation Tasks

• “Create a HashMap” names an implementation task. It does not explain the outcome a user needs.
• A story can lead to tasks (data structures, checks, interface work), but they should remain connected to the outcome.
• Not all backlog work needs a fictional user-story sentence.

Technical Enablers

• A build-check task can be labelled a technical enabler, justified by the delivery problem it addresses.
• Our convention: US- for stories and EN- for enablers.
• These prefixes are local identifiers, not Agile rules.

INVEST as Questions (1 of 2)

INVEST as Questions (2 of 2)

• Bill Wake introduced INVEST to prompt useful qualities in stories.

INVEST Is a Reasoning Aid

• It is not a six-point score that certifies a story.
• Real dependencies should be recorded. “Independent” should not make us pretend cancellation needs no existing reservation.
• “Negotiable” should not mean ignoring an agreed safety or domain rule.

A Small Version of the Availability Story

• Inspect the coordinator’s current records for one known item and one period, leaving records unchanged.
• Adding live inventory, maintenance calendars, permissions and email delivery at the same time would make it harder to identify what is being delivered.

A Backlog Is Ordered Work

• The Scrum Guide describes the Product Backlog as an emergent, ordered list.
• Refinement is the ongoing work of breaking items into smaller, more precise ones.
• Ordering and refinement together make upcoming work understandable.
• We record current support as well as remaining work, because the team inherits code from Chapter 2.

The Beginning of a Draft Backlog

Not a Delivery Report

• This is the beginning of a draft backlog, not a report that three items have been delivered.
• Review inherited capability instead of pretending to implement it again.
• When a story’s conditions are met, retain the evidence in completed history rather than counting it again as new work.

3.7 Is the Story Finished?

Acceptance criteria and Definition of Done

Two Different Questions

• Acceptance criteria describe the behaviour expected for a particular item.
  • Specific enough that a second team can tell whether an implementation meets them.
• Definition of Done describes the shared quality conditions required for an increment.
  • Scrum makes that definition the commitment associated with the Increment.

US-01 Criteria: Conventions

• All counts are measured before adding the new reservation.
• All stored reservations are currently active.
• Dates use the exclusive-end convention from Chapter 2.
• The next slides list AC-01 to AC-05.

US-01 Acceptance Criteria

What the Criteria Do Not Establish

• They describe a controlled demonstration using non-blank, agreed sample identifiers and representable dates.
• They do not establish catalogue membership, authentication, persistence or concurrency safety.
• Those omissions must remain visible when judging what kind of product the story represents.

Turn AC-02 into an Example

Given CAM1 is reserved for B1 from 20 October to 22 October,
using a start-inclusive, end-exclusive period,
when B2 requests CAM1 from 21 October for one day,
then the request is rejected as unavailable,
and the original reservation remains the only stored record.

• The format separates context, action and observations.
• It is plain text here, not an executable framework.

Both Observations Matter

• The rejection, and
• the unchanged state.
• A program that prints the correct rejection but still adds a reservation has not met the criterion.
• This introduces traceability between an example and behaviour. It is not yet a complete TDD or BDD method.

A Working Definition of Done (1 of 2)

DoD version 0.1 for the controlled teaching increment:

1. Relevant acceptance examples have been checked, including important rejection paths.
2. The code compiles and runs using the documented commands in the agreed environment.
3. The change has been reviewed and acceptance-blocking findings resolved.

A Working Definition of Done (2 of 2)

4. The work is integrated with the team’s shared codebase and existing checks still pass.
5. Necessary usage notes, domain decisions and known limitations are current.
6. The increment can be reproduced and demonstrated within its explicitly stated scope.

• A proposed team agreement, not a university grading policy.

Do Not Pretend a Pipeline Exists

• The DoD uses checks available now. Automated CI gates can be added when the infrastructure is introduced.
• Do not claim a pipeline has passed before it exists.
• Do not weaken the agreed standard merely to move a card to Done.

Story Criteria and Shared Completion

• AC-03 belongs to the reservation story because it defines date behaviour.
• Reproducible setup belongs to the shared completion agreement.
• Passing a story’s examples while leaving an unreviewed, unintegrated change does not meet this DoD.
• Appendix C has blank forms, each with a worked example, for a story card (C.2), an acceptance example (C.3) and a Definition of Done (C.4).

“Ready” Has a Different Purpose

• “Ready” records whether a team considers an item sufficiently understood to start.
• Our Ready-column policy is a local agreement, not an additional formal Scrum artefact or event.
• It should help a conversation, not become a ritual that demands every detail months in advance.

Distinguishing the Three Conditions

From Criterion to Code: A Plain-Java Bridge

// AC-02: an overlapping request 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");

• The companion’s Chapter03AcceptanceExamples runs AC-01 to AC-05 against the completed Chapter 2 coordinator.

Running the Bridge

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

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

What the Bridge Shows

• Each labelled group corresponds to a criterion: setup, action, observations.
• AC-04 uses different item identifiers, so the fourth refusal comes from the borrower’s total count, not an item conflict.
• AC-05 stays below the count limit, so the duration rule is the reason for rejection.
• A passing run does not satisfy the Definition of Done by itself: review, integration and reproducibility still matter.

Do the Examples Detect Faults?

Why AC-03 Has Two Requests

• If AC-03 contained only a request starting at an existing end, the first overlap change would pass every Chapter 3 example.
• The extra request, one that ends exactly where an existing reservation begins, closes that gap.
• Chapter 2’s adjacency symmetric check also caught that change.
• Lesson: choose example sets to expose specific faults, not merely to be numerous.

3.8 Estimating Without Pretending to Know

Relative estimation

What an Estimate Is For

• An estimate helps a team discuss and forecast work.
• It is not a guarantee that a specific person will finish at a precise time.
• Before estimating, establish what is included: implementation alone, or also review, checking and documentation needed to meet Done?

Story Points as a Local Scale

• Story points are an optional local relative scale.
• A team might use 1, 2, 3, 5 and 8 to compare work considering effort, complexity and uncertainty.
• These numbers are not hours.
• The same number in two teams need not represent equivalent work.

Two Estimates That Disagree

• A familiar display adjustment is the reference item at two points.
• A small availability query may seem larger: a non-mutating operation, several date examples and a new interaction.
• One learner estimates three, another eight.
• Averaging them immediately would discard the most useful information: why they disagree.

Expose the Assumption

• The second learner may be assuming the query includes maintenance schedules.
• Once exposed, the team can narrow the story or record a separate requirement.
• If the uncertainty is an external catalogue with an unknown interface, a short investigation may be more useful than a larger number.

A Bounded Investigation

• Good: “Determine whether a read-only sample catalogue can be accessed and record the fields it provides.”
• Bad: an unlimited task called “research the system”.
• A bounded investigation has a question and an output, including the result “access not obtained”.
• Do not probe systems without authorisation.

Practising Estimation

• Estimate only clarified items and write the assumption behind each estimate.
• Leave an item unestimated when a material question remains.
• Different reasoned estimates are acceptable. Claiming certainty without evidence is not.

Estimates Are Not Productivity Measures

• Do not rank students by points completed.
• Do not convert points into individual productivity targets.
• Do not assume that doubling team size doubles delivery.
• Chapter 4 combines selected work with actual capacity; Chapter 12 examines measured progress and flow.

An Example of Estimates With Assumptions

• Invented numbers for discussion. No velocity or forecast is claimed.

3.9 Challenging a Story with AI Without Letting It Invent Policy

Without inventing policy

What AI Can and Cannot Do Here

• An AI assistant can suggest missing assumptions and candidate criteria.
• It has no authority to decide the equipment office’s rules.
• The exercise is to evaluate its proposals against the agreed context.
• Chapter 15 collects the recurring AI workflows. This activity is self-contained.

Ground Rules for the Activity (1 of 2)

Ground Rules for the Activity (2 of 2)

The Ready-Made Example (1 of 2)

An ready-made example written by the author, not a captured response from a real model.

1. A request for the same item and an identical period must be refused.
2. A request that begins exactly when an existing period ends must be refused.
3. Every confirmation must be emailed within thirty seconds.
4. A refused request must leave stored reservations unchanged.

The Ready-Made Example (2 of 2)

5. Specify how start dates that are already in the past are treated.
6. A deposit payment must be taken before any reservation can be confirmed.
7. Specify whether cancelled reservations count toward the borrower’s limit.

• Classify each suggestion with a reason.
• “Reject” can mean the proposal contradicts a rule or introduces unapproved scope. It need not mean the idea could never be useful.

Decision Log (1 of 2)

Decision Log (2 of 2)