The organisational models of a system (repository, layered, client–server) describe its STATIC STRUCTURE but not how it behaves at run time. CONTROL STYLES are concerned with the control flow between subsystems — how the flow of control between them is organised. Two generic control styles are used in software systems: CENTRALISED CONTROL One subsystem has overall responsibility for control, and starts and stops other subsystems. EVENT-BASED CONTROL Rather than one subsystem being responsible for control, each subsystem can respond to externally generated events from other subsystems or from the system's environment. CENTRALISED CONTROL — TWO MODELS: 1. THE CALL–RETURN MODEL The familiar top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. · applicable to SEQUENTIAL systems only · the control subroutine is at the top; control passes down and returns up · simple to analyse — you can trace exactly what happens when, and where a value came from ┌──────────────┐ │ main │ └───┬───┬───┬──┘ │ │ │ ┌──▼┐ ┌▼─┐ ┌▼──┐ │r1 │ │r2│ │r3 │ └───┘ └──┘ └───┘ 2. THE MANAGER MODEL Applicable to CONCURRENT systems. One system component is designated as a system MANAGER and controls the starting, stopping and coordination of other system processes. · a process is a subsystem or module that can execute in parallel with other processes · a manager may also be implemented in a sequential system as a CASE STATEMENT that decides which process to invoke depending on state variables — this variant is often called a CALL-RETURN with dispatch, and is common in real-time systems ┌──────────────────────┐ │ system controller │ └──┬────┬────┬────┬────┘ │ │ │ │ ┌───▼┐ ┌─▼──┐ ┌▼──┐ ┌▼──────┐ │user│ │sens│ │act│ │compute│ │intf│ │ or │ │uat│ │process│ └────┘ └────┘ └───┘ └───────┘ EVENT-BASED CONTROL — TWO MODELS: 1. BROADCAST MODELS An event is broadcast to all subsystems. Any subsystem that has registered to handle that event can handle it. · effective in integrating subsystems distributed across different computers on a network · the subsystems that generate events do not know which subsystem will handle them — so the coupling is genuinely minimal · a subsystem may generate an event, or register an interest in particular events; when an event occurs the handler is invoked · CONTROL POLICY IS NOT EMBEDDED in the event and message handler — the subsystems decide on the events of interest to them · DISADVANTAGE: the subsystem generating an event does not know if or when the event will be handled 2. INTERRUPT-DRIVEN MODELS Used in REAL-TIME SYSTEMS where interrupts are detected by an interrupt handler and passed to some other component for processing. · there are a known number of interrupt types, each with a handler · each type is associated with a memory location, and a hardware switch causes a transfer to its handler · allows a VERY FAST RESPONSE to an event — this is the point of the model · DISADVANTAGES: complex to program and difficult to validate; the number of interrupts is limited by the hardware. OTHER EVENT-DRIVEN MODELS worth naming: SPREADSHEETS a cell change triggers recomputation of dependent cells (a dependency-driven model) PRODUCTION rule-based systems where a fact matching a SYSTEMS rule's condition fires its action

REQUIREMENT: when a licence is issued, print it, email the applicant, update the revenue dashboard, and notify the police records system. CENTRALISED (call–return / manager): LicenceIssuer.issue(app): licence = allocateNumber(app) printer.print(licence) # 1 mailer.send(app.email, licence) # 2 dashboard.increment(app.fee) # 3 policeSystem.notify(licence) # 4 app.status = ISSUED return licence ✔ THE ORDER IS EXPLICIT AND READABLE. Anyone can see exactly what happens, in what sequence, by reading one function. ✔ EASY TO DEBUG — one stack trace shows the whole story. ✔ TRANSACTIONAL REASONING IS POSSIBLE — you can wrap it. ✘ LicenceIssuer must KNOW ABOUT four subsystems. Adding an SMS notification means editing this function — so the module that issues licences changes whenever a notification requirement changes. That is exactly the coupling problem. ✘ IF THE POLICE SYSTEM IS SLOW, issuing a licence is slow. The officer waits at the counter for a system they do not care about. ✘ IF THE POLICE SYSTEM IS DOWN, what should happen? Fail the whole issuance? Then an external outage stops licence issuance nationally. Swallow the error? Then records silently diverge. EVENT-BASED (broadcast): LicenceIssuer.issue(app): licence = allocateNumber(app) app.status = ISSUED publish(LicenceIssued(licence, app.id, app.fee)) return licence # elsewhere, independently: PrintService subscribes to LicenceIssued MailService subscribes to LicenceIssued DashboardService subscribes to LicenceIssued PoliceGateway subscribes to LicenceIssued ✔ LicenceIssuer KNOWS ABOUT NOTHING. Adding SMS means adding a new subscriber and editing no existing code — the open/closed principle, achieved structurally. ✔ A SLOW OR DOWN SUBSCRIBER DOES NOT BLOCK issuance. The officer is served; the police notification retries. ✔ NATURALLY DISTRIBUTABLE across machines. ✘ THE ORDER IS NO LONGER VISIBLE ANYWHERE. To answer "what happens when a licence is issued?" you must search for subscribers. This is the single biggest cost, and it grows with the system. ✘ THE PUBLISHER DOES NOT KNOW IF THE EVENT WAS HANDLED. Did the email go out? Nothing in the issuing code can tell you. ✘ DEBUGGING IS HARD — there is no single stack trace; you need correlation ids and distributed tracing. ✘ NO TRANSACTION spans the subscribers. If printing fails after the status is ISSUED, you have an issued licence with no printed document, and you need a compensating action. THE HONEST SUMMARY ───────────────────────────────────────────────────────────── CENTRALISED EVENT-BASED ───────────────────────────────────────────────────────────── coupling high low order of events explicit invisible adding a consumer edit the caller add a subscriber debugging one stack trace tracing required failure isolation poor good transactions natural need compensation latency of the sum of all just the publish originating action steps ───────────────────────────────────────────────────────────── NEITHER COLUMN IS THE WINNER. Centralised control buys UNDERSTANDABILITY at the price of coupling; event-based control buys DECOUPLING at the price of understandability. The right choice depends on which of those you are short of.

USE CENTRALISED CONTROL WHEN · the sequence matters and must be auditable · a transaction must span the steps · the system is sequential, or small enough that one component can reasonably know the others · debuggability is worth more than flexibility — safety and financial systems commonly choose this deliberately USE EVENT-BASED CONTROL WHEN · the set of reactions to an event is OPEN — you expect to add more, and you do not want to edit the originator each time · subsystems are distributed across machines or owned by different teams · reactions must not block or endanger the originating action · the system must respond to environmental events it does not initiate (real-time, embedded, GUI) THE MIXED APPROACH THAT REAL SYSTEMS USE: Keep the CRITICAL PATH centralised and transactional; push everything else onto events. LicenceIssuer.issue(app): # one transaction licence = allocateNumber(app) # must not be lost app.status = ISSUED # must not be lost commit() publish(LicenceIssued(...)) # everything optional Print, email, dashboard and police notification are all reactions that may be retried, delayed or added to. Number allocation and status are invariants that must be atomic. Splitting on that line — INVARIANTS CENTRALISED, REACTIONS EVENT-DRIVEN — is the most useful heuristic in this topic, and it is the shape almost every well-built system converges on.