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: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: fac41,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public From: rkaiser@dimensional.com (Richard Kaiser) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/19 Message-ID: <5gnttg$jkc$1@quasar.dimensional.com>#1/1 X-Deja-AN: 226672116 References: <332B5495.167EB0E7@eiffel.com> <332D113B.4A64@calfp.co.uk> <5gl1f5$a26$2@quasar.dimensional.com> <332E8D5D.400F@calfp.co.uk> Organization: Dimensional Communications Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada Date: 1997-03-19T00:00:00+00:00 List-Id: In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton wrote: >Richard Kaiser wrote: > >> The first mistake was to not put the time limit in some human readable >> documentation, or if the time limit was documenting then it was not read. >> Writing code so it documents itself reduces or eliminates the code >> documentation, but this can be done in Ada, EIffel, C, C++ and even >> assembly language and FORTRAN. These limits are part of the design >> and belong in a Software Requirements/Requirements Verification document >> and in the Version Description Document. And these documents must be >> reviewed prior to reuse. > >The difference between writting comments that document code, and >writting assertions is simple. The assertions will get tested, your >comments will not. I prefer to trust the latter But this software was Never tested. No end-to-end test with the hardware, nor even a software only simulation. If the testing is not performed assertions will not be executed to detect a problem. With proper testing the simulated flight would have failed with or without the assertions. >> >2) Design. Writting assertions makes design easier. This is a personal >> >observation and harder to justify. I find being clear about what >> >something does helps clear up what I am doing. Having complex >> >preconditions is not a good idea, again you probably don't have the >> >right structure. >> >> The code is going to say "I am not in my original application and may or >> will fail?" Assertions are only going to catch problems if there is: >> > >No, the code does what it is contracted to do. If you break the >contract, it raises an exception. But software testing "never re-read the contract". Why is Eiffel saying assertions are a new tool? C (and now C++) have been using #include for years? Software engineers have been using assert macros to verify program limits are not exceeded. Richard Kaiser