We have looked at taking a complex, multi-faceted, task and breaking it down into a set of possible constituent parts, each of which may itself need further breaking down, or refinement. In our example to prepare the dinner, what we ended up with at the lowest level of detail was a list of actions that would be done one after the other in order to achieve our original goal:

Look in a few cookery books for a short list.
Check with everyone which recipe they would prefer.
Make a list of ingredients in the recipe.
Check the cupboards for which ingredients are missing.
Get the car out.
Drive to Sainsburys.
Buy the ingredients.
Drive back home.
Prepare the ingredients.
Put the oven on to the right temperature.
Follow the recipe.

In effect, we are saying, `Do this, then do this, then do this', and so on. We have a sequence of steps to accomplish the task. This is the simplest sort of solution to a problem - doing one thing after another. Unfortunately, life is rarely as simple as following a course of action in which there aren't any decisions to be made. We will often be faced with making choices in the solutions to our problems. For instance, if we live a long way from the supermarket, driving there might not be quite so simple as we have suggested so far:

Drive to Sainsburys:
    Get in the car.
    If we haven't enough petrol then fill up at the garage.
    Go to Sainsburys.

Clearly, we wouldn't wish to fill up with petrol every time we go shopping at Sainsburys, so we only, `fill up at the garage', if `we haven't enough petrol.' We choose whether or not to perform an extra action depending on the state of our petrol tank. In programming problems such choices are common

Dispense money from a hole in the wall machine:
    If there is enough money in the account
                then pay out the amount requested.

Run a computer session:
    Request a login name from the user.
    Request a password from the user.
    If the password matches that for the user
		    then let them use the computer.

In both cases, we only do a dependent set of actions if we find that a particular condition is true.

Another common scenario is to choose between two possible alternative actions depending on a condition

Dispense money from a hole in the wall machine:
    If there is enough money in the account
                then pay out the amount requested
    otherwise ask the user to request a smaller amount.

If the cash machine can fulfill the request from the balance held in the account then it will do so, otherwise it will tell the user to try again. The request to the user to modify the amount requested is only made if the condition is false. So you can see that during a particular attempt to withdraw money, only one of these alternatives will ever be acted on. The machine will never both pay out and ask for a smaller amount.

As well as doing things in sequence and choosing between different courses of action, another common practice in solving problems is to do things repeatedly. Suppose, for instance, that we wish to adjust the flavour of some soup that we are making. We might taste it and, if it isn't salty enough, add another pinch of salt. It still might not be right, so we will probably taste it again, and add some more if necessary. We would keep on doing this until it is just right. We might express this as follows:

Flavour the soup:
    Taste the soup.
    While there isn't enough salt in it,
        Add another pinch.
        Taste the soup.

Note that we might not like much salt in things, and our first taste tells us that the soup is just right. In which case, we won't add any more. The number of times that we add salt to the soup depends on the flavour of the other ingredients, and our own preferences. This kind of repetition is called indefinite or unbounded, because we usually can't tell in advance how many times we will repeat the actions. Other kinds of repetitive actions will be for a fixed number of times and this is called bounded repetition, for instance:

Three Times,
    Fill the spoon with sugar.
    Add it to your tea.

Breaking down problems will produce smaller problems involving tasks that need to be done one after the other, tasks that need to be done more than once, and tasks that only need to be done sometimes. In the next section of these notes we shall look at the way that these concepts are expressed in simple fragments of Modula 3.