Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!rpi!uupsi!sunic!dkuug!iesd!kjeld
From: kjeld@iesd.auc.dk (Kjeld Flarup)
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Keywords: CASE rubbish
Message-ID: <1990Jun12.123053.946@iesd.auc.dk>
Date: 12 Jun 90 12:30:53 GMT
References: <37538@genrad.UUCP> <55137@microsoft.UUCP>
Reply-To: kjeld@iesd.auc.dk (Kjeld Flarup)
Organization: Mathematics & Computer Science, University of Aalborg
Lines: 52

In article <55137@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>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.
...
>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.

What we need is a rational way to document object-oriented dsigns. If
we got a lot of object, which can interact in a lot of ways, then how
is it possible for two software engineers to get the same
understanding of the system. The one may be the designer, and the
other may be the maintainer, and the may never meet.

Now if the designer wants to document his system for later
maintaineance. He should use a terminologi that the maintainer can
understand. The key question here is not how to describe a object. If
OO just was a question of pushing a ahndle and then something
happened, then I do not see much difference between top down and OO.
But what are the sideeffects of pushing a handle, where does the
control go. It is actually possible that all objects may be affected
before control returns to you. 

So along with a better understanding of objects it is also nessecary
to devellop a way to document OO systems. Personally I work with CASE,
but at home when doing some programming for my self I use OO. Why the
difference ? The programs I write at home is my own, and there is only
my self to maintain them later. Then using OO gives me an advantage.
But when working on larger systems requireing more people, I need to
use a mechanism to secure my documentatiuon and the possibility to
maintain the system later.
-- 
*     I am several thousand pages behind my reading schedule.    *
Kjeld Flarup Christensen                         kjeld@iesd.auc.dk