Java Reference
In-Depth Information
frameworks). Most readers will read the parts sequentially and return to
specific parts as reference materials.
Domain oriented
. The case studies document the development of appli-
cations in three broad software domains: computer simulation of control
systems (Chapters 5, 9, 10, 11, 13), data processing (Chapters 3, 4, 6, 8,
18, 21) and information systems (Chapters 14, 15, 16, 19, 20). The reader
can browse the topic according to his or her interest in specific domains.
■
1.2
■
The process
Our intent is not to propose a new software development process, but to
present the reader with a consistent approach throughout the topic. We will
define a set of lightweight process guidelines that form a unifying framework
through all the case studies. The process that will be adopted is based on
incremental development. The structure of each case study chapter will
follow this development process, since we want to repeat, together with the
reader, the process of devising and implementing a solution for a problem.
Table 1.1 shows the phases of the development process.
1.2.1
Specification
The first section of each case study presents the description of the problem
from the customer's point of view.
1.2.2
Problem analysis
The information available during this phase consists of the requirements
specification. That artifact is mainly an unstructured document in natural
language containing the description of the system. This phase is made up of
three activities:
Analysis of the domain of the problem
. Often a system encompasses
several topics that fall into well-defined areas in which there are widely
accepted domain models or theoretical background. Such models must
be taken into account in order to solve the problem in the most effective
way.
■
Identification of main features
. The main features that the system is
required to exhibit are identified in the problem analysis phase. They are
tracked back to the issues presented in the requirement specification and
are described at a shallow level of detail. Features usually consist of
functional requirements, but if some other decomposition criteria are
obvious they can be adopted to define the features. If use cases can
provide clarity, they can supplement the textual description of the
requirements. An initial priority can be assigned to the features, possibly
based on some knowledge of the domain.
■
