crm@romeo.cs.duke.edu (Charlie Martin) (06/11/90)
In article <37538@genrad.UUCP> charlie@genrad.com (Charlie D. Havener) writes:
-There has been a lot of talk about CASE tools in this group lately.
-The questions seem to be where can I get one and how is Brand X
-slightly better than Brand Y. It seems to me the real question is
-'Are Structured Design CASE tools worth investing time, effort and
-money in?' I have tentatively formed my decision. The answer is NO!
The problem is: what is the basis of your decision? What measurements
have you made, or based your decision on?
-Recently I have done a lot of reading on CASE tools, experimented with
-CADRE's TeamWork and IDE's StP ( Software Through Pictures $5k to $20k
-per seat ), read much of the Hatley-Phirbhai text, and played with
-EasyCASE ( The $200 PC formerly ShareWare Product ). I have also
-learned C++, taken courses in Object Oriented Design and Analysis (
-e.g. a seminar by Ed Berard ), read the Peter Coad & Ed Yourdon text
-"Object-Oriented Analysis", and read parts of the new Grady-Booch text
-"Object Oriented Design with Applications".
In other words, you've read 3 1/2 texts, taken a course, and played with
three tools, and on that basis you've determined its all bunk. This is
called the scientific method. Hmmph.
-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.
In *all* ways? how about when the specification requires you to produce
structure charts and data flows, as many Gvt contracts at least once
did? Does OO analysis and design help then? How about in the
implementation of a rule base in an expert system?
-It seem to me the vendors of
-these old case tools are blowing all the smoke and fog they can to
-protect their lucrative markets which depend on management Fear,
-Uncertainty and Doubt. The CASE vendors are happy as can be when one
-of their employees gets an article published that, in effect, says
-'Don't worry - Structured Analysis works just fine with objects', while
-all the independent authors are saying it is completely orthogonal to
-Object Oriented techniques and has very little if any use
-what-so-ever. Maybe it can be used to help implement some complex
-method ( or member function ) of an object but other than that - forget
-it.
-A quote from the Coad/Yourdon text, "Computer-Aided Software
-Engineering (CASE) -- it's hard to believe that such simplistic
-software tools are getting so much attention these days. .... a less
-sexy but more accurate name would be CADC - Computer Aided Drawing and
-Checking."
Interesting quote, but Coad and Yourdon have an axe to grind and a
product to flog, just like everyone else. "Computer aided software
engineering" is what CASE stands for, and if a lot of the basis of
software engineering is drawing specific notations and checking them,
then computer aides for this ARE computer aided software engineering.
What basis do they offer for believing that current CASE tools are of
little value?
-The government loves paper - these tools help you create a monument of
-paper.
This may in fact be one of the best reasons for using CASE tools as they
currently exist; DOD 2167, 2167A, and Son-of-2167A when it comes will
almost certainly require mountains of paper documenting the design, the
testing, the testing of the testing, and so on. This has nothing toi do
with software, little to do with the Gvt per se, and everything to do
with Congressionally mandated procurement practices. It certainly isn't
the CASE community's fault that these practices are less than
reasonable. But when one must develop for the Gvt, one must meet 2167A;
doing so can be *very* expensive. one project I helped direct had over
one staff-day of overhead in each phase (requirements, design, coding)
per 300 SLOC to meet the governments requirements. It was a 400 KSLOC
project; the cost would have been 1333 staff-days = 5+ staff years =
better than half a million dollars to meet these needs. If all a CASE
tool could offer was reducing this cost by 10 percent, StP would pay for
itself fivefold.
-There are some tools for Object Oriented approaches available (
-e.g. Semaphore Tools, Andover Mass. ) but one of the nice thing about
-Objects is that you can do fine with no CASE tools at all. The CRC (
-Class Responsibility Collabortators ) method is one that uses 4 by 6
-index cards and it seems well on it's way to becoming a standard
-technique.
It sounds like good stuff -- can you provide a pointer to it? I'd like
to read about it.
But I do have some questions about it:
(1) what is the effect on cost?
(2) how are the cards then used in maintenance?
(3) what validation method works best with CRC?
(4) does it have any effect on correctness? Does it change errors per
1000 SLOC?
-I've said enough. If anyone can provide a substantive rebuttal I would
-like to hear it.
The real problem with offering you a substansive rebuttal is that you've
made no substansive claims. OOP and OOAD are better, you've heard and
believe: but why? What meeasurements have you performed or seen
performed or read about? What measure was used in these? Is there any
reason to expect that these studies correlate with practice?
CASE tools are no use; they just help you produce a mountain of paper:
but if part of the task is producing a mountain of paper, as it often
is, then your claim seems flawed.
The basis for your assertions is not very strong, based on the
experiences you quoted; do you have actual development experience with
OOAD compared to SA? What is it? What were the results?
The worst problem with Software Engineering as a topic, and the most
frustrating one I face as a researcher, is that measurement is *so*
DAMNED hard to do, and so easily confounded by any number of problems.
The worst problem with the perception of software engineering as a topic
within computer science is that so many people will claim that something
or other is better without making measurements.
Charlie Martin (...!mcnc!duke!crm, crm@summanulla.mc.duke.edu)
O: NBSR/One University Place/Suite 250/Durham, NC 27707/919-490-1966
H: 13 Gorham Place/Durham, NC 27705/919-383-2256weide@tut.cis.ohio-state.edu (Bruce Weide) (06/12/90)
Another problem regarding the recent discussion of CASE tools is the tendency to equate CASE tools with tools that support structured design and the better-known (better publicized) methods that can be taught in the classroom. There are other tools out there, maybe even some that support your favorite design paradigm. If you're lucky they may also support testing, maintenance, etc. -Bruce
scotth@boulder.Colorado.EDU (Scott Henninger) (06/12/90)
In article 3770 crm@romeo.cs.duke.edu (Charlie Martin) writes: > This may in fact be one of the best reasons for using CASE tools as > they currently exist; DOD 2167, 2167A, and Son-of-2167A when it comes > will almost certainly require mountains of paper documenting the > design, the testing, the testing of the testing, and so on. This has > nothing toi do with software, little to do with the Gvt per se, and > everything to do with Congressionally mandated procurement practices. > It certainly isn't the CASE community's fault that these practices are > less than reasonable. But when one must develop for the Gvt, one must > meet 2167A; doing so can be *very* expensive. > > [...] > > CASE tools are no use; they just help you produce a mountain of paper: > but if part of the task is producing a mountain of paper, as it often > is, then your claim seems flawed. This is true in practice today. But the point for discussion should be: is this reasonable? Just because the government mandates inefficient documentation methods, should we concentrate only on these methods, or should we strive to streamline this process? > The worst problem with the perception of software engineering as a > topic within computer science is that so many people will claim that > something or other is better without making measurements. I call it "armchair design", and it is definitely a problem. In fact, it reminds me of the state of psychology around the turn of the century when most studies of cognition centered around introspective accounts. The problem they found was that there were no common grounds on which they could argue the veracity of their theories; leading researchers to jump in the opposite direction - behaviorism. It is now generally held that a mix of both behaviorism and introspective accounts and theories are needed to study cognition. The same probably holds true for computer science; at least it will be necessary before a true science can emerge that is more than the description of "neat" tools and techniques. -- Scott scotth@boulder.colorado.edu