THE FOLLOWING QUESTIONS BEING ASKED QUITE OFTEN?

• Are there any differences between OOAand OOD? If so, what are they?

Yes, there are differences. OOA is the act of determining the
abstractions which unerly the requirements. It is the backwards
reasoning that starts with the requirements and ends up with a set of
objects that express the abstractions; and messages that support the
required behaviors. OOD embodies the set of decisions that
determines how those objects and methods will be implemented.
Typically class inheritance and composition hierarchies are among
those design decisions.

OOA exposes the components of the required behaviors, in order that
they may be implemented. On the other hand, OOD hides the details
of the implementation so that those details do not pollute the rest of
the design.

Despite the differences, however, OOA and OOD are simply at
opposite ends of the same activity. Moreover, there is no good
dividing line which separates them, either in time or in function. It is
better to view OOA and OOD like the different colors in a spectrum.
They are certainly different, but it is difficult to tell when one starts
and the other leaves off. OOAD is a continuum of activity which
incorporates both analysis and design.

• Should we do OOA first, followed by OOD?

No, they are best done concurrently. Analysis and Design should not
be separated into broad phases. Nor should the analysis model be
frozen before the design modeling begins. It should be evident from
our case study that OOA and OOD are very closely related, and that
they cooperate synergistically. The analysis model cannot be
completed in the absence of the design model. And the design model
cannot be completed in the absence of the analysis model. One of the
most important aspects of OOAD is the synergy between the two
concepts.

• What is a reasonable output from OOA, OOD?

At very least a set of class and object diagrams. The class diagrams
show the static structure of the application. It is from these diagrams
that class headers can be written. Object diagrams show the
dynamics of the collaborations between objects. It is from these
diagrams that the class implementations will be written.
However, in large projects these meager beginnings are hardly
adequate. There is much that we have not covered in this simple case
study. We have not discussed how to organize the analysis and
design of a large program. How to control large scale visibility.
How to control the physical model so that a large project can be
developed and released in an organized and well managed way.
These topics are important parts of the OOAD universe, and should
not be neglected.

• Are there different notations for OOA and OOD?

Yes and No. OOA, since it is based on the analysis of required
behaviors, tends to focus on the behavioral model. Thus tit places
more emphasis on the generation of object diagrams. We saw this in
the case study. In every case, the central abstraction for each
requirement was documented, first, by an Object Diagram.
Conversely, since OOD focuses on finding static structures which
support the required dynamics, it tends to focus on class diagrams.
However, there are certainly plenty of cases where class diagrams are
produced by OOA activities and object diagrams are produced by
OOD activities.

One of the great advantages of OOAD over other analysis and design
techniques is that the notation for analysis is compatible with the
notation for design. In fact, only one set of documents is maintained.
We do not separate them into “analysis documents” and “design
documents".