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 V — C++/Java and Modular Programming (answer any 5 of 7)
The open–closed principle (OCP, Bertrand Meyer) states that a class or module should be open for extension (new behaviour can be added) but closed for modification (its existing, already-tested source code is never edited to add that behaviour).
The two halves must hold simultaneously, not one alone. "Open" without "closed" — freely editing the class every time new behaviour is needed — means every extension risks re-breaking existing, already-verified clients, and regression risk grows unbounded as the system accumulates features. "Closed" without "open" — a frozen, unmodifiable class with no extension point — would simply be useless once requirements evolve, since nothing could ever be added. Achieving both together is what lets a class be trusted while the system as a whole keeps evolving: the mechanism is abstraction plus polymorphism, so client code and existing subclasses depend only on a stable interface, and new behaviour is added purely by writing new implementations of that interface.
Example. Java's collection-sorting facility takes a Comparator interface: Collections.sort(list, comparator). The sort algorithm's own source code is never touched to support a new ordering — a caller wanting to sort employees by salary instead of by name simply writes a new class implementing Comparator and passes it in. The framework (the sort routine) is closed — nobody edits it — yet open, because arbitrarily many new orderings can be plugged in without ever recompiling it. The benefit is direct: the sort algorithm's own correctness, once verified, is never put at risk by a new sorting need, and new orderings can be developed, tested, and shipped independently of the sort routine itself.
