Question 2 of 9: Software Design

Question 2: Software Design (a) 10, (b) 10 — 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.

(a) Cohesion, Coupling, Adaptability

Cohesion is the degree to which the responsibilities inside a single module are functionally related and work together toward one well-defined purpose — a highly cohesive module "does one thing." Coupling is the degree of interdependence between separate modules: how much one module must know about another's internal representation, control flow or interface details in order to work correctly. Adaptability (maintainability/flexibility) is the ease with which a system can accommodate changes — in requirements, in the operating environment, or in the platform — without extensive, wide-reaching rework.

Maximizing cohesion and minimizing coupling both serve the same underlying goal: localizing the effect of change. A highly cohesive module is small in scope and purpose, so it is easy to understand, test and modify in isolation, and any change driven by a new requirement about that one responsibility touches only that one module. Low coupling means modules interact only through narrow, well-defined interfaces rather than through shared internal state or implicit assumptions about each other's implementation, so a module can be modified, replaced, or even completely re-implemented without forcing changes on the modules that use it. Systems built with high cohesion and low coupling therefore confine the "blast radius" of any single change to a small, identifiable part of the system, which is precisely what makes a system easy (cheap) to maintain over its lifetime.

Coupling and portability are directly related because porting a module means moving it into a new environment with minimal modification, and what must be modified during a port is exactly whatever the module is coupled to. A module tightly coupled to a specific operating system API, a specific hardware register layout, or another module's internal data representation carries that dependency with it, and every one of those dependencies must be reworked when the environment changes. A module with low coupling — one that reaches the outside world only through a small, abstract interface — confines any platform-specific code to a thin boundary layer beneath that interface, so the bulk of the module's logic ports unchanged; only the boundary layer needs replacing. Low coupling is therefore a prerequisite for portability, not merely a maintainability nicety.

(b) Function-Oriented Design of the Home Security System

The HSS decomposes naturally into input-handling, decision, storage and output/actuation functions, each an independent module communicating through explicit data and control flows rather than shared state.

Sensor Input Handler polls (or receives interrupts from) the entry, smoke, temperature and flood sensors and normalizes each raw reading into a common internal representation. Keypad Input & Programming handles owner interaction with the keypad, including PIN-gated access to programming mode, and writes owner-set thresholds, phone numbers and alarm delays into the Configuration Store. Threshold Monitor is the core decision function: on every sensor update it compares the reading against the configuration store's thresholds (allowing for the programmed delay before an alarm is declared, e.g. an entry delay to allow disarming) and raises the appropriate event. Alarm Controller, Light Controller and Auto-Dialer are independent output functions triggered by Threshold Monitor events, each responsible for one physical actuation (siren/alarm, selected lights, and dialling the owner's programmed numbers in sequence until one is answered or the list is exhausted).