NivaarExam PrepOfficial exam papers ↗

19-Soft-A7 Software Development Process · May 2016

Question 4 of 8: UML Modelling of the Pilot Take-off/Landing Emulator

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

Notes on this paper

National Exams, May 2016 — 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 3 asks for an incremental-model schedule using three teams, and Question 4 introduces a hypothetical pilot take-off/landing emulator (a pilot requests take-off or landing from the dispatcher, and the dispatcher records the request and allows the movement) 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 Pilot Take-off/Landing Emulator (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 Pilot, who requests a take-off or landing; the Dispatcher records the request and authorizes (or denies) the movement. Three use cases are modelled: Submit Movement Request (the pilot submits aircraft ID, request type — take-off or landing — and requested time), Record Request (the dispatcher logs the request as a tracked, uniquely-identified record), and Authorize Movement (the dispatcher checks runway/airspace conflicts and grants or denies clearance).

Pilot Emulator System — Use-Case DiagramPilot Emulator SystemPilotDispatcherSubmit MovementRequest(Take-off/Landing)RecordRequestAuthorizeMovement
Figure 1 — Use-case diagram: the Pilot participates in Submit Movement Request; the Dispatcher participates in Record Request and Authorize Movement.
Use caseEntry conditionExit conditionQuality requirement
Submit Movement RequestPilot's aircraft is at the gate/holding point (take-off) or inbound (landing) with an active radio/data link to the dispatcher.Request (aircraft ID, type, requested time) is transmitted and acknowledged by the system.Request must be acknowledged within 2 seconds of submission (availability & response-time requirement, safety-critical).
Record RequestA new, unacknowledged movement request is queued for the dispatcher.Request is logged with a unique ID and status "Pending", visible on the dispatcher console.No request may be silently dropped — every submitted request must result in exactly one logged record (reliability/data-integrity requirement).
Authorize MovementA logged request exists with status "Pending" and the runway/airspace conflict check has run.Dispatcher's decision (Cleared/Denied) is recorded and transmitted to the pilot; status updates to "Cleared" or "Denied".Decision must reach the pilot within 3 seconds of the dispatcher's input (safety-critical latency requirement).

Part b) — class diagram. Five classes capture the domain: Pilot and Dispatcher as the two actor-backed roles, MovementRequest as the central record created by a Pilot and managed by a Dispatcher, ClearanceDecision as the join entity recording the dispatcher's decision on a request, and Runway as the resource a decision references for availability.

Pilot Emulator System — Class DiagramPilot- pilotId- name- aircraftId+ submitRequest()Dispatcher- dispatcherId- name+ recordRequest()+ authorizeMovement()MovementRequest- requestId- aircraftId- type- requestedTime- status+ updateStatus()ClearanceDecision- decisionId- requestId- decision- decisionTimeRunway- runwayId- status+ checkAvailability()1*submits1*manages1*generates*1references
Figure 2 — Class diagram: one Pilot submits many MovementRequests; one Dispatcher manages many MovementRequests; each MovementRequest generates one or more ClearanceDecisions, each of which references exactly one Runway.

Part c) — sequence diagram. The interaction below traces one "request → record → authorize → notify" cycle across the classes from Part (b) (via a thin UI/controller/store split so the diagram matches how the classes actually collaborate at runtime): the Pilot submits the request through a RequestUI, which forwards it to a DispatchController (the object realising the Dispatcher's recordRequest()/authorizeMovement() behaviour), which persists it to the RequestStore (the MovementRequest/ClearanceDecision data), then returns the resulting clearance decision back up to the pilot.

Sequence Diagram — “Requesting Take-off/Landing Clearance”PilotRequestUIDispatchControllerRequestStoresubmitMovementRequest(aircraftId, type, time)recordRequest(details)persist(request, status=Pending)ackreturn clearanceDecisiondisplayClearanceDecision()
Figure 3 — Sequence diagram: the Pilot submits a movement request via RequestUI; DispatchController records it, persists it to RequestStore (acknowledged), evaluates and authorizes the movement, and returns the clearance decision, which RequestUI displays back to the Pilot.