Advantages of decomposition
Top-down programming design for procedural languages
When faced with any complex problem, finding a solution may well appear a daunting task at first. However, with the right systematic approach, complex problems can be reduced to many far simpler problems. Each of these simpler problems can then be solved. They can then be re-combined back up to the original problem. Before you know it, that unsolvable, complicated task that you had to find a solution for has been solved! This approach has been around for years and is suitable for any problem that is going to be solved using a procedural programming language. This is a type of programming language that makes a lot of use of self-contained blocks of code that then interact with each other. It is not the best approach to use for other types of languages that you will learn about, such as object-oriented languages. The approach to use for this type of language will be discussed in much more detail later in the book.
In top-down programming, a programmer takes a task and then breaks it down into smaller tasks. They then take each smaller task and break it down further into sub-tasks. They continue to do this until each sub-task is simple enough to understand and program and, ideally, each sub-task performs only one job. The sub-tasks are then programmed as self-contained modules of code. When a problem is broken down into modules, the relationship between one module and the next is clearly defined. If we break down one module into three modules, for example, the relationship between the three modules is clearly defined so that together, they perform in exactly the same way that one big module of code would have performed.
Consider a module that calculates a salesman's commission. You could have one module that does this, but because it performs a number of different tasks, it will be split into three modules. This is shown in the next diagram.
- The first module is now responsible for initialising the program and reading in values. That is all it does. Its relationship with the main program is that it passes sales figures out to the program.
- The next module is responsible for doing the calculations. Its relationship with the main program is that it reads in sales figures and passes back commissions due.
- The third module is the display and print module. Its relationship with the main program is that it reads in commissions due.
The above design could be improved further. We have already said that ideally modules should perform only one function. The 'Initialise and read in data' module could be split into an 'Initialise' module and a 'Read data' module. The 'Display and Print' module could also be split into two modules, one called ‘Display’, which will be in charge of displaying results on a VDU, and one called 'Print' which will be responsible for printing out results.
Once modules have been identified, they can then be written. Remember, each module is a block of code that should be self-contained, perform one very specific task and will usually have an interface with the main program.
Different names for ‘modules of code’
Do note that different programming languages call modules of code by different names although they all (very broadly speaking) mean the same thing. One language might, for example, call a self-contained block of code a ‘module’ of code. Another one might talk about ‘procedures’ and ‘functions’. A third one might use the word ‘subroutine’.
Look at the next program. It has the name ‘commission’. Three procedures are written. The actual program is at the end of the code and is simply made up of calls to the procedures that have been written.
If you looked at the 'shape' of the final code for the problem just described, it might look something like this:
Program commission
Procedure InitialiseAndRead //procedure responsible for initialising variables and reading in data.
Begin
-------
-------
End
Procedure Calculate //this procedure is responsible for calculations.
Begin
-------
-------
End
Procedure DisplayAndPrint //procedure responsible for displaying & printing the output.
Begin
-------
-------
End
Begin //this is the program. It is made up of calls to the various procedures.
InitialiseAndRead
Calculate
DisplayAndPrint
End
The benefits of top-down programming design
Programs written using a top-down approach produce modules of code. We sometimes refer to this approach as ‘modular design’ or ‘modular programming’. Whether the modules are called procedures, functions, objects or anything else, they have some distinct advantages when compared to writing one big block of code.
- Splitting up a problem into modules helps get the job done more efficiently because modules of code can be worked on at the same time by different programmers. In addition, it helps because easier modules can be given to less experienced programmers while the harder ones can be given to more experienced ones.
- Splitting up a problem into modules helps program testing because it is easier to debug lots of smaller self-contained modules than one big program.
- Splitting up a problem into modules helps program readability because it is easier to follow what is going on in smaller modules than a big program.
- Splitting up a problem into modules improves a company's efficiency because self-contained modules can be re-used. They can be put into a library of modules. When a module is needed to, for example, display some values, you don't need to get the programmers to write and test a module for this again. You just re-use a module from the library. Over time, this will save a company a lot of time and money.
- Splitting up a problem into modules improves a Project Manager's ability to monitor the progress of a program. Modules can be 'ticked off the list' as they are done and this will demonstrate some progress. This is far harder for a Project Manager to do if the program has not been split up into modules.
- Splitting up a problem into modules is good for future program maintenance. If a program needs to be changed for any reason, it may be possible simply to remove one module of code and replace it with another.