25-Comp-B11 Advanced Software Design · Undated paper
Question 5 of 28: Why Multiple Design Alternatives Are Produced, and the Basis for Selecting One
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
17-Comp-B11 Advanced Software Design — National Exams, May 2019. 3 hours, closed book exam with two 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, testing, dependability, reuse; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/metrics/quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — pattern-language structure, the GoF pattern catalogue, and the "favor object composition over class inheritance" / "program to an interface, not an implementation" principles; Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, visibility, encapsulation, interfaces; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/class invariants; Barbara Liskov's 1987 substitutability paper for Question 12; Stroustrup, The C++ Programming Language, for friend/access-control semantics (Question 25).
Question 12 prints “Liskpv substitution principle”, a typo in the paper; it is answered as the Liskov substitution principle.
PART I — General Principles (answer any 5 of 7)
Question 5: Why Multiple Design Alternatives Are Produced, and the Basis for Selecting One (Part I)
Why multiple alternatives. The design space for satisfying a given set of functional requirements is large: different architectural styles, data structures, and patterns can all implement the SAME functional behaviour while differing substantially on quality attributes that the FRs alone say nothing about — performance, memory footprint, testability, extensibility, development cost and schedule. Because the first design that comes to mind is rarely the best on every one of these axes, experienced designers deliberately generate more than one candidate so trade-offs become visible for comparison, rather than being locked in by whichever design happened to be thought of first.
Basis for selection. Since every candidate already satisfies the FRs (that is the entry condition for being a candidate at all), selection is driven by the system's NON-functional requirements and constraints (Question 2): which candidate best meets the prioritized quality attributes (e.g. response time if the NFRs demand it, or maintainability if the system will be extended often), the project's cost/schedule/team-skill constraints, and the risk profile of any unfamiliar technology a candidate would require. In practice this is done with an explicit weighted trade-off/scoring matrix so the choice is documented and defensible rather than a matter of individual preference.