Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mrmarx!abvax!ejp
From: ejp@abvax.icd.ab.com (Ed Prochak)
Newsgroups: comp.software-eng
Subject: Re: Information Systems is an Engineering Discipline
Message-ID: 
Date: 3 Oct 89 13:09:01 GMT
References: <1142@svx.SV.DG.COM> <34399@regenmeister.uucp> <5296@eos.UUCP>
Sender: news@abvax.UUCP
Distribution: comp.edu
Organization: Allen-Bradley
Lines: 85
In-reply-to: eugene@eos.UUCP's message of 30 Sep 89 00:20:26 GMT


In article <5296@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:

   >DESIGN

   Noble words, wish I could agree.

   The problem is (best noted by Butler Lampson and Fred Brooks in various
   articles and one book) is that software is an intrinsically different
   thing that "hardware."  The hardware people make mistakes (so you get cries
   for certification).  The software people try to mimic with design and
   documentation.  I don't think these will ever be enough.

   I say this because I contrast the pre-computer parts of my
   pre-engineering: things like mechanical drawing, etc. to the computer parts.
   I can remember one teacher saying, "It's not adequate just to design
   and something.  You have to know and be able to construct it as well."
   This of course lead to those drawings E shaped forms which have n roots
   and n-1 spokes, something Escher would design: optical illusions.

   In software on two flight projects, I've used 2 design languages and 1
   requirements specification language (SDDL, PDL, and RSL/RSA).  I think
   the people who use and design some of this stuff are dreaming.  Language
   is kinda of a poor basis for modeling things.  Real world hardware
   can utilize
   geometric and mathematics.    It follows conservation principles.  Software
   doesn't have any of this, and it still has to work.  We will have a computer
   literate public before we have design languages which "work."

[text deleted]

   ... Said managers and other politicians, etc. who ask for big
   software projects have to learn to understand the consequences
   of their requests, the side-effects, etc.  Life's tough, computers aren't
   going to resolve moral issues.

   If engineers are going to get criticized for being engineers, this is part
   of the reason why.  No simple answers.

   Another gross generalization from

   --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
    resident cynic at the Rock of Ages Home for Retired Hackers:
    "You trust the `reply' command with all those different mailers out there?"
    "If my mail does not reach you, please accept my apology."
    {ncar,decwrl,hplabs,uunet}!ames!eugene
				   Live free or die.

Eugene,
	I agree with you for the most part. I think you hinted at the
key difference between software and hardware: model building, based on
known mathematical fact. For example, aircraft designers can build a
scale model and test its characteristics at a very low cost compared
to the final product. They make use of Reynolds number and other
aerodynamic parameters to be sure the model will behave like the
real thing.
	We need a rule for scaling software so that we can test
small, cheap models of the software system. I think this is what
top-down design, structured design and object oriented design all are
striving for. We need to be able to build the model based on the
design, test it, if it doesn't work throw it away, if it does work then
build the real thing.
	The problem has been that we don't build models.
There has been proposals that we build prototypes instead.
This may be okay as long as the prototype never leaves the
development lab. Prototypes have to be treated as throw-aways,
especially when they work!
	My personal opinion is that prototypes are not good enough,
and that models of software systems are possible. What the techniques
will be, I don't know. I agree that verbal descriptions cannot be good
enough. Pictures are better (data flow diagrams and the like) but they
aren't models, they can't be easily tested. There must be something
we can use. Suggestions? Opinions?
 (BTW I am still looking for a reference to petri nets.
  If anyone can suggest a good introductory text, I would
  be very grateful.)

	Well, I made my point. Time to get out of here.
	bye
	ed prochak
--
Edward J. Prochak        (216)646-4663       I think. 
{cwjcc,pyramid,decvax,uunet}!abvax!ejp       I think I am.
Allen-Bradley Industrial Computer Div.       Therefore, I AM!
Highland Heights,OH 44143                    I think?  --- Moody Blues