Question 19 of 27: Separating Boundary from Entity/Control 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 19: Separating Boundary from Entity/Control Classes (Part IV)
Boundary classes model the interface between the system and its actors (a screen, an API endpoint, a device driver) and are, by their nature, VOLATILE — they change whenever the presentation technology changes (a new UI toolkit, a new device, a redesigned screen layout, localizing for a new market) even when the underlying business logic and data are completely unchanged.
Keeping Boundary separate from Entity (persistent domain data) and Control (use-case orchestration logic) confines presentation-layer churn to the Boundary classes alone, and it never forces changes to Entity/Control classes; conversely, business-rule changes never force a UI rewrite.
Impact of NOT separating (business logic embedded directly inside GUI event handlers):
Implementation: the same business logic cannot be reused behind a different interface (e.g., exposing the same rules through a REST API alongside a desktop GUI) since the logic is welded to one specific UI technology's event model.
Testing: business logic embedded in UI event handlers can only be exercised by driving the actual UI — slow, brittle, and often requiring a real or simulated display — instead of fast, headless unit tests against a pure Entity/Control class with no UI dependency at all; this is the single largest practical cost of not separating.
Maintenance: a UI framework upgrade or platform port (e.g., desktop to web) forces re-verifying and often re-writing business logic that merely happened to live inside now-obsolete UI classes, multiplying the cost and risk of what should have been a purely cosmetic change.
This is exactly the requirements-analysis-level rationale underlying both Question 4 (actor vs. class independence) and Question 18 (MVC's View/Model split) — the Boundary/Control/Entity pattern is the general responsibility-assignment principle both of those questions are specific instances of.
