Modularisation & Decomposition

1. Using a Top-Down & Bottom-Up approach

Imagine you have been asked to cook dinner.

The first step is to find out as much information as you can about what you are being asked to do. For example:

• How many people are you cooking for? This will determine how much food to buy.
• Do any of your guests have 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 end-users.

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.

An example of top-down and bottom-up approaches is shown in Figure 1.1.

2. Using a Modularisation Approach

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.

An example of a modular approach to preparing dinner is shown in Figure 1.2.

3. Identifying & Describing the Main Features

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 taking a larger problem and breaking it down into smaller, more manageable problems is called Decomposition.

The first step of decomposition is working out what the main features of a given problem are which is shown in figure 1.3.

4. Breaking a Problem Down

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 1.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.

Figure 1.4 shows the decomposition of this process using modularisation.