25-Comp-A6 Software Engineering · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — 17-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: eight questions, candidates answer any five (all questions equal weight — each of the five counted questions is worth 20%; any five questions constitute a complete paper, and only the first five as they appear in the answer book are marked). All eight questions are solved below for completeness. The page-1 heading reads "National Exams.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software reuse and portability, dependable/critical systems, distributed software engineering, configuration management, reliability metrics; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Leveson, Safeware — hazard and fault-tree analysis for safety-critical software.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Function-oriented design decomposes a system top-down into a hierarchy of functions (procedures) that transform input data into output data, typically documented as data-flow diagrams and structure charts. Data is treated as a separate, often shared or global, resource that flows between functions; the functions themselves are the primary unit of decomposition and reuse. Object-oriented design instead decomposes the system into objects, each of which bundles together a piece of state (its attributes) and the operations that are allowed to act on that state, and objects collaborate by sending each other messages (calling one another's operations) rather than by all reaching into a common pool of data.
The practical consequence is that function-oriented systems are easy to reason about for simple, well-defined data transformations (batch reports, numerical pipelines) but scale poorly as systems grow: because state is shared, a change to a data structure's representation can ripple through every function that touches it, producing the classic "change amplification" problem. Object-oriented design's information hiding — each object exposes only an interface and hides its internal representation — localizes the impact of a representation change to the object itself, and its support for inheritance and polymorphism gives a natural mechanism for extending and reusing behaviour. The trade-off is that object-oriented designs generally require more up-front design effort to identify the right objects and their responsibilities, and the extra layer of indirection (message passing between many small objects) can make the control flow of the finished system harder to trace by eye than a single top-down function hierarchy.
Applying the standard object-identification heuristic — underlining the nouns implicit in the scenario ("micro-sensor", "pump controller", "miniaturized pump", "needle") and separating what senses, what decides, and what physically acts — gives four collaborating objects, plus a fifth introduced deliberately as an independent safety check rather than derived from the narrative's nouns directly.
BloodSensor wraps the micro-sensor embedded in the patient, exposing only a calibrated read() operation that returns a sugar-level reading and hiding the raw analog signal path and calibration behind it. PumpController is the central decision object: its controlLoop() periodically calls BloodSensor.read(), passes the reading to computeDose() to derive a candidate insulin dose from the current target range, and forwards that candidate dose onward — but, critically, not directly to the pump. SafetyLimiter sits between the controller and the pump specifically because it must never be reachable through the same software path that computed the candidate dose: its clamp() operation is implemented as independent hardware logic (not a software class the PumpController can bypass or reconfigure) that caps whatever dose it is given at a fixed, separately-verified maximum, so that a single defect in PumpController's dosing algorithm cannot by itself cause the delivered dose to exceed a hard physical ceiling. InsulinPump is a thin actuator object whose only externally visible operation, dispense(safeDose), physically delivers the already-clamped dose via the permanently attached needle; it never receives an unclamped dose. AlarmManager is notified by PumpController whenever a hazardous condition is detected (a sensor reading outside plausible bounds, a candidate dose the SafetyLimiter had to clamp, a stop command that fails to take effect) and is kept as a separate object precisely so that alarm-handling logic can be tested, and reasoned about, independently of the dosing logic itself.
