Question 18 of 28: The Model-View-Controller Architecture
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, May 2016. 3 hours, closed book exam with one aid sheet allowed (written on both sides), no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any five (5) questions in Part I, any three (3) in Part II, any four (4) in Part III, any two (2) in Part IV, and any five (5) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 19 questions actually marked (5+3+4+2+5 of 28) each count for 100/19 ≈ 5.26% of the paper. All 28 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles, dependability; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — creational/structural/behavioural pattern catalogue (Singleton, Proxy, Template Method, Observer, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/invariants, the open–closed principle; Barbara Liskov's 1987 substitutability paper for Question 11; Rogers, Sharp & Preece, Interaction Design, and Nielsen, Usability Engineering, for Question 21's HMI-specific non-functional requirements; Myers, The Art of Software Testing, for Question 28's boundary value analysis.
PART I — General Principles (answer any 5 of 7)
PART IV — GUI Design (answer any 2 of 4)
Question 18: The Model-View-Controller Architecture (Part IV)
MVC separates an interactive application into three collaborating parts. The Model holds the application's domain data and business logic/state, with no knowledge of any UI. A View is a visual presentation of some part of the Model's current state, purely a renderer with no business logic of its own. A Controller interprets user input/gestures directed at a View and translates them into operations on the Model (or into a switch of the active View).
Collaboration: the Model changes state and notifies its registered Views (typically via the Observer pattern, Question 16) that something changed; each notified View re-renders itself by re-reading the current Model state. A user interacting with a View has that input routed to the associated Controller, which invokes Model operations and/or switches which View is currently displayed. A single Model may drive MULTIPLE Views simultaneously (e.g., the same underlying data shown as both a table and a bar chart, both staying synchronized).
MVC collaboration: Controller updates the Model on user input; Model notifies the View(s) via Observer; the View reads current Model state to re-render.
(i) Extensibility — HELPS. Because View and Controller depend on the Model, but the Model holds no reference to any specific View, new Views (or Controllers) can be added for an existing Model with zero changes to the Model or to existing Views — e.g., adding a chart View alongside an existing tabular View of the same data.
(ii) Response time — HURTS (in the naive/default implementation). The Observer-based notification chain, plus the added indirection of routing every user action through a separate Controller object, plus potentially re-rendering several Views on every single Model change even when only one is currently visible, adds genuine overhead compared to a monolithic class that updates its own display directly. Mitigations exist (batching notifications, dirty-flag lazy repaint), but the architecture's default behaviour costs more per user action than a non-separated design.
(iii) Modifiability — HELPS. Each concern can change independently: redesigning the visual presentation (View) does not touch business logic (Model); changing the input mechanism (e.g., a Controller for touch input vs. one for mouse input) does not touch the Model or View classes; changing business rules (Model) never requires touching View/Controller code as long as the Model's notification interface stays unchanged. This isolation is the primary reason MVC is adopted despite its response-time cost.
