Question 7 of 11: Identifying Classes for a Walk-In Clinic System

Question 7: Identifying Classes for a Walk-In Clinic System (10 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) Classes and Responsibilities

Reading the description for nouns that carry distinct data and behaviour yields the following classes. Patient holds a name and medicare number and is responsible for signing in online and requesting its own position in the queue. QueueEntry represents one patient's place in the waiting line and is responsible for recording that patient's arrival status and urgency, so the queue can be reordered without touching the Patient record itself. WaitingQueue is responsible for maintaining the ordered collection of QueueEntry objects, computing a given patient's position for the "view my position" feature, supporting removal on arrival, completion or a missed appointment, and supporting reordering by urgency. Secretary is responsible for marking a patient's arrival, removing entries from the queue, reordering the queue, and assigning patients to doctors. Doctor is responsible for viewing the patients currently assigned to them. StaffAccount (a shared base responsibility for Secretary and Doctor) is responsible for authenticating staff before any queue-modifying or full-queue-viewing operation is permitted, since the description requires authentication for both roles but not for a patient viewing only their own position.

(b) Actors, Data Entities and Linking Classes

The actors — the external roles that interact with the system — are the Patient, the Secretary and the Doctor. The data entities — the persistent information the system stores — are the patient's registration details (name, medicare number) and each patient's queue-position record (arrival status, urgency, assigned doctor). The classes needed to link the actors to those data entities are WaitingQueue, which links every registered Patient entity to a position and lets both the patient (a restricted, position-only view) and the staff (a full view) query it appropriately, and StaffAccount (authentication/session), which links the Secretary and Doctor actors to the system by verifying their identity before granting the queue-modification and full-visibility operations the description reserves for staff.

(c) Class Hierarchy vs. Object Hierarchy

A class (inheritance) hierarchy is a compile-time relationship between classes, in which a subclass specialises a more general superclass, inheriting its attributes and operations and adding or overriding its own. In the clinic system, Secretary and Doctor could both be defined as subclasses of an abstract StaffAccount class that provides a shared authenticate() and viewFullQueue() operation, with Secretary adding its own assignDoctor(patient) and Doctor adding its own viewAssignedPatients() — an "is-a" relationship (a Secretary is a kind of StaffAccount). An object (aggregation) hierarchy, by contrast, is a runtime relationship between object instances, in which one object owns or is composed of other objects — a "has-a"/"part-of" relationship. In the same system, a single WaitingQueue object aggregates many QueueEntry objects at runtime, and each QueueEntry object is, in turn, associated with one Patient object; this hierarchy of composed instances exists independently of, and at a different level from, the class-inheritance hierarchy of Secretary and Doctor above.

Practical Application

Building the StaffAccount inheritance hierarchy first lets the authentication logic required by the description be written once and reused by both Secretary and Doctor, while the separate WaitingQueue–QueueEntry aggregation is what actually answers the "how many patients before me" query a patient asks at runtime.