Here is another of my seminar summaries from Student Originated Software on one of the classic ACM papers we have been reading.
As with my last summary post, please don’t bother stealing this. It’s immoral, unethical, and usually just plain rotten. If you don’t understand the paper but you are required to turn a summary in, you need to read the paper carefully – this summary comes straight from the paper text, as with the summary posted in Part I.
PARNAS, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES
Parnas utilizes the example of a KWIC system to demonstrate how programs can be constructed by utilizing a series of different modules. By way of this example, he demonstrates how different modularizations yield different results in the level of information hiding available. He suggests criteria that might be used to properly construct these modules in order to ensure that modules may be developed independently of one another. He claims that the managerial and development time should be drastically reduced and that it should drastically increase the comprehensibility of the program for coders.
Parnas explicitly defines a module as a “responsibility assignment” rather than a subprogram, which may actually limit his argument. In larger programs, subprograms could in fact be fully modularized via responsibility assignments controlled by a master module called by the remainder of the program – the level of decomposition he discusses here can be more widely applied than is implied by the remainder of the paper. He creates two different modularizations for a KWIC index system: the first is based upon the stages the program steps through, the second is based upon discrete units of functionality. The first modularization utilizes five modules: input (reading in data), circular shift (finding the location of each circular shift), alphabetizing (alphabetizes the shifts), output (prints the shifts), and the master control module, which controls the operation of the program. This first module, Parnas argues, is the approach that would be used by most coders in creating a modularized system.
The second modularization utilizes six modules: line storage (responsible for the management of information regarding circular shifts), input (reads in from the input media), circular shifter (manages anything to do with shifts), alphabetizer (manages the alphabetical ordering of shifts), output (prints circular shifts), and master control (same function as the previous modularization). Parnas then begins to compare the benefits and drawbacks of each modularization. Both modularizations ease the ability to program each section individually, but only the second appropriately hides information so that the other modules do not need to rely on or replicate knowledge provided by other modules. After assembly, each module could be analytically identical, but the second module has more potential to be developed in an inefficient manner due to the information hiding available in this approach. Parnas also extensively discusses the changeability of each module and areas that could be modified and the impact that such changes may have on the programming of each module. Parnas is also concerned about the comprehensibility of code.
He proceeds to give an analysis of the impact of changing a particular portion of the design on both modules, isolating the circular shift algorithms. He gives examples of advisable decompositions for the system: creating data structures as a single module, pairing routines with their calling instructions is a single module, control structures are a single module, and information about the inputs are a single module.He also discusses the difference between hierarchical structures and modularization. He states that having a partial ordering of modules that allows different modules to use lower-level functionality and stand alone is beneficial; higher levels can be pruned to create a new program with the same base functionality.Thus, he concludes, a combination of modularization and hierarchical ordering can be greatly beneficial to a program.
In his conclusion, Parnas disdains directly correlating program modules with steps in a flowchart, instead urging the usage of a list of design decisions that could change and to press for information hiding whenever possible.