25-Comp-B11 Advanced Software Design · December 2014
Question 20 of 26: 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, 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 20: 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 9 (actor vs. class independence) and Question 19 (MVC's View/Model split) — the Boundary/Control/Entity pattern is the general responsibility-assignment principle both of those questions are specific instances of.
