Path: utzoo!attcan!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!fluke!kelpie
From: kelpie@tc.fluke.COM (Tony Garland)
Newsgroups: comp.software-eng
Subject: Re: CASE - The Emperor has no clothes on!
Keywords: CASE rubbish
Message-ID: <1990Jun11.201406.17646@tc.fluke.COM>
Date: 11 Jun 90 20:14:06 GMT
References: <37538@genrad.UUCP>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 57

In article <37538@genrad.UUCP>, charlie@genrad.com (Charlie D. Havener) writes:
 
[ material deleted]

> 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.

    As I view it, OOD and traditional functional decomposition are two 
    valid ways of approaching a wide range of problems.  A view which
    holds that all one or all the other is the best approach assumes
    that all sizes and sorts of problems should be solved with a single
    approach.  Certainly there are some sorts of problems (especially small
    and in real-time) where an "old fashioned" functional algorithmic
    treatment might yet be the best way to go.

> all the independent authors are saying it is completely orthogonal to Object Oriented techniques

    That's not the message that I get from some of these same authors.

    I think one needs to be careful when discussing CASE.  There are
    really at least two separate aspects to CASE; the methodology and
    the tools themselves.  Each of these can be used to address a
    wide range of problems.  For instance, when writing methods for
    your OOD, are you going to totally chuck everything you learned
    about functional decomposition out the window as being outdated?
    Although the mindsets with which one approaches OOA and
    structured analysis differ significantly, some of the same
    methodologies and tools can be used to advantage with either
    one.

    For instance, state transition diagrams can be used to describe
    the states an object takes on through its lifetime, data flow
    diagrams can be used to describe its methods, and entity
    relationship diagrams certainly help specify an object's
    attributes.

 
> I've said enough. If anyone can provide a substantive rebuttal I would like to hear it.

    After having done many an "old fashioned" functional decomposition
    spec and designs (many of which actually worked ;-)) and having used
    a CASE tool recently, I know it would have made my job easier and
    less error prone.  

    While I am excited about the benefits of OOA and OOD, it appears
    that for the near future the systems I'll be working on will make
    use of a combination of OO and structured decomposition.  More OO in
    a higher-level layers like the user-interface, less in low-level 
    software control of real-time measurement hardware).  When
    it comes to the application of CASE tools, I see aspects of
    tools available today that can be used to advantage with either
    paradigm.


-----------------------------------------------------------------------------
Tony Garland  -  John Fluke Mfg. Co. Inc., P.O. Box C9090, Everett, WA  98206
kelpie@tc.fluke.COM | {uw-beaver,microsoft,sun}!fluke!kelpie | (206) 356-5268