The Programming Process

All programming involves creating something that solves a problem. The problems can range from something of great scientific or national importance, through to something as trivial as relieving personal boredom!

This section describes one approach to solving such problems - think of it as a rough guide to the things you should do when entering the land of programming.

In broad terms, those things are:

  1. Identify the Problem
  2. Design a Solution
  3. Write the Program
  4. Check the Solution

Of these, only the third step is usually called "programming", but as you'll see later, it's probably the least important stage of the process.

Identify the Problem

In fact, this stage should really be called identifying the solution because what you're really trying to do is to tie down exactly what it is that you're trying achieve.

There are two stages to identifying a solution:

  • Requirements
  • Specification

Requirements

The first step is to examine the problem carefully to try to identify what qualifies as a solution. A single problem may have many different solutions, but they will all have something in common. So here you're trying to work out exactly what your program will be required to do.

For example, if we were asked to write a calculator program, we could choose many different ways for the user to enter calculations - from entering equations, pressing buttons or even writing them on the screen - but if the software can't add up correctly then it won't have solved the problem. Therefore our first few requirements must be that:

  • the user can enter sums (we don't care how they do this)

  • and that the program will then evaluate those sums correctly
    and display the result for the user.

We also have to decide what sort of sums our calculator will be required to evaluate. Again, we have a fair amount of choice - we could be ambitious and ask it to solve simultaneous equations or complex expressions, however since this is our first program we should probably make the requirements more simple. So the third requirement is that:

  • The calculator must be able to evaluate sums made up of two whole numbers (integer operands) and one addition (+), subtraction (-), multiplication (*) or division (/) sign (operator).

Note that computer scientists traditionally use * instead of x and / instead of ÷ to indicate multiplication and division respectively.

Thus our calculator must be able to deal with sums like 1 + 1, 10 - 6, 43 * 5 and 42 / 7. However it won't have to handle 67.345 + 6¼, the cube root of PI or 152.

Specification

The second step is to then look at the list of requirements and to decide exactly what your solution should do to fulfil them. As we mentioned above, there are usually many different solutions to a single problem; here, your aim is to decide on which of those solutions you want. Therefore, you're trying to specify, in a fairly accurate manner, just what it is your final program will do.

For example, for the calculator, we've already decided that the program must allow us to enter simple sums and then must evaluate them correctly and display an answer. We must now tie down exactly what this means.

Therefore, we have to decide which method of entering sums to use. We could specify any one of a number of methods, but for now, we'll choose a simple method. We should also specify what other behaviour we're expecting the program to have:

  • When the program runs it will display a welcome message, followed by some simple instructions.

  • The program will then display a prompt sign ([number]>) and the user can then type the first number of their sum at the keyboard followed by the RETURN (<-') key.

  • The program will display a second prompt sign ([+-/*]>) and the user can then enter the operator that they wish to use, followed by RETURN.

  • A third prompt sign will be displayed ([number]>) and the user will then enter the second number, again followed by RETURN.

  • The calculator program will then display the mathematically correct answer to the sum on the screen and end.

By the time you have worked out your specification, you should have a very clear idea of what your final program will do: your goal.

Design a Solution

Once you've identified the things required to solve your problem, and specified what form your solution will take, the next step is to work out just how you're going to turn that specification into a working program. This is usually the hardest task!

As mentioned before, a program is simply a list of steps describing to the computer what it should do. A design is simply a higher-level description of those steps. In effect it's a program written as if the computer was a person. So, it doesn't have to completely spell out every step - because humans know how to do a lot of things already and have a lot of common sense, meaning that they can work the simple steps out for themselves. It also doesn't have to be written in any special programming language - English will do (although people often use special notations like pseudocode or flow charts for the more complicated sections).

Another way of looking at is that a programmer should be able to take a design and write the program from it without having to think too hard. It's a bit like an architect's drawing: it contains all the important structures without showing every bit of brick and mortar.

Working out a design to fulfil a particular specification can be difficult for several reasons:

  1. You may need to learn a bit more about the capabilities of your computer and your chosen programming language/environment to see what things it makes easy or difficult.

  2. You may also need to learn some extra information about the problem or find a technique to solve it before you can work out how to build the program.

  3. Finally, you may be able to think of several ways to build the program, but they will all have different strengths and weaknesses and so some choices will have to be made.

We'll return to these problems a bit later on in the course.

For our calculator, we have a fairly comprehensive specification and since it is a fairly simple program we can turn the that quite easily into a design:

  1. BEGIN
  2.   PRINT welcome message
  3.   PRINT instructions
  4.   PRINT [number]>
  5.   READ first_number
  6.   PRINT [+-/*]>
  7.   READ the_operator
  8.   PRINT [number]>
  9.   READ second_number
  10.   calculate result of using the_operator on
      the first_number and the second_number
  11.   PRINT result
  12. END

Here we assume that PRINT means 'put something on the screen' and READ means 'get something typed on the keyboard' - both fairly standard programming operations.

Notice how step ten is actually hiding quite a complicated procedure. Although we (as humans) could work out which operator was which and do the appropriate arithmetic, the computer itself will need to be told exactly how to do this - but we'll leave that until the programming stage.

Notice also how the design includes all of the important steps needed to fulfil our specification - but that doesn't go into too much unnecessary detail. This is called abstraction.

When your design is completed you should have a very clear idea of how the computer is going to fulfil your specification, which in turn meets your requirements, which in turn should solve your original problem.

Program

Programming is then the task of describing your design to the computer: teaching it your way of solving the problem.

There are usually three stages to writing a program:

  1. Coding
  2. Compiling
  3. Debugging

Coding

Coding is the act of translating the design into an actual program, written in some form of programming language. This is the step where you actually have to sit down at the computer and type!

Coding is a little bit like writing an essay (but don't let that put you off). In most cases you write your program using something a bit like a word processor. And, like essays, there are certain things that you always need to to include in your program (a bit like titles, contents pages, introductions, references etc.). But we'll come on to them later.

When you've finished translating your design into a program (usually filling in lots of details in the process) you need to submit it to the computer to see what it makes of it.

As an example, we shall develop and present the code for the calculator later on.

Compiling

Compilation is actually the process of turning the program written in some programming language into the instructions made up of 0's and 1's that the computer can actually follow. This is necessary because the chip that makes your computer work only understands binary machine code - something that most humans would have a great deal of trouble using since it looks something like:

01110110
01101101
10101111
00110000
00010101

Early programmers actually used to write their programs in that sort of a style - but luckily they soon learnt how to create programs that could take something written in a more understandable language and translate it into this gobbledy gook. These programs are called compilers and you can think of them simply as translators that can read a programming language, translate it and write out the corresponding machine code.

Compilers are notoriously pedantic though - if you don't write very correct programs, they will complain. Think of them as the strictest sort of English teacher, who picks you up on every single missing comma, misplaced apostrophe and grammatical error.

Debugging

This is where debugging makes it first appearance, since once the compiler has looked at your program it is likely to come back to you with a list of mistakes as long as your arm. Don't worry though, as this is perfectly normal - even the most experienced programmers make blunders.

Debugging is simply the task of looking at the original program, identifying the mistakes, correcting the code and recompiling it. This cycle of code -> compile -> debug will often be repeated many many times before the compiler is happy with it. Luckily, the compiler never ever gets cross during this process - the programmer on the other hand...

It should also be said at this point that it isn't actually necessary to write the entire program before you start to compile and debug it. In most cases it is better to write a small section of the code first, get that to work, and then move on to the next stage. This reduces the amount of code that needs to be debugged each time and generally creates a good feeling of "getting there" as each section is completed.

Finally though, the compiler will present you with a program that the computer can run: hopefully, your solution!

Solution!

The final step in the grand programming process is that of testing your creation to check that it does what you wanted it to do. This step is unfortunately necessary because although the compiler has checked that your program is correctly written, it can't check whether what you've written actually solves your original problem.

This is because it is quite possible to write a sentence in any language that is perfectly formed with regards to the language that it's written in (syntacticly correct) but at the same time be utter nonsense (semantically incorrect). For example, 'Fish trousers go sideways.' is a great sentence - it's got a capital letter and a full stop - but it doesn't mean a lot. Similarly, 'Put the ice cube tray in the oven.' has verbs and nouns and so on - but it's pretty useless if you wanted to make ice cubes.

So your program needs to be tested, and this is often initially done informally (or perhaps, haphazardly) by running it and playing with it for a bit to see if it seems to be working correctly. After this has been done, it should also be checked more thoroughly by subjecting it to carefully worked out set of tests that put it through its paces, and check that it meets the requirements and specification - but we shall discuss this more later on in the course.

Where mistakes are identified, it is a case of donning a Sherlock Holmes hat and trying to figure out where in the code the mistake is. Once identified, the problem should be fixed by changing the code and recompiling. Care should be taken at this point that this fix doesn't break something else, so careful retesting is important. This process is also known as debugging.

Once all the testing and debugging has been completed, you should be pretty certain that your program works according to your requirements and your specification and so you should finally have a solution to your problem!

Easy isn't it?!

Summary

  1. Identify the Problem - What Are You Trying To Do?
    • Requirements
    • Specification

  2. Design a Solution - How Is It Going To Be Done?

  3. Write the Program - Teaching the Computer
    • Code
    • Compile
    • Debug

  4. Check the Solution - Testing it Understands You

While this may sound like a great deal of effort to go to to build a simple program, don't worry, as after a while it will become second nature, and for small programs, most of the stages can be done in your head.

The next section will introduce you to your first programming language, and your very first program!