Question 2 of 8: Software Design

Question 2: Software Design (a) 6, (b) 7, (c) 7 — 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) Object-Oriented vs. Function-Oriented Design

Function-oriented design decomposes a system top-down into a hierarchy of functions (procedures) that transform input data into output data, typically documented as data-flow diagrams and structure charts. Data is treated as a separate, often shared or global, resource that flows between functions; the functions themselves are the primary unit of decomposition and reuse. Object-oriented design instead decomposes the system into objects, each of which bundles together a piece of state (its attributes) and the operations that are allowed to act on that state, and objects collaborate by sending each other messages (calling one another's operations) rather than by all reaching into a common pool of data.

The practical consequence is that function-oriented systems are easy to reason about for simple, well-defined data transformations (batch reports, numerical pipelines) but scale poorly as systems grow: because state is shared, a change to a data structure's representation can ripple through every function that touches it, producing the classic "change amplification" problem. Object-oriented design's information hiding — each object exposes only an interface and hides its internal representation — localizes the impact of a representation change to the object itself, and its support for inheritance and polymorphism gives a natural mechanism for extending and reusing behaviour. The trade-off is that object-oriented designs generally require more up-front design effort to identify the right objects and their responsibilities, and the extra layer of indirection (message passing between many small objects) can make the control flow of the finished system harder to trace by eye than a single top-down function hierarchy.

(b) Function-Oriented Design of the Date-Book

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."

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.

(c) Object-Oriented Design of the Same Date-Book

Applying the standard object-oriented design heuristic of extracting candidate objects from the nouns implicit in the problem description ("appointment", "date book", "reminder", "user") and separating what varies (how a reminder is actually delivered) from what stays fixed (the appointment record and the scheduling rules), gives the following object model:

User owns exactly one DateBook and represents the person the electronic date-book is kept for, including the time zone their appointment times are interpreted in. DateBook is the central aggregate: it holds the user's collection of Appointment objects, exposes add(appt) (which checks the new appointment against every existing one via conflictsWith and returns any clash to the caller as a warning before storing it), and answers queries such as "what is scheduled on date d" and "which appointments are due for a reminder right now" — the latter delegated to each Appointment's own knowledge of its date, time, and configured lead time. Appointment is a simple, self-contained record (date, start/end time, description, and how far in advance the user wants to be reminded) plus the one piece of behaviour needed to keep the DateBook consistent, conflictsWith(other), which compares two time ranges on the same date for overlap.

ReminderScheduler is a background object that is woken periodically (its tick(now) operation) purely to ask the DateBook which appointments have become due, and for each one calls fire(appt) on a Notifier. Notifier is deliberately modelled as an abstract interface rather than a concrete class, with concrete subclasses AudibleAlert and PopupDisplay supplying the actual notification mechanism — the ReminderScheduler is written once against the abstract notify(appt) operation and never needs to change when a new notification channel (e.g. an email or SMS reminder) is added as a further Notifier subclass. PersistentStore is a further abstract boundary, exposing only save(dateBook) and load(user), so that the choice of physical storage medium (a local file, a removable card, a cloud-synced database) is confined to one object and never leaks into DateBook, Appointment, or ReminderScheduler.

Contrasting parts (b) and (c) on the same system makes the difference from part (a) concrete: the function-oriented version routes every kind of data (appointments, thresholds-of-time, queries) through a single shared Appointment Store that every function reads and writes directly, so a change to how an appointment is represented would have to be re-checked against all five functions; the object-oriented version instead confines the appointment representation to the Appointment class itself and confines the notification/storage mechanism behind the abstract Notifier/PersistentStore interfaces, so the same kind of change touches exactly one class.