25-Comp-A6 Software Engineering · December 2018
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2018 — 17-Comp-A6 Software Engineering. Three-hour, closed-book, no-calculator exam. 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, requirements engineering, software testing, software reuse, software reliability, client-server architectures, software verification and validation; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design/reuse vocabulary.
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.
Cohesion is the degree to which the responsibilities inside a single module are functionally related and work together toward one well-defined purpose — a highly cohesive module "does one thing." Coupling is the degree of interdependence between separate modules: how much one module must know about another's internal representation, control flow or interface details in order to work correctly. Adaptability (maintainability/flexibility) is the ease with which a system can accommodate changes — in requirements, in the operating environment, or in the platform — without extensive, wide-reaching rework.
Maximizing cohesion and minimizing coupling both serve the same underlying goal: localizing the effect of change. A highly cohesive module is small in scope and purpose, so it is easy to understand, test and modify in isolation, and any change driven by a new requirement about that one responsibility touches only that one module. Low coupling means modules interact only through narrow, well-defined interfaces rather than through shared internal state or implicit assumptions about each other's implementation, so a module can be modified, replaced, or even completely re-implemented without forcing changes on the modules that use it. Systems built with high cohesion and low coupling therefore confine the "blast radius" of any single change to a small, identifiable part of the system, which is precisely what makes a system easy (cheap) to maintain over its lifetime.
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.
