NivaarExam PrepOfficial exam papers ↗

19-Soft-A7 Software Development Process · December 2013

Question 4 of 8: UML Modelling of an Information Search & Delivery Tool

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

Notes on this paper

National Exams, December 2013 — 04-Soft-A7, Software Process (open book, 3 hours). Notes on the paper: FIVE of the eight questions constitute a complete paper (the first five as answered in the answer book are marked, each of equal value); this solution answers all eight as a full study resource. Most questions call for essay-format answers; Question 4 introduces a hypothetical information search-and-delivery tool (delivering electronic documents from a repository to a user by keyword/preference — e.g. a product catalog or classified-ads listing) that Question 5 and parts of Questions 7 build on.

Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 2 (Software Processes), Ch. 3 (Agile Software Development), Ch. 5 (System Modeling), Ch. 8–9 (Testing), Ch. 22–23 (Project Management, Configuration Management), Ch. 9 (Software Evolution/Maintenance); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 2–3 (Process Models, Agile), Ch. 23–24 (Project Management, Risk Management), Ch. 29 (Function-Point sizing), Ch. 22 (SQA), Ch. 24 (Software Configuration Management); SWEBOK v4 (Software Engineering Process, Software Configuration Management, Software Maintenance KAs).

Question 4: UML Modelling of an Information Search & Delivery Tool (10 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.

Part a) — use-case diagram. The primary actor is the User who searches for and receives documents; an external Document Repository supplies the underlying content the tool indexes and delivers against. Three use cases are modelled exactly as specified: Set User Preferences (the user records the keywords/categories they are interested in), Search Documents (the user issues a keyword search against the repository, informed by their stored preferences), and Select & Deliver Document (the user picks a result from the search and the system delivers the electronic document to them).

Document Search & Delivery Tool — Use-Case DiagramSearch & Delivery systemUserDocumentRepository(ext.)Set UserPreferencesSearchDocumentsSelect & DeliverDocument
Figure 1 — Use-case diagram: the User actor participates in all three required use cases; the external Document Repository supplies the content that Search and Select & Deliver both depend on.

Part b) — sequence diagram for “Setting the User's Preferences”. The flow is deliberately simple — a thin UI layer collects the user's keywords/categories, a domain-level PreferenceManager validates and orchestrates the save, and a PreferenceStore persists the data — separating presentation, business logic and persistence as three distinct participants (a standard layered-architecture decomposition, echoing the layered/deployment structures used for similar systems elsewhere in this subject).

Sequence Diagram — “Setting the User's Preferences”UserPreferencesUIPreferenceManagerPreferenceStoreenterPreferences(keywords, categories)savePreferences(userId, prefs)persist(prefs)ackreturn statusdisplayConfirmation()
Figure 2 — Sequence diagram for Setting the User's Preferences: the User's input is validated/orchestrated by PreferenceManager and persisted by PreferenceStore, with acknowledgements returned along the same path (dashed arrows) before the UI confirms success to the User.

Part c) — would agile change specifications or just focus on implementation? Under agile development the answer is both, but not simultaneously frozen — specifications are changed incrementally, in parallel with implementation, rather than being frozen up front (Waterfall) or ignored in favour of pure coding. Concretely: the product backlog (the living specification) is refined and re-prioritised before every sprint based on what was learned from the previous increment's demo and user feedback, while each sprint's implementation work targets only the currently-refined slice of that backlog. This is a deliberate middle ground: agile does not "just focus on implementation" and skip specification (an unspecified feature cannot be correctly built or accepted), but it also does not attempt Waterfall's single, complete up-front specification for a novel, exploratory product like this one, where user preference/search behaviour is exactly the kind of requirement best discovered by observing real usage of an early increment.