NivaarExam PrepOfficial exam papers ↗

25-Comp-B11 Advanced Software Design · December 2018

Question 5 of 28: Design Decisions, Design Alternatives, and Documented Rationale

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)

Question 5: Design Decisions, Design Alternatives, and Documented Rationale (Part I)

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.

A design alternative is one of several candidate solutions to a given design problem (e.g. "use MVC" vs. "use a monolithic UI class" for Question 18's interface-separation problem); a design decision is the act of committing to exactly one alternative, discarding the rest, at a specific point in the design process. Design proceeds by repeatedly generating a set of alternatives for a sub-problem and then making a decision that selects among them — decisions and alternatives are two views of the same activity: alternatives are the decision's INPUT (the option space), and the decision is the alternatives' OUTPUT (the one path actually taken).

Basis for selection. Design goals (Question 3's quantified quality requirements, prioritized) are the criteria against which alternatives are compared — performance, maintainability, reliability, security, reusability, cost, time-to-market. A project virtually never maximizes every goal simultaneously (Question 18's MVC trades response time for modifiability/extensibility), so the major concern is not finding an alternative that wins on every axis, but choosing the alternative that best satisfies whichever goals have been PRIORITIZED for this project, and being explicit about what is being traded away.

Why documented rationale matters. Without a recorded rationale, only the CHOSEN alternative survives in the codebase; the rejected alternatives, and the reasoning that eliminated them, are lost. This causes three concrete problems later: (1) a future maintainer, unaware an alternative was already considered and rejected for a specific reason, may re-propose and re-investigate it, wasting effort re-deriving a conclusion the original team already reached; (2) when the ORIGINAL trade-off conditions change (e.g. a performance constraint that ruled out an alternative is later relaxed), nobody can tell whether the decision should be revisited, since the reason it was made is unknown; (3) auditing or certifying a safety- or regulation-critical decision (relevant to EGBC-regulated work) requires demonstrating that alternatives were genuinely considered and why the chosen one was safe/adequate — an undocumented decision cannot be defended after the fact, even if it was correct at the time.