During this phase two main activities are performed:
selection of the system's software architecture, and
the planning of the development.
The increments are defined as a consequence of the problem analysis and
based on the architecture defined for the system. Each increment consists of
the analysis and design of a set of architectural components and leads to the
implementation of a prototype that tests their functionalities.
A new iteration is started with every increment. The rationale for the
choices made during the definition of models is provided and a generic
approach is used whenever possible (i.e. in analysis, identification of nouns
and verbs is important).
The models are developed incrementally and evolve from a simple
intuitive solution to a pattern-oriented, smart, optimal solution.
Assessment of the design is performed at each iteration. Such assessment
represents the rationale for design evolution in the next iterations.
Each iteration is a sequence of four activities:
Analysis . This consists in the identification of classes and relationships.
The process is described and motivated step by step. When a large model is
considered, it is allowed to “skip some low-level step”. The artifacts of the
analysis are mainly: object diagrams, class diagrams and detailed use cases.
Design . We adopt a flow of thoughts approach: we start with an initial
solution that is the most obvious and intuitive and is defined using only
the “design vocabulary” that the reader has acquired so far. The “design
vocabulary” is the one provided by the preceding parts of the topic or the
initial knowledge of the reader, who is required to know the basic con-
cepts of generic object-oriented analysis, design and Java programming.
Then the solution is evolved into a smarter and better one: new develop-
ment techniques and design models are introduced, which have proven to
be effective in solving similar problems.
Implementation . We adopt the Java coding conventions described in Sun
Microsystems (see References at the end of the chapter). Getter and setter
methods have a “get” or “set” prefix respectively. Parameters which are
intended to be copied into attributes should have the same name.
Exceptions to these rules are admitted when appropriate.
Test . Test cases are defined in order to exercise the components'
Each chapter ends with a summary of the relevant issues encountered in the
development process of the case study application. The assessment section