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