Analysis is the process of taking the
“customer” requirements and re-casting them in the
language of, and from the perspective of, a putative
solution.

We are not actually trying the flesh out the detailed
solution at this stage. That occurs in the Design
Phase (see Chapter 6, Design).

Unlike the boundary between Requirements and Analysis
Phases, the boundary between Analysis and Design Phases is
inherently blurred. The key is that analysis should define the
solution no further than is necessary to specify the
requirements in the language of the solution. The model elements in
Analysis generally represent a high level of abstraction.

Once again the recursive, and
iterative nature of our process means we
will come back to the Analysis phase many times in the
future.

5.1. The Analysis Process

There are three schools of thought on how Analysis
should be approached.
The ontologist defines the data (actually the metadata)
first and worries about processes later.
The true ontologist would prefer not to have to think
about processes at all.
The phenomenonologist reverses this and favors
process over data.
The panparadigmist considers both process and data to be
equally important and addresses both from the start.

When it comes to being a purist the ontologist has
the upper hand.
It is possible to define and build a database into
which data can be entered and retrieved without concern for
what happens to it or is done with it.
On the other hand implementing a process without having any
data structures for it to operate on is not very meaningful.

5.1.1. Class, Responsibilities, and Collaborators (CRC) Cards

The CRC methodology favors the phenomenonologists
preference for analysis.
It is the equivalent of starting with the use cases,
the process aspects (operations) of the class diagrams,
and scenarios from which sequence diagrams can be initiated.

In this phase the group should consist of two or
three domain experts, one object-oriented technology
facilitator, and the rest of the group made up of people
who are responsible for delivering the system.

The first time that the Analysis phase occurs a special
case of the CRC session happens as there are no classes
or scenarios to choose from to define a CRC session.
At this point a special type of session known
as brainstorming is held.
During this session you identify the initial set of
classes in the problem domain by using the problem statement
or requirements document or whatever you know about the
desired result for a starting point.
The nouns that are found in whatever you are starting from are
a good key to an initial set of classes in the system.
In a brainstorming session there should be little or no
discussion of the ideas.
Record them and filter the results after the brainstorming.
At this stage the distinction between class and object
is blurred.

Once a reasonable set of classes has been defined
by the group, responsibilities can be added.
Add responsibilities that are obvious from the requirements
or the name of the class.
You don't need to find them all (or any for that matter).
The scenarios will make them more obvious.
The advantage of finding some in the beginning is that
it helps provide a starting place.

Select the initial scenarios from the requirements document
by examining it's verbs in much the same way that we scanned
its nouns earlier.
Then as many walk through sessions as necessary to complete
the analysis phase are performed.

When is enough of the analysis complete that design can begin?
When all the different responsibilities are in place
and the system has become stable.
After all the normal behavior has been covered, exceptional
behavior needs to be simulated.
When you notice that the responsibilities are all in place to
support the new scenarios, and there is little change to the
cards, this is a sign the you are ready to start design.

5.1.2. Concept Diagram (To be written)

To be written...

5.1.3. System Sequence Diagram (To be written)

To be written...

5.1.4. System Statechart Diagram (To be written)

To be written...

5.1.5. Realization Use Case Diagram (To be written)

To be written...

5.1.6. Documents (To be written)

Use Case Specifications and Supplementary
Requirements Specifications recast in solution language. To
be written...