Lecture 3: Functions and Modularization I and Text File IO

Modularization

As a program becomes larger and more complex, you will find it necessary to break the program into smaller and more manageable pieces. These pieces are frequently called modules. The examples that follow begin the approach to writing programs that utilize modules. The process of designing programs by breaking them into these smaller pieces is called modularization.

The modularization of programs introduces an additional graphic to represent the relationship between the main program and all of its modular pieces. This graphic is called a hierarchical chart and is also called a structure chart. In Lecture 1 an accounting program was discussed. In that lecture the following structure chart was shown that illustrated the various parts/modules of that program:

The main module: accounting has five sub modules: startClient, salesLedger, pAndl, expenseLedger and endOfYear. Each of these modules in addition had sub modules of their own. For example the structure chart above shows the sub modules of the module: salesLedger and the sub modules of the module: expenseLedger. (This is not the complete structure chart for this program. Some of the other modules themselves had sub modules as well.)

The pseudo code adds new features for modules as well. For example a partial pseudo code for this accounting program would be the following:

 Accounting   DO    Input type_accounting    CASE OF type_accounting     1: Perform startClient     2: Perform salesLedger     3: Perform pAndl     4: Perform expenseLedger     5: Perform endOfYear     6: Perform "End of Program"    ENDCASE   WHILE(type_accounting != 6) End startClient    ...... Return salesLedger    .... Return .... .... 

 Note:  The …. above means that there are additional statements but they are left out.

In the pseudo code above, notice that not only is there pseudo code for the main part/module but there is also pseudo code for each of the sub modules. In the example above, the main module calls each of the sub modules (i.e. the called module) by using Process (or Perform) when selected by the user. After the sub module completes its instructions, the control is returned to the main module (i.e. the calling module). Notice the Return at the end of each sub module. The program above will continue until the user selects the option to end.

In some programs it is necessary to share data between some of the modules. The sharing of data can be accomplished in several ways. One way would be to have a variable available to all modules. This type of variable is called a global variable. Those variables that are only available or accessible within a particular module are called local variables. By using global variables, data may be passed between the various modules. However, it is no longer viewed as good programming style to use global variables and they should be avoided. The reason for this point of view is that global variables can be modified or removed accidentally during maintenance by someone who does not know all of the global variable's uses. When the pseudo code is written for global variables, they are listed in any module when and where they are needed. No special pseudo code notation is therefore necessary for global variables.

Another method for sharing data is to pass data into the called module from the calling module and to return data from the called module to the calling module. These methods permit better control of where and when data may be accessed and changed. For example consider the following pseudo code:

 discount    DO      SET Continue = 'Y'      Input price, discountCode      Perform printDiscountSign(price,discountCode)      Input Whether to Continue (Y/N)    WHILE(Continue='Y') End printDiscountSign(price,discountCode)   .... Return 

In the example above, the values of price and discountCode are made available to the body of the module printDiscountSign( ) by listing these variables inside of the parenthesis when the module is called. However, the variables themselves are not available to the body of the module. We call this passing-by-value. That is, should the body of the module change the value stored in price for example, the change would not be available outside of the module printDiscountSign( ). A structure chart to depict this program is the following:

Notice the arrow to the left of the names of the variables price and discountCode. This graphic is meant to depict the fact that the values of the variables price and discountCode are being passed to the module.

For the flowcharting of the modules the Subroutine symbol below is used to represent this modularization.

Using this flowcharting symbols, the above program would be depicted by the following flowchart:

An additional flowchart for the module: printDiscountSign( ) would also be a part of the flowchart for the program.

Sometimes you may want to return to the calling module from a called module some value that was calculated in the called module. To do this it is possible to return a value as in the following pseudo code example:

 grade   Set Continue = 'Y'   DO     Input studentName, grade1, grade2,grade3     Process calculateGrade(grade1, grade2, grade3)     Receive in theAverage output from calculateGrade()     Display studentName, theAverage     Input Whether to Continue (Y/N)   WHILE(Continue='Y') End calculateGrade(grade1,grade2,grade3)    average = (grade1+grade2+grade3)/3 Return average 

In this example above grade1, grade2 and grade3 are local variables of the program grade. Their data are passed-by-value to the body of the module: calculateGrade( ). However, the variables themselves are not available to the body of the module only their values. In the body of the module, the value of average is calculated. Since average, in this case, is a local variable in the module, it is not available to the program and the data must be returned to the program. A structure chart to depict this program is the following:

The arrow on the right pointing down in the structure chart above is meant to depict the fact that the values of the variables grade1, grade2 and grade3 are being passed to the called module calculateGrade(). The arrow on the left pointing upward is meant to depict the fact that the value of the variable average is being transferred to the calling program grade from the called module: calculateGrade().

A flowchart for the above program is the following:

Notice in the above flowchart that the module calculateGrade( ) also has a flowchart. Further notice that the value of average is returned.

In the example above only the value of one variable average is changed in the called module and therefore only one variable in the calling program theAverage is changed. There are times in which more than one value needs to be changed in the calling module yet you do not want to use global variables. How this is handled will depend on the language used. More will be said about this later when the C++ implementation of these concepts are discussed.

 Note:  Modularization is an extension of the structure theorem used in designing programs.