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

Question 5: Modularity, Coupling/Cohesion and Decomposition (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.

(a) Modularity, Coupling and Cohesion

Modularity is the property of a software system being divided into a set of discrete, individually-named and separately-addressable units (modules), each with a clearly-defined responsibility and interface, that together compose the whole system. Modularity matters because it lets a large problem be attacked as a set of smaller, more manageable ones: a single module is small enough for one developer to understand, implement, test and later change without holding the entire system in mind at once. Modularity primarily supports maintainability (changes are localised to the module responsible for that concern), reusability (a well-bounded module can be reused in another context) and testability (a module can be tested in isolation from the rest of the system). Cohesion measures how strongly the responsibilities within a single module relate to one another — a highly cohesive module does one clear thing. Coupling measures how strongly one module depends on the internals of another — low coupling means a module can change without forcing changes elsewhere. Good modular design deliberately maximises cohesion within each module while minimising coupling between modules.

(b) Modules in Function-Oriented vs. Object-Oriented Systems

In a function-oriented system, the module is typically a source file or a group of related functions plus the data structures they operate on — for example, a C file inventory.c exposing functions such as addItem(), removeItem() and checkStock() that all manipulate a shared inventory data structure, with the file's header declaring which functions are public. In an object-oriented system, the module is the class (or a tightly related cluster of classes forming a package): a class bundles its own data (fields) and the operations on that data (methods) into one unit, and the class's public methods form its interface while its fields and private methods remain hidden, which is a stronger, built-in form of the same module boundary that a function-oriented file has to maintain by convention alone.

(c) Decomposition and Quality Attributes

Decomposition is the process of breaking a system down into its constituent modules during design — deciding what the modules are, what each is responsible for, and how they will interact — and it is the design activity that produces modularity. The relationship between decomposition and quality attributes is direct and causal: how a system is decomposed — along which boundaries, with what interfaces — determines the resulting cohesion and coupling, which in turn determines maintainability, reusability and testability. A poor decomposition (for example, splitting a payroll system by which developer happened to write the code, rather than by responsibility) produces modules with low cohesion and high coupling, so a single business change (a new tax rule) ends up touching several unrelated modules. A good decomposition of the same payroll system — separate modules for hours calculation, tax calculation and payment disbursement, each hiding its own data — means the same tax-rule change is confined to the tax-calculation module alone, directly improving maintainability through the choice of decomposition rather than through any change to the code's line-by-line quality.

Practical Application

A team redesigning a monolithic order-processing system into modules for order validation, inventory reservation and shipping is performing exactly this kind of decomposition: each new module is highly cohesive around one responsibility, the modules interact only through defined interfaces (low coupling), and the resulting system is measurably easier to test and to extend than the original.