A memorize-friendly rebuild of the MVC and Layered pattern lecture — with the mnemonics, flows, and interfaces you actually need for the exam, drawn as the box‑and‑line schematics they really are.
Everything in this chapter hangs off one split. Ask: does the user interact with it? If yes → Interactive. If it's built from clean levels of abstraction → Hierarchical.
Systems built around user interfaces. The two quality attributes that matter most: Usability and Modifiability.
Main pattern: Model‑View‑Controller (MVC)
Systems decomposed into levels, top (abstract) to bottom (concrete). Each level only needs to know the level next to it.
Two patterns: Main Program & Subroutine · Layered (our focus)
IVHL — Interactive→MVC, Hierarchical→Layered. If you remember this pairing, you can't mix up which pattern answers which question type on the exam.
MVC decomposes an interactive system into Model, View, and Controller so the same data can be shown and driven in many different ways without touching the core logic.
| Component | What it does | Memory hook |
|---|---|---|
| Model | The system's core — data + major processing capabilities. When data changes, it updates its Views. | "The Model has the facts." |
| View | Output representation shown to the user (graphical, console, voice reply...). Every View is paired with a Controller. | "The View is the face." |
| Controller | Receives user input and translates it into service requests sent to the Model. | "The Controller is the hands." |
Facts don't move until the Hands push them, and the Face just shows whatever the Facts currently say.
Every MVC exam question is secretly asking you to trace this loop. It's alliterative on purpose — use that.
U‑C‑M‑V, and each role's job starts with the same letter as the role — the sentence is the definition.
Same Model, two very different Views/Controllers — this is why MVC exists.
User: waves hands at a wall‑sized display.
Controller: gesture recognition → sendCommand(FIND, SFH, 33803)
View: map with pins refreshes to show matches.
User: "Find single family home in Lakeland, FL."
Controller: speech recognition → same sendCommand(...) shape
View: laptop screen updates the same underlying results.
IObserver of the Model).
Easy to swap, enhance, or add new user interfaces without rewriting the Model.
Different UIs can be configured per audience (gesture wall vs. voice phone) from the same core.
Because concerns are separated, Model, View, and Controller can each be reused in other systems.
Common variations: fusing View+Controller (Microsoft's 1990s Document‑View) or the more elaborate Process‑Abstraction‑Controller pattern.
Each layer only talks to the layer directly above/below through a well‑defined interface. Higher layers consume what lower layers provide — nothing skips a level.
Or just remember: the layer nearest the user is the most abstract; the layer nearest the metal is the most concrete.
Dependencies stay local — swap a layer's implementation without touching the others.
Encapsulate the platform API in one system layer; port that layer and everything above moves free.
Controlled hierarchy makes it easy to slot in an encrypt/decrypt layer at the right boundary.
Each layer's services are compartmentalized, so they're easy to lift into another system.
MPSR — the exact same 4 letters, every time a question asks "why use layers?"
System type: Interactive
Shape: One Model, many View/Controller pairs, all peers.
Direction of data: Circular — User↔Controller↔Model↔View↔User.
Qualities: Modifiability, Usability, Reusability
System type: Hierarchical
Shape: Strict stack — level N only touches level N±1.
Direction of data: One‑way per hop — provides down, requires up.
Qualities: Modifiability, Portability, Security, Reusability
IVHL — Interact with a View → Hierarchy of Layers.
Model = Facts, View = Face, Controller = Hands.
Users Click, Controllers Convert, Models Mutate, Views Visualize (U‑C‑M‑V).
M‑U‑R — Modifiability, Usability, Reusability.
Satcom → Security → Application → Hardware (top to bottom).
M‑P‑S‑R — "My Program Stays Reusable" (Modifiability, Portability, Security, Reusability).
Pulled straight from the graded midterm pages you shared — the exact spots partial credit was lost. These aren't from this chapter, but they sit right next to it on the exam.
Every scenario has exactly these six pieces. Say all six, every time, even if the question only shows a diagram.
A "consoles + LAN server" box diagram is a component diagram, and that represents the Development view — not Physical/Deployment (that needs actual hardware nodes & installation).
A functional/quality requirement is only valid if it's measurable and specific. "The software shall be secure and fast" fails — no bandwidth number, no auth mechanism named, nothing to check it against.
Modularization = continuously decomposing a system into fine‑grained components.
Abstraction — show only what's important, hide the "how."
Encapsulation — hide data, expose only what's needed.
4 components: Source (data in) → Filter (transform) → Pipe (transmit) → Sink (consume).
Parallel/graph layout (B) beats strict sequential (A) on performance — filters run concurrently. Security can be injected as a filter at any stage (firewall, auth, detection).
Source → Stimulus (crash, omission, timing, incorrect response) → Artifact → Response (prevent / log / notify / disable source / go temporarily unavailable) → Measure (time available, detection time, repair time).
| Family | Patterns | One‑line hook |
|---|---|---|
| Creational | Abstract Factory · Factory Method · Builder · Singleton · Prototype | How an object gets born. |
| Structural | Adapter · Facade · Composite · Bridge · Decorator · Flyweight · Proxy | How objects get wired together. |
| Behavioral | Iterator · Observer · Strategy · State · Command · Template Method · Visitor · Mediator · Memento · Interpreter · Chain of Responsibility | How objects talk and decide. |