We've learned some of the basics of the Java programming language, but we've yet to learn how to write a piece of software. We've written some small snippets of code, but the complexity of writing software grows very quickly as the size of the software necessary to solve a task increases.
This is one of the reasons that Java was designed in the manner that it was -- to help us with the complexity of writing large pieces of software. In this section, we'll talk about how to approach a 'real' problem, and illustrate these 'how to approach it' ideas by going through a sizeable example.
The overall approach is one that has been borrowed from other areas of engineering; it is called the waterfall model of software development. There are other models, and if you continue in computer science you'll study a subject called Software Engineering which will discuss models for the production and maintenance of software in more depth. For now we'll just look at the basics of one model.
The waterfall method gets its name from the following diagram:
The idea is that the process starts with a specification of the software to be built, followed by the design, implementation, and verification stages. The specification describes what the software should do, the design describes how it should do it, the implementation is a translation of the design into code, and the verification stage involves a) making sure that there are no bugs in the program, and b) making sure that the final product does in fact fulfill the original specifications.
As is suggested by the orientation of the arrows, the process is supposed to 'flow' in only one direction -- like a waterfall. However, in most real situations the situation would be better drawn like this:
In this situation, we can go from a later stage to an earlier stage. This often happens because specifications tend to be either incorrect or not detailed enough which can lead the design team to ask to have the specifications revised. Or after the design is completed, it may become apparent during the implementation stage that there was an oversight in the design, necessitating redesign and re-implementation. The verification stage may turn up flaws in the implementation, the design, or may show that the specification was incorrect, necessitating a jump back to any of these stages.
At any rate, this is roughly how things are done within this model, and we'll use this model to develop a Student Registration System in the next sections.
