On the criteria to be used in decomposing systems into modules
흐름도가 아니라 정보 은닉을 기준으로 시스템을 모듈화하자는 주장을 담은 논문.
2003-06-22에 읽고 요약. 월간 마이크로소프트웨어 “고전을 찾아서” 시리즈에 김창준님과 공동 집필. —AK
Abstract
This paper discusses modularization as a mechanism for improving the flexibility an comprehensibility of a system while allowing the shortening of its development time. The effectiveness of “modularization” is dependent upon the criteria used in dividing the system into modules.
Introduction
A Brief Status Report
Expected Benefits of Modular Programming
The benefits expected of Modular programming are:
- Managerial: Development time should be shortened because separate groups would work on each module with little need for communication.
- Product flexibility: It should be possible to make drastic changes to one module without a need to change others.
- Comprehensibility: It should be possible to study the system one module at a time. The whole system can therefore be better desgined because it is better understood.
What is Modularization?
“Module” is considered to be a responsibility assignment rather than a subprogram. The modularizations include the design decisions which must be made before the work on independent modules can begin.
Example System 1: A KWIC Index Production System
Modularization 1
It should be clear that the above(a description about modularization 1) does not constitute a definitive document. Much more information would have to be supplied before work could start. … All of the interfaces between the four modules must be specified before work could begin.
Modularization 2
Comparison of the Two Modularizations
- Managerial(Independent development): In the second modularization the interfaces are more abstract; they consist primarily in the function names and the numbers and type of the parameters. These are relatively simple decisions and the independent development of modules should begin much earlier.
- Product flexibility(Changeability): (On Modularization 2) 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!
- Comprehensibility: To understand the output module in the first modularization, it will be necessary to understand something of the alphabetizer, the circular shifter, and the input module. … The system will only be comprehensible as a whole.
The Criteria
In the first decomposition the criterion used was to make each major step in the processing a module. … The second decomposition was made using “Information hiding” as a criterion. Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.
While we carefully hid the method of storing or calculating the list of circular shifts, we specified an order to that list. Programs could be effectively written if we specified only
- that the lines indicated in circular shift’s current definition will all exist in the table
- that no one of them would be included twice
- that an additional function existed which would allow us to identify the original line given the shift.
Be prescribing the order for the shifts we have given more information than necessary and so unnecessariliy restricted the class of systems that we can build without changing the definitions. … Our failure to do this in constructing the systems with the second decomposition must clearly be classified as a design error.
Improvement in Circular Shift Module
Efficiency and Implementation
If we are not careful, the second decomposition will prove to be much less efficient than the first. … The several representations of the program (which were mentioned earlier) must be maintained in the machine together with a program performing mapping between them.
A Decomposition Common to a Compiler and Interpreter for the Same Language
The statement that the order in time in which processing is expected to take place should not be used in making the decomposition into modules. It further provides evidnece that a careful job of decomposition can result in considerable carryover of work from one project to another.
Hierarchical Structure
Our design has allowed us to have a single representation for programs which may run at either of two levels in the hierarchy. … The partial ordering gives us two additional benefits. First, parts of the system are benefited (simplified) because they yse the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. … The 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. If we had designed a system in which the “low level” modules made some use of the “high level” modules, we would not have the hierarchy, we would find it much harder to remove portions of the system, and “level” would not have much meaning in system. …
We must conclude that hierarchical structure and “clean” decomposition are two desirable but independent properties of a system structure.
Conclusion
We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.