On the Criteria To Be Used in Decomposing Systems into Modules

• SE 3

https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

the criteria used in arriving at the decomposition … a problem, and a conventional and unconventional (alternative) decomposition

benefit expected for modular programming

• managerial — development time shortened because separate groups … with little need for communication
• product flexibility — make drastic changes to one module without a need to chnage others
• comprehensibility — possible to study the system one module at a time

modularization, considered to be responsibility assignment rather than a subprogram

“system level” decisions — which affect more than one module

comparison of two modularization

1. ..
2. the decision to have all lines stored in core …
3. decision to pack the characters four to a word …

changeability

the first change is confined to one module in both decompositions … second / third change would result in changes in every module! … Knowledge of the exact way that the lines are stored is entirely hidden from all but module 1. any change in the manner of storage can be confined to that module.

… in some versions of the system there was an additional module in the decomposition. … a symobl table module → this fact was completely invisible to the rest of the system.

independent development

1st version: … development of … formats a major part of the module development … a joint effort among the several development groups. In the 2nd modularization the interfaces are more abstract; consist primarily in the function names and the numbers and types of the parameters.

the criteria

in the first decomposition the criterion used was to make each step in the processing a module. … to get the first decomposition one makes a flowchart. … the flowchart was a useful abstraction for systems with on the order of 5,000-10,0000 instructions, but as we move beyond … it does not appear to be sufficient. ….

the second decomposition uses “information hiding” … every module is characterized by its knowledge of design decision which it hdies from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.

efficiency and implementation

If each of the functions is actually implemented as a procedure with an elaborate calling sequence there will be a great deal of such calling due to the repeated switching between modules. the first decomposition will not suffer from this problem …

hierarchical structure

have a hierarchical structure if a certain relation may be defined between the modules or programs and that relation is a partial ordering. the relation is “uses” or “depends upon” …

1. parts of the system are benefited (simplified) because they use the services of lower levels. …
2. able to cut off the upper levels and still have a usable product … existence of the hierarchical structure assures us that we can “prune” off the upper levels of the tree and start a new tree on the old trunk.

hierarchical structure and “clean” decomposition are two desirable but independent properties …

reference

• [9]. Balzer, R. M. Dataless programming. Proc. AFIPS 1967 FJCC, Vol. 31, AFIPS Press, Montvale, N.J., pp. 535-544.

• [10]. Mealy, G. H. Another look at data. Proc. AFIPS 1967FJCC, Vol. 31, AFIPS Press, Montvale, N.J., pp. 525-534.