Question 6 of 8

Question 6 (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) — requirements/design specifications: conventional vs. object-oriented.

Both traditions specify the same two concerns — what the system must do (requirements) and how it will be internally organized to do it (design) — but the conventional approach decomposes around processes acting on shared data, while the object-oriented approach decomposes around objects that own their data and expose behaviour, which is why their respective diagram sets look so different even though they answer the same underlying questions.

Part (b) — the purpose of design patterns in OO design. A design pattern is a named, reusable, general solution to a recurring design problem within a given context — it captures proven object-oriented structure (which classes exist, how they collaborate) without dictating the specific classes of any one application. Design patterns serve several purposes: they let a team apply a design solution already known to work well (avoiding "reinventing" a flawed approach to a well-understood problem), they provide a shared vocabulary that makes design discussion and documentation far more compact ("use an Observer here" communicates an entire collaboration structure in two words), and, most importantly for design quality, most patterns exist specifically to promote loose coupling and high cohesion — e.g., the Observer pattern decouples a subject from the specific observers reacting to its state changes, and the Strategy pattern decouples an algorithm's clients from the algorithm's own implementation, both making the design easier to extend and maintain (directly supporting the maintainability discussion in Questions 1b and 4c).

Part (c) — component-based design and test specifications. Component-based design decomposes a system into components with well-defined interfaces (the operations and data a component exposes, independent of its internal implementation). This decomposition maps directly onto test specifications:

1. Interface-driven unit test cases. Because each component's interface explicitly enumerates its operations, pre/post-conditions, and exchanged data, a unit test specification can be derived almost mechanically from the interface itself — one or more test cases per operation, exercising valid inputs, boundary inputs, and invalid/error inputs against the interface's documented contract, without needing to know the component's internal implementation.
2. Integration test cases from component collaborations. The design's component diagram documents which components depend on which others through which interfaces; each such dependency becomes an integration test case verifying that the calling component correctly invokes the provided component's interface and correctly handles the results (including documented error/exception conditions).
3. Independent, parallel test development. Because interfaces are specified before (or concurrently with) implementation, test specifications for a component can be written and even automated as soon as its interface is fixed, in parallel with that component's own implementation — and a stub/mock implementing the same interface lets a dependent component's tests run before the real component exists.

In short, component-based design's defining property — a stable, explicit interface separating "what a component does" from "how it does it" — is exactly what test-specification derivation needs: the interface alone, without implementation detail, is sufficient to write a complete black-box test specification.