Whenever a computer programmer sets down to write a program he or she is faced with the same challenges every single time:
One of the key methods used to solve this problem is to use a technique called decomposition.
In this lesson, we will learn about the process of decomposition:
Imagine you have been asked to cook dinner.
The first step is to identify any problems you might encounter from the outset. For example:
In programming, identifying the problem means getting used to the PROBLEM DOMAIN, the area where your program will end up being used.
You might also identify any PROCESSES at this stage – a process is a set of steps that must happen in order to proceed.
For example, if you are going to make mashed potatoes, your potatoes must be peeled, put in a pan of boiling water and boiled for 20 minutes. This is a PROCESS.
Let’s go back to your dinner problem. You could try and cook the whole thing at once, but this would be challenging.
You might decide to break it down into a starter, a main course and a dessert.
You might decide that as the dessert is cake and ice cream, you can make it the day before and leave it in the fridge.
You might then break the main course down further into meat and vegetables and you might ask a friend to help with the meat while you do the vegetables.
This process, of taking a larger problem and breaking it down into smaller, more manageable problems is called DECOMPOSITION.
You need to keep decomposing the problem until you arrive at a series of steps that cannot be broken down any further. You should be able to stick all the individual pieces back together to make a complete program.
In the example shown in Figure 1, the process ‘make other vegetables’ could be broken down further.
In programming terms, every password-based login process on the planet must check the password entered by the user against the password stored in the system. If the password matches, the user is logged in.
However, there is no mention of what to do if the user enters the wrong password.
This is where you need to define your problem.
If an incorrect password is entered, the system should show the user an error message.
But what happens then? How many times does the user get to enter their password?
There is not enough information here and we would need to go back to our client.
Figure 2 shows the decomposition of the password process.
This is why you need to understand what you are trying to do, as it will determine how you go about writing the code.
When you have broken the problem down into a set of clear, easy to follow steps, your problem is FULLY DECOMPOSED.
At this stage, you can hand the problem over to any other programmer and they should be able to follow what you need to do.
You should also have a clear list of any processes so that your program can be built by anyone else.
Once you have a list of what you want to do, you need to check that you have understood the problem correctly.
This would usually mean talking with your client who has asked you to build the program, to make sure it is going to do what they want.
You could also end up talking with other programmers, who might recognise problems that you have not spotted or suggest alternative techniques you might want to consider.
This would be like talking with your dinner guests, to make sure they are happy with what you are serving and talking with cooks to find the best way of serving the food you intend to make.
Before beginning to build any software program we need to carry out a process called Decomposition.
Decomposition means identifying from the start any problems or processes that we might encounter.
We then keep breaking the problem down into smaller tasks and processes.
A process is a set of steps that need to be carried out in order to achieve a particular goal.
Each task or process could then be handed out to different people.
Once we think we know what we are going to do, we need to check this with others, such as the client & other developers.