Top-Down Structure of Modules

Top – down methods are used throughout the analysis and design process. The value of using a top-down approach, starts at the general levels to gain an understanding of the system and gradually moves down to levels of greater detail. In the process of moving from top downward, each component is “exploded” into greater detail. One data flow diagram became several at the next lower level.

During the discussion of input and menu design, a top-down approach was emphasized. The main menu contains several choices. Making one choice produces another menu in, which more detailed options are presented to the user. This capability provides users with an easy – to – understand method for using the system and selecting option. They do not have to make all decision together but instead can make one at a time.

The top – down method is also widely used in systems engineering and software design. Each function, the system will perform is first identified, and then developed in greater detail. Program designers term this as stepwise refinement: the procedures and processes are developed a step at a time, from general to specific.

For example, an accounting system consists of many separate modules that are invoked one at a time as users indicate the particular function they wish to perform. Each upper – level module in turn leads to using one or several lower-level modules until the desired function is performed.

8.4.2 Coupling

Coupling refers to the strength of the relationship between modules in a system. In general, good designers seek to develop the structure of a system so that one module has little dependence on any other module.

Loose coupling minimizes the interdependence between modules. We can achieve this in the following ways.

Control the number of parameters passed between modules Avoid passing unnecessary data to called modules

Pass data (whether upward or downward) only when needed

Maintain superior/subordinate relationship between calling and called modules.

Pass data, not control information

Consider the manner in which data are passed in an accounting system. In editing a vendor record (for the accounts payable portion), two alternative designs for editing a vendor record (for the accounts payable portion) are available. In the first, typified by tight coupling, which is undesirable, the calling module passes the vendor name, vendor identification number, address, tax status and date. The called module returns the customer record, along with an end – of – file flag.

Figure: 8.1 Coupling & Cohesion in software design

Couplin Coupling Couplin Coupling: Strength of relations Between Modules Strength

Cohesion: Strength of relation Within modules

Figure 8.2 Coupling and strength of relations between modules

Compare this with the preferred loosely coupled version in which only the vendor ID is passed to retrieve the same record of information. Not only does this design move less data (only non-superfluous data), but also there is far less dependence between modules. Only the vendor identification is needed to distinguish one vendor’s record from another. Since it is likely to be the record key, it is also unlikely to change. Other items in the record may change. Hence, the loosely coupled alternative is better suited to achieving the stated design and maintenance objectives.

Edit vendor record _{Edit vendor} record Retrieve vendor record Retrieve vendor record Vendor name vendor ID vendor address Tax status date

Vendor record EOF Vendor record EOF Vendor ID

Poor: Tight Coupling Good: Loose

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 for a 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 at one 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. A better 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 at one 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.