19-Soft-A3 Software Design · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, 04-Soft-A3 Software Design — May 2014. Open-book, 3-hour exam. Each question carries 10 marks, split 3/3/4 or similar across its three parts.
Reference texts: Sommerville, Software Engineering (10th ed.); Pressman, Software Engineering: A Practitioner's Approach (9th ed.); Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software; ISO/IEC 25010, Systems and Software Quality Requirements and Evaluation (SQuaRE); SWEBOK v4.
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.
Strictly, no: a UML use case diagram is a product of requirements analysis, not of design — it captures what the system must do from an external actor's point of view, without saying anything about how that behaviour will be structured internally, which is precisely the boundary between requirements and design. Its relationship to software design is nonetheless close and essential: each use case identified during requirements analysis becomes an input that design must satisfy, and it is elaborated during design into the concrete classes, components and interactions that will realise it (for instance, a "Retrieve Contact" use case is realised in design by the class diagram and sequence diagram below). It is also common for a use case diagram to be refined during design — splitting a coarse use case into finer include/extend relationships as the design team clarifies exactly how the system will deliver it — so the diagram sits at the requirements/design boundary, feeding design and occasionally being revised by it, without itself being an output the design stage is responsible for producing.
The Contact class holds one person's data (name, phone number, email, mailing address) and the small set of accessor operations a caller needs to read or update that data. The AddressBook class owns the collection of contacts and exposes exactly the four operations the requirement specifies — addContact() to enter and store a new contact, retrieveContact() to look one up by name, and removeContact() to delete one — keeping the storage collection itself private inside AddressBook so no external code can bypass these operations to manipulate it directly.
The diagram shows the User invoking retrieveContact(name) on the UI, which delegates to findContact(name) on the AddressBook object; AddressBook searches its internal collection, asks the matching Contact object for its getDetails(), and the details are returned back up the call chain — from Contact to AddressBook to the UI — until the UI finally displays the retrieved contact to the User. Each dashed return arrow corresponds to a value handed back from a completed call, distinguishing it from the solid arrows that represent the original invocations.
Drawing the class diagram before the sequence diagram is standard practice precisely because the sequence diagram cannot be drawn correctly until the classes, and the operations each one exposes, already exist to be called — the class diagram in (b) is what makes the message names in (c) meaningful rather than invented.
