Function-oriented Design: 25-Comp-A6 Software Engineering, December 2013, Q3

Question 3: Function-oriented 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.

High-Level Function-Oriented Design

The date-book decomposes into an interaction function, a data-integrity function, a scheduling function, persistent storage, and a background notification function — a straightforward pipeline from "user enters an appointment" through to "system reminds the user of it."

Fig. Q3 — data-flow design of the automatic date-book system.

The User Interface function accepts new/edited appointment entries and answers queries (e.g. "show today's appointments," "show next week"). Every candidate entry first passes through the Appointment Validator, which checks it for basic integrity — a valid date, a valid time, a non-negative duration, and a non-empty description — before it is allowed further into the system. A validated entry then passes to the Scheduler / Conflict Check function, which compares the candidate's date/time/duration window against every appointment already held in the Appointment Store for that day and flags an overlap back to the user (who may still choose to accept a double-booking). Accepted entries are written to the Appointment Store, which is the single persistent record of all appointments and answers the UI's query requests directly. Independently of user interaction, the Reminder / Alarm Notifier runs continuously (or on a periodic timer) scanning the store for appointments whose reminder time has arrived and raises an alert to the user.

Check — assumptions

Single-user, single-device system (no networking or multi-user concurrent access, consistent with an early personal electronic organizer). Each appointment record holds date, start time, duration, a text description, and an optional reminder lead-time. Conflict checking flags but does not forbid an overlapping entry, since a user may deliberately double-book (e.g. a tentative appointment). The notifier is assumed to poll the store at a fine enough interval (e.g. once per minute) that no reminder is missed by more than that interval.

Concept & Theory: Separating Validation, Business Logic and Storage

Topic: a general structured-design pattern — validate at the boundary, apply domain logic next, persist last, and let a separate background function handle time-driven behaviour.
Key relations: Validator (data integrity) → Scheduler (domain rule: conflict detection) → Store (persistence) → Notifier (time-triggered side function reading the same store).
Why this works: separating "is this data well-formed" from "is this data acceptable under the domain rules" from "how is it persisted" keeps each function narrowly cohesive and lets any one of them change independently — e.g. adding a recurring-appointment rule only touches the Scheduler, not the Validator or Store.
Common pitfall: folding conflict-checking directly into the User Interface function, which then has to be re-tested for every scheduling-rule change and cannot be reused if a second interface (e.g. a remote sync client) is later added.
Source: Sommerville, Software Engineering, ch. "Software Design."

Question 3 of 9: Function-oriented Design

Question 3: Function-oriented Design (20 marks)

High-Level Function-Oriented Design