Question 16 of 27: 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, 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 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 18), 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.
