A SYSTEM SEQUENCE DIAGRAM (SSD) illustrates INPUT AND OUTPUT EVENTS related to the system under discussion, for ONE SCENARIO of a use case. THE ESSENTIAL DISCIPLINE: the system is drawn as a SINGLE BLACK BOX. There are no internal objects, because we are still in analysis and the internal design does not yet exist. The diagram shows only what crosses the boundary. WHY THIS MATTERS: an SSD identifies the SYSTEM OPERATIONS — the operations the system as a whole must offer. Those operations become the starting point for design: each one gets a controller and a collaboration that realises it. Skip the SSD and design begins without knowing what the system's public behaviour is. A WORKED SSD for the main success scenario of UC-05: :Counter Officer :System │ │ │ enterApplication(no) │ ├────────────────────────▶│ │◀ - - - - - - - - - - - -│ application details, feeDue │ │ │ confirmIdentity(no) │ ├────────────────────────▶│ │◀ - - - - - - - - - - - -│ verification result │ │ │ recordPayment(no, amt, │ │ method) │ ├────────────────────────▶│ │◀ - - - - - - - - - - - -│ receipt │ │ │ issueLicence(no) │ ├────────────────────────▶│ │◀ - - - - - - - - - - - -│ licence number │ │ NOTATION: solid arrow a message / request into the system dashed arrow a return of information vertical line the LIFELINE of a participant tall thin box an ACTIVATION (optional in an SSD) frames loop, alt, opt for repetition and alternatives THE FOUR SYSTEM OPERATIONS EXTRACTED: enterApplication(applicationNo) confirmIdentity(applicationNo) recordPayment(applicationNo, amount, method) issueLicence(applicationNo) NAMING SYSTEM OPERATIONS: use a verb phrase in the imperative, starting with a verb, at the level of the user's INTENT rather than the UI mechanics. `enterApplication` not `onSubmitClick`; `issueLicence` not `updateStatusToIssued`. The name should survive a change of user interface. ONE SSD PER SCENARIO, not per use case. The main success scenario gets one; a significant alternative may get another. Do not attempt to draw every extension — that is what the written use case is for. EXTERNAL SYSTEMS APPEAR AS ACTORS on their own lifelines, since they are outside the boundary: :System ─── verifyIdentity(citizenId) ──▶ :NationalIdService which makes the external dependency visible, and is where the availability arithmetic from the inter-organisational topic gets its input.

An OPERATION CONTRACT describes what a system operation does, in terms of STATE CHANGES to the objects in the domain model, using preconditions and postconditions. THE TEMPLATE: OPERATION the name and parameters CROSS REFERENCES the use cases this can occur in PRECONDITIONS assumptions about the state of the system BEFORE execution — noteworthy assumptions worth telling the reader POSTCONDITIONS the state of the objects in the domain model AFTER completion THE POSTCONDITION IS THE HEART OF IT, and there are strict conventions: · postconditions are DECLARATIONS ABOUT THE DOMAIN MODEL STATE, not actions · they are expressed in the PAST TENSE, as though the operation has already completed — "a Payment was created", not "create a Payment" · WHY THE PAST TENSE? Because it forces a statement about RESULTS rather than a description of an algorithm. The moment you write "then look up the district and calculate…" you are designing, which is the next phase's job. THE FOUR KINDS OF POSTCONDITION — the checklist to work through: 1. INSTANCE CREATION or DELETION 2. ATTRIBUTE MODIFICATION 3. ASSOCIATIONS FORMED or BROKEN 4. (and by implication) nothing else changed WORKED CONTRACT: ─────────────────────────────────────────────────────────── OPERATION recordPayment(applicationNo : String, amount : Money, method : PaymentMethod) CROSS REFERENCES UC-05 Issue a Licence, UC-07 Renew a Licence PRECONDITIONS an Application with applicationNo exists; its status is APPROVED; no Payment is currently associated with it; the officer is authenticated and authorised POSTCONDITIONS · a Payment instance p was created (1) · p.amount became amount (2) · p.method became method (2) · p.receivedOn became the current time (2) · p was associated with the Application (3) · p was associated with the recording Officer (3) · a Receipt instance r was created (1) · r was associated with p (3) · no other Application was modified (4) ─────────────────────────────────────────────────────────── NOTE THE LAST LINE. "No other Application was modified" is the FRAME CONDITION from the formal-methods topic, and it is the clause prose specifications always omit. Its absence permits an implementation that quietly changes something it should not. NOTE ALSO the precondition "no Payment is currently associated with it". That is what prevents double payment, and it was discovered by asking what must be true beforehand — a question the main scenario never prompts. WHY CONTRACTS ARE WORTH THE EFFORT: writing one forces you to walk the domain model and state precisely which instances, attributes and associations change. That walk regularly reveals a missing concept or association — the Receipt in the example above appears because you cannot state the postcondition without it. WHEN NOT TO WRITE CONTRACTS: when the operation's effect is obvious from its name and the use case text. Contracts earn their cost on operations with complex or subtle state changes, and are waste on `getApplicationDetails`. Larman's advice is explicit: use them when the use case text is insufficient.

A STATE MACHINE DIAGRAM shows the lifecycle of ONE object: the states it can occupy, the events that cause transitions, and any guards and actions. WHEN TO DRAW ONE: for a STATE-DEPENDENT object — one that reacts differently to the same event depending on its current state. An Application is state-dependent (approving a REJECTED application must fail); a Payment largely is not. THE APPLICATION LIFECYCLE, as a state machine: ● │ submit ▼ ┌──────────┐ assignForReview ┌──────────────┐ │ RECEIVED │───────────────────▶│ UNDER_REVIEW │ └──────────┘ └──────┬───┬───┘ approve │ │ reject [reviewedBy │ │ ≠ issuedBy] │ │ ┌───────▼┐ ▼┌──────────┐ │APPROVED│ │ REJECTED │◉ └───┬────┘ └──────────┘ issue │ [feePaid] / │ allocateNumber ▼ ┌─────────┐ │ ISSUED │◉ └─────────┘ NOTATION: ● initial pseudostate ◉ final state event [guard] / action on a transition entry / exit actions inside a state composite states, and history, for nested behaviour WHAT THE DIAGRAM MAKES UNAVOIDABLE — and this is its value: · WHICH TRANSITIONS ARE LEGAL, exhaustively. Every pair not drawn is illegal, so the diagram is a complete statement. This is the state machine that the interface specification topic discovered by asking about HTTP 409, and that the formal-methods topic needed to write the precondition. · GUARDS as business rules: `[feePaid]` and `[reviewedBy ≠ issuedBy]` are visible constraints. · TERMINAL STATES: REJECTED and ISSUED are final, which raises the reversal question from the change-management topic — CR-227 was precisely a request to make ISSUED non-terminal, and this diagram is what shows the size of that request. · TESTING IMPLICATIONS: from the test case design topic, state transition testing requires exercising every valid transition AND representative invalid ones. Counting the arrows gives you a test count: 5 valid transitions here, plus the invalid combinations worth probing. CHOOSING A BEHAVIOURAL VIEW — the practical summary of this whole topic: QUESTION DIAGRAM / ARTEFACT ───────────────────────────────────────────────────────── What crosses the system SYSTEM SEQUENCE DIAGRAM boundary, in what order? What exactly changes when OPERATION CONTRACT this operation runs? What states can this object STATE MACHINE be in, and what is legal? What is the flow of this ACTIVITY DIAGRAM process, including parallel branches? Which internal objects (design) SEQUENCE or collaborate to achieve this? COMMUNICATION DIAGRAM THE LAST ROW IS THE BOUNDARY OF THIS SECTION. Everything above it is ANALYSIS — the system as a black box, described by what it must do. The last row opens the box and assigns responsibilities to internal objects, which is design, and the subject of ACtE0805. THE ONE-LINE SUMMARY OF THE DISCIPLINE: an SSD says WHAT operations exist, a contract says WHAT each one changes, a state machine says WHEN each is legal — and none of them says HOW. Keeping the "how" out until all three are answered is what makes the design that follows a solution to a properly understood problem.