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/11 Message-ID: <33EFCCE4.4CE0@flash.net>#1/1 X-Deja-AN: 263627922 References: <33E09CD5.634F@flash.net> <33E9ADE9.4709@flash.net> <5siqrr$3of@jupiter.milkyway.org> <5smgts$p68$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-11T00:00:00+00:00 List-Id: Paul Johnson wrote: > > In article <5siqrr$3of@jupiter.milkyway.org>, jtc@jupiter.milkyway.org says... > > >I think the most important use of Eiffel assertions (specifically > >require, ensure, and (class) invariant) is for documentation [...] > > While this is true, the importance of executable assertions should not > be under-estimated. Execution acts as a safeguard on the inspection and > documentation parts. We've all worked on projects where the documentation > has been put off or not done because of schedule pressure. Everyone agrees > that this is a bad thing, but it still keeps on happening. Executable > assertions won't let you do this. Leaving out executable assertions is just as easy as leaving out non-executable ones, isn't it? > A mature software process can also use this property by tracking assertion > failures and using them to monitor and improve inspection procedures. Is there a systematic method for reviewing code to determine if the right number and type of assertions have been added? This would seem to be the more critical issue. Without any assertions, the number of assertions failures can be predicted with some confidence :) > > > [...] I think the designer of > >the software is going to need to decide how to handle each situation > >where an exception could occur. > > This is true. It depends on the context of the application. For example > a real-time control system would shut down, re-initialise and try to > continue. For safety or mission-critical apps it would let the back-up > take over (yes, I've read the Ariane 5 report). For an interactive > application it would try to save the user data, put up an informative > message, and close down. I think this is a little over-simplified. For example, in each case: 1. A real-time feedback system would probably not want to shut down, even for a small interval. 2. As you note, turning over control to a backup is not always a good idea. 3. Interactive application error messages can be missed (see the recent InterNIC risk). Real-world exception responses in complex systems can be extremely difficult to analyze. > > 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.