From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/15 Message-ID: <33F52989.38BB@flash.net>#1/1 X-Deja-AN: 264469869 References: <33E09CD5.634F@flash.net> <33E9ADE9.4709@flash.net> <5siqrr$3of@jupiter.milkyway.org> <5smgts$p68$1@miranda.gmrc.gecm.com> <33EFCCE4.4CE0@flash.net> <5sskfd$nn5$2@miranda.gmrc.gecm.com> <33F25AA5.49ED@flash.net> <5t1fen$c7d$1@miranda.gmrc.gecm.com> Organization: Flashnet Communications, http://www.flash.net Reply-To: Ken.Garlington@computer.org Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-15T00:00:00+00:00 List-Id: Paul Johnson wrote: > > In article <33F25AA5.49ED@flash.net>, kennieg@flash.net says... > > > >Paul Johnson wrote: > > >> The whole point is to document the interface, and then check > >> the documentation for correctness. > > > >Against what? All you have is the code and the assertions created as > >part > >of the code. Checking them against each other determines internal > >consistency between the two, but that's all. > > Its a pretty big "all". Such an inconsistency points to an error > either in the documentation or the code. Then you can go and figure > out which one is wrong. > > >Based on the studies I've > >seen, most errors aren't to pure internal inconsistencies at the code > >level. > > I have some difficulty parsing that. I take it you mean that most > errors in software are not due to inconsistencies in the code. So what? So, (a) that's where the difficult part lies and (b) it means a methodology that focuses on code inconsistency is not working the difficult part. > Most development systems do not include automatic checking of the > documentation. This is design-level stuff, not code level. That's why automated checking should not be relied upon to find the hard errors. > > >It's difficult to explain a software methodology to someone who only > >sees one step: coding. > > Please don't talk down to me: you'll only miss. > > Try thinking of Eiffel as a software engineering notation, rather than > just a programming language. Its features allow the code to > capture information about the analysis, design and implementation. This > information is kept in one place, in one format and hence can be > checked for consistency. Again: You need to have experience in systems analysis and requirements capture to understand that the hard stuff is not readily expressible in code. This isn't talking down to you, it's just that you don't apparently have experience in this area. This issue is described further in: http://www.flash.net/~kennieg/ariane.html > > Paul. > > -- > Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | > +44 1245 242244 +-----------+-----------------------------------------+ > Work: | You are lost in a twisty maze of little > Home: | standards, all different.