Architectural Design: Control Models

6.1 Architectural Design: Role, Stages, and Models

6.1.1 The role of architectural design in the development process

Architectural design establishes the overall structure of a software system: the way the components and modules are designed, the interfaces between them, and the communications between the various components. It sits between requirements engineering and the design phases of software engineering. Requirements engineering decides what the system must do; architectural design decides the shape of the system that will do it; the design phases that follow fill in the details of that shape.

We need several different models to describe an architecture because one diagram cannot carry structure, runtime behavior, and data flow at the same time. A single picture is like a single photograph of a building: it shows one angle, but an architect needs floor plans, wiring diagrams, and plumbing layouts before the building can be built. Architectural design also supports reuse: a good architecture carries across products of a similar category within the application domain. Systems in the same domain often share the same skeleton, so the architecture itself becomes a reusable asset. The previous session covered the importance of architecture, architectural models drawn as box and line diagrams, and architectural design decisions.

The organization of a system reflects the basic strategy used to structure the system. So the overall organizational model has to be decided early in the design process — early enough to structure the requirements engineering process itself. In other words, the high-level shape of the system is often chosen while requirements are still being gathered, because the requirements discussion is easier when stakeholders can point at large components. The system organization may show up directly in the subsystem structure and in how the subsystems are interconnected. Even so, the subsystem model usually carries more detail than the overall architectural structural model. There is also no simple mapping between the subsystem structural models and the overall system organizational architecture: the same high-level organization can be realized by very different subsystem structures.

In the wider discipline, architecture is seen as the dominant influence on non-functional characteristics such as performance, security, safety, availability, and maintainability. Components deliver the functional requirements; the way those components are organized decides whether the system is fast enough, secure enough, and cheap enough to maintain.

6.1.2 The three stages of the architectural design process

The architectural design process has three steps. They are usually tackled in this order, though in practice the stages feed back into each other as new information appears.

1. System structuring: decompose the system into several subsystems and identify the communications between these subsystems. Several architectural styles are used to structure the system into subsystems. This is the stage where the architect picks the big skeleton — layered, repository, client server, pipes and filters, and so on — and decides which subsystems talk to which.
2. Control modeling: model the control relationships between different parts of the system while the system is in execution, that is, at runtime. Structuring says what exists; control modeling says who drives whom when the system runs. This stage is the focus of the rest of this session.
3. Modular decomposition: after system structuring, decompose the subsystems into modules. Each subsystem is broken into smaller, individually designable and implementable units, which become the targets for detailed design and coding.

The three stages answer three different questions about the same system: how it is divided, how it is controlled, and how each piece is built in detail.

6.1.3 The variety of architectural models

Depending on what we want to communicate, we can build different kinds of models. Each model type answers one kind of question, and an architecture is usually described with several of them together:

• a static structural model based on some architectural pattern — this shows the system as a set of components and subsystems and how they are connected, without worrying about when anything runs;
• a dynamic process model, which is the control model — this shows how control moves between subsystems while the system is executing, and it is the subject of the next section;
• an interface model — this defines the services each subsystem offers and the contracts the other subsystems rely on when they use those services;
• a data flow model that shows the flow of information and the relationships between entities — this tracks where data is produced, transformed, and consumed.

The useful mental model: the structural model is a map of the system, the control model is the schedule, the interface model is the contract, and the data flow model is the movement of goods on that map. No single one of these replaces the others.

6.1.4 Structural models from the previous session

At a high level, architectural design is informally expressed as a box and line diagram. This is a very high level abstract view of the systems and subsystems and their interaction. It gives little detail about the type of interaction or the flow of control or information between them. More specific models show how the subsystems are structured, how they share data, how they are distributed, and how they interface with each other. The main structural models are:

• Layered model: the system is arranged in layers, each layer offering services to the one above it. A layer only relies on the layer immediately beneath it, so a change inside one layer does not ripple through the whole system. Real-world: a typical web application — browser interface, business logic, and database support sit in separate layers, and each can be replaced independently.
• Shared repository model (shared data model): subsystems share data through a central store that all of them access. Components do not talk to each other directly; they communicate through the repository. Real-world: an integrated development environment (IDE) where editors, compilers, and debuggers all read and write the same project data. The downside is that the repository is a single point of failure.
• Client server model: a distributed system model with a number of clients and servers. Clients request services; servers provide them, usually over a network with a request–reply pattern. Real-world: a film or photo library where separate servers manage the catalog, video, and pictures, and browsers act as clients.
• Pipes and filters model: a sequence of processing elements that transform input data at various stages into the output. Each filter takes a stream, transforms it, and passes the result to the next filter through a pipe. It is usually suitable for batch processing of data. It also suits applications where the format of the data is consistent across all the processes. Real-world: an invoicing batch — read issued invoices, identify payments, issue receipts, find payments due, issue reminders — where each step is one filter.

The four patterns are not rivals for the same job; each answers a different need:

Real-world: beyond these, patterns such as the MVC architectural pattern and the microservices pattern are familiar from everyday application development work. You will use them in your regular work as part of application development. MVC splits a system into model (data), view (presentation), and controller (user interaction), so the data can change independently of how it is shown; microservices split a large system into small, independently deployable services that talk over a network.

6.1.5 Application architectures from the previous session

Application architectures are the structures that recur across whole categories of applications. They are the same shapes appearing in system after system within a domain, so a designer can start from the known shape instead of inventing one from nothing.

• Transaction processing systems: these process user requests that read from or update a database. They include e-commerce applications; an ATM is an example. A customer's cash withdrawal is treated as one transaction: check the balance, modify it, and dispense the cash — either all happens or none does.
• Information systems: these allow controlled access to a large base of information such as a library catalog or patient records. They typically use layered architectures, with a user interface layer on top, application logic in the middle, and a database at the bottom.
• Language processing systems: these translate a language into another representation. They can use pipes and filters, a repository model, or a hybrid of the two. A compiler is the classic case.

Anyone who has worked on compiler design will recognize this. Compiler design is typically studied in undergraduate work. Some students have also built compiler modules as part of a project or an assignment — at least a lexical analyzer, a syntactic analyzer, and a semantic analyzer. Building those modules means choosing an architecture very much like this one: typically the repository architecture, which is applicable to a variety of systems. The same compiler can also be modeled with pipes and filters, so one system can be shown either way.

6.2 Control Models: How the System Behaves at Runtime

6.2.1 Control models vs structural models

Control models describe the runtime behavior of the software, and they are distinct from structural models. Structural models are concerned with how a system is decomposed into subsystems and then into modules. Control models are concerned with the control flow between subsystems while the system operates — in short, how the system is controlled when it is running.

For the subsystems to work together as a system, they must be controlled so that their services are delivered to the right place at the right time. A bank's subsystems might be perfectly structured on paper, but unless something decides when the cash-dispensing unit runs, when the account check runs, and in what order, the ATM delivers nothing. That "something" is the control model.

None of the structural patterns we saw — repository, layered, pipes and filters, client server — includes control information. The architect must organize the subsystems according to some control model that supplements the structural model being used.

6.2.2 Two generic control types

Two generic control types cover most software systems.

1. Centralized control: one subsystem has overall responsibility for control and starts and stops other subsystems. It may hand control to another subsystem, but it expects the control responsibility to come back to it, the way control returns in a normal program. One boss, giving orders and expecting them to be executed and reported back.
2. Event-driven control: used when the system must respond to externally generated events. Instead of control being embedded in one subsystem, each subsystem is programmed to respond to externally generated events. These events may come from other subsystems or from the environment of the system. No single boss: each part reacts when something happens, and the "something" can arrive at any time.

The two types answer the same question — "who decides what runs next?" — in opposite ways:

When to pick which: choose centralized control when the work follows a predictable sequence or a soft deadline and one coordinator can manage it; choose event-driven control when the system must react to things that can happen at any moment, especially from outside the system.

The rest of this session looks at each type in detail: the two flavors of centralized control first, then the two flavors of event-driven control.

6.3 Centralized Control

6.3.1 The call-return model

In a centralized control model, one subsystem is designated the system controller and has the responsibility for managing the execution of the other subsystems. Centralized control models fall into two types, depending on whether the controlled subsystems execute sequentially or in parallel. For sequential systems we use the call-return model; for concurrent systems we use the centralized management model.

The call-return model is the familiar top-down subroutine model. Control starts at the top of the subroutine hierarchy, the main function. Through subroutine calls — the main program calls routine 1, which in turn calls subroutine 1.1 — control passes to lower levels of the hierarchy. When subroutine 1.1 completes its task, control returns to routine 1. When that routine completes its task, control returns to the main program, which may then invoke the next routine.

This model is applicable only to sequential systems, where one set of instructions is executed at a time. Anyone who has written programs in a language like C knows the pattern. Think of a large program: you have a main module and many submodules or functions. Once a function is called, its task is executed, and control returns to the calling module or the main module — the same shape as this hierarchy. The model describes the dynamics of the program — how control moves — not a structural model of the code. A subroutine that is called by another subroutine does not need to be physically nested inside it: subroutine_1_1 may live anywhere in the code, and it is the call that links it to routine 1, not its location.

The currently executing subroutine holds the responsibility for control: it can call other subroutines or return to its parent. Returning control to some other point in the program rather than to the calling module is poor programming style. It bypasses the caller, which may still have cleanup to do, and it makes the flow of control unpredictable. If you have ever seen a program that used an unconditional jump or a long jump to "escape" out of a deeply nested call, you have seen this anti-pattern in practice.

The call-return model can be used at the module level to control functions or objects. Subroutines called by other subroutines are naturally functions in functional programming; in object-oriented systems, the operations of objects — methods — are implemented as procedures or functions. When a Java object requests a service from another object, it does so by calling an associated method: object A invokes b.calculate() and expects control to come back to A when the call finishes. The same top-down discipline applies at the object level.

6.3.2 Strengths and weaknesses of the call-return model

The model is a little bit rigid and restricted, and that shows up as one clear strength and one clear weakness.

The strength: it is relatively simple to analyze the control flows and work out how the system will respond to particular inputs. Because every call returns to its caller, the path a request takes is a tree that can be traced by hand: follow the calls down, follow the returns up, and the response to any input is predictable. This makes the model easy to reason about, to test, and to explain to a new member of the team.

6.3.3 The centralized management model

The centralized management model (the manager model) is used for concurrent systems, often in soft real-time systems that do not have very tight time constraints. One system component acts as a monitor or manager that watches the other subsystems and controls the starting, stopping, and coordination of the other processes. Unlike the call-return model, the managed processes may run in parallel; the manager does not wait for one process to finish before dealing with another.

A process, in this context, is a subsystem or a module that can execute in parallel with other processes.

The controller also checks whether other processes have produced information to be processed, and passes information to them for processing — the manager is not just a start/stop switch; it is also the traffic director for data between the managed processes.

A form of this model may also be applied in sequential systems. A management routine calls particular subsystems depending on the values of some state variables, usually implemented as a case statement — if these conditions hold, activate these subsystems. This is the sequential cousin of the manager model: the same "look at the state, then decide" logic, but executed as a plain switch rather than as parallel process management.

6.3.4 The event loop model

The controller usually loops continuously, pulling sensors and other processes for events or state changes. For this reason, the model is sometimes called the event loop model. It is the usual choice for soft real-time systems that run several processes concurrently.

Picture the loop as a circle: poll (ask each process what its state is), analyze (compare against the conditions that matter), act (start or stop processes, pass data on), then repeat from the top. The loop never ends while the system is running, and the shorter the loop time, the faster the system notices a change — but also the more processor time the polling consumes.

6.4 Event-Driven Control

6.4.1 What counts as an event

Event-driven systems respond to internally or externally generated events in real time. In centralized control models, the control decisions are usually determined by the value of some system state variables. In event-driven control systems, the system is activated and driven by externally generated events. The difference is the direction of initiative: a central controller checks whether something needs doing; an event-driven subsystem is interrupted in its work when something needs doing.

The term event does not just mean a binary signal. It may be a signal that can take a range of values, or a command input from a menu. The distinction between an event and a simple input is that the timing of the event is outside the control of the process that handles that event. An external or internal event can occur at any time; a signal can arrive at any moment.

6.4.2 Kinds of event-driven systems

Many kinds of systems are event-driven.

• Editors, including program editors, driven by user interface events that signify editing commands. Every key press and menu selection is an event that the editor turns into an editing action.
• Rule-based production systems, used in AI applications, where a condition becoming true can trigger an action. The system has a set of rules; when a fact changes and a rule's condition becomes true, that rule fires.
• Active objects, where changing the value of an object's attribute triggers some action. The object notices that one of its properties changed and reacts without being asked.
• Spreadsheets, where a change in one value correspondingly changes the related values in the spreadsheet. The user edits one cell; the spreadsheet recomputes every dependent cell on its own.

The pioneering text on software architectures by Garlan and Shaw discusses these kinds of event-driven systems. (The name is sometimes transcribed as "Garland".)

We look at two event-driven control models: the broadcast model and the interrupt-driven model. Broadcast models work well for integrating subsystems distributed across different computers on a network, while interrupt-driven models are used in real-time systems with very stringent timing requirements.

6.4.3 The broadcast model

In a typical broadcast model, subsystems register an interest in specific events — in this respect it works like a client server model. When those events occur, control is transferred to the subsystem that can handle the event.

The distinction from the centralized control model used for soft real-time systems: the control policy is not embedded in the event and message handler. Subsystems decide which events they require, and the event and message handler ensures that those events are sent to them. The events are broadcast; the subsystems that are programmed to respond to a specific event respond to it. Nobody prescribes from above which subsystem must react to which event — each subsystem declares its own interests.

All events could be broadcast to all subsystems, but that would impose a great deal of processing overhead. More often, the event and message handler maintains a register of subsystems and the events of interest to each subsystem. A subsystem generates an event indicating, perhaps, that some data is available for processing. The handler detects the event, consults the event register, and passes the event to the subsystems that declared an interest.

The event handler also usually supports point-to-point communication: a subsystem can explicitly send a message to another subsystem. Broadcast and point-to-point are both available, so subsystems can either shout an event to whoever is listening or whisper directly to a named partner.

6.4.4 Advantages and drawbacks of the broadcast model

The advantages of the broadcast model:

• Evolution is relatively simple. A new subsystem that handles particular classes of events is integrated by registering its events with the event handler. No existing subsystem has to change — the new one simply declares its interests.
• Any subsystem can activate any other subsystem without knowing its name or location. The sender never needs an address book; it generates the event and the handler delivers it.
• Subsystems can be implemented on distributed machines, and the distribution need not be known to the subsystems: it is transparent. They simply interact over a network as they normally do, whether they sit on the same computer or in different buildings.

The drawbacks of the broadcast model:

• Subsystems do not know if or when events will be handled. When a subsystem generates an event, it does not know which other subsystems registered an interest in that event. The sender cannot rely on a reply, so it cannot easily verify that its work was consumed.
• Different subsystems can register for the same events, which can cause conflicts when the results of handling an event by multiple subsystems are made available. Two subsystems may both react to "data available" and both try to process the same data, stepping on each other.
• The model does not fit real-time systems. Systems that must handle externally generated events very quickly must be event-driven in the interrupt sense, covered next.

6.4.5 The interrupt-driven model

Real-time systems that require externally generated events to be handled very quickly must be event-driven. Consider a real-time system controlling the safety systems in a car. It must detect a possible crash and inflate an airbag before the driver's head would hit the steering wheel. Providing that rapid response requires interrupt-driven control.

There are a known number of interrupt types, each a class of external events with a specific handler defined for it. Each type of interrupt is associated with a memory location where its event handler's address is stored. When an interrupt of a particular type is received, a hardware switch causes the control to be transferred immediately to its event handler. The interrupt handler may then start or stop other processes in the system in response to the event signaled by the interrupt. In the car example, the crash interrupt invokes a process that inflates the airbag immediately, before the driver's head can move toward the steering wheel.

This model is mostly used in real-time systems where an immediate response to some event is necessary. It may be combined with the centralized management model: the central manager handles the normal running of the system, and interrupt-based control handles specific emergencies. The manager keeps the routine processes running in its polling loop, while the interrupt handler jumps in the moment a critical event arrives.

6.4.6 Strengths and drawbacks of interrupt-driven control

The strength: it allows very fast responses to events to be implemented.

The drawbacks:

• It is complex to program and difficult to validate, because a separate event handler is needed for each and every exceptional event that may occur. Every handler is a small program of its own, with its own assumptions about the state of the rest of the system, and every one of them has to be written and checked.
• It may be impossible to replicate patterns of interrupt timing during system testing. A handler may work perfectly in a thousand tests and still fail on the one timing pattern that the tests never reproduced — two interrupts arriving almost together, for example.
• Systems built with this model are hard to change when the number of interrupts is limited by the hardware. Once the limit is reached, no other types of events can be handled.

6.4.7 Interrupt mapping and its limits

The hardware limit can sometimes be worked around by mapping several types of events onto a single interrupt. The handler then works out which event has occurred and invokes the corresponding process. Instead of needing a separate hardware interrupt for each event type, the system groups several related events under one interrupt number and lets the handler disambiguate them.

But interrupt mapping may be impractical when a very fast response to individual interrupts is required, as in an automotive crash prevention system. The disambiguation step costs time: the handler must first discover which event occurred and then dispatch to the right process. In a crash, those extra microseconds are precious, so each safety-critical event type keeps its own dedicated interrupt.

6.5 Modular Decomposition and Where Architectural Design Goes Next

6.5.1 Modular decomposition: the third stage

After system structuring and control modeling, the third stage of the architectural design process is modular decomposition: decomposing the subsystems into modules. Where system structuring divided the whole system into large subsystems, modular decomposition now takes each subsystem and breaks it into smaller, self-contained modules with well-defined interfaces. Each module becomes a unit that can be designed, implemented, and tested separately, which is why modular decomposition is the natural bridge from architecture into detailed design.

Large systems typically have composite architectural styles: each module may be developed using a different architectural style, because what suits one subsystem — a repository for the shared data, pipes and filters for the batch pipeline — may not suit its neighbor. The architecture of a big system is a mixture of styles rather than a single pure pattern.

The discussion of this stage was announced and then the session closed with the key points below. Architectural design is a very detailed topic, and detailed design comes in the subsequent sessions. The control models examined in this session — centralized and event-driven — decide how execution is directed; modular decomposition decides how the units that execute are shaped.

6.5.2 Key points and what comes next

• Architectural design is an important aspect of the software development process: it interfaces between the requirements engineering and the design phases of software engineering.
• As part of the process we derive a structural system model, develop a control model, and produce a modular decomposition model.
• Large systems typically have composite architectural styles, because each module may be developed using a different architectural style.
• Systems can be structured using patterns and styles such as MVC, the repository model, the client server model, the layered model, and the microservices pattern.
• The control of system execution can be structured with either centralized control or event-driven control.
• Certain application architectures recur; transaction processing systems and language processing systems are the ones we saw.

Exam Guidance Summary

• Exam note: the regular exam is scheduled for 23rd of September; the makeup exam comes two weeks later. The exam is less than a month away, so start revising now rather than waiting for the last classes.
• Study advice: study the textbook chapters on architectural design and the courseware, and follow the material delivered for this topic. The exam follows the delivered material, so the lecture content is your primary guide.
• Exam note: two or three more classes remain before the mid-semester exam — use them to resolve any doubts on architectural design.
• Exam note: questions on architectural design can be posted and answered, so ask early instead of carrying confusion into the exam.

Key Industry Applications

• Real-world: transaction processing systems cover e-commerce applications; an ATM is a familiar example. Every cash withdrawal is a transaction that must complete as one unit.
• Real-world: information systems typically use layered architectures, with the user interface, application logic, and database in separate layers.
• Real-world: language processing systems, such as compilers, use a repository model, pipes and filters, or a hybrid of both. The repository holds the symbol table and the syntax tree.
• Real-world: building monitoring systems and home monitoring systems use the centralized management model. A controller starts and stops sensor, actuator, computation, user interface, and fault handler processes, and raises alarms for intrusion or fire.
• Real-world: personal computers use event listener subsystems that translate mouse clicks and keyboard events into specific commands.
• Real-world: automotive safety systems use interrupt-driven control to inflate airbags on crash detection, because the response must happen in milliseconds.
• Real-world: editors, rule-based production systems in AI, active objects, and spreadsheets are event-driven systems.
• Real-world: Java object method calls follow the call-return model at the object level: one object asks another for a service by calling a method, and control returns when the call finishes.