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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Joachim Durchholz Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/18 Message-ID: <33F83585.2FB006C3@munich.netsurf.de>#1/1 X-Deja-AN: 265396813 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> X-Priority: 3 (Normal) Organization: ccn - computer consultant network GmbH Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-18T00:00:00+00:00 List-Id: 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. > > 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, 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.