Question 2 of 8: Software Design

Question 2: Software Design (a) 10, (b) 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) Cohesion, Coupling, Adaptability

Cohesion is the degree to which the responsibilities inside a single module are functionally related and work together toward one well-defined purpose — a highly cohesive module "does one thing." Coupling is the degree of interdependence between separate modules: how much one module must know about another's internal representation, control flow or interface details in order to work correctly. Adaptability (maintainability/flexibility) is the ease with which a system can accommodate changes — in requirements, in the operating environment, or in the platform — without extensive, wide-reaching rework.

Maximizing cohesion and minimizing coupling both serve the same underlying goal: localizing the effect of change. A highly cohesive module is small in scope and purpose, so it is easy to understand, test and modify in isolation, and any change driven by a new requirement about that one responsibility touches only that one module. Low coupling means modules interact only through narrow, well-defined interfaces rather than through shared internal state or implicit assumptions about each other's implementation, so a module can be modified, replaced, or even completely re-implemented without forcing changes on the modules that use it. Systems built with high cohesion and low coupling therefore confine the "blast radius" of any single change to a small, identifiable part of the system, which is precisely what makes a system easy (cheap) to maintain — i.e. more adaptable — over its lifetime.

(b) Function-Oriented Design of the Newspaper/Magazine Delivery System

A function-oriented decomposition partitions the system by what it does — a pipeline of functions transforming input data into output data via shared, centrally-held data stores — rather than by the objects it manipulates.

Process 1, Record Subscription/Vacation, is the data-entry function through which office staff maintain which households take which publications, on which delivery round, and any vacation periods during which delivery must pause; it writes directly into the shared data store and is the only process that updates household/subscription/vacation records. Process 2, Generate Daily Delivery List, runs once per delivery round each morning: it reads every subscription on that round, excludes any household currently on vacation, and prints the ordered list of newspapers/magazines to drop at each remaining address, which is handed to that round's delivery person. Process 3, Compute Daily Sales Summary, also reads the store once per day but aggregates in the opposite direction — per publication rather than per round — counting how many active (non-vacation) subscriptions of each newspaper are due that day across the whole town, to produce the "copies sold per newspaper per day" report. Process 4, Compute Monthly Bill, runs once a month per household: it sums that household's active subscriptions' charges over the billing period (again consulting vacation records, since a vacation suspends the delivery a bill would otherwise charge for) and produces a bill that is handed to Process 2 for inclusion with that household's first delivery of the new month.