Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!mrsvr.UUCP
From: brown@mrsvr.UUCP (Russ Brown)
Newsgroups: comp.object
Subject: Re: Yourdon's OOA text
Message-ID: <1140@mrsvr.UUCP>
Date: 6 Oct 89 14:24:12 GMT
References: <317@sierra.stanford.edu>
Sender: news@mrsvr.UUCP
Lines: 49

From article <317@sierra.stanford.edu>, by bryan@sierra.Stanford.EDU (Doug L. Bryan):
> Has anyone read Yourdon's book ``OOA---Object-Oriented Analysis''
> from Prentice-Hall?  It would be nice to see some recommendations or
> reviews posted to this news group.
> 
First of all, the book was actually written by Peter Coad, who used
to teach for Yourdon but is now vice president of Object-International, Inc.
Edward Yourdon has his name on the book, but he served mainly as a
consultant/editor.

I was at Peter Coad's tutorial at OOPSLA Tuesday and I saw a loose-leaf
copy of the book at the Prentice-Hall booth. In general, the book looks
good, certainly the best coverage to date of an elusive subject.  But
the quality could be better - lots of unnecessary clip art thrown in.

Keep in mind that I haven't actaully read the book; these comments are
based on the tutorial and a glance at the draft.

Some of the good points:

1) A good discussion of the purpose and products of analysis.

2) Mr. Coad has developed helpful "strategies" for each step in the 
OOA process.  These are basically lists of things to look for and questions
to ask about the relationships/objects you've identified.

3) A reasonable system of notation which has been used on a couple of
large projects. (probably needs some work before it can handle objects
with complex states).

4) LOTS of helpful examples/case studies of actual systems.

And some shortcomings:

1) Pretty much ignores requirements traceability.  I guess Mr. Coad
assumed the traceability between objects identified during analysis and
those in the design whould be straightforward (basically true), but he
doesn't consider the fact that many projects are based on a fixed price
contracts for written FUNCTIONAL requirements.  There has to be some
way to maintain traceability through analysis.

2) WARNING! MY PERSONAL OPINIONS! There seems to be too much emphasis on
identifying class (inheritance) relationships (a design/implementation
issue). There doesn't seem to be enough emphasis on tracing events through
the system and identifying states.  Basically, OOA seems to be tailored 
for systems which clearly model/manage a real-world problem.

DISCLAIMER:
These are just my personal opinions.  No one else here agrees with me...