You are on page 1of 16

PROGRAM

MING KEY
CONCEPTS
PART 1: PROBLEM SOLVING PHASE
PHASES OF PROGRAMMING
 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.
1. 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.
2. 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.
 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.
 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:

 BEGIN
 PRINT welcome message
 PRINT instructions
 PRINT [number]>
 READ first_number
 PRINT [+-/*]>
 READ the_operator
 PRINT [number]>
 READ second_number
 calculate result of using the_operator on

the first_number and the second_number


 PRINT result
 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.
3. 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.
 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.
 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.
 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.
 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.
4. CHECK THE 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 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 (syntactically 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.
 So, your program needs to be tested, and this is often initially done informally 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.
 Where mistakes are identified, it is a case of 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!
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

You might also like