Previous Chapter Main Menu Next Section

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

A. XTask 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:

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: