NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/object/5111

Internet Message Format | 1993-01-28 | 5.3 KB

Xref: sparky comp.object:5111 comp.software-eng:5505 comp.lang.c++:20088
Newsgroups: comp.object,comp.software-eng,comp.lang.c++
Path: sparky!uunet!rational.com!thor!rmartin
From: [e-mail] (Bob Martin)
Subject: Re: How About Using Bootch for Analysis?
Message-ID: <rmartin.728266476@thor>
Sender: [e-mail]
Organization: Rational
References: <[e-mail]>
Date: Fri, 29 Jan 1993 00:14:36 GMT
Lines: 97

[e-mail] (Mike Mac Cormack) writes:

>1) Can you use Bootch for both analysis and design?  The first 3 steps of
>his method are almost identical to Coad/Yourdon's OOA.

The Booch notation and method are extremely well suited to OOA and OOD
both.  However, the important thing is to understand what OOA and OOD
are.

Analysis (Structured or OO) is the practice of converting a
requirements document into a functional specification.  A requirements
document is a list of behaviors required of the software product.
Such a document is necessarily incomplete and even contradictory.  A
functional specification is a detailed, precise and unambiguous
statement of the behaviors of the software product.  (At least that's
what it's supposed to be! :-)

OOA is the exploration of the *behavior* of the software product.
(Which objects send what messages to which other objects and when)  OOD
is the exploration of the static structure of the system (Who inherits
from who, who contains who, who uses who) and how that static
structure can be inserted into a physical environment (Multiple
processors, operating systems, etc.)

Both of these tasks take place concurrently.  Although we start out
doing mostly analysis type activities, we very rapidly begin doing
some design like activities.  As the development progresses we slowly
transition the ratio of analysis like activity to design like
activity.  Thus, although OOA and OOD are different, there is no clear
dividing line between them.  Instead there is a continuum between
them.  It's like a spectrum, although Red is different from Orange,
there is no clear dividing line between them.

The Booch notation is peculiarly adept at both the analysis parts and
the design parts of this activity.  This is becuase it put equal
weight on the dynamic and static modeling techniques.  Interestingly
enough, many of the so-called OOA notations do not support *any*
dynamic modeling, and so are not analysis tools at all.  They are more
design like.

In the Booch notation, object diagrams are used to map out the flow of
messages between objects.  This is a very important analysis activity.
It is one of the best ways to identify what objects are in the model,
and how they interact with each other.  Objects can't evolve in a
vacuum.  They most evolve based on their association with other
objects.  Thus, using the dynamic modelling provided by Booch's
object diagrams turns out to be an excellent way to model and evolve
objects.

Static modeling is also very important.  The static model describes
the structure and relationships of your classes.  This is the
progenitor of code.  Static structure cannot be developed in the
absence of a dynamic model.  You have to know who your objects talk to
in order to design the relationships between your classes.

Booch's class diagrams are probably the most expressive notation
(aside from code itself) for capturing the details of static
structure.  They can start out abstract and incomplete.  As time goes
on they can be fleshed out with many many adornments to capture design
details at both the high and low levels.

While static structure is driven by the behavioral model, it also has
a profound effect upon it.  Often you will alter your static model to
deal with one requirment, and this will force you to change your
dynamic model in another part of the design.

When you are done, you wind up with a static model which supports a
dynamic model.  The dynamic model is a set of behaviors which
implements the behaviors from the requirements document.  So you have
a clear path from the requirments document to the static structure.
And it is the static structure that drives the most important aspects
of the code.

>3) How about using Coad/Yourdon for analysis and Bootch for design?

One of the most significant disadvantages to Structured analysis and
design is that they use different notations.  This forces a
translation between analysis and design.  This keeps analysis and
design separate.  And they belong together.

I strongly recommend that you use the same notation for analysis and
design, and that you not separate your project into analysis and
design phases.  Keep the analysis and design together, and even
sprinkle a little coding in for good measure.  Do not manage your
project in phases (Analysis, Design, Code, Test) etc.  Instead manage
the project by slicing the project vertically in to the completion of
several features or behaviors of the project.  Each vertical slice
will require its own analysis, design, implementation and testing.
When each vertical slice is done, you can use the knowledge gained
about schedule and technology to help manage and complete the next
one.

--
Robert Martin       | Design Consulting    | Training courses offered:
R. C. M. Consulting | [e-mail] |  Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: [phone]  |  Object Oriented Design
Green Oaks, Il 60048| Fax: [phone]  |  C++