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:

  1. Identifying and Describing Problems and Processes.
  2. Breaking Down Problems and Processes into Distinct Steps.
  3. Describing Problems and Processes As a Set of Structured Steps.
  4. Communicating the Key Features of Problems and Processes to Others

Media Attachments: Presentation

1. Identifying and Describing Problems and Processes

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.

Further Thought

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?

2. Breaking Down Problems & Processes into Distinct Steps

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.

Decomposing the Making Dinner Problem
Figure 1.1 Decomposing the problem of making dinner into smaller problems

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.

Decomposing the Login System Problem
Figure 1.2 Decomposing the login system problem

This is why you need to understand what you are trying to do, as it will determine how you go about writing the code.

Further Thought

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?

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

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.

Further Thought

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?

4. Communicating the Key Features of Problems & Processes

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.

Further Thought

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?

Lesson Summary

So to summarise what we have learned in this lesson:

  • 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.
  • We need to make sure that we understand the language of the Problem Domain.
  • Once we think we know what we are going to do, we need to check this with others, specifically the Client and/ or other programmers. This helps us make sure we are on the right lines before we get started.