A lucid statement of the philosophy of modular programming can be found in a 1970 textbook on the design of system programs by Gouthier and Pont [1, l Cfl0. 23], which we quote below: A well-defined segmentation of the project effort ensures system modularity. Each task fonos a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the inΒ tegrity of the module is tested independently; there are few scheΒ duling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching. Usually nothing is said about the criteria to be used in dividing the system into modules. This paper will discuss that issue and, by means of examples, suggest some criteria which can be used in decomposing a system into modules. A Brief Status Report The major advancement in the area of modular programming has been the development of coding techniques and assemblers which (1) allow one modu1e to be written with little knowledge of the code in another module, and (2) alJow modules to be reasΒ sembled and replaced without reassembly of the whole system.
