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.
The three terms describe successive stages in how a defect in the software can (but need not always) turn into a user-visible problem, and standard dependability terminology (IEEE/Sommerville) keeps them strictly distinct.
Fault. A static, latent property of the software itself — an incorrect step, process, or data definition (a wrong line of code, an off-by-one loop bound, a mis-typed constant). A fault exists in the artifact whether or not it is ever executed; it is sometimes called a "bug" or "defect."
Error. A dynamic, internal deviation from the correct state that occurs when a fault is actually EXECUTED (e.g., a variable holding an out-of-range value, an internal data structure left inconsistent). An error is a symptom that has appeared inside the running system, but has not necessarily reached anything a user can observe yet.
Failure. An externally OBSERVABLE deviation from the system's specified or expected service — the point at which an error has propagated all the way to the system's output or behaviour, where a user or an external system can actually see something wrong.
Relationship. A fault, when executed, MAY produce an error (not every fault is triggered by every input — a fault on a rarely-taken code path may sit dormant indefinitely); an error, if it propagates without being masked or corrected, MAY become a failure (defensive checks, redundancy, or simple luck — the erroneous value happening not to affect the final output — can prevent an error from ever reaching the output). Concretely: an off-by-one loop bound (fault) reads one element past the intended array range, producing a wrong internal total (error); if that wrong total is later displayed to the user or drives an incorrect downstream decision, a failure has occurred. If a later step in the same computation happens to discard or overwrite that specific wrong value before it reaches any output, the fault and the error both existed, yet no failure occurred.
