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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,289fc110e894cd68,start X-Google-Attributes: gid103376,public From: vijay Subject: Please delete me from your mailing list - Thank you Date: 1997/08/26 Message-ID: <199708262346.QAA06839@mx-a.qnet.com> X-Deja-AN: 269517610 Sender: Ada programming language Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Date: 1997-08-26T00:00:00+00:00 List-Id: ---------- > From: Automatic digest processor > To: Recipients of INFO-ADA digests > Subject: INFO-ADA Digest - 24 Aug 1997 to 25 Aug 1997 > Date: Tue, 26 Aug 1997 00:07:07 -0500 > >There are 4 messages totalling 345 lines in this issue. > >Topics of the day: > > 1. Critique of Ariane 5 paper (finally!) (2) > 2. AZ - SOFTWARE ENGINEERS with ADA experience (CONTRACTS NOW!) > 3. PLEASE REMOVE ME FROM YOUR MAILING LIST - Thank You > >---------------------------------------------------------------------- > >Date: Mon, 25 Aug 1997 07:15:04 GMT >From: Don Harrison >Subject: Re: Critique of Ariane 5 paper (finally!) > >Robert S. White wrote: > >: Ken, myself, and a few others have been arguing that you can >:not always employ the executable code aspects of DBC (or Ada >:run time checks) in hard real time systems with constrained >:resources. > >Agree - for current technology which requires *sequential* evaluation of >assertions. > >[..] > >:.. But I think it is a "good thing" to use assertions and/or a DBC >:methodology whenever practical. Unfortunately, IME, it is >:often not practical for resource constrained hard real time >:systems. > >Agree. > > >Don. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Don Harrison nospam@thankyou.maam.com.au > >------------------------------ > >Date: Mon, 25 Aug 1997 18:15:58 +1000 >From: Thomas Beale >Subject: Re: Critique of Ariane 5 paper (finally!) > >Ken Garlington wrote: >> >I've been caught out using a very informal argument and relying >on "commonly agreed" norms of software engineering. But as you >imply, (and I have done often enough, many of these can be >wrong). So... > >> > Jeff Kotula wrote: >> > > 1. Any evaluation of a system's reliability must be based on its >> > > requirements specification. >> >> False. The Musa model, for example, does not require examination >> of a requirements specification. > >I don't know what the Musa model is; does its definition of reliability >of a system rely in no way on the requirements (or any transformation of >any expression of it)? If not, does its idea of reliability not relate >to any expression of the correctness of the system (of which the >requirements spec is an instance)? > >> > > 2. Any evaluation of a system's reliability will directly correlate with >> > > the reliability of its component's reliability. >> >> For software, not true. See "Safeware." The sum of the component >> reliability >> does not necessarily equal the system's reliability. (This is a common >> mistake made when attempting to apply hardware reliability models to >> software.) > >I would have to agree here. A better statement would have been: >"A system's unreliability will strongly correlate to the unreliability >of the components". I.e., you can build rubbish out of good bits, but >its unlikely (if not impossible) to build a good system out of >broken components. > >> > > 3. Any evalution of a component's reliability must be based on its >> > > requirements specification. >> >> Again, not true. See above. > >I would need to be convinced by this "Musa" argument... > >> > which closes the loop from requirements to implementation. I think >> > this argument is a pretty fair statement of why DBC is not just another >> > tool in the toolkit: (to paraphrase the above) DBC is a way of >> > formalising, implementing, and enforcing the requirements specification >> > at the design and implementation levels of abstraction. >> >> Unfortunately, there can be elements of the requirements specification >> which cannot be enforced at the implementation level (e.g. certain >> classes of assumptions about the external environment). > >Naturally... probably the majority (measured by pages of document or >whatever) is informal or semi-formal, and does not map directly to >the various levels of design/implementation. But on the other hand, >if contracts were used as a formalism in the reqts spec, then the >ability to map through would be better. > >> > Where I think there is more room for debate is in how DBC should be >> > implemented. I have used Eiffel's DBC for some time, and it is miles >> > ahead of no DBC. >> >> What did you use before DBC? > >At university (Qld, Australia), we used formal assertions (a la >Dijkstra) to specify the meaning of program components. There >were no tools to support this, but we could easily code up test >cases to test correctness by encoding these statements (in >"pascal plus"). > >I spent about 6 years in distributed real-time SCADA systems >coded in K&R C, and at the end, had come to the conclusion (along >with other team members and developers) that modules built using >PRE_CONDITION, POST_CONDITION, and CHECK (macro) statements >in the code were better because: > >a) they were more readable & thus maintainable; > >b) they produced much more useful man pages (we built automated > back-extraction tools) - developers could avoid defensive > programming & complain to the authors if their program > died in a way forbidden by the assertion statements; > >c) they were _much_ easier to debug (we used the Fred Fish dbug > macros as well, and integrated them with the assertions); > >d) they acted as a repository for design-level decisions, which > began to replace voluminous design documentation which was > immediately out of date; > >e) the incentive was there to write more generic, re-usable > modules, since for the first time, client developers had > a trustworthy way of knowing what a given module did, > without having to look at the code: the (automatically > extracted) man page with both function signatures (like > you get if you do "man strcat" for example, on a unix > system), and the pre- and post-condition statements.... > this was treated as the "truth". A new experience - > trust in software not written by me - was discovered. > >Although we never had the means or time to make comparative >studies of code done this way versus the old way, I believe >we were able to write much better software, more quickly, and >that it was more reliable because a) our ability to test it >was much better, and b) it tended to get re-used more often >(and hence further tested). > >I should mention that we weren't doing this for amusement >either: these systems control e.g. gas pipelines, electric >power transmission and distribution systems (e.g. Sydney...), >and passenger rail systems. Reliability was the most >important thing in the world. > >As well as the eariler Dijkstra/Hoare etc work, Meyer's >original OOSC was a major influence on this work, since it >encouraged us to think it would be possible to do this >kind of thing in actual software (not hidden away in >some document), and it showed us what reasonable syntax >might look like for object-oriented software. > >Since then I have felt that formalisms that don't support >these ideas are way behind those that do. Eiffel is the >only out-of-the-box formalism in this category that is >available for building object-oriented software, but other >formalisms (even the augmented C "formalism" I describe >above) have great merit. It just depends on how much pain >you want to go through to make reliable software. > >I have since used Eiffel for some years because >- I am allergic to pain, >- it does the rest of the OO paradigm so well. > >- thomas beale > >------------------------------ > >Date: Sun, 24 Aug 1997 07:51:18 -0600 >From: Resumes@ICCJOBS.COM >Subject: AZ - SOFTWARE ENGINEERS with ADA experience (CONTRACTS NOW!) > > ICC INTERNATIONAL COMPUTER CONSULTANTS, Inc. located in Scottsdale, >Arizona has CONTRACT OPENINGS in the Phoenix area for candidates with the > following backgrounds: > > 1. Must have a BSCS, BSAE, or BSEE and 3+ years of S/W > Development experience. > > 2. Solid C or Ada programming skills. Vax literate, Knowledge of > Software Configuration Management principles a plus. > > > > Please fax your resume to ICC: Resumes@iccjobs.com > or > (602) 585-5449 > > ICC International Computer Consultants, Inc. > Scottsdale, Arizona > (602) 585-5488 > > >-------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to Usenet > >------------------------------ > >Date: Mon, 25 Aug 1997 18:23:24 -0700 >From: vijay >Subject: PLEASE REMOVE ME FROM YOUR MAILING LIST - Thank You > >---------- >> From: Automatic digest processor >> To: Recipients of INFO-ADA digests >> Subject: INFO-ADA Digest - 23 Aug 1997 to 24 Aug 1997 >> Date: Mon, 25 Aug 1997 00:03:07 -0500 >> >>There are 3 messages totalling 119 lines in this issue. >> >>Topics of the day: >> >> 1. Library model in Ada. was Re: Difference between ADA and c++ >> 2. Critique of Ariane 5 paper (finally!) >> 3. Difference between ADA and c++ >> >>---------------------------------------------------------------------- >> >>Date: Sat, 23 Aug 1997 17:12:44 -0700 >>From: Undetermined origin c/o LISTSERV administrator >> >>Subject: Library model in Ada. was Re: Difference between ADA and c++ >> >>In article <01bcafdf$50784b80$7774d8cc@fatman>, "Michael says... >>> >>>Here are several comparisions of Ada and C++ on the www: >>> >>>Langauge comparisons: >>> >>>A Comparison of Ada, C, and C++ >>>http://rep1.iei.pi.cnr.it/projects/JADA/ada-collection/tuft.html >>> >> >>thanks for the pointers! I did not have some of these before. >> >>Now, I was reading this below, from the above paper: >> >>"1) Separate Compilation and Library Management >> >> Ada: An Ada compiler is required to enforce consistency and >>strong type checking across separate compilation. The concept of >> ^^^^^^^^^^^^^^ >>a program library is built into the language, based on separately >>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>compilable modules called "library units" whose names are part of >>a hierarchical name space." >> >>GNAT, probably the most popular Ada95 compiler, does NOT use the >>program library model, but uses the code-source model, i.e. the >>traditional model. >> >>So, what going on here? who is wrong, and who is right? >> >>thanks, >>Nasser >> >>------------------------------ >> >>Date: Sat, 23 Aug 1997 22:09:00 -0500 >>From: Ken Garlington >>Subject: Re: Critique of Ariane 5 paper (finally!) >> >>Robert S. White wrote: >>> >>> The Ariane 4 IRS software as-is reuse should not have made it >>> by such reviews. Please read Ken's rebuttal paper: >>> >>> http://www.progsoc.uts.edu.au/~geldridg/eiffel/ariane/ >>> >>> My reading of it does not indicate a general "critising DBC" >>> but rather it summerizes: >>> >>> "In the specific case of the Ariane IRS design fault, there >>> is not clear and compelling evidence that DBC/Eiffel >>> assertions were likely to have uncovered the fault prior to >>> operational use, either through their documentation, test, >>> or execution value. Furthermore, alternative means were >>> available to the Ariane team to isolate the particular >>> fault, even without the use of DBC/Eiffel. Therefore, >>> although there may be a compelling claim to use DBC/Eiffel >>> in real-time safety-critical systems, the Ariane case >>> (and the Eiffel paper describing this case) does not >>> support such a claim." >> >>In addition, it states in section 6: >> >>"It would not be appropriate to use the criticisms here to say >>in the general case that assertions have no value, anywhere >>("casuistry"), but this criticism does not attempt to do this. >>It focuses on the specific claim in the Eiffel paper in the >>context of the Ariane IRS fault.... >> >>"Several Eiffel advocates will attest that they like the use of >>Eiffel for their domain. Eiffel may be very useful in some domains, >>however Ariane is a real-time embedded safety-critical system and >>has unique properties (as described above). Again, this is a specific, >>not a general, criticism of DBC/Eiffel." >> >>Perhaps my paper is so boring that no one made it to this >>section :) >> >>------------------------------ >> >>Date: Sun, 24 Aug 1997 08:07:32 GMT >>From: Dale Stanbrough >>Subject: Re: Difference between ADA and c++ >> >>" Ada: An Ada compiler is required to enforce consistency and >> strong type checking across separate compilation. The concept of >> ^^^^^^^^^^^^^^ >> a program library is built into the language, based on separately >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> compilable modules called "library units" whose names are part of >> a hierarchical name space." >> >> GNAT, probably the most popular Ada95 compiler, does NOT use the >> program library model, but uses the code-source model, i.e. the >> traditional model." >> >>Gnat does have a program library, just as Intermetrics also has >>a program library. The library just happens to be implemented as >>a series of source code files, and not some mysterious black box >>piece of software. >> >>List through the requirements of such a library, and you'll find >>that the source code model can meet them. >> >>Dale >> >>------------------------------ >> >>End of INFO-ADA Digest - 23 Aug 1997 to 24 Aug 1997 >>*************************************************** >> > >------------------------------ > >End of INFO-ADA Digest - 24 Aug 1997 to 25 Aug 1997 >*************************************************** >