NivaarExam PrepOfficial exam papers ↗

25-Comp-A6 Software Engineering · December 2014

Question 2 of 10: Object-Oriented Software Design

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

Notes on this paper

National Exams — December 2014 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: ten questions, candidates answer any six (all questions equal weight — each question carries 20 marks, so the paper is marked out of 120; only the first six questions as they appear in the answer book are marked). All ten questions are solved below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, real-time systems, software testing, configuration management, dependable/critical systems, reliability engineering, component-based software engineering; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing/quality coverage; IEEE/ISO 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.

Question 2: Object-Oriented Software Design (20 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.

Identifying the Objects

Applying the standard object-identification heuristic of extracting candidate objects from the nouns of the problem description (destination, menu, credit card, PIN, ticket, transaction) and merging those that are really the same concept viewed twice gives the following object model, with a coordinating TicketMachine object driving the interaction as an internal state machine.

TicketMachine- state- selectedDestination+ start(), + selectDestination(d)+ readCard(), + readPin(pin)+ issueTicket()DestinationMenu- destinations[]- fares[]+ display(), + fareFor(d)CreditCardValidator- cardNumber, - pin+ checkValidity()+ chargeAccount(amount)Ticket- destination, - fare+ print()CreditCardCompany(external system)display / selectread card / PINissueTicket()verify / charge (network)Fig. Q2 — object model for the automated ticket-issuing system
Fig. Q2 — object model for the automated ticket-issuing system; TicketMachine coordinates the interaction, delegating validation to CreditCardValidator and printing to Ticket.

Object Responsibilities and Behaviour

TicketMachine is the coordinating object: it holds the current interaction state (idle → destination-selection → card-read → PIN-entry → validating → issuing) and drives the sequence of operations described in the question exactly, so that the front-panel flow is owned by one object rather than scattered across the others. DestinationMenu holds the list of sellable destinations and their fares and is responsible only for displaying them and reporting the fare once one is selected — it knows nothing about payment. CreditCardValidator encapsulates everything to do with the card: it holds the card number and PIN entered for the current transaction, and its checkValidity() and chargeAccount(amount) operations are the only place in the system that talks to the external CreditCardCompany system, over whatever network protocol that requires. Ticket is created once the destination is known and the transaction is validated, holds the destination and fare it was issued for, and knows how to print() itself; keeping it a separate object (rather than a field on TicketMachine) means a printed ticket's data outlives the transaction that created it, which matters if the machine needs to reprint or log issued tickets.

Check
Assumptions made explicit for this design: PIN validation happens together with card validity checking in a single round-trip to CreditCardCompany (the question does not say the PIN is checked locally, and a magnetic-stripe card of this era carries no PIN verification data itself); the fare is looked up from the DestinationMenu at the time of selection and is fixed for that transaction even if the fare table changes before the ticket is actually issued; and if validation fails at either the card or the PIN step, TicketMachine returns to the idle state and returns the card, charging nothing — the question describes only the success path, so the failure path is added as a reasonable inference.