Final architecture-patterns lecture: the patterns for interactive systems (MVC) and hierarchical systems (layered). After this, the course moves from architecture to detailed design.

Two quality attributes matter most: usability (the UI must be easy to use) and modifiability (UIs change often, so changing them must be cheap).

The mainstream pattern for interactive systems is MVC, because it isolates the part that changes most (the UI) from the data and rules.

MVC is for interactive applications that need flexible human-computer interfaces: the UI can be replaced or multiplied without touching the core.

The three component types (the table):

Model

Represents the system’s core: its major processing capabilities and data.

View

The output representation of the system (graphical or console-based).

Controller

Associated with a view; handles user input.

The same app is also part of a distributed system: the mobile client sends requests (login, messages, balance) through APIs to a server that applies business rules and uses a database. Summary: MVC inside the app, client–server outside it. Patterns combine at different levels.

The motivating example: the same core data is shown in different formats (line chart, bar chart, pie chart, table). Each is a different representation of one data set.

When the data changes, all views must update to reflect it. MVC achieves that by keeping one model and letting every view observe it, instead of each view keeping its own copy that could drift.

Model: holds the core data and system functionality; when the data changes, it updates (notifies) the views. In the box-and-line diagram one model sits under all the views and controllers.

MVC for a real-estate system with two very different interfaces (not a UML diagram). The model in the middle holds the real-estate data and the core functionality.

Two controllers translate input into the same kind of service request, sendCommand(FIND, 5FH, 33803): on the very large screen, a controller uses hand-gesture recognition; on the small screen (no room for buttons), a controller uses speech recognition (“Find single family home in Lakeland, FL”).

Each view is updated to display the results of the service request: two views of the same data. Adding a third interface would mean adding a view–controller pair, without touching the model.

RealEstateModel: processCommand() handles the FIND command, update() changes its internal state (and notifies views), getResults() is how views fetch the search results (messages 10–12).

Application (set-up, messages 1–5): creates the model, the speech-customised view and the voice controller, and attach(aView)es the view to the model.

User: onVoiceInput("find single family homes in Lakeland, FL") starts the interaction (message 7). Reading order: set-up, then input → controller → model → view.

The quality properties table: modifiability (easy to exchange, enhance or add user interfaces), usability (because UIs are exchangeable, systems can be configured with different interfaces for different groups of users), reusability (with concerns separated, model, view and controller components can be reused in other systems).

MVC has many variations: Microsoft’s 1990s Document-View architecture fused view and controller into one component; presentation-abstraction-control is a more extensive variant (the slide calls it “process-abstraction-controller”).

Remember the three qualities as the payoff of separating the UI: change it, tailor it, reuse the parts. The cost is more objects and update paths, which isn’t worth it for a trivial static screen.

Two common patterns: main program and subroutine (a main routine calls subroutines, which call lower ones) and layered. This lecture covers layered.

The diagram: a top-level module (highest abstraction) uses intermediate modules (middle layer), which use low-level modules (base operations). Calls go downward; higher levels never need to know how lower ones work.

Modifiability: dependencies stay local within a layer; components only reach others through a well-defined, unified interface, so a layer component can be swapped for an enhanced one.

Portability: everything that touches the platform’s APIs is encapsulated in one layer; port that layer and the higher layers move to the new platform unchanged.

Security: the controlled hierarchy makes it easy to insert security components, e.g. a layer that encrypts and decrypts all incoming and outgoing data.

A layered remote-monitoring system, top to bottom. SatcomLayer handles satellite communication; it provides ISatcom to the outside.

HardwareLayer controls the physical devices and sensors; it provides IHardware. In the UML diagram each layer requires exactly the interface of the layer below; the subsystem’s external ports (IMonitorPlan, INodeMonitor) are delegated to the top and bottom layers. Each extra layer adds a call, which is the pattern’s performance cost.

This completes the architectural patterns: blackboard, pipes and filters, client–server, broker, MVC and layered.