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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Ken Garlington Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/19 Message-ID: <33FA76D7.21D9@flash.net>#1/1 X-Deja-AN: 268139947 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> <33F52989.38BB@flash.net> <33F83585.2FB006C3@munich.netsurf.de> Reply-To: Ken.Garlington@computer.org Organization: Flashnet Communications, http://www.flash.net Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-19T00:00:00+00:00 List-Id: Joachim Durchholz wrote: > > Ken Garlington wrote: > > > ...most > > > errors in software are not due to inconsistencies in the code. > > > > So, (a) that's where the difficult part lies > > Agreed. > > > and (b) it means a > > methodology > > that focuses on code inconsistency is not working the difficult part. > > The issue is that DBC allows to integrate code and code documentation > better. It is possible to write top-level abstract classes that just > encapsulate a few assertions; there is no need to duplicate these > assertions in other documents, at Eiffel (at this level) is easy to read > even for a non-programmer. To demonstrate the problem, attempt to encode the critical Ariane 5 assumption as a "top-level abstract class." It is not directly representable as code, even as a "top-level" abstraction. Said another way, could you write "War and Peace" as a "top-level" abstraction? > > > > 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. > > Eiffel assertions are *not* code. They are specifications for code. > Some of these specifications happen to be checkable at run-time, Read both of these statements carefully, several times. That, coupled with the experiment I describe above, should demonstrate the problem with your thinking. > so > they take the form of executable expressions instead of comments, but > that's a secondary issue. > > Regards, > Joachim > -- > Please don't send unsolicited ads.