MVC Class Design for a Stock Monitoring Application: 25-Comp-B11 Advanced Software Design, December 2018, Q18

Question 18 of 28: MVC Class Design for a Stock Monitoring Application

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

17-Comp-B11 Advanced Software Design — National Exams, December 2018. 3 hours, closed book exam with up to 2 aid sheets 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, 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 and the "program to an interface, not an implementation" / "favor object composition over class inheritance" principles; 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; Barbara Liskov's 1987 substitutability paper for Question 11; Karl Wiegers, Software Requirements (3rd ed.) — the functional/quality/process/implementation/business requirements taxonomy of Question 2; Kruchten, The Rational Unified Process: An Introduction, for Question 1; Myers, The Art of Software Testing, for Questions 6 and 28.

PART I — General Principles (answer any 5 of 7)

PART IV — GUI Design (answer any 2 of 4)

Question 18: MVC Class Design for a Stock Monitoring Application (Part IV)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

The Model (StockModel) holds the current price data for the requested stock and knows nothing about how it is displayed. Two Views present the SAME Model simultaneously in different forms: TextualStockView renders the price as plain text, GraphicalStockView renders it as a chart. A Controller (StockController) accepts the user-entered stock name, fetches/attaches the correct StockModel, and mediates further user input (e.g., switching the monitored stock).

MVC class structure for the stock application: one StockModel drives two concurrently-displayed Views (textual and graphical); StockController handles the entered stock name and routes further input.

(i) Extensibility — HELPS. Because both Views depend on the Model but the Model holds no reference to either concrete View, a third View (e.g., a mobile-widget summary) can be added later with zero changes to StockModel or to the existing two Views.

(ii) Response time — HURTS (in the naive/default implementation). Every price update must notify and re-render BOTH Views via the Observer mechanism (Question 16), plus route user actions through the separate Controller object, adding overhead versus a single monolithic class that updates its own display directly.

(iii) Modifiability — HELPS. The graphical View's charting library can be swapped, or the textual View's format changed, without touching StockModel or StockController; conversely, changing how the current price is fetched or computed (Model) never requires touching either View's rendering code.

Concept & Theory: MVC's Cost/Benefit Trade-off

Topic: Separation of concerns purchased at the price of indirection overhead.

Key relations: Decoupling (Model unaware of View) → extensibility and modifiability improve; indirection (Observer notification + Controller routing) → raw response time worsens.

Why this works: The same structural decision that lets a second View be added for free is exactly what costs response time when several Views must all be kept in sync — there is no free separation.

Common pitfall: Claiming MVC "helps" every design goal — the question specifically expects at least one "hurts" answer; response time is the standard one, and it is more pronounced here because TWO Views must be kept synchronized on every price tick.

Source: Sommerville, Software Engineering, ch. "Object-Oriented Design"; Gamma, Helm, Johnson & Vlissides, Design Patterns (Observer, the mechanism underlying MVC's Model→View notification).