Several poor design features should be avoided. Passing too little data can make it impossible to perform the task. For example, if the calling module does not pass the vendor ID, how does the subordinate module know which record to locate Designs that create floating data should also be avoided. This occurs when one module produces data that are not needed by the calling module but by another elsewhere in the system. The details are passed through the system (hence
the term floating, until they finally reach the function that requires them. Redesigning, to establish loose coupling, along with the creation
of more cohesive modules, will avoid this difficulty.
8.4.3 Cohesion Using the top- down approach to planning the software fora system is no guarantee that errors will be avoided or that the system will be maintainable. In properly modularized,
cohesive systems, the contents of the modules are so designed that they perform a specific function and are more easily understood by people than systems designed by other methods. There are four general types of modules contents
1. Module contents determined by function performed,
2. Module contents
determined by data used,
3. Module contents determined by logic of processing and
4. Module contents not closely related. The least desirable type of grouping of module contents consists of steps that do not perform any complete function or that do not logically go together. This extreme case can arise if programmers work according to strict rules and divide modules into section of
50 statements each (or some other imposed limit. Input, output, calculation and file – handling activities are thus performed in a single module.
If this case occurs, it is usually created as result of the programmer’s working without explicit design specifications or a clear understanding of how to handle a task. Module contents may also be grouped together because they logically go together. A module that handles all input or all output operations or one that handles all order – processing activities, regardless of type of customer or data – handling needs for each customer, uses logical grouping. The elements may also be related by the time at which
they are performed that is, they logically seem to go together and are performed at the same time. A module that
initializes all variables and opens files is logically bound. This level of modularity is preferable to the first type because all the elements are executable atone time. Modules that are logically bound are difficult to modify because the cost will be shared for each type of activity. Even the simplest change can affect all types of transactions. Abetter solution is to separate each type of transaction into its own module. Module contents may also be determined by the data used. A module in which the contents refer to the same data is preferable to one that is developed only on the basis of processing logic. For example, a module can be designed so that all operations on a set of data are performed atone time a file is prepared
to be printed on paper, spooled to disk, and also duplicated for backup purposes. A module that reads the next transaction and updates the master file by adding,
deleting, or changing records, including the errors checking required for each type of function, shares a common set of data. This type of binding is better
than the other types discussed, but it is not as good functional grouping. Functional grouping permits more thorough testing of the module. If changes are needed at a later time, analysts and programmers can quickly determine how the module is constructed and how it processes data and interacts with other modules in the system. The emphasis on reliability and maintainability is constant throughout systems development.
Share with your friends: