25-Comp-B11 Advanced Software Design · December 2018
Question 9 of 28: Verifying Contract Fulfillment — Assertions vs. Defensive Checks
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.
Common technique: runtime ASSERTIONS. A contract's precondition, postcondition, and class invariant (Question 10) are each expressed as a boolean assertion statement placed at the operation's entry, exit, and (where the language supports it) automatically re-checked at every public-method boundary. Languages without first-class contract syntax approximate this with a plain assert statement (Java, C, C++) or an annotation-based tool (JML for Java, Code Contracts for .NET) that generates the equivalent assertion checks. Crucially, assertions are typically compiled OUT of production builds (Question 8) — they exist to catch contract violations during development and testing, not to handle them gracefully at runtime.
Difference from defensive-programming checks. An assertion checking a precondition is written from the standpoint that the condition MUST already be true — if it fails, the assertion halts execution (or throws an unrecoverable error) because the caller has a BUG; it is not meant to be caught and handled as a normal control-flow path. A defensive-programming check, by contrast, is written from the standpoint that the condition MIGHT legitimately be false at runtime (because the caller is untrusted), so it must handle the failure gracefully — return an error code, throw a documented, catchable exception, or substitute a safe default — every single time, in every build, because the check is part of the program's normal, expected behaviour rather than a debugging aid. In short: an assertion documents and checks an assumption that should never be false; a defensive check handles a condition that legitimately CAN be false.
