Friday, June 19, 2015

Criteria for Decomposing Systems into Modules

Benefits from decomposing system into modules:
  • Managerial - independent development
  • Flexibility - easier to change product
  • Comprehensibility - easier to understand product
Criteria for splitting system into modules:
  • BAD: Each module corresponds to separate subroutine
  • GOOD: Module hides ("chunk") information
What module should hide:
  • Important design decisions
  • Design decisions which is likely to change
What else:
  • Data structures
  • Sequence of instructions to call a given routine and the routine itself
  • The sequence of items processing
etc.

Hierarchical structure of dependencies and "clean" decomposition into modules are two desirable but independent properties of the system.

It is almost always incorrect to do decomposition of the system based on the flow chart (each block in the flow chart is a separate module). Instead begin with the list of difficult design decisions or decisions which is likely to change. Each module then designed to hide such decisions from others. So subroutines and programs (blocks in flow chart) is an assembled collection of code from various modules.

References:
  1. On the Criteria To Be Used in Decomposing Systems into Modules (1972)