Objectives: Introduction Over View of System Analysis and Design
Download 0.94 Mb. View original pdf
|
- Navigate this page:
- 8.4.5 Module Size
- 8.4.6 Shared Modules
| 8.4.4 Span of Control Span of control refers to the number of subordinate modules controlled by a calling module. In general, we should seek to have no more than five to seven subordinate modules. On the one hand, excessive span of control, meaning a high number of subordinate modules, creates considerable overhead in determining which module to invoke under certain conditions and in establishing calling sequences to pass data and receive results. On the other hand, it typically results from not adhering to the coupling and cohesion objectives discussed previously. 8.4.5 Module Size How large should a program module be While it is impossible to fix a specific number of instructions, there are useful guidelines to manage module size. Some organizations have established rules to manage module size. A common one is that no module should contain more than 50 instructions. Another is that the listing of source code fora module should fit on a single printer page. In some situations, these rules are appropriate, but in others they result in arbitrary decision (for example, If the module cannot be coded in 50 instructions, create a second module that is called by the first) that miss the point of managing module size. In general, we should seek designs in which the modules focus on a single purpose, are highly cohesive, and are loosely coupled. Yet the modules should not be too small (when that occurs, modules should be combined. The size of the module depends on the language used as well. Approximately 50 statements in COBOL maybe an acceptable upper limit (programmers should not have to redesign if, say 51 or 55 statements are needed, providing other design objectives are met. On the other hand, 50 instructions in a powerful fourth – generation language (where one instruction replaces from 10 to 50 equivalent COBOL statements) will probably be unacceptable. 8.4.6 Shared Modules Shared use results from the desire to have a certain function, calculation, or type of processing performed in one place in a system. We want to design the system so that a certain calculation (such as determination of sales tax in an order processing system) is performed once. Then the module can be shared throughout the system by invoking it from various calling modules. Why share modules There are several reasons. First, sharing modules minimizes the amount of software that must be designed and written. Second, it minimizes the number of changes that must be made during system maintenance For instance, if tax calculation procedures change, only one module must be modified under the shared module principle. And third, having a single shared module reduces the chance of error there is a greater likelihood that redundant modules will follow different calculation procedures, if not initially, after the introduction of maintenance changes (one module may not be changed because it is overlooked. Many systems establish library modules – predefined procedures – which are included in the system’s program library. A single command or call quickly invokes the routine. Shared library modules are one of the best ways in which good designers can design solutions. Download 0.94 Mb. Share with your friends:
|