Java Reference
In-Depth Information
■
Note
Many different development methodologies are used in varying degrees in the software industry.
Some of the commonly used design approaches are the Iterative Process, the Rational Unified Process, the
Boehm Spiral Model, and XP (Extreme Programming). In this topic, we are using another common model: the
Waterfall Model. As its name implies, this design model requires that development be an ongoing process,
with one version of software based on a previous version, and so on. In addition, requirements are deter-
mined before project design and development begin in this model. The SCJD exam allows unlimited time to
complete the project, and it requires that you work as a single developer. Both of these special criteria set
forth in the SCJD exam fit perfectly into the Waterfall methodology.
Design is a fluid process that is grounded by coding. The best way to begin a project
design is to explore the technical challenges ahead by coding a little, designing a little, and
coding some more. In this respect, project design becomes an iterative process. Some sug-
gested principles follow.
Getting Started
As a first step, spend a little time verifying your understanding of the requirements. Read the
material several times and scrutinize its contents. Explore the logical breakdown of function-
ality and document your assumptions. Make sure that you note the umbrella activities that
encompass several different variations under a given topic. This often helps with the package
structure design. For example, it might make sense to have a GUI package that is responsible
for visual presentation.
Gathering Requirements
Requirements are functions of a project that the client wants in the system you are creating.
The requirements should detail everything that the system is required to do. Our suggestion is
to ask questions. Better yet, ask a lot of questions. Write down the questions before you formu-
late answers, and ensure that they make sense. For the sake of clarity, phrase them differently
and ask them again. It is probably best to be thought a little slow at the beginning of a project
than to be proven careless at the end.
Confirm all assumptions either in writing or as a GUI layout. Of course, on this project,
you are not going to be able to ask anyone your questions, but that should not prevent you
from articulating potential issues and project risks. As a matter of fact, it should encourage
you to formulate questions to organize your thoughts.
■
Note
Chapter 3 introduces some example use cases derived from project requirements. Chapter 8 pres-
ents a full example of dealing with use cases and their translation to project functionality.
