25-Comp-A6 Software Engineering · December 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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 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.
Function-oriented design decomposes a system top-down into a hierarchy of functions (procedures) that transform input data into output data, typically documented as data-flow diagrams and structure charts. Data is treated as a separate, often shared or global, resource that flows between functions; the functions themselves are the primary unit of decomposition and reuse. Object-oriented design instead decomposes the system into objects, each of which bundles together a piece of state (its attributes) and the operations that are allowed to act on that state, and objects collaborate by sending each other messages (calling one another's operations) rather than by all reaching into a common pool of data.
The practical consequence is that function-oriented systems are easy to reason about for simple, well-defined data transformations (batch reports, numerical pipelines) but scale poorly as systems grow: because state is shared, a change to a data structure's representation can ripple through every function that touches it, producing the classic "change amplification" problem. Object-oriented design's information hiding — each object exposes only an interface and hides its internal representation — localizes the impact of a representation change to the object itself, and its support for inheritance and polymorphism gives a natural mechanism for extending and reusing behaviour. The trade-off is that object-oriented designs generally require more up-front design effort to identify the right objects and their responsibilities, and the extra layer of indirection (message passing between many small objects) can make the control flow of the finished system harder to trace by eye than a single top-down function hierarchy.
Following structured/function-oriented convention, the system is decomposed into five numbered processes connected by labelled data flows to two external entities (the Driver and the Credit Card Company); no shared object state is used — each process reads its inputs, does its transformation, and passes its outputs on.
Process 1 reads the inserted card and opens a session. Process 2 sends the card number to the credit card company (dashed flows) and, on approval, receives back an authorized fuel limit; on decline it hands control straight to process 5, which ejects the card with no fuel dispensed. Process 3 is the tight control loop that runs while fuel flows: it monitors the flow meter against the authorized limit and the hose-holster sensor, dispensing fuel until either condition ends delivery. Process 4 converts litres dispensed into a cost and sends the debit request to the credit card company. Process 5 is common to both the decline path and the normal-completion path, returning the card (and, on completion, a receipt) to the driver.
