Introduction to C Programming by Rob Miles, Electronic Engineering
I tell people I am a "Software Engineer".
Programming is a black art. It is the kind of thing that you grudgingly admit to doing, at night, with the blinds drawn and nobody watching. Tell people that you program computers and you will get one of the following responses:
Programming is defined by most people as earning huge sums of money doing something which nobody can understand.
Programming is defined by me as deriving and expressing a solution to a given problem in a form which a computer system can understand and execute.
One or two things fall out of this definition:
There are many things you must consider when writing a program; not all of them are directly related to the problem in hand. I am going to start on the basis that you are writing your programs for a customer. He or she has problem and would like you to write a program to solve it. We shall assume that the customer knows even less about computers than we do!
Initially we are not even going to talk about the programming language, type of computer or anything like that, we are simply going to make sure that we know what the customer wants. Coming up with a perfect solution to a problem the customer has not got is something which happens surprisingly often in the real world.
You might think that this is not necessary if you are writing a program for yourself; there is no customer to satisfy. This is not true. Writing an FDS forces you to think about your problem at a very detailed level.
Consider the scenario; You are sitting in your favourite chair in the pub contemplating the universe when you are interrupted in your reverie by a friend of yours who sells double glazing for a living. He knows you are a programmer of sorts and would like your help in solving a problem which he has:
He has just started making his own window units and is looking for a program which will do the costing of the materials for him. He wants to just enter the dimensions of the window and then get a print out of the cost to make the window, in terms of the amount of wood and glass required.
"This looks like a nice little earner" you think, and once you have agreed a price you start work. The first thing you need to do is find out exactly what the customer wants you to do...
When considering how to write the specification of a system there are three important things :
There are lots of ways of representing this information in the form of diagrams, for now we will stick with written text when specifying each of the stages:
Information going in
In the case of our immortal double glazing problem we can describe the information as:
Information coming out
The information that our customer wants to see is :
What the program actually does
The program can derive the two values according to the following equations :
glass area = width of window * height of window wood length = (width of window + height of window) * 2
Putting in more detail
We now have a fairly good understanding of what our program is going to do for us. Being sensible and far thinking people we do not stop here, we now have to worry about how our program will decide when the information coming in is actually valid.
This must be done in conjunction with the customer, he or she must understand that if information is given which fits within the range specified, your program will regard the data as valid and act accordingly.
In the case of the above we could therefore expand the definition of data coming in as :
Note that we have also added units to our description, this is very important - perhaps our customer buys wood from a supplier who sells by the foot, in which case our output description should read :
If I give the above program the inputs 2 metres high and 1 metre wide the program should print out : 2 square metres of glass and 9.75 feet of wood.
The test procedure which is designed for a proper project should test out all possible states within the program, including the all important error conditions. In a large system the person writing the program may have to create a test harness which is fitted around the program and will allow it to be tested. Both the customer and the supplier should agree on the number and type of the tests to be performed and then sign a document describing these.
Note also in a "proper" system the customer will expect to be consulted as to how the program will interact with the user, sometimes even down to the colour of the letters on the display! Remember that one of the most dangerous things that a programmer can think is "This is what he wants"! The precise interaction with the user - what the program does when an error is encountered, how the information is presented etc., is something which the customer is guaranteed to have strong opinions about. Ideally all this information should be put into the specification, which should include layouts of the screens and details of which keys should be pressed at each stage.
The customer thinks that this is great, reminiscent of a Saville Row tailor who produces the perfect fit after numerous alterations. All the customer does is look at something, suggests changes and then wait for the next version to find something wrong with.....
Again, if I could underline in red I would : All the above apply if you are writing the program for yourself. You are your own worst customer!
You may think that I am labouring a point here, the kind of simple systems we are going to create as we learn to program are going to be so trivial that the above techniques are far too long winded. You are wrong. One very good reason for doing this kind of thing is that it gets most of the program written for you - often with the help of the customer. When we start with our double glazing program we now know that we have to :
read in the width verify the value read in the height verify the value calculate width times height and print it calculate ( width + height ) * 2 * 3.35 and print it
The programming portion of the job is now simply converting the above description into a language which can be used in a computer.......
You might ask the question "Why do we need programming languages, why can we not use something like English?" There are two answers to this one:
Programming languages get around both of these problems. They are simple enough to be made sense of by computer programs and they reduce ambiguity. There are very many different programming languages around, you will need to know more than one if you are to be a good programmer.