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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: WhiteR@no.spam.please.CRPL.Cedar-Rapids.lib.IA.US (Robert S. White) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/21 Message-ID: <5quaos$jie$2@flood.weeg.uiowa.edu>#1/1 X-Deja-AN: 257897639 References: <33C835A5.362A@flash.net> <33CC0548.4099@flash.net> <33CD578D.562CC6A4@munich.netsurf.de> Organization: If you have a good KTN then I might tell you. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-21T00:00:00+00:00 List-Id: In article <33CD578D.562CC6A4@munich.netsurf.de>, joachim.durchholz@munich.netsurf.de says... > >changed anything. The issue is that the preconditions would have been an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >integral part of the routine's signature, and thus not likely to have ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >been overlooked by the team that ported the Ariane-4 code to Ariane-5. ^^^^^^^^^^^^^^^ Wrong! The code was _REUSED_ as is and nothing new was even looked at. The systems engineers did not even allow for the chance of a review/reading of embedded Ariane 4 preconditions in the software source code. They don't read the Ada code and they would not have read any Eiffel source code. They should have reviewed and modified the system requirements and then (somebody) showuld have flowed the changes down to the software requirements. NOT A LANGUAGE ISSUE! >As it were, the preconditions were buried in some obscure part of the >documentation, and management didn't reread everything when they reused >the code (together with its hardware). EXACTLY! But the fight dynamics in a system requirements spec IS NOT an _obscure_ part of the documentation! > >The paper may not be very clear in this respect (I got Meyer's view on >the topic from his book, not from the paper), or people might >misinterpret what it's saying. Yes his sanctimonious preaching of this "Eiffel only" DBC "magic bullet" to practioners in this particular hard real-time safety-critical difficult INS/IRS software domain has raised our collective blood pressures. It is not to say that DBC is not a good thing _When_ it can be readily applied. > >> According to Meyer, et. al. Eiffel programmers would have written the >> handler >> differently, and also they would have known to do the testing >> differently (even though >> the requirements specification said that the tests need not change). > >No. They would have written the handler the same way, and documented the >precondition with the routine where it belongs, not in some obscure spec ^^^^^^^^^^^^^^^^^^^^^^^^ >sheets that are shelved away. You do _not_ know what your are talking about here. This type of requirement _MUST_ be in the software requirements document!!! ...rest of post deleted, stopping now, to let my blood pressure drop down. _____________________________________________________________________ Robert S. White -- An embedded systems software engineer