Aug 02 2009
The Work of the Programmer
The programmer is the one who turns the designs of the analyst into software to be used with the new system. His job is to design and code the list of instructions that tell the computer what to do. Sometimes a programmer may well take on the job of a systems analyst, in which case he is an analyst programmer. Normally the programmer works as part of a project team under the supervision of a project leader, who will allocate parts of the project to the members of the team. The project leader will be responsible for the whole suite of programs, with the individual programmers working on individual programs or sub-systems.
Once the systems analysts have completed the design, it’s the programmers who create, code, and test the programs. The detail of the design depends on the relationship between the analysts and the programmers, i.e. who does what. Most companies set up a methodology, a formal set of procedures and aids used to develop systems, i.e. we do it this way. Therefore the systems are developed under the same set of rules which avoid problems and sets the standard known and understood by all.
Sometimes methodologies dictate that the analysts produce a design so detailed that the programmers just do the coding in the appropriate language. Other methodologies leave the detailed planning to the programmers who use program design methodologies to produce logical steps for each action in the program.
Whatever the methodology, there are some common factors:
- Programs are split up into small manageable modules, each of which performs a discrete function, as far as possible.
- The modules are executed in order defined by a control procedure.
- Programs are designed top-down or bottom-up.
When programs are designed bottom-up, the programmer identifies all the individual actions that need to be done, and places these into self-contained modules. The higher levels in the program are then designed, and these execute the modules in the correct order. These higher levels are placed in the final structure at the appropriate place.
In the top-down approach, the problem is defined at the highest level, and worked on through successively lower levels, each stage being refined more and more until the detailed solution is arrived at.
Program designs are often represented as a tree like structure read in a top-down manner. As we go down the tree, each level is an expansion of the box in the previous level. An example of a structure chart (or structure diagram) is shown below.
The * in the corner of the main process loop box means a repetition, i.e. many records are to be processed. The o shows a choice, one or the other, but not both, and indicates only one option path alone can be followed.
We should also note that at each branch at each level, the order of processing goes from left to right. This means that in the initial process the open files command must come before the print report headings command is used. We can see that each box is expanded at a lower level to give more detail. We might consider that the box print record details needs further expansion. Is it information of all the record, or just some fields? This process continues until the programmer decides that sufficient detail is provided. This is called functional decomposition.
The structure chart shows how a program can be modularized. The topmost level can be regarded as being the main control procedure in the finished program, and this can be broken down into three separate parts or procedures. The programmer works on each as a separate unit that will be put together as a complete program, and he must know how it will be put together. It’s like breaking down the power unit of a car to engine, gearbox, differential, and drive shafts. It would be no good if the engine could not fit onto the gearbox.
The use of stepwise refinements is another methodology. This is like a structure chart without the boxes or connecting lines. We can still achieve the modular solution by defining outline procedures, and these can be refined further. The refining stops when sufficient detail is reached.
Refinement 1
- Do initial process
- Do main process loop until file has ended
- Do final process
- End program
Refinement 2.1 – Initial Process
- Open files
- Print report headings
Refinement 3.1 – Main Process Loop
- Read a record from the data file
- If at end of file, then display “END-OF FILE” message
- Else
- Do process record
- End if…
And so on…
Each instruction is written in a form of structured English called pseudo-code, which does not relay on the syntax of any particular language; it is language independent. Therefore the systems analyst who designed the specification does not necessarily need to know the language it’s going to be programmed in. The analyst and the programmer can discuss the application using the pseudo-code and can iron out any problems at this stage.
This kind of planning allows problems to be identified at an early stage before everything is put onto computer and tested. Sorting out problems (debugging) once they are in the computer is most very tedious.
NEXT: Role of Computer Staff