Some corporations equate Object Oriented Design with a specific design notation (i.e. BoochMethod, Object Model Notation, Coad Method, etc).  Any failure of these  methodologies and their associated notations indicate (falsely) a failure of Object Oriented Design.

With the unification of BoochMethod and Rumbaugh's Object Model Notation we may see one emergent standard notation for major object oriented projects.  The ramifications of this possibility is scary.  Remember TopDownDesign and all of its restrictions?

Of course, none of these notations and techniques are inherently bad. Each represent years of research and case studies of huge software development efforts.  But, they (and the CaseTool''''''s that implement them) are taken as rigid guidelines for successful software development by many project managers.

Perhaps we need some AntiPattern''''''s to remind us not to
place too much faith in any particular notation or 
methodology.

-- ToddCoram

------

So, true, and so sad. I wonder if CargoCult should be 
adapted to reflect this phenomenon: the representation of
something is mistaken for the thing itself. As with
organizational charts, so with elaborate design documents
which, however detailed, elegantly wrought, and gorgeously
bound, do not necessarily lead to functioning software
systems. Of course, CASE tool manufacturers have been 
making a ton o' money selling just such a notion, but the
fact remains: if you can't run it, it ain't done yet. And
in my experience, CASE tools are great for only one thing:
recording a design that is as easily captured on a few
cocktail napkins and a pocketful of patterns. -- DonOlson

-----

I have introduced into my speaking and writing the ScannerChallenge.  A CASE tool is slower on entry, but should eventually pay for itself on changes.  The question is, how many times can you (a) redraw, (b) scan in, (c) paste into a Lotus note, the design, before the CASE tool catches up.  I currently estimate it at 8 changes per sheet. -- AlistairCockburn