Program Design consists of the steps a programmer should do before they start coding the program in a specific language. These steps when properly documented will make the completed program easier for other programmers to maintain in the future. There are three broad areas of activity:
- Understanding the Program
- Using Design Tools to Create a Model
- Develop Test Data
Understanding the Program
If you are working on a project as a one of many programmers, the system analyst may have created a variety of documentation items that will help you understand what the program is to do. These could include screen layouts, narrative descriptions, documentation showing the processing steps, etc. If you are not on a project and you are creating a simple program you might be given only a simple description of the purpose of the program. Understanding the purpose of a program usually involves understanding it's:
This IPO approach works very well for beginning programmers. Sometimes, it might help to visualize the programming running on the computer. You can imagine what the monitor will look like, what the user must enter on the keyboard and what processing or manipulations will be done.
Using Design Tools to Create a Model
At first you will not need a hierarchy chart because your first programs will not be complex. But as they grow and become more complex, you will divide your program into several modules (or functions).
The first modeling tool you may have learned is pseudocode (we will talk a bit more about this in a moment). This allows you to document the logic or algorithm of each function in your program. At first, you usually have only one function, and thus your pseudocode will follow closely the IPO approach mentioned above.
There are several methods or tools for planning the logic of a program. They include: flowcharting, hierarchy or structure charts, pseudocode, HIPO, Nassi-Schneiderman charts, Warnier-Orr diagrams, etc. Some classes make you do flowcharting and pseudocode. While these can be useful, in my 35+ years of working in the computer industry there was only one project where any type of flowchart was attempted. Several standards exist for flowcharting and pseudocode and most are very similar to each other. However, most companies have their own documentation standards and styles. Programmers are expected to be able to quickly adapt to whatever software development standards the company they work for uses. The others methods that are less universal require some training which is generally provided by the employer that chooses to use them.
Understanding the logic and planning the algorithm on paper before you start to code is very important concept. Many students develop poor habits and skipping this step is one of them. A good concept that I have found useful is to write simple comments as to how the code should flow - this is somewhat of a psuedocode approach, but you kind of develop your own terminology and ideas.
It is important to think about your code BEFORE you start writing it....