Methodology for Developing Programs

We have already studied that the programming process consists of a problem solving phase and an implementation phase. Whatever may be the problem, you were warned not to try to bypass the problem solving phase even when a problem is small. When we solve even small problem we must need to take care of every details and follow a methodological approach. The practice of applying the following methodology approach to small problems will prepare you to tackle larger programming problems that you can not solve directly.

Top-Down Approach

The top-down approach divides the problem into smaller problems (subproblems) that can be handled more easily. If these subproblems are still too difficult to handle then they are subdivided again and so on. This process continues until each subproblem can not be further divided. Figure-(c) shows this. It is the programmer who decides exactly how the work will be divided among them.

Sometimes we also follow bottom-up approach in which the programmer might choose to solve different parts of the problem directly in his programming language and them combine these pieces into a complete program. Experience suggests that the top-down approach should be followed when creating a program.

It is true that it is often not easy to decide exactly how to divide the work into subproblems and sometimes even a decision once made must later be modified. But once a problem has been divided into subproblems, each subproblem can be solved independently of the others. These subproblems are also called modules. That’s why the top-down approach is also called as modular programming or step-wise programming. Modules at one level can call on the services of the module at lower level. For example one module could read elements of a matrix, another could display these values, and some other modules could add, subtract, or multiply matrices.

The top-down approach can be broken down as follows:

1. Understand the problem very carefully, rewriting it more clearly and completely if necessary. You can say that one must very clear about what is given (input) and what is required (output).
2. Write the main (super) module and name the lower-level modules (submodules) that provide certain functions.
3. Write the remaining sub modules, if any. Actually there is no fixed number of levels. Modules at one level can specify more modules at lower levels.
4. Resequence and revise, if necessary. You can maintain clarity by expressing yourself simply and directly.

Figure (c)