Almost everybody learns the program nowadays through just a minor course, using just one particular programming language, through fun exercises, and using all kinds of technologies. After this course, a lot of them think they can really program, that that particular language is the programming language, and that they master high-end technologies.
In fact, they just learnt to mock up some program without any knowledge of computational models, memory models, machine models, etc. But a more important issue is that they did not learn how to design a program, they did not make any sketch at all of what the behaviour of the program should be and how they want it to implement in the programming language.
We address these problems and others in more detail.
What really is missing is a step-by-step plan, a development process. Here, we set out to give a base for understanding what programming really is, and to establish a minimal software development process.
What is a program?
A program is a design expressed in a particular programming language. It is not software. Software is something a computer can execute. A program is translated into something a computer can execute. This translating is either than externally by a compiler after which it can be executed by a system, or internally by a system that executes the code directly. So, we do not build a program, but we design it. And we build the software from this program (fully automated).
However, we can make a design for a program (on a higher level of abstraction), from which we make an implementation of the program. In this context we speak of building a program, also called programming.
How to program?
If you want to build a house, you probably make a sketch of how you think it should look like. At first it has not much detail at all. Later, you add some details of particular parts of the house. This is the first part of the design of the house.
With building a program, there is no difference. You start with sketching and add more details later.
For building a shed or a doghouse you can get away with mocking up something, mostly based on the materials you have at hand at the moment. But if you want it too last, you need a certain quality, not only from the materials used, but also from the construction, and the process (design of the construction, selection of the materials, etc).
With building a program, there is no difference.
Off course, when you have enough experience, you can get away with following some shortcuts in the process.
With building a program, there is no difference.
SketchingBut how do we sketch a program? You can use pseudo-code.
Pseudo-codePseudo-code is not real code but it gives us the possibility to add some structure to our thoughts, and that can be refined later on.
What does pseudo-code look like? Well, anything you want, but it is much more useful if it looks anything like real code. Not code in a particular programming language, but code that can be refined into several different programming languages.
Structure diagramsThe pseudo-code can be combined with program structure diagrams (psd) in the form of Nassi-Schneidermann diagrams, giving a graphical representation of the design. The downside however is that modifications of the code often require a redrawn of the diagram, so a special editor for the diagrams may come in handy.
ImplementationAn implementation in a particular programming language should follow the sketches and/or diagrams, such that he resulting code is a refinement of the sketches.
When on implementing it is found that the sketches contains faults, the
sketches have to be corrected and the implementation has to be adjusted to
the improved sketches.
It is also possible that the resulting code does not meet some requirement that has or could not be taken into account with the sketches. In which case the sketches should be altered so that an implementation of this does meet the requirement.
It is of no coincidence that a programming language contains constructs that look similar to the constructs that are used in the pseudo-code. That is because the programming language is meant to support these kind of constructs. And it is definitly not the other way round, that you are working towards using particular constructs of the programming language.
Software Development ProcessWe now have a software development process in which we can find three descriptions with different level of detail: one the sketches, two the program, and three the software (compiled program). Where the program is a refinement of the sketches, and the software is a refinement of the program. And the other way, the program is an abstraction of the software, and the sketches are an abstraction of the program. These abstractions ease up the design process, as we do not have to bother how these abstraction are to be implemented at a lower level of abstraction.
It all comes down every time to two questions: What?, and How?.
- What is the program supposed to do?
- How are we going to do that? (sketches)
- What do we have to implement? (follows from the sketches)
- How are we going to implement it?
This software development is suitable for rather small projects, but depending on the skills of the developer(s), can be used for larger projects. But in general, more is needed for larger projects. For more on this subject we refer to Software Design.