Please delete me from your mailing list - Thank you

[vijay <vijay@QNET.COM>]

----------
> From: Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
> To: Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
> 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 <donh@SYD.CSA.COM.AU>
>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 <thomas_beale@INVEST.AMP.COM.AU>
>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 <vijay@QNET.COM>
>Subject: PLEASE REMOVE ME FROM YOUR MAILING LIST - Thank You
>
>----------
>> From: Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
>> To: Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
>> 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
>>         <owner-LISTSERV@LISTSERV.NODAK.EDU>
>>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 <kennieg@FLASH.NET>
>>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 <dale@GOANNA.CS.RMIT.EDU.AU>
>>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
>***************************************************
>