Question 9 of 10: Component-Based Software

Question 9: Component-Based Software (a) 5, (b) 5, (c) 10 — 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.

(a) Component-Based Software Engineering

Component-Based Software Engineering (CBSE) is an approach to building systems by assembling independent, pre-existing, reusable software components rather than developing every part of the system from scratch. A component is a self-contained unit of functionality that publishes an explicit interface, can be deployed and composed independently of the internal implementation of any other component, and is designed from the outset with reuse across more than one system in mind (as opposed to an ordinary object or module, which is typically designed for use only within the system it was written for). CBSE shifts the engineering effort from writing new code toward selecting, adapting, and integrating existing components against their published interfaces, which is what makes it possible to build large systems faster and with functionality that has already been independently exercised by prior use.

(b) Why "Requires" and "Provides" Interfaces Matter

A component's provides interface defines the services it makes available to other components, while its requires interface defines the services it assumes will be available from its environment in order to function — the two together are the component's complete external contract. Making both directions explicit matters because a component is meant to be deployed into systems its original developer never saw: if a component silently assumes some capability is present (an undocumented requires interface), an integrator has no way to know that assumption exists until the system fails at run time when the assumption turns out false, whereas an explicit requires interface lets the assumption be checked (and satisfied by a substitutable component) before deployment. Symmetrically, an explicit provides interface is what lets one component be swapped for another with a compatible interface without touching anything that uses it, which is the entire economic basis of component reuse and of a component marketplace. Without documenting both directions, "component-based" integration degenerates into read-the-source integration, which defeats the purpose of building from independently developed, black-box components in the first place.

(c) Interfaces for the Emergency Control Room Components

Following the CBSE convention of specifying each component purely by its provides and requires interfaces (never its internal implementation):

CallLoggingComponent provides logCall(caller, incidentType, time), called once per incoming call to create a permanent record, and getCallHistory(vehicleId), which answers "what calls has this vehicle been dispatched against" for later audit or reporting. It requires a TimeService (so log timestamps are independent of the calling component's own clock handling) and an IncidentStore to persist records to, neither of which it implements itself. VehicleDiscoveryComponent provides the single operation the question names, findNearestVehicle(postalCode, incidentType), returning the identifier of the nearest vehicle qualified to handle that incident type; it requires a GeocodingService to convert the postal code into coordinates it can do distance calculations against, and a VehicleTracker to obtain the current positions and availability status of vehicles of the requested type. Declaring the requires interfaces explicitly means either component can be deployed into a different control-room system that already has its own time/geocoding/tracking services, without either component needing to be rewritten — only the requires interface needs to be satisfied by whatever concrete service the new deployment provides.