Skip to main content

OOD Project and Carry-Forward

Project: a contract-driven account and report boundary​

Budget 12–16 hours, included in the module estimate. Reuse the offline labs; do not build a payment integration or real banking service.

  1. Reproduce two failures in legacy.py and preserve the initial traces.
  2. Define the approved public contract and classify each change as preserved behavior, bug repair or API/representation migration.
  3. Implement the two account representations, value validation, read-only statement consumer, supplied rate policy and report boundary. Keep model-based checks.
  4. Compare one architecture alternative, including a justified choice to retain a function or a central dispatch. Link the three design experiments.
  5. Handle a changed request: a read-only live history for a new client while old callers retain snapshots. Propose a compatible API and test a small variant; explicitly exclude concurrent iteration guarantees you have not established.

Deliver code, a README with fresh-run commands, public contracts, before/after traces, decision note, observed experiment output and assistance declaration. A concise 2–3 page narrative can link the evidence. Another reviewer should trace an unseen rejected operation and challenge the ownership/migration decision; if no reviewer is available, record self-assessment and pending independent review.

Pass requires reproducible core behavior, explicit failure and alias contracts, a supported tradeoff and changed-case defense. Class count or pattern names do not add credit. Keep the legacy fixture, characterization observations and contract tests for Module 2, where you will develop the mechanics of smaller behavior-preserving changes.

This module prepares API and ownership evidence for the semester project. It does not complete the semester's separate human-centered accessibility strand; retain that requirement and its actual usability/audit evidence at semester integration.