19-Soft-A3 Software Design · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, 04-Soft-A3 Software Design — May 2019. Closed-book exam, 3 hours, two double-sided reference sheets allowed, no calculator. Six questions constitute the exam paper; candidates answer five of the six, with the first five as they appear in the answer book marked, and each question and each sub-question carries equal value. Every question is answered in full below so this solution serves as a complete study resource for the whole bank.
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.
In function-oriented design, the top-level AddressBookMain module calls each of the five operations the requirements demand as separate functions, and all five functions read and write the SAME shared data structure — there is no per-function private copy of the contact data.
AddressBookMain calls AddContact, DeleteContact, ModifyContact, SaveContacts and LoadContacts; every one of those five functions reads and/or writes the single shared ContactList[] array of Contact records (name, phone, email, address).The relationship between the functions and the data structure is global sharing through a common data area: AddContact and DeleteContact both write to ContactList[], ModifyContact both reads and writes it, and SaveContacts/LoadContacts read/write it respectively while translating to and from the persisted file format. Because the data structure is external to any one function, every function that touches it must independently maintain any invariant the structure requires (e.g. no duplicate contact names) — there is no single owner enforcing it, which is the central weakness function-oriented design has relative to the object-oriented alternative in part (b).
The OO design for the same application uses two distinct hierarchies, each answering a different question.
Contact (common attributes: name, phone, email, address) is specialised by PersonalContact (adds birthday, relationship) and BusinessContact (adds company, jobTitle) — both are-a Contact.myAddressBook : AddressBook object CONTAINS zero-or-more Contact objects (contact1, contact2, ...) — the diamond marks the whole-to-part containment relationship.The class hierarchy answers "what kind of thing is this" — it captures that a PersonalContact IS-A Contact and therefore automatically has every attribute and method the base Contact class defines, without re-declaring them, and it lets code written against the base Contact type work correctly on either subtype (polymorphism). The object hierarchy answers a completely different question, "what is this made of" — it captures that a specific AddressBook instance HAS-A collection of Contact instances, with a 1-to-many multiplicity, and that the address book owns the lifetime of its contained contacts (deleting the address book deletes its contacts). The two hierarchies are independent: which subclass a given Contact object belongs to (inheritance) has nothing to do with which AddressBook object currently contains it (aggregation), and both are needed to fully specify the OO design.
The function-oriented design in part (a) has the advantage of being simple to trace — a call graph shows exactly which function calls which, and there is exactly one shared data structure to reason about — which suits small, stable, algorithm-centric programs well. Its central disadvantage, visible directly in part (a)'s diagram, is that the shared ContactList[] data structure has no single owner enforcing its invariants: any of the five functions can corrupt it, and adding a new function that also needs contact data means giving it unrestricted access to the same shared structure, which is exactly the low-cohesion/high-coupling problem that Question 5(b) identified as undesirable. The object-oriented design in part (b) has the advantage that the Contact class owns and encapsulates its own data — no external function can corrupt a Contact's invariants except through its own methods — and the inheritance hierarchy lets PersonalContact and BusinessContact share the common Contact behaviour without duplicating it, so extending the system with a new contact type is a matter of adding one new subclass rather than modifying five existing functions. Its disadvantage is added structural complexity up front (two hierarchies to design instead of one call tree) and the risk of inheritance being overused for problems that do not actually have a natural is-a relationship. For a personal address book that is expected to grow (new contact types, new operations), the OO design's stronger encapsulation and easier extensibility in part (b) make it the better long-term choice; for a small, fixed, one-off utility, the function-oriented design's simplicity in part (a) may be perfectly adequate.
A real address book product that later needs to add a third contact type (e.g. OrganizationContact for a shared company line) demonstrates the difference starkly: the OO design adds one new subclass of Contact and is done, while the function-oriented design would require auditing and modifying every one of the five functions that touch ContactList[] to handle the new case correctly.