Question 2 of 8: Software Design

Question 2: 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.

Given. The Insulin Delivery System (IDS) scenario above, with the explicit instruction to use a function-oriented (structured) design approach rather than an object-oriented one.

Find. A function-oriented design for the IDS: a data-flow decomposition of the system into its constituent processes and data stores, plus the top-down module (structure-chart) hierarchy this design implies.

Approach. Function-oriented design decomposes a system top-down into functions/processes connected by the data that flows between them (rather than by identifying real-world objects, as Question 3 does for a different system) — the standard notation for the first step is a Data-Flow Diagram (DFD), which is then refined into a structure chart showing the call hierarchy of the modules that implement each process.

Data-Flow Decomposition

Four processes carry the main control loop, each triggered ultimately by a periodic Timer so the whole loop runs at a fixed sampling rate rather than only in response to an external event. Sensor Interface reads the raw micro-sensor signal on each tick and packages it for analysis. Sugar-Level Analysis converts that raw signal into a calibrated blood-sugar reading (applying the sensor's calibration curve). Dose Computation compares the calibrated reading against the target range held in the Patient Profile data store and computes the insulin quantity required to move the reading toward that target. Pump Actuation converts the computed dose into the drive signal that operates the miniaturized pump and needle. A fifth process, Safety Monitor, is not part of the source description's control loop but is fed the sugar-level reading and the computed dose in parallel with the main path and raises an Alarm whenever either value falls outside a safe range or the two are inconsistent with each other.

Top-Down Module Hierarchy (Structure Chart)

Refining the data-flow diagram into a callable module hierarchy under a single top-level controller gives:

• IDS_Controller (top-level, invoked once per timer tick)
  • ReadSensor() — implements Sensor Interface
  • ComputeSugarLevel(rawSignal) — implements Sugar-Level Analysis
  • ComputeInsulinDose(sugarLevel, patientProfile) — implements Dose Computation, reads Patient Profile
  • ActivatePump(dose) — implements Pump Actuation
  • CheckSafety(sugarLevel, dose) — implements Safety Monitor, calls RaiseAlarm(reason) on failure

Each module has a single, narrow responsibility and communicates with its caller only through its parameters and return value (no shared global state), which is the structured-design goal of high cohesion within each module and low coupling between them.