25-Comp-A6 Software Engineering · May 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Paper: 98-Comp-A6, Software Engineering — 2016-May, 3 hours, closed book, no calculators. Answer any five of the eight questions; all five count equally (20 marks each, 100 total). All eight questions are answered below.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, real-time systems, software testing, formal methods, rapid software development, client-server/distributed architectures; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing coverage; IEEE/ISO 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.
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.
Extracting candidate objects from the nouns of the requirement (sensor, base station, central monitoring station) and specializing the sensor concept into its four stated variants gives an object model built around an abstract Sensor superclass:
The abstract Sensor class factors out what all four wireless devices share — an id, an assigned zone, an enabled/disabled flag toggled from the base station, and the ability to report a trigger event upward — leaving only checkState() abstract, since how each subclass actually senses (a contact switch for DoorWindowSensor, an ionization/photoelectric element for SmokeSensor, a conductivity probe for WaterSensor, a PIR element for MotionDetector) genuinely differs. BaseStation is the coordinating object: it owns the full set of installed sensors, holds the system's armed/disarmed state, and exposes the two owner-facing operations the requirement calls for — arm()/disarm() for the whole system and toggleSensor(id) for an individual sensor. Its onSensorTriggered(s) operation is called by any enabled sensor that detects an event; if the system is armed, it invokes AlarmSounder.sound() locally and CentralMonitoringLink.notifyAlarm(zone, type) over the Internet to the monitoring company. CentralMonitoringLink is kept as its own object (rather than folding the network call directly into BaseStation) specifically so the Internet-connectivity concern — retries, connection loss, heartbeat keep-alives to the monitoring station — is isolated behind one narrow interface, matching the cohesion/coupling reasoning of Question 2(a): BaseStation's own logic never needs to know how the notification actually reaches the monitoring station.
toggleSensor(id) can disable a sensor entirely (e.g. a pet-triggered motion detector) independent of the overall armed state, per the requirement's "turn on or off any of the sensors individually" wording; and CentralMonitoringLink retries its notification and raises a local fault indication on BaseStation if the Internet connection itself is down, since an unreachable monitoring station on a genuine intrusion is the single most safety-critical failure mode of this design.