Decomposition

1. Identifying and Describing Problems and Processes

Imagine you have been asked to cook dinner.

The first step is to identify any problems you might encounter from the outset. For example:

• How many people are you cooking for? This will determine how much food to buy.
• Are any of your guests vegetarian or do any of them have any allergies? This will determine what kind of food you should buy.
• What kind of equipment do you have in your kitchen? This will determine how you can cook the food.

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.

2. Breaking Down Problems & Processes into Distinct Steps

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.

3. Describing Problems & Processes As a Set of Structured Steps

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.

4. Communicating the Key Features of Problems & Processes

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.