NivaarExam PrepOfficial exam papers ↗

25-Comp-A6 Software Engineering · May 2014

Question 2 of 9: Object-Oriented Software Design

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

Notes on this paper

National Exams — May 2014 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: nine questions, candidates answer any five of the nine (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 nine questions are solved below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented design, formal methods, real-time systems, software testing, project management, critical/dependable systems, software quality, distributed systems; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing/quality coverage; IEEE 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.

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

Identifying the Objects

Applying the standard object-oriented heuristic of extracting candidate objects from the nouns of the problem description (diary, appointment, co-worker/user, time slot, request) and merging duplicates gives the following object model.

Person- name- workingHours+ freeSlotsOn(date)Diary- owner- entries[]+ freeSlots(date), + rearrange()DiaryEntry- startTime, endTime- kind (fixed/movable)+ overlaps(slot)MeetingRequest- participants[]- duration- dateRange+ findCommonSlot()+ negotiateReschedule()Appointment- slot, - participants[]RescheduleAgent+ proposeSwap(entry)11..*reads 2..*confirmsdelegates (no slot)Fig. Q2 — object model for the group diary and time-management system
Fig. Q2 — object model for the group diary/time-management system; MeetingRequest coordinates across each participant's Diary.

Object Responsibilities and Behaviour

Person represents a co-worker and holds their normal working hours (used to keep proposed slots inside working hours). Each Person owns exactly one Diary, an aggregate of DiaryEntry objects; a DiaryEntry is marked either fixed (cannot be moved — e.g. an external commitment) or movable (the owner is willing to reschedule it), which is the key attribute that later drives the rearrangement logic. When a group appointment is wanted, a MeetingRequest is created holding the list of participants, the desired duration, and an acceptable date range; its findCommonSlot() operation queries every participant's Diary for free slots and intersects them. If the intersection is non-empty, the earliest common slot is booked directly as an Appointment referencing that slot and the full participant list. If no common slot exists, negotiateReschedule() hands control to a RescheduleAgent, which examines each participant's movable DiaryEntries near the desired time and proposes swaps (proposeSwap(entry)) back to the affected user for confirmation, re-running findCommonSlot() once a movable entry has actually been relocated.

Check
Assumptions made explicit for this design: every DiaryEntry is tagged fixed/movable by its owner at creation time (the system never moves a fixed entry without being told it may); rearrangement is interactive and one entry at a time, per the question's "interacts with the user to rearrange his or her personal diary" wording, rather than an automatic multi-entry replan; and MeetingRequest treats a slot as common only if it falls within every participant's stated working hours, not merely inside a gap in their Diary.