25-Comp-B11 Advanced Software Design · December 2014
Question 16 of 26: Observer Roles vs. Boundary/Entity Classes
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, December 2014. 3 hours, closed book, no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any three (3) questions in Part I, any four (4) in Part II, any four (4) in Part III, any two (2) in Part IV, and any two (2) 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 15 questions actually marked (3+4+4+2+2 of 26) each count for 100/15 ≈ 6.7% of the paper. All 26 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles; 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 (Proxy, Bridge, Strategy, Observer, Template Method, Composite, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics (also underpins the Java/C++ discussion in Part V); Brown, Malveau, McCormick & Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis — anti-pattern catalogue (Question 18). Bertrand Meyer's Object-Oriented Software Construction is cited by name where the paper's own vocabulary (design by contract, open–closed principle) originates there; Barbara Liskov's 1987 substitutability paper is likewise cited by name for Question 11.
PART I — General Principles (answer any 3 of 5)
Question 16: Observer Roles vs. Boundary/Entity Classes (Part III)
The Boundary/Control/Entity (ECB) classification is a REQUIREMENTS-ANALYSIS-level responsibility category (what role a class plays with respect to actors, data, or use-case control flow), while Subject/Observer is a DESIGN-level, GoF pattern role (who publishes state changes, who subscribes to them). These are ORTHOGONAL classifications, so no ECB role is bound to a particular pattern role.
ConcreteSubject. "The object whose state changes matter to others" is very commonly an ENTITY (e.g., a StockPrice or SensorReading data object), but it need not be: a CONTROL class tracking the current step of a long-running workflow can itself be a ConcreteSubject, notifying several UI panels whenever the workflow's control-state advances. The "subject" role only requires "has state that other objects care about"; Entity, Control, and even Boundary classes can all satisfy that.
ConcreteObserver. "The object that reacts to a notification" is very commonly a BOUNDARY class (a GUI widget refreshing its display when notified — the classic use case, and the mechanism underlying MVC's Model-to-View notification in Question 19), but it need not be: a CONTROL class can observe another object purely to trigger further internal processing with no display involved at all — e.g., a logging/audit Control class observing a domain object to persist an audit trail, or a Control class recalculating a derived value whenever an upstream Entity changes. Nothing in the Observer contract (register interest, get notified, react) requires that reaction to be a screen update.
Conclusion. Observer's Subject/Observer roles describe the NOTIFICATION RELATIONSHIP, which is independent of WHY a class exists in the requirements model (data storage vs. use-case control vs. actor interface). Treating a design pattern's structural role as if it were itself a requirements-analysis responsibility category is a category error.
