cs1ch4sec1.htm
 

Chapter 4

Design with Functions

 
Section I: Decomposition Section II: Functions Section III: Output, Calculation, and Display Functions Section IV: Parameters
Section V: Tracing Section VI: Final Thoughts on Redesigning the Employee Salary Problem

  


Table of Contents

Learning C++:
An Index of Entry Points

2. The

of C++

A reference document on the basic elements of C++.


3. The Patterns


Index!

A. Task Decomposition
In this chapter we begin to work with more complex programming problems. The analysis phase remains the same and the specifications that are created still provide a general sense of what is expected of the program. However, we need to learn new tools for the design phase, tools that are specifically for handling program complexity. As you read the material in this chapter, remember that our goal is to develop and use ways to manage the complexity of the programming task. If you understand the ideas presented here, your work as a programmer will be easier.

The analysis effort focused on ways to describe formally and precisely what the problem required. To simplify our task, we broke the requirements phase down into a number of parts:

    -rewriting the problem in our own words (create a problem narrative);
    -describing specific display screens such as any welcoming, help, and exit screens;
    -defining the inputs (what they were, where they came from, and their type);
    -defining the outputs (what they were, where they went to, and their type);
    -defining any constants.

As noted earlier this process of breaking up or decomposing a task into smaller parts is very common in almost all areas of human endeavor. Politically and militarily, it is the idea of 'divide and conquer'. If a nation, idea, problem etc. is too large or too complex, you decompose it into smaller chunks that can be managed more easily by themselves. Different organizations have different approaches for developing a design for a programming task but most approaches focus on some kind of problem decomposition .

One classical approach emphasizes task decomposition - looking for ways to decompose the programming task into smaller and smaller tasks until a set of simple tasks is reached. By simple, we mean tasks that are easy to program.Each of these smaller, more easy to program tasks is also designed to be relatively distinct or separate from the other tasks so that the programmer can focus on one small task at a time. This takes advantage of the fact that it is easier for humans to focus on one aspect/task of a problem while for the moment ignoring other aspects/tasks. The result is that if each task is well defined and simple enough, the programming process should be relatively simple. Also, once the programming of a task is complete and the code has been tested, the code for that task can be used more than once in a program and even used in other programs that require the same task.

Consider the task of having a dinner party. This can be seen as involving hundreds of subtasks:buy the meat, invite Fred, cook the meat, buy the vegetables, clean the living room, buy the rice,invite Aria, cook the rice, clean the bathroom, invite Art, buy the bread, clean the dinning room,clean the kitchen, clean the hallway, cook the vegetables, invite Jose, clean the bedrooms,bake the bread, buy the salad ingredients, invite Lisa, clean, make the salad.

In this decomposition all the tasks are mixed in with no organization.

Or, we can see the whole task as being broken up into four subtasks:

    -Do the shopping
    -Invite the guests
    -Clean the house
    -Prepare the food.

Each of these subtasks is itself complex enough to, in turn, be further decomposed. For example the food preparation task could be decomposed into:

    -Cook the meat
    -Cook the vegetables
    -Make a salad
    -Bake a cake.

And, each of these could also be further decomposed. The decomposition process ends when we arrive at a set of tasks we are so familiar with, they no longer seem complex. At this point each task is 'easy'!

When we talked about algorithms last chapter we assumed that each problem was so simple as to have only one task. We therefore only needed one algorithm for the problem at hand. Now, as our programs become more complex, we will have multiple tasks in each program and each of these tasks will need its own algorithm. Some of the tasks will be so simple that the algorithms for them will be almost a waste of time. Others tasks will require careful thought in support of the algorithm development process. In may cases, the algorithms can be based on one or more of the patterns we just finished studying.

As we determine each task, we will state its purpose and then use these purpose statements to determine if we have access to a pattern upon which we can base the task's algorithm. Thus we have simplified our programming problem in two ways - some aspects of the overall problem will have become so simple that the algorithms for them will be obvious. Other aspects will be more complex but will involve the use of the patterns we know - making them manageable.

B. Structure Charts
The employee salary problem from the last chapter was on the verge of getting more complex than we could handle at one glance. This would be especially true if you add in the 'Introductory' and 'Exit' screens we found useful in our problem analysis back in chapter 3.. Let's use this problem as our example of the decomposition process. One way to divide this problem into separate tasks is as follows:

    -Display Introductory Screen
    -Get the Rate of Pay for an Employee
    -Get the Hours Worked for an Employee
    -Calculate the Salary
    -Output the Salary
    -Display Exit Screen

There are other ways and we will explore at least one of them later.

We now have six independent tasks each of which should be very easy to code. To picture the results of such a decomposition, programmers often use a format called a structure chart. The structure chart for the above problem might look as follows:

Warning Label: If you have ever heard of or used flow charts, be forewarned that structure charts are NOT flowcharts. They have a different semantics or meaning. In the structure chart of fig 4.1, the fact that 'GetRateOfPay' hangs off of ' main' means that 'GetRateOfPay' is a task that is part of the task handled by 'main' - which represents the whole program. Likewise, the order of the tasks (let's call them modules to be 'techie') is unimportant. The modules can be in any horizontal order. Be sure you understand that the picture does NOT mean that 'GetRateOfPay' somehow occurs 'after' 'CalculateSalary'. .

A structure chart is a bit like a management chart - with a box for the president at the top of the chart, followed by boxes for the vice- presidents and on down the line. The president 'uses' the vice-presidents to accomplish his/her goals while the vice-presidents use their subordinates for the same purpose. There is one very important difference, however. A management chart describes the relationships among various job categories while a structure chart describes the relationships among actions. For that reason you should always label the boxes in a structure chart with verbs - 'Get ...', 'Calculate...', 'Output ....'

Top of Section Main Menu Next Section