Object-Oriented Software Design: 25-Comp-A6 Software Engineering, May 2015, Q3

Question 3: Object-Oriented Software Design (20 marks)

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.

Identifying the Objects

Applying the standard noun-extraction heuristic to the problem description (entry/smoke/temperature/flood sensors, alarms, lights, phone numbers, keypad, thresholds, delays) and merging duplicates gives an abstract Sensor class with four concrete subclasses (one per sensor type, sharing a common polling/threshold interface), a coordinating SecuritySystem object that holds the armed/disarmed state and owns a Configuration object (thresholds, phone numbers, delays), a Keypad object for owner interaction, and three independent output/actuator objects (AlarmController, LightController, PhoneDialer).

Fig. Q3 — object model for the microprocessor-based Home Security System.

SecuritySystem is the coordinating object: it holds the current arm state (Armed/Disarmed), owns the Configuration, and its handleEvent() operation is invoked whenever any sensor reports an event, applying the configured threshold/delay logic before deciding whether to trigger an alarm. Sensor is an abstract base class defining a common poll() interface returning a SensorEvent; EntrySensor, SmokeSensor, TemperatureSensor and FloodSensor are its concrete subclasses, each knowing only how to read its own physical transducer and compare against its own threshold — polymorphism lets SecuritySystem treat every sensor type uniformly through the common interface rather than needing a type-specific branch for each. Keypad handles owner interaction (PIN entry to arm/disarm, and PIN-gated access to programming mode) and writes new thresholds, phone numbers and delays into Configuration, which is simply a structured store of the owner-settable parameters, decoupled from both the sensors that read it and the keypad that writes it. AlarmController, LightController and PhoneDialer are independent output objects, each responsible for exactly one physical actuation (sounding/silencing the siren; turning on the selected light zone; dialling the owner's programmed numbers in sequence) and each triggered only by SecuritySystem, never directly by a sensor — this keeps the decision of whether and how to respond to an event in one place.

Check — assumptions

Entry-sensor alarms are assumed to honour a programmed entry delay (to allow the owner to disarm after entering) while smoke and flood sensors are assumed to bypass any delay and trigger immediately, since they protect against life-safety/property hazards rather than intrusion and the question does not distinguish delay behaviour by sensor type. Disarming is assumed to require the correct PIN entered at the Keypad within a fixed number of attempts; a lockout or silent-alarm response after repeated failed attempts is a reasonable extension but is not specified, so it is not designed here. PhoneDialer is assumed to retry the owner's programmed numbers in the order entered until one is answered/acknowledged or the list is exhausted.

Concept & Theory: Object Identification via an Abstract Sensor Hierarchy

Topic: deriving an object model from a narrative requirement by extracting candidate classes from its nouns, then factoring structurally similar candidates (the four sensor types) into a shared abstract base class.
Key relations: nouns → candidate classes; shared attributes/operations across similar candidates → an abstract superclass exposing one polymorphic interface (poll()) that the coordinator can call uniformly.
Why this works: the four sensor types differ only in what physical quantity they read and what threshold they compare against, not in how the rest of the system uses them, so factoring the common interface into an abstract Sensor class lets SecuritySystem.handleEvent() stay a single piece of logic instead of four near-duplicate branches, and lets a new sensor type be added later without changing SecuritySystem at all.
Common pitfall: giving each concrete sensor subclass its own bespoke event type or handling method on SecuritySystem, which defeats the purpose of the abstraction and reintroduces the type-specific branching the hierarchy was meant to remove.
Source: Sommerville, Software Engineering, ch. "Object-Oriented Design" (object identification and inheritance-based generalisation).

Question 3 of 8: Object-Oriented Software Design

Question 3: Object-Oriented Software Design (20 marks)

Identifying the Objects