Before the cycle, the concepts it depends on. These four are the definitional core of object orientation and a guaranteed exam question. ABSTRACTION The essential characteristics of an object that distinguish it from all other kinds of object, providing a crisply defined boundary relative to the perspective of the viewer. → decide what matters and ignore the rest, as in the design concepts topic. ENCAPSULATION The process of compartmentalising the elements of an abstraction that constitute its structure and behaviour; encapsulation serves to separate the CONTRACTUAL INTERFACE of an abstraction from its IMPLEMENTATION. → this is Parnas's information hiding, realised as a language feature. The class publishes operations and hides its data representation, so the representation can change without breaking callers. NOTE: encapsulation is not the same as data hiding. Data hiding is one mechanism; encapsulation is the principle of bundling data with the operations that act on it, and keeping the internals private. MODULARITY The property of a system that has been decomposed into a set of cohesive and loosely coupled modules. → in OO, the class is the primary unit of modularity and the package or namespace groups classes. HIERARCHY A ranking or ordering of abstractions. The two important hierarchies: IS-A hierarchy — INHERITANCE / generalisation. A Car is-a Vehicle. Shares structure and behaviour. PART-OF hierarchy — AGGREGATION / composition. A Wheel is part-of a Car. CONFUSING THESE IS THE COMMONEST OO MODELLING ERROR. If you can say "is a kind of", use inheritance; if you can say "has a" or "is part of", use composition. THE THREE ADDITIONAL CONCEPTS usually listed alongside: CLASS a description of a set of objects sharing the same attributes, operations, relationships and semantics. A class is a TEMPLATE; an object is an INSTANCE. MESSAGE objects interact by sending messages — requesting an operation of another object. Behaviour is distributed, not centralised. POLYMORPHISM the ability of different types to respond to the same message in their own way. It is what makes a design extensible: a new subtype can be added without changing the code that sends the message — the open/closed principle from the design concepts topic. WHY POLYMORPHISM MATTERS, concretely. Without it: if (type == PDF) renderPdf(doc); else if (type == EXCEL) renderExcel(doc); else if (type == CSV) renderCsv(doc); Every new format edits this function — and every other function shaped like it. With polymorphism: renderer.render(doc); A new format adds a class and edits nothing. THIS IS THE SINGLE LARGEST PRACTICAL BENEFIT of object orientation, and it is the same conclusion the design heuristics topic reached when it exploded a report controller into a strategy interface.

THE THREE PHASES, and what carries between them: OBJECT-ORIENTED ANALYSIS (OOA) Purpose: understand and describe the PROBLEM DOMAIN. Activities: · identify the actors and their goals → use cases · build the GLOSSARY · identify domain CONCEPTS → the conceptual/domain model · identify ASSOCIATIONS and ATTRIBUTES of concepts · describe SYSTEM BEHAVIOUR — what the system does in response to events, without saying how Output: use case model, domain model, system sequence diagrams, operation contracts. THE DISCIPLINE: NO software classes. Everything named here is a real-world concept a domain expert would recognise. OBJECT-ORIENTED DESIGN (OOD) Purpose: define a SOFTWARE SOLUTION that satisfies the analysis. Activities: · define the architecture and layers · assign RESPONSIBILITIES to software objects — the central activity, and the subject of ACtE0805 · design the collaborations that realise each use case → interaction diagrams · determine VISIBILITY between objects · define the design class diagram with types, visibility and method signatures · apply DESIGN PATTERNS where a known solution fits Output: interaction (sequence/collaboration) diagrams, design class diagram, package/deployment structure. OBJECT-ORIENTED IMPLEMENTATION / PROGRAMMING (OOP) Purpose: express the design in a programming language. Activities: · map design classes to class definitions · derive method bodies from the interaction diagrams · implement associations as references or collections · handle exceptions per the contracts Output: source code and unit tests — the subject of ACtE0806. WHAT CARRIES THROUGH, which is the point of the whole approach: a CONCEPT in analysis → a DESIGN CLASS → a CLASS in code an ASSOCIATION → a REFERENCE or collection a USE CASE → a set of INTERACTIONS → a set of METHODS and a test a SYSTEM OPERATION → a CONTROLLER method No paradigm shift, and therefore no translation loss. Compare structured development, where a data-flow diagram must be converted into a module hierarchy by a process with no mechanical correspondence. THE ITERATIVE SHAPE — the phases are not sequential stages but activities repeated per iteration: iteration n: select use cases → analyse them → design → implement → test → demonstrate iteration n+1: the next use cases, PLUS what the demonstration taught you EACH ITERATION IS A COMPLETE MINIATURE PROJECT, typically two to six weeks, producing running tested software. From the requirement process topic: the demonstration at the end is the validation mechanism, and iterations are ordered by risk.

TRACE "Record Payment" end to end, so the correspondence is concrete rather than asserted. ── ANALYSIS ────────────────────────────────────────────────── USE CASE step 4 of UC-05: "Officer records the fee payment." DOMAIN CONCEPTS identified from the text: Payment, Fee, Application, Officer, Receipt ASSOCIATIONS: Application 1 ──── 0..1 Payment Payment * ──── 1 Officer (recorded by) Payment 1 ──── 0..1 Receipt ATTRIBUTES: Payment: amount, receivedOn, method, reference SYSTEM OPERATION (what the system must do, stated abstractly): recordPayment(applicationNo, amount, method) PRE the application is APPROVED and unpaid; amount equals the fee due POST a Payment instance was created and associated with the Application; a Receipt was created; the application's paid flag is set NOTE: an OPERATION CONTRACT in analysis says what changes, not how. "A Payment instance was created" is a statement about the domain, not about a constructor. ── DESIGN ──────────────────────────────────────────────────── RESPONSIBILITY ASSIGNMENT — who does what: PaymentController receives the system operation Application knows its fee and its paid state, so it validates the amount (it has the information — the Information Expert principle of ACtE0805) Payment is created and holds its own data ReceiptPrinter renders the receipt PaymentRepository persists the Payment INTERACTION (a sequence, abbreviated): Officer → PaymentController : recordPayment(no, amt, m) Controller → ApplicationRepository : find(no) Controller → Application : assertPayable(amt) Controller → Payment : «create»(amt, m, officer) Controller → Application : attach(payment) Controller → PaymentRepository : save(payment) Controller → ReceiptPrinter : print(payment) DESIGN CLASS, now with solution detail: class Payment { - id : PaymentId - amount : Money {≥ 0} - receivedOn: Instant - method : PaymentMethod - reference : String {gateway ref, nullable} - version : int ← solution-domain only + Payment(amount, method, officer) + isReconciled() : boolean } `version` and `reference` have no analysis counterpart — optimistic locking and gateway reconciliation are solution concerns, exactly as the design model topic described. ── IMPLEMENTATION ──────────────────────────────────────────── public final class Payment { private final Money amount; private final PaymentMethod method; private final OfficerId recordedBy; private final Instant receivedOn; private String gatewayReference; // null until known private int version; Payment(Money amount, PaymentMethod method, OfficerId by, Clock clock) { if (amount.isNegative()) throw new IllegalArgumentException( "amount must not be negative"); this.amount = amount; this.method = method; this.recordedBy = by; this.receivedOn = clock.instant(); } boolean isReconciled() { return gatewayReference != null; } } NOTE `Clock clock` IN THE CONSTRUCTOR. The design said `receivedOn` is set at creation; taking the clock as a parameter rather than calling a static now() is what makes the class testable — the FIRST properties from the test automation topic, specifically Repeatable. A design decision with a testing consequence. THE CORRESPONDENCE, tabulated: analysis concept Payment → design class Payment → Java class Payment association Application—Payment → attach(payment) + a field contract postcondition → the constructor's assignments contract precondition → assertPayable + the constructor's guard use case extension 4a → gatewayReference nullable + isReconciled() EVERY ROW IS A MECHANICAL STEP. That is the claim object orientation makes about the development cycle, and it is substantially true — which is why the same nouns survive from the interview to the source file.