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.
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.
CRC cards and the associated methodology are described
in detail in Appendix G,
The CRC Card Methodology
They are used again in the design phase and are further
discussed in Chapter 6,
The strength of CRC cards during analysis.
Common Project Vocabulary -
Spread Domain Knowledge -
Making the Paradigm Shift -
Live Prototyping -
Identifying Holes in Requirements -
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
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.