Unit 18 · lesson

Checkpoint 6: Java Software Engineering Capstone

Submit the complete Java capstone dossier. This checkpoint evaluates the chain from requirement through validation, not just the amount of source code.

1. Problem and scope

Include:

  • user/audience;
  • credible problem;
  • explicit in-scope and out-of-scope boundary.

2. Requirements

Include at least five testable functional requirements and one quality constraint.

Every requirement must map to observable acceptance evidence.

3. Architecture and data design

Include:

  • responsibility/dependency diagram;
  • primary collection choice and rejected alternative;
  • class/record decisions;
  • at least one enforced invariant;
  • interface/composition decision;
  • inheritance use or explicit rejection where appropriate;
  • execution-lane statement: browser core or full JDK.

4. Implementation

The program must meaningfully use:

  • methods with distinct contracts;
  • at least one collection;
  • custom domain type(s);
  • validation/failure handling;
  • object collaboration where it reduces complexity.

Do not add classes/interfaces merely to increase feature count.

5. Test matrix

Include normal, boundary, invalid, empty/absence where applicable, integration, and regression cases.

Full-JDK lane may provide JUnit 6 evidence. Browser-core work must provide deterministic expected/actual evidence and must not claim a JUnit runner was used.

6. Preserved Version 1 failure

Provide:

  • failing requirement/test;
  • input/state;
  • expected versus actual;
  • reproducible Version 1 evidence;
  • whether the failure was natural or deliberately injected into a copy.

7. Root-cause analysis

Trace boundaries until the first divergent state. State the failed assumption/operation and a falsifiable hypothesis.

8. Controlled Version 2

Show the smallest responsible correction or explain why an architectural correction was required.

9. Regression evidence

Rerun the original failure plus previously passing and nearby-risk cases. Show a V1/V2 comparison.

10. Design defense

Give a concise defense covering:

  • problem;
  • architecture;
  • data/object decisions;
  • failure and correction;
  • validation;
  • limitation;
  • next evidence-producing experiment.

Mastery standard

A passing capstone must make this chain inspectable:

requirement
 -> design decision
 -> Java implementation
 -> test evidence
 -> failure evidence
 -> root cause
 -> revision
 -> regression evidence

A large program with no traceable decision/evidence chain is weaker than a smaller system whose behavior and design can be defended.