Question 9 of 27: Benefits and Challenges of Design by Contract
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, May 2015. 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 four (4) questions in Part I, any three (3) in Part II, any three (3) in Part III, any two (2) in Part IV, and any four (4) 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 16 questions actually marked (4+3+3+2+4 of 27) each count for 100/16 ≈ 6.25% of the paper. All 27 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 — structural/behavioural pattern catalogue (Adapter, Bridge, Strategy, Observer, Template Method, Composite, 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.
PART I — General Principles (answer any 4 of 7)
Question 9: Benefits and Challenges of Design by Contract (Part II)
Design by Contract (Question 8) formalizes each operation's obligations as an explicit precondition/postcondition/class-invariant triad (Question 10) between a supplier and its clients.
Benefits. Contracts document each operation's real behaviour precisely and unambiguously (far more precisely than prose comments), and in languages with runtime assertion support they can be MACHINE-CHECKED. They sharply localize fault assignment when something goes wrong (caller's fault if a precondition failed; supplier's fault if a postcondition or invariant failed despite a satisfied precondition), which speeds debugging. They also justify omitting redundant defensive checks inside the supplier (Question 8) — if the precondition already guarantees a non-empty stack, pop() need not re-check emptiness defensively, since a violated precondition is by definition the caller's bug, not a case the supplier must recover from gracefully.
Challenges. Writing and maintaining contracts alongside the code is extra effort, and runtime assertion checking has a real performance cost, often leading teams to strip it from production builds — removing exactly the safety net most useful for catching real violations. Many mainstream languages (historically Java, C++) lack first-class contract syntax, requiring library or annotation workarounds (assert, JML) rather than a language-enforced mechanism. Stating precise, correct contracts for complex, stateful, or concurrent operations (e.g., invariants spanning multiple collaborating objects) can become nearly as hard as writing the implementation itself, and a wrong contract only formalizes a wrong assumption rather than catching it — DbC complements testing, it does not replace it.
