NivaarExam PrepOfficial exam papers ↗

19-Soft-A7 Software Development Process · December 2014

Question 4 of 8: UML Modelling of the Emergency Reporting System

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

Notes on this paper

National Exams, December 2014 — 04-Soft-A7, Software Process (open book, 3 hours). Notes on the paper: FIVE of the eight questions constitute a complete paper (the first five as answered in the answer book are marked, each of equal value); this solution answers all eight as a full study resource. Most questions call for short, bulleted written answers; Question 4 introduces a hypothetical emergency reporting system (a field officer reports an emergency, a dispatcher records the issue and allocates resources) that Question 5 builds on.

Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Processes), Ch. 3 (Agile Software Development), Ch. 5 (System Modeling), Ch. 8–9 (Testing), Ch. 22–23 (Project Management, Configuration Management), Ch. 9 (Software Evolution/Maintenance); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2–3 (Process Models, Agile), Ch. 23–24 (Project Management, Risk Management), Ch. 29 (Function-Point sizing), Ch. 22 (SQA), Ch. 24 (Software Configuration Management); SWEBOK v4 (Software Engineering Process, Software Configuration Management, Software Maintenance KAs).

Question 4: UML Modelling of the Emergency Reporting 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.

Part a) — use-case diagram, entry/exit conditions, and quality requirements. The primary actor is the Field Officer, who detects and reports an emergency; the Dispatcher records the incident and allocates resources to respond. Three use cases are modelled: Report Emergency (the field officer submits location, description and severity), Record Incident (the dispatcher logs the report as a tracked incident), and Allocate Resources (the dispatcher assigns available personnel/equipment to the incident).

Emergency Reporting System — Use-Case DiagramEmergency Reporting SystemFieldOfficerDispatcherReportEmergencyRecordIncidentAllocateResources
Figure 1 — Use-case diagram: the Field Officer participates in Report Emergency; the Dispatcher participates in Record Incident and Allocate Resources.
Use caseEntry conditionExit conditionQuality requirement
Report EmergencyField officer observes/is notified of an emergency and is logged into the reporting device.Report (location, description, severity, timestamp) is transmitted and acknowledged by the system.Report must reach the dispatcher within 5 seconds of submission (availability & response-time requirement).
Record IncidentA new, unacknowledged report is queued for the dispatcher.Incident is created with a unique ID and status "Open", visible on the dispatcher console.No report may be silently dropped — every submitted report must result in exactly one recorded incident (reliability/data-integrity requirement).
Allocate ResourcesAn incident exists with status "Open" and at least one resource type is required.One or more resources are assigned, incident status changes to "Assigned", and the field officer receives confirmation.Resource-availability lookup must complete within 2 seconds so the dispatcher is never blocked waiting during a live incident (performance requirement).

Part b) — class diagram. Five classes capture the domain: FieldOfficer and Dispatcher as the two actor-backed roles, EmergencyReport as the central record created by a Field Officer and managed by a Dispatcher, ResourceAssignment as the join entity linking a report to the Resource(s) allocated to it.

Emergency Reporting System — Class DiagramFieldOfficer- officerId- name- badgeNo+ reportEmergency()Dispatcher- dispatcherId- name+ recordIncident()+ allocateResource()EmergencyReport- reportId- location- description- timestamp- status+ updateStatus()ResourceAssignment- assignmentId- reportId- resourceId- assignedTimeResource- resourceId- type- status+ dispatch()1*submits1*manages1*generates*1assigns
Figure 2 — Class diagram: one FieldOfficer submits many EmergencyReports; one Dispatcher manages many EmergencyReports; each EmergencyReport generates one or more ResourceAssignments, each of which assigns exactly one Resource.

Part c) — would agile change specifications or just focus on implementation? Both, but incrementally rather than frozen up front. Under agile, the product backlog (living specification) is refined before every sprint based on feedback from the previous increment, while each sprint's implementation targets only the currently-refined slice; agile does not "just focus on implementation" and skip specification (an unspecified emergency-handling rule cannot be correctly built or safely deployed), nor does it attempt Waterfall's single, complete up-front specification. For a system like this, where the exact resource-allocation rules and quality thresholds (Part a's table) are best refined by observing real dispatcher usage of an early increment, agile's incremental specification is a genuine advantage — but because misclassifying or losing a real emergency report has real safety consequences, the core reporting/logging behaviour still warrants early, careful specification and validation (e.g. via Question 6's testing activities) rather than being left entirely to "discover as we build."