NivaarExam PrepOfficial exam papers ↗

25-Comp-A6 Software Engineering · December 2015

Question 3 of 8: Object-Oriented Design

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams — December 2015 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: eight questions, candidates answer any five of the eight (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All eight questions are solved below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software testing, requirements engineering, dependability and critical systems, configuration management, project/risk management; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Leveson, Safeware: System Safety and Computers — hazard analysis and fault tree analysis for safety-critical software (applied to the Question 7 medical-device case).

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

Identifying the Objects

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- name- timeZone+ ownsDateBook()DateBook- owner- appointments[]+ add(appt)+ appointmentsOn(date)+ dueForReminder(now)Appointment- date, start, end- description- leadTime+ conflictsWith(a)PersistentStore+ save(dateBook)+ load(user)ReminderScheduler+ tick(now)+ fire(appt)Notifier+ notify(appt)AudibleAlertPopupDisplay11..*usespollsfire()Fig. Q3 — object model for the automatic date-book system (open triangles = generalisation of Notifier)
Fig. Q3 — object model for the automatic date-book system; Notifier is an abstract interface specialised by concrete notification channels.

Object Responsibilities and Behaviour

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 before accepting 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 — this is the same information-hiding/inheritance technique examined in Question 4: 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.

Check
Assumptions made: a DateBook belongs to exactly one User (no shared/team calendars); "automatic" is interpreted as the system autonomously polling for due reminders (ReminderScheduler.tick) rather than requiring the user to manually check for them; and a conflicting appointment is rejected at the point of add rather than silently double-booked, since the question asks for a design that keeps track of appointments, which implies detecting double-booking as a core responsibility.