In this process, each stage of the process—requirements, analysis, design and build (code and test) is completed before the next one starts. This is illustrated in Figure 3.1, “The Waterfall Process”.

Figure 3.1. The Waterfall Process

This is a very satisfactory process where requirements are well designed and not expected to change, for example automating a well proven manual system.

The weaknesses of this approach show with less well defined problems. Invariably some of the uncertainties in the requirements will not be clarified until well into the analysis and design, or even code phases, requiring backtracking to redo work.

The worst aspect of this, is that working code does not become available until near the end of the project, and very often it is only at this stage that problems with the original requirements (for example with the user interface) become apparent.

This is exacerbated, by each successive stage requiring more effort, than the previous, so that the costs of late problem discovery are hugely expensive. This is illustrated by the pyramid in Figure 3.2, “Effort Involved in the Steps of the Waterfall Process”.

Figure 3.2. Effort Involved in the Steps of the Waterfall Process

The waterfall process is still probably the dominant design process. However because of its limitations it is increasingly replaced by iterative processes, particularly for projects where the requirements are not well defined.

In recent years a new approach has been used, which aims to get at least part of the code up and running as quickly as possible, to bring discovery of problems forward in the development cycle.

These processes use a series of “mini-waterfalls”, defining a few requirements (the most important) first, taking them through analysis, design and build to get an early version of the product, with limited functionality, related to the most important requirements. Feedback from this can then be used to refine the requirements, spot problems etc before more work is done.

The process is then repeated for further requirements to construct a product with a step up in functionality. Again further feedback can be applied to the requirements.

The process is repeated, until eventually all requirements have been implemented and the product is complete. It is this iteration that gives these processes their name. Figure 3.3, “Effort Involved in the Steps of an Iterative Process” shows how this process compares to the pyramid structure of the Waterfall Process.

Figure 3.3. Effort Involved in the Steps of an Iterative Process

The growth in popularity of iterative processes is closely tied to the growth of OOA&D. It is the clean encapsulation of objects that allows a part of a system to be built with stubs for the remaining code clearly defined.

3.2.1.2.1. The Rational Unified Process

Perhaps the best known Iterative Process is the Rational Unified Process (RUP) from Rational Software ( www.rational.com).

This process recognizes that our pyramid view of even slices of the waterfall is not realistic. In practice the early iterations tend to be heavy on the requirements end of things (you need to define a reasonable amount even to get started), while the later iterations have more of their effort in the design and build areas.

RUP recognizes that iterations can be grouped into a number of phases according to their stage in the overall project. Each phase may have one or more iterations.

• In the inception phase iterations tend to be heavy on the requirements/analysis end, while any build activity may be limited to emulation of the design within a CASE tool.

• In the elaboration phase iterations tend to be completing the specification of the requirements, and starting to focus on the analysis and design, and possibly the first real built code.

• In the construction phase iterations the requirements and analysis are more or less completed, and the effort is mostly in design and build.

• Finally, in the deployment phase iterations are largely about build activity, and in particular the testing of the software.

	Note
	It should be clear that testing is an integral part of all phases. Even in the early phases the requirements and design should be tested, and this is facilitated by a good CASE tool.

We shall use an iterative process in this manual, that is loosely based on the RUP.

Very few software systems are conceived as monolithic artifacts. They are broken down into subsystems, modules etc.

Software processes are the same, with early parts of the process defining a top level structure, and the process reapplying to parts of the structure in turn to define ever greater details.

For example the initial design of a telephone system might identify objects to i) handle the phone lines, ii) process the calls, iii) manage the system and iv) bill the customer. The software process can then be reapplied to each of these four components to identify their design.

OOA&D with its clean boundaries to objects, naturally supports this approach. Such OOA&D with recursive development is sometimes abbreviated as OOA&D/RD.

Recursive development can be applied equally well to waterfall or iterative processes. It is not an alternative to them.

Our requirements capture will use the UML concept of Use Cases. Starting with a Vision Document we will see how Use Cases can be developed to describe all aspects of the system's behavior in the problem domain.

During the analysis stage, we will introduce the UML concept of classes to allow us to build a top level view of the objects that will make up the solution—sometimes known as a concept diagram.

We will introduce the UML sequence diagram and statechart diagram to capture requirements for the overall behavior of the system.

Finally we will take the Use Cases from the requirements capture stage, and recast them in the language of the solution domain. This will illustrate the UML ideas of stereotyping and realization.

We use the UML package diagram to organize the components of the project. We then revisit the class diagram, sequence diagram and statechart diagram, to show how they can be used recursively to design the complete solution.

During this part of the process, we need to develop our system architecture, to define how all the components will fit together and operate.

Although not strictly part of our process, we'll look at how the UML collaboration diagram can be used as an alternative to, or to complement the sequence diagram. Similarly we will look at the UML activity diagram as an alternative or complement to the statechart diagram.

Finally we shall use the UML deployment diagram to specify how the system will actually be realized.

UML is not really concerned with code writing. However at this stage we will show how ArgoUML can be used for code generation.

We will also look at how the UML Use Case Diagram and Use Case Specification are invaluable tools for a test program.