Papers on the Ariane-5 crash and Design by Contract

Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

We have made available on-line the paper that Jean-Marc Jezequel
and I published in the January issue of IEEE Computer about the
June 1996, software-induced $500-million crash of the Ariane 5
mission, and the lessons it holds for software development
--  in particular the role of contracts for reusable software.

The paper can be found by following the "Ariane 5" link at

	http://www.eiffel.com

We have used this opportunity to update the technology
paper that summarizes the theory of Design by Contract
(http://www.eiffel.com/doc/manuals/technology/contract/index.html).


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Thomas says

<<In that note you essentially argue that if only the Ariane 5 software
had used Eiffel preconditions, the rocket would not have crashed.
You suggest a precondition of the form:>>

Indeed .. anyone can argue that their favorite language, if used properly,
would have avoided the Ariane 5 bug. That's true even for assembly language.

The fact of the matter is that this bug was a result of the approach
used, and had nothing to do with the particular language chosen. Indeed
the Ariane 5 crash serves as a useful reminder that Ada is not some magic
panacea that prevents incompetent design and implementation!

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

nouser@nohost.nodomain (Thomas) wrote:

>In article <332B5495.167EB0E7@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

<..snip..>

>I think the lesson to be learned from this is that projects should
>choose hardware that is sufficiently powerful to let the software
>engineers implement their software without making dangerous
>compromises and without having to spend a lot of their time on
>worrying about how to squeeze complex algorithms into inadequate
>hardware.  With more powerful hardware, you don't have to disable the
>runtime checks in a language like Ada in the first place, and you can
>afford to add adequate exception handling code.  While on a rocket
>every gram and watt counts, we are talking maybe 10-20% more memory
>and performance.  More powerful hardware might also have permitted a
>simpler, more easily tested and maintained design overall.

That's far easier said than done. It's not necessarily cost/power/mass
that's the problem with computers used in the space industry, it's
availability of radiation tolerant or hardened processors and memory
and so on. Memory is generally too much of a problem, you can easily
get hold of Radiation Tolerant memories from Harris and Honeywell or
MHS, however hardly any microprocessor manufacturers build devices
specifically for the space industry, and those that do generally don't
build very fast devices.

The most commonly used device in the european space industry at the
moment is the GPS MA31750 (probably), a MIL-STD-1750 implementation
that runs at 10MHz and gives a performance of 1.3 MIPS. It is,
however, available radiation hardened. 200MHz Pentium Pros are not.

>Of course, those hardware costs might have been noticeable, resulting
>in either lower payload or noticeably higher overall project costs.
>But if you want your rockets to fall out of the sky less often, that's
>the price you have to pay.

Given a higher performance version of the same processor, the extra
hardware costs are unlikely to be significant, the MA31750 we've been
using costs aroun $13000 (Thirteen Thousand Dollars - 1.3 MIPS, 10MHz
- Value for money?), and 8kx8 RAMs are around $2500 a piece. However
as I said, in the Space Industry, you are probably using the highest
performance device available to you anyway so cost is irrelevant
(unless of course you want to use hundreds of millions of dollars of
project money to package and qualify a new processor!).


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

[Marin David Condic, 561.796.8997, M/S 731-93]

    Will this subject never die? Will there always be someone posting
    here with the claim that if only language XYZ were used instead of
    Ada that the whole thing would have worked fine???

    I thought it had been very well documented that there was a
    deliberate design decision to *remove* all the language safety
    checks and operate "at risk". On Ariane 4, this turned out to be
    the correct engineering decision. (or at least "one of many
    possible" correct decisions.)

    Absolutely *no* programming language is going to prevent this sort
    of decision because even if the language won't let you turn off
    checks, you'll just circumvent the language to get what you want
    anyway. (And there's no way that programmer "X" raised on a steady
    diet of language "Y" would never make such a disasterous decision
    because there's always Manager "A" with big stick "B" to
    re-educate programmer "X" until he becomes a team player, sees the
    big picture and gets with the program.)

    There is no programming language ever invented which can stop you
    from putting a round into the chamber, pointing the muzzle at your
    toe and squeezing the trigger. (Not even PL-1 - just in case we
    want to bring *that* one up again ;-)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
        In Vegas, I got into a long argument with the man at the
        roulette wheel over what I considered to be an odd number.

            --  Steven Wright
===============================================================================

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Robert I. Eachus wrote:
 
>     How many times do people have to be told that the lack of an
> assertion was NOT the problem here.  The assertion existed

Where?
 
 
> [...] The real problem was that the software was used unchanged and
> without review [from Ariane 4 to] Ariane 5, where these assumptions
> were not true.

The real problem was that the assertion was not part of the software.

Successful reuse requires that what you reuse be equipped with a
specification - a contract. That's the point made Jean-Marc Jezequel
and I made in the article at
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Enrico Facchin - Sartori E.T.]

Dear gentlemen,
I've missed the original post, and I can't find it with DejaNews.
Would anybody post again it (or tell me if any other archive exists)?

Thanks in advance.

Enrico Facchin

ing. Enrico Facchin - Ufficio Tecnico



****************************************************************************
Sartori Elettronica Telecomunicazioni - tel. 049 772188 - fax 049 772946
email:sartori.elettronica@intercity.shiny.it
http://www.intercity.shiny.it/sartori
Impianti per telecomunicazioni professionali civili e militari.
Forniture per impianti d'antenna di qualsiasi genere.
Laboratorio riparazioni e centro assistenza (Tv sat., tel. cellulare).
****************************************************************************

Re: Papers on the Ariane-5 crash and Design by Contract

[Martin Tom Brown]

In article <EACHUS.97Mar17120250@spectre.mitre.org>
           eachus@spectre.mitre.org "Robert I. Eachus" writes:

> In article <332D113B.4A64@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> 
>   > But in conclusion, my experience is that people write assertions in
>   > their code, because it is effective.
> 
>     How many times do people have to be told that the lack of an
> assertion was NOT the problem here.  The assertion existed, and the
> deliberate decision, apparently thrashed around in several meetings at
> different management levels, was that on Arianne 4, this condition
> could only occur through hardware failure.
> 
>     The software designers were under no illusions about what would
> happen if this constraint was violated, or the conditions under which
> that could occur: the rocket could be way off course--which would tend
> to indicate a guidance failure, or one part or another of the guidance
> system was malfunctioning.

To summarise - it was rather unfortunate that the ability to survive
the launch trajectory of Arianne 5 was not a design requirement of 
the original software, and that no fullscale simulation test was done
when the Arianne 4 unit was adopted for use in the later system.
 
>     The real problem was that the software was used unchanged and
> without review on Arianne 5, where these assumptions were not true.
> The Arianne 5 was much faster off the pad, and although it was
> possible to follow a trajectory which would not have run into this
> problem the actual trajectory did exceed the (built-in, appropriate
> for Arianne 4) limits.

It also adds insult to injury that the data from the guidance unit 
which failed was meaningless once Arianne 5 was off the launch pad,
and the only reason it was running was to allow Arianne 4 countdowns
to hold and restart without excessive delays.  :(

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <tz8ohcjv7cc.fsf@aimnet.com>, Thomas <nouser@nohost.nodomain>
writes 

>I think the lesson to be learned from this is that projects should
>choose hardware that is sufficiently powerful to let the software
>engineers implement their software without making dangerous
>compromises and without having to spend a lot of their time on
>worrying about how to squeeze complex algorithms into inadequate
>hardware.  With more powerful hardware, you don't have to disable the
>runtime checks in a language like Ada in the first place, and you can
>afford to add adequate exception handling code.  While on a rocket
>every gram and watt counts, we are talking maybe 10-20% more memory
>and performance.  More powerful hardware might also have permitted a
>simpler, more easily tested and maintained design overall.


    "Might also have"?  Hmmm...
  

    I think this is wrong.  Total bull wrong.  Good Software Engineering
arises out of the organisation of good social structure.  The flow of
communications.  Nothing else.  In the end, it's down to people really
_talking_ to eachother.  A Challenger disaster doesn't go away just
because you have a springier rubber in your O-rings.  The malaise that
caused that disaster will cause something to fail somewhere else.


    And what's this talk of weight and watt?  A high-end pentium PC
today has millions of times more storage and millions of times more
speed than the systems that took Apollo into lunar orbit.  And
undoubtably weighs and takes far less power too.  Communication made it
happen, I mean -- all they had for RAM at the time was a bulky cube of
64,000 _hand_threaded_ ferrite beads called core-store.


    So I say what you're "Might also have" saying is just plain wrong.




Sandy
/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Paul Johnson]

In article <tz8ohcjv7cc.fsf@aimnet.com>, nouser@nohost.nodomain says...

>What was required here was a simple check that a function argument was
>within a certain range.  That check could have been expressed as an
>Ada type declaration and checked by the compiler at compile time, or
>as a runtime assertion/check. 

The whole point of Eiffel is that the assertions are more than just a
run-time check.  In fact the run-time checking is the least important
aspect of Eiffel assertions.  Far more important are the self-documenting
aspects.  This is where Ada misses out: the fatal exception occured
because the limitations were not properly documented.

>The design team apparently decided that
>either approach was too costly in terms of design or speed and instead
>opted for leaving the code unsafe and documenting the conditions under
>which the function could be used safely. 

They did this by commenting the code, rather than writing it into the
documentation.  Furthermore the exception occured (as I understand it)
because the compiler included explicit range checks in the compiled code,
and the programmers had opted not to include manual range checking and
limiting because of CPU limits.  In other words they had a choice between
checking it once or twice (redundantly), and the single check option had
catastrophic consequences.  The important thing is that neither of these
checks were actually very useful at run-time.  The real cause of the 
Arianne 5 failure was the policy that any exception be treated as fatal
while identical software was used on both inertial guidence units.  Hence
any bug that caused an exception would inevitably lead to self-destruction.

In practice, due to the time at which the exception occured it would have
been better to continue processing because the results in question were not
actually being used.  However if they had been in use then its difficult
to see how any kind of run-time checking could have helped: range limiting
only ensures that the wrong results are produced, and this would have been
as fatal as the exception.

[On annotation and documentation]

>And if the programmer culture on a project is such that
>they don't use Ada assertions, why would they use Eiffel
>preconditions?

Because Ada assertions don't form part of the documentation.  Eiffel
assertions do.  So by writing one piece of code you get both benefits.

Furthermore the "Eiffel culture" is very different to the "Ada culture".
In Eiffel the external assertions are seen as a key component of the
software, while in Ada they are just an optional extra.


>   The exception was due to a floating-point error: a conversion from a
>   64-bit integer to a 16-bit unsigned integer, which should only have
>   been applied to a number less than 2^16, was erroneously applied to a
>   greater number, representing the "horizontal bias" of the flight.
>   There was no explicit exception handler to catch the exception, so it
>   followed the usual fate of uncaught exceptions and crashed the entire
>   software, hence the on-board computers, hence the mission.

>I don't understand these statements at all.

Bertrand is accurately paraphrasing the published report, except for one
point: there was a high-level policy in the Arianne programme that any
exception should cause the shutdown of whatever unit of hardware it
occured in.  The assumption seems to have been that the software was
perfect, and so any exception must indicate a hardware flaw.  Therefore
the correct thing to do with an exception is to shut down and let the 
backup unit take over.  Unfortunately the backup in this case was running
exactly the same software and was receiving basically the same data.
Hence they crashed within a fraction of a second of each other.

There was no exception handler: the exception error message was actually
dumped onto the system bus and interpreted by the guidance mechanism as
real data.  This would have probably destroyed the rocket anyway, but
the fact that both inertial sensors went permanently down made it 
inevitable.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my opinions. |
+44 1245 242244         +-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Leaton]

Thomas wrote:

> convert (horizontal_bias: INTEGER): INTEGER is
>             require
>                   horizontal_bias <= Maximum_bias
>             do
>                   ...
> 
>             ensure
>                   ...
> 
>             end
> 
> What was required here was a simple check that a function argument was
> within a certain range.  That check could have been expressed as an
> Ada type declaration and checked by the compiler at compile time, or
> as a runtime assertion/check.  The design team apparently decided that
> either approach was too costly in terms of design or speed and instead
> opted for leaving the code unsafe and documenting the conditions under
> which the function could be used safely.  Also, they apparently did
> not have a practice of annotating their code with assertion statements
> for testing, and you suggest that they didn't have a standard
> practice for documenting unchecked preconditions.
> 
> I don't see how the different notation that Eiffel uses for the same
> purpose helps.  Eiffel's conditions are also enforced either at
> compile time or at runtime, and exactly the same tradeoffs apply as
> they do in the Ada program: you incur costs for type conversions and
> range checks.  And if the programmer culture on a project is such that
> they don't use Ada assertions, why would they use Eiffel
> preconditions?
> 

Eiffel does type checking at compile time. You can check type at runtime
but the need to do this is such that you should query if you write code
that uses this feature. 

	x ?= y

x will be Void if y does not conform to they type of x.

The point about culture and assertions is an interesting one. I have
moved to a company that uses Eiffel. Initially I was very sceptical
about assertions, for the same reason you are, that I don't see people
using them, or that they remove them when the release the code.

In practice though, you write them because as part of developing
software they make a huge difference to development. This has an effect
in various areas.

1) Documentation. You need less of this. Documentation which say 'This
feature expects this and does that' is no longer need. Documentation
that is needed is the 'intent' of the routine, and high level intent or
overviews. There are tools that can produce what is called the short
form, the code without the implementation built into most compilers.
These will also produce HTML and other outputs.

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.

3) Debugging / Testing. Running with assertions enabled detects bugs 
earlier. This is the real saver in time and costs. 

4) Reviews. If you review code, then having the assertions in place
is very useful. A large part of reviewing C++ is working out what
assertions have been assumed, and checking code against them. Having
them written into the code makes this easier.

There are other more complex parts to Eiffels assertion system, in
relation to inheritance, and soon in relation to parallel processing.

But in conclusion, my experience is that people write assertions in
their code, because it is effective.


-- 

Nick

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:

<snip irrelevant example on Eiffel assertions>

The problem was with the Requirements flowdown and verification and 
with the testing process.

>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.

Self documenting code is the usual standard for most languages in use
today but self documenting code is for documenting the code, not the
design.  Design documentation belongs in a Requirements Flowdown
and Requirements Verification documents and any limits should be
coppied in the Version Description Document.  But the bigger issue is these
documents need to be reviewed for a new application.

>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 assert "I will not run correctly in this new rocket?"
The problem was with Exceptions that did not try and recover and
due to ...

>3) Debugging / Testing. Running with assertions enabled detects bugs 
>earlier. This is the real saver in time and costs. 

Not simulated flight was made for the new design so the first flight
was also the first test.  A simulated flight would have found this time
limit and allowed a fix.

>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.

And reviews are where someone says that  the Requirements Flowdown
and Requirements Verification documents have been read and updated  
for the new requirements.  Or where someone mentions a difference in
requirements and someone else says "Oh Sh...".     pardon my French 8-)

>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.
>
>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.

Languages cannot review the design and catch this type of a change in
requirements problem.  The only language issue is too much complexity that
prevented someone from seeing this problem.

Designing code for reuse is a difficult and expensive task and 
                  May NOT Be Cost Efficve In Many Application !!!!.  
I have seen several books and magazine articles on this though much of it is 
about designing out limits such as this.

Richard Kaiser

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <332D113B.4A64@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

  > But in conclusion, my experience is that people write assertions in
  > their code, because it is effective.

    How many times do people have to be told that the lack of an
assertion was NOT the problem here.  The assertion existed, and the
deliberate decision, apparently thrashed around in several meetings at
different management levels, was that on Arianne 4, this condition
could only occur through hardware failure.

    The software designers were under no illusions about what would
happen if this constraint was violated, or the conditions under which
that could occur: the rocket could be way off course--which would tend
to indicate a guidance failure, or one part or another of the guidance
system was malfunctioning.

    The real problem was that the software was used unchanged and
without review on Arianne 5, where these assumptions were not true.
The Arianne 5 was much faster off the pad, and although it was
possible to follow a trajectory which would not have run into this
problem the actual trajectory did exceed the (built-in, appropriate
for Arianne 4) limits.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <milkweed-1803970737590001@port3.chester.smallmedia.com>, milkweed@plainfield.bypass.com (Anders Pytte) writes:
>In article <tz8g1xtzx9y.fsf@aimnet.com>, nouser@nohost.nodomain (Thomas) wrote:

>I concur. In earlier threads I pushed the point that choice of language is
>not as significant as good coding practices. Meyers et. al. are to be

True.

>congratulated on creating a language that incorporates as much good coding
>practices as may be possible into a language. But they lose credibility by
>asserting that language can enforce good coding practices.

The language by itself does not (and cannot) enforce good coding practices.
You can do Fortran in Eiffel or in Ada. I wonder who is asserting the contrary:
I do not for one, and I do not remember B. Meyer "asserting that language can 
enforce good coding practices". What is true, IMHO, is that languages differ
by the level of integration/support of best OO practices, and thus make it more
or less easy for programmer to adopt them.
You say yourself that Eiffel is "a language that incorporates as much good coding
practices as may be possible into a language".  For myself, I wouldn't even
go that far.


>I have learned to use assertion exhaustively in C++, even though I do not
>work on critical products. I get the point about auto-extraction of
>assertions into documentation, but in the end most coders feel more secure
>looking at code itself (documentation may be incomplete or out of date).
>There is no substitute for self documenting code, and for that purpose
>assertion is priceless.

It seems that we are actually in agreement.

>I expect Meyers to push his own products, but to imply the Ariane-5 crash
>was caused by poor choice of programming language seems out of step with
>his otherwise impeccable manners.

Unless our English is so bad that it betrays our thinking, we 
*never* implied such a thing. Just a point in a case: Eiffel simply did not exist when they 
worked on Ariane4. Let me quote the relevant section of the paper:

<<Is it the programming language's fault?
Although one may criticize the Ada exception mechanism, it could have been used here
 to catch the exception. In fact, quoting the report: [omitted]
In other words the potential problem of failed arithmetic conversions was recognized.
 Unfortunately, the fatal exception was among the three that were not monitored,
 not the four that were.>>

In case it is not clear enough, I repeat again: *it is not a language problem*
Let me quote another part of the paper:
<<Does this mean that the crash would automatically have been avoided had the mission used
a language and method supporting built-in assertions and Design by Contract? >>

Please note the "language and method supporting built-in assertions and Design by Contract"
and please do not reduce it to : "a language". 



-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Paul Johnson wrote:
> 
> In article <tz8ohcjv7cc.fsf@aimnet.com>, nouser@nohost.nodomain says...
> 
> They did this by commenting the code, rather than writing it into the
> documentation.  Furthermore the exception occured (as I understand it)
> because the compiler included explicit range checks in the compiled code,
> and the programmers had opted not to include manual range checking and
> limiting because of CPU limits.

You do not understand correctly. The design team for Ariane IV made a
conscious decision to eliminate the *automated* check, which was
documented.
The Ariane V team did not do sufficient analysis to believe that this
decision was wrong for Ariane V, nor did they do sufficient testing
which
would have demonstrated their error. Note that the documentation of the
assertion (the legal range of the value in question) was still in the
code;
only the check was removed.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Laurent Moussault]

Anders Pytte wrote:
> 
> I concur. In earlier threads I pushed the point that choice of language is
> not as significant as good coding practices. Meyers et. al. are to be

[...]

> I have learned to use assertion exhaustively in C++, even though I do not

	May be there is two different things : the Eiffel language,
and the Eiffel method, based on Design by Contract.

	As you said, neither the use of Design by Contract nor of the Eiffel
method implies the use of the Eiffel language : they can be used with other
languages as well.

	I think what the Eiffel programmers are trying to say is that
the use of the Eiffel language implies the use of the Eiffel method, or
at least the use of contracts. Am I wrong ?

	Anyway, this doesn't allow to say that the use of Eiffel (the
language or the method) would have been enough to solve the problem,
or would have been the only (or best) solution. And I'm sure noone have
said that.

	I don't understand the fear of a "language war". Aren't languages
important ? No need to fight, of course -- just to exchange ideas, for
the benefit of every languages, including Eiffel and Ada. I think that
a language improvement leads to an improvement of the coding practices.

(Excuse my poor English)

-- 
Laurent MOUSSAULT
Universite de Bretagne Occidentale (Brest, France)
Courier electronique : moussaul@kelenn-gw.univ-brest.fr

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

   I said:

   >     How many times do people have to be told that the lack of an
   > assertion was NOT the problem here.  The assertion existed

In article <332DA14C.41C67EA6@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

   > Where?

   In lots of places, including the code.  The assertion was quite
clear, as was the run-time action: out of range data here indicates a
hardware failure.  Switch to the other processor, run the diagnostics
and send the data down the telemetry channel.

  Let me interrupt for a second.  There has been a lot of discussion
about the fact that this condition was not "handled" correctly in the
code.  But the assertion was there, it was detected by the compiler
that this condition could not be ruled out at compile time, and the
software engineers suggested a "better" way to deal with it.  It is
only at this point that the error handling becomes an issue.  But the
compilers and other development tools, AND their users made no silly
mistakes or omissions.

  The software was explicit, and the compiler diagnostics essentially
said: "Rocket can crash here."  Whether to change this was
debated--look at the report--by several layers of management, and in
the end five of seven such issues were closed by adding local handlers
in the code.  Two, including this one, were closed with a proof that
if the software detected that condition, it indicated a hardware flaw.
This was perfectly correct--on the Arianne 4.

  The fact that the hardware "switched to the other computer" and
resulted in diagnotic data going to the engine actuators was extremely
bad hardware design, but that is not the issue here.

   (I said:) 

   > [...] The real problem was that the software was used unchanged and
   > without review [from Ariane 4 to] Ariane 5, where these assumptions
   > were not true.

  (Back to Bertrand:)

  > The real problem was that the assertion was not part of the software.

  However, the assertion was implicit and explicitly in the code.  But
that was not where this reuse went wrong...

  > Successful reuse requires that what you reuse be equipped with a
  > specification - a contract.

  Exactly.  Good specifications existed, but no one was ever tasked to
see if there were any conflicts between the specification of the
Ariane 5, and the specifications of the Ariane 4 guidance software.
This was not a "one-line" miss.  There were pages and pages on the
float to integer conversion issue, and volumes on running the
alignment software after liftoff.  (Including the fact that this
capability had been used on at least one Ariane 4 launch.)

  My guess is that tasking one software or systems engineer to do such
a review would have found the problem--and resulted in a much more
thorough requirements scrub!

  By the way, even worse was the fact that the Ariane 4 software
designers were told they had no "need-to-know" the Ariane 5 specs when
designing the system for the Ariane 4.  I'm sure if they had been
allowed to see the Ariane 5 specs, the specs would have been used as
"ammunition" in the local handler debate.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <5gjoel$jre$1@quasar.dimensional.com> rkaiser@dimensional.com (Richard Kaiser) writes:

> In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:
> 
> >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 assert "I will not run correctly in this new rocket?"

No.  And this is not the sort of thing that simple pre and post
conditions is going to help you with.  It's disingenuous to say
otherwise.  In fact, while this paper is fairly good in its analysis,
it is extremely poor in its conclusion.  Here's the relevant bit:

 "Does this mean that the crash would automatically have been avoided
 had the mission used a language and method supporting built-in
 assertions and Design by Contract?  Although it is always risky to
 draw such after-the-fact conclusions, the answer is probably yes:"

Well, the facts indicate that the answer should be "highly UNlikely".
Why?  Because the language used _does_ have such capabilities.  Here's
the relevant Eiffel:

convert (horizontal_bias: INTEGER): INTEGER is 
              require 
                    horizontal_bias <= Maximum_bias 
...


The *exact* analog with the *exact* same capabilities in Ada is:

function Convert ( Horizontal_Bias: Integer ) return Integer is
    subtype Bias_Constraint is Integer range 0..Maximum_Bias;
    Require : Bias_Constraint := Horizontal_Bias;
...


So, the _only_ evidence we in _fact_ have, is that this sort of
capability DOES NOT help in this sort of scenario.  And actually, that
should not be very surprising.  It is not even particularly
interesting.

Here are a few more bits which just don't hold up:

   "Assertions (preconditions and postconditions in particular) can
   be automatically turned on during testing, through a simple compiler
   option. The error might have been caught then."

Exactly the same in Ada, including the above type of constraint.

   "Assertions can remain turned on during execution, triggering an
   exception if violated. Given the performance constraints on such a
   mission, however, this would probably not have been the case."

Exactly the same in Ada, including the above type of constraint.

   "But most importantly the assertions are a prime component of the
   software and its documentation ("short form", produced automatically
   by tools). In an environment such as that of Ariane where there is so
   much emphasis on quality control and thorough validation of
   everything, they would be the QA team's primary focus of
   attention."

Exactly the same in Ada.  Assuming you actually _write_ the assertion.

   "Any team worth its salt would have checked systematically
   that every call satisfies the precondition. That would have
   immediately revealed that the Ariane 5 calling software did not meet
   the expectation of the Ariane 4 routines that it called."

Exactly the same in Ada.  Assuming the constraint was written.

But, the constraint was not written.  This despite the fact that the
language, Ada, was fully capabale of _explicitly_ expressing the
assertion with clear and easily seen demarcated code.


 Nick sez,

> >There are other more complex parts to Eiffels assertion system, in
> >relation to inheritance, and soon in relation to parallel processing.

Yes, but the bald fact of the matter is, even the most capable aspects
of Eiffel assertions are just too rudimentary to be of any use in this
sort of scenario.  They do not have anything even remotely like the
semantic context capabilities needed to address this problem.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> 
wrote:

<snip>

>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.

This was the first point of failure in the design.  The time limit in the
original software release should have been documented in a Version
Description Document or software requirements document.  And these
documents should have been reviewed for the new rocket.

>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.

But design was not done.  An old box was placed into a new rocket.  Unless
the old software could detect it was in a new application it could not handle
the only way to detect the problem was by documentation of requirements and 
limitation or by ...

>3) Debugging / Testing. Running with assertions enabled detects bugs 
>earlier. This is the real saver in time and costs. 




>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.
>
>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.
>
>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.
>
>

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> 
wrote:
>Path:
> dimensional.com!visi.com!news.maxwell.syr.edu!dispatch.news.demon.net!demon!ca
>lfp.demon.co.uk!not-for-mail
>From: Nick Leaton <nickle@calfp.co.uk>
>Newsgroups:
> comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.l
>ang.ada,comp.lang.java.tech
>Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>Date: Mon, 17 Mar 1997 09:39:07 +0000
>Message-ID: <332D113B.4A64@calfp.co.uk>
>References: <332B5495.167EB0E7@eiffel.com> <tz8ohcjv7cc.fsf@aimnet.com>
>NNTP-Posting-Host: calfp.demon.co.uk
>X-NNTP-Posting-Host: calfp.demon.co.uk
>X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
>MIME-Version: 1.0
>To: Thomas <nouser@nohost.nodomain>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Lines: 81
>Xref: dimensional.com comp.lang.eiffel:7803 comp.object:23425
> comp.software-eng:17269 comp.programming.threads:4199 comp.lang.ada:23371
> comp.lang.java.tech:8859
>Status: N
>
>Thomas wrote:
>
>> convert (horizontal_bias: INTEGER): INTEGER is
>>             require
>>                   horizontal_bias <= Maximum_bias
>>             do
>>                   ...
>> 
>>             ensure
>>                   ...
>> 
>>             end
>> 
>> What was required here was a simple check that a function argument was
>> within a certain range.  That check could have been expressed as an
>> Ada type declaration and checked by the compiler at compile time, or
>> as a runtime assertion/check.  The design team apparently decided that
>> either approach was too costly in terms of design or speed and instead
>> opted for leaving the code unsafe and documenting the conditions under
>> which the function could be used safely.  Also, they apparently did
>> not have a practice of annotating their code with assertion statements
>> for testing, and you suggest that they didn't have a standard
>> practice for documenting unchecked preconditions.
>> 
>> I don't see how the different notation that Eiffel uses for the same
>> purpose helps.  Eiffel's conditions are also enforced either at
>> compile time or at runtime, and exactly the same tradeoffs apply as
>> they do in the Ada program: you incur costs for type conversions and
>> range checks.  And if the programmer culture on a project is such that
>> they don't use Ada assertions, why would they use Eiffel
>> preconditions?
>> 
>
>Eiffel does type checking at compile time. You can check type at runtime
>but the need to do this is such that you should query if you write code
>that uses this feature. 
>
>        x ?= y
>
>x will be Void if y does not conform to they type of x.
>
>The point about culture and assertions is an interesting one. I have
>moved to a company that uses Eiffel. Initially I was very sceptical
>about assertions, for the same reason you are, that I don't see people
>using them, or that they remove them when the release the code.
>
>In practice though, you write them because as part of developing
>software they make a huge difference to development. This has an effect
>in various areas.
>
>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.

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.

>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:

>3) Debugging / Testing. Running with assertions enabled detects bugs 
>earlier. This is the real saver in time and costs. 

This is the

>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.
>
>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.
>
>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.
>
>

Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

rkaiser@dimensional.com (Richard Kaiser):
>>1) Documentation. You need less of this. Documentation which say 'This
>>feature expects this and does that' is no longer need. Documentation
>>that is needed is the 'intent' of the routine, and high level intent or
>>overviews. There are tools that can produce what is called the short
>>form, the code without the implementation built into most compilers.
>>These will also produce HTML and other outputs.

>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.

Yes, that's the point!. And the interest of using Eiffel-like assertions is that
there are standard tools (class abstracters) that are able to *automatically* extract 
this kind of document from the actual code, including *inherited* assertions.
Assertions go farther than documenting the code: they document (parts of) the 
design. And because they are extracted from the code, they have more chances to stay up to date
with the code itself.

And clearly, the main interest of assertions (as design documentation) is to
facilitate code review. Facilatating testing/debugging is only a side-effect, IMHO.

>>4) Reviews. If you review code, then having the assertions in place
>>is very useful. A large part of reviewing C++ is working out what
>>assertions have been assumed, and checking code against them. Having
>>them written into the code makes this easier.

Imagine a Design by Contract approach applied to an Ariane5-like software system:
- there is somewhere a function called convert (horizontal_bias) with 
a precondition horizontal_bias <= Maximum_bias 
- the function f that calls this function (convert(x)) must be sure that it is entitled to do it,
that is that x <= Maximum_bias. If f cannot know, it means that there is a precondition of f
of the form x <= Maximum_bias (the precondition is propagated to the caller).
- idem for f' that calls f, and so on until either I know enough about the value of x, or
eventually x comes from a source external to the package/module. In this last case, it means that
the module has a precondition on an external reading.
If you can prove that your external reading always respect the precondition 
(with some engineering margin) you're OK, as they were for Ariane4. If you try to reuse the module 
in another context, you're supposed to check its preconditions against the new environment.

The saliant points of this approach are that:
- it makes all assumptions in the code explicit at the level of a design document,
automatically extracted from the code (and properly dealing with assertion inheritance issues)
- coupled with a proper reviewing process (as it exist in this kind of mission-critical software), 
it allows the detection of this kind of problem early.

To answer  Jon  S Anthony, yes, all that could have been done in Ada using:
function Convert ( Horizontal_Bias: Integer ) return Integer is
    subtype Bias_Constraint is Integer range 0..Maximum_Bias;
    Require : Bias_Constraint := Horizontal_Bias;

Ada's subtype declarations are a kind of contract, that could be documented as such.
Design by contract is not specific to Eiffel. You can do it with any language, just because 
it is a way of designing! Eiffel is, however, one of the few languages that provide 
built-in support for it.

Let's finally sum up what I perceive as the most important claims in this paper:
- reusing a component without checking its full specification is dangerous, which means that
simple minded CORBA-like approaches at building components for mission-critical software are doomed.
- using design by contract is an interesting way to specify the behavior of a component
- at least in the case of Ariane 501, simple assertions (a la Eiffel and other languages)
would have been expressive enough to specify the fatal hidden assumption. 

Whether the last point scales up to a full sized mission critical system is still an open question.
I'm quite confident it is so, but I've only my own experience with telco systems to back it up.

-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Papers on the Ariane-5 crash and Design by Contract

[Ulrich Windl]

In article <332DA14C.41C67EA6@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Robert I. Eachus wrote:
>  
> >     How many times do people have to be told that the lack of an
> > assertion was NOT the problem here.  The assertion existed
> 
> Where?
>  
>  
> > [...] The real problem was that the software was used unchanged and
> > without review [from Ariane 4 to] Ariane 5, where these assumptions
> > were not true.
> 
> The real problem was that the assertion was not part of the software.

(I've read the story about half a year ago)

When I read that story I could not help, but had to shake my head
several times. I definitely agree with Dr. Meyer that this case should
be handled in every class about software engineering.

If I remember things right, the main problem was the interconnection
of different components that were almost correct, but failed to
communicate:

The modules computing course corrrection data both failed due to to
problems mentioned (violating the specs for that code); they shut
themselves down. But to me the main issue is that the module that
received the course correction data did not detect that both computing
modules failed and that the data was just a "test pattern" to indicate
that event. Probably a better reaction would have been to stop making
further corrections instead of driving the engine to its borders.

If the modules to compute course correction data would have failed in
a more paraniod way (the module had an exception due to overflow and
shut itself down. If it would have continue with the appropriately
signed maximum possible value, well I don't know).

Maybe one could postulate "Every part in a software system that must
not fail that receives an unexpected exception should handle the
situation as good as possible, even if it can't guarantee its
specification". This sounds contrary to programming by contract, but
sometimes this can help. Theoreticans might say "quit on the first
error encountered" while real hackers might say "continue as long as
you can".

(Excuse my non-rocket vocabulary, but this is from memory, and English
is not my first language, too)

> 
> Successful reuse requires that what you reuse be equipped with a
> specification - a contract. That's the point made Jean-Marc Jezequel
> and I made in the article at
> http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html.

Ulrich

Re: Papers on the Ariane-5 crash and Design by Contract

[Tarjei Jensen]

> Bertrand Meyer writes:
>
>  The real problem was that the assertion was not part of the software.
>

Show how it should be done.

I think you will have problems creating assertions that would catch anything
more than an Ada compiler would catch before the actual liftoff. After liftoff
no amounts of assertions will help.

Greetings,

 
-- 
// Tarjei T. Jensen 
//    tarjeij@ulrik.uio.no || fax +47 51664292  || voice +47 51 85 87 39
//   Support you local rescue centre: GET LOST!
// Working, but not speaking for the Norwegian Hydrographic Service.

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Leaton]

Richard Kaiser wrote:

> >1) Documentation. You need less of this. Documentation which say 'This
> >feature expects this and does that' is no longer need. Documentation
> >that is needed is the 'intent' of the routine, and high level intent or
> >overviews. There are tools that can produce what is called the short
> >form, the code without the implementation built into most compilers.
> >These will also produce HTML and other outputs.
> 
> This was the first point of failure in the design.  The time limit in the
> original software release should have been documented in a Version
> Description Document or software requirements document.  And these
> documents should have been reviewed for the new rocket.

But lets be practical. No body can sucessfully keep documentation in
line with code, without errors. The more the code documents itself,
and in this case I'm referring to assertions the better. Also,
programmers like programming, not documentation. Documentation is not
the product! It is an aid to producing product.


-- 

Nick

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Leaton]

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

> >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. 

-- 

Nick

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <tz8g1xtzx9y.fsf@aimnet.com>, nouser@nohost.nodomain (Thomas) wrote:

> In article <332D113B.4A64@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk>
writes:
> 
>    The point about culture and assertions is an interesting one. I have
>    moved to a company that uses Eiffel. Initially I was very sceptical
>    about assertions, for the same reason you are, that I don't see people
>    using them, or that they remove them when the release the code.
> 
> I'm not at all sceptical about assertions.  I use them liberally.
> I'm sceptical about the claim that Eiffel assertions would have
> much of a difference in this case.
> 
> Incidentally, systems that provide extensive support for "structured"
> assertions exist both for Ada and C++ (in addition to the
> straightforward support that exists in the base languages).
> 
> Thomas.

I concur. In earlier threads I pushed the point that choice of language is
not as significant as good coding practices. Meyers et. al. are to be
congratulated on creating a language that incorporates as much good coding
practices as may be possible into a language. But they lose credibility by
asserting that language can enforce good coding practices.

I have learned to use assertion exhaustively in C++, even though I do not
work on critical products. I get the point about auto-extraction of
assertions into documentation, but in the end most coders feel more secure
looking at code itself (documentation may be incomplete or out of date).
There is no substitute for self documenting code, and for that purpose
assertion is priceless.

I expect Meyers to push his own products, but to imply the Ariane-5 crash
was caused by poor choice of programming language seems out of step with
his otherwise impeccable manners.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jon S Anthony wrote:
> 
> And this is not the sort of thing that simple pre and post
> conditions is going to help you with.  It's disingenuous to say
> otherwise.  In fact, while this paper is fairly good in its analysis,
> it is extremely poor in its conclusion.  Here's the relevant bit:
> 
>  "Does this mean that the crash would automatically have been avoided
>  had the mission used a language and method supporting built-in
>  assertions and Design by Contract?  Although it is always risky to
>  draw such after-the-fact conclusions, the answer is probably yes:"

The reasoning here is quite transparent:

1. The Ariane V problem is not a language problem (true enough).

2. Our design methodology would have solved the problem (absolutely no
evidence to support this).

3. Eiffel is the best/only language that supports our methodology (could
be).

4. Use Eiffel.

>    "Any team worth its salt would have checked systematically
>    that every call satisfies the precondition. That would have
>    immediately revealed that the Ariane 5 calling software did not meet
>    the expectation of the Ariane 4 routines that it called."

Why not just say: "Any team worth its salt would have made absolutely no
errors in judgement" and leave it at that?

> --
> Jon Anthony
> Organon Motives, Inc.
> Belmont, MA 02178
> 617.484.3383
> jsa@organon.com

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]


In article <5gm8a6$2qu$2@news.irisa.fr>, jezequel@irisa.fr (Jean-Marc
Jezequel) wrote:

> >I expect Meyers to push his own products, but to imply the Ariane-5 crash
> >was caused by poor choice of programming language seems out of step with
> >his otherwise impeccable manners.
> 
> Unless our English is so bad that it betrays our thinking, we 
> *never* implied such a thing. Just a point in a case: Eiffel simply did
not exist when they 
> worked on Ariane4. Let me quote the relevant section of the paper:
> 
> <<Is it the programming language's fault?
> Although one may criticize the Ada exception mechanism, it could have
been used here
>  to catch the exception. In fact, quoting the report: [omitted]
> In other words the potential problem of failed arithmetic conversions
was recognized.
>  Unfortunately, the fatal exception was among the three that were not
monitored,
>  not the four that were.>>
> 
> In case it is not clear enough, I repeat again: *it is not a language problem*
> Let me quote another part of the paper:
> <<Does this mean that the crash would automatically have been avoided
had the mission used
> a language and method supporting built-in assertions and Design by
Contract? >>
> 
> Please note the "language and method supporting built-in assertions and
Design by Contract"
> and please do not reduce it to : "a language". 

Let me quote the entire paragraph:

"Does this mean that the crash would automatically have been avoided had
the mission used a language and method supporting built-in assertions and
Design by Contract? Although it is always risky to draw such
after-the-fact conclusions, the answer is probably yes�"

And further:

"To attempt to reuse software without Eiffel-like assertions is to invite
failures of potentially disastrous consequences."

This is somewhat confusing, since assertions and design by contract can be
easily effected in Ada, the language used for Ariane5 (and in the other
languages disparaged in the article). I acknowledge that a strict reading
of the article would not prove my point, but the implication is obvious to
an unbiased reader, that the writer believes the use of Eiffel, as opposed
to "CORBA to C++ to Visual Basic to ActiveX to Java" and ofcourse Ada,
"probably" would have prevented the crash.

Don't get me wrong: I think Eiffel is a fine language.

My point was that assertions and design by contract are good, but are not
enforced by Eiffel any more than any other modern programming language.
The presence of "built-in" assertions does not mean they will be used; a
person who would use assertions fastidiously in Eiffel is probably already
using them in C++ or Ada. If your article does not seem slanted to you,
that is probably because you wrote it - I am not the only reader that
detected a pro-Eiffel bias.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

Bertrand Meyer <bertrand@eiffel.com> wrote:

>The real problem was that the assertion was not part of the software.

No - the real problem was that the developers were _not_ provided with
Ariane 5 trajectory information which should have been used in the
analysis.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <5gm8a6$2qu$2@news.irisa.fr>, jezequel@irisa.fr (Jean-Marc
Jezequel) wrote:

> Please note the "language and method supporting built-in assertions and
Design by Contract"
> and please do not reduce it to : "a language". 


I regret my previous note where I continued to argue my point. I accept
your clarification (above). I think we have squeezed all the water out of
this stone.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <332E8C1A.3A7F@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> But lets be practical. No body can sucessfully keep documentation in
> line with code, without errors. The more the code documents itself,
> and in this case I'm referring to assertions the better. Also,
> programmers like programming, not documentation. Documentation is not
> the product! It is an aid to producing product.

And simplistic pre and post condition assertions are not sufficient
for this sort of thing.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <332E8D5D.400F@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> > 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. 

Well, that's what _happened_ in this case.  Since the result was not
satisfactory, it is clear that assertions per se are _not_ sufficient.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc Jezequel) writes:

> To answer  Jon  S Anthony, yes, all that could have been done in Ada using:
> function Convert ( Horizontal_Bias: Integer ) return Integer is
>     subtype Bias_Constraint is Integer range 0..Maximum_Bias;
>     Require : Bias_Constraint := Horizontal_Bias;
>
>  Ada's subtype declarations are a kind of contract, that could be
> documented as such.  Design by contract is not specific to
> Eiffel. You can do it with any language, just because it is a way of
> designing! Eiffel is, however, one of the few languages that provide
> built-in support for it.

You miss my point.  Which is that this stuff is NOT sufficient to have
prevented this error.  And further, the evidence supports this
position because the language used in fact _does_ have this capability
but it was _not_ used.  While design by contract is a good first step,
it _too_ is simply insufficient as currently realized.  It in no way
captures any of the semantic context that scopes the usage scenarios
that are assumed in the design and implementaion of "components".


> Let's finally sum up what I perceive as the most important claims in
> this paper:
> - reusing a component without checking its full
>   specification is dangerous, which means that simple minded
>   CORBA-like approaches at building components for mission-critical
>   software are doomed.

Agreed, but this too is simply way too simplistic.  If "full
specification" simply means signatures and their pre and post
condition requirements, it does not capture the "full" scope of the
problem.  If it does include the various semantic aspects associated
with "components", it is not and, what is more, _cannot_ be captured
in signatures and assertions.


> - using design by contract is an interesting
>   way to specify the behavior of a component

Yes, but _only_ a rather _limited_ aspect.  It is clearly better than
nothing, but alone it could not prevent the sort of problem being
discussed.


> - at least in the case of
>   Ariane 501, simple assertions (a la Eiffel and other languages)
>   would have been expressive enough to specify the fatal hidden
>   assumption.

This I simply don't believe.  And the evidence does not support it
either.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

["Paul E. Bennett"]

In article <332E8C1A.3A7F@calfp.co.uk> nickle@calfp.co.uk "Nick Leaton" writes:

> But lets be practical. No body can sucessfully keep documentation in
> line with code, without errors. 

A lot depends on where the documentation of the software is located. If 
it's in another obscurely referenced document then your statement above 
will indeed be correct. However, if the documentation of the software was 
part of the source code file itself, this would be less the case. To do this 
effectively requires that code modules are small enough to enable thorough 
review and rigourous testing for compliance and non-compliance with its 
specification.

> The more the code documents itself,
> and in this case I'm referring to assertions the better. Also,
> programmers like programming, not documentation. Documentation is not
> the product! It is an aid to producing product.
 
There is probably a whole world of difference between self-documenting code 
and plain code (locally) well documented. Whilst the former can be highly 
desirable, the latter is good enough for virtually all situations. As this 
documentation is part and parcel of the normal code commenting structure it 
is a god-send when problems are being resolved.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: Papers on the Ariane-5 crash and Design by Contract

[Ray McVay]

John McCabe wrote:
> 
> Bertrand Meyer <bertrand@eiffel.com> wrote:
> 
> >The real problem was that the assertion was not part of the software.
> 
> No - the real problem was that the developers were _not_ provided with
> Ariane 5 trajectory information which should have been used in the
> analysis.
> 
> Best Regards
> John McCabe <john@assen.demon.co.uk>

Finally!  Thank you, sir.  It was obvious from reading the report that
was pointed out several months ago by a post in this newsgroup that this
was a wonderful example of a failure WAY early in the lifecycle.  It had
nothing to do with design or construction and everything to do with a
bogus specification.  They were in effect designing a control system for
a completely different rocket than the one in which the system was used!

Re: Papers on the Ariane-5 crash and Design by Contract

[Ron Forrester]

> > designing! Eiffel is, however, one of the few languages that provide
> > built-in support for it.
> 
> You miss my point.  Which is that this stuff is NOT sufficient to have
> prevented this error.  And further, the evidence supports this
> position because the language used in fact _does_ have this capability
> but it was _not_ used.  While design by contract is a good first step,
> it _too_ is simply insufficient as currently realized.  It in no way
> captures any of the semantic context that scopes the usage scenarios
> that are assumed in the design and implementaion of "components".

Maybe a simplistic first step would be an Eiffel system that required
ensure and require clauses for all members, as well as an invariant
clause for all classes.

This would at least *help* the engineer *think* about doing it as
s/he coded.

rjf

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <332E8D5D.400F@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> 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 <assert.h> for years?  Software engineers have been using
assert macros to verify program limits are not exceeded. 

Richard Kaiser

Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <5gnttg$jkc$1@quasar.dimensional.com>, rkaiser@dimensional.com (Richard Kaiser) writes:

>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.

Yes. But in some cases, actual testing can be extremely hard to perform.
If you do not want to test during a rocket launch, you have to simulate the supposed
environment of this rocket. aka a software simulated launch. Enabling this is possible,
but you have to design your software *with this purpose in mind*. Most notably,
it means decoupling your software from your hardware, and simulating the expected behavior
of the later one. Still, you're never 100% sure that you didn't miss something in your simulation
of the environment. 

Because the Ariane4 SRI was designed as a *functional* black-box, that is
vertically integrated, this approach was simply not possible, unless you re-designed
everything instead of re-using the black-box. You cannot fool an inertial reference system,
e.g. to make it believe it follows a given trajectory, unless you make it follow this trajectory,
i.e. you launch it!

So our point in the paper is that yes, better testing would have caught the problem.
But don't throw the stone to the testers. It's not always as easy as it seems.
OTOH, assertions always help software component verification during reviews.
This is where the problem should have been detected, provided it was made explicit
enough through design by contract.


>Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
>using #include <assert.h> for years?  Software engineers have been using
>assert macros to verify program limits are not exceeded. 

Yes. This is nice. But the original point in Eiffel is that assertions are
tighly integrated within the language, and serve as a design tool before simplifying
the debugging and testing processes. Eiffel assertions belong to a method specification
(along with the method signature), not to the method implementation. For example, 
they are inherited, even when a method is overidded (BTW, if you know a simple
way of doing that in C/C++, I'm a taker). Also, it is not trivial to check class
invariants in C/C++ (how do you know, without compiler support, that the call to a
class method originates from outside or inside the class? In the former case, the class
invariant has to be checked upon entering and exiting the method, and not in the later case).

As a consequence of this tight integration, a class abstractor can automatically
collect all the assertions and present a complete abstract data type view of a class
(including all inherited pre/post conditions and class iinvariants),
whatever its position in the class hierachy.

For more details on that, you can check my book:
"Object-Oriented Software Engineering with Eiffel"
Addison-Wesley Eiffel in Practice Series, ISBN 0-201-63381-7 
http://www.irisa.fr/pampa/EPEE/book.html

-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Leaton]

Jon S Anthony wrote:
> 
> In article <332E8D5D.400F@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> 
> > > 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.
> 
> Well, that's what _happened_ in this case.  Since the result was not
> satisfactory, it is clear that assertions per se are _not_ sufficient.
> 

Yes you need exception handling in the client. But what other
alternative do you propose if you break the contract?

-- 

Nick

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Leaton]

Paul E. Bennett wrote:
> 
> In article <332E8C1A.3A7F@calfp.co.uk> nickle@calfp.co.uk "Nick Leaton" writes:
> 
> > But lets be practical. No body can sucessfully keep documentation in
> > line with code, without errors.
> 
> A lot depends on where the documentation of the software is located. If
> it's in another obscurely referenced document then your statement above
> will indeed be correct. However, if the documentation of the software was
> part of the source code file itself, this would be less the case. To do this
> effectively requires that code modules are small enough to enable thorough
> review and rigourous testing for compliance and non-compliance with its
> specification.

Exactly, and having Eiffel style assertions go one better, you 
can test them. You cannot test comments.

> > The more the code documents itself,
> > and in this case I'm referring to assertions the better. Also,
> > programmers like programming, not documentation. Documentation is not
> > the product! It is an aid to producing product.
> 
> There is probably a whole world of difference between self-documenting code
> and plain code (locally) well documented. Whilst the former can be highly
> desirable, the latter is good enough for virtually all situations. As this
> documentation is part and parcel of the normal code commenting structure it
> is a god-send when problems are being resolved.


-- 

Nick

Re: Papers on the Ariane-5 crash and Design by Contract

[Eric M. Boyd]

Jon S Anthony wrote:
> 
> And this is not the sort of thing that simple pre and post
> conditions is going to help you with.  It's disingenuous to say
> otherwise.  In fact, while this paper is fairly good in its analysis,
> it is extremely poor in its conclusion.  Here's the relevant bit:
> 
>  "Does this mean that the crash would automatically have been avoided
>  had the mission used a language and method supporting built-in
>  assertions and Design by Contract?  Although it is always risky to
>  draw such after-the-fact conclusions, the answer is probably yes:"

"There never has been, nor will there ever be a language in which it is the
least bit difficult to write bad code."

I'm quoting someone...but don't know who.

The point is the language doesn't matter...anybody can write bad code in any
language.
--------------------------------+----------------------------------------------
Eric Boyd (TSMA)                |       "It's easier to ask for 
InterDimensions Corp.           |        forgiveness than for permission."
25 Ellery St.                   |
Cambridge Ma, 02138             |       "640K ought to be enough for anybody."
617-661-4200                    |               -- Bill Gates, 1981
                                |
boyd@interdim.com               |

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Thomas wrote:
> 
> Well, what if a lot more money had been budgeted for hardware?  Could
> the space agency have paid the processor manufacturers to come out
> with a version that was 30% faster (that should have been sufficient
> to use runtime checks everywhere without changing the design)?

Some problems with doing that:

1. New designs add risk, since there's not a history of use.
2. Faster usually means more power/cooling required, which reduces
payload.
3. Processor manufacturers charge more for small production runs, which
   cuts into the profit margin. Remember that hardware is a recurring
   cost; software (in the absence of maintenance) isn't.

> Another option could have been to add more individual processors and
> use them in parallel (almost certainly harder than it sounds, but
> still a possibility).

1. Adds weight, power and cooling requirements (reducing payload).
2. Costs more (more parts)
3. Adds complexity to the design, and thus risk.

>  Or what about choosing a less ambitious flight
> trajectory and maybe lower payload so that control required less
> computation?

Would have made the Ariane V less competitive, and possibly non-viable.

> Of course, none of those would have been easy choices to make.  Design
> by contract and other methodologies are useful, but I still think
> without a solid foundation of runtime checks in the production code
> and multiple exception handlers and recovery blocks, no methodology
> alone is going to give sufficient protection from failure.  In fact,
> Eiffel itself, which has been mentioned here because of its assertion
> system, is built on a foundation of runtime safety.

However, runtime safety doesn't do much good if either/or (a) you test
on the ground to see what exceptions are raised; (b) you know how to
correct from the exception (in some cases, there IS no good response
to certain exceptions).


--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Fergus Henderson]

rkaiser@dimensional.com (Richard Kaiser) writes:

>Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
>using #include <assert.h> for years?  Software engineers have been using
>assert macros to verify program limits are not exceeded. 

The major difference between C/C++/Ada assertions and Eiffel style
design-by-contract is that in the latter, the assertions are part of
the interface, not just embedded in the implementation.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Papers on the Ariane-5 crash and Design by Contract

[Jeffrey W. Stulin]

Eric

If languages don't matter then why don't we write all programs in binary?

Jeff Stulin



In article <5gp49g$p7p$1@news.kersur.net>, boyd@interdim.com\x03 says...
>
>Jon S Anthony wrote:
>> 
>> And this is not the sort of thing that simple pre and post
>> conditions is going to help you with.  It's disingenuous to say
>> otherwise.  In fact, while this paper is fairly good in its analysis,
>> it is extremely poor in its conclusion.  Here's the relevant bit:
>> 
>>  "Does this mean that the crash would automatically have been avoided
>>  had the mission used a language and method supporting built-in
>>  assertions and Design by Contract?  Although it is always risky to
>>  draw such after-the-fact conclusions, the answer is probably yes:"
>
>"There never has been, nor will there ever be a language in which it is the
>least bit difficult to write bad code."
>
>I'm quoting someone...but don't know who.
>
>The point is the language doesn't matter...anybody can write bad code in any
>language.
>--------------------------------+--------------------------------------------
--
>Eric Boyd (TSMA)                |       "It's easier to ask for 
>InterDimensions Corp.           |        forgiveness than for permission."
>25 Ellery St.                   |
>Cambridge Ma, 02138             |       "640K ought to be enough for 
anybody."
>617-661-4200                    |               -- Bill Gates, 1981
>                                |
>boyd@interdim.com               |

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> Let's finally sum up what I perceive as the most important claims in this paper:
> - reusing a component without checking its full specification is dangerous, which means that
> simple minded CORBA-like approaches at building components for mission-critical software are doomed.
> - using design by contract is an interesting way to specify the behavior of a component
> - at least in the case of Ariane 501, simple assertions (a la Eiffel and other languages)
> would have been expressive enough to specify the fatal hidden assumption.

Although I agree that Eiffel, Ada, and other languages are expressive
enough to specify the
"fatal hidden assumption", it is not clear that being able to specify
the assumption would have
led to detection and correction of the problem.

1. Being ABLE to specify the assumption does not mean that the
assumption WILL be specified.
   From the final inquiry: "The reason for the three remaining
variables, including the one
   denoting horizontal bias, being unprotected was that further
reasoning indicated that they
   were either physically limited or that there was a large margin of
safety." It is not
   at all obvious to me that development teams routinely document
limitations that they
   consider impossible to violate! Futhermore, it should be noted that
the assumptions that
   they felt *could* be violated were in fact documented in the code:
"In particular, the
   conversion of floating point values to integers was analysed and
operations involving seven
   variables were at risk of leading to an Operand Error. This led to
protection being added to
   four of the variables, evidence of which appears in the Ada code."

2. SPECIFYING the assumption does not mean that a violation of the
assumption will be DETECTED.

   a. If the detection is based on manual inspection of the code, human
error due to incomplete
      or faulty knowledge of the operating environment can always occur.
"There is no evidence
      that any trajectory data were used to analyse the behaviour of the
unprotected variables,
      and it is even more important to note that it was jointly agreed
not to include the Ariane
      5 trajectory data in the SRI requirements and specification." How
would the development
      team know there was a problem if they did not have sufficient
information?

      Futhermore, even if the information is available, performing the
appropriate analysis to
      determine the effect at the low-level software interfaces can be
difficult: "software is
      flexible and expressive and thus encourages highly demanding
requirements, which in turn
      lead to complex implementations which are difficult to assess."

      Finally, the human must know the right question to ask: "When
taking this
      design decision, it was not analysed or fully understood which
values this particular
      variable might assume when the alignment software was allowed to
operate after lift-off."

   b. If the detection is based on embedded run-time checks, such
detection is based on the
      operation of the system in such a manner (in a real or simulated
environment) that the
      check will be triggered. "...no test was performed to verify that
the SRI would behave
      correctly when being subjected to the count-down and flight time
sequence and the
      trajectory of Ariane 5." It should be noted that this test was
entirely possible:
      "it is possible to do ground testing by injecting simulated
accelerometric signals in
      accordance with predicted flight parameters, while also using a
turntable to simulate
      launcher angular movements."

3. Even if the problem was DETECTED, there is no guarantee that the
appropriate ACTION would
have been taken:

   a. With respect to manual detection: On the X-29 program, an engineer
in the control room knew
      that the air data sensor heating was not operational. He assumed
that others knew, and that
      the appropriate action was taken. It wasn't, and as I recall, an
aircraft was lost. In
      any large-scale development effort, it is very easy to lose
critical information of this
      type.

   b. With respect to operational run-time checks, the right decisions
about how to react to
      the check must be made: "Although the source of the Operand Error
has been identified,
      this in itself did not cause the mission to fail. The
specification of the
      exception-handling mechanism also contributed to the failure....
It was the decision to
      cease the processor operation which finally proved fatal."

Based on the published inquiry, I am extremenly skeptical that a
software design technique
by itself would have avoided the Ariane V disaster. If you have inside
information from
the Ariane V team that indicates otherwise, please share it.

The final inquiry report is at:
http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

> Whether the last point scales up to a full sized mission critical system is still an open question.

Very much so.

> I'm quite confident it is so, but I've only my own experience with telco systems to back it up.
> 
> --
> Jean-Marc Jezequel               Tel : +33 2 99847192
> IRISA/CNRS                       Fax : +33 2 99847171
> Campus de Beaulieu               e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <332FD608.2CDB@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:

> Jon S Anthony wrote:
> > 
> > In article <332E8D5D.400F@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> > 
> > > > 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.
> > 
> > Well, that's what _happened_ in this case.  Since the result was not
> > satisfactory, it is clear that assertions per se are _not_ sufficient.
> > 
> 
> Yes you need exception handling in the client. But what other
> alternative do you propose if you break the contract?

I'm not proposing anything.  I'm trying to point out that the
conclusion of this paper, assertions on signatures would _probably_
have prevented the error, is pure unadulterated RUBBISH.

First, such assertions _were_ there (though only implicitly _after_ a
concious choice to _remove_ the explicit stuff).

Second, the exception was raised, but the fact that there was no
handler was _intentional_ and _correct_ for the semantic context that
the component was written for!

Third, that semantic context is vastly richer than could ever be
captured in simpe minded pre and post conditions.  A fact that should
be _obvious_, and which in any case is directly supported by the
_actual_ evidence.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Karel Th�nissen]

Thomas wrote:
>
> In fact,
> Eiffel itself, which has been mentioned here because of its assertion
> system, is built on a foundation of runtime safety.

True, but there is reason to believe that it is simpler to obtain a
reliable runtime system for a programming language then for a flight
control system. Not only is the flight control system depending on the
runtime system (adding an additional layer of complexity), but also for
several reasons it is easier to test and mature the runtime system. The
runtime system does not need a complicated testing environment and gets
tested every day by each of its users. By the time it qualifies for
space, it will have had its child diseases.

Unfortunately, one major software firm is well known for using its
customers as unpaid beta-testers....

Groeten, Karel

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]


In article <332d65a9.21952314@news.interbusiness.it>,
sartori.elettronica@intercity.shiny.it wrote:

> Dear gentlemen,
> I've missed the original post, and I can't find it with DejaNews.
> Would anybody post again it (or tell me if any other archive exists)?
> 

The original post simply announced the following paper:

http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

by:

Jean-Marc J�z�quel, IRISA 
Bertrand Meyer, ISE 


Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Karel Th�nissen]

Thomas wrote:
>
> In fact,
> Eiffel itself, which has been mentioned here because of its assertion
> system, is built on a foundation of runtime safety.

True, but there is reason to believe that it is simpler obtain a
reliable runtime system for a programming language then for a flight
control system. Not only is the flight control system depending on the
runtime system (adding an additional layer of complexity), but also for
several reasons it is easier to test and mature the runtime system. The
runtime system does not need a complicated testing environment and gets
tested every day by each of its users. By the time it qualifies for
space, it will have had its child diseases.

Unfortunately, one major software firm is well known for using its
customers as unpaid beta-testers....

Groeten, Karel

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Ulrich Windl wrote:
> 
> The modules computing course corrrection data both failed due to to
> problems mentioned (violating the specs for that code); they shut
> themselves down. But to me the main issue is that the module that
> received the course correction data did not detect that both computing
> modules failed and that the data was just a "test pattern" to indicate
> that event. Probably a better reaction would have been to stop making
> further corrections instead of driving the engine to its borders.

This is the same as saying: "If the driver of an automobile has a heart
attack and dies, the steering system should ignore further inputs and
lock the wheels in the last 'good' position." It doesn't work with
automobiles,
and it doesn't work with missiles, either. The flight control system
must
receive valid sensor data to maintain control of the aircraft. There is
generally no reasonable 'fail-safe" value for a feedback system like
this!

> If the modules to compute course correction data would have failed in
> a more paraniod way (the module had an exception due to overflow and
> shut itself down. If it would have continue with the appropriately
> signed maximum possible value, well I don't know).
> 
> Maybe one could postulate "Every part in a software system that must
> not fail that receives an unexpected exception should handle the
> situation as good as possible, even if it can't guarantee its
> specification". This sounds contrary to programming by contract, but
> sometimes this can help. Theoreticans might say "quit on the first
> error encountered" while real hackers might say "continue as long as
> you can".

Sounds good. Unfortunately, sometimes there is not an obvious way to
continue. This is the fallacy of the "add exception handlers to make
code safer" crowd - there has to be a reasonable response to the failure
available to the designer. Sometimes, there isn't one. Adding exception
handlers where there isn't a reasonable response only makes the design
more complex - which generally means a greater risk of failure!

> 
> (Excuse my non-rocket vocabulary, but this is from memory, and English
> is not my first language, too)
> 
> >
> > Successful reuse requires that what you reuse be equipped with a
> > specification - a contract. That's the point made Jean-Marc Jezequel
> > and I made in the article at
> > http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html.
> 
> Ulrich

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <5goe44$ngf$2@news.irisa.fr>, jezequel@irisa.fr (Jean-Marc Jezequel) wrote:
>
>In article <5gnttg$jkc$1@quasar.dimensional.com>, rkaiser@dimensional.com
> (Richard Kaiser) writes:
>
>>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.
>
>Yes. But in some cases, actual testing can be extremely hard to perform.
>If you do not want to test during a rocket launch, you have to simulate the
> supposed
>environment of this rocket. aka a software simulated launch. Enabling this is
> possible,
>but you have to design your software *with this purpose in mind*. Most notably,
>it means decoupling your software from your hardware, and simulating the
> expected behavior
>of the later one. Still, you're never 100% sure that you didn't miss something
> in your simulation
>of the environment. 
>
>Because the Ariane4 SRI was designed as a *functional* black-box, that is
>vertically integrated, this approach was simply not possible, unless you
> re-designed
>everything instead of re-using the black-box. You cannot fool an inertial
> reference system,
>e.g. to make it believe it follows a given trajectory, unless you make it
> follow this trajectory,
>i.e. you launch it!

There are TWO ways to do this kind of testing.  
1. Replace the gyros with simulation computer driven D/A converters.
2. Place the navigation unit in a three or four axis table and load the
   acceleration numbers via a test message or a special test port.

Where I work we use both methods and can run full end-to-end testing
with either the flight computer and navigation unit only or we have run 
a full end-to-end test with a full-up equipment section.  With this testing
we have gone from it should work to we have proven most of it works
(aerodynamic models require actual flights to get them exact).  

>So our point in the paper is that yes, better testing would have caught the
> problem.
>But don't throw the stone to the testers. It's not always as easy as it seems.
>OTOH, assertions always help software component verification during reviews.
>This is where the problem should have been detected, provided it was made
> explicit
>enough through design by contract.

The stones are going to management and to system engineering.  With the 
cost of launch vehicles and payload (plus ground damage such as $50 for
the Delta failure) how can you not perform end-to-end testing?  The system
group was responsible for flowing down requirements and for verifying these
requirements were met.  Management assumed the navigation boxes  were
"interchangeable hardware" black boxes when they are integrated hardware
and software units. 

>>Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
>>using #include <assert.h> for years?  Software engineers have been using
>>assert macros to verify program limits are not exceeded. 

<snip on assertions>

The limits analysis can be more automated and can be more automatic and
easier to use by programmer instead of software engineers.  But they are
not new.

>For more details on that, you can check my book:
>"Object-Oriented Software Engineering with Eiffel"
>Addison-Wesley Eiffel in Practice Series, ISBN 0-201-63381-7 
>http://www.irisa.fr/pampa/EPEE/book.html
>

Re: Papers on the Ariane-5 crash and Design by Contract

[Chris Brand]

Bertrand Meyer wrote:
> 
> We have made available on-line the paper that Jean-Marc Jezequel
> and I published in the January issue of IEEE Computer about the
> June 1996, software-induced $500-million crash of the Ariane 5
> mission, and the lessons it holds for software development
> --  in particular the role of contracts for reusable software.
> 

In your paper, you note that "Any team worth its salt would have checked
systematically that every call satisfies the precondition.", which is,
of course, equally true with the code in Ada, or any other language.

It is interesting that you chose not to comment on the statement in the
report that "it was jointly agreed not to include the Ariene 5
trajectory data in the SRI requirements and specification.". In which
case, examination of the preconditions would have been unlikely to
prevent the problem, because the expected trajectory was not in the
requirments or specification for the re-used software.

I feel that Eiffel's assertions are a good idea, but the suggestion that
the use of them could have avoided the Ariene 5 crash is wrong.

-- 
Chris
Stating my own opinions, not those of my company.

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

> rkaiser@dimensional.com (Richard Kaiser) writes:
> 
> >Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
> >using #include <assert.h> for years?  Software engineers have been using
> >assert macros to verify program limits are not exceeded. 
> 
> The major difference between C/C++/Ada assertions and Eiffel style
> design-by-contract is that in the latter, the assertions are part of
> the interface, not just embedded in the implementation.


Well, in this particular sort of case, your claim here is not correct
for Ada:


subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;

function Convert ( High_Bias : Bias_Constraint ) return Integer;


The asserstion is part of the interface, NOT the implementation.
Further, to answer a point of Jean's, it will be inherited in any
appropriate derivation case.  And certainly we could do the same for
the post condition (the return subtype).


Now, as John McCabe, Ken Garlington, myself and others have pointed
out, none of this was (or is in any sense likely to be) sufficient to
prevent the type of error exhibited by this example.  The required
semantic context (scope of use, intended behavior, presumed
environment, etc) is far to rich and complex to be dealt with by such
rudimentary simple minded stuff as pre and post conditions on
signatures.  *THE* most alarming aspect of this entire discussion is
that many, including folks the caliber of Meyer and Jezequel, don't
seem to understand this.  Now that is damn _scary_.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Matt Kennel (Remove 'nospam' to reply)]

Hmm.  Doesn't it seem that the proper course for something like the
overflow error would have been to set the result to a "NaN"??

This may propagate undesirably through part of the system, but the control
software could realize that and proceed to use 'uncontaminated' inputs.

Non-signalling 'NaN's are usually undesirable for running scientific research
codes.  We tend to get really upset when our hour long jobs do nothing
but print out a datafile of NaN's, especially when the low-level signal
handling on many CPUs mean the run will be extra-slow.

As it would happen, the standard compiler options on workstations make
silent NaN's the norm (where they are usually dumb), but yet the "abort
everything upon overflow" was done on a rocket controller where continuing
NaN's would be more useful.

Murphy's cackling his head off. 

-- 
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
Don't blame me, I voted for Emperor Mollari. 

Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <33307a43.1705970@news.demon.co.uk>, john@assen.demon.co.uk (John McCabe) writes:
>I am a bit unhappy with the way the paper has been written. As I
>mentioned in another posting on this thread, the fundamental problem
>was that the developers did not have Ariane 5 trajectory data to work

Yes this is true. But, since the SRI was reused from Ariane4, the problem
is not with developers, but with the *integration* team.

>with. It was apparently "agreed at various contractual levels" that
>this would not be provided, so using the Ariane 5 failure as a
>demonstration of how useful Eiffel's assertions (or even Design by
>Contract possibly) could have helped is fundamentally flawed!

AFAIK, the integration team had the possibility to work with Ariane 5 trajectory data,
and in the ideal case where Design by Contract would have been used on the SRI,
they would have the opportunity the check it wrt the environment of Ariane5.

-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Papers on the Ariane-5 crash and Design by Contract

[Paul Johnson]

jsa@alexandria (Jon S Anthony) wrote:
>In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

>> The major difference between C/C++/Ada assertions and Eiffel style
>> design-by-contract is that in the latter, the assertions are part of
>> the interface, not just embedded in the implementation.

>Well, in this particular sort of case, your claim here is not correct
>for Ada:

>subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;
>
>function Convert ( High_Bias : Bias_Constraint ) return Integer;
>
>
>The asserstion is part of the interface, NOT the implementation.

Yes, but this doesn't help.  Sure, the range limit is in the interface
to the conversion routine, but there is no way (other than comments)
to propogate that limit into the interfaces of its callers, and no
methodological rule that says you should.

The point about Eiffel is not merely that it has the syntax to express
these limits, but that it also has the rules and "programmer culture"
that causes these mechanisms to be used routinely.  This might well
have caused the limit in question to documented at a high enough level
to have been noticed by whoever it was that decided to re-use the Ariane
4 inertial guidance system.  Its not certain, but its a lot more likely.

The report said that the limits *were* documented (commented I think)
in the code, but this was essentially invisible to any kind of management
oversight.  Had the limitation been propogated to a high level interface
then its more likely that someone would have noticed.

Having said that, I must admit that this exception was caused by a high
horizontal speed sensed by the unit, rather than external data which
violated preconditions.  Hence the restriction would not have appeared
at the API level for the sensor.

Paul.

-- 
Paul Johnson            | GEC-Marconi Ltd is not responsible for my 
opinions. |
+44 1245 242244         
+-----------+-----------------------------------------+
Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of 
little
Home: <Paul@treetop.demon.co.uk>    | standards, all different.

Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <JSA.97Mar19144933@alexandria>, jsa@alexandria (Jon S Anthony) writes:
>In article <5gp3hd$i0l@mulga.cs.mu.OZ.AU> fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:

>> >Why is Eiffel saying assertions are a new tool?  C (and now C++) have been
>> >using #include <assert.h> for years?  Software engineers have been using
>> >assert macros to verify program limits are not exceeded. 

>> The major difference between C/C++/Ada assertions and Eiffel style
>> design-by-contract is that in the latter, the assertions are part of
>> the interface, not just embedded in the implementation.

>Well, in this particular sort of case, your claim here is not correct
>for Ada:

>subtype Bias_Constraint is Integer range Min_Bias..Max_Bias;
>
>function Convert ( High_Bias : Bias_Constraint ) return Integer;

>The asserstion is part of the interface, NOT the implementation.
>Further, to answer a point of Jean's, it will be inherited in any
>appropriate derivation case.  And certainly we could do the same for
>the post condition (the return subtype).

Yes, that's true for pre- and post that actually correspond to range
constraints. But remember that Eiffel pre- and post can be much more general
than that, including any arbitrary function call.
Also, how do you check/inherit your class invariants in Ada?
(this is a real question, I really don't know whether it is possible)

>Now, as John McCabe, Ken Garlington, myself and others have pointed
>out, none of this was (or is in any sense likely to be) sufficient to
>prevent the type of error exhibited by this example.  The required
>semantic context (scope of use, intended behavior, presumed
>environment, etc) is far to rich and complex to be dealt with by such
>rudimentary simple minded stuff as pre and post conditions on

In general, this may be true. But in this particular Ariane 501 crash, I maintain
that such "stuff" would have been  enough, for a team fully embrassing design by contract,
to specify this particular assumption. By the mere definition of design by contract, 
they should have done this. Then, with the process explained in another of my posts,
the constraint (along with many, many others) would have propagated to the boundaries of
the SRI module, as a constraint on the environment where the module could be reuse.

I would expect that you could agree with me on that, because it is just a bare bone application
of design by contract. What I concede you (Jon), is that the set of assertions
emerging at the SRI module level could have been so complex that it would have made
verification in the context of Ariane5 very costly in human ressources. 
I know that humans can fail, but I'm confident that, given enough ressources (and 
avoiding a 500M$ crash gives you some leeway) it could have been succesful.
You may disagree on this point, and we can stop this discussion by agreeing to disagree.

In the light of their very constructive posts and mails, I concede to Ken Garlington and 
Paul Dietz that re-testing of the SRI in the context of the Ariane5 trajectory would
not have been as hard as I have thought initialy. But in any case, the solution they propose
would have broken the idea of a black-box (integrating all the inertial hardware and software)
reuse, since you have to enter the black box to "feed simulated accelerometer signals into the
rest of the system". OK, I admit this is a bit of dialectics, but it still illustrates one of the
main point of the paper: beware of black-box reuse (aka component reuse), when the specification
is limited to routine signatures (a la CORBA).

>signatures.  *THE* most alarming aspect of this entire discussion is
>that many, including folks the caliber of Meyer and Jezequel, don't

Thanks for putting me on the same level as B. Meyer. I'm feeling flattered;-)


-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: Papers on the Ariane-5 crash and Design by Contract

[John the Hamster]

Nick Leaton wrote:
<<snip discussion of code documentation>>
...
> But lets be practical. No body can sucessfully keep documentation in
> line with code, without errors. The more the code documents itself,
> and in this case I'm referring to assertions the better. Also,
> programmers like programming, not documentation. Documentation is not
> the product! It is an aid to producing product.

Check out literate programming. See the newsgroup 
comp.programming.literate.

Regards,
Steve Furlong

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <33308C91.40CC@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com>
                <332D113B.4A64@calfp.co.uk> <EACHUS.97Mar17120250@spectre.mitre.org>
                <332DA14C.41C67EA6@eiffel.com> <WIU09524.97Mar18100523@rrzc4> wrote:
>Ulrich Windl wrote:
>> 
>> The modules computing course corrrection data both failed due to to
>> problems mentioned (violating the specs for that code); they shut
>> themselves down. But to me the main issue is that the module that
>> received the course correction data did not detect that both computing
>> modules failed and that the data was just a "test pattern" to indicate
>> that event. Probably a better reaction would have been to stop making
>> further corrections instead of driving the engine to its borders.
>
>This is the same as saying: "If the driver of an automobile has a heart
>attack and dies, the steering system should ignore further inputs and
>lock the wheels in the last 'good' position." It doesn't work with
>automobiles,
>and it doesn't work with missiles, either. The flight control system
>must
>receive valid sensor data to maintain control of the aircraft. There is
>generally no reasonable 'fail-safe" value for a feedback system like
>this!

Data validity bits have been included in data messages for years.  I used them
in aircraft interfaces where one or more boxes could fail and the system still
had to function.  The error message dumped by the navigation subsystem 
should not have been interpretable as data.  Now this may not have helped 
to guide the vehicle in this situation.

Richard Kaiser

Re: Papers on the Ariane-5 crash and Design by Contract

[Martin Tom Brown]

In article <33308C91.40CC@lmtas.lmco.com>
           GarlingtonKE@lmtas.lmco.com "Ken Garlington" writes:

> Ulrich Windl wrote:
> > 
> > The modules computing course corrrection data both failed due to to
> > problems mentioned (violating the specs for that code); they shut
> > themselves down. But to me the main issue is that the module that
> > received the course correction data did not detect that both computing
> > modules failed and that the data was just a "test pattern" to indicate
> > that event. Probably a better reaction would have been to stop making
> > further corrections instead of driving the engine to its borders.
> 
> This is the same as saying: "If the driver of an automobile has a heart
> attack and dies, the steering system should ignore further inputs and
> lock the wheels in the last 'good' position." It doesn't work with
> automobiles, and it doesn't work with missiles, either.

Whilst I am generally in agreement, it isn't usually beyond the 
wit of man to design in a relatively primitive hardware bias on
servo systems so that they fly top dead centre with no input.
Or fly round in small circles or whatever the design team decide 
is the least embarassing failure mode. At least that way the rocket
survives for long enough that humans can decide kill or cure.

The deadman's handle on a train springs to mind as an example
of this sort of approach. Even so failures can still occur :(

> The flight control system must
> receive valid sensor data to maintain control of the aircraft. There is
> generally no reasonable 'fail-safe" value for a feedback system like
> this!

Although the component module that failed was not producing useful 
course correction data at the time, it's diagnostic output was quite
sufficient to wreck the flight control system. 

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

jezequel@irisa.fr (Jean-Marc Jezequel) wrote:

>In article <33307a43.1705970@news.demon.co.uk>, john@assen.demon.co.uk (John McCabe) writes:
>>I am a bit unhappy with the way the paper has been written. As I
>>mentioned in another posting on this thread, the fundamental problem
>>was that the developers did not have Ariane 5 trajectory data to work
>
>Yes this is true. But, since the SRI was reused from Ariane4, the problem
>is not with developers, but with the *integration* team.

I think there was a bit more to it than just getting one off the
shelf. I quote from the inquiry report:

"The design of the Ariane 5 SRI is practically the same as that of an
SRI which is presently used on Ariane 4, particularly as regards the
software."

Note Practically the same - not identical.

>AFAIK, the integration team had the possibility to work with Ariane 5 trajectory data,
>and in the ideal case where Design by Contract would have been used on the SRI,
>they would have the opportunity the check it wrt the environment of Ariane5.

Again, I quote:

"There is no evidence that any trajectory data were used to analyse
the behaviour of the unprotected variables, and it is even more
important to note that it was jointly agreed not to include the Ariane
5 trajectory data in the SRI requirements and specification."



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <5gqrkt$bp1$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc Jezequel) writes:

  > In general, this may be true. But in this particular Ariane 501
  > crash, I maintain that such "stuff" would have been enough, for a
  > team fully embrassing design by contract, to specify this
  > particular assumption. By the mere definition of design by
  > contract, they should have done this. Then, with the process
  > explained in another of my posts, the constraint (along with many,
  > many others) would have propagated to the boundaries of the SRI
  > module, as a constraint on the environment where the module could
  > be reuse.

  All this was done for Ariane 4.  When it came time to reuse the
software on Ariane 5, the plan was to verify that the Ariane 4
software and hardware met the Ariane 5 requirements by testing.

  The testing rig was cancelled as too expensive and behind schedule,
so the software was reused without testing and without a requirements
review. 

  > I would expect that you could agree with me on that, because it is
  > just a bare bone application of design by contract...

   Get it through your head.  There is no evidence that the Ariane 5
flight dynamics requirements were EVER in the same building or
possibly the same country as the Ariane 4 guidance system specs.  If
even the most cursory spec review was done, it would have caught and
fixed the problem.

   The problem is not the in the way design by contract was or was not
implemented on the Ariane 4.  It is that the software was reused
without ever checking that it was fit for its new role.

   If you had a 1993 Audi engine controller chip and put it in your
new 1997 Audi, it might work.  Or it might burn up the engine.  Or the
engine might not run at all.  Or... You get the picture.  This is
precisely what Arianespace did.  The chip fit the socket so they
plugged it in and tried it.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <5gqtve$1ol@gcsin3.geccs.gecm.com> Paul Johnson <paul.johnson@gecm.com> writes:

   >function Convert ( High_Bias : Bias_Constraint ) return Integer;

  > Yes, but this doesn't help.  Sure, the range limit is in the interface
  > to the conversion routine, but there is no way (other than comments)
  > to propogate that limit into the interfaces of its callers, and no
  > methodological rule that says you should.

   The way to do this, if appropriate, is to use a derived type not a
subtype:

   type Bias_Constraint is new Integer range Min_Bias..Max_Bias;

   ...but that would not be appropriate here.  The horizontal velocity
should be permitted to range up to at least 25000 kilometers/second or
more.  It was just in this one routine where the value was limited.
So it makes sense to have the routine do an internal check and have
the external interface include an exception called maybe
Too_Fast_for_Calibration that would be raised in the case of overflow.
As it was, the exception raise was effetively Hardware_Broken, and the
rest is history.

  > The point about Eiffel is not merely that it has the syntax to
  > express these limits, but that it also has the rules and
  > "programmer culture" that causes these mechanisms to be used
  > routinely.  This might well have caused the limit in question to
  > documented at a high enough level to have been noticed by whoever
  > it was that decided to re-use the Ariane 4 inertial guidance
  > system.  Its not certain, but its a lot more likely.

  Again, this is part of where the process was totally haywire.  The
decision to reuse the software HAD ALREADY BEEN MADE when the
developers were debating this issue and adding the quick turnaround
support.  But the Ariane 4 developers were not allowed to see the
planned Ariane 5 flight profile, and the Ariane 5 designers never
looked at the Ariane 4 software specs.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Marin David Condic, 561.796.8997, M/S 731-93]

Thomas <nouser@NOHOST.NODOMAIN> writes:
>I have implemented a number of signal processing algorithms both using
>small integer and floating point arithmetic.  The floating point
>versions were not only much easier to develop, they also were
>considerably more robust.  That is true even if both the inputs
>and outputs of the system are actually small integers (as they
>usually are when it comes to sensors and effectors).  On low-end
>hardware, the floating point versions are, of course, somewhat
>slower (on modern RISCs there is often no difference).
>
    We've found that on machines with on-board floating point, the
    difference between scaled integers and floating point ends up
    being about a wash. While the integer arithmetic may be faster,
    there's usually more overhead in converting between scalings and
    so forth. (Of course, this may be very application specific. YMMV)

    As for overflow situations - you're right that the use of floating
    point usually means more than enough resolution so you never see
    it overflow. It might have saved the Ariane. What might also have
    saved them would be if the arithmetic on the machine had saturated
    instead of causing an interrupt. (Disable the interrupt & let the
    hardware saturate or enable the interrupt & put your own
    saturation software in there.) Floating point usually saturates
    the way you want it to from hardware, but fixed usually doesn't.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
        In Vegas, I got into a long argument with the man at the
        roulette wheel over what I considered to be an odd number.

            --  Steven Wright
===============================================================================

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

nouser@nohost.nodomain (Thomas) wrote:

>Well, what if a lot more money had been budgeted for hardware? 

The bid would probably never have been accepted.

>Could
>the space agency have paid the processor manufacturers to come out
>with a version that was 30% faster (that should have been sufficient
>to use runtime checks everywhere without changing the design)?

The European Space Agency has been funding a lot of development work
over the years, effectively the GPS MA31750 was funded by ESA, and
look at the performance that has produced (as I mentioned before
1.3MIPS @ 10MHz for the I iteration). When we first looked at using
the MA31750, GPS data books spoke of a 22Mhz version (the JMA31750),
but that was never built. We then found out that the latest version
available was the G Iteration which, while specced at 10MHz, didn't
work at >6MHz. We then looked at the H which was again specced at
10MHz but didn't work properly above 8! We finally used the I version
which was specced at 10MHz, and almost worked at that speed apart from
a few data dependent instructions (which didn't work at any speed!).
So again, it's not as simple as it looks.

ESA's thrust now is on a project called ERC32 (see the ESA web pages
at http://www.estec.esa.nl/ (I think)), which is basically a Rad-Hard
Sparc chipset being developed by the French company MHS. It is very
powerful compared to any previous attempts at using up-to-date
technology in space (at least Rad-Hard technology anyway), but because
of this uses a lot of watts!

>Another option could have been to add more individual processors and
>use them in parallel (almost certainly harder than it sounds, but
>still a possibility).  Or what about choosing a less ambitious flight
>trajectory and maybe lower payload so that control required less
>computation?

You would of course increase cost and power consumption in this way,
and also complexity, however, I'm not so sure about that being harder
than it sounds, there's a lot of this technique about these days**. A
lot more thought would have to have gone into it to repartition the
functionality of the system, but this would probably have been a very
good thing to do anyway by the sounds of the original ESA/CNES report.


**The system I have just finished working on uses 1 microprocessor and
2 ASICs. One of the ASICs is very complex and includes a 1553 protocol
handler and a DMA controller interfacing with the processor. That
functionality could have been implemented by another microprocessor
except we had certain restrictions that made that impossible.

>Of course, none of those would have been easy choices to make.  Design
>by contract and other methodologies are useful, but I still think
>without a solid foundation of runtime checks in the production code
>and multiple exception handlers and recovery blocks, no methodology
>alone is going to give sufficient protection from failure.  In fact,
>Eiffel itself, which has been mentioned here because of its assertion
>system, is built on a foundation of runtime safety.

I am a bit unhappy with the way the paper has been written. As I
mentioned in another posting on this thread, the fundamental problem
was that the developers did not have Ariane 5 trajectory data to work
with. It was apparently "agreed at various contractual levels" that
this would not be provided, so using the Ariane 5 failure as a
demonstration of how useful Eiffel's assertions (or even Design by
Contract possibly) could have helped is fundamentally flawed!

>It's good to hear from someone in the industry, by the way; thanks
>for participating.

You're welcome, I'm happy to be contributing.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

nouser@nohost.nodomain (Thomas) wrote:

>In article <332d95c9.1004852@news.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes:

<..snip..>

I forgot to address this bit:

>Or what about choosing a less ambitious flight
>trajectory and maybe lower payload so that control required less
>computation?

This was one of the ironies of it all i.e. the computations being
performed at the time of the exception were completely unnecessary and
should not have been performed at the time. Sure with a lower CPU
loading you could have put in checks, but it sounds to me like noone
had a clue what they should do if they detected a fault anyway.



Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

[Gavin Collings]

Niall Cooling <niall@feabhas.co.uk> wrote in article
<AF58300896684E8E07@pstn-dyn13.hiway.co.uk>...
> This is where I like the Java model
> where, if using a member function that may raise an exception, you must
> either handle it or propagate it, you cannot just ignore it (I do not
know
> enough about Eiffel to comment).

I wholly agree with you on the Java model.  I believe Eiffel does not do
much
for you here.  Although it does express relationships between post/pre-
conditions and inheritance (which I don't think Java does),  the only
'data'
passed between client and supplier is a boolean (success or failure).
Although this ties in nicely with the ideas expressed in OOSC,  i.e. a
routine
should either succeed or fail, nothing else, it does limit the options for
retry
clauses in clients - who cannot distinguish between multiple modes of
failure and are therefore usually in no position to "fix and retry".  (In
my opinion,
querying the immediate supplier for lasterror does not work very well -
especially as the exception may have been generated by a supplier's
supplier...)

Although I don't approve of using exceptions as a modified form of
longjmp()
I am attracted to the idea of catching exception objects based on their
run-time type and I'm sure Eiffel is missing some semantic content here.
Hopefully, there is an elegant way to combine the two approaches.

   raise( !!MyException.make() );
   require/ensure ( BOOLEAN ) else raise();
   rescue( e : MyException );

plus compiler support to detect un-rescued exception types

??

-- 
Gavin Collings
gcollings@sperry-sun.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Ron Forrester wrote:
> 
> Maybe a simplistic first step would be an Eiffel system that required
> ensure and require clauses for all members, as well as an invariant
> clause for all classes.
> 
> This would at least *help* the engineer *think* about doing it as
> s/he coded.

The final report states quite explicitly that the SRI team did *think*
about this, and made a decision that was reviewed and approved at
several
levels. This was not the problem!



> 
> rjf

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> Unless our English is so bad that it betrays our thinking, we
> *never* implied such a thing. Just a point in a case: Eiffel simply did not exist when they
> worked on Ariane4. Let me quote the relevant section of the paper:
> 
> <<Is it the programming language's fault?
> Although one may criticize the Ada exception mechanism...

Interestingly enough, such a statement is not made about Eiffel
assertions,
although one could criticize those as well (or any feature of any
language, for that matter.)

Later in the paper:

"From the principle of Design by Contract expounded by earlier columns,
we
know that any software element that has such a fundamental constraint
should
state it explicitly, as part of a mechanism present in the programming
language, as in the Eiffel construct..."

Interestingly, all of the coding examples are in Eiffel, although
apparently
any language could have been used. Or could it? From later in the paper:

"To attempt to reuse software without Eiffel-like assertions..."
                                      ^^^^^^

Note that these are not characterized as "design by contract-like"
assertions, but Eiffel-like assertions. The paper goes on to make it
clear that not just any language will do:

"It is regrettable that this lesson has not been heeded by such recent
designs as Java (which added insult to injury by removing the modest
assert
instruction of C!), IDL (the Interface Definition Language of CORBA,
which is intended to foster large-scale reuse across networks, but fails
to provide
any semantic specification mechanism), Ada 95 and ActiveX."

From this we learn that Java and Ada 95 are not properly designed for
Design by Contract. What does a language need to support Design by
Contract?
We are told... 

"For reuse to be effective, Design by Contract is a requirement. Without
a precise specification attached to each reusable component --
precondition,
postcondition, invariant -- no one can trust a supposedly reusable
component."

I wonder which languages have built-in precondition, postcondition, and
invariant statements...

It's bad enough that you post statements that are explicitly
contradicted
by the Ariane V final report (e.g. that the IRS could not be tested in
a black-box environment). When you post statements that are contradicted
by your *own* paper...

> 
> --
> Jean-Marc Jezequel               Tel : +33 2 99847192
> IRISA/CNRS                       Fax : +33 2 99847171
> Campus de Beaulieu               e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ulrich Windl]

In article <33308C91.40CC@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:

> Ulrich Windl wrote:
> > 
> > The modules computing course corrrection data both failed due to to
> > problems mentioned (violating the specs for that code); they shut
> > themselves down. But to me the main issue is that the module that
> > received the course correction data did not detect that both computing
> > modules failed and that the data was just a "test pattern" to indicate
> > that event. Probably a better reaction would have been to stop making
> > further corrections instead of driving the engine to its borders.
> 
> This is the same as saying: "If the driver of an automobile has a heart
> attack and dies, the steering system should ignore further inputs and
> lock the wheels in the last 'good' position." It doesn't work with
> automobiles,

Well, the main problem i see is "detecting the heart attack" here.

> and it doesn't work with missiles, either. The flight control system
> must
> receive valid sensor data to maintain control of the aircraft. There is
> generally no reasonable 'fail-safe" value for a feedback system like
> this!

I was never claiming fail-safe-ness, but back in University the
professor teaching logic used constructs like "loop-forever" or "halt"
in situations where a precondition was violated. I just wanted to say
that there is a better way in most cases. Still you can flash the read
light, or start the post-mortem dump if you like.

(It's completely off-topic, but if you think about your body, it works
a lot like that. Otherwise you would die too easily.)

> 
> > If the modules to compute course correction data would have failed in
> > a more paraniod way (the module had an exception due to overflow and
> > shut itself down. If it would have continue with the appropriately
> > signed maximum possible value, well I don't know).
> > 
> > Maybe one could postulate "Every part in a software system that must
> > not fail that receives an unexpected exception should handle the
> > situation as good as possible, even if it can't guarantee its
> > specification". This sounds contrary to programming by contract, but
> > sometimes this can help. Theoreticans might say "quit on the first
> > error encountered" while real hackers might say "continue as long as
> > you can".
> 
> Sounds good. Unfortunately, sometimes there is not an obvious way to
> continue. This is the fallacy of the "add exception handlers to make
> code safer" crowd - there has to be a reasonable response to the failure
> available to the designer. Sometimes, there isn't one. Adding exception
> handlers where there isn't a reasonable response only makes the design
> more complex - which generally means a greater risk of failure!

Again, I was not stating that the code after the first detected error
is still valid, I was just saying "you might turn on fuzzy mode if you
must go on". Fuzzy mode might be wrong (lead to wrong results).

If you have an algorithm that is performing in a limited window of
time, it would be an advantage if the equipment were still together
after the algorithm's time is over. Agreed, with rockets you just
don't have enough fuel to do a course correction later.

[...]

Ulrich

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <WIU09524.97Mar18100523@rrzc4>, Ulrich Windl <wiu09524@rrzc4>
writes 


>When I read that story I could not help, but had to shake my head
>several times. I definitely agree with Dr. Meyer that this case should
>be handled in every class about software engineering.


    Has anyone written a book of collected Software disaster stories?


    I think this would be a great seller.  Does the Pentium division
disaster count as software, methinks?




Sandy
/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Like Jean-Marc Jezequel, I think Ken Garlington may be finding things
in our article that are not there. 

[Ken Garlington quoting Jean-Marc Jezequel:]
 
> > Unless our English is so bad that it betrays our thinking, we  
> > [i.e. Jezequel and Meyer]
> > *never* implied such a thing. Just a point in a case:
> > Eiffel simply did not exist when they
> > worked on Ariane4. Let me quote the relevant section of the paper:
> >
> > << Is it the programming language's fault?
> > << Although one may criticize the Ada exception mechanism...

[Ken Garlington]

> Interestingly enough, such a statement is not made about Eiffel
> assertions,
> although one could criticize those as well (or any feature of any
> language, for that matter.

You are picking on a sentence that explicitly says it is NOT the
programming
language's fault.

It was important to note as an aside, as we did, that Ada's exception
mechanism IS subject to criticism (many people have criticized it
thoroughly, including Tony Hoare in his Turing Award lecture), but that
this was NOT the point here since Ada's exception mechanism, in spite
of its deficiencies, COULD have been used to avoid the error.
 
> Interestingly, all of the coding examples are in Eiffel, although
> apparently any language could have been used.

Only a language that has built-in support for preconditions,
postconditions
and  class invariants.

> Or could it? From later in the paper:
> 
>>>>"To attempt to reuse software without Eiffel-like assertions..."
>                                       ^^^^^^ 
> Note that these are not characterized as "design by contract-like"
> assertions, but Eiffel-like assertions. The paper goes on to make it
> clear that not just any language will do.

Because not just any language will do. Of commonly available languages,
Eiffel is the only one to have built-in support for assertions in the
spirit of Design by Contract. This is a plain fact, not subject
to disputations or to accusations of starting "language wars".
(What is subject to discussion is of course everything else:
whether it is useful to have assertions as part of the language,
whether Eiffel's assertion mechanism is properly designed etc.)

The paper as quoted above by Mr. Garlington explicitly talks about
"Eiffel-like" assertions, not about Eiffel assertions.

[Ken Garlington quoting from the Ariane paper by Jean-Marc Jezequel
and me at http://www.eiffel.com:]

>>>>"It is regrettable that this lesson has not been heeded by such recent
>>>>designs as Java (which added insult to injury by removing the modest
>>>>assert instruction of C!), IDL (the Interface Definition Language of CORBA,
>>>>which is intended to foster large-scale reuse across networks, but fails
>>>>to provide any semantic specification mechanism), Ada 95 and ActiveX."

[Ken Garlington]
 
> From this we learn that Java and Ada 95 are not properly designed for
> Design by Contract.

Which is the simple truth. The designers of these languages have
explicitly
rejected the inclusion of assertions. Why? They are the ones to ask.
I am sure they must have their reasons (however unlikely it is I would
find these to be good reasons).

> What does a language need to support Design by Contract? We are told...

>>>>"For reuse to be effective, Design by Contract is a requirement. Without
>>>>a precise specification attached to each reusable component --
>>>>precondition,
>>>>postcondition, invariant -- no one can trust a supposedly reusable
>>>>component."

> I wonder which languages have built-in precondition, postcondition, and
> invariant statements...

Eiffel, for one. People have tried adding these constructs to various
other languages too, although none of these efforts has gained
widespread
acceptance. And of course in Eiffel they are not an add-on but part of
the
language's basic design (the inheritance mechanism, in particular) and
methodology. It doesn't mean the concepts are worthless for people
using other languages. If they were, no one besides Eiffel users would
be paying attention to Design by Contract.

	(I don't mean to imply that Eiffel's assertions came out of the
	blue and that no one else has had related ideas. In a recent
	posting in a different thread I tried to give a reasonable account
	of the origin of the ideas, going back to the late sixties,
	and quoted other languages that have
	integrated neighboring constructs. The only one that is still
	active to my knowledge is Turing, although I haven't followed
	its recent developments.)

> It's bad enough that you post statements that are explicitly
> contradicted by the Ariane V final report (e.g. that the IRS could not be
> tested in a black-box environment). When you post statements that are
> contradicted by your *own* paper...

No evidence has been furnished of either of the purported
contradictions.  
 
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[William Clodius]

Bertrand Meyer wrote:
> 
> <snip>
> It was important to note as an aside, as we did, that Ada's exception
> mechanism IS subject to criticism (many people have criticized it
> thoroughly, including Tony Hoare in his Turing Award lecture), but that
> this was NOT the point here since Ada's exception mechanism, in spite
> of its deficiencies, COULD have been used to avoid the error.

I hope I am correct in my memory, but I believe Tony Hoare's criticism
of Ada's exception handling mechanism in this context is sufficiently
general in its comments to apply to any modern exception handling
mechanisms including those of Ada, C++, and Eiffel. He was largely
concerned with the difficulty of correctly implementing this construct
(and other aspects of Ada), and those aspects of Ada's mechanism that
cause implementation difficulty are shared by the mechanisms of the
other languages.

> <snip>

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

William Clodius wrote:
 
> I hope I am correct in my memory, but I believe Tony Hoare's criticism
> of Ada's exception handling mechanism in this context is sufficiently
> general in its comments to apply to any modern exception handling
> mechanisms 

You may have a point. Hoare's article, in the part
about Ada, talks about "a plethora of
features and notational conventions, many of them unnecessary
and some of them, like exception handling, even dangerous".
I understand this remark (partly on the basis of verbal comments
heard at the time) as a criticism of Ada's specific exception
handling, but it is possible to understand it
as an indictment of exception handling in general.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Martin Tom Brown]

In article <5gssgv$bei@news.ccit.arizona.edu>
           frank@bigdog.engr.arizona.edu "Frank Manning" writes:

> In article <858850191snz@nezumi.demon.co.uk> Martin@nezumi.demon.co.uk
> (Martin Tom Brown) writes:
> 
> > Whilst I am generally in agreement, it isn't usually beyond the 
> > wit of man to design in a relatively primitive hardware bias on
> > servo systems so that they fly top dead centre with no input.
> > Or fly round in small circles or whatever the design team decide 
> > is the least embarassing failure mode. At least that way the rocket
> > survives for long enough that humans can decide kill or cure.
> 
> Well, I understand what you're saying, and I agree that generally
> this is a good idea.
> 
> In this case, though, I suspect the rocket is statically unstable,
> which means the nozzles must be actively steered to keep the
> vehicle on course. If the nozzles were locked in the center
> position, for example, the vehicle would probably start flying
> sideways very quickly. Depending on the speed, it would probably be
> torn apart.

Essentially what happened to it.
I'm sure it is statically unstable like balancing a broomstick on end.

My point is that a primitive hardware based accelerometer could 
have kept the thrust on average parallel to the velocity for
quite a lot longer once the main guidance system was wrecked.
It wouldn't be injected on the right orbit, but it wouldn't
self destruct quite so easily either.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Papers on the Ariane-5 crash and Design by Contract

["Paul E. Bennett"]

In article <tz8n2s1hrdc.fsf@aimnet.com> nouser@nohost.nodomain "Thomas" writes:

> In article <332d95c9.1004852@news.demon.co.uk> john@assen.demon.co.uk (John
>  McCabe) writes:
> 
>    >I think the lesson to be learned from this is that projects should
>    >choose hardware that is sufficiently powerful to let the software
>    >engineers implement their software without making dangerous
>    >compromises and without having to spend a lot of their time on
>    >worrying about how to squeeze complex algorithms into inadequate
>    >hardware.
> 
>    That's far easier said than done. It's not necessarily cost/power/mass
>    that's the problem with computers used in the space industry, it's
>    availability of radiation tolerant or hardened processors and memory
>    and so on.  Memory is generally too much of a problem, you can easily
>    get hold of Radiation Tolerant memories from Harris and Honeywell or
>    MHS, however hardly any microprocessor manufacturers build devices
>    specifically for the space industry, and those that do generally don't
>    build very fast devices.
> 
> Thanks for pointing this out.  I realize that using more powerful
> hardware must have been a difficult choice for various reasons,
> otherwise it would have been done.  After all, the people working
> on the project were experienced professionals.
> 
>    Given a higher performance version of the same processor, the extra
>    hardware costs are unlikely to be significant, the MA31750 we've been
>    using costs aroun $13000 (Thirteen Thousand Dollars - 1.3 MIPS, 10MHz
>    - Value for money?), and 8kx8 RAMs are around $2500 a piece.

For such a slow processor at that clock speed, they could have made a better
selection of device and had at least 10 times the performance for the same 
clock speed. Other benefits are really low power, very cool running and (oh 
yes) rad-hard (more or less as standard). NASA have a load of them but maybe 
Harris might be persuaded to make some more. If you persuade them to make some 
more please send me a few more too. The device? .... The RTX2000.

> Well, what if a lot more money had been budgeted for hardware?  Could
> the space agency have paid the processor manufacturers to come out
> with a version that was 30% faster (that should have been sufficient
> to use runtime checks everywhere without changing the design)?
> Another option could have been to add more individual processors and
> use them in parallel (almost certainly harder than it sounds, but
> still a possibility).  Or what about choosing a less ambitious flight
> trajectory and maybe lower payload so that control required less
> computation?

The option you did not mention, of course, was a much better basic design 
of processor which is able to check it's own operation. There have been a 
number of experiments on this line and some of the techniques are well 
worth consideration.
 
> Of course, none of those would have been easy choices to make.  Design
> by contract and other methodologies are useful, but I still think
> without a solid foundation of runtime checks in the production code
> and multiple exception handlers and recovery blocks, no methodology
> alone is going to give sufficient protection from failure.  In fact,
> Eiffel itself, which has been mentioned here because of its assertion
> system, is built on a foundation of runtime safety.
> 
> It's good to hear from someone in the industry, by the way; thanks
> for participating.

Whatever language you use for producing the eventual machine instructions 
the best "defensive programming" techniques should always be used. Such 
defenses need rigorous "assault withstand" testing to prove they will work 
every time.

However, getting back to the original thread, it was obvious that within 
the design process certain verification steps must have been missed out 
from consideration. This left critical elements of the systems functionality
in potential (and finally actual) jeopardy. In ordinary engineering the 
phrase "measure three times - cut once" is often brought to mind when some 
critical dimension has to be acheived without wasting precious material.

In systems development we could paraphrase that as "test three times - release 
once" correctly!.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: Papers on the Ariane-5 crash and Design by Contract

[Frank Manning]

In article <858850191snz@nezumi.demon.co.uk> Martin@nezumi.demon.co.uk
(Martin Tom Brown) writes:

> Whilst I am generally in agreement, it isn't usually beyond the 
> wit of man to design in a relatively primitive hardware bias on
> servo systems so that they fly top dead centre with no input.
> Or fly round in small circles or whatever the design team decide 
> is the least embarassing failure mode. At least that way the rocket
> survives for long enough that humans can decide kill or cure.

Well, I understand what you're saying, and I agree that generally
this is a good idea.

In this case, though, I suspect the rocket is statically unstable,
which means the nozzles must be actively steered to keep the
vehicle on course. If the nozzles were locked in the center
position, for example, the vehicle would probably start flying
sideways very quickly. Depending on the speed, it would probably be
torn apart.

(Bit of Shuttle trivia -- in the Challenger accident, what destroyed
the orbiter was not an explosion, but the fact that it started
flying sideways when the dynamic pressure was rather high.)

-- Frank Manning

Re: Papers on the Ariane-5 crash and Design by Contract

[ae59]

In <tz8sp1qiywm.fsf@aimnet.com>, nouser@nohost.nodomain (Thomas) writes:
>In article <33308069.3279956@news.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes:

>Well, with a more powerful CPU, it might have been possible to use
>floating point arithmetic throught the system and implement algorithms
>that were valid over the whole physically meaningful ranges of
>parameters, not just those actually encountered by Ariane 4.

Didn't say J. v. Neumann that he would never use an aeroplane that
was constructed using floating -points calculation ?

>
>Or, to put that in the context of the paper we are discussing,
>even better than to declare and manage arbitrary restrictions
>on a reusable piece of code is to avoid them in the first place.
>
>I have implemented a number of signal processing algorithms both using
>small integer and floating point arithmetic.  The floating point
>versions were not only much easier to develop, they also were
>considerably more robust.  That is true even if both the inputs

Sounds interesting for me. Why is this the case? 
How did you handle rounding errors and states of your FPU (or software
model), which needs a proper error analysis. 
You will also need to have an exception handler, won't you.

>and outputs of the system are actually small integers (as they
>usually are when it comes to sensors and effectors).  On low-end
>hardware, the floating point versions are, of course, somewhat
>slower (on modern RISCs there is often no difference).

In the case of interval computations using floating-point I would totally
agree, but interval computations would double the number of 
floating-point operations.

I think the problem here is that _after_ a crash it is pretty simple to say
that this or that assertion would have avoided it, but how to formulate
them before s.th. has happend?

Ciao Heiner
------------- URL http://www.uni-karlsruhe.de/~ae59 ---------------------
Heinrich Berlejung                       |Institut f. Angewandte Mathematik
Tel.:+49 721 377936 / Fax:+49 721 385979 |P.O. Box 6980,D-76128 Karlsruhe   
Mail:Heiner.Berlejung@math.uni-karlsruhe.de|Universitaet Karlsruhe (TH)

Re: Papers on the Ariane-5 crash and Design by Contract

[Niall Cooling]

I'm not sure this thread is overlooking the obvious (or simple).  The
discussion on Eiffel and Design by Contract is very useful and informative.
It is useful to show that reuse shouldn't be expected to just happen. It
has to be planned and designed for (and programmed for).

Nevertheless, as I see it (for what that's worth!), the basic problem was a
simple engineering one. Anybody who is doing floating point to integer
conversion *MUST* understand the basics of number representation and
manipulation. In our book [1] we devoted a complete chapter just on this
point.

Ada did the right thing, it caught the exception (unlike languages such as
C which would have happily continued). Unfortunately in Ada83 you are not
required the handle all exceptions. This is where I like the Java model
where, if using a member function that may raise an exception, you must
either handle it or propagate it, you cannot just ignore it (I do not know
enough about Eiffel to comment).

The programmer should have planned for the exception, but based on their
assumptions this exception would not happen (and it didn't in Ariane-4 so
their assumption was correct). Nancy Levenson's book [2] covers this type
of problem is great detail. Every "software engineer" should have read this
book.

My twopence worth.

Niall Cooling

[1]  J.E. Cooling, N.S. Cooling & J. Cooling "Introduction to Ada" Chapman
& Hall 1993 ISBN 0-412-44810-6

[2] Leveson, Nancy G. "Safeware: System Safety and Computers"
Addison-Wesley 1995 ISBN 0-201-11972-2

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <33330FE5.3F54BC7E@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> > From this we learn that Java and Ada 95 are not properly designed for
> > Design by Contract.
> 
> Which is the simple truth. The designers of these languages have
> explicitly rejected the inclusion of assertions. Why? They are the
> ones to ask.  I am sure they must have their reasons (however
> unlikely it is I would find these to be good reasons).

It is simply amazing to see you sit there (or type there) and say in
one breath "Which is the simple truth" and then proceed to make an
absolutely false statement in the next.  In fact, it is extremely
disappointing and makes you look ridiculous.

Ada _has_ assertions.  Their form is not of the same syntactical look
as Eiffel's.  So what?  They take the form of constraints, in
particular (wrt to the case at hand) subtype constraints.  They are
_not_ as flexible or full "featured" as Eiffel's but they are
certainly there and in the Ariane case, they are every bit as capable
as Eiffel's.  There is no difference in this sort of case.  You are
just plain a) wrong or b) - well it doesn't take a genius to fill in
the obvious answer to this option.


> > It's bad enough that you post statements that are explicitly
> > contradicted by the Ariane V final report (e.g. that the IRS could not be
> > tested in a black-box environment). When you post statements that are
> > contradicted by your *own* paper...
> 
> No evidence has been furnished of either of the purported
> contradictions.  

Do you have any idea how ridiculous this sort of statement makes you
look???  You are not doing Eiffel any favors here...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ron Forrester]

Ken Garlington <GarlingtonKE@lmtas.lmco.com> wrote in article
<3332BF11.7D89@lmtas.lmco.com>...
> Ron Forrester wrote:
> > 
> > Maybe a simplistic first step would be an Eiffel system that required
> > ensure and require clauses for all members, as well as an invariant
> > clause for all classes.
> > 
> > This would at least *help* the engineer *think* about doing it as
> > s/he coded.
> 
> The final report states quite explicitly that the SRI team did *think*
> about this, and made a decision that was reviewed and approved at
> several
> levels. This was not the problem!

I probably should not have placed my reply in this thread, as I was not
impling that my suggestion would have remedied the Ariane disaster.

I am definately of the opinion that is was NOT the language which was
at fault, even C has an assertion mechanism which could have been used
to catch the bug -- I am obviously much happier with Eiffel's treatment
of assertions.

rjf

Re: Papers on the Ariane-5 crash and Design by Contract

[Nigel Tzeng]

In article <332d95c9.1004852@news.demon.co.uk>,
John McCabe <john@assen.demon.co.uk> wrote:
>nouser@nohost.nodomain (Thomas) wrote:
>
>>In article <332B5495.167EB0E7@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
>
><..snip..>
>
>The most commonly used device in the european space industry at the
>moment is the GPS MA31750 (probably), a MIL-STD-1750 implementation
>that runs at 10MHz and gives a performance of 1.3 MIPS. It is,
>however, available radiation hardened. 200MHz Pentium Pros are not.

No, but rad hard 386s are available (flown on SAMPEX and later SMEX
missions).  R3000s have also been flight qual'd although the floating
point performance isn't as good as the 386.  I think one flew on
Clementine.

Why folks still baseline on the 1750A is something of a mystery to
this software person.  I suppose there is a base of 1750A test suites
and simulators that 386 users wouldn't have.

>Best Regards
>John McCabe <john@assen.demon.co.uk>

Nigel

Re: Papers on the Ariane-5 crash and Design by Contract

[Fergus Henderson]

Bertrand Meyer <bertrand@eiffel.com> writes:

>[Ken Garlington]
>
>> From later in the paper:
>> 
>>>>>"To attempt to reuse software without Eiffel-like assertions..."
>>                                       ^^^^^^ 
>> Note that these are not characterized as "design by contract-like"
>> assertions, but Eiffel-like assertions. The paper goes on to make it
>> clear that not just any language will do.
>
>Because not just any language will do. Of commonly available languages,
>Eiffel is the only one to have built-in support for assertions in the
>spirit of Design by Contract.

What about Sather?  Doesn't it meet those criteria?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Fergus Henderson wrote:
 
> Bertrand Meyer <bertrand@eiffel.com> writes:
> 
!!! Eiffel is the only [commonly available language] to have built-in
support for assertions in the
!!! spirit of Design by Contract.
> 
> What about Sather?  Doesn't it meet those criteria?

You are right, I should have mentioned Sather. Sorry
and thanks for correcting me. 


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Is it ever possible  to have a technical discussion without
resorting to insults? Jon S. Anthony finds it productive to write,
about my earlier messages

> Do you have any idea how ridiculous this sort of statement makes you
> look???

further, that my comments are

> extremely disappointing and make [me] look [again!] ridiculous.

and that I am

> just plain a) wrong or b) - well it doesn't take a genius to fill in
> the obvious answer to this option.

It is this type of gratuitous attack that empoverishes Usenet and has
the potential to destroy it. When people who know what they are talking
about, and could contribute usefully to the debate, see this kind of
absurdity, they refrain from participating. Everyone loses.

I assume Mr. Anthony's hope is that by making sufficiently outrageous
statements he'll win by causing others either to lose their temper
or to shut up in disgust. For me the latter will probably happen,
but not yet. So let's see what he has to contribute.
 
In response to my matter-of-fact statement that

!!! The designers of these languages [i.e. Ada (83 or 95) and Java]
!!! have explicitly rejected the inclusion of assertions

he writes that

> Ada _has_ assertions.  Their form is not of the same syntactical look
> as Eiffel's.  So what?  They take the form of constraints, in
> particular (wrt to the case at hand) subtype constraints  
 
OK. Ada has assertions. Great news! I have read a lot about Ada but
must have missed them. So let's see what their application would be
to a typical example of Design by Contract.

Take a class PERSON in a system for genealogical or demographical
analysis.
Here are some of the logical properties to be documented and enforced:

	- A person is married if and only if he or she has a spouse.

	- The spouse of a person's spouse is that person.

	- You cannot marry someone who is already married.

	- The gender of a person's spouse is not the same as that person's
	  gender. (Note that this is consistent with the observation that
	  we need at least three values for the gender: Male, Female and
Unknown.
	  We may be talking about processing a database with incomplete
information.)

I think we can accept these rules as part of the specification and stay
away
from facile jokes and individual opinions about the underlying topics
(polygamy, same-sex marriages etc.). Just consider that this is a
genealogical database for 19-th century England.

Here is a quickly written sketch in Eiffel. I don't guarantee the
exactness
of the details since this is a 5-minute design, but the ideas should be
clear.

    class
        PERSON

    feature -- Access

        gender: ...

        status: ...

	married: BOOLEAN
		-- Is person married?

    feature -- Element change

        marry (other: PERSON) is
                -- Get married to `other' .
            require
                available: not married
                other_exists: other /= Void
                other_not_married: not other.married
                different_gender: gender /= other.gender
            do
                ...
            ensure
                married: married
                married_to_other: spouse = other
            end

    ... Other features ...

    invariant

        married_iff_has_spouse: married = (spouse /= Void)
        married_to_spouse: married implies (spouse.spouse = Current)
        married_to_other_sex: married implies (gender /= spouse.gender)

    end

	(Some comments come up immediately, e.g. the assertions preclude 
	a married couple with two "unknown" genders, suggesting that perhaps
	instead of expressions of the form `gender1 /= gender2'
	we should have a function same_gender (s1, s2).
	Or perhaps not. But this is precisely where the ideas of
	Design by Contract as implemented in Eiffel help you: they force
	you to ask the tough questions at the right time - class design -,
	not let a down-the-line implementer, writing in a low-level
	programming language devoid of those concepts, make the tough
	decisions, rightly or not, consciously or not.)

	(Also, `not married' is probably too weak; we may need a
	function `available_for_marriage' which is defined in terms of
	the status, e.g. if status can be Single, Divorced, Married
	and Dead, and we have an invariant clause stating that
	`married = (status = Married)', then `available_for_marriage'
	will mean Single or Divorced. Same comment as before: it's
	precisely by writing and refining assertions that we can get
	things right when it's still time. That's the idea in Eiffel.
	The above class sketch is only a first iteration.)

I have purposely not filled the types for `status' and `gender', and the
trivial
properties that can be expressed by using enumeration types a la
Pascal-Ada
and range constraints, for example that `status' and `gender' can only
take
certain specified values. These are easy to add.

Now if Ada has assertions, how would you express the above properties?

	(For anyone not familiar with Design by Contract: we are not
	talking about testing for abnormal cases, as in
	`if other.married then ... report error ...',
	nor even about Algol W/C/C++ `assert' instructions, as in
	`assert not other.married'. Instead, we are interested in
	associating with every software element - class or routine -
	a precise specification, or "contract", describing
	its obligations and benefits. The contract will serve as
	help in the analysis-design-implementation process (as briefly
	mentioned above), as documentation of the final software, as
	aid in debugging - by turning on run-time assertion monitoring
	in Eiffel environments -, as safeguard in using inheritance, as
	a basis for exception handling etc.)

	(The precondition of a routine, introduced by `require', states
	what must be true for the routine to be applicable; for example
	don't apply `marry' unless the   reference `other' denoting
	the intended spouse is non-void, i.e. is attached to some object.
	The postcondition of a routine, introduced by `ensure', states
	the goals to be achieved by the routine; for example one of the
	results of `marry' is to make the boolean attribute `married' true.
	The invariant of a class expresses properties that will be satisfied
	at object creation time, and maintained by all routines of the class,
	e.g. a person is married if and only if he or she has a spouse - which
	places constraints on what such routines as `marry', `divorce' etc.
	can do; these constraints come on top of the routine's own specific
	constraints expressed by its precondition and postcondition.)


 
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Is it ever possible  to have a technical discussion without
resorting to insults? Jon S. Anthony finds it productive to write,
about one of my earlier messages:

> Do you have any idea how ridiculous this sort of statement makes you
> look???

He adds for good measure that my comments are

> extremely disappointing and make [me] look [again!] ridiculous.

and that I am

> just plain a) wrong or b) - well it doesn't take a genius to fill in
> the obvious answer to this option.

It is this type of gratuitous attack that empoverishes Usenet and has
the potential to destroy it. When people who know what they are talking
about, and could contribute usefully to the debate, see this kind of
absurdity, they refrain from participating. Everyone loses.

I assume Mr. Anthony's hope is that by making sufficiently outrageous
statements he'll win by causing others either to lose their temper
or to shut up in disgust. For me the latter will probably happen,
but not yet. So let's see what he has to contribute.
 
In response to my matter-of-fact statement that

!!! The designers of these languages [i.e. Ada (83 or 95) and Java]
!!! have explicitly rejected the inclusion of assertions

he writes that

> Ada _has_ assertions.  Their form is not of the same syntactical look
> as Eiffel's.  So what?  They take the form of constraints, in
> particular (wrt to the case at hand) subtype constraints  
 
OK. Ada has assertions. Great news! I have read a lot about Ada but
must have missed them. So let's see what their application would be
to a typical example of Design by Contract.

Take a class PERSON in a system for genealogical or demographical
analysis. Here are some of the logical properties to be documented
and enforced:

        - A person is married if and only if he or she has a spouse.

        - The spouse of a person's spouse is that person.

        - You cannot marry someone who is already married.

        - The gender of a person's spouse is not the same as that
	  person's gender. (Note that this is consistent with the
	  observation that we need at least three values for the
	  gender: Male, Female and  Unknown. We may be talking
	  about processing a database with incomplete
	  information.)

I think we can accept these rules as part of the specification and stay
away from facile jokes and individual opinions about the underlying
topics (polygamy, same-sex marriages etc.). Just consider that this
is a genealogical database for 19-th century England.

Here is a quickly written sketch in Eiffel. I don't guarantee the
exactness of the details since this is a 5-minute design, but the
ideas should be clear.

    class
        PERSON

    feature -- Access

        gender: ...

        status: ...

        married: BOOLEAN
                -- Is person married?

    feature -- Element change

        marry (other: PERSON) is
                -- Get married to `other' .
            require
                available: not married
                other_exists: other /= Void
                other_not_married: not other.married
                different_gender: gender /= other.gender
            do
                ...
            ensure
                married: married
                married_to_other: spouse = other
            end

    ... Other features ...

    invariant

        married_iff_has_spouse: married = (spouse /= Void)
        married_to_spouse: married implies (spouse.spouse = Current)
        married_to_other_sex: married implies (gender /= spouse.gender)

    end

        (Some comments come up immediately, e.g. the assertions
	preclude a married couple with two "unknown" genders,
	suggesting that perhaps
        instead of expressions of the form `gender1 /= gender2'
        we should have a function same_gender (s1, s2).
        Or perhaps not. But this is precisely where the ideas of
        Design by Contract as implemented in Eiffel help you: they force
        you to ask the tough questions at the right time
	- class design -, not let a down-the-line implementer,
	writing in a lower-level programming language devoid of
	those concepts, make the tough decisions, rightly or not,
	consciously or not, and without an automatic feedback
	into the analysis and design.)

        (Also, `not married' is probably too weak; we may need a
        function `available_for_marriage' which is defined in terms of
        the status, e.g. if status can be Single, Divorced, Now_married
        and Dead, and we have an invariant clause stating that
        `married = (status = Now_married)', then
	`available_for_marriage' will mean Single or Divorced.
	Same comment as before: it's precisely by writing and
	refining assertions that we can get things right when it's
	still time. That's the idea in Eiffel. The above class sketch
	is only a first iteration.)

I have purposely not filled the types for `status' and `gender',
and the trivial properties that can be expressed by using enumeration
types a la Pascal-Ada and range constraints, for example
that `status' and `gender' can only take certain specified values.
These are easy to add.

Now if Ada has assertions, how would you express the above properties?

        (For anyone not familiar with Design by Contract: we are not
        talking about testing for abnormal cases, as in
        `if other.married then ... Report error ...',
        nor even about Algol W/C/C++ `assert' instructions, as in
        `assert not other.married'. Instead, we are interested in
        associating with every software element - class or routine -
        a precise specification, or "contract", describing
        its obligations and benefits. The contract will serve as
        help in the analysis-design-implementation process (as briefly
        mentioned above), as documentation of the final software, as
        aid in debugging - by turning on run-time assertion monitoring
        in Eiffel environments -, as safeguard in using inheritance, as
        a basis for exception handling etc.)

        (The precondition of a routine, introduced by `require', states
        what must be true for the routine to be applicable; for example
        don't apply `marry' unless the   reference `other' denoting
        the intended spouse is non-void, i.e. is attached to some
	object. The postcondition of a routine, introduced by
	`ensure', states the goals to be achieved by the routine;
	for example one of the results of `marry' is to make the
	boolean property `married' true.
        The invariant of a class expresses properties that
	will be satisfied at object creation time, and maintained
	by all routines of the class, e.g. a person is married if
	and only if he or she has a spouse - which
        places constraints on what such routines as `marry',
	`divorce' etc. can do; these constraints come on top of
	the routine's own specific constraints, as expressed by
	its precondition and postcondition.)


 
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

In a few hours my team developed much of the functionality of Eiffel's
assertions (certainly the most essential functionality) for our C++
project by using macros. With minor changes, I could apply them to the
problem suggested by Bertrand as follows. Show me how this will not work,
please!

The macros, which can offcourcse be turned on or off according to compile
switches:

ENTER: Sets up data structures to register requires by name so they can
override requires of the same name in calls to inherited method.

REQUIRE, ENSURE, INVARIANT: Registers name (check to see if overridden)
and handles false expression with exception, program break, or other
means.

EXIT: Cleans up data structures created by ENTER and calls CheckInvariants().

The class (note that CheckInvariants() may be overridden):

class Person
{
private:

   EGender gender;
   EStatus status;
   Boolean married;
   Person spouse;

protected:

   virtual void CheckInvariants()
   {
      ENTER(Person, CheckInvariants);

      INVARIANT(married_iff_has_spouse, married == (spouse != NULL));
      INVARIANT(married_to_spouse, !married || (spouse.spouse == Current));
      INVARIANT(married_to_other_sex: !married || (gender != spouse.gender));

     EXIT(Person, CheckInvariants);
   }

public:

   void Marry (Person other)
   {
      ENTER(Person, Marry);

      REQUIRE(available, !married);
      REQUIRE(other_exists, other);
      REQUIRE(other_not_married, !other.married);
      REQUIRE(different_gender, gender != other.gender);

      // the wedding...

      ENSURE(married, married);
      ENSURE(married_to_other, spouse == other);

      EXIT(Person, Marry);
   }
}

I would prefer using Eiffel, but I agree with Jon Anthony that the same
practices (use of assertion for design by contract) are available from
alternative languages. Getting this concept across to Eiffel language
fiends can be exasperating!

In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

> Is it ever possible  to have a technical discussion without
> resorting to insults? Jon S. Anthony finds it productive to write,
> about my earlier messages
> 
> > Do you have any idea how ridiculous this sort of statement makes you
> > look???
> 
> further, that my comments are
> 
> > extremely disappointing and make [me] look [again!] ridiculous.
> 
> and that I am
> 
> > just plain a) wrong or b) - well it doesn't take a genius to fill in
> > the obvious answer to this option.
> 
> It is this type of gratuitous attack that empoverishes Usenet and has
> the potential to destroy it. When people who know what they are talking
> about, and could contribute usefully to the debate, see this kind of
> absurdity, they refrain from participating. Everyone loses.

I think a real problem we have in our discussions is that the cleverest
among us are also the best at convincing themselves of there own
correctness even when they are wrong. Sometimes the best antidote to those
who hide behind seemingly inviolable intellect is to stoop low when
dressing down - it reminds us of our human-ness.

While I agree in principle that we all gain by observing standards of
mutual respect in our discussions, there are subtle forms of bullying
practiced by the most trenchant of contributors whose refinement seems to
elevate them above the level of smut and insult here criticized by
Bertrand.

A good example is the paper in question: many readers, including myself,
immediately detected an incorrect _attitude_ in the paper, even though it
is so well guarded as to utterly defensible. Mr. Anthony accurately
described how that attitude was projected. His observations are obvious to
me but difficult to defend, because they stray into the realm of humanity.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 21 Mar 1997 19:48:22 -0800 in article <33335686.FF6D5DF@eiffel.com> posted to comp.lang.eiffel, Bertrand Meyer <bertrand@eiffel.com> wrote:
> William Clodius wrote:
>  
> > I hope I am correct in my memory, but I believe Tony Hoare's criticism
> > of Ada's exception handling mechanism in this context is sufficiently
> > general in its comments to apply to any modern exception handling
> > mechanisms 

> You may have a point. Hoare's article, in the part
> about Ada, talks about "a plethora of
> features and notational conventions, many of them unnecessary
> and some of them, like exception handling, even dangerous".
> I understand this remark (partly on the basis of verbal comments
> heard at the time) as a criticism of Ada's specific exception
> handling, but it is possible to understand it
> as an indictment of exception handling in general.


Anything's better than Eiffel.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzTNzKlPvImbzLKZAQGJkAQAqQz45O/nconOMwV/H2zLp5JELjXCt7tw
RoCuEsVM8ubXnI3l9WrKwYY+dG3KR+8+nD67Vv/BVjkrAR/URo+o5l2XaJAdWaJs
e+TeIcdi7Qm+4Fj2A6Js5wRvZhT7QSXa1iL+LHA9dhEEduNlzymONOnui2/p3fIS
IyqPd0gXqss=
=Pwxo
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On Sat, 22 Mar 1997 11:56:37 -0800 in article <33343975.31DFF4F5@eiffel.com> posted to comp.lang.eiffel, Bertrand Meyer <bertrand@eiffel.com> wrote:
> Fergus Henderson wrote:
>  
> > Bertrand Meyer <bertrand@eiffel.com> writes:
> > 
> !!! Eiffel is the only [commonly available language] to have built-in
> support for assertions in the
> !!! spirit of Design by Contract.
> > 
> > What about Sather?  Doesn't it meet those criteria?

> You are right, I should have mentioned Sather. Sorry
> and thanks for correcting me. 


Bertrand Meyer has been caught lying once again.  What a sorry piece of work.

Bertrand, you have no credibility any more.  Every time you try to promote
eiffel and to put down other (i.e. superior) programming languages, you're
exposed as a bumbling liar and an idiot.  Why don't you crawl back under
a rock.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzTNiqlPvImbzLKZAQHv1AP9H1oUPJhTBKM3UDi5qn448+MM2qGbcU+T
wt839BrcLFsIVtbarGPWJTPu+sx56MUfwojQasBSVCx63+WVLhhCqlVrUmgnsg5M
iGaN4xN/ns6FsnClLlmnEdM1QyiLAT+YAOUvsQss4LqqmKlOPSDaqUjrhPdV8FNl
0Tlsia5uXvQ=
=Gy2S
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On Sat, 15 Mar 1997 18:01:57 -0800 in article <332B5495.167EB0E7@eiffel.com> posted to comp.lang.eiffel, Bertrand Meyer <bertrand@eiffel.com> wrote:
> We have made available on-line the paper that Jean-Marc Jezequel
> and I published in the January issue of IEEE Computer about the
> June 1996, software-induced $500-million crash of the Ariane 5
> mission, and the lessons it holds for software development
> --  in particular the role of contracts for reusable software.

> The paper can be found by following the "Ariane 5" link at

> 	http://www.eiffel.com

> We have used this opportunity to update the technology
> paper that summarizes the theory of Design by Contract
> (http://www.eiffel.com/doc/manuals/technology/contract/index.html).

Executive summary: anyone who uses Eiffel should and will be
summarily fired.

> -- 
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com
> 	(including instructions to download Eiffel 4 for Windows)


I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzTLw6lPvImbzLKZAQH2HAQAgwZSsgnPTGBpoadbX5T7/4zwJtPMwQhn
LqsdhLI0fAreJ8qrpSUXvePgPPeGxlgG8XoFgAnqbyPfSvOPT2jI/55q3wShfHzt
Cztq/WvQ1EKzoMFnsBOV/ONTgFvllaqp7y9Oe9xc75o4HzR6NwbgoLtspnICkoY6
Va3TJCgmBug=
=23dJ
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[John McCabe]

nigel@access5.digex.net (Nigel Tzeng) wrote:

>In article <332d95c9.1004852@news.demon.co.uk>,
>John McCabe <john@assen.demon.co.uk> wrote:
>>nouser@nohost.nodomain (Thomas) wrote:
>>
>>>In article <332B5495.167EB0E7@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
>>
>><..snip..>
>>
>>The most commonly used device in the european space industry at the
>>moment is the GPS MA31750 (probably), a MIL-STD-1750 implementation
>>that runs at 10MHz and gives a performance of 1.3 MIPS. It is,
>>however, available radiation hardened. 200MHz Pentium Pros are not.
>
>No, but rad hard 386s are available (flown on SAMPEX and later SMEX
>missions).  R3000s have also been flight qual'd although the floating
>point performance isn't as good as the 386.  I think one flew on
>Clementine.

Who supplies the Rad-Hard 386? Is it SEI? If so, although specified to
100kRads total dose I believe, (which is technically Rad-Tolerant) the
Rad-Pak doesn't really enhance the SEE (Single Event Effect)
performance.

I am aware of the R3000, Harris build it don't they? I was interested
in using this before, but we came up with too many reasons not to.
Possibly cost, power, radiation performance (again I believe it's
built on a Rad Tolerant rather than Rad-Hard process).

>Why folks still baseline on the 1750A is something of a mystery to
>this software person.  I suppose there is a base of 1750A test suites
>and simulators that 386 users wouldn't have.

Possibly, but I think from the point of view of the space industry,
they can go to GPS and buy a 300kRad total dose Silicon On Sapphire
(SOS) device and be pretty sure it's not going to fail. SOS and SOI (I
think) are really the only way you can avoid the effects of radiaition
on processor. Bulk-CMOS is good, but you're still taking a bit of a
risk.

Also, the 1750A has a built in FPU, the 386 hasn't.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Papers on the Ariane-5 crash and Design by Contract

["Paul E. Bennett"]

In article <x11xqvAJbnMzEwAT@almide.demon.co.uk>
           sandy@almide.demon.co.uk "Alexander Anderson" writes:

> In article <WIU09524.97Mar18100523@rrzc4>, Ulrich Windl <wiu09524@rrzc4>
> writes 
> 
> 
> >When I read that story I could not help, but had to shake my head
> >several times. I definitely agree with Dr. Meyer that this case should
> >be handled in every class about software engineering.
> 
> 
>     Has anyone written a book of collected Software disaster stories?

Yes. "Out of Control: Why control systems go wrong and how to prevent 
failure" published by the UK Health and Safety Executive UKP10.25 
ISBN 0-7176-0847-6. It is however not entierly software oriented but 
takes a total systems viewpoint.

Available by Mail Order from:
        HSE Books
        PO Box 1999                     Tel: +44 (0)1787-881165
        Sudbury                         Fax: +44 (0)1787-313995
        Suffolk
        CO10 6FS

Quoting from the first part of the conclusions section:

"The majority of accidents described in this publication were not caused 
by some subtle failure of the control system, but by defects that were 
preventable if a systematic approach had been adopted throughout its 
design lifecycle. Failure to pay attention to detail, particularly during 
the specification phase of a project, and to properly manage technical 
issues were the root causes of these accidents.

Two important general conclusions can be drawn:

(a) The engineering and management principles employed to ensure safety 
    throughout the life of a control system are the same whatever the 
    underlying technology used;

(b) Although it is not possible to anticipate all causes of control system 
    failure, most can be anticipated if a systematic approach is employed 
    throughout the life of the system."


A second book "Software Failure: management failure; amazing stories and 
cautionary tales" by Stephen Flowers published by John Wiley & Sons 
ISBN 0-471-96113-7 is also a worthwhile read. 
(See http://www.wiley.com/compbooks/)

>     I think this would be a great seller. ..

We'd have to ask UK-HSE and Stephen Flowers about that.
 
> ..........................................Does the Pentium division
> disaster count as software, methinks?

Only if you think of logic design as software. In my book all design is 
software until it is implemented. After implementation it is just part 
of the (homogeneous) system.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: Papers on the Ariane-5 crash and Design by Contract

[Dale Stanbrough]

Bertrand Meyer writes:

"You may have a point. Hoare's article, in the part
 about Ada, talks about "a plethora of
 features and notational conventions, many of them unnecessary
 and some of them, like exception handling, even dangerous".
 I understand this remark (partly on the basis of verbal comments
 heard at the time) as a criticism of Ada's specific exception
 handling, but it is possible to understand it
 as an indictment of exception handling in general."


Oh dear, more FUD being spread. Perhaps a more modern (1987!) quote will help
everyone here. Tony Hoare in his foreword to "Ada: Language and Methodology"
by Watt, Wichmann and Findlay wrote...

(1987)

... the language incorporates many excellent
    structural features which have proved their value ...

... unfortunate delay in ... implementation ...
    coming to an end and ...

... one can look forward to a rapid and widespread
    improvement in programming practice ...

... I hope the book will be useful ... to those
    who have the privilege ... to use the language ...


The original commments from Hoare (circa 1980) are from an early review
of the language, before it was finalised. My, but urban legends take a
long time to die. 

Furthermore the language has been updated in Ada95, making Betrand Meyer's
comments even further out of date.


Dale

Re: Papers on the Ariane-5 crash and Design by Contract

[William Clodius]

Bertrand Meyer wrote:
> 
> <snip>
> I understand this remark (partly on the basis of verbal comments
> heard at the time) as a criticism of Ada's specific exception
> handling, but it is possible to understand it
> as an indictment of exception handling in general.
><snip>

I took this remark as based on three points emphasized in the text, his
previous experiences in implementing compilers for languages which made
him distrust linguistic complexity in general, his and others experience
with PL/I, the best known previous exception handling system, and the
overall complexity of the Ada language, which caused him to distrust the
most obvious additions to its complexity.  However, Ada had removed the
most problematic aspects of PL/1 exception handling system, i.e.,
resumption semantics. Note that while his speech occurred after Ada's
definition was fixed by the DoD, it occurred before robust and efficient
implementations were available so that it was not based on direct
experience with the language, and at least some of his subsequent public
comments since that time have been favorable towards Ada.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <33330FE5.3F54BC7E@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

> [Ken Garlington]
> 
> > Note that these are not characterized as "design by contract-like"
> > assertions, but Eiffel-like assertions. The paper goes on to make it
> > clear that not just any language will do.
> 

[Bertrand Meyer]

> Because not just any language will do. Of commonly available languages,
> Eiffel is the only one to have built-in support for assertions in the
> spirit of Design by Contract. This is a plain fact, not subject
> to disputations or to accusations of starting "language wars".
> (What is subject to discussion is of course everything else:
> whether it is useful to have assertions as part of the language,
> whether Eiffel's assertion mechanism is properly designed etc.)

Is it is useful to have assertions as part of the language? Yes, ofcourse;
but that was not Ken's concern. The concern he raised regarding the
implications of the paper were: would having assertions as part of the
language have prevented the crash? The answer to that has been
convincingly demonstrated to be false.

An engineer with a strong understanding of design by contract will use
that form (method/pattern/whatever) in their language of choice, even if
they need to improvise a little. Apparently the exclusion of the critical
assertion from the Arriane-5 code was a decision based on resource
limitation, not an oversight resulting from lack of an explicit require
feature (Ada has assertion), nor from lack of knowledge of good
programming practices (i.e. design by contract).

An engineer with a weak understanding of design by contract will not use
that form effectively in any language, including Eiffel. I suppose that
inclusion of require as part of the language is a useful pedogogical tool:
users of the language may be more likely to explore the use of design by
contract then users of another language.

But again, this would not apply to the case at hand.

> [Ken Garlington]
>  
> > I wonder which languages have built-in precondition, postcondition, and
> > invariant statements...

[Bertrand Meyer]

> Eiffel, for one. People have tried adding these constructs to various
> other languages too, although none of these efforts has gained
> widespread
> acceptance. And of course in Eiffel they are not an add-on but part of
> the
> language's basic design (the inheritance mechanism, in particular) and
> methodology. It doesn't mean the concepts are worthless for people
> using other languages. If they were, no one besides Eiffel users would
> be paying attention to Design by Contract.

True, but not really relevant to Ken's point. Again, I am not criticising
Eiffel. I am objecting to the implication of the Meyers/Jezequel paper,
made explicit in Meyers' further remarks in this thread, that the use of a
language with "built-in support for assertions in the spirit of Design by
Contract" would have prevented the Arianne-5 crash.

Anders.

b-t-w, I feel badly about the "one and only true kibo" hate mail.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Steve Furlong]

Anders Pytte wrote:
> 
> In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
> <bertrand@eiffel.com> wrote:
> 
> In a few hours my team developed much of the functionality of Eiffel's
> assertions (certainly the most essential functionality) for our C++
> project by using macros. With minor changes, I could apply them to the
> problem suggested by Bertrand as follows. Show me how this will not work,
> please!
> 
> The macros, which can offcourcse be turned on or off according to compile
> switches:
> 
> ENTER: Sets up data structures to register requires by name so they can
> override requires of the same name in calls to inherited method.
> 
> REQUIRE, ENSURE, INVARIANT: Registers name (check to see if overridden)
> and handles false expression with exception, program break, or other
> means.
> 
> EXIT: Cleans up data structures created by ENTER and calls CheckInvariants().

<<snip an example>>
 
> I would prefer using Eiffel, but I agree with Jon Anthony that the same
> practices (use of assertion for design by contract) are available from
> alternative languages. Getting this concept across to Eiffel language
> fiends can be exasperating!


PLEASE make these macros available. I've failed to raise interest in 
Eiffel or Ada instead of C++, so now I'm trying to bring some of their 
better features to our C++ code.


Thanks,
Steve Furlong

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <5h2iid$8qk@stronghold.dhp.com>, the one and only real true
kibo <kibo@dhp.com> wrote:

> Bertrand Meyer has been...

Don't waste your time, kibo: like most participants here, no doubt, I'm
auto-filtering you into oblivion.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Anders Pytte wrote:
 
> I am objecting to the implication of the [Jezequel/Meyer] paper,
> made explicit in Meyer's further remarks in this thread, that the
> use of a language with "built-in support for assertions in the spirit
> of Design by Contract" would have prevented the Ariane-5 crash.

Especially since the presence of quote symbols carries an impression of
accuracy, please don't put words in our mouth that are not ours, even if
they seem at first to sound like ours. The relevant extract from our
paper at http://www.eiffel.com is

        !! Does this mean that the crash would automatically have
        !! been avoided had the mission used a language and method
        !! supporting built-in assertions and Design by Contract?
        !! Although it is always risky to draw such after-the-fact
        !! conclusions, the answer is probably yes:
        
        !! [Detailed reasoning omitted.]

which anyone can see is significantly different ("language and method",
and "probably yes", with caveats about the risk of inferences, and a
careful point-by-point discussion to examine the reasons for the
assumption).

A friend forwarded to me the following extract from an ongoing
discussion on
the mailing list for the programming language Python, which may be
relevant here:

        >>> From: Fredrik Lundh <Fredrik_Lundh@ivab.se>
        >>> Cc: python-list@cwi.nl
        >>> Subject: Re: Guido's assertion proposal
        >>> (Was: something silly...)
        >>> Date: Thursday, March 20, 1997 1:22 AM


        >>> Paul writes (on "programming by contract"):
        >>> >||| This is the view of the software from the point of
        >>> >||| view of a potential customer for its services.
        >>> >||| If I call it
        >>> >||| with the require clause satisfied, I know it will not
        >>> >||| return to me unless the promises it makes in its
        >>> >||| ensure clause are true. As libraries of
        >>> >||| components grow, the ability to see this "contract"
        >>> >||| is the key to enabling reuse
 

        >>> This is probably the most crucial part in the
        >>> "component oriented design" (or maybe "interface oriented
        >>>  design") school that I happen to
        >>> subscribe to; you cannot *reuse* things if you don't
        >>> know *exactly* what they are supposed to do.
        >>> Some fascinating reading on this can
        >>> found in the following article by Meyer/Jezequel:

        >>>
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

        >>> (read it, and if you think they say "this wouldn't
        >>> have happened if they'd used Eiffel", read it again ;-)

I think the last two lines are good advice...

[In the quotations I have reinstituted the spelling of my name,
of Jean-Marc Jezequel's, and of Ariane.]
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Frank Manning]

In article <858933630snz@nezumi.demon.co.uk> Martin@nezumi.demon.co.uk
(Martin Tom Brown) writes:

> My point is that a primitive hardware based accelerometer could 
> have kept the thrust on average parallel to the velocity for
> quite a lot longer once the main guidance system was wrecked.
> It wouldn't be injected on the right orbit, but it wouldn't
> self destruct quite so easily either.

OK -- I see your point. A 2-axis accelerometer could measure the
sideways acceleration generated by a non-zero angle of attack. You
could use that information to steer the engines and prevent the
vehicle from flying sideways w/r/t the air mass. Might work.

-- Frank Manning

Re: Papers on the Ariane-5 crash and Design by Contract

[Robb Nebbe]

Bertrand Meyer wrote:
> 
> Is it ever possible  to have a technical discussion without
> resorting to insults? Jon S. Anthony finds it productive to write,
> about one of my earlier messages:

Yes, he was insulting; however, apparently you did not read and
understand his post. (which is admittedly hard when you have been
insulted) He does have a valid point that neither you and Jean-Marc
Jezequel have not addressed. 

Your article in IEEE Computer clearly demonstrates that you do not
understand what actually happened and how it relates to the Ada
programming language. You do diagnose the problem correctly but your
suggestions for possibly avoiding the accident, in the context of a
correct understanding of what really happened, come across as very
naive. (which is probably the reason that you have Jon Anthony so upset
in the first place)

The important text from Jon Anthony's post (that you edited out) is the
following:

> Ada _has_ assertions.  Their form is not of the same syntactical look
> as Eiffel's.  So what?  They take the form of constraints, in
> particular (wrt to the case at hand) subtype constraints.  They are
> _not_ as flexible or full "featured" as Eiffel's but they are
> certainly there and in the Ariane case, they are every bit as capable
> as Eiffel's.  

Notice that Jon limits the scope (very clearly in my opinion) to say
that in the Ariane case they are as capable as Eiffel's. I.e. the
use of Eiffel in the Ariane --even with its undeniably more general
support for assertions-- would not have helped one bit.

In your article you include the following section:

> Does this mean that the crash would automatically have been avoided
> had the mission used a language and method supporting built-in
> assertions and Design by Contract? Although it is always risky to
> draw such after-the-fact conclusions, the answer is probably yes: 
>
>       Assertions (preconditions and postconditions in particular)
>       can be automatically turned on during testing, through a
>       simple compiler option. The error might have been caught then. 
>
>       Assertions can remain turned on during execution, triggering
>       an exception if violated. Given the performance constraints
>       on such a mission, however, this would probably not have been
>       the case. 
>
>       But most importantly the assertions are a prime component of
>       the software and its documentation ("short form", produced
>       automatically by tools). In an environment such as that of
>       Ariane where there is so much emphasis on quality control and
>       thorough validation of everything, they would be the QA team's
>       primary focus of attention. Any team worth its salt would have
>       checked systematically that every call satisfies the
>       precondition. That would have immediately revealed that the
>       Ariane 5 calling software did not meet the expectation of the
>       Ariane 4 routines that it called.

The problem with this section is that constraint checking (Ada's
simple support for assertions about scalar types amoung others) was
turned on during execution and this resulted in the exception. I would
assume that they were also turned on during any testing since turning
them on only during execution would be foolish. Finally the evaluation
to see if any exceptions were possible --the equivalent of making
sure every precondition is satisfied-- was done for the Ariane 4 and
based on this analysis several "assertions" were protected.

The real problem was that this analysis was not done for the Ariane 5.

This was truly beyond the scope of a programming language and comments
to the contrary are at best uninformed. Your "probably yes" is based
on an a provably incorrect understanding of the actual situation.

Other than this major blemish I found the article to be very well done.
It is definitely a resuse error. However, since Eiffel doesn't offer
any substantially better facilities than Ada _in_this_particular_
situation_ the claim that Eiffel (since they seem to have used an
appropriate method for Ariane 4) would probably have made a difference
is understandably infuriating to Jon, to whom it is obvious that you
don't know enough about Ada to recognize that your claim is bogus.
(that still doesn't excuse him being rude but it does explain it)

Robb Nebbe

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Bertrand writes

<<It is this type of gratuitous attack that empoverishes Usenet and has
the potential to destroy it. When people who know what they are talking
about, and could contribute usefully to the debate, see this kind of
absurdity, they refrain from participating. Everyone loses.>>

Well there seems to be no way to prevent a few nitwits from sounding off,
but you don't have to listen to them. Rather than refrain from 
participating, everyone should learn how to setup kill files, filters
etc to just remove people whose contributions have a net negative worth
to you. Virtually all newsreaders have this capability.

One of the useful thinks about the comp.lang groups, and comp.lang.ada
in particular, is that there are a lot of people participating who do
know what they are talking about. Yes, we all know that one of the rewards
for posting to newsgroups is to get occasional nonsense replies and even,
as in this case, absurd personal attacks, but hopefully, the situation
is managable, particularly if aided by a well chosen kiill file :-)

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Bertrand Meyer wrote

<<        !! Does this mean that the crash would automatically have
        !! been avoided had the mission used a language and method
        !! supporting built-in assertions and Design by Contract?
        !! Although it is always risky to draw such after-the-fact
        !! conclusions, the answer is probably yes:>>

Note that this conclusion is completely language independent. In particular
the use of assertions is not language dependent. No method can possibly
*rely* on having actual execution of assertions, since that just reduces
you to relying on testing, but certainly execution of assertions is a
helpful adjunct to testing, and certanly at the level that was needed in
this case, any language can certainly implement runtime assertions.

The main point is that a systematic design using Design by Contract would
indeed probably have avoided the error. However, be careful not to conclude
from this observation that Design by Contract somehow has something special
to say in the Ariane case.

As has become painfully obvious in the aftermath, the Ariane 5 incident
could have been avoided by any number of means, and almost any competent
design approach, formal or informal, should have prevented this particular
software error. Even in the absence of a systematic design approach, 
rigorous testing and/or common sense in approaching the design would have
avoided the problem.

The Ariane 5 crash was spectacular, and therefore acts as a focus for
discussion, but in fact it is not a particularly instructive example of
a BIG BUG. On the contrary it was the kind of simple minded carelessness
that plagues software, and can be reduced or eliminated without any
very specialized techniques if you have competent people working in a 
reasonably systematic manner.

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Paul Johnson wrote:
> 
> Yes, but this doesn't help.  Sure, the range limit is in the interface
> to the conversion routine, but there is no way (other than comments)
> to propogate that limit into the interfaces of its callers, and no
> methodological rule that says you should.
> The point about Eiffel is not merely that it has the syntax to express
> these limits, but that it also has the rules and "programmer culture"
> that causes these mechanisms to be used routinely.

Then why is Design by Contract needed, if Eiffel is its own methodology?

> This might well
> have caused the limit in question to documented at a high enough level
> to have been noticed by whoever it was that decided to re-use the Ariane
> 4 inertial guidance system.  Its not certain, but its a lot more likely.
> 
> The report said that the limits *were* documented (commented I think)
> in the code, but this was essentially invisible to any kind of management
> oversight.

Actually, it says the exact OPPOSITE:

"No reference to justification of this decision was found directly in
the source
code... It is important to note that the decision to protect certain
variables
but not others was taken jointly by project partners at several
contractual levels."

>  Had the limitation been propogated to a high level interface
> then its more likely that someone would have noticed.
> 
> Having said that, I must admit that this exception was caused by a high
> horizontal speed sensed by the unit, rather than external data which
> violated preconditions.  Hence the restriction would not have appeared
> at the API level for the sensor.
> 
> Paul.
> 
> --
> Paul Johnson            | GEC-Marconi Ltd is not responsible for my
> opinions. |
> +44 1245 242244
> +-----------+-----------------------------------------+
> Work: <paul.johnson@gecm.com>       | You are lost in a twisty maze of
> little
> Home: <Paul@treetop.demon.co.uk>    | standards, all different.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> Yes, that's true for pre- and post that actually correspond to range
> constraints. But remember that Eiffel pre- and post can be much more general
> than that, including any arbitrary function call.
> Also, how do you check/inherit your class invariants in Ada?
> (this is a real question, I really don't know whether it is possible)

Does any of this have anything to do with the Ariane 5 crash? Your own
paper
says that Ada assertions were adequate in this case.

> In general, this may be true. But in this particular Ariane 501 crash, I maintain
> that such "stuff" would have been  enough, for a team fully embrassing design by contract,
> to specify this particular assumption.

*Specifically* for the Ariane 501 crash, I disagree (as do others). I
even went so
far as to quote sections of the Ariane 501 final report that dispute
your
belief, rather than just relying on my own experience in building
similar systems.
Do you wish to respond?

> I know that humans can fail, but I'm confident that, given enough ressources (and
> avoiding a 500M$ crash gives you some leeway) it could have been succesful.
> You may disagree on this point, and we can stop this discussion by agreeing to disagree.

Apparently, you do not wish to respond. It would be interesting to see
this
subject addressed in a referreed paper, rather than only in Mr. Meyer's
opinion
column and on a web page. Too bad there's not a way to post permanent
responses
to a web page... given the presence of Mr. Meyer's name, I'm sure it
will be
quoted as an "authoritative" source on how assertions would have
prevented this crash.

It's times like this that I really hate software engineering. To think
that such
gibberish could ever see the light of day in a respected software
engineering magazine!

> 
> In the light of their very constructive posts and mails, I concede to Ken Garlington and
> Paul Dietz that re-testing of the SRI in the context of the Ariane5 trajectory would
> not have been as hard as I have thought initialy. But in any case, the solution they propose
> would have broken the idea of a black-box (integrating all the inertial hardware and software)
> reuse, since you have to enter the black box to "feed simulated accelerometer signals into the
> rest of the system".

This is a routine test for such systems. I have no idea what your issue
is here. I
assume your main problem is that it would have detected the error either
with or
without assertions, thus making it difficult to say that Design by
Contract (i.e.,
Eiffel) would have been a better choice.

> OK, I admit this is a bit of dialectics, but it still illustrates one of the
> main point of the paper: beware of black-box reuse (aka component reuse), when the specification
> is limited to routine signatures (a la CORBA).

I would go further: beware of black-box reuse REGARDLESS of the richness
of the
specification, particularly for critical systems.

> 
> --
> Jean-Marc Jezequel               Tel : +33 2 99847192
> IRISA/CNRS                       Fax : +33 2 99847171
> Campus de Beaulieu               e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <3335D3AC.9B8@pti-us.com.nospam>, Steve Furlong
<sr.furlong@pti-us.com.nospam> wrote:

> Anders Pytte wrote:
> > 
> > In article <333438B5.ABD322C@eiffel.com>, Bertrand Meyer
> > <bertrand@eiffel.com> wrote:
> > 
> > In a few hours my team developed much of the functionality of Eiffel's
> > assertions (certainly the most essential functionality) for our C++
> > project by using macros. With minor changes, I could apply them to the
> > problem suggested by Bertrand as follows. Show me how this will not work,
> > please!
> > 
> > The macros, which can offcourcse be turned on or off according to compile
> > switches:
> > 
> > ENTER: Sets up data structures to register requires by name so they can
> > override requires of the same name in calls to inherited method.
> > 
> > REQUIRE, ENSURE, INVARIANT: Registers name (check to see if overridden)
> > and handles false expression with exception, program break, or other
> > means.
> > 
> > EXIT: Cleans up data structures created by ENTER and calls
CheckInvariants().
> 
> <<snip an example>>
>  
> > I would prefer using Eiffel, but I agree with Jon Anthony that the same
> > practices (use of assertion for design by contract) are available from
> > alternative languages. Getting this concept across to Eiffel language
> > fiends can be exasperating!
> 
> 
> PLEASE make these macros available. I've failed to raise interest in 
> Eiffel or Ada instead of C++, so now I'm trying to bring some of their 
> better features to our C++ code.


Steve,

Our techniques are not original, so don't blame me for inventing all of
the following.

We actually used REQUIRE and ASSERT, not REQUIRE, ENSURE and INVARIANT.
REQUIRE usage was to detect fatal errors like NULL pointers or incorrect
run-time type. ASSERT usage was to detect non-fatal runtime errors. Our
reason for distinguishing is that we could optionally retire ASSERT and
switch REQUIRE from a program break to an exception or user error alert.
This distinction also added extra information for the code reader - a
trivial advantage over Eiffel.

You can define the macros like this (slightly modified from our versions):

#define ASSERT(identifier, expression)                            \
   if (!(expression))                                             \
      (AssertionFailed(__FILE__, __LINE__, false,                 \
         #identifier, #expression));                              \

#define REQUIRE(identifier, expression)                           \
   if (!(expression))                                             \
      (AssertionFailed(__FILE__, __LINE__, true,                  \
         #identifier, #expression));                              \

#define EXIT  CheckInvariants();                                  \

And the function that does the work could be like this:

void AssertionFailed(char *file, int line, Boolean fatal,
                        char *identifier, char *expression);

Missing from the above illustration are compiler switches to switch
assertions on and off (and into intermediate states). In order to reduce
code size (methods often have more assertions than behavior!) you may want
alternative definitions that will not generate any code, for example:

#define ASSERT(ignore) ((void) 0)

AssertionFailed can write to a log file, or to the debugger (using
DebugStr), and/or if fatal can throw an exception or pose a user alert.
The alert would display the file name and line number of the require along
with instructions to report the error to the developer, and allowed the
user to quit (better than crashing the system). I leave it to you to draft
your own version.

I think the idea of using separate macros ENSURE and INVARIANT is a good
idea - the debug message could express what kind of check is being
enforced along with the identifier and expression text. Modify the
assertion procedure to accept and express the type of assertion:

enum EAssertionType {eRequire, eEnsure, eInvariant, eCheck};

#define REQUIRE(identifier, expression)                           \
   if (!(expression))                                             \
      (AssertionFailed(__FILE__, __LINE__, eRequire,              \
         #identifier, #expression));                              \

#define ENSURE(identifier, expression)                            \
   if (!(expression))                                             \
      (AssertionFailed(__FILE__, __LINE__, eEnsure,               \
         #identifier, #expression));                              \

void AssertionFailed(char *file, int line,
                        EAssertionType assertionType,
                           char *identifier, char *expression);

You may not find it necessary to override assertions (other than adding
additional ones in subclass methods), but if you really want to follow
through on that part of my suggestion, you need to

1) on startup of each process (normally just the application) create a
stack of global scope to the process
2) save a local "frame pointer" in ENTER (the macro would declare an index
and assign it the size of the stack)
3) check each assertion to see if the identifier is already in the stack
and, if so, ignore the local assertion
4) otherwise push the identifier name for the assertion onto the stack and
invoke the assertion
5) clear the stack down to the local frame pointer in EXIT (the macro
would set the size of the stack to the saved index).

For example:

#define ENTER                                                     \
   long assertionStackSize = globalAssertionStack->GetSize();     \

#define EXIT                                                      \
   CheckInvariants();                                             \
   globalAssertionStack->SetSize(assertionStackSize);             \

#define REQUIRE(identifier, expression)                           \
   if (!globalAssertionStack->Contains(identifier)                \
   {                                                              \
      globalAssertionStack->Push(identifier);                     \
      if (!(expression))                                          \
         (AssertionFailed(__FILE__, __LINE__, whatever,           \
            #identifier, #expression));                           \
  }                                                               \
 
You can either put the identifier's text on the stack, or else enumerate
all your assertion identifiers and place the enumerator on the stack (in
which case the AssertionFailed parameter lists I suggested would need to
be modified).

In general, the process of writing code using these assertions is try to
state every assumption being made when you write methods and classes, in
such a way that the reader can immediately see what assumptions you are
making, and thereby get a good idea of how you expect the method or class
to be used, and ofcourse also enforce these assumptions when the
assertions are turned on. That is "design by contract" in fifty words,
more or less.

NOTA BENE: in my example there is a danger of missing the ENSURE and
INVARIANT if the method has multiple returns. I can think of several
rather messy ways to solve this. Or you could just avoid multiple exits
when necessary, which may be a better programming style anyway. 

Please feel free to contact me at my email address if you have any more
questions.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Ulrich Windl wrote:
> 
> Again, I was not stating that the code after the first detected error
> is still valid, I was just saying "you might turn on fuzzy mode if you
> must go on". Fuzzy mode might be wrong (lead to wrong results).

The problem with this approach is:

1. There might not be a fuzzy mode. Feedback systems are notoriously
difficult to control with invalid inputs.

2. Any fuzzy modes have to be specified, designed, implemented,
processed
by the compilation system, and tested. This all takes resources, and
makes
it possible to introduce an error. A more complicated system is not
necessarily a safer one! As a design guideline, simpler is better
(although
there are many exceptions to that rule).

> 
> If you have an algorithm that is performing in a limited window of
> time, it would be an advantage if the equipment were still together
> after the algorithm's time is over. Agreed, with rockets you just
> don't have enough fuel to do a course correction later.
> 
> [...]
> 
> Ulrich

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jon S Anthony wrote:
> 
> In article <33330FE5.3F54BC7E@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
> 
> > > From this we learn that Java and Ada 95 are not properly designed for
> > > Design by Contract.
> >
> > Which is the simple truth. The designers of these languages have
> > explicitly rejected the inclusion of assertions. Why? They are the
> > ones to ask.  I am sure they must have their reasons (however
> > unlikely it is I would find these to be good reasons).
> 
> It is simply amazing to see you sit there (or type there) and say in
> one breath "Which is the simple truth" and then proceed to make an
> absolutely false statement in the next.  In fact, it is extremely
> disappointing and makes you look ridiculous.

That's not fail. Mr. Meyer does, in the same post, define what he means
by assertions, which is a superset of Ada's. Certainly, it contradicts
any notion that the Design by Contract method is appropriate in any
language - in fact, Mr. Meyer has explicitly stated that Eiffel is the
only widespread language that supports Design by Contract.

My problem with the paper is, again, two-fold:

1. The claim that Eiffel assertions would have prevented the Ariane V is
   clearly unsupported by the final report.

2. Claims that Design by Contract is not language-specific (i.e. Eiffel)
   are also clearly false, and attempts to sell it as such are silly.

> 
> Ada _has_ assertions.  Their form is not of the same syntactical look
> as Eiffel's.  So what?  They take the form of constraints, in
> particular (wrt to the case at hand) subtype constraints.  They are
> _not_ as flexible or full "featured" as Eiffel's but they are
> certainly there and in the Ariane case, they are every bit as capable
> as Eiffel's.  There is no difference in this sort of case.  You are
> just plain a) wrong or b) - well it doesn't take a genius to fill in
> the obvious answer to this option.
> 
> > > It's bad enough that you post statements that are explicitly
> > > contradicted by the Ariane V final report (e.g. that the IRS could not be
> > > tested in a black-box environment). When you post statements that are
> > > contradicted by your *own* paper...
> >
> > No evidence has been furnished of either of the purported
> > contradictions.
> 
> Do you have any idea how ridiculous this sort of statement makes you
> look???  You are not doing Eiffel any favors here...
> 
> /Jon
> 
> --
> Jon Anthony
> Organon Motives, Inc.
> Belmont, MA 02178
> 617.484.3383
> jsa@organon.com

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Alexander Anderson wrote:
> 
> In article <WIU09524.97Mar18100523@rrzc4>, Ulrich Windl <wiu09524@rrzc4>
> writes
> 
> >When I read that story I could not help, but had to shake my head
> >several times. I definitely agree with Dr. Meyer that this case should
> >be handled in every class about software engineering.
> 
>     Has anyone written a book of collected Software disaster stories?

There are more than one. I highly recommend "Safeware" by Nancy Levison.
Although I think she relies on hardware interlocks and "fail-safe" modes
a little too much for my taste, it is overall a great book. See

http://www.cs.washington.edu/research/projects/safety/www/book.html

> 
>     I think this would be a great seller.  Does the Pentium division
> disaster count as software, methinks?
> 
> Sandy
> /*
> --
> //    Alexander Anderson  <sandy@almide.demon.co.uk>
> //    Home Fone                 +44 (0) 171-794-4543
> //    London, UK      http://www.almide.demon.co.uk/
> */

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

John McCabe wrote:
> 
> jezequel@irisa.fr (Jean-Marc Jezequel) wrote:
> 
> >In article <33307a43.1705970@news.demon.co.uk>, john@assen.demon.co.uk (John McCabe) writes:
> >>I am a bit unhappy with the way the paper has been written. As I
> >>mentioned in another posting on this thread, the fundamental problem
> >>was that the developers did not have Ariane 5 trajectory data to work
> >
> >Yes this is true. But, since the SRI was reused from Ariane4, the problem
> >is not with developers, but with the *integration* team.
> 
> I think there was a bit more to it than just getting one off the
> shelf. I quote from the inquiry report:
> 
> "The design of the Ariane 5 SRI is practically the same as that of an
> SRI which is presently used on Ariane 4, particularly as regards the
> software."
> 
> Note Practically the same - not identical.
> 
> >AFAIK, the integration team had the possibility to work with Ariane 5 trajectory data,
> >and in the ideal case where Design by Contract would have been used on the SRI,
> >they would have the opportunity the check it wrt the environment of Ariane5.
> 
> Again, I quote:
> 
> "There is no evidence that any trajectory data were used to analyse
> the behaviour of the unprotected variables, and it is even more
> important to note that it was jointly agreed not to include the Ariane
> 5 trajectory data in the SRI requirements and specification."

What I think he's saying is that if the integration team had done a
proper test, and
had used Eiffel, then the problem would have been detected. Left
unstated is the
observation from the final report that if a proper test had been done,
the problem would
have been detected even *without* the added assertions. Of course, this
statement
would make it more difficult to imply to the uninformed that "Ariane V
would not
have happened if it was programmed in Eiffel"...

> 
> Best Regards
> John McCabe <john@assen.demon.co.uk>

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Richard Kaiser wrote:
> 
> In article <33308C91.40CC@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com>
>                 <332D113B.4A64@calfp.co.uk> <EACHUS.97Mar17120250@spectre.mitre.org>
>                 <332DA14C.41C67EA6@eiffel.com> <WIU09524.97Mar18100523@rrzc4> wrote:
> >Ulrich Windl wrote:
> >>
> >> The modules computing course corrrection data both failed due to to
> >> problems mentioned (violating the specs for that code); they shut
> >> themselves down. But to me the main issue is that the module that
> >> received the course correction data did not detect that both computing
> >> modules failed and that the data was just a "test pattern" to indicate
> >> that event. Probably a better reaction would have been to stop making
> >> further corrections instead of driving the engine to its borders.
> >
> >This is the same as saying: "If the driver of an automobile has a heart
> >attack and dies, the steering system should ignore further inputs and
> >lock the wheels in the last 'good' position." It doesn't work with
> >automobiles,
> >and it doesn't work with missiles, either. The flight control system
> >must
> >receive valid sensor data to maintain control of the aircraft. There is
> >generally no reasonable 'fail-safe" value for a feedback system like
> >this!
> 
> Data validity bits have been included in data messages for years.  I used them
> in aircraft interfaces where one or more boxes could fail and the system still
> had to function.  The error message dumped by the navigation subsystem
> should not have been interpretable as data.  Now this may not have helped
> to guide the vehicle in this situation.

I absolutely agree with both statements:

1. The flight controls should have received some indication that both
IRSs
failed, and

2. It probably wouldn't have helped in this situation.

> 
> Richard Kaiser

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Like Jean-Marc Jezequel, I think Ken Garlington may be finding things
> in our article that are not there.
> 
> [Ken Garlington quoting Jean-Marc Jezequel:]
> 
> > > Unless our English is so bad that it betrays our thinking, we
> > > [i.e. Jezequel and Meyer]
> > > *never* implied such a thing. Just a point in a case:
> > > Eiffel simply did not exist when they
> > > worked on Ariane4. Let me quote the relevant section of the paper:
> > >
> > > << Is it the programming language's fault?
> > > << Although one may criticize the Ada exception mechanism...
> 
> [Ken Garlington]
> 
> > Interestingly enough, such a statement is not made about Eiffel
> > assertions,
> > although one could criticize those as well (or any feature of any
> > language, for that matter.
> 
> You are picking on a sentence that explicitly says it is NOT the
> programming
> language's fault.
> 
> It was important to note as an aside, as we did, that Ada's exception
> mechanism IS subject to criticism (many people have criticized it
> thoroughly, including Tony Hoare in his Turing Award lecture), 

Anyone want to beat that chestnut to death, or is it worth the effort?

> but that
> this was NOT the point here since Ada's exception mechanism, in spite
> of its deficiencies, COULD have been used to avoid the error.
> 
> > Interestingly, all of the coding examples are in Eiffel, although
> > apparently any language could have been used.
> 
> Only a language that has built-in support for preconditions,
> postconditions
> and  class invariants.

I am totally confused now. The Ariane V incident could only have been
prevented by a language that has Eiffel-like constructs, but it wasn't
the language's fault?


> 
> > Or could it? From later in the paper:
> >
> >>>>"To attempt to reuse software without Eiffel-like assertions..."
> >                                       ^^^^^^
> > Note that these are not characterized as "design by contract-like"
> > assertions, but Eiffel-like assertions. The paper goes on to make it
> > clear that not just any language will do.
> 
> Because not just any language will do. Of commonly available languages,
> Eiffel is the only one to have built-in support for assertions in the
> spirit of Design by Contract. This is a plain fact, not subject
> to disputations or to accusations of starting "language wars".

So, the paper does make a statement about the preferred language? Then
why does the co-author state (as you did earlier, in fact) that the
language did not matter?

This must be a language barrier, because I hear you contradicting
yourself
in the same post.

It should be noted that the term "language wars" was brought up
by your co-author. My criticisms have been solely in two areas:

1. Eiffel assertions would not have saved the Ariane 5, all other
   things being the same.

2. Although the co-authors claim that their web page is about a
   design technique that can be implemented in any language, they
   contradict themselves both in the paper itself and in subsequent
   posts.

> (What is subject to discussion is of course everything else:
> whether it is useful to have assertions as part of the language,
> whether Eiffel's assertion mechanism is properly designed etc.)

I posted a detailed critique, using quotes from the report, addressing
whether "it is useful to have assertions as part of the language",
specifically in the case of the Ariane 5 incident. There has been no
response.

> 
> The paper as quoted above by Mr. Garlington explicitly talks about
> "Eiffel-like" assertions, not about Eiffel assertions.

> 
> [Ken Garlington quoting from the Ariane paper by Jean-Marc Jezequel
> and me at http://www.eiffel.com:]
> 
> >>>>"It is regrettable that this lesson has not been heeded by such recent
> >>>>designs as Java (which added insult to injury by removing the modest
> >>>>assert instruction of C!), IDL (the Interface Definition Language of CORBA,
> >>>>which is intended to foster large-scale reuse across networks, but fails
> >>>>to provide any semantic specification mechanism), Ada 95 and ActiveX."
> 
> [Ken Garlington]
> 
> > From this we learn that Java and Ada 95 are not properly designed for
> > Design by Contract.
> 
> Which is the simple truth. The designers of these languages have
> explicitly
> rejected the inclusion of assertions. Why? They are the ones to ask.
> I am sure they must have their reasons (however unlikely it is I would
> find these to be good reasons).

Again, you hammer home the point that there is only one language which
is appropriate for solving the Ariane 5 problem, contradicting your
earlier statement.

I will freely admit that Eiffel is required for Design by Contract. Why
do you hestiate to do the same? In fact, would it not be more accurate
to simply state your position as: "If the Ariane V had been programmed
in Eiffel, with proper use of Eiffel assertions, then the incident would
not have happened?"

Why be so oblique in your paper? Simply make this assertion, give the
address where to order copies of Eiffel, print it on color glossy paper,
and send it to all the major aerospace companies? It seems
intellectually
dishonest to say "this is not a language issue."

> 
> > What does a language need to support Design by Contract? We are told...
> 
> >>>>"For reuse to be effective, Design by Contract is a requirement. Without
> >>>>a precise specification attached to each reusable component --
> >>>>precondition,
> >>>>postcondition, invariant -- no one can trust a supposedly reusable
> >>>>component."
> 
> > I wonder which languages have built-in precondition, postcondition, and
> > invariant statements...
> 
> Eiffel, for one. People have tried adding these constructs to various
> other languages too, although none of these efforts has gained
> widespread
> acceptance.

So, the only language with widespread acceptance that properly supports
Design by Contract is Eiffel. Again, you prove my point. I'm glad we
can agree on this.

> And of course in Eiffel they are not an add-on but part of
> the
> language's basic design (the inheritance mechanism, in particular) and
> methodology. It doesn't mean the concepts are worthless for people
> using other languages. If they were, no one besides Eiffel users would
> be paying attention to Design by Contract.

Why should non-Eiffel users pay attention to Design by Contract, if
other
languages do not properly support it? Is it your intent that software
engineers use inferior tools?

> 
>         (I don't mean to imply that Eiffel's assertions came out of the
>         blue and that no one else has had related ideas. In a recent
>         posting in a different thread I tried to give a reasonable account
>         of the origin of the ideas, going back to the late sixties,
>         and quoted other languages that have
>         integrated neighboring constructs. The only one that is still
>         active to my knowledge is Turing, although I haven't followed
>         its recent developments.)
> 
> > It's bad enough that you post statements that are explicitly
> > contradicted by the Ariane V final report (e.g. that the IRS could not be
> > tested in a black-box environment). When you post statements that are
> > contradicted by your *own* paper...
> 
> No evidence has been furnished of either of the purported
> contradictions.

Your co-author has at least partially conceded the testing point in
another
post. There are many other objections I could make to the paper, but
since
neither you nor your co-author have responded to the list of barriers to
assertions I posted previously (and in a mail message to you when the
IEEE
column was originally published), I assume they will not be addressed.



> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com
>         (including instructions to download Eiffel 4 for Windows)

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <33343EE3.7DE14518@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Is it ever possible  to have a technical discussion without
> resorting to insults? Jon S. Anthony finds it productive to write,
> about one of my earlier messages:

Yes, it is possible, and I admit that you indeed did successfully goad
me into making these comments.  The frustrating part is that you just
simply deny some facts - over and over.  I'm not sure why you want to
deny them - it's not as if they make that much of a difference to your
overall case.  That is what goaded me into these statements.

Also, I have no problem whatsoever with your being biased toward
Eiffel here.  Both for technical reasons as well as business reasons.
I just don't understand why you should bother trying to deny it or
pretend that the paper in question is not rather blatently biased
against any other implementation language.  What's the point?  It's
not as if anyone actually believes these denials and they don't make
any difference to your position anyway (unless you are trying to
assume some air of objectivity in the matter??)


> It is this type of gratuitous attack that empoverishes Usenet and has
> the potential to destroy it. When people who know what they are talking
> about, and could contribute usefully to the debate, see this kind of
> absurdity, they refrain from participating. Everyone loses.

Indeed you are correct and I apologize here and now for doing the very
sort of thing that I have decried myself.  Ugh!  I am dooly (sp?)
embarassed.


> I assume Mr. Anthony's hope is that by making sufficiently outrageous
> statements he'll win by causing others either to lose their temper

No, on the contrary - it was you who successfully made me lose my temper...


> > Ada _has_ assertions.  Their form is not of the same syntactical look
> > as Eiffel's.  So what?  They take the form of constraints, in
> > particular (wrt to the case at hand) subtype constraints  
>  
> OK. Ada has assertions. Great news! I have read a lot about Ada but
> must have missed them. So let's see what their application would be
> to a typical example of Design by Contract.

Why not take the case in hand?  The Ariane one?  Perhaps because that
case is easily handled by Ada constraints?  Oh, by the way, you left
out the part where I clearly concede they are not as capable or
general as Eiffel's:

  "They are _not_ as flexible or full "featured" as Eiffel's but they
   are certainly there and in the Ariane case"

Any particular reason why you would want to do that?


> Take a class PERSON in a system for genealogical or demographical
> analysis. Here are some of the logical properties to be documented
> and enforced:

Hmmm, Clearly you are being nicely sarcastic here, but I never said
that Ada's "assertions" were as flexible and as widely capable as
Eiffel's.  So, this is a strawman and simply irrelevant.


> Now if Ada has assertions, how would you express the above properties?

Come on, who ever claimed that Ada's constraints are anywhere near as
capable as Eiffel assertions??  Quote anything anywhere of mine where
I even hinted at such a ridiculous claim.  In fact, I have often
stated (even in the message that started this) that they are much more
capable and that I think Ada95 goofed in not putting in some better
support for them.

BUT.  "Not as capable" does not mean does not exist.  A simple matter
that I am sure you would agree with.  In fact, "not as capable"
clearly implies they exist - lest there would not be anything to not
be as capable.  So, this entire example, is nice and quite good, but
has nothing to do with the topic or the point.  Ada does have
assertions and in the particular case at hand, the Eiffel you gave in
your paper has an _exact_ analogue in Ada.  I've stated it a couple
three times.  No point in repeating it again.


>         `assert not other.married'. Instead, we are interested in
>         associating with every software element - class or routine -
>         a precise specification, or "contract", describing
>         its obligations and benefits. The contract will serve as
>         help in the analysis-design-implementation process (as briefly
>         mentioned above), as documentation of the final software, as
>         aid in debugging - by turning on run-time assertion monitoring
>         in Eiffel environments -, as safeguard in using inheritance, as
>         a basis for exception handling etc.)

All of this is great and wonderful and I wish you had put the case
more like this in both your paper and in your subsequent comments on
news.  Perhaps the mistake was in using trying to use an inappropriate
example (Ariane failure) as somehow being a case where Eiffel
assertions would have saved they day when the evidence clearly
suggests they wouldn't have.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Anders Pytte wrote:
> 
> True, but not really relevant to Ken's point. Again, I am not criticising
> Eiffel. I am objecting to the implication of the Meyers/Jezequel paper,
> made explicit in Meyers' further remarks in this thread, that the use of a
> language with "built-in support for assertions in the spirit of Design by
> Contract" would have prevented the Arianne-5 crash.

Yes and no. One of my points is language-independent, as you state, and
is
never addressed by either of the paper's authors (although one did
conditionally
accept part of my argument). The other point, however, is that it is not
practical to separate Design by Contract as a language-independent
methodology from the specifics
of the Eiffel implementation, as it is presented in the paper. Thus,
assertions
that Design by Contract is meaningful in other languages cannot be
supported.
Mr. Meyer (without meaning to do so, I'm sure) emphasizes this point in
his
response. It may be possible to describe Design by Contract in such a
way that it
is not tied specifically to Eiffel, but then I suspect the case for it
solving the
Ariane 5 disaster is further weakened.

> 
> Anders.
> 
> b-t-w, I feel badly about the "one and only true kibo" hate mail.
> 
> --
> Anders Pytte            Milkweed Software
> RR 1, Box 227           Voice: (802) 472-5142
> Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

> My point was that assertions and design by contract are good, but are not
> enforced by Eiffel any more than any other modern programming language.
> The presence of "built-in" assertions does not mean they will be used; a
> person who would use assertions fastidiously in Eiffel is probably already
> using them in C++ or Ada.

Sorry that I have to disagree.
I bought all of programming-by-contract. I'd very much like to use it in my 
projects (unfortunately, the projects at work aren't in Eiffel). But all I 
can do is add comments in programming-by-contract style. 
I can't switch precondition checking on for a single class, I have to switch 
it on for everything that's written by myself; however, this would incur 
such a run-time penalty that I usually don't do it. 
Worse, I can't switch on precondition checking for the classes that were 
delivered as part of the compiler, so whenever the program crashes, I keep 
wondering wether the error is in my code or in the libraries. And of course 
some crashes don't even tell me which routine failed, and in what way - I 
recently had to single-step through every line of initialization code in my 
system to find the broken precondition.

Programming-by-contract is much like parameter type checking. You can do 
without it if you work very carefully. But in practice, all sorts of stupid 
mistakes occur, and they occur in the libraries, too.

Just my 5c.

Regards,

Re: Papers on the Ariane-5 crash and Design by Contract

[Marin David Condic, 561.796.8997, M/S 731-93]

Bertrand Meyer <bertrand@EIFFEL.COM> writes:
>        !! Does this mean that the crash would automatically have
>        !! been avoided had the mission used a language and method
>        !! supporting built-in assertions and Design by Contract?
>        !! Although it is always risky to draw such after-the-fact
>        !! conclusions, the answer is probably yes:
>
>        !! [Detailed reasoning omitted.]
>
    O.K. Here's my question: When the project team comes up with the
    answer that assertions and/or Design by Contract (whatever your
    favorite Eiffel-ism is) costs too much CPU time and hence needs to
    be turned off lest the software doesn't run at all, is there a way
    to do it?

    If there is no way to disable the features mentioned, is there a
    way to get straight into assembler from Eiffel so that the code
    can be written without the assertions and/or Design by Contract?

    If there is no way to disable the features and there's no way to
    get to assembler, is there some way I can pay the compiler writer
    to give me a custom switch to disable the features or get to
    assembler and thus avoid the checks?

    If the answer to the above questions is "No", "No", and "No" then
    you have just explained why Eiffel could never be used to develop
    the Ariane software. The design team *knew* that the runtime
    checks for valid data ranges were too costly in the particular
    application and hence needed to be disabled. They deliberately
    chose to ignore all of the possible features of Ada (or any other
    language for that matter) that could perform range checks and
    insure the data could never be wrong. This sort of thing is done
    *all the time* in the realtime world and insisting that one should
    *never* turn off runtime checks is displaying a lack of
    understanding about hard, realtime applications.

    Hence, I would conclude that Eiffel *could not* have saved the
    Ariane, because it was a deliberate, conscious, decision on the
    part of the design team to exclude runtime checking. No language
    could have saved them. On Ariane 4, the decision was one valid way
    to build the software. On Ariane 5, they messed up by assuming
    there was no difference from Ariane 4, and thus they could reuse
    the software.

    When folks sit around and discuss language theory and software
    design strategies or methodologies, they often come up with really
    good ideas. But in real applications, you very often have to back
    off of what is "theoretically pure" because of real world
    constraints. And that sort of "backing off" would happen no matter
    *what* language gets used.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
        In Vegas, I got into a long argument with the man at the
        roulette wheel over what I considered to be an odd number.

            --  Steven Wright
===============================================================================

Re: Papers on the Ariane-5 crash and Design by Contract

[John Hogg]

Bertrand Meyer wrote:
> 
> > What does a language need to support Design by Contract? We are told...
> 
> >>>>"For reuse to be effective, Design by Contract is a requirement. Without
> >>>>a precise specification attached to each reusable component --
> >>>>precondition,
> >>>>postcondition, invariant -- no one can trust a supposedly reusable
> >>>>component."
> 
> > I wonder which languages have built-in precondition, postcondition, and
> > invariant statements...
> 
> Eiffel, for one. People have tried adding these constructs to various
> other languages too, although none of these efforts has gained widespread
> acceptance. And of course in Eiffel they are not an add-on but part of the
> language's basic design (the inheritance mechanism, in particular) and
> methodology. It doesn't mean the concepts are worthless for people
> using other languages. If they were, no one besides Eiffel users would
> be paying attention to Design by Contract.
> 
>         (I don't mean to imply that Eiffel's assertions came out of the
>         blue and that no one else has had related ideas. In a recent
>         posting in a different thread I tried to give a reasonable account
>         of the origin of the ideas, going back to the late sixties,
>         and quoted other languages that have
>         integrated neighboring constructs. The only one that is still
>         active to my knowledge is Turing, although I haven't followed
>         its recent developments.)

Unfortunately, Eiffel's assertions are not sufficient to guarantee
black-box behaviour.  In fact, no existing practical object-oriented
language can support reliable precondition/postcondition pairs, and
Eiffel is no exception.

The reason is object aliasing.  If an object can be reached through
two paths from an execution context, then an assertion on one path
can be invalidated by an unseen operation on another path.  One
solution to this is aliasing control, which doesn't exist in any
mainstream language today (although it isn't hard to retrofit).

Interestingly enough, Turing avoids this problem.  Procedral aliasing
is quite different from object aliasing, and Turing programs can be
provably correct (within the accepted formal definition of the term).
However, aliasing issues becomes glaringly obvious when Turing is
extended to Object Turing.

Eiffel is a great leap forward as an attempt to bring provably
correct programming to the masses.  It's better for this than the
alternatives. (At least the OO ones.)  However, don't make the
mistake of believing that its contracts are unbreakable.  You
can have a full set of them and still blow up your rocket.

-- 
John Hogg			    | ObjecTime Limited
Manager, Toolset Applications	    | 340 March Road
mailto:hogg@objectime.com	    | Kanata, Ontario, CANADA K2K 2E4
Voice: +1.613.591.7053		    | +1.800.567.TIME (+1.800.567.8463)
Fax:   +1.613.591.3784		    | http://www.objectime.com/

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <VA.00000018.00578c19@herold>,
joachim.durchholz@munich.netsurf.de wrote:

> > My point was that assertions and design by contract are good, but are not
> > enforced by Eiffel any more than any other modern programming language.
> > The presence of "built-in" assertions does not mean they will be used; a
> > person who would use assertions fastidiously in Eiffel is probably already
> > using them in C++ or Ada.
> 
> Sorry that I have to disagree.
> I bought all of programming-by-contract. I'd very much like to use it in my 
> projects (unfortunately, the projects at work aren't in Eiffel). But all I 
> can do is add comments in programming-by-contract style. 
> I can't switch precondition checking on for a single class, I have to switch 
> it on for everything that's written by myself; however, this would incur 
> such a run-time penalty that I usually don't do it. 
> Worse, I can't switch on precondition checking for the classes that were 
> delivered as part of the compiler, so whenever the program crashes, I keep 
> wondering wether the error is in my code or in the libraries. And of course 
> some crashes don't even tell me which routine failed, and in what way - I 
> recently had to single-step through every line of initialization code in my 
> system to find the broken precondition.
> 
> Programming-by-contract is much like parameter type checking. You can do 
> without it if you work very carefully. But in practice, all sorts of stupid 
> mistakes occur, and they occur in the libraries, too.
> 


I guess i made a dangerous generalization there. I've been instinctively
appliying programming-by-contract tecniques for the 15 years i've been
programming professionally - imperfectly, ofcourse. I've gathered and
developed tools and techniques slowly along the way, and am still
learning.

Ocourse, it is much easier to prove that a thing is possible than to prove
that it is impossible, since in the former case one needs only a single
example.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

Comments as source code documentation help, but they don't eliminate the 
problem. I have seen code where comments and code were badly out of sync (I 
have to woefully admit that I'm the author of some of it). The reason for such 
inconsistencies is usually pressure to meet a deadline.

We all (well, most of us) program on systems where only a tiny fraction of the 
code is available. For example, I have to live with Windows in its various 
incarnations, and I don't have the sources of that. Documentation in the 
source would be a desaster, except if it were derived from the source 
automatically. 
In Eiffel, there are clear places where the programmer should write such 
comments - preconditions, postconditions, invariants. Languages without 
explicit support for programming-by-contract don't have such good places, so 
there are no universally recognized tools for extracting docs from the source.

Regards,

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On Sun, 23 Mar 1997 16:06:09 -0500 in article <milkweed-2303971606090001@port4.chester.smallmedia.com> posted to comp.lang.eiffel, Anders Pytte <milkweed@plainfield.bypass.com> wrote:

> b-t-w, I feel badly about the "one and only true kibo" hate mail.


And fuck you too, asshole.

it takes a fucking mron to use Eiffel.

> -- 
> Anders Pytte            Milkweed Software
> RR 1, Box 227           Voice: (802) 472-5142
> Cabot VT 05647          Internet: milkweed@plainfield.bypass.com


I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzXojalPvImbzLKZAQGifwQAq8m4BVMptgv1n4m0nTjE0hNDl195BNWc
lzTYi55MKwbdFwhSDNaJ3zCYvfqH0VDv9WXl69ooJONBbrc8xPVUTxklXldwBuLn
ZzVYqWJ3jE8kAXwQ9iBxlLD+LB+ohPhPyrlS5Cb7E/KH2t0Up31Yy/AzngIKVqxS
k5Mtjv3FvB4=
=/iVZ
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <859123410snz@transcontech.co.uk>, "Paul E. Bennett"
<peb@transcontech.co.uk> writes

>It is however not entierly software oriented but 
>takes a total systems viewpoint.


    Oh, la la!  Mais c'est pas vrai?!!


    Bit ahead of it's time, isn't it?




Sandy

/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Roberts]

Marin David Condic, 561.796.8997, M/S 731-93 <condicma@PWFL.COM> wrote in
article <97032020033927@psavax.pwfl.com>...
>     As for overflow situations - you're right that the use of floating
>     point usually means more than enough resolution so you never see
>     it overflow. It might have saved the Ariane. What might also have
>     saved them would be if the arithmetic on the machine had saturated
>     instead of causing an interrupt. (Disable the interrupt & let the
>     hardware saturate or enable the interrupt & put your own
>     saturation software in there.) Floating point usually saturates
>     the way you want it to from hardware, but fixed usually doesn't.
> 

I would be very grateful if you (or someone) would explain the term
'saturation' in this context. I'm not accusing you of incorrect usage of a
technical term, merely myself of ignorance. I would be very interested. 

Nick.

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Frank Manning wrote:
> 
> In article <858933630snz@nezumi.demon.co.uk> Martin@nezumi.demon.co.uk
> (Martin Tom Brown) writes:
> 
> > My point is that a primitive hardware based accelerometer could
> > have kept the thrust on average parallel to the velocity for
> > quite a lot longer once the main guidance system was wrecked.
> > It wouldn't be injected on the right orbit, but it wouldn't
> > self destruct quite so easily either.
> 
> OK -- I see your point. A 2-axis accelerometer could measure the
> sideways acceleration generated by a non-zero angle of attack. You
> could use that information to steer the engines and prevent the
> vehicle from flying sideways w/r/t the air mass. Might work.

From experience: An accelerometer/gyro set might be able to back up
an IRS sufficiently for flight control use, but not always. It depends
upon
the airframe stability and other factors.

Adding redundant/backup sensors is always a tricky proposition (actually
in many respects a hardware analogue to the discussion of using
assertions).
They add cost/weight/power/cooling, they have to be
spec'd/designed/tested,
they can introduce faults, and so forth.

> 
> -- Frank Manning

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Bertrand Meyer wrote:
> 
> which anyone can see is significantly different ("language and method",
> and "probably yes", with caveats about the risk of inferences, and a
> careful point-by-point discussion to examine the reasons for the
> assumption).

So, for those of us who have posted a detailed rebuttal on your
"language
and method" (both presumably being required, based on the word "and")
being
able to "probably" solve the Ariane 5 problem, what are you saying? You
disagree, for the reasons cited in your paper? Or do you care to address
the rebuttals?

Like ships passing in the night :)

>         >>> (read it, and if you think they say "this wouldn't
>         >>> have happened if they'd used Eiffel", read it again ;-)
> 
> I think the last two lines are good advice...

Having done this, I have come to the following conclusions:

The paper indicates that Eiffel, when used with Design by Contract,
would "probably" have prevented the Ariane 5 disaster.

  a. As a result, it is incorrect to claim that Design by Contract
     alone would solve the problem.

  b. Furthermore, the reasoning that the combination of Design by
Contract
     and Eiffel would have prevented the Ariane 5 disaster is
unconvincing.
     It fails to address (and is some cases contradicted by) the final
     report, and is unconvincing to those with experience in this type
of
     system. See my previous posts for more information.

  c. The paper also contains some material that is extraneous to the
issue
     of the Ariane 5 accident. Although not by itself a fatal flaw, it's
     annoying. (I haven't really commented on this previously, but it is
     strange for example that the paper admits Ada assertions were
adequate for
     the Ariane 5 issue, but goes on to explain how much more powerful
     Eiffel assertions can be. What's the point, other than selling
Eiffel?)

> 
> [In the quotations I have reinstituted the spelling of my name,
> of Jean-Marc Jezequel's, and of Ariane.]
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com
>         (including instructions to download Eiffel 4 for Windows)

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <33330FE5.3F54BC7E@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

  > You are picking on a sentence that explicitly says it is NOT the
  > programming language's fault.

  > It was important to note as an aside, as we did, that Ada's exception
  > mechanism IS subject to criticism (many people have criticized it
  > thoroughly, including Tony Hoare in his Turing Award lecture), but that
  > this was NOT the point here since Ada's exception mechanism, in spite
  > of its deficiencies, COULD have been used to avoid the error.

   It WAS used. It was used in a way that could and should have
resulted in the misuse being detected.  But as discussed at length
here, the disconnect was in the process by which the software was
reused.  There was no failure of analysis, since this statement was
found to comply with all known requirements.  The failure was a
management failure which guaranteed that the code was neither
evaluated with respect to, or tested against, the Ariane 5
requirements.  (Even though these were known to differ significantly
from those for Ariane 4.)

   To say that your paper is not trying to disparage Ada here is
certainly highly creative.  If Eiffel had been used, the same failure
would have occured, at the same time, and for the same reasons.  If
the software had ever been compared to the Ariane 5 requirements, the
failure would have been averted, whether Ada was used or Eiffel.

   Flame Retardant: I have nothing against Eiffel, and I am not trying
to start a language war.  The issue here is and should be the
requirements for safe reuse of code.  Those issues are the same, no
matter whether the software is written in Eiffel or Ada.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

J Durchholz says

<<Comments as source code documentation help, but they don't eliminate the
problem. I have seen code where comments and code were badly out of sync (I
have to woefully admit that I'm the author of some of it). The reason for such
inconsistencies is usually pressure to meet a deadline.>>

Discrepancies between code and comments are bugs, often serious bugs.
Pressure to meet a deadline should never result in the technial folks
involved being willing to cut corners and deliver code with bugs.

Usually the reason that comments get out of synch is programmers who don't
give the correctness of comments sufficiently high priority!

Note incidentally that executable assertions can ALSO get out of date, yes
you may have a chance of testing revealing such a bug, and it is true that
testing will never reveal a bug in a comment. However, relying on testing
alone is always dangerous, so whatever techniques (other than testing)
are used to ensure the correctness of code should also be applied to
ensuring that comments are correct.

It is this attitude that is critical in achieveing the admiteldly
difficult goal of making sure that comments stay in sync (systematic
reading of code is also very helpful :-)

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Robert I. Eachus wrote:
> 
>    To say that your paper is not trying to disparage Ada here is
> certainly highly creative.

By the way, this wasn't my point in my original post. My point was
that the suggestion that Design by Contract was not tightly coupled
to the Eiffel language is not supported by the paper. In fact, the
paper goes to great pains to imply that Eiffel is the only suitable
language to solve the Ariane 5 problem (contradicting its earlier
qualified statement that Ada was sufficient). Mr. Meyer reinforces
this in his later posts.

It reminds me of these annoying posts about various web sites: "I
just visited this great web site..." Of course, it's THEIR web
site they're promoting, but the writer wants to give off an air
of impartiality to impress the reader.

So, is this paper an impartial analysis of the Ariane 5 problem, or
an Eiffel sales pitch buried inside an impartial-sounding paper?
I would be more convinced of the former if, for example:

  (a) more of the criticisms I and others have expressed were
      addressed

  (b) the paper did not continuously mix the discussion of Eiffel
      (after all, the paper states Ada was sufficient) with the
      Ariane 5 specifics.

  (c) the paper had fewer appeals to authority at the end (always
      a red flag in any argument)

  (d) the paper indicated that the authors had some insight beyond
      just the final report (and I'm not convinced even that is
      demonstrated!). For example, who on the Ariane 5 team has
      been interviewed regarding the issues described in this paper?

However, I suspect that criticisms of this paper are falling on deaf
ears, so I would not expect it to change...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Thomas Beale wrote:
> 
> Jean-Marc Jezequel wrote:
> >
> > Yes this is true. But, since the SRI was reused from Ariane4, the problem
> > is not with developers, but with the *integration* team.
> 
> If the SRI is a black box, and this is taken to mean it is reusable,

I've never considered the term "black box" to be synonymous with
"reusable
in all environments." Moving away from software, a black box built for
any
Air Force aircraft may not meet the environmental conditions required
for
a Navy aircraft.

> doesn't
> that imply (by definition) that it should do its job with _any_
> trajectory
> data (or at least any data for a "reasonable" rocket trajectory)?

Once you use the word "reasonable," you have opened the door to
a potential problem.

 If
> this
> is not true, then you haven't got a "reusable SRI", you have "Ariane-4
> SRI".
> 
> So the assertion that the "real problem" was the decision not to supply
> Ariane-5
> trajectory data relies on the idea of the SRI not really being a
> reusable component,
> but one that "might work" or something similar.
> 
> However, the fact that an explicit decision was made not to use this
> data in effect
> means that the deciders (whoever they were) tacitly deemed the SRI as
> reusable (whether
> they realised that or not). (One imagines that this would be true for
> all kinds of
> components on the Ariane-5....).
> 
> So it seems that the "real problem" was one of the following:
> 
>         * the SRI component being deemed (knowingly or unwittingly) as reusable
> when it
>           wasn't, and then the development proceeding as if it was a reusable
> component.
> 
>         * if the SRI component was indeed _supposed_ to be re-usable, meaning
> it should have
>           worked with different datasets (among other things), then the fault
> is in the
>           implementation of the SRI's notional engineering specification, i.e.
> its "contract"
>           to other components.
> 
> So either way, it is a re-use error, as originally claimed.

I don't think anyone has suggested otherwise?


> 
> - thomas beale

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken Garlington said
> 
> <<I am totally confused now. The Ariane V incident could only have been
> prevented by a language that has Eiffel-like constructs, but it wasn't
> the language's fault?>>
> 
> No one said anything completely silly like that! Ken you are putting words
> into someone else's mouth. The most that has been said is something like
> "systematic use of xxxx would have prevented the Ariane V incident"

Let's review what was said (with the help of DejaNews):

[1] jezequel@irisa.fr (Jean-Marc Jezequel) writes in this thread on
1997/03/17:

"Basically, our claim in this paper is that it is a reuse issue (and in
a
lesser extent, a system integration test problem). Reusing a component
without
a precise specification of it is dangerous. That the component is
written in
Ada, Eiffel, C, assembly language has nothing to do with the way it is
specified.

"The all point of the paper is that Design by Contract helps in the
precise
specification of components: signatures (a la CORBA) are not enough to
specify a
behavior, pre- and post conditions are needed to give more details."

From this, I deduced (possibly erroneously) that Design by Contract
helps in the
precise specification of components, and that the implementation
language has
nothing to do with this specification. Well and good. However, I got the
strong
sense from the paper that Design by Contract would not have been
sufficient in
this case. Perhaps this statement was the source of my confusion:

[2]
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

"Does this mean that the crash would automatically have been avoided had
the
mission used a language and method supporting built-in assertions and
Design by
Contract? Although it is always risky to draw such after-the-fact
conclusions,
the answer is probably yes:"

Note the statement "language and method". The Design by Contract method
alone
is apparently insufficient: it also requires a language that supports
built-in
assertions. What languages, then, are considered in this category? Well,
we
know that they must look something like Eiffel:

[3]
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

"To attempt to reuse software without Eiffel-like assertions is to
invite
failures of potentially disastrous consequences."

What languages meet this further criteria? Well, we know which do NOT:

[4]
http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html

"It is regrettable that this lesson has not been heeded by such recent
designs as Java (which added insult to injury by removing the modest
assert instruction of C!), IDL (the Interface Definition Language of
CORBA,
which is intended to foster large-scale reuse across networks,
but fails to provide any semantic specification mechanism), Ada 95 and
ActiveX."

Of course, one could argue that these last few statements aren't
technically
in this thread, and so Dr. Dewar is correct. However, Bertrand Meyer is
quick to confirm, and in fact expand upon, this issue:

[5] Bertrand Meyer <bertrand@eiffel.com> writes on 1997/03/22:

"Fergus Henderson wrote:
 
"> Bertrand Meyer <bertrand@eiffel.com> writes:
> 
!!! Eiffel is the only [commonly available language] to have built-in
support for assertions in the
!!! spirit of Design by Contract.
> 
> What about Sather?  Doesn't it meet those criteria?"

"You are right, I should have mentioned Sather. Sorry
and thanks for correcting me. "

So, Eiffel and Sather are apparently the only commonly available
languages to have built-in support for assertions in the spirit of
Design by Contract (unless of course, I am misinterpreting
this post).

Therefore, I feel that the suggestion raised in [1], that Design
by Contract is not related to the implementation language, is
not correct. The paper, and Mr. Meyer's statements, appear to me
to couple the method with a language, and specifically the Eiffel
language (or Sather, I suppose). If someone wishes to argue this
point, feel free. Mr. Meyer has posted much on this issue, much of
which confirms my observation as quoted above.

I think part of the confusion on this issue can be explained by the
following quote:

[6] Bertrand Meyer <bertrand@eiffel.com> writes on 1997/03/25:

"(By the way I don't primarily think of Eiffel as a "language", more as
a
method. But this is not the main point of this particular discussion.)"

If Eiffel is a method as well as a language, is it a different method
than
Design by Contract, or are these synomyms? I suspect the latter. It is
unfortunate that the paper does not just refer to the Eiffel method, so
that this confusion over nomenclature could be avoided.

I also agree that this is a side issue: whether the paper is describing
a language-independent or a language-specific approach. Far more
interesting,
to me, would be for someone to address the language-independent issues
related to this paper, such as those I raised in:

http://xp7.dejanews.com/getdoc.xp?recnum=9332328&server=dnserver.db97p1x&CONTEXT=859409847.28570&hitnum=128

which has the message header
 
Subject:      Re: Papers on the Ariane-5 crash and Design by Contract
From:         Ken Garlington <GarlingtonKE@lmtas.lmco.com>
Date:         1997/03/19
Message-Id:   <33303627.4EDE@lmtas.lmco.com>

To summarize from the post, they are:

1. Being ABLE to specify the assumption does not mean that the
   assumption WILL be specified. There is evidence it would not have
   been specified, even using Design by Contract.

2. SPECIFYING the assumption does not mean that a violation of the
   assumption will be DETECTED. There is evidence that it would not
   have been detected before flight.

3. Even if the problem was DETECTED, there is no guarantee that the
   appropriate ACTION would have been taken. There is evidence that
   an incorrect action would have been taken.

These issues would matter, even if Design by Contract were not coupled
to a
particular language, in accepting or refuting the claim made in [2]. The
only argument made against this post, as far as I can tell, is that the
IRS
testing related to point #2 would not be "black-box" testing. I disagree
with
this statement (as do other engineers familiar with such systems), but
in fact
the nomenclature for this test is irrelevant to issue #2.

According to DejaNews, no response was posted. If I missed a post,
perhaps
someone could post a reference to it?

> 
> That is a statement that is highly NON-contentious, since it is true for
> almost all possible xxxx including
> "common sense".
> 
> The trouble is that when people start replacing xxxx with specific language
> features, it is only to easy to read the statement as saying that the
> particular choice of xxxx is somehow the only one or at least a key one.
> 
> I have no problem with the statement above with "Eiffel assertions" or
> "Programming by Contract" inserted for the xxxx,

which would lead to the statements:

systematic use of "Eiffel assertions" would have prevented the Ariane V
incident
systematic use of "Programming by Contract" would have prevented the
Ariane V incident

I consider either statement (or both together) to be controversial. See
above.

> but the suggestion that
> only these approaches would be appropriate, or even that in this case they
> have some special advantage would be respectively absurd or dubious. The
> first allegation simply has not been made in this thread.

True. Not even by me! When I said "only have been prevented by a
language
that has Eiffel-like constructs," I was referring to the single-language
issue described above.

> Some people have
> made the second, and I find the argument dubious.

Me, too. Doesn't this contradict the claim you made above, that you have
no problem with the two statements generated from the "xxxx"?

> The Ariane V goof is not
> a particularly instructive one from a language or methodology point of view.

However, from a total system development process standpoint, it is
extremely valuable.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

<<I guess i made a dangerous generalization there. I've been instinctively
appliying programming-by-contract tecniques for the 15 years i've been
programming professionally - imperfectly, ofcourse. I've gathered and
developed tools and techniques slowly along the way, and am still
learning.>>

Sure, but virtually everyone has been instincitively applying at least 
some of the basic idea of programming-by-contract for ever and ever amen.
The basic idea here is nothing new, and indeed is obvious.

What is significant about programming by contract is *precisely* the
activity of formalizing it and embodying it into fixed syntax (even that
idea is by no means new, Eiffel did not invent this idea, and I am sure
that Bertrand Meyer would not claim otherwise -- what Eiffel did was to
make it a centerpiece of the design, and that is indeed interesting!)

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <3336D167.6BFC@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:


> I will freely admit that Eiffel is required for Design by Contract. Why
> do you hestiate to do the same? In fact, would it not be more accurate
> to simply state your position as: "If the Ariane V had been programmed
> in Eiffel, with proper use of Eiffel assertions, then the incident would
> not have happened?"

I agree.  This would be perfectly understandable (even "reasonable").


> Why be so oblique in your paper? Simply make this assertion, give
> the address where to order copies of Eiffel, print it on color
> glossy paper, and send it to all the major aerospace companies? It
> seems intellectually dishonest to say "this is not a language
> issue."

Yes, this, unfortunately (and _disappointingly_) has become precisely
the point.  Putting on airs of objectivity while repeatedly denying
facts and stating contradictory claims doesn't help anything.  Indeed,
it just ends up annoying people and goading them.  I don't understand
why people of this calibre (and stature in the field) feel that they
are somehow served by this kind of behavior.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Thomas Beale]

Jean-Marc Jezequel wrote:
> 
> Yes this is true. But, since the SRI was reused from Ariane4, the problem
> is not with developers, but with the *integration* team.

If the SRI is a black box, and this is taken to mean it is reusable,
doesn't
that imply (by definition) that it should do its job with _any_
trajectory
data (or at least any data for a "reasonable" rocket trajectory)? If
this 
is not true, then you haven't got a "reusable SRI", you have "Ariane-4
SRI". 

So the assertion that the "real problem" was the decision not to supply
Ariane-5
trajectory data relies on the idea of the SRI not really being a
reusable component,
but one that "might work" or something similar.

However, the fact that an explicit decision was made not to use this
data in effect
means that the deciders (whoever they were) tacitly deemed the SRI as
reusable (whether
they realised that or not). (One imagines that this would be true for
all kinds of 
components on the Ariane-5....).

So it seems that the "real problem" was one of the following:

	* the SRI component being deemed (knowingly or unwittingly) as reusable
when it
	  wasn't, and then the development proceeding as if it was a reusable
component.

	* if the SRI component was indeed _supposed_ to be re-usable, meaning
it should have
	  worked with different datasets (among other things), then the fault
is in the
	  implementation of the SRI's notional engineering specification, i.e.
its "contract"
	  to other components.

So either way, it is a re-use error, as originally claimed.

- thomas beale

Re: Papers on the Ariane-5 crash and Design by Contract

[Matt Kennel (Remove 'nospam' to reply)]

On Mon, 24 Mar 1997 20:18:12 -0500, Anders Pytte <milkweed@plainfield.bypass.com> wrote:
:
:I guess i made a dangerous generalization there. I've been instinctively
:appliying programming-by-contract tecniques for the 15 years i've been
:programming professionally - imperfectly, ofcourse. I've gathered and
:developed tools and techniques slowly along the way, and am still
:learning.

This is exactly why "programming by contract" *technology* is so valuable,
because it enforces, abets, and promotes good behavior and hard-earned
wisdom to many more people, just as good register allocation technology
in compilers once rendered the assembly language prowess of above-the-norm
programmers to the masses. 

The C++ design attitude is "don't even try to enforce any style at all"
which I don't like.  If you're particularly postmodernist you might
assert that such a 'nonstyle' is as much a style in empirical reality
as any other. 

IMHO, it really is true that "policy and mechanism" is better than "mechanism
not policy" if such policy were thoughfully crafted via wisdom, insight and
experience. 

"There is no 'it would be possible to implement it in a library'.
 There is only do or not do." :-)
 
-- 
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
Don't blame me, I voted for Emperor Mollari. 

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <33389335.279@invest.amp.com.au>, Thomas Beale <thomas_beale@
invest.amp.com.au> writes

>So either way, it is a re-use error, as originally claimed.


    Do people _really_ think this way?


    Talking about the total destruction of a multi-billion dollar rocket
at lift-off, and arguing whether or not it's "a" reuse error?


    Fucking alienated BULLSHIT, chummy:


    At the bottom of the rubble is people failing to communicate...


    ...And I ain't talking Shannon.




Sandy

/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Ken Garlington said

<<I am totally confused now. The Ariane V incident could only have been
prevented by a language that has Eiffel-like constructs, but it wasn't
the language's fault?>>

No one said anything completely silly like that! Ken you are putting words
into someone else's mouth. The most that has been said is something like
"systematic use of xxxx would have prevented the Ariane V incident"

That is a statement that is highly NON-contentious, since it is true for
almost all possible xxxx including
"common sense".

The trouble is that when people start replacing xxxx with specific language
features, it is only to easy to read the statement as saying that the
particular choice of xxxx is somehow the only one or at least a key one.

I have no problem with the statement above with "Eiffel assertions" or
"Programming by Contract" inserted for the xxxx, but the suggestion that
only these approaches would be appropriate, or even that in this case they
have some special advantage would be respectively absurd or dubious. The
first allegation simply has not been made in this thread. Some people have
made the second, and I find the argument dubious. The Ariane V goof is not
a particularly instructive one from a language or methodology point of view.

Re: Papers on the Ariane-5 crash and Design by Contract

[Marin David Condic, 561.796.8997, M/S 731-93]

Nick Roberts <Nick.Roberts@DIAL.PIPEX.COM> writes:
>>     it overflow. It might have saved the Ariane. What might also have
>>     saved them would be if the arithmetic on the machine had saturated
>>     instead of causing an interrupt. (Disable the interrupt & let the
>>     hardware saturate or enable the interrupt & put your own
>>     saturation software in there.) Floating point usually saturates
>>     the way you want it to from hardware, but fixed usually doesn't.
>>
>
>I would be very grateful if you (or someone) would explain the term
>'saturation' in this context. I'm not accusing you of incorrect usage of a
>technical term, merely myself of ignorance. I would be very interested.
>
>
    I'm not sure if there is some formal academic definition of the
    term in either mathematics or computer science. I've only learned
    to use the term the way it gets used in the embedded world around
    here.

    Integer arithmetic is the simplest case: If you have a 16bit
    signed integer with a value of +32766 in it and you add, say +10
    to it, instead of getting a value that wraps around to the
    negative (including an interrupt for fixed point overflow) you get
    +32767. In other words, the register "saturates" to its maximum
    possible value.

    Floating point overflow/underflow is similar, except you have to
    deal with very large & very small numbers as well as negative &
    positive. If you have "saturated" floating point arithmetic, as
    you continually divide a number by 0.1 and it gets closer and
    closer to zero, eventually you trip over the smallest number
    representable and the number "saturates" to zero. Likewise, in the
    other direction.

    If you're lucky, your hardware will do this for you. If not,
    you've got to implement this effect in software - which in Ada is
    easy to do by defining your own type with it's own "+", "-", etc
    operators - but that can be terribly slow!

    The reason that saturation is such a good thing in "control"
    systems is because it is very much like the real world works. If
    you're commanding some motor to turn at a given rate, sooner or
    later you hit the maximum rate the motor can turn and commanding
    it to turn faster does no good. Thus your math which calculates
    how to command the motor ought to saturate the same way the motor
    does. If it wraps around to a big negative number, chances are you
    just commanded the motor to spin at max rate in the opposite
    direction. (Generally considered "bad") Naturally, you want all
    your math to work correctly and never generate an overflow. But if
    you made a mistake? An unanticipated, "out-of-range" condition?
    If your math saturates, chances are you're doing the right thing -
    or at least the least harmful thing.

    Hope this explains it. Maybe more hardware designs (or language
    designs?) will one day provide this sort of behavior for us
    control geeks.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "That which belongs to another."

        --  Diogenes, when asked what wine he liked to drink.
===============================================================================

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

> 2. Claims that Design by Contract is not language-specific (i.e. Eiffel)
>    are also clearly false, and attempts to sell it as such are silly.

Yes and no.
Besides Eiffel, there is currently no commercial language that supports 
design-by-contract. In this sense, it is language-specific.
But it would not be a problem to add programming-by-contract to any OO 
language. In this sense, it is definitely not language-specific, and it is 
even in the grey areas between design and code writing.

Regads,
Joachim

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

> I am attracted to the idea of catching exception objects based on their
> run-time type and I'm sure Eiffel is missing some semantic content here.

The class EXCEPTION with several subclasses does exist as part of the 
standard libraries. Exception handlers can decide what to do based on the 
run-time class of the exception. This facility does not seem to be in 
wide-spread use, but it's all there.

Regards,

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Ray said

<<Finally!  Thank you, sir.  It was obvious from reading the report that
was pointed out several months ago by a post in this newsgroup that this
was a wonderful example of a failure WAY early in the lifecycle.  It had
nothing to do with design or construction and everything to do with a
bogus specification.  They were in effect designing a control system for
a completely different rocket than the one in which the system was used!>>

Indeed, and in such a case, tightening up the methodology for encoding the
specification is not likely to be helpful. It can even be harmful if it
results in diverting effort into a non-useful area!

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On 26 Mar 1997 17:13:20 -0500 in article <dewar.859414225@merv> posted to comp.lang.eiffel, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> <<I guess i made a dangerous generalization there. I've been instinctively
> appliying programming-by-contract tecniques for the 15 years i've been
> programming professionally - imperfectly, ofcourse. I've gathered and
> developed tools and techniques slowly along the way, and am still
> learning.>>

> Sure, but virtually everyone has been instincitively applying at least 
> some of the basic idea of programming-by-contract for ever and ever amen.
> The basic idea here is nothing new, and indeed is obvious.

> What is significant about programming by contract is *precisely* the
> activity of formalizing it and embodying it into fixed syntax (even that
> idea is by no means new, Eiffel did not invent this idea, and I am sure
> that Bertrand Meyer would not claim otherwise -- what Eiffel did was to
> make it a centerpiece of the design, and that is indeed interesting!)

Bertrand Meyer is a crook, and so is Dewar.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzoPaalPvImbzLKZAQFQmwP/Q98hKcuvGhuk20mlaQPEJHSHR8xaanAQ
JUT0mw2b5PA7e5EqunSJYmYDuzikJt9apx2WGSlTNFFgxIvtfEWMTeRsQI+7lRzX
wy4S1K3II6tZjcKnhcd+N6azct8b75hrpHkZzvYknIQbslmSlu+ZtqjalntM83QV
E3EU/wsjAhs=
=Mj/u
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[Matt Kennel (Remove 'nospam' to reply)]

On 22 Mar 1997 01:45:25 GMT, Jon S Anthony <jsa@alexandria> wrote:
:In article <33330FE5.3F54BC7E@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
:
:> > From this we learn that Java and Ada 95 are not properly designed for
:> > Design by Contract.
:> 
:> Which is the simple truth. The designers of these languages have
:> explicitly rejected the inclusion of assertions. Why? They are the
:> ones to ask.  I am sure they must have their reasons (however
:> unlikely it is I would find these to be good reasons).
:
:It is simply amazing to see you sit there (or type there) and say in
:one breath "Which is the simple truth" and then proceed to make an
:absolutely false statement in the next.  In fact, it is extremely
:disappointing and makes you look ridiculous.
:
:Ada _has_ assertions.  Their form is not of the same syntactical look
:as Eiffel's.  So what?  They take the form of constraints, in
:particular (wrt to the case at hand) subtype constraints.  They are
:_not_ as flexible or full "featured" as Eiffel's but they are
:certainly there and in the Ariane case, they are every bit as capable
:as Eiffel's.  

Of course static type constraints are a form of 'precondition', namely
"the object being referred to by this reference, or in this variable is
 one of these types".

By that measure C++, C, and Pascal, and maybe even Fortran have assertions. 
 
It is often useful and powerful to program in a style in
a statically typed language where important information is encoded into
types, but this is not a full substitute for Eiffel's additional
capabilities. 

Whether or not it would have done so in the rocket crash is another
story.  

Simply not testing the control system with a whole new rocket is an
*idiotic* mistake.  "Oh, we change the mass, the moment of inertia, the 
power, and all that, but sure the old control system will work just
fine."

At least with the Challenger screwup there was a judgement call involved
with a piece of physics not entirely known. 
 
:Jon Anthony
:Organon Motives, Inc.
:Belmont, MA 02178
:617.484.3383
:jsa@organon.com

-- 
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
Don't blame me, I voted for Emperor Mollari. 

Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

In article <slrn5jmbhv.7k9.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'nospam' to reply)) writes:

> :Ada _has_ assertions.  Their form is not of the same syntactical look
> :as Eiffel's.  So what?  They take the form of constraints, in
> :particular (wrt to the case at hand) subtype constraints.  They are
> :_not_ as flexible or full "featured" as Eiffel's but they are
> :certainly there and in the Ariane case, they are every bit as capable
> :as Eiffel's.  
> 
> Of course static type constraints are a form of 'precondition', namely
> "the object being referred to by this reference, or in this variable is
>  one of these types".
> 
> By that measure C++, C, and Pascal, and maybe even Fortran have assertions. 

Yes, I would agree with that.  Also note that while subtypes are
indeed "primitive" in comparison to Eiffel capabilities, their limits
can be (and often are) computed at runtime.  For example:

    subtype Current_Constraint is integer range Current_Min .. Current_Max;

where both Current_Min and Current_Max are functions.


> It is often useful and powerful to program in a style in a
> statically typed language where important information is encoded
> into types, but this is not a full substitute for Eiffel's
> additional capabilities.

Absolutely agreed.


> Whether or not it would have done so in the rocket crash is another
> story.

Check.  The main thing to note in regards to this point is that

  a) the sort of assertion capability called out in the M&J paper
which supposedly could have helped is nothing more (or less) than an
Ada subtype constraint.

  b) the practitioners knew all about this capability and even used
it in places.

  c) the particular case in point was _proven_ to be not possible
_within_ the contextual environment intended for the use of the
component.

  d) given c) there is no good reason (no reason even) to include such
an assertion and in fact very good reasons to _not_ include it.

  e) for those who think d) is dumb, please note that this sort of
thing is standard practice in _real_ engineering - lest nothing would
be buildable and/or useable.

To draw an analogy, someone who is designing a wing notes that the
context of its use will be that of standard A to B general aviation
flights.  The context also requires all sorts of practical things like
weight limits, cost limits, etc. for the sort of use it will have.
Now, such an environment does not require unlimited style acrobatic
flight or some such.  Nor does it assume that the pilots will
intentionally fly into category 6 thunderstorms.  The G loads of the
environment are will within limit loads of +3 and -1 (ultimate loads
of +4 and -2).

Now, under such circumstance why would the designer require that the
wing shall meet limit loads of +10/-10?  The attitude of some people
here seems to be "of course it should be built with such capability -
some fool _might_ try to fly acro with the plane it is on or maybe go
into such storms".  But that's not the context of use and in the
intended area of use, the cost of such a thing will be much more than
another perfectly suitable wing with the appropriate assumed limits.
It will likely be much heavier as well, and with less usable space for
fuel cells.  This would reduce practical useful load and range in any
airplane using it.  What's more, it is always possible that someone
would exceed +10/-10 as well.  So where do you stop?

Now, where is this sort of contextual information in such real
engineering designs?  In the "code" - i.e., actual example?  No way.
That's way to easy to miss.  It's in the associated specifications,
blueprints, and documentation - including all the way down to the user
(pilot operating handbook).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7754 bytes --]


Don Harrison wrote:
> 
> Before getting into this, let me say that I acknowledge that specifying
> assertions is largely futile unless they are tested. [Well, that's not
> strictly true because they have documentation value (though not much if not
> correct) and do help the developer become more aware of their assumptions.]
> 
> Ken Garlington writes:
> 
> :From this, I deduced (possibly erroneously) that Design by Contract
> :helps in the
> :precise specification of components, and that the implementation
> :language has
> :nothing to do with this specification.
> 
> At the risk of putting words into their mouths, I think Bertrand and Jean-Marc
> may mean Design by Contract in its richest sense as available in Eiffel and
> Sather rather than an impoverished version of it.

Exactly. This contradicts an earlier post by Mr. J�z�quel, to which I
was responding.

> If they are speaking of it
> in this sense, this statement is certainly true of any language that supports
> it fully. It's also true that the same benefit is available to a lesser degree
> in languages that support it in an impoverished form. The truth is, Ada
> developers use Design by Contract (of a kind) liberally as I'll explain below.

However, the paper (and Mr. Meyer, in posts to this thread) make it
clear that
Ada (including Ada95) is not adequate for Design by Contract.

> 
> They ought to make no excuse for believing in using the best available tools
> for that's what software engineering is about - using the best tools for the
> job in the most effective way to produce high quality software. This is the
> essence of genuine Design by Contract.
> 
> I now use contracting liberally in my own Ada development (well, I've always
> used subtypes, but now use more general assertions as well) and I'm convinced it
> more than pays for itself in reduced integration time. Granted, they take extra
> effort to design and debug but it's more than offset by easier testing.
> 
> So, what is meant by "Design by Contract in its richest sense". Assertions
> that are:
> 
>   1) Built-in because
>      - It's easier to automatically document the specification.
>      - It's easier to visually differentiate assertions from mandatory code.
>      - Developers are more likely to use them, IMO. ["IMO" only because, while
>        obviously true, it is difficult to prove.  :( ]
> 
>   2) General because
>      - They allow you to specify at any level of abstraction (high to low).
>      - They allow you to specify virtually any specification (anything
>        expressible as a boolean expression - not just range constraints on
>        discrete types).
> 
>   3) Inheritable because
>      - The specification is propagated into descendants causing it to be
>        automatically reused and enforced. Because descendants are forced to
>        honour contracts, you can be confident they will behave correctly
>        (provided the software is tested, of course).
> 
> :To summarize from the post, they are:
> :
> :1. Being ABLE to specify the assumption does not mean that the
> :   assumption WILL be specified.
> 
> True. You can put an electric drill in someone's hands and they can
> (without plugging it in) gouge a hole by manually turning it, but it would be
> a whole lot easier if they just turned the power on and used it properly.

I'm afraid I don't understand this argument. You consider writing code
easier than not writing code?

> 
> :There is evidence it would not have
> :   been specified, even using Design by Contract.
> 
> I consider this unlikely. Assuming a reasonably-designed system, a contract
> testing for this abnormal behaviour would be expressible at some level of
> abstraction.

You are free to consider this unlikely. However, there are specific
statements
in the final report that support this assertion. See the referenced
earlier
post. If you have evidence to the contrary, you may want to address this
point in more detail.

> 
> :2. SPECIFYING the assumption does not mean that a violation of the
> :   assumption will be DETECTED. There is evidence that it would not
> :   have been detected before flight.
> 
> Agree. An assumption will only be detected if tested.
> 
> :3. Even if the problem was DETECTED, there is no guarantee that the
> :   appropriate ACTION would have been taken. There is evidence that
> :   an incorrect action would have been taken.
> 
> Agree. Appropriate action will only be taken if the exception handler is
> designed to cater for the misadventure.
> 
> However, also true is the fact that if you specify contracts you will detect
> *as many* and, likely, *more* errors (providing testing is adequate etc. etc.)
> than if you do not specify them.

Yes, absolutely.

However, again, my comments are directed at the paper Mr. Meyer and Mr.
J�z�quel regading a *specific* application of contracts in a *specific*
context. Based on that *context*, I believe their conclusions are in
error.
 
> 
> Now, before explaining this, let's clear something up. Many Ada developers
> already use (a specific kind of) Design by Contract day-in-day-out without even
> realising it. Some contributors to this thread have indicated that Ada
> programmers specify their own contracts by declaring Ada subtypes. But subtypes
> are not the only way they use contracting. They also use a swag of pre-defined
> contracts provided by the language environment. To identify them, we need to
> take a look at Ada's predefined exceptions. We see that each one specifies a
> specific kind of contract (sorry this is only Ada-83 - there are probably more
> in Ada-95):
> 
> 1) constraint_error: a contract specifying that
>    - The allowable bounds of a discrete type (subtype, array index) will not
>      be exceeded, or
>    - A record variant will only exist for a specific discriminant value
>    - etc.
> 
> 2) numeric_error: a contract specifying that
>     - A floating point value will be within the bounds of the type.
> 
> 3) program_error: a contract specifying
>    - The unit ('object') containing the operation called will have been
>      initialised, or
>    - A function will return (a postcondition)
>    - etc.
> 
> 4) storage_error: a contract specifying
>    - That a task will not exceed its allocated storage, or
>    - The heap will not exhausted
>    - etc.
> 
> Well, you get the picture. Probably, the reason some Ada developers have
> trouble seeing how they can benefit from Design by Contract is because they're
> oblivious to the fact that they already use it liberally in the form of
> predefined contracts (and reap the benefits of it)!
> 
> While it's good that Ada is rich in specific pre-defined contracts, it
> disappoints in that it doesn't offer the full power and flexibility of
> *user-defined* contracts in the way Eiffel does. If it did, then it would
> be easier to specify the more general kind of assertion that would expose
> the kinds of dysfunction that may go unnoticed in an assertion-less Ada
> program.

Again, in the *context* of the paper:

1. As the paper explicitly states, Ada was adequate for this type of
error.

2. The paper does not make the case that "making it easier to specify"
the
   right assertion would have led to saving the Ariane 5, as it claims.
   As you noted, there are critical holes in the path from "able to
   specify" to "fault detected" which would have avoided the crash.
   Apparently, I think there's more holes than you, but we appear to
   agree there were sufficient holes.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Anders Pytte]

In article <slrn5jhm2i.1rq.kennel@lyapunov.ucsd.edu>,
kennel@nospam.lyapunov.ucsd.edu wrote:

> On Mon, 24 Mar 1997 20:18:12 -0500, Anders Pytte
<milkweed@plainfield.bypass.com> wrote:
> :
> :I guess i made a dangerous generalization there. I've been instinctively
> :appliying programming-by-contract tecniques for the 15 years i've been
> :programming professionally - imperfectly, ofcourse. I've gathered and
> :developed tools and techniques slowly along the way, and am still
> :learning.
> 
> This is exactly why "programming by contract" *technology* is so valuable,
> because it enforces, abets, and promotes good behavior and hard-earned
> wisdom to many more people, just as good register allocation technology
> in compilers once rendered the assembly language prowess of above-the-norm
> programmers to the masses. 
> 
> The C++ design attitude is "don't even try to enforce any style at all"
> which I don't like.  If you're particularly postmodernist you might
> assert that such a 'nonstyle' is as much a style in empirical reality
> as any other. 
> 
> IMHO, it really is true that "policy and mechanism" is better than "mechanism
> not policy" if such policy were thoughfully crafted via wisdom, insight and
> experience. 
> 
> "There is no 'it would be possible to implement it in a library'.
>  There is only do or not do." :-)
>  
> -- 
> Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
> Don't blame me, I voted for Emperor Mollari. 

I don't agree with "C++ design attitude is don't even try to enforce any
style at all". That is not even close to the case with any C++ programmers
that I know, nor any of the C++ libraries whose sources I have seen. I
think that statement more accurately reflects the snobbishness of persons
who have the luxury of programming with a language which I acknowledge is
more advanced.

Perhaps you are in academics (not meant as an insult ;-).

In fact, there is nothing essential to Eiffel that I am aware of that was
not practiced by good engineers years before Eiffel was concieved, with
great effort and inspite of difficulties imposed by language (like
non-inheritence of pre- and post-conditions).

Otherwise i agree with everything you said.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Steve Furlong]

Anders Pytte wrote:
> In fact, there is nothing essential to Eiffel that I am aware of that was
> not practiced by good engineers years before Eiffel was concieved, with
> great effort and inspite of difficulties imposed by language (like
> non-inheritence of pre- and post-conditions).

Indeed. But that's the reason I like Ada, Eiffel, and other languages 
which promote "good technique". Careful, professional programmers can 
write a well-engineered program in any language, with proper attention to 
interfaces, boundary conditions, and all other likely pitfalls. Code 
cowboys and fumblefingers can bypass safety features to create a mess in 
any language.

The goal, IMHO, is to encourage the "average" programmer, the one between 
these extremes, to use proper technique. Use of languages supporting good 
software engineering can only make this easier.

FWIW, I'm hardly a language snob. I program professionally in C++ and 
Visual Basic, since that's what they pay me for.


Regards,
Steve Furlong

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On 27 Mar 1997 00:06:39 -0500 in article <dewar.859439125@merv> posted to comp.lang.eiffel, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> Ray said

> <<Finally!  Thank you, sir.  It was obvious from reading the report that
> was pointed out several months ago by a post in this newsgroup that this
> was a wonderful example of a failure WAY early in the lifecycle.  It had
> nothing to do with design or construction and everything to do with a
> bogus specification.  They were in effect designing a control system for
> a completely different rocket than the one in which the system was used!>>

> Indeed, and in such a case, tightening up the methodology for encoding the
> specification is not likely to be helpful. It can even be harmful if it
> results in diverting effort into a non-useful area!

Fuckhead.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMz1LsqlPvImbzLKZAQFJgwQAkl4Rwjj558h1Rlw/ZtnvEgYudMFlNuLU
+SqyrMF/9mg5LdsAzEdH9kMqhmFdY89QZj4BY1bxsg3NtIipq94NZ73Z0x7uSZb9
gajFwUyK2BZC5+/iW9j54isZWL4jc45D5vlf8j2oxxzyKyLreo2fJdo7yAYOrBat
q+AhPlVx5sM=
=XOtl
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On 26 Mar 1997 17:13:20 -0500 in article <dewar.859414225@merv> posted to comp.lang.eiffel, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> <<I guess i made a dangerous generalization there. I've been instinctively
> appliying programming-by-contract tecniques for the 15 years i've been
> programming professionally - imperfectly, ofcourse. I've gathered and
> developed tools and techniques slowly along the way, and am still
> learning.>>

> Sure, but virtually everyone has been instincitively applying at least 
> some of the basic idea of programming-by-contract for ever and ever amen.
> The basic idea here is nothing new, and indeed is obvious.

> What is significant about programming by contract is *precisely* the
> activity of formalizing it and embodying it into fixed syntax (even that
> idea is by no means new, Eiffel did not invent this idea, and I am sure
> that Bertrand Meyer would not claim otherwise -- what Eiffel did was to
> make it a centerpiece of the design, and that is indeed interesting!)

Who cares what Bertrand Meyer claims - he's a well-known liar and
a crook.  Anything Bertrand Meyer claims has got to be a fucking lie.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMz1MCalPvImbzLKZAQGWfgP9FOd+wiUm2JNpLobEBvbkne1BpDpeyc83
+L8DcCyUHSYO2inB3vFtOOkK8rDL1CqRsrCQZnR8yIdDXd+Em4SkGRQyreyooW2R
zIzB9X6n34gGfhZI0JyABcwuu1T34q3UtrDFDZwZz0+oQMmBUOC2tM5xLXcyEDn3
8Jhx7Lp5YAs=
=E+R3
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick S Bensema]

In article <5hji69$2hq@stronghold.dhp.com>,
the one and only real true kibo  <kibo@dhp.com> wrote:
>Who cares what Bertrand Meyer claims - he's a well-known liar and
>a crook.  Anything Bertrand Meyer claims has got to be a fucking lie.

Hey guess what!  Bertrand Meyer just claimed you're the real Kibo!

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Roberts]

Kibo! Tone down your language! Usenet is a highly flammable area.
Nick ;-)

Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

-----BEGIN PGP SIGNED MESSAGE-----

On 29 Mar 1997 18:57:02 -0700 in article <5hkh9e$fh6@nnrp1.news.primenet.com> posted to comp.lang.eiffel, Nick S Bensema <nickb@primenet.com> wrote:
> In article <5hji69$2hq@stronghold.dhp.com>,
> the one and only real true kibo  <kibo@dhp.com> wrote:
> >Who cares what Bertrand Meyer claims - he's a well-known liar and
> >a crook.  Anything Bertrand Meyer claims has got to be a fucking lie.

> Hey guess what!  Bertrand Meyer just claimed you're the real Kibo!

Mirabile dictu -- Bertrand Meyer spoke the truth for the first time
in his fucking life.

I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
Finger me for my PGP public key. Check out my home page for the coolest
way to vote on new newsgroup proposals or to issue Usenet cancels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMz6LzqlPvImbzLKZAQESCQP/ZcBzJ2SI9a78TbAruE9xRvntYfJEUpTN
hbMwHcVPE0n9cZli2a7GZ4Pai7tmvrCONvXybPqlPpB03Y/3gUa0OjBiixQUIf/R
Cwck1T/SfgpvXZw5pHLSuEuJMlLGQzPWL1jgUZb8LUBFAwZiQXoNZhmxDwv4yHXI
Lve9F/qJR0I=
=IrCI
-----END PGP SIGNATURE-----

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jon S Anthony wrote:
> 
> In article <slrn5jmbhv.7k9.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'nospam' to reply)) writes:
> 
> > :Ada _has_ assertions.  Their form is not of the same syntactical look
> > :as Eiffel's.  So what?  They take the form of constraints, in
> > :particular (wrt to the case at hand) subtype constraints.  They are
> > :_not_ as flexible or full "featured" as Eiffel's but they are
> > :certainly there and in the Ariane case, they are every bit as capable
> > :as Eiffel's.
> >
> > Of course static type constraints are a form of 'precondition', namely
> > "the object being referred to by this reference, or in this variable is
> >  one of these types".
> >
> > By that measure C++, C, and Pascal, and maybe even Fortran have assertions.
> 
> Yes, I would agree with that.  Also note that while subtypes are
> indeed "primitive" in comparison to Eiffel capabilities, their limits
> can be (and often are) computed at runtime.  For example:
> 
>     subtype Current_Constraint is integer range Current_Min .. Current_Max;
> 
> where both Current_Min and Current_Max are functions.
> 
> > It is often useful and powerful to program in a style in a
> > statically typed language where important information is encoded
> > into types, but this is not a full substitute for Eiffel's
> > additional capabilities.
> 
> Absolutely agreed.
> 
> > Whether or not it would have done so in the rocket crash is another
> > story.
> 
> Check.  The main thing to note in regards to this point is that
> 
>   a) the sort of assertion capability called out in the M&J paper
> which supposedly could have helped is nothing more (or less) than an
> Ada subtype constraint.
> 
>   b) the practitioners knew all about this capability and even used
> it in places.
> 
>   c) the particular case in point was _proven_ to be not possible
> _within_ the contextual environment intended for the use of the
> component.
> 
>   d) given c) there is no good reason (no reason even) to include such
> an assertion and in fact very good reasons to _not_ include it.
> 
>   e) for those who think d) is dumb, please note that this sort of
> thing is standard practice in _real_ engineering - lest nothing would
> be buildable and/or useable.

Exactly. It has been implied that, with Design by Contract, that the
reasons _not_ to include an assertion are mitigated to the extent that
just about every conceivable assertion is routinely included in systems
designed with this methodology. I could be easily convinced that there
are more explicit assertions in a DBC program than an Ada program, based
on the extra expressive power in Eiffel specifications. However, if a
programmer sees the violation of an assertion as highly improbably, I
would expect it would not get written regardless of the language used.
I would be interested in evidence to the contrary.

> 
> To draw an analogy, someone who is designing a wing notes that the
> context of its use will be that of standard A to B general aviation
> flights.  The context also requires all sorts of practical things like
> weight limits, cost limits, etc. for the sort of use it will have.
> Now, such an environment does not require unlimited style acrobatic
> flight or some such.  Nor does it assume that the pilots will
> intentionally fly into category 6 thunderstorms.  The G loads of the
> environment are will within limit loads of +3 and -1 (ultimate loads
> of +4 and -2).
> 
> Now, under such circumstance why would the designer require that the
> wing shall meet limit loads of +10/-10?  The attitude of some people
> here seems to be "of course it should be built with such capability -
> some fool _might_ try to fly acro with the plane it is on or maybe go
> into such storms".  But that's not the context of use and in the
> intended area of use, the cost of such a thing will be much more than
> another perfectly suitable wing with the appropriate assumed limits.
> It will likely be much heavier as well, and with less usable space for
> fuel cells.  This would reduce practical useful load and range in any
> airplane using it.  What's more, it is always possible that someone
> would exceed +10/-10 as well.  So where do you stop?
> 
> Now, where is this sort of contextual information in such real
> engineering designs?  In the "code" - i.e., actual example?  No way.
> That's way to easy to miss.  It's in the associated specifications,
> blueprints, and documentation - including all the way down to the user
> (pilot operating handbook).
> 
> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> Belmont, MA 02178
> 617.484.3383
> jsa@organon.com

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Jan Galkowski]

Robert Dewar wrote:
> 
[snip]

> 
> Discrepancies between code and comments are bugs, often serious bugs.
> Pressure to meet a deadline should never result in the technial folks
> involved being willing to cut corners and deliver code with bugs.
> 

I heartily agree with you and have left a job because of management's
willingness to ship such code over the objections of some technical
people.  Worse, I can entirely understand how Ariane 5 happened if only
because in the rush to get paid, contractors sometimes rush and shortcut
systems acceptance tests, justifying their actions with rationales that are
little more than handwaving and the equivalent of "Well, it worked on Ariane 
4...."  

But the problem is, unfortunately, many people who need to make a choice
between taking a strong stand in favor of correctness and possibly putting
their jobs on the line and just keeping quiet, doing what they are told, will
opt for the latter.  This makes the job of the relative few who do want
code to be right very much more difficult: Management says "How come
you're the only one objecting...."

I don't mean to imply what you say isn't valid: It is.  It's just the
world of aerospace and military contracting is more complicated than that.

[snip]

-- 
 Jan Theodore Galkowski, 
 developer, tool & numerical methods elf
   Digicomp Research Corporation,
   Ithaca, NY 14850-5720
 jan@digicomp.com 
 (also jtgalkowski@worldnet.att.net)

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Joachim Durchholz wrote:
> 
> > 2. Claims that Design by Contract is not language-specific (i.e. Eiffel)
> >    are also clearly false, and attempts to sell it as such are silly.
> 
> Yes and no.
> Besides Eiffel, there is currently no commercial language that supports
> design-by-contract. In this sense, it is language-specific.
> But it would not be a problem to add programming-by-contract to any OO
> language. In this sense, it is definitely not language-specific, and it is
> even in the grey areas between design and code writing.

Putting aside the problems associated with modifying languages, and of
making them
sufficiently "commercial" to use in critical systems, I think you would
agree that if C++, for example, were modified sufficiently to meet the
"spirit"
of Design by Contract, it would no longer be C++, but another language.
So,
a programmer writing in C++ would still not have a language that would
be
sufficient.

Most methologies that address software design make some assumptions
about the
underlying language capabilities. DBC makes assumptions that can only be
completely met, _today_, by Eiffel and Sather. As a result, this should
be (a)
be made explicit in the paper, since it may affect whether a particular
project
can use DBC, and (b) should constrain the paper's authors from implying
otherwise.

> 
> Regads,
> Joachim

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Robert Dewar wrote:
> 
> Bertrand Meyer wrote
> 
> <<        !! Does this mean that the crash would automatically have
>         !! been avoided had the mission used a language and method
>         !! supporting built-in assertions and Design by Contract?
>         !! Although it is always risky to draw such after-the-fact
>         !! conclusions, the answer is probably yes:>>
> 
> Note that this conclusion is completely language independent. In particular
> the use of assertions is not language dependent. No method can possibly
> *rely* on having actual execution of assertions, since that just reduces
> you to relying on testing, but certainly execution of assertions is a
> helpful adjunct to testing, and certanly at the level that was needed in
> this case, any language can certainly implement runtime assertions.

If the arguments supplied in support of this argument were limited to
run-time execution of assertions, I would agree with this. However,
of the three arguments offered, only the first two are related to
execution. The third argument, considered the "most important" is
as follows:

"But most importantly the assertions are a prime component of the
software and its documentation ("short form", produced automatically
by tools). In an environment such as that of Ariane where there is so
much emphasis on quality control and thorough validation of everything,
they would be the QA team's primary focus of attention. Any team worth
its salt would have checked systematically that every call satisfies the
precondition. That would have immediately revealed that the Ariane 5
calling software did not meet the expectation of the Ariane 4 routines
that it called."

I believe Mr. Meyer considers this a critical distinction between
Eiffel and other languages such as Ada. The ability to document
assertions explicitly, and have them _read_ as part of the
_specification_, appears to be a prime consideration. Consider
this Ada example:

  package X is

    subtype Value is Float range 1.0 .. 100.0;

    procedure Update ( New_Value : in Value );

    Rate_Error : exception; -- raised when Update changes Contents by
more than 5%

  private

      Contents : Value := 1.0;

  end X;

As I understand it, the Eiffel way would be to define the
Rate_Error condition as an explicit constraint on the
Update operation, such as:

  update ( new_value : INTEGER ) is
  require
    abs ((contents - new_value) / contents) > 0.05
  do
    contents := new_value
  end

rather than relying on the comment associated with the exception
declaration. This equation would end up in the "short form"
version of this declaraion, making it more obvious as to the
nature of the assertion. I thought this was at least part of the
reason why Mr. Meyer stated that Eiffel and Sather were the only
languages that captured the spirit of Design by Contract. The role of
exceptions as documentation is emphasized in Mr. Meyer's Introduction
to Eiffel at www.eiffel.com:

"Run-time checking, however, is only one application of assertions,
whose role as design and documentation aids, as part of the theory
of Design by Contract, exerts a pervasive influence on the Eiffel
style of software development."

So, if Design by Contract includes the premise that assertions must
be documented in the specification (the "contract") in an explicit
manner, then I don't believe this claim can be made for most languages.
Certainly, declaring the name of the exception (Rate_Error, in this
case) could be argued as an equivalent, but I don't believe Mr. Meyer
would agree.

> 
> The main point is that a systematic design using Design by Contract would
> indeed probably have avoided the error. However, be careful not to conclude
> from this observation that Design by Contract somehow has something special
> to say in the Ariane case.
> 
> As has become painfully obvious in the aftermath, the Ariane 5 incident
> could have been avoided by any number of means, and almost any competent
> design approach, formal or informal, should have prevented this particular
> software error. Even in the absence of a systematic design approach,
> rigorous testing and/or common sense in approaching the design would have
> avoided the problem.

I agree. Moreover, it appears to me that the quoted statement claims
that
there is something special about Design by Contract, *in this particular
case*

> The Ariane 5 crash was spectacular, and therefore acts as a focus for
> discussion, but in fact it is not a particularly instructive example of
> a BIG BUG. On the contrary it was the kind of simple minded carelessness
> that plagues software, and can be reduced or eliminated without any
> very specialized techniques if you have competent people working in a
> reasonably systematic manner.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <333FD855.2781E494@digicomp.com>, Jan Galkowski
<jan@digicomp.com> writes

>But the problem is, unfortunately, many people who need to make a choice
>between taking a strong stand in favor of correctness and possibly putting
>their jobs on the line and just keeping quiet, doing what they are told, will
>opt for the latter.  This makes the job of the relative few who do want
>code to be right very much more difficult: Management says "How come
>you're the only one objecting...."
>
>I don't mean to imply what you say isn't valid: It is.  It's just the
>world of aerospace and military contracting is more complicated than that.



    Now, this sounds more like the ring of truth.


    What kind of pressures _were_ there on the Ariane 5 project?



                           --------



    Talking of Eiffel and Java (this title is cross posted to
clj.programmer), it also appears, to me at any rate, that "Contract"  --
If you present exactly _this_ I will do precicely _that_ with it --  is
*fundamental* to the construction of Object Technology.  It's always
irked me, that in C++ and Java, this is left outside the language, to be
said in the documentation.  Naturally, this happens only at the best of
times.  For Java, we're lucky; someone included a javadoc.  


    As a student in '96, doing my final year project, it drove me
absolutely barmy wondering what we, as users of AWT (Abstract Windowing
Toolkit), were *required* to do in order to get something to work:


        http://www.almide.demon.co.uk/html/Conio/Project/jam_023.html


    I note, wryly, that there are still "NullPointerException???"
letters regularly appearing in clj*, mostly revolving around AWT.


    On reading "Object Oriented Software Construction", by Bertrand
Meyer, ISBN 0-13-629031-0, (the older 1988 version) I realise that the
ability to specify the contract in the code, explicitly checking it at
run time, is a necessary, fundamental, ingredient for Object-Oriented
languages. 


    Heady stuff, that book.




Sandy

/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

> Pressure to meet a deadline should never result in the technial folks
> involved being willing to cut corners and deliver code with bugs.

My experience with customers has been that nothing mattered except 
getting the system delivered.
In the specific projects I'm working on it's even sensible that way. It 
is business programming with non-critical data, like sales personnel 
reports and similar stuff. The cost to get the bugs out of the system 
can surpass the cost of experiencing an occasional bug.
Depending on the type of bug, of course. I'm aware of one case where a 
report got lost due to a bug in badly-designed and 
less-than-thoroughly-tested software. The company may have lost a 
contract worth a few million ("may" because the company might not have 
gotten it anyway).

Regards,
Joachim

Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Ken Garlington wrote:

[Quoting the article by Jezequel and me:]
>!! But most importantly the assertions are a prime component of the
>!! software and its documentation ("short form", produced
>!! automatically by tools). In an environment such as that of
>!! Ariane where there is so much emphasis on quality control
>!! and thorough validation of everything, they would be the QA
>!! team's primary focus of attention. Any team worth
>!! its salt would have checked systematically that every call
>!! satisfies the precondition. That would have immediately
>!! revealed that the Ariane 5 calling software did not meet
>!! the expectation of the Ariane 4 routines that it called.

[Ken Garlington:] 
> I believe Mr. Meyer considers this a critical distinction between
> Eiffel and other languages such as Ada. The ability to document
> assertions explicitly, and have them _read_ as part of the
> _specification_, appears to be a prime consideration. 

Yes. It is a critical distinction.
  
> Certainly, declaring the name of the exception (Rate_Error, in this
> case) could be argued as an equivalent, but I don't believe Mr. Meyer
> would agree.

Well, yes and no. It's pursuing the same general goal, but
I would not call it an equivalent because
it's using very different techniques (a posteriori detection
of an abnormal case). I think the a priori technique, whenever
applicable, is much better. But that's partly a matter of opinion.

I find myself disagreeing less and less with the comments in the
tail end of this discussion - except perhaps for Robert Dewar's
mention that the Ariane 5 crash
 
>> is not a particularly instructive example of a BIG BUG

which strikes me as rather paradoxical (even in the full quotation
- read the original message). I think I understand Prof. Dewar's
point but a "BIG BUG" does not have to be a tricky, complicated
mistake having to do with an intellectually challenging issue.
It's big because of its consquences. Admittedly this is a matter
of how you define things, but contrary to him I think
this specific bug is indeed "particularly instructive" and
deserves to be examined in courses and textbooks, as well
as articles like ours.
 
-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: Papers on the Ariane-5 crash and Design by Contract

[Alexander Anderson]

In article <333FD855.2781E494@digicomp.com>, Jan Galkowski
<jan@digicomp.com> writes

>I heartily agree with you and have left a job because of management's
>willingness to ship such code over the objections of some technical
>people.  Worse, I can entirely understand how Ariane 5 happened if only
>because in the rush to get paid, contractors sometimes rush and shortcut
>systems acceptance tests, justifying their actions with rationales that are
>little more than handwaving and the equivalent of "Well, it worked on Ariane 
>4...."  
>
>But the problem is, unfortunately, many people who need to make a choice
>between taking a strong stand in favor of correctness and possibly putting
>their jobs on the line and just keeping quiet, doing what they are told, will
>opt for the latter.  This makes the job of the relative few who do want
>code to be right very much more difficult: Management says "How come
>you're the only one objecting...."
>
>I don't mean to imply what you say isn't valid: It is.  It's just the
>world of aerospace and military contracting is more complicated than that.



    On hearing sense like the above,  I've found myself going over the
Report again, listening to my guts, as it were.


    There are a number of points skirted around in the Inquiry Board's
Ariane 5 Failure Report, that are telling:



    (from 2.2 COMMENTS ON THE FAILURE SCENARIO)

        The reason for the three remaining variables, including
        the one denoting horizontal bias, being unprotected was
        that further reasoning indicated that they were either
        physically limited or that there was a large margin of
        safety, a reasoning which in the case of the variable BH
        turned out to be faulty. It is important to note that
        the decision to protect certain variables but not others
        was TAKEN JOINTLY BY PROJECT PARTNERS AT SEVERAL
            ********************************************
        CONTRACTUAL LEVELS.
        ******************


-- I'm sure there's a huge story lying beneath the surface of this last
legalese phrase --


    (from the FINDINGS)


        n) During design of the software of the inertial
           reference system used for Ariane 4 and Ariane 5,
           A DECISION WAS TAKEN that it was not necessary to
           ********************
           protect the inertial system computer from being
           made inoperative by an excessive value of the
           variable related to the horizontal velocity, a
           protection which was provided for several other
           variables of the alignment software. When taking
           this design decision, it was not analysed or fully
           understood which values this particular variable
           might assume when the alignment software was
           allowed to operate after lift-off.


        p) Ariane 5 has a high initial acceleration and a
           trajectory which leads to a build-up of
           horizontal velocity which is FIVE TIMES MORE
                                        ***************
           RAPID than for Ariane 4. The higher horizontal
           *****
           velocity of Ariane 5 generated, within the
           40-second timeframe, the excessive value which
           caused the inertial system computers to cease
           operation.


-- clearly, SOMEONE knew that there could just be problems
(theoretically) not far beyond the envelope, even on Ariane 4 then.
What was the nature of this variable, that could overflow if speeds (or
accelerations?) were only 5 times greater? --


        s) It would have been technically feasible to
           include almost the entire inertial reference
           system in the overall system simulations which
           were performed. FOR A NUMBER OF REASONS it was
                           ***********************
           decided to use the simulated output of the
           inertial reference system, not the system itself
           or its detailed simulation. Had the system been
           included, the failure could have been detected.



    (from the RECOMMENDATIONS)

            R9 Include external (to the project) participants
               when reviewing specifications, code and
               justification documents. Make sure that these
               reviews CONSIDER THE SUBSTANCE OF ARGUMENTS,
                       ***********************************
               rather than check that verifications have been
               made.



    These phrases, "A DECISION WAS TAKEN", "FOR A NUMBER OF REASONS",
and to make sure reviews "CONSIDER THE SUBSTANCE OF ARGUMENTS", suggest,
to me, a picture of a deeper malaise running through the history of the
project organisation.


    In other words, if you got people in private, you'd hear individual
professional worries over morale, over how things were being handled,
and they'd insist you kept them anonymous.  The last excerpt, R9, from
the recommendations, is to my mind, particularly telling.




Sandy

/*
--                                                          
//    Alexander Anderson  <sandy@almide.demon.co.uk>
//    Home Fone                 +44 (0) 171-794-4543
//    London, UK      http://www.almide.demon.co.uk/     
*/

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Joachim said

<<In the specific projects I'm working on it's even sensible that way. It
is business programming with non-critical data, like sales personnel
reports and similar stuff. The cost to get the bugs out of the system ...>>

To me, such an approach is never sensible. Look at the Y2K mess -- a perfect
example of the magnitude of trouble you can get into if you abandon an
emphasis on quality .... Yes, in the short run, it might make sense for
the supplier to cut corners, if all they are interested in is the bottom
line in the near future, but in the long run, for both consumers and the
vendors, this kind of short sightedness pays negative dividends.

Here is an interesting thought: The use of computers has added $x to the
aggregate bottom line of companies in the world. Assessing the magnitude
of x is difficult, but I think that, unlike the situation twenty years
ago, when some economists were not so sure, people generally agree that
the value of x is positive and substantial.

But ... could the cost of fixing the Y2K mess, including the cost of
ancilliary litigation associated with this mess, exceed x, and wipe out
the aggregate advantage (in a business sense) of computers counted over
their history so far???

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Alexander Anderson wrote:
> 
>     There are a number of points skirted around in the Inquiry Board's
> Ariane 5 Failure Report, that are telling:
> 
[several quotes from the report snipped]
> 
>     These phrases, "A DECISION WAS TAKEN", "FOR A NUMBER OF REASONS",
> and to make sure reviews "CONSIDER THE SUBSTANCE OF ARGUMENTS", suggest,
> to me, a picture of a deeper malaise running through the history of the
> project organisation.
> 
>     In other words, if you got people in private, you'd hear individual
> professional worries over morale, over how things were being handled,
> and they'd insist you kept them anonymous.  The last excerpt, R9, from
> the recommendations, is to my mind, particularly telling.

The report could be read that way; however, I think another
interpretation
is also possible:

First, the time frame is important when reading excerpts from the
report.
Several of the "decisions" cited appeared to occur during the original
development of the IRS for the Ariane 4. In that context, those
decisions
could be defended.

The report does note that the Ariane 5 has a significantly different
profile than the Ariane 4. However, it also appears that the
IRS *technical* team did not have access to that information:

"it is even more important to note that it was jointly agreed
not to include the Ariane 5 trajectory data in the SRI
requirements and specification."

I read this as a decision by *management* to leave out this information.
In past projects where I have seen this happen, it is usually
because the managers involved have a lot of systems experience,
but not much software experience. They are making what they consider
to be reasonable decisions based on their background. Unfortunately,
that oftentimes causes problems for systems which have transitioned
from hardware-intensive to software-intensive designs over the years -
such as inertial reference systems.

So, it may have been less a consideration of the technical team
being pressured to make a bad choice, and more of the management
team making a decision without the technical team even being
aware of it. Who knows?

> 
> Sandy
> 
> /*
> --
> //    Alexander Anderson  <sandy@almide.demon.co.uk>
> //    Home Fone                 +44 (0) 171-794-4543
> //    London, UK      http://www.almide.demon.co.uk/
> */

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Gavin Collings]

-- 
Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote  > The class
EXCEPTION with several subclasses does exist as part of the 
> standard libraries. Exception handlers can decide what to do based on the

> run-time class of the exception. This facility does not seem to be in 
> wide-spread use, but it's all there.

Good.  The main point about the Java model, though, is that the compiler
checks that the programmer has at least thought about handling all
exceptions that may be generated in nested calls.  This means that the
programmer HAS to think about dealing with error conditions.  So, in the
Ariane case, if the precondition existed (as some say it did) the compiler
would have given warnings to the effect that it IF the error occurred, it
would NOT have been handled.  Wouldn't this have made the disaster less
likely?

Gavin.

Re: Papers on the Ariane-5 crash and Design by Contract

[Adrian B.Y. Hoe]

> ------------------------------
>
> Date:    Sat, 29 Mar 1997 17:04:50 GMT
> From:    the one and only real true kibo <kibo@DHP.COM>
> Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On 27 Mar 1997 00:06:39 -0500 in article <dewar.859439125@merv> posted to
> comp.lang.eiffel, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> > Ray said
>
> > <<Finally!  Thank you, sir.  It was obvious from reading the report that
> > was pointed out several months ago by a post in this newsgroup that this
> > was a wonderful example of a failure WAY early in the lifecycle.  It had
> > nothing to do with design or construction and everything to do with a
> > bogus specification.  They were in effect designing a control system for
> > a completely different rocket than the one in which the system was used!>>
>
> > Indeed, and in such a case, tightening up the methodology for encoding the
> > specification is not likely to be helpful. It can even be harmful if it
> > results in diverting effort into a non-useful area!
>



> Fuckhead.
>
> I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
> Finger me for my PGP public key. Check out my home page for the coolest
> way to vote on new newsgroup proposals or to issue Usenet cancels.




Alright, this is too much. Where is this uneducated arrogant moron coming
from???


GET OUT!!!





>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBMz1LsqlPvImbzLKZAQFJgwQAkl4Rwjj558h1Rlw/ZtnvEgYudMFlNuLU
> +SqyrMF/9mg5LdsAzEdH9kMqhmFdY89QZj4BY1bxsg3NtIipq94NZ73Z0x7uSZb9
> gajFwUyK2BZC5+/iW9j54isZWL4jc45D5vlf8j2oxxzyKyLreo2fJdo7yAYOrBat
> q+AhPlVx5sM=
> =XOtl
> -----END PGP SIGNATURE-----
>
> ------------------------------
>
> Date:    Sat, 29 Mar 1997 17:06:17 GMT
> From:    the one and only real true kibo <kibo@DHP.COM>
> Subject: Re: Papers on the Ariane-5 crash and Design by Contract
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On 26 Mar 1997 17:13:20 -0500 in article <dewar.859414225@merv> posted to
> comp.lang.eiffel, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> > <<I guess i made a dangerous generalization there. I've been instinctively
> > appliying programming-by-contract tecniques for the 15 years i've been
> > programming professionally - imperfectly, ofcourse. I've gathered and
> > developed tools and techniques slowly along the way, and am still
> > learning.>>
>
> > Sure, but virtually everyone has been instincitively applying at least
> > some of the basic idea of programming-by-contract for ever and ever amen.
> > The basic idea here is nothing new, and indeed is obvious.
>
> > What is significant about programming by contract is *precisely* the
> > activity of formalizing it and embodying it into fixed syntax (even that
> > idea is by no means new, Eiffel did not invent this idea, and I am sure
> > that Bertrand Meyer would not claim otherwise -- what Eiffel did was to
> > make it a centerpiece of the design, and that is indeed interesting!)
>
> Who cares what Bertrand Meyer claims - he's a well-known liar and
> a crook.  Anything Bertrand Meyer claims has got to be a fucking lie.
>
> I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.
> Finger me for my PGP public key. Check out my home page for the coolest
> way to vote on new newsgroup proposals or to issue Usenet cancels.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBMz1MCalPvImbzLKZAQGWfgP9FOd+wiUm2JNpLobEBvbkne1BpDpeyc83
> +L8DcCyUHSYO2inB3vFtOOkK8rDL1CqRsrCQZnR8yIdDXd+Em4SkGRQyreyooW2R
> zIzB9X6n34gGfhZI0JyABcwuu1T34q3UtrDFDZwZz0+oQMmBUOC2tM5xLXcyEDn3
> 8Jhx7Lp5YAs=
> =E+R3
> -----END PGP SIGNATURE-----
--

B.Y.




>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Adrian, B.Y. Hoe   VP, Business Development   Email : byHoe@quantum.pc.my

                                     \/       Lexical Integration (M) Sdn Bhd
                                   \/  \/     13-B Jln Pandan Indah 4/2
                                 \/  \/  \/   Pandan Indah
                                   \/  \/     55100 Kuala Lumpur
                                     \/       Malaysia

                                              Tel   : +60 3 495 4048
                                              Fax   : +60 3 495 4037
                                              Email : system@quantum.pc.my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
                                              member of Team-Ada in Malaysia

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <01bc4021$607eea80$b280400a@gavinspc> "Gavin Collings" <gcollings@sperry-sun.com> writes:

  > Good.  The main point about the Java model, though, is that the compiler
  > checks that the programmer has at least thought about handling all
  > exceptions that may be generated in nested calls.  This means that the
  > programmer HAS to think about dealing with error conditions.

  > So, in the Ariane case, if the precondition existed (as some say it did)

  It did.

  > the compiler would have given warnings to the effect that it IF
  > the error occurred, it would NOT have been handled.

     Not quite, the warning that the developers were presented with
was that if this exception occured it would be handled by a non-local
(default) handler.  There were no "unhandled" exceptions as such.

  > Wouldn't this have made the disaster less likely?

    Hardly.  The message that the Ariane 4 developers got was VERY
clear.  If this happens, rocket crashes.  Well actually it was
apparently more of a list of conditions under which the guidance
system would shut itself down and spew failure diagnostics to the
ground systems.  But I don't get the impression that anyone thought
this meant anything other than rocket crashes here.

    Of a list of seven such occurances, local handlers were added for
either four or five.  The others, including this one, were determined
to be physically impossible. (Unless, of course, you put the guidance
system in a different rocket--or launched from a different planet.)

    This is the point that Robert Dewar, Ken and myself I have been
emphasizing again and again--there was no error in software
development (for the Ariane 4), and ANY reasonable approach to reuse
would have found the potential problems.  Remember the actual failure
sequence involved deflecting the engines beyond the acceptable
stresses for the Ariane 5, which were apparently less than for the
rocket the system was designed for.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Gavin Collings wrote:
> 
> --
> Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote  > The class
> EXCEPTION with several subclasses does exist as part of the
> > standard libraries. Exception handlers can decide what to do based on the
> 
> > run-time class of the exception. This facility does not seem to be in
> > wide-spread use, but it's all there.
> 
> Good.  The main point about the Java model, though, is that the compiler
> checks that the programmer has at least thought about handling all
> exceptions that may be generated in nested calls.  This means that the
> programmer HAS to think about dealing with error conditions.  So, in the
> Ariane case, if the precondition existed (as some say it did) the compiler
> would have given warnings to the effect that it IF the error occurred, it
> would NOT have been handled.  Wouldn't this have made the disaster less
> likely?

No, for two reasons:

1. There was a top-level hander for exceptions. So, it was handled, just
   not in the proper manner.

2. The development team had already decided that the exception would not
   occur in practice, and so would have discounted the warning.

Both of these are noted in the final report.

If the software had been recompiled when reused for the Ariane 5,
it might have helped (although there are other aspects of this
incident that would probably have defeated this feature). However,
there's no evidence in the final report that it was recompiled.
The report implies that the total system was reused as a "black box."

> 
> Gavin.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Martin Tom Brown]

In article <dewar.859999362@merv> dewar@merv.cs.nyu.edu "Robert Dewar" writes:

> Joachim said
> 
> <<In the specific projects I'm working on it's even sensible that way. It
> is business programming with non-critical data, like sales personnel
> reports and similar stuff. The cost to get the bugs out of the system ...>>
> 
> To me, such an approach is never sensible. Look at the Y2K mess -- a perfect
> example of the magnitude of trouble you can get into if you abandon an
> emphasis on quality .... Yes, in the short run, it might make sense for
> the supplier to cut corners, if all they are interested in is the bottom
> line in the near future, but in the long run, for both consumers and the
> vendors, this kind of short sightedness pays negative dividends.

Part of the problem is that in commercial work the company can get paid
to put the bugs in, and then to "maintain" the system by taking them out.
Rush jobs tend to create more long term expense, but a shorter time to
market and a quick return on investment. They get what they pay for.
 
Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Papers on the Ariane-5 crash and Design by Contract

[Robin Rosenberg]

"Gavin Collings" <gcollings@sperry-sun.com> writes:
[...]
> Good.  The main point about the Java model, though, is that the compiler
> checks that the programmer has at least thought about handling all
> exceptions that may be generated in nested calls.  This means that the
> programmer HAS to think about dealing with error conditions.  So, in the
> Ariane case, if the precondition existed (as some say it did) the compiler
> would have given warnings to the effect that it IF the error occurred, it
> would NOT have been handled.  Wouldn't this have made the disaster less
> likely?

In this paricular case: No. A special case in Java is the exception class
RunTimeException which you don't have to handle or declare.

> Gavin.

-- 
Robin Rosenberg,  | Voice: +46-8-7036200 | "Any opinions are my own, etc. etc."
Enator Objective  | Fax:  (+46-8-7036283)|      <this line left blank>
Management AB     | Mail:  rrg@funsys.se | 

Re: Papers on the Ariane-5 crash and Design by Contract

[Chris Beer]

Robert I. Eachus wrote:

>
>    This is the point that Robert Dewar, Ken and myself I have been
>emphasizing again and again--there was no error in software
>development (for the Ariane 4), and ANY reasonable approach to reuse
>would have found the potential problems. 

Agreed.

> Remember the actual failure
>sequence involved deflecting the engines beyond the acceptable
>stresses for the Ariane 5, which were apparently less than for the
>rocket the system was designed for.
>

Remember that the flight control software, not the Inertial Navigation System 
software, was attempting to steer the vehicle with a 'non-real' problem, i.e. the 
measured data it was receiving (from both INS) was (identically) false. If the 
problem had been real, i.e. a gust of wind, or a propulsion problem, then such 
engine deflections would be perfectly acceptable if maintaining the vehicle with 
minimum (zero) incidence. 

There is no criticism in the 501 report of the requested engine deflections.

Chris Beer
Opinions are my own...etc..

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Robert I. Eachus wrote:
>     This is the point that Robert Dewar, Ken and myself I have been
> emphasizing again and again--there was no error in software
> development (for the Ariane 4), and ANY reasonable approach to reuse
> would have found the potential problems.

I'll go along with the first half of this statement, but I'm not
sure about the second. If I had to state my position in one
sentence, it would be:

"Methodologies that assume reuse at the software module level
work poorly when the entire hardware-software system is reused
(and vice versa)."

> 
>                                         Robert I. Eachus
> 
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Derek Clarke]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:
>In article <01bc4021$607eea80$b280400a@gavinspc> "Gavin Collings" <gcollings@sperry-sun.com> writes:
>
>  > Good.  The main point about the Java model, though, is that the compiler
>  > checks that the programmer has at least thought about handling all
>  > exceptions that may be generated in nested calls.  This means that the
>  > programmer HAS to think about dealing with error conditions.
>
>  > So, in the Ariane case, if the precondition existed (as some say it did)
>
>  It did.
Yep.
>
>  > the compiler would have given warnings to the effect that it IF
>  > the error occurred, it would NOT have been handled.
>
>     Not quite, the warning that the developers were presented with
>was that if this exception occured it would be handled by a non-local
>(default) handler.  There were no "unhandled" exceptions as such.
In the sense that the microprocessor executing the instructions hit a 
floating point exception that wasn't covered by the language system.

I'd tend to call that an unhandled exception. 
>
>  > Wouldn't this have made the disaster less likely?
>
>    Hardly.  The message that the Ariane 4 developers got was VERY
>clear.  If this happens, rocket crashes.  
Not true. The message was actually "We don't care about what happens 
because this can situation can never arise".

That was true for Ariane 4.

Well actually it was
>apparently more of a list of conditions under which the guidance
>system would shut itself down and spew failure diagnostics to the
>ground systems.  But I don't get the impression that anyone thought
>this meant anything other than rocket crashes here.
If they seriously believed the situation could arise, they would have 
properly covered (_not_ handled necessarily) the exception. They 
certainly didn't plan on their bit making the launcher blow up.

>
>    Of a list of seven such occurances, local handlers were added for
>either four or five.  The others, including this one, were determined
>to be physically impossible. (Unless, of course, you put the guidance
>system in a different rocket--or launched from a different planet.)
Not _physically possible_. The exceptions weren't covered for efficiency 
reasons. Instead of looking at some way of handling the problem more 
sophisticated than "shall I include this automatic feature or not"...

>    This is the point that Robert Dewar, Ken and myself I have been
>emphasizing again and again--there was no error in software
>development (for the Ariane 4), 
Although I'm rather dubious about the treatment of floating-point 
exceptions as "hardware errors". 

>and ANY reasonable approach to reuse
>would have found the potential problems.  
Only if the re-use specification of the hardware unit had included the 
maximum horizontal velocity that the unit should be subjected to. Can you 
see the likelihood of that popping out of an Eiffel compiler? I can't... 

Remember the actual failure
>sequence involved deflecting the engines beyond the acceptable
>stresses for the Ariane 5, which were apparently less than for the
>rocket the system was designed for.
If Ariane 4 had followed the same flight profile on a launch, it too 
would have broken up.

All liquid-fuel launchers are pressurised tubes of very low wall 
thickness, and none of them could take that abuse!

The biggest bug was surely the flight controller interpreting the 
diagnostic data put on the bus by the crashed SRI(s) as real flight data, 
and swivelling the rockets to suit.

Given the fact the the SRI(s) weren't needed in flight anyway, if the 
flight controller had been able to ignore the rubbish, all would have 
been sweetness and light.

And possibly SRI(s) would harmlessly crash on every other Ariane 5 flight 
thereafter... 

Re: Papers on the Ariane-5 crash and Design by Contract

[Derek Clarke]

Ken Garlington <GarlingtonKE@lmtas.lmco.com> wrote:
>
>If the software had been recompiled when reused for the Ariane 5,
>it might have helped (although there are other aspects of this
>incident that would probably have defeated this feature). However,
>there's no evidence in the final report that it was recompiled.
>The report implies that the total system was reused as a "black box."
This wouldn't have made the slightest difference.

The failure was a floating-point-to-integer conversion exception caused 
by a velocity sensor reporting real horizontal velocities. No amount of 
recompiling the code would change that!

The "total system" was re-used as a black box because it _was_. Literally 
a completely different box to the flight control system that interpreted 
post-crash diagnostics as real data.

Re: Papers on the Ariane-5 crash and Design by Contract

[Derek Clarke]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
<snip>
>But ... could the cost of fixing the Y2K mess, including the cost of
>ancilliary litigation associated with this mess, exceed x, and wipe out
>the aggregate advantage (in a business sense) of computers counted over
>their history so far???
Personally I don't regard the cracking of Enigma and therefore saving 
thousands of Allied lives as an advantage wiped out by Y2K costs...

That's the first year of computer history dealt with - need I go on?

The wholly economic argument that computers save money overall is 
probably wrong. It's the spot savings that make the difference. 

Re: Papers on the Ariane-5 crash and Design by Contract

[Derek Clarke]

"Gavin Collings" <gcollings@sperry-sun.com> wrote:
>-- 
>Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote  > The class
>EXCEPTION with several subclasses does exist as part of the 
>> standard libraries. Exception handlers can decide what to do based on the
>
>> run-time class of the exception. This facility does not seem to be in 
>> wide-spread use, but it's all there.
>
>Good.  The main point about the Java model, though, is that the compiler
>checks that the programmer has at least thought about handling all
>exceptions that may be generated in nested calls.  This means that the
>programmer HAS to think about dealing with error conditions.  So, in the
>Ariane case, if the precondition existed (as some say it did) the compiler
>would have given warnings to the effect that it IF the error occurred, it
>would NOT have been handled.  Wouldn't this have made the disaster less
>likely?
No, no and thrice no!

The Ariane 4 software people _knew_ about this possibility. They made the 
judgement call that this particular floating-point to integer conversion 
would never exceed the integer range and cause an exception because the 
velocity reading that produced the floating-point value would never 
exceed the danger value in the real (Ariane 4) environment.

Whether or not you agree with leaving exceptions unhandled on efficiency 
grounds, that was a genuine engineering decision in the light of all 
available evidence.

Some long time following this judgement call, which was carefully 
documented , passed by several committees, and generally inspected to 
death, someone in the _management_ structure of the _Ariane 5_ project 
decided not to test the assumptions built into the unit concerned by 
denying the technical team for Ariane 5 access to data of the projected 
flight profile for the new launcher.

No number of language features would get around this dumbass move.

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Ken said

<<"Methodologies that assume reuse at the software module level
work poorly when the entire hardware-software system is reused
(and vice versa).">>

This seems like a very nice insight. As soon as I read it, I reacted,
"yes, that makes a lot of sense", and I have not seen this principle
clearly enunciated before ...

Re: Papers on the Ariane-5 crash and Design by Contract

[Jonathan Egre']

In article <dewar.859999362@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Joachim said
>
><<In the specific projects I'm working on it's even sensible that way. It
>is business programming with non-critical data, like sales personnel
>reports and similar stuff. The cost to get the bugs out of the system ...>>
>
>To me, such an approach is never sensible. Look at the Y2K mess -- a perfect
>example of the magnitude of trouble you can get into if you abandon an
>emphasis on quality .... Yes, in the short run, it might make sense for
>the supplier to cut corners, if all they are interested in is the bottom
>line in the near future, but in the long run, for both consumers and the
>vendors, this kind of short sightedness pays negative dividends.

I've heard at least one other person claim that if you add up the cost
of saving 2 bytes per date across millions of instances, multiply by the
much higher cost of data storage in the past, and allow for inflation,
then the amount saved is actually more than the cost of solving the year
2000 crisis.

How far do you think that an aircraft engineer would get with a proposal
to increase safety and efficiency at a cost of "only" 10% more weight?
That's the difference between an aircraft flying and an aircraft failing
to take off.  Sometimes you just have to work within a short-term budget,
and make the best choices you can under the circumstances.

I'm not saying that we should not strive for higher quality.  I am saying
that to blame the mistakes we see now on a lack of attention to quality
is not a fair assessment of the choices that were realistically available
at the time.
-- 
Jonathan Egre' at Jobstream Group plc in Cambridge, UK 
The above does not represent the opinions or policies of Jobstream Group plc 

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Roberts]

Add kibo to your killfile. Nick.

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Jonathan said

<<I've heard at least one other person claim that if you add up the cost
of saving 2 bytes per date across millions of instances, multiply by the
much higher cost of data storage in the past, and allow for inflation,
then the amount saved is actually more than the cost of solving the year
2000 crisis.
>.

  Claims like this are almost always just guesses that have been passed
  on, and because they appeal to the hearer (as in this case :-) they
  get passed on further. This particular one is nonsense. Just do the
  calculations yourself very roughly and you will see.

<<How far do you think that an aircraft engineer would get with a proposal
to increase safety and efficiency at a cost of "only" 10% more weight?
That's the difference between an aircraft flying and an aircraft failing
to take off.  Sometimes you just have to work within a short-term budget,
and make the best choices you can under the circumstances.
>>

  I sure don't think that that engineer would be treated kindly when he
  had to explain that the reason that a plane fell out of the sky and
  killed x hundred people was to save 10% of the weight so that more
  passengers could be carried.

  Again, this 10% of the weight figure is pulled out of thin air. Care in
  software usually weighs nothing. Often carefully written and safer software
  can be shorter than carelessly written unsafe software.

  Actually talking about the weigh of the software reminds me of the old
  story (fact? urban legend? who knows, perhaps the appropriate urban legend
  www site knows). The story goes that on an early NASA mission, the engineer
  in terms of the weight control demanded to know the weight of the software.
  He would not take for an answer that it had no weight and demanded to see
  it. Finally he was shown a deck of punched cards. "Ah ha!" he said, "see,
  I knew it had to weigh something". The software engineer replied: "You
  don't understand, the software is the *holes* punched into these cards :-)

P.S. rumours can often be turned into fact due to wishful thinking. Try 
starting a rumour based on a completely bogus fact, and present it to 
someone to whom it will appeal. For example, tell an environmentalist
"Did you know -- 24% of the volume in land wastes is taken up by
non-degradable plastic!". Or tell someone of suitable political
persuasion "Did you know the Russians are building ICBMS faster than
ever, and that now they have three times as many deployed than the
time when communism supposedly disappeared", or or or or [[make up
your own attractive pseudo-fact here]] :-)

Re: Papers on the Ariane-5 crash and Design by Contract

[Robert Dewar]

Derek said to Colin

<<
>Good.  The main point about the Java model, though, is that the compiler
>checks that the programmer has at least thought about handling all
>exceptions that may be generated in nested calls.  This means that the
>programmer HAS to think about dealing with error conditions.  So, in the
>Ariane case, if the precondition existed (as some say it did) the compiler
>would have given warnings to the effect that it IF the error occurred, it
>would NOT have been handled.  Wouldn't this have made the disaster less
>likely?
No, no and thrice no!
>>

In fact it is even worse. If there had been systematic assertions in the
code, then the assertion that the exception could not possibly arise would
have been explicitly built into the software. The assertion, if implemented
by runtime code, would of course have failed, but this would have been
functionally equivalent to the runtime check that *did* fail.

But the source code would have had a very explicit, rather formal looking,
gizmo that would have acted to reassure any software person looking over
the code. One can imagine the following scenario.

"Hey Joe, can't this conversion raise an exception, and as far as I can
 see that would be disastrous."

"Well look at the assertion, I guess the hardware guys know what they are
 talking about". ...

I have seen a number of cases where formalizing error checking, and in
particular doing runtime checking have caused problems that would not
otherwise be there. Overall, runtime checking is a clear win, but it
does have a bit of a dark side, as the Ariane experience showed, and it
means that software folks have to be VERY sure that this dark side is
properly dealt with, particularly in the context of reuse, where all
assumptions, big and small, explicit and implicit, must be carefully
revisited.

I know it is very tempting when a giant bug occurs with the software
written in language X, for all the (not X) advocates to crowd around
and see whether their language would have "prevented" the error. Ada
folks can't complain too much about this phenomenon, since it has 
happened the other way round often enough ...

Still, often it turns out that the bug is not really language related
at all, as in the Ariane case. It may teach us something about software
process, and about reuse strategies, but in this particular case we
do not learn much about programming language design.

Re: Papers on the Ariane-5 crash and Design by Contract

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.860336303@merv>...
[...]
>   Actually talking about the weigh of the software reminds me of the old
>   story (fact? urban legend? who knows, perhaps the appropriate urban
legend
>   www site knows). The story goes that on an early NASA mission, the
engineer
>   in terms of the weight control demanded to know the weight of the
software.
>   He would not take for an answer that it had no weight and demanded to
see
>   it. Finally he was shown a deck of punched cards. "Ah ha!" he said,
"see,
>   I knew it had to weigh something". The software engineer replied: "You
>   don't understand, the software is the *holes* punched into these cards
:-)
[...]


Presumably the software actually weighed _less_ than nothing, then!
Nick :-}

Re: Papers on the Ariane-5 crash and Design by Contract

[Doctorb]

the one and only real true kibo <kibo@dhp.com> writes:

>Fuckhead.

>I am the only true <A HREF="http://www.dhp.com/~kibo">Kibo</A>.

Then post something funny, you gimp.

>Finger me for my PGP public key. 

Finger this.

>Check out my home page for the coolest
>way to vote on new newsgroup proposals or to issue Usenet cancels.

Bite me.

Yeah, that's right.  <A HREF="http://www.me.org/~bite">BITE ME</A>.

Re: Papers on the Ariane-5 crash and Design by Contract

[Joachim Durchholz]

> I think you would
> agree that if C++, for example, were modified sufficiently to meet the
> "spirit"
> of Design by Contract, it would no longer be C++, but another language.

Sorry I wouldn't. C++ has been evolving since its definition. Adding 
design-by-contract style assertions would not change the language into 
something totally different. It would only make C++ less of a punching-ball 
for those who want to have a bad language to contrast against their 
favourite language...

> So,
> a programmer writing in C++ would still not have a language that would
> be
> sufficient.

Of course there are lots of weaknesses beyond lack of DBC in C++, many of 
them so intimately part of the language that it's impossible to remove them. 
It's just that adding programming-by-contract to C++ would not be a 
problem.

Regards,
Joachim

Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Robert Dewar wrote:
> 
> Overall, runtime checking is a clear win, but it
> does have a bit of a dark side, as the Ariane experience showed, and it
> means that software folks have to be VERY sure that this dark side is
> properly dealt with, particularly in the context of reuse, where all
> assumptions, big and small, explicit and implicit, must be carefully
> revisited.

I do think that this is one good language-related lesson from Ariane:
that exceptions are not a magic wand with respect to safety. In fact,
as I've said in the past, I think there are several aspects of the
use (and suppression) of exceptions that need to be more publicly
discussed.

I think there are more important lessons here, but this is certainly
one that can be applied to software design methodology.

> I know it is very tempting when a giant bug occurs with the software
> written in language X, for all the (not X) advocates to crowd around
> and see whether their language would have "prevented" the error. Ada
> folks can't complain too much about this phenomenon, since it has
> happened the other way round often enough ...

And I have objected when Ada advocates have overstated the case
for our language, for some of the same reasons I objected to claims
made about DBC/Eiffel. (Patting myself on the back, which is not as
satisfying as I'd hoped because of the sunburn :)

> Still, often it turns out that the bug is not really language related
> at all, as in the Ariane case. It may teach us something about software
> process, and about reuse strategies, but in this particular case we
> do not learn much about programming language design.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Ron Crocker]

In article <332F6411.4261@arlington.net>,
Ray McVay  <bmcvay@arlington.net> wrote:
>John McCabe wrote:
>> 
>> Bertrand Meyer <bertrand@eiffel.com> wrote:
>> 
>> >The real problem was that the assertion was not part of the software.
>> 
>> No - the real problem was that the developers were _not_ provided with
>> Ariane 5 trajectory information which should have been used in the
>> analysis.
>> 
>> Best Regards
>> John McCabe <john@assen.demon.co.uk>
>
>Finally!  Thank you, sir.  It was obvious from reading the report that
>was pointed out several months ago by a post in this newsgroup that this
>was a wonderful example of a failure WAY early in the lifecycle.  It had
>nothing to do with design or construction and everything to do with a
>bogus specification.  They were in effect designing a control system for
>a completely different rocket than the one in which the system was
used!

I heard this the other day:
	All the really important mistakes are made the first day.

I don't know who to attribute it to, but it is once again applicable.


-- 
Ron Crocker
Motorola Cellular Infrastructure Group
(847) 632-4752 [FAX: (847) 632-6064]
crocker@mot.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Gavin Collings]

This is really a reply to all the messages that have been posted in
response to my Java exception model post (most of which disagree with me).

As many have pointed out this probably would not have averted the disaster.
 However my original claim was only that it would make it less likely
(which I still believe - the degree being a matter for debate).  Let me
deal with the main objections one by one :-

1) I take the point that the programmers knew that the unhandled exception
existed but still maintain that explicit warnings on every build may have
helped raise its visibility as a potential problem.

2) I take the point that a Java compiler may not have reported the error
since these particular types of exceptions may go unchecked in Java.  I am
only proposing something LIKE Java - not Java.

3) Someone said that the exception would be handled by a "top-level"
handler so it would not be reported.  I take this as splitting hairs to a
fine degree - after all what is an unhandled exception: one that propagates
to some default handler - within the language runtime or within the
operating system - what's the difference.  I don't believe that this should
prevent the compiler issuing a warning.


Finally, I am not fighting you when you say that the Ariane disaster was
mainly caused by something else - untested assumptions, hardware shutdown
on software failure... nor am I trying to enter into any language war
(other than to make general points about features).  I am merely focusing
on one particular aspect which might help improve software quality
generally (including the Ariane case).

My view of the contemporary use of exception handling is that its something
like relying on the FORTRAN first letter rule for type checking and I
believe the more that a compiler can help you the better.  Indeed the
analogy may be strong - if you regard the exceptions that a routine may
throw as part of its type then all I am really asking for more stricter
type checking.

Gavin.
-- 
Gavin Collings
gcollings@sperry-sun.com

Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Riehle]

 Bertrand Meyer <bertrand@eiffel.com> wrote:
>  
> The real problem was that the assertion was not part of the software.

  Probably not true.

  1) It is possible to incorrectly formulate an assertion.

  2) Assertions based on incorrect assumptions are also incorrect. 

  3) The engineers on Ariane V made fundamentally incorrect assumptions.

  4) Even if they had used some mechanism for including assertions in the
     software, those assertions would have been incorrect.  

  Richard Riehle