Design Heuristics for Effective Modularity

Once a program structure has been build effectual modularity can be achieved through applying the design concepts introduced previous in this chapter.  The program architecture is manipulated according to a group of heuristics presented in this section.

I. Evaluate the "first iteration" of the program structure to reduce coupling and improve cohesion. At Once program structure has been build; modules may be imploded or exploded with an eye toward improving module independence.   An exploded module becomes 2 or more modules in the final program structure.   An imploded module is the result of combining the processing implied through two or more modules. The exploded module often results when a general process parts exists in two or more modules and can be redefined as a divide cohesive module. When high coupling is expected the modules can sometimes be imploded to reduce passage of control reference to global data and interface difficulty.

II. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.  The structure shown inside the cloud in the Figure does not make effectual use of factoring. All the modules are pancaked below a single control module.  In common, a more reasonable distribution of control is described in the upper structure.  The Structure takes an oval shape indicating a number of layers of highly and control utilitarian modules at lower levels.

III. Keep scope of effect of a module within the scope of control of that module.

The scope of result of a module is described as all other modules which are affected through a decision made in module e.   Scope  of  control  of  module  e  is  all  modules  that  are  subordinate  and  ultimately Subordinate to module e.  As describe in Figure, if module e makes a decision which affects module r, we have a violation of heuristic III  because module r lies outside the scope of control of module e.

IV.  Evaluate  module  interfaces  to  reduce  complexity  and  redundancy  and  improve  consistency. The Module interface complexity is a major cause of software errors.  The Interfaces should be designed to pass information easily and should be consistent by the function of a module.  The Interface inconsistency for example seemingly unrelated data passed through an argument list or other method is an indication of low cohesion. Module in question should be re-evaluated.

V. Define modules whose function is predictable, but avoid modules which are overly restrictive. This module is predictable when it can be treated as a black box   which is, the similar external data will be produced regardless of internal processing details. The Modules which have internal memory can be unpredictable unless care is taken in their use.

The module which restricts processing to a single sub function exhibits large cohesion and is viewed with favor through a designer.  Moreover, a module which arbitrarily restricts size of a local data structure option within control flow or modes of external interface will invariably need maintenance to remove such type of restrictions.

VI. Strive for controlled entry modules avoiding pathological connections.  This design heuristic warns besides content coupling. The Software is easier to understand and thus easier to maintain when modules interfaced are controlled and constrained. The Pathological connection refers to branches or references into the middle of a module.

VII. Package software based on design constraints and portability requirements.    The Packaging alludes to the methods used to assemble software for an exact processing environment.  The Design constrains sometimes dictate in which a program overlay   itself in memory.   When this must happen the design structure may have to be reorganized to group modules through degree of repetition, frequency of access and interval among calls. Additionally optional or one-shot modules may be divided in the structure so in which they may be effectively overlaid.