UML provides two INTERACTION DIAGRAMS that show the same information with different emphasis. Both illustrate how objects collaborate to fulfil a responsibility, and both are drawn from the system operations and contracts of analysis. COMMUNICATION DIAGRAM (formerly COLLABORATION DIAGRAM in UML 1.x — the syllabus's term) Objects are arranged as a GRAPH, connected by links, with messages written along the links and NUMBERED to show sequence. ✔ shows the STRUCTURE of the collaboration — who is connected to whom — at a glance ✔ compact; good for a small number of objects with many messages ✔ makes COUPLING VISIBLE: an object with many links is highly coupled, and you can see it immediately ✘ the sequence must be read from numbers, which is harder ✘ poor for long sequences SEQUENCE DIAGRAM Objects are lifelines across the top, time runs DOWN the page, messages are arrows between lifelines. ✔ the ORDER is immediately obvious ✔ handles long interactions, loops, alternatives and concurrency well (with frames) ✔ the dominant choice in practice ✘ says less about structure — you must trace arrows to see how coupled an object is THEY ARE SEMANTICALLY EQUIVALENT: a tool can generate one from the other. THE CHOICE IS ABOUT WHAT YOU WANT THE READER TO NOTICE — order, or structure. NOTATION — COMMUNICATION DIAGRAM: ┌────────────────────┐ 1: find(no) │ :RecordPayment │ ──────────────────────▶ ┌──────────────┐ │ Handler │ │ :Application │ └────────────────────┘ │ Repository │ │ │ └──────────────┘ │ │ 2: recordPayment(amt, m, o) │ ▼ │ ┌──────────────┐ 2.1: «create»(amt, m, o) │ │ :Application │ ─────────────────────▶ ┌──────────┐ │ └──────────────┘ │ :Payment │ │ └──────────┘ │ 3: create(payment) ▼ ┌────────────────┐ │ :ReceiptFactory│ └────────────────┘ THE ELEMENTS: :ClassName an instance (anonymous) name:ClassName a named instance a link (plain line) the connection permitting messages 1:, 2:, 2.1: sequence numbering; nesting uses dots, so 2.1 happens during 2 «create» a stereotype marking instance creation *[i := 1..n] iteration over a collection [condition] a guard on a conditional message msg() : ReturnType a return value NOTATION — SEQUENCE DIAGRAM, the same collaboration: :Handler :Repository :Application :Payment :ReceiptFactory │ │ │ │ │ │ find(no) │ │ │ │ ├──────────────▶│ │ │ │ │◀ - - - - - - -│ app │ │ │ │ recordPayment(amt, m, o) │ │ │ ├────────────────────────────▶│ │ │ │ │ │ «create» │ │ │ │ ├────────────▶│ │ │◀ - - - - - - - - - - - - - -│ payment │ │ │ create(payment) │ │ │ ├─────────────────────────────────────────────────────────▶ │◀ - - - - - - - - - - - - - - - - - - - - - - - - - - - -│ ADDITIONAL SEQUENCE-DIAGRAM NOTATION: ACTIVATION BAR a tall thin rectangle on a lifeline showing the object is active FRAMES operators framing a region: loop [cond] repetition alt [c1]/[c2] mutually exclusive alternatives opt [cond] an optional region par parallel regions ref a reference to another interaction ✕ on a lifeline object destruction a self-message an arrow returning to the same lifeline

THE MOST VALUABLE USE OF THESE DIAGRAMS IS NOT DOCUMENTATION — it is DIAGNOSIS. A drawn collaboration exposes design problems that are invisible in a class diagram. PROBLEM 1 — THE GOD CONTROLLER (high fan-out) :IssueLicenceHandler sends messages to nine objects: Repository, Application, Payment, LicenceNumberPool, Printer, AuditWriter, PoliceGateway, SmsSender, Dashboard THE DIAGNOSIS: fan-out 9, which from the design heuristics topic gives structural complexity S = 9² = 81. The handler knows about everything, so any change touches it, and it cannot be tested without nine collaborators. THE FIX: the invariant/reaction split from the control styles topic — the handler does the transactional core (allocate, record, audit) and publishes an event; printing, notification and the dashboard subscribe. Fan-out falls to 4, S = 16, a 5-fold reduction. PROBLEM 2 — THE MESSAGE CHAIN (a train wreck) handler → application.getApplicant() .getDistrict() .getFeeSchedule() .getRate(category) THE DIAGNOSIS: the handler now depends on Applicant, District AND FeeSchedule, though it was only given an Application. Any change to the shape of that chain breaks the handler. This violates the LAW OF DEMETER (the "don't talk to strangers" principle): an object should only send messages to itself, its own fields, its method parameters, and objects it creates. THE FIX: `application.feeDue()` — ask the object you have for what you want, and let it delegate internally. One dependency instead of four. PROBLEM 3 — THE ANAEMIC COLLABORATION handler → application.getStatus() handler → if (status == APPROVED) … handler → application.setStatus(ISSUED) THE DIAGNOSIS: the handler is making the decision using the Application's data. That is the anaemic domain model from the previous topic, visible in the interaction as a get/decide/set pattern. THE DIAGNOSTIC PATTERN TO LOOK FOR: any sequence of get → compute → set on the SAME object means the behaviour belongs in that object. THE FIX: `application.issue(officer)`. PROBLEM 4 — TOO MANY LAYERS CROSSED A UI object sending a message directly to a Repository skips the domain, which means the business rules were bypassed. The layering rule from the previous topic is a statement about which arrows may appear in an interaction diagram — and the diagram is where a violation becomes visible. A QUANTIFIED COMPARISON of two candidate designs for the same operation: criterion design A design B ────────────────────────────────────────────────── objects involved 9 5 messages sent 14 8 handler fan-out 9 4 S = fan_out² 81 16 deepest chain 4 1 collaborators needed to unit test the handler 9 2 ────────────────────────────────────────────────── THE LAST ROW IS THE ONE THAT MATTERS DAILY. A handler needing nine collaborators requires nine test doubles per test, so the tests are long, brittle and rarely written. A handler needing two is testable in a few lines. INTERACTION DESIGN DETERMINES TESTABILITY, which is the same conclusion the development-cycle topic reached about the Clock parameter.

THE FULL METHOD, applied to `issueLicence(applicationNo)`. THE CONTRACT (from analysis): PRE the Application exists; status is APPROVED; the fee is paid POST a Licence was created with a unique number; the Licence was associated with the Application; status became ISSUED; a StatusChange was created and associated; no other Application was modified STEP 1 — START WITH THE CONTROLLER, which receives the system operation: :IssueLicenceHandler receives issueLicence(no) STEP 2 — FOR EACH POSTCONDITION, ASK "WHO HAS THE INFORMATION NEEDED TO DO THIS?" (this is the Information Expert reasoning of the next topic, applied): "a Licence with a UNIQUE number was created" → who knows which numbers are used? Not the Application — uniqueness is system-wide. A LicenceNumberPool (or a sequence in the repository) is the expert. → :LicenceNumberPool.allocate() : LicenceNo "the Licence was associated with the Application" → the Application holds the reference, so it should create or receive it → :Application.issue(licenceNo, officer) : Licence "status became ISSUED and a StatusChange was created" → the Application owns its status and its history → inside issue(), the Application does both. It is the only object that can enforce "no status change without a history entry", so THE INVARIANT LIVES INSIDE IT. "no other Application was modified" → satisfied by construction: only one Application receives a message STEP 3 — DRAW IT: :IssueLicenceHandler 1: app := find(no) ──▶ :ApplicationRepository 2: no := allocate() ──▶ :LicenceNumberPool 3: lic := issue(no, officer)──▶ :Application 3.1: «create» :Licence 3.2: «create» :StatusChange 4: save(app) ──▶ :ApplicationRepository 5: return lic STEP 4 — CHECK THE FAILURE PATHS from the elaborated use case: pool exhausted (5a) → allocate() throws; nothing else has happened yet, so the minimal guarantee "no number consumed without an issuance" holds ONLY IF allocation happens before any commit. THE ORDER OF MESSAGES 2 AND 3 IS A CORRECTNESS DECISION, not a stylistic one. concurrent issuance (5d) → save() fails on a version conflict; the transaction rolls back; the allocated number is lost unless the pool is transactional. → THE DIAGRAM RAISES A QUESTION THE CONTRACT DID NOT: is a gap in licence numbers acceptable? The business must answer. If not, the pool must participate in the same transaction. STEP 5 — READ THE METHODS OFF THE DIAGRAM: IssueLicenceHandler.handle(no, officer) : Licence ApplicationRepository.find(no) / .save(app) LicenceNumberPool.allocate() : LicenceNo Application.issue(licenceNo, officer) : Licence FOUR OBJECTS, FIVE MESSAGES, fan-out 3 for the handler. And step 4 surfaced a business question that neither the use case nor the contract had asked — which is the argument for drawing the interaction rather than going straight to code.