19-Soft-A3 Software Design · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, 04-Soft-A3 Software Design — May 2019. Closed-book exam, 3 hours, two double-sided reference sheets allowed, no calculator. Six questions constitute the exam paper; candidates answer five of the six, with the first five as they appear in the answer book marked, and each question and each sub-question carries equal value. Every question is answered in full below so this solution serves as a complete study resource for the whole bank.
Reference texts: Sommerville, Software Engineering (10th ed.); Pressman, Software Engineering: A Practitioner's Approach (9th ed.); Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software; ISO/IEC 25010, Systems and Software Quality Requirements and Evaluation (SQuaRE); SWEBOK v4.
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.
MVC decomposes an interactive application into three collaborating parts, each owning exactly one concern, as shown below for the address book application: the Model owns the data and business logic; the View renders the model's current state to the screen and contains no business logic; the Controller receives user input events, translates them into calls on the model, and selects which view to display next.
Applications with a rich, frequently changing user interface backed by relatively stable business logic benefit most from MVC — interactive desktop, web and mobile applications (the address book, e-commerce storefronts, dashboards). The quality benefit is Modifiability/Portability: because the View is isolated from the Model, a new interface (a mobile view alongside a desktop view) can be added, or the visual layout completely redesigned, by writing or changing only the View, without touching the business logic at all; and because the Controller isolates input handling, adding a new input device (voice command alongside mouse/keyboard) only requires a new Controller. This directly follows from the separation-of-concerns principle applied at the architectural scale.
In Publish-Subscribe, publishers announce events to a named topic (or message broker) without knowing who, if anyone, is listening; subscribers register interest in a topic and are notified automatically whenever a matching event is published, without the publisher needing any direct reference to them.
Applications with many independent components that must react to the same events, where the set of interested components changes over time or grows large benefit most from Publish-Subscribe — event-driven systems, IoT/sensor networks, stock-ticker/notification services, and microservice architectures that must stay loosely coupled. The quality benefit is Modifiability/Scalability: because the publisher never references its subscribers directly, a new subscriber (e.g. a new "sync to cloud" service reacting to contact edits) can be added at runtime with zero changes to the publisher's code, and the number of subscribers can grow without the publisher's complexity growing — a stark contrast to a design where the publisher would otherwise have to call each interested component by name.
The public part of a component or module is the interface it exposes to the rest of the system — the operations (with their signatures) that other modules are permitted to call. The private part is everything else: internal data structures, helper functions, and the algorithm implementing each public operation, none of which any other module may access directly. The relationship is that the public part is a deliberately narrow, stable contract, while the private part is free to change as long as it continues to honour that contract; for the address book's contact-storage module, saveContacts() and loadContacts() are public, while the exact file format, buffering strategy and any internal caching are private. The benefit of separating them is information hiding, and it directly improves Maintainability (the private storage format can be changed from a flat file to a database without any change to code that only calls the public saveContacts()/loadContacts() operations), Reusability (another application can reuse the module purely through its public interface, without needing to understand its private internals), and Security (private data cannot be manipulated except through the sanctioned public operations, which can enforce validation).
A payment module that hides which payment gateway it calls behind a single public processPayment(amount) operation lets an organisation switch providers later by rewriting only the private internals — exactly the maintainability benefit that public/private separation, MVC and Publish-Subscribe all deliver by the same underlying mechanism: hiding volatile detail behind a stable, narrow interface.
