Modularisation & Decomposition

Whenever a computer programmer sits down to write a program, they are faced with the same problem every single time: What is the program going to do, and how is the programmer going to build it?

There are several approaches to problem-solving that the developer could use.

In this lesson, we’ll learn about:

1. Using a top-down and bottom-up approach to problem-solving
2. Using a modularisation approach to problem-solving
3. Identifying & describing the main features of problems & processes
4. Breaking down problems & processes into distinct steps

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 vegetarians, or do they 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.

A top-down approach is where you look at the problem as a whole and then start to break it down into smaller problems.

For example, you decide to break up the dinner into a starter, main and pudding courses.

A bottom-up approach is where you identify a list of small tasks that you already know about, and then you assemble them together into a larger task.

For example, you know you’ll need some pans of boiling water, you’ll need the oven turned on, and you’ll need some vegetables peeled.

You then start to assemble these together to create your dinner.

A module is where processes that have things in common are grouped together. The group is called a module.

This could be a code object or a library of functions.

For example – you might have a module that contains all the functionality you need to read and write from files.

If you were to modularise the dinner, you would identify an ‘oven’ module. This would have functions to set the temperature and the timer.

You would then work out which of your meal ingredients need to use the oven and which oven functions are needed.

One module can use the functions of another. For example, roasting meat would use the oven functions.

When looking at your dinner problem, you will need to work out how you are going to go about solving the problem.

The first thing you would need to do is identify the main features of the problem.

In this example, you decide to break the task down into a Starter, Main and Pudding.

This process of dividing a larger problem 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 put all the individual steps back together to make a complete program.

In the example shown in Figure 3, the process ‘make other vegetables’ could be broken down into further steps. For example:

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 a programmer, and they should be able to follow your steps.

For a real-world example, every password-based login process must follow these steps.

1. Check the password entered by the user against the password stored in the system.
2. If the password matches, the user is logged in.
3. If not, an error message is displayed.

Entering the username and password would need code from the user interface module.

Sending data to the database would need code from the database module.

The problem domain is the field where your program will be used.

A top-down approach is where a large problem is broken down into smaller problems.

A bottom-up approach is where a series of smaller tasks are put together to solve a problem.

Modularisation is where related sets of functionalities are grouped together.

Decomposition of a problem involves identifying the main features of a problem and breaking the problem down into smaller tasks.

Once each task cannot be broken down any further, the problem is fully decomposed.