Whenever a computer programmer sets down to write a program he or she is faced with the same challenges every single time: namely, what is the program going to do and how are they going to go about building it.
One of the key methods used to solve this problem is to use a technique called decomposition.
The process contains four key steps that a programmer will use to help them to understand the programming problem and to start to give them some ideas about how they might go about building the program.
In this lesson, we will learn about the process of decomposition including:
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.
If you are writing a program to help chemical engineers visualise proteins in the body, you will need to understand the technical terminology required by the people who will ultimately end up using your program.
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.
You have been asked to build a Student Planner program to use in your school or college to help students securely view their timetable and manage their homework on any mobile device that they bring in to class, including laptops and mobile phones.
Can you identify any problems you might encounter?
Can you identify any processes you might need?
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.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 1.2 shows the decomposition of this 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.
Following on from the Student Planner program in the previous example, can you break the problem down into a series of steps that cannot be broken down any further?
Do you actually have enough information do this?
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.
Can you now describe the Student Planner program as a complete set of structured steps and processes that need to happen in the correct order?
If you cannot, what other information do you need?
Who might you need to ask for this information?
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. Also talking with some cooks to find the best way of serving the food you intend to make.
Communicating with others means that you might need to explain technical terminology to a non-specialist.
Can you explain the tasks and processes of your Student Planner to a non-technical member of your family?
So to summarise what we have learned in this lesson: