Systematic and Structured Programming

The Update

You have now been using the Four Step Programming Process for a while, and you should be familiar enough with it to know that it makes programming easier, and that you will spend much less time with your programs then you would if you were trying to hack, fix, test, and hack your programs again (and again). As mentioned earlier, this is not the only way to design or develop a program. However, it is a system designed not only to create quality programs but to lead new programmers to these quality programs with less fear or difficulty.

The arguments for using a system like this are plentiful, and you have seen them previously. However, they are important, and deserve as much airtime as they can get, so they are presented here for your review:

1. It is true that most people can slap together trivial programs without working their way through a design and development process. As long as you plan to write trivial programs -- which might get them about halfway through most introductory programming courses (and nowhere in industry) -- hacking will work, at least to some extent. If you intend to write non-trivial programs, and possibly even get paid for it, you simply must have an organized and refined strategy for doing so


2. The number two goal for a quality program is that it works. The number one goal is to write programs that other people can read and understand without spending very costly hours trying to figure out what it was you were trying to do. You can no more guarantee that your program is bug-free than you can guarantee that it won't rain. On the other hand, you CAN guarantee well-organized and effective program design and documentation, especially if you start with a well-organized and effective development process. Finally, you should be aware that for most products, including software, the working life of the software will be much longer than the development time, assuming your software product was of good quality. This means that in industry, much more time -- and money -- is spent on maintenance than on development


3. There are rumors that students taking introductory programming courses are actually enrolled in other courses. If this is true and you prefer to hack your way through programs, taking other courses is very foolish. However, if you plan on taking this course and others all at the same time, you had better have an organized and systematic way to design and develop your programs (and for some introductory courses, it must be this one). There is simply not enough time, with or without sleep, to try to hack programs together and remain coherent and reasonably healthy (and then there's that GPA thing . . . )


4. The best has been saved for last: The number one problem students have with introductory programming classes is that they get psyched out by how "hard" it appears to be to write non-trivial programs. Truth: It IS really hard to write readable, quality programs that work. However, just as it would be rather foolish to build a four-story building in an afternoon without any plans, it is just as silly to develop a non-trivial program under the same circumstances. One of the fundamental laws of programming is NEVER SOLVE BIG PROBLEMS. Whether you are fixing a leaky roof, or developing a massive database, no intelligent professional will try to do the whole thing at one sitting, and without advance planning. The smart ones will break the problems down into easily conquerable smaller components . . . and the others will flounder. There is no in between

The Process - Same Beginning, Different Ending

For completeness, the steps of the programming process are shown here. Steps One and Two are identically the same. However, things change in Step Three as you begin to design your own methods. Step Four is actually the same as before in that you will be implementing (writing) the code for the main method (only), but since you will still have methods to design and implement, Step Four will no longer be the end of the development process. From there forward, the process is all new. Take the time to go back through the review part so you will be comfortable when you get to the new stuff.

In step one, the entire program is written in no more than eight to ten English-language or pseudocode steps as comments in the main method area, as well as other areas where appropriate. Even though the whole program is written at a very high level without concern for the details – this is called abstraction – the program must be complete. That is to say, everything the program will do must be contained in the specified steps.

Step two simply takes the statements created in step one and breaks them down by placing “substep” statements under each step one statement. As was previously the case with step one, no group or block of statements should have more than eight to ten statements; the substeps should be broken down into further substep groups as needed to satisfy the requirements of that particular step. When step two is completed, the series of statements, substatements, and sub-substatements (as needed) should provide the developer with a complete step-by-step description of how the program will run at the main method level. At this point, the developer should be able to "run" the program in her head or on paper, and it should correctly solve the problem.

There will always be subroutines -- known as methods in the Java programming language -- in every program you observe or write from this point forward in this reference. Subroutines, subprograms, or methods are the tools that support your programming process by taking care of unique parts of the program. In your step three process, the methods must be specified (i.e., their specifications are written) and located (i.e., the location where the methods are called is specified) in step three.

Once you have identified and specified the methods as needed, method prototypes and stub methods are developed and placed in the program for the methods you will be writing. Throughout the program development process, you must compile frequently, and other than warnings that variables are set but not used, you should not have any other warnings or errors with each compile (or as you develop in Eclipse). Warnings and errors multiply each other and three or four problems may generate 30, 40, or more warnings and/or errors. Don't let them do this to you.

In step four, the main method is implemented (i.e., the actual program code is written for the main method).

The step five action is used to design the methods that were previously specified. Step five is considered a recursive process because the developer actually reuses steps 1, 2, and 3 to design these methods in the same way he developed the main program. When step five is complete, the solution to each method should be clearly stated in pseudocode, and any methods needed by the supporting methods are specified and designed. If new methods are developed for the supporting methods, they too are designed and developed using steps 1, 2, and 3.

Finally, step six is used to implement the code in the supporting methods. At the point of implementing step six, writing the code is pretty easy since the steps and design statements for all the methods have already been developed in step five.

Brief Summary. Here is the nutshell explanation of each step:

1. Write the major actions of the program in fewer than 8 to 10 steps; no code block at any level should have more than 8 to 10 steps


2. Expand on the major actions with more specific details related to each of the major steps; the programming solution is completed in English form


3. Design, specify, and locate the methods necessary to solve the problem. You will identify the use of others' methods, and you will also be developing the specifications, prototypes, and stub methods required by the design(s) and specification(s) for your own methods (as needed)


4. Using the previously developed steps, write the code for the main method; this is a complete, compilable, and runnable program. However, because you have not implemented your own methods, it will not work yet


5. Using the previously developed method specifications and comments, you will reuse steps 1, 2, and 3 to develop the programming solutions for each individual method in pseudocode/English. This includes designing and specifying any further methods required by the methods you have previously developed; this recursive process continues until all supporting methods contain all the pseudocode steps required to solve each of their individual tasks


6. Following the design and steps developed in step five, the code is written for the supporting methods, a process called implementing the method code

The simple fact is that if you learn to use this structured and systematic process for your program development, your programming tasks will be easier, they will take less time, and you will finish with a better quality programming product (and grade). As stated at the beginning of this topic, once you have completed this reference and/or a course you might be taking, you don’t have to use this exact programming process. However, if you don’t have some kind of comparable programming process, you will struggle.