Question 5 of 6: Modifiability, Cohesion/Coupling, and Decomposition

Question 5: Modifiability, Cohesion/Coupling, and Decomposition (equal value)

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) Modifiability and How Modularity Supports It

Modifiability is the quality attribute that measures how easily a software system can be changed — how little effort, time and risk of introducing new defects is involved in implementing a given change, whether that change is a bug fix, a new feature, or an adaptation to a new environment. As established in Question 2(b), it is a static (design-time) quality attribute: it cannot be measured by running the finished system, only assessed by making or estimating a representative change and observing how contained the resulting effort turns out to be. Modularity — dividing a system into separate, well-defined modules that interact only through defined interfaces — directly supports Modifiability because it localises the impact of a change: if each module is responsible for one clear piece of functionality, a change to a requirement almost always maps onto a change inside one module (or a small number of them), rather than rippling unpredictably across the whole system. For the address book, keeping contact-validation logic inside its own module means a change to the validation rule (for example, accepting international phone numbers) is confined entirely to that module and never touches the storage or presentation code — exactly the contained, low-effort change that a high-modifiability design is meant to achieve. This benefit is only realised, however, when the decomposition itself is good; a system split into modules along the wrong boundaries can be "modular" in name while remaining as hard to change as a monolith, which is why Question 5(c) below decomposes the address book along boundaries chosen specifically to isolate its likely axes of future change.

(b) Cohesion and Coupling

Cohesion measures how strongly related the responsibilities inside a single module are to one another; coupling measures how much one module depends on the internals of another. Strong cohesion means every element inside a module contributes to one single, well-defined purpose. Functional cohesion — where every element in the module works together to perform exactly one well-defined function (e.g. a module that does nothing but validate a phone number) — is the strongest form of cohesion, because there is no way to further separate its elements without breaking the one task apart; every statement inside it exists for the same reason. Loose (weak) coupling means a module depends on very little about another module's internals to work correctly. Data coupling — where two modules communicate only by passing simple data (parameters) through a well-defined interface, with neither depending on the other's internal structure — is weak coupling, because it is the minimum dependency two collaborating modules can have while still exchanging information: change the internal implementation of either module and, as long as the parameter data itself is unchanged, the other module is unaffected. We deliberately seek strong cohesion and weak coupling together because they compound: strong cohesion keeps each module easy to understand, test and reuse in isolation, while weak coupling means a change or defect inside one module cannot easily propagate into another, so their combination is exactly what makes a system easy to understand, test and modify piece by piece — the two central goals (Modifiability and Testability) that Question 5(a) already identified as central to design quality.

(c) Decomposing a Single-Module Address Book

The diagram below shows the initial single-module address book being decomposed into four separate modules, each responsible for one concern.

The purpose of this decomposition is precisely the cohesion/coupling argument made in part (b): the single-module version mixes screen-drawing code, validation logic, in-memory list handling and file I/O together, so every one of those four concerns has low cohesion with the others and any change (e.g. switching from a flat file to a database) risks touching code that also handles the UI. After decomposition, each of the four modules is internally cohesive (the Data Storage module does nothing but persist and retrieve records) and the modules interact only through narrow interfaces, giving weak coupling between them. The direct quality payoff is Modifiability (a storage-format change is now confined to the Data Storage module), Testability (each module can be unit-tested in isolation, e.g. testing Data Management's add/delete logic without any real file I/O), and Reusability (the Data Management module could be reused in a different application with a different UI).

Practical Application

A team that decomposes along these lines can hand the User Interface module to a front-end developer and the Data Storage module to a back-end developer working in parallel, each coding against the Application Logic module's interface rather than against each other's implementation — the same parallel-development benefit modularity delivers on every question in this paper.