Question 5 of 11: Modularity, Modules and Decomposition

Question 5: Modularity, Modules 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

Modularity is the property of a software system being divided into separate, well-defined modules, each responsible for a distinct piece of functionality and each interacting with the rest of the system only through defined interfaces. It matters because it lets a large, otherwise unmanageable problem be tackled by "divide and conquer": different modules can be designed, implemented and tested by different people or teams working largely independently, and a single module can later be understood, modified or replaced without requiring the whole system to be re-examined. Modularity directly supports Maintainability (a bounded, well-defined piece of the system can be changed in isolation), Reusability (a self-contained module can be lifted into another system), and Testability (each module can be exercised and verified on its own, independent of the rest of the system).

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

In a function-oriented system, a module is typically a function or procedure — or, at a coarser grain, a source file or library exposing a small public set of functions while keeping helper functions private — grouping a related piece of behaviour behind one callable interface. In an object-oriented system, the module is the class: it groups a coherent set of data (attributes) with the operations (methods) that act on that data into a single named unit, and classes are further grouped into packages or namespaces that form a coarser-grained module boundary above the level of individual classes.

(c) Decomposition and Its Relationship to Quality Attributes

Decomposition is the process of breaking a system down, typically hierarchically, into progressively smaller and more manageable modules or subsystems — either by function (top-down functional decomposition) or by object responsibility (object-oriented decomposition into classes and subsystems). The relationship to quality attributes is direct and causal: a decomposition with high cohesion inside each module and low coupling between modules produces high Maintainability, Reusability and Testability, because each module can be understood, changed and verified largely in isolation from the rest of the system. A poor decomposition — a single "do everything" module, or modules so interdependent that changing one forces changes in several others — can satisfy the identical functional requirements while scoring badly on every one of those quality attributes. For example, decomposing a payroll system into separate Read Employee Data, Calculate Pay and Print Report modules (the same decomposition used as the structure-chart example in Question 6) means a change to a tax-withholding rule is confined to the Calculate Pay module; the equivalent single monolithic runPayroll() function that inlines reading, calculating and printing in one block would force the same tax-rule change to be made and re-tested inside code that also handles I/O and formatting, directly reducing maintainability and testability for no functional difference.

Practical Application

Teams that enforce modular decomposition in a design review consistently find defects are cheaper to localise and fix, because a failing test almost always points at one specific module rather than requiring the whole system to be traced through.