25-Comp-B11 Advanced Software Design · Undated paper
Question 13 of 28: The Structured Contents of a Pattern Language
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)
PART III — Patterns (answer any 4 of 5)
Question 13: The Structured Contents of a Pattern Language (Part III)
Name. A short, memorable handle (e.g. "Observer") that becomes shared vocabulary — naming a pattern lets designers communicate an entire solution shape in one word.
Motivation. A concrete scenario illustrating the recurring design problem the pattern solves, grounding the abstract structure in a relatable example before the general solution is presented.
Applicability. The situations in which the pattern should be applied — the recognizable symptoms in a design (or in the requirements) that indicate this pattern, rather than another, is the right fit.
Forces. The competing concerns or constraints the pattern must balance (e.g. flexibility vs. performance, simplicity vs. extensibility) — understanding the forces explains WHY the solution is shaped the way it is.
Solution Structure. The static structure of the solution — the classes/objects involved, their responsibilities, and their relationships, typically shown as a UML class diagram.
Consequences. The trade-offs of applying the pattern — both benefits (e.g. increased flexibility) and costs (e.g. added indirection or number of classes) — so a designer can judge whether the trade-off is worthwhile for the case at hand.
Implementation. Practical guidance, pitfalls, and language-specific techniques for realizing the structure correctly (e.g. how a given language's features make one variant easier than another).
Sample code. A concrete code fragment in a specific language showing the pattern's structure translated into an actual, compilable implementation.
Known applications. Real, existing systems or libraries that use the pattern, giving evidence the pattern is proven rather than theoretical.
Relation to other patterns. How the pattern combines with, is often used alongside, or can be confused with other patterns (e.g. Question 16's State/Strategy pair share an almost identical structure diagram but differ in intent).
