Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!mcnc!duke!romeo!crm From: crm@romeo.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: CASE - The poster can't tell if there are clothes or not. Summary: Good polemic, bad science. Keywords: "CASE rubbish" rubbish. Message-ID: <20129@duke.cs.duke.edu> Date: 10 Jun 90 21:42:31 GMT References: <37538@genrad.UUCP> Sender: news@duke.cs.duke.edu Reply-To: crm@romeo.UUCP (Charlie Martin) Organization: Duke University CS Dept.; Durham, NC Lines: 123 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-2256