Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Keywords: CASE rubbish
Message-ID: <55137@microsoft.UUCP>
Date: 11 Jun 90 19:18:57 GMT
References: <37538@genrad.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 44

In article <37538@genrad.UUCP> charlie@genrad.com (Charlie D. Havener) writes:
....
>The message I get and believe is that Object Oriented analysis, design and implementation
>via a supportive languge is superior in all ways to the old structured analysis approach.
....
>....  a less sexy but more accurate name would be CADC - Computer Aided Drawing and Checking."
>
>The government loves paper - these tools help you create a monument of paper.
....

[Caution: Fuzzy, but Heretical Comments Follow]

I second your concerns about CASE -- and traditional software design techniques
in general -- where applied to OOP.

The traditional approach is structured design, top-down programming, CASE,
paper-work, etc.  The traditional approach tends to be management heavy --
the top-down factoring of the project is mirrored along the top down 
factoring of the people working on the problem.  The project follows 
traditional military aka business organization.  Flow of control is from
manager to subordinate.  Everything done is documented on paper.

I claim OOP is quite different than this.  It is not naturally a top-down
approach, but rather a topless approach -- somewhat analogous to Minsky's
Sea of Agents.  Things have a strong tendency [heavens!] to be built from
the bottom up.  This scares managers to death -- they're loosing control --
and they try to force a global top-down design on top of the object oriented
approach.  But OOP doesn't naturally have a top.  People on OOP projects
likewise tend to follow an organization similar to Minsky's Sea of Objects.
Each programmer tries to make her own decisions, based on constraints imposed
by neighboring agents towards reaching the overall goal.  Until the goal is
met, everything looks like confusion, then suddenly things snap into focus,
and an answer emerges.  Flow of control is naturally from subordinate to
manager.

Into this new emerging approach comes people trying to sell ways to make
diagrams of software.  This is somewhat analogous to diagramatic dance
notations.  The diagram is not the dance.  Eventually, you have to shut up 
and dance.

I think we do need better ways to understand the interactions between
classes.  And we need better ways to understand the interactions between
objects.  But when such emerge, they're not going to have much in 
common with structured analysis.