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!

Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <dewar.858568071@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>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!

I agree with Robert Dewar.
Please do not start a language war! It is made crystal clear in the paper that 
*THIS IS NOT A LANGUAGE PROBLEM*
let me repeat it in case it is not clear:
*THIS IS NOT A LANGUAGE PROBLEM*

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.

I'm willing to discuss this last point, but I will not answer any language issue
in this thread.

Best regards,

-- 
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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Irvine]

Jean-Marc Jezequel wrote:
> 
> 
> I agree with Robert Dewar.
> Please do not start a language war! It is made crystal clear in the paper that
> *THIS IS NOT A LANGUAGE PROBLEM*
> let me repeat it in case it is not clear:
> *THIS IS NOT A LANGUAGE PROBLEM*
> 
> 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.
> 

Maybe a 'language war' was not intended, but in which case it's a pity
that some people cannot resist the opportunity to grind their own axe -
I refer to Bertrand Meyer's follow-up to your article:

'What software managers must understand is that Design by Contract is
not a
 pie-in-the-sky approach for special, expensive projects. It is a
pragmatic
 set of techniques available from several commercial and public-domain
Eiffel
 sources and applicable to any project, large or small.'

Re: Ariane-5: can you clarify? (Re: Please do not start a language war

[Roedy Green]

nouser wrote:
>I agree with Robert Dewar.  Please do not start a language war! It
>   is made crystal clear in the paper that *THIS IS NOT A LANGUAGE
>   PROBLEM*

go ahead and fight, but please do the Java part of it in
comp.lang.java.advocacy.
rather than comp.lang.java.tech.

Roedy Green               Roedy rhymes with Cody   roedy@bix.com
Canadian Mind Products    contract programming     (250) 285-2954 
POB 707 Quathiaski Cove   Quadra Island BC         Canada V0P 1N0 
http://oberon.ark.com/~roedy for CMP utilities and the Java glossary
-30-

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Gavin Collings]

> There are multiple ways of reducing the probability of a catastrophic
> software defect like Ariane 5.  Two of them are the following.
> (1) You can test more, enable runtime checks, and implement multiple
> levels of exception handling and recovery.  (2) You can adopt a Design
> by Contract methodology.

(3) You can assume that no matter how much testing you do
and even if you use design by contract to its full potential that
some errors still exist in the software.  So no such exception
should be treated as fatal.

Quoting an earlier reply :-

> There was a high-level policy in the Arianne programme that any
> exception should cause the shutdown of whatever unit of hardware it
> occurred in.  The assumption seems to have been that the software was
> perfect, and so any exception must indicate a hardware flaw.

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

Don't get me wrong - design by contract is a useful and necessary 
concept for the development of reliable software. BUT we should
always remember that contracts CAN and WILL be broken
Two decisions seem to have gone against this realisation: (1) The
decision to run identical software on the backup computer - if
the software contains errors - this is not a backup at all;  (2) To
treat the software as intrinsically more reliable than the hardware
seems to go against all experience and indeed against common
sense.

The corollary to this second point - allowing an exception to propagate
to the extent of crashing the entire system seems to be the grossest
possible violation of the principle of loose coupling between modules!
This is the light in which I would view the comments in the original
article and in this area Eiffel does indeed have a valuable contribution
to make.  That of eliminating the half-hearted approach to exception
handling which is all to common in the industry.

-- 
Gavin Collings
gcollings@sperry-sun.com

P.S. I used to work on Ariane 4.

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> Please do not start a language war! It is made crystal clear in the paper that
> *THIS IS NOT A LANGUAGE PROBLEM*
> let me repeat it in case it is not clear:
> *THIS IS NOT A LANGUAGE PROBLEM*

It is certainly *NOT* clear in Mr. Meyer's IEEE article that this is not
a language issue.
He asserts repeatedly that the use of Eiffel constructs would have
solved the issue.

> 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.
> 
> I'm willing to discuss this last point, but I will not answer any language issue
> in this thread.

Regarding this last point: It is absolutely not sufficient to specify
the specification of
the components precisely. It is also required that the assumptions about
the environment
in which the component is (re)used be thoroughly analyzed, and that the
results of that
analysis be confirmed by test.

In the case of the Ariane V, assume that the most excruciatingly correct
specification was
given for the module, making it clear that it would fail when given a
certain range of inputs.
The Ariane V would still have crashed, because:

   1. No one on the design team expected the invalid inputs to occur (if
they did, they
      would have added back the Ada check that would have detected the
problem). This is
      not uncommon; oftentimes, the team developing a particular
component in a large
      distributed system like a missile does not have the "big picture"
regarding the
      vehicle's flight characteristics. They are working to a
specification developed by
      a prime contractor, which may not contain a full description of
the flight envelope
      (in some cases, because that envelope is also being changed over
time).

   2. No one ran a full integration test with realistic flight data,
which would have
      alerted them to the mistake made in #1. Particularly for a
distributed mission-
      critical system, this should be considered an absolute
requirement.

Although I like some of Mr. Meyer's columns, I found this particular
column not only wrong,
but dangerous, since it continues the trend of denigrating sound test
strategy and common
sense system engineering in favor of a software-centric approach. (There
is a recent article by
Boris Beizer regarding the Cleanroom approach that makes this point
better than I can.)

> 
> Best regards,
> 
> --
> 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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:

>   2. No one ran a full integration test with realistic flight data,
>which would have
>      alerted them to the mistake made in #1. Particularly for a
>distributed mission-
>      critical system, this should be considered an absolute
>requirement.

Yes, this is true. But you have to understand that the mere design of the SRI
made it very difficult to test it in an other way that performing a launch.
This is because of the tight integration of hard-to-fool hardware with software
in a black box functional unit. What can be your test strategy for a black box
containing an inertial central? If the software had been designed with less coupling
on this particular hardware, you could have test the software vs. a simulation of the
hardware and its environment. Here, the launch was the test.


>Although I like some of Mr. Meyer's columns, I found this particular
>column not only wrong,
>but dangerous, since it continues the trend of denigrating sound test
>strategy and common
>sense system engineering in favor of a software-centric approach. 

I don't see where it denigrates sound testing. IMHO, sound testing *is* needed.
And testing is effective only if you have a sound test strategy.
Even more when you use programming by contract. In the paper,
we just recall that you cannot rely on tests only.


-- 
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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Richard Kaiser]

In article <5go8nk$ngf$1@news.irisa.fr>, jezequel@irisa.fr (Jean-Marc Jezequel) wrote:


>In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington
> <GarlingtonKE@lmtas.lmco.com> writes:
>
>>   2. No one ran a full integration test with realistic flight data,
>>which would have
>>      alerted them to the mistake made in #1. Particularly for a
>>distributed mission-
>>      critical system, this should be considered an absolute
>>requirement.
>
>Yes, this is true. But you have to understand that the mere design of the SRI
>made it very difficult to test it in an other way that performing a launch.
>This is because of the tight integration of hard-to-fool hardware with software
>in a black box functional unit. What can be your test strategy for a black box
>containing an inertial central? If the software had been designed with less
> coupling
>on this particular hardware, you could have test the software vs. a simulation
> of the
>hardware and its environment. Here, the launch was the test.

Take your pick:
For linear rates:
1. Replace the accelerometers with A/D converters
2. Replace the values read from the accelerometers with simulated data
For angles:
1. either of the above for the gyros
2. place the navigation unit in a three or four axis table.


>>Although I like some of Mr. Meyer's columns, I found this particular
>>column not only wrong,
>>but dangerous, since it continues the trend of denigrating sound test
>>strategy and common
>>sense system engineering in favor of a software-centric approach. 
>
>I don't see where it denigrates sound testing. IMHO, sound testing *is* needed.
>And testing is effective only if you have a sound test strategy.
>Even more when you use programming by contract. In the paper,
>we just recall that you cannot rely on tests only.

Prove it works.

Richard Kaiser

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> 
> >   2. No one ran a full integration test with realistic flight data,
> >which would have
> >      alerted them to the mistake made in #1. Particularly for a
> >distributed mission-
> >      critical system, this should be considered an absolute
> >requirement.
> 
> Yes, this is true. But you have to understand that the mere design of the SRI
> made it very difficult to test it in an other way that performing a launch.
> This is because of the tight integration of hard-to-fool hardware with software
> in a black box functional unit. What can be your test strategy for a black box
> containing an inertial central? If the software had been designed with less coupling
> on this particular hardware, you could have test the software vs. a simulation of the
> hardware and its environment. Here, the launch was the test.

Read the final report. If you don't have a copy, see:

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

In particular:

"It should be noted that for reasons of physical law, it is not
feasible to test the SRI as a "black box" in the flight environment,
unless one makes a completely realistic flight test, but 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. Had such a test been performed
by
the supplier or as part of the acceptance test, the failure mechanism
would have been exposed."

If language is a problem, I believe the report is also available in
French.

As someone who, today, is performing testing of coupled IRS and flight
control systems in a ground-based environment, I am quite confident in
the conclusions of the paper on this point.

> 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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <3332C049.2A0F@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:


>"It should be noted that for reasons of physical law, it is not
>feasible to test the SRI as a "black box" in the flight environment,
>unless one makes a completely realistic flight test, but it is possible

OK, it seems that some people refuse to get the point of our paper
(design by contract is need when you attempt to reuse "black-boxes"). 
It is their pure right. I would be a pity if it would degenerate into a
flame bait. So I won't continue to argue...

>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. Had such a test been performed

That is, opening the black box...

>the supplier or as part of the acceptance test, the failure mechanism
>would have been exposed."

>As someone who, today, is performing testing of coupled IRS and flight
>control systems in a ground-based environment, I am quite confident in
>the conclusions of the paper on this point.

I understand that you feel touchy on the subject since it is your job that is at 
stake. But you do not need to worry: our point was not that test is not necessary:
it is! But it is not sufficient (I expect that you would agree on that).
Also, testing is a part of V&V, which is itself a part of the
larger goal of making a project succesful (whatever be the meaning of that).


-- 
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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> In article <3332C049.2A0F@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> 
> >"It should be noted that for reasons of physical law, it is not
> >feasible to test the SRI as a "black box" in the flight environment,
> >unless one makes a completely realistic flight test, but it is possible
> 
> OK, it seems that some people refuse to get the point of our paper
> (design by contract is need when you attempt to reuse "black-boxes").
> It is their pure right. I would be a pity if it would degenerate into a
> flame bait. So I won't continue to argue...

So far, the only arguments I've seen from either author are:

(a) It's not really black-box testing to test an IRS as described in the
paper.
(Why this even matters, I don't know, but I disagree with it in any
case. See
below.)

(b) It's not just Eiffel, it's Design by Contract plus Eiffel. (Which is
what
I said. Specifically, it's definitely NOT Design by Contract plus any
language.
Eiffel is required. So, I'm glad we all agree on this point. :)

Left unchallenged are the interesting arguments: Does the ability to
specify
an assertion mean that the assertion would have been specified, in the
case
of the Ariane 5? Does the specification of an assertion mean that it
will detect
errors (either by manual review, static analysis, or dynamic analysis)
of the type
detected on Ariane 5?

Too bad.

> 
> >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. Had such a test been performed
> 
> That is, opening the black box...

THIS   TEST   DOES   NOT   REQUIRE   OPENING   THE   BOX!

(1) Put the black box on the turntable.
(2) Hook the connectors to the EXTERIOR of the black box.
(3) Feed the signals through the connector!

Lord have mercy, why do people who have never tested an IRS INSIST on
explaining
it to those of us who have!

> 
> >the supplier or as part of the acceptance test, the failure mechanism
> >would have been exposed."
> 
> >As someone who, today, is performing testing of coupled IRS and flight
> >control systems in a ground-based environment, I am quite confident in
> >the conclusions of the paper on this point.
> 
> I understand that you feel touchy on the subject since it is your job that is at
> stake. But you do not need to worry: our point was not that test is not necessary:
> it is! But it is not sufficient (I expect that you would agree on that).

(a) I'm a software engineer. My job is not at stake in any of this.

(b) If the test is necessary, and Design by Contract does not require
testing, and
Ariane 5 did not plan to do the test, then Design by Contract by itself
would not
have prevented the accident. QED. Remove "probably yes" from the paper,
or add a
statement that Design by Contract, PLUS V&V, system engineering
(specifying the
Ariane V flight profile to the IRS team), etc. would have prevented the
problem.
At this point, you have no other intellectually honest option.

This has nothing to do with whether DBC/E (Design by Contract/Eiffel)
would detect
errors that might be missed otherwise. If you want to discuss such an
abstraction,
feel free. Your paper is written in terms of a specific problem in a
specific
environment. You admit that test was (a) possible, (b) not done, and (c)
required.
If you add (d), that DBC/E does not require V&V with realistic data (and
there
is nothing in the paper that contradicts this), your argument is dead.
We don't
even have to discuss whether or not being able to specific the specific
assertion
required in this case would have been specified by the design team, FOR
THE ARIANE
5 CASE.

I don't expect a response to this, of course, but there it is
nonetheless.

> Also, testing is a part of V&V, which is itself a part of the
> larger goal of making a project succesful (whatever be the meaning of that).

Completely missed the point. Too bad.

> 
> --
> 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: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robert S. White]

In article <33383A6F.3A5A@lmtas.lmco.com>, GarlingtonKE@lmtas.lmco.com says...

>Lord have mercy, why do people who have never tested an IRS INSIST on
>explaining
>it to those of us who have!

  I also work_on/design/(write requirements for)/integrate IRS's (I call 
them Inertial Navigation Systems - INS) and I agree completely with Ken.  
So don't think it is just him that has been put off by people saying that 
"Design By Contract with the Eiffel language" would have (alone - without 
simulation or HWIL) testing) prevented the Arianne 5 disaster.

  And it is normal industry practice to have different (from the 
designers/coders) personnel do the qualification tests (HWIL) test 
procedures and conduct the tests using the "Black Box" requirements.
_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer
-- my personal comments from industry experience at Rockwell Collins Inc.

Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Bertrand Meyer]

Robert S. White wrote:
 
> So don't think it is just him that has been put off by people
> saying that "Design By Contract with the Eiffel language"
> would have (alone - without simulation or HWIL) testing)
> prevented the [Ariane] 5 disaster.

In this particular case there is good reason to think that good
use of Design by Contract would in fact have evidenced the bug
early in the development cycle, long before any simulation or
testing. I think anyone that has practiced the method will agree.
To repeat the basic point of our (Jezequel's and mine) paper:
do not reuse without a contract.

But of course this is not a reason to say there should not be
simulation, testing, inspections, independent reviews etc. etc.
I don't recall anyone even coming close to suggesting this in the
present thread. And our paper certainly does not say anything of
the sort.

	(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.)
 
> And it is normal industry practice to have different (from the
> designers/coders) personnel do the qualification tests (HWIL) test
> procedures and conduct the tests using the "Black Box" requirements.

Agreed. Not only normal but excellent practice.

I like the modified thread title of your message:
"Trust but verify" although I would make it stronger:
"Make it trustable, then DON'T trust it" (and so verify it).
It would be as absurd to use Design by Contract or other
a priori relability techniques as an excuse not to do a posteriori V & V
(testing, simulation etc.),
as it would be to develop in a sloppy way with the expectation that
testing will uncover any problems.

If a priori reliability techniques - Design by Contract, static typing,
genericity, automatic memory management etc. - were a substitute for
testing, why would Eiffel environments bother to include debugging
tools? Engineering reliability can only result from the combination of
several techniques approaching the product from different angles:
some a priori (building the product right in the first place),
some a posteriori (not believing that it is right, and test it
extensively). That this is not an either-or situation
is so obvious as to be almost a platitude (although one does
encounter people, including software engineering authors,
who believe in only the a priori part or only the
a posteriori part).

But the need for a posteriori verification 
is too often an excuse for not applying the proven a priori
reliability techniques, such as Design by Contract. This is not
only silly but a recipe for disaster of Ariane-5 proportions.

It's been amazing in this discussion how some postings have taken
to task our paper for ideas that are not there.
The points that it makes are pretty simple, and there for everyone
to examine (http://www.eiffel.com, link to "Ariane 5 paper");
after reading most of the discussion, and re-reading the paper,
I think that its arguments and conclusion are perfectly in line with
many useful comments made by people who thought they disagreed with it.
Please check what it really has to say.

-- 
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: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robb Nebbe]

Bertrand Meyer wrote:
> 
> Robert S. White wrote:
> 
> > So don't think it is just him that has been put off by people
> > saying that "Design By Contract with the Eiffel language"
> > would have (alone - without simulation or HWIL) testing)
> > prevented the [Ariane] 5 disaster.
> 
> In this particular case there is good reason to think that good
> use of Design by Contract would in fact have evidenced the bug
> early in the development cycle, long before any simulation or
> testing.

The problem is that you conclusion is based on a misunderstanding
of what actually happened. Your mistakes are relatively clear to
anyone who knows Ada. Obviously, you don't see any problem with the
paper or its conclusions because you don't know Ada well enough
to interpret the findings of the Ariane 5 report. 

 
> It's been amazing in this discussion how some postings have taken
> to task our paper for ideas that are not there.
> The points that it makes are pretty simple, and there for everyone
> to examine (http://www.eiffel.com, link to "Ariane 5 paper");
> after reading most of the discussion, and re-reading the paper,
> I think that its arguments and conclusion are perfectly in line with
> many useful comments made by people who thought they disagreed with it.
> Please check what it really has to say.

The problem is that there are a number of factual errors linked to
you lack of knowledge of Ada. If everything you said was true then
you conclusions would also be true. Just because someone, out of
ignorance, claims something is true does not make it so. 


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

Robb Nebbe

Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Bertrand Meyer wrote:
> 
> Robert S. White wrote:
> 
> > So don't think it is just him that has been put off by people
> > saying that "Design By Contract with the Eiffel language"
> > would have (alone - without simulation or HWIL) testing)
> > prevented the [Ariane] 5 disaster.
> 
> In this particular case there is good reason to think that good
> use of Design by Contract would in fact have evidenced the bug
> early in the development cycle, long before any simulation or
> testing. I think anyone that has practiced the method will agree.
> To repeat the basic point of our (Jezequel's and mine) paper:
> do not reuse without a contract.
> 
> But of course this is not a reason to say there should not be
> simulation, testing, inspections, independent reviews etc. etc.
> I don't recall anyone even coming close to suggesting this in the
> present thread. And our paper certainly does not say anything of
> the sort.

Unfortunately, it does. To quote:

"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 flaw in this statement is essentially two-fold: What is
said in support of this argument is shaky, and just as importantly
what is NOT said in the paper is flawed. Taking the supporting
arguments first:

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

Catching this error via automated testing, in the case of Ariane 5,
depends upon two key aspects:

  a. That the proper data is available to trigger the exception
     during test. This was not available in the case of the
     Ariane 5 (see the final report).

  b. That the test would have been executed in the proper
     manner. The final report states quite clearly that
     proper testing was not performed.

Thus, *in the context of the Ariane-5 development*, this
argument fails.

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

There are many counter-arguments to this point. However, since
you acknowledge explicitly that it is inapplicable to
this case, it fails inherently. 

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

  a. This implies that the QA team would have had proper information
     to do such checking. As noted above, the final report clearly
     states that they would not have such information. The most thorough
     manual validation will fail in the face of incomplete data.
     This alone invalidates this claim.

  b. It also implies that the QA team would have done the check.
     Putting aside the argument as to whether the Ariane 5 team
     was "worth its salt", the report makes it clear that there
     was NOT an emphasis on "thorough validation of everything."
     Therefore, the assumption made in this point is in error,
     further invalidating the claim.

  c. There is, of course, the issue of scalability. Can a QA team
     check that every call satisfies every assertion manually
     (remember that automated testing is described in a seperate
     argument), for a system of this size? No evidence is given
     to support this claim. This further weakens an already dead
     claim.

There is also a general argument for all of these points. Given
that Design by Contract/Eiffel makes it *possible* to specify
the assertion, would the development team have, in fact,
specified the assertion? The final report clearly indicates that
the team felt the assertion could not be violated in practice,
and that this analysis was agreed to at several management levels.
No evidence is given that, in this context, the assertion would
have been written by *this* team. I suspect most development
teams do not introduce assertions they consider impossible to
trigger! As the paper itself notes: "If you have proved that a
condition cannot happen, you are entitled not to check for it.
If every program checked for all possible and impossible events,
no useful instruction would ever get executed!" By extension,
no useful program would ever get *coded*, even if the
extraneous assertions would be suppressed at run-time, if some
decisions were not made about what assertions to include.

(There are several other general arguments related to the use of
assertions, of course, but advancing such arguments seems
unnecessary at this point.)

So much for the explicit arguments. Now, for what the paper
does NOT say. You state that "...there should... be
simulation, testing, inspections, independent reviews etc...."
and go on to note that the paper does not *deny* this fact.
This, however, is not the issue. The issue is, does Design
by Contract *require* such activities, which everyone seems
to agree are in fact required? Note, again, that the
statement is made that:

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

This says that the crash would probably have been avoided
if Design by Contract/Eiffel (DBC) has been used. It does *not*
say that the crash would have been avoided if Design by
Contract/Eiffel has been used, AND IN ADDITION:

a. That the proper data had been provided in the *system*
specification. Although this is extensively described
in the final report, the DBC paper makes no mention of
it. As noted above, without such data, all arguments in
support of DBC fail.

b. That DBC would have caused the introduction of the critical
assertion. As quoted above, it in fact implies the opposite:
that "impossible" assertions may not in fact be introduced.

c. That sufficient manual QA would have been done. The paper
does say that proper manual QA should be done. However,
it does not say how DBC supports this activity, either in
terms of educating management to the need for
this activity (a key issue in the Ariane 5 case), or in
terms of proper performance of this activity. (Apparently,
all that is needed is "salt" :)

d. That sufficient automated verification would have
been done. Here is the paper's statement on testing:

"Is it a testing error? Not really... if one can test
more one cannot test all. Testing, we all know, can show
the presence of errors, not their absence. And the only
fully 'realistic' test is to launch..."

This, to me, is not a particularly strong endorsement of
testing!

So, clearly, DBC would not have been *sufficient* in this
case. You emphasized this point later in your post (although,
unfortunately, not in the paper):

> Engineering reliability can only result from the combination of
> several techniques approaching the product from different angles:
> some a priori (building the product right in the first place),
> some a posteriori (not believing that it is right, and test it
> extensively). That this is not an either-or situation
> is so obvious as to be almost a platitude (although one does
> encounter people, including software engineering authors,
> who believe in only the a priori part or only the
> a posteriori part).

So, if there are people who do not consider this a "platitiude"
(as was obviously true for Ariane 5), and such considerations
are essential to the use of DBC, why does the paper not state this
explicitly?

So, the only argument remaining is: is DBC *necessary* for
the Ariane 5 case? I would say, no. If the proper flight
trajectory had been provided, and the proper test would have
been performed, then the SRI error would have been detected
before launch. This is noted in the final report. Note that this
is not an issue of 20/20 hindsight; as several people familiar
with such systems have noted, such a test is standard practice.
One could argue that the proper use of assertions would have been
able to more easily isolate and correct the problem, or that some other
system fault might have been detected through the use of DBC,
but both arguments are irrelevant to the subject of the
paper: that DBC would have saved the Ariane 5 from the *specific*
fault which destroyed it. So, if the paper had emphasized that
proper system engineering and verification testing had been done,
it would have further weakened it's own case. It is not
surprising, then, that no such statement is in the paper.

> It's been amazing in this discussion how some postings have taken
> to task our paper for ideas that are not there.
> The points that it makes are pretty simple, and there for everyone
> to examine (http://www.eiffel.com, link to "Ariane 5 paper");
> after reading most of the discussion, and re-reading the paper,
> I think that its arguments and conclusion are perfectly in line with
> many useful comments made by people who thought they disagreed with it.
> Please check what it really has to say.

I would appreciate a response to any or all of my rebuttals to your
paper. I have tried in good conscience to quote it accurately. If
you believe I have misquoted you, please say so.

Unfortunately, continuing to claim that the paper answers these
criticisms, without providing any details as to *how* they are
answered, does not provide me with any confidence that your
paper is valid. Perhaps your paper is not directed at practitioners
in the flight controls or inertial reference fields. If so, then
I could understand why you would ignore the arguments made by
those practitioners, such as myself and Mr. White.

In any case, I have posted these arguments several times without
response. If you do not respond to this post, I will assume that
no response is possible.

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

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

Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Karel Th�nissen]

Ken Garlington wrote:

> 1. "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."
> 
> Catching this error via automated testing, in the case of Ariane 5,
> depends upon two key aspects:
>   a. That the proper data is available to trigger the exception
>      during test. This was not available in the case of the
>      Ariane 5 (see the final report).
>   b. That the test would have been executed in the proper
>      manner. The final report states quite clearly that
>      proper testing was not performed.
> Thus, *in the context of the Ariane-5 development*, this
> argument fails.

I agree.

> 2. "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."
> 
> There are many counter-arguments to this point. However, since
> you acknowledge explicitly that it is inapplicable to
> this case, it fails inherently.

I agree.
 
> 3. "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."
> 
>   a. This implies that the QA team would have had proper information
>      to do such checking. As noted above, the final report clearly
>      states that they would not have such information. The most thorough
>      manual validation will fail in the face of incomplete data.
>      This alone invalidates this claim.

Yes, one needs the data. But if the integration team would have had the
documentation generated from the DBC-like assertions, it would have
been  clear to them that the correctness/applicability of the software
depends on the maximum horizontal speed of Ariane 5 (or of the actual
flight path, to be more specific). Isn't it likely then, that they would
have asked for it? Would higher levels of management have refused the
provision of these data, if the integration team could show the
importance of these data? So there is no certainty here that assertions
would prevent the disaster, but it would make it less likely, as was
claimed by several advocates of the use of DBC.

>   b. It also implies that the QA team would have done the check.
>      Putting aside the argument as to whether the Ariane 5 team
>      was "worth its salt", the report makes it clear that there
>      was NOT an emphasis on "thorough validation of everything."
>      Therefore, the assumption made in this point is in error,
>      further invalidating the claim.

What is your point? I feel you are exercising casuistry here.
BTW, DBC is not only about writing assertions in the code, it also
involves using the analytical results provided by the system. For this
reason the support by the language can be so important! Meyer's claim
that the crash was avoidable was about the use of DBC ('language and
method') and not about the sole use of assertions in the code. So your
argument cannot fairly be used as an argument against Meyer's
exposition.
 
>   c. There is, of course, the issue of scalability. Can a QA team
>      check that every call satisfies every assertion manually
>      (remember that automated testing is described in a seperate
>      argument), for a system of this size? No evidence is given
>      to support this claim. This further weakens an already dead
>      claim.

Firstly, your argument depends on claims already refuted. Secondly,
verification of the code is not a two-valued process. Assertions can
sometimes prove correctness, sometimes incorrectness and sometimes
neither.  Even if we can not prove the absence of contract breaking, we
may be able to show the presence of it. In either case, the use of DBC
was useful. And in the case of assumptions that regard the operating
environment of the software: not the calls need to be checked, but the
input to the system.
 
> There is also a general argument for all of these points. Given
> that Design by Contract/Eiffel makes it *possible* to specify
> the assertion, would the development team have, in fact,
> specified the assertion? The final report clearly indicates that
> the team felt the assertion could not be violated in practice,
> and that this analysis was agreed to at several management levels.
> No evidence is given that, in this context, the assertion would
> have been written by *this* team. I suspect most development
> teams do not introduce assertions they consider impossible to
> trigger! As the paper itself notes: "If you have proved that a
> condition cannot happen, you are entitled not to check for it.
> If every program checked for all possible and impossible events,
> no useful instruction would ever get executed!" By extension,
> no useful program would ever get *coded*, even if the
> extraneous assertions would be suppressed at run-time, if some
> decisions were not made about what assertions to include.

It seems you do not properly understand the use of assertions and DBC.
Apart from there role during testing and execution, DBC and assertions
are part of the documentation. It is not necessary to execute them
during testing (I would rather do it, though) and execution. So there
does not have to be a performance penalty (again, this switching
capability is a good argument for having these checks as part of the
language).

Even if one deems something impossible, it is still an assumption and
should therefore be documented with an assertion. What you are saying is
something like: 'this is so obvious that there is no need to document
it'. Firstly, in mission critical systems things are never obvious and,
secondly, leaving out the obvious is not DBC!!!

Then your claim that the assumption is not documented is not supported
by the Lions-report, to the contrary, it was 'agreed', but obscured by
the 'large amount of documentation'. Therefore, it is absurd to suppose
that the programming team would not have made use of assertions in an
environment of DBC supported with the proper tools or languages.

Yes, you are entitled not to *check* an assertion considered impossible
to trigger, but you are not entitled to leave it out! Just do not check
it in the production system, but do check it during verification and
during testing/simulation. Note that this is exactly what Meyer and
Jezequel wrote: not _checking_. They did not suggest to refrain from
writing or verifying the assertion.

> (There are several other general arguments related to the use of
> assertions, of course, but advancing such arguments seems
> unnecessary at this point.)

So do not mention this at all.
 
> So much for the explicit arguments. Now, for what the paper
> does NOT say. You state that "...there should... be
> simulation, testing, inspections, independent reviews etc...."
> and go on to note that the paper does not *deny* this fact.
> This, however, is not the issue.

If it is not the issue, why bother?

> The issue is, does Design by Contract *require* such activities, which 
> everyone seems to agree are in fact required? Note, again, that the
> statement is made that:

Mr Meyer has always been very clear about this. Nowhere the suggestion
is made that testing etc. can be skipped or weakened. The point of DBC
is that it provides an additional technique for obtaining quality
software, not an replacement for testing.

BTW what did you not mention? It is far too simple to use this kind of
default reasoning. Are you a racist just because you did not explicitly
deny it? I would not think so :-).
 
> This says that the crash would probably have been avoided
> if Design by Contract/Eiffel (DBC) has been used. It does *not*
> say that the crash would have been avoided if Design by
> Contract/Eiffel has been used, AND IN ADDITION:

I do not want to put words in other people's mouth, so _I_ will state it
on my behalf: DBC (language and method) indeed would have avoided the
crash. Remember what I have written above: DBC is incomplete without the
analysis part.
 
> a. That the proper data had been provided in the *system*
> specification. Although this is extensively described
> in the final report, the DBC paper makes no mention of
> it. As noted above, without such data, all arguments in
> support of DBC fail.

DBC would have triggered the integration team to ask for that data.
 
> b. That DBC would have caused the introduction of the critical
> assertion. As quoted above, it in fact implies the opposite:
> that "impossible" assertions may not in fact be introduced.

???
 
> c. That sufficient manual QA would have been done. The paper
> does say that proper manual QA should be done. However,
> it does not say how DBC supports this activity, either in
> terms of educating management to the need for
> this activity (a key issue in the Ariane 5 case), or in
> terms of proper performance of this activity. (Apparently,
> all that is needed is "salt" :)
> 
> d. That sufficient automated verification would have
> been done. Here is the paper's statement on testing:

Mixing up testing and verification, hmmmm? These may be identical in
systems engineering, they are not in software engineering.
 
> "Is it a testing error? Not really... if one can test
> more one cannot test all. Testing, we all know, can show
> the presence of errors, not their absence. And the only
> fully 'realistic' test is to launch..."
> 
> This, to me, is not a particularly strong endorsement of
> testing!
> 
> So, clearly, DBC would not have been *sufficient* in this
> case. You emphasized this point later in your post (although,
> unfortunately, not in the paper):
> 
> So, if there are people who do not consider this a "platitiude"
> (as was obviously true for Ariane 5), and such considerations
> are essential to the use of DBC, why does the paper not state this
> explicitly?

Are you joking? Default reasoning.
 
> So, the only argument remaining is: is DBC *necessary* for
> the Ariane 5 case? I would say, no. If the proper flight
> trajectory had been provided, and the proper test would have
> been performed, then the SRI error would have been detected
> before launch.

Yes, that is true for flight 501. This again is casuistry. Testing would
have remedied indeed, but so would verification with DBC. It seems you
only rely on testing. But verification can catch bugs that are very
difficult to catch with testing. The paper by M&J was one from a
software engineering point of view, and an interesting one from that
perspective. And 501 is an good illustration of a software engineering
pitfall that can be avoided with DBC.

> This is noted in the final report. Note that this
> is not an issue of 20/20 hindsight; as several people familiar
> with such systems have noted, such a test is standard practice.
> One could argue that the proper use of assertions would have been
> able to more easily isolate and correct the problem, or that some other
> system fault might have been detected through the use of DBC,
> but both arguments are irrelevant to the subject of the
> paper: that DBC would have saved the Ariane 5 from the *specific*
> fault which destroyed it. So, if the paper had emphasized that
> proper system engineering and verification testing had been done,
> it would have further weakened it's own case. It is not
> surprising, then, that no such statement is in the paper.

???? should one comment???
 
> Unfortunately, continuing to claim that the paper answers these
> criticisms, without providing any details as to *how* they are
> answered, does not provide me with any confidence that your
> paper is valid. Perhaps your paper is not directed at practitioners
> in the flight controls or inertial reference fields. If so, then
> I could understand why you would ignore the arguments made by
> those practitioners, such as myself and Mr. White.

(Speaking only for myself) I think the paper is directed at a wider
audience than only practitioners in flight controls and IR fields. It
will help them and others to understand to problems of software reuse.
It is not the case that there is a software engineering for flight
control and a different software engineering for other disciplines. 

I appreciate your replies, because they illustrate the complexities of
feedback systems, complex closed loop simulations, fail behaviour, etc.,
but I do not think that they invalidate M&J's claims.
 
> In any case, I have posted these arguments several times without
> response. If you do not respond to this post, I will assume that
> no response is possible.

This is a silly and childish way of exchanging ideas. Maybe you are the
one that needs to be convinced :-).

Re: Trust but verify (was 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: 27385 bytes --]


Karel Th�nissen wrote:
> 
> Ken Garlington wrote:
> 
> > 1. "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."
> >
> > Catching this error via automated testing, in the case of Ariane 5,
> > depends upon two key aspects:
> >   a. That the proper data is available to trigger the exception
> >      during test. This was not available in the case of the
> >      Ariane 5 (see the final report).
> >   b. That the test would have been executed in the proper
> >      manner. The final report states quite clearly that
> >      proper testing was not performed.
> > Thus, *in the context of the Ariane-5 development*, this
> > argument fails.
> 
> I agree.
> 
> > 2. "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."
> >
> > There are many counter-arguments to this point. However, since
> > you acknowledge explicitly that it is inapplicable to
> > this case, it fails inherently.
> 
> I agree.
> 
> > 3. "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."
> >
> >   a. This implies that the QA team would have had proper information
> >      to do such checking. As noted above, the final report clearly
> >      states that they would not have such information. The most thorough
> >      manual validation will fail in the face of incomplete data.
> >      This alone invalidates this claim.
> 
> Yes, one needs the data. But if the integration team would have had the
> documentation generated from the DBC-like assertions, it would have
> been  clear to them that the correctness/applicability of the software
> depends on the maximum horizontal speed of Ariane 5 (or of the actual
> flight path, to be more specific). Isn't it likely then, that they would
> have asked for it? Would higher levels of management have refused the
> provision of these data, if the integration team could show the
> importance of these data? 

Here is the suggested assertion from the web page:

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

There are two issues with manual verification of this statement from the
flight path data:

1. Based on my experience, the transformation of flight path information
to
   the horizontal bias, in the form used at this point in the program,
may
   be a complex process involving several non-trivial equations,
scalings,
   etc. It is not clear that the inspection team would have had
sufficient
   resources, knowledge, etc. to do this computation to generate the
parameter's
   maximum real value at this exact point.

2. If the integration team had asked for data, they would have been
given
   data. The data from the specification. The data for the Ariane *IV*.
   The integration team would have had to have asked a much more
   important question: "Is the data that we have available sufficient
for
   the new environment we are using?" That decision had already been
   made (incorrectly) by the development team: YES. As noted in the
final
   report, this was a deliberate decision, based on the faulty premise
   that the IRS would work equally well in either environment.

So, if someone had known that the environments were sufficiently
different to
cause a problem, then they might have had a chance. However, reading the
assertion above is insufficient to know that this is the case,
particularly
when you are working to a specification that does not even acknowledge
mulitple environments!
   
> So there is no certainty here that assertions
> would prevent the disaster, but it would make it less likely, as was
> claimed by several advocates of the use of DBC.

Again, I think that this claim is based on an unstated assumption: that
the *right* data is always available to the development team. See how
easy it is to assume the "obvious"? :)

> 
> >   b. It also implies that the QA team would have done the check.
> >      Putting aside the argument as to whether the Ariane 5 team
> >      was "worth its salt", the report makes it clear that there
> >      was NOT an emphasis on "thorough validation of everything."
> >      Therefore, the assumption made in this point is in error,
> >      further invalidating the claim.
> 
> What is your point? I feel you are exercising casuistry here.
> BTW, DBC is not only about writing assertions in the code, it also
> involves using the analytical results provided by the system. For this
> reason the support by the language can be so important! Meyer's claim
> that the crash was avoidable was about the use of DBC ('language and
> method') and not about the sole use of assertions in the code. So your
> argument cannot fairly be used as an argument against Meyer's
> exposition.

My point is that the "integration team" you described earlier did not
exist on this program, at least in the form required to take the
actions you suggest.

I am completely confused. The three statements in the paper used in
support of Meyer's claim all are in terms of assertions in the code.
These are the statements I am refuting.

Quoting further from the paper: "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 assume from this quote that the critical part of DBC is the
specification
of preconditions, postconditions, and invariants -- which I assume all
fall
under the umbrella of assertions -- in a meaningful manner. I certainly
do
not assume they are done randomly, but intelligently. However, this does
not address the issues I raise.

If you are saying that DBC would have caused the integration team to
look beyond the specification and challenge management's decisions in
this area, I would appreciate a citation to support this claim. I cannot
find any justification for the statement in the paper provided.

> 
> >   c. There is, of course, the issue of scalability. Can a QA team
> >      check that every call satisfies every assertion manually
> >      (remember that automated testing is described in a seperate
> >      argument), for a system of this size? No evidence is given
> >      to support this claim. This further weakens an already dead
> >      claim.
> 
> Firstly, your argument depends on claims already refuted.

Even if the integration team had the appropriate data (claim a), and
was tasked to examine the module specifications with this data (claim
b),
it seems to me that an independent claim can be made that they would
not have had the resources to manually check all assertions in a
complete manner for a program of moderate complexity (claim c). At
least,
to me, this claim is an independent challenge. Perhaps you can explain
further the dependencies.

> Secondly,
> verification of the code is not a two-valued process. Assertions can
> sometimes prove correctness, sometimes incorrectness and sometimes
> neither.  Even if we can not prove the absence of contract breaking, we
> may be able to show the presence of it. In either case, the use of DBC
> was useful. And in the case of assumptions that regard the operating
> environment of the software: not the calls need to be checked, but the
> input to the system.

This is interesting, but I don't see the relevance to claim c. My point
is that, using DBC, there would have been more than one assertion in the
system. In fact, there may have been quite a few. As the number of
assertions grows, analyzing them (through any n-valued process you
choose)
requires more and more resources. Mr. J�z�quel has acknowledged in a
separate post that the scalability of DBC is not proven, although his
experience in telco applications suggests it *may* scale.

> 
> > There is also a general argument for all of these points. Given
> > that Design by Contract/Eiffel makes it *possible* to specify
> > the assertion, would the development team have, in fact,
> > specified the assertion? The final report clearly indicates that
> > the team felt the assertion could not be violated in practice,
> > and that this analysis was agreed to at several management levels.
> > No evidence is given that, in this context, the assertion would
> > have been written by *this* team. I suspect most development
> > teams do not introduce assertions they consider impossible to
> > trigger! As the paper itself notes: "If you have proved that a
> > condition cannot happen, you are entitled not to check for it.
> > If every program checked for all possible and impossible events,
> > no useful instruction would ever get executed!" By extension,
> > no useful program would ever get *coded*, even if the
> > extraneous assertions would be suppressed at run-time, if some
> > decisions were not made about what assertions to include.
> 
> It seems you do not properly understand the use of assertions and DBC.
> Apart from there role during testing and execution, DBC and assertions
> are part of the documentation. It is not necessary to execute them
> during testing (I would rather do it, though) and execution. So there
> does not have to be a performance penalty (again, this switching
> capability is a good argument for having these checks as part of the
> language).

This point is not related to execution. As with the analysis of
assertions,
the writing of assertions takes resources (schedule and cost). These
"people"
resources are finite, and serve as a limit on the number of assertions.
Therefore, I would expect that assertions are not written in the code
for
what the coder considers wildly improbable. If the assertion is never
written
down, then it cannot serve as documentation, never mind testing or
execution.

> 
> Even if one deems something impossible, it is still an assumption and
> should therefore be documented with an assertion. What you are saying is
> something like: 'this is so obvious that there is no need to document
> it'. Firstly, in mission critical systems things are never obvious and,
> secondly, leaving out the obvious is not DBC!!!

Using this criteria, I would have to write a large number of assertions
to
handle cases such as:

  * compiler errors
  * CPU microcode software failures
  * hardware failures
  * physics failures (moving from one location to another at faster than
    the speed of light, for example)
  * etc.

The reality is: there are always assumptions so basic that they are
never
coded as assertions in any methodology. At some point, you have to say,
"This is so brutally obvious that I would waste the analyst's time
writing
it." And, with that decision, the door is opened to not writing
something
that isn't so obvious. As noted in the final report:

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

Note especially the phrase "physically limited". In the Ada sense,
it would be much like writing:

  if Integer'First not in Integer'Range then
    raise Impossible_Error;
  end if;

Generally, this is considered a tautology, and would not be
written. My reading of the final report is that the development
team considered the BH variable range to be in somewhat the
same category (although probably not the *same*).

> Then your claim that the assumption is not documented is not supported
> by the Lions-report, to the contrary, it was 'agreed', but obscured by
> the 'large amount of documentation'. Therefore, it is absurd to suppose
> that the programming team would not have made use of assertions in an
> environment of DBC supported with the proper tools or languages.

In fact, the programming team did *not* use assertions for this
variable,
although they had a language which the paper (at one point) asserts was
sufficient to write the assertion. Furthermore, they did use assertions
in other areas, so they clearly had a methodology which included such
techniques.

I would also quibble with your reading of the final report. I believe
they
are saying that the decision to leave certain variables unprotected was
documented, not the specific assertion in the case of BH. See the
paragraph
above from the final report, which is part of the context of the
sentence you quoted.

Note further the complete sentence from the final report:

"Given the large amount of documentation associated with any industrial
application, the assumption, although agreed, was essentially obscured,
though not deliberately, from any external review."

It does not say that the *development* team did not have access to the
"assumption" (again, the assumption that it was not worth writing an
assertion, IMHO), rather than it was obscured from any *external*
review. It
is unclear to me whether this means an independent integration team,
a safety review team, or other body.

> Yes, you are entitled not to *check* an assertion considered impossible
> to trigger, but you are not entitled to leave it out! Just do not check
> it in the production system, but do check it during verification and
> during testing/simulation. Note that this is exactly what Meyer and
> Jezequel wrote: not _checking_. They did not suggest to refrain from
> writing or verifying the assertion.

Again, this is not my point. See above.

> > (There are several other general arguments related to the use of
> > assertions, of course, but advancing such arguments seems
> > unnecessary at this point.)
> 
> So do not mention this at all.
> 
> > So much for the explicit arguments. Now, for what the paper
> > does NOT say. You state that "...there should... be
> > simulation, testing, inspections, independent reviews etc...."
> > and go on to note that the paper does not *deny* this fact.
> > This, however, is not the issue.
> 
> If it is not the issue, why bother?

Because I wished to bring to Mr. Meyer's attention (it was his post
to which I was responding, after all!) that he did not understand
my position.

> 
> > The issue is, does Design by Contract *require* such activities, which
> > everyone seems to agree are in fact required? Note, again, that the
> > statement is made that:
> 
> Mr Meyer has always been very clear about this. Nowhere the suggestion
> is made that testing etc. can be skipped or weakened. The point of DBC
> is that it provides an additional technique for obtaining quality
> software, not an replacement for testing.

I disagree. I believe the paper strongly implies that DBC was
*sufficient*
for solving this problem. The following statements support that claim.

It is true that Mr. Meyer has made many statements *outside* of the
paper
that support your statement. I would like to see some of those
qualifiers
*inside* the paper. I am, after all, critiquing the paper, not an
individual!

> 
> BTW what did you not mention? It is far too simple to use this kind of
> default reasoning. Are you a racist just because you did not explicitly
> deny it? I would not think so :-).

No. However, if I had said "The world would be a better place if there
were no [racial group members]," I hardly think you would require me to
explicitly state I was a racist!

> 
> > This says that the crash would probably have been avoided
> > if Design by Contract/Eiffel (DBC) has been used. It does *not*
> > say that the crash would have been avoided if Design by
> > Contract/Eiffel has been used, AND IN ADDITION:
> 
> I do not want to put words in other people's mouth, so _I_ will state it
> on my behalf: DBC (language and method) indeed would have avoided the
> crash. Remember what I have written above: DBC is incomplete without the
> analysis part.

You're braver than the paper, which only goes so far as "probably yes."
:)
Do you have experience in flight controls/IRS integration?

> 
> > a. That the proper data had been provided in the *system*
> > specification. Although this is extensively described
> > in the final report, the DBC paper makes no mention of
> > it. As noted above, without such data, all arguments in
> > support of DBC fail.
> 
> DBC would have triggered the integration team to ask for that data.

See the analysis above, starting with: "a. This implies that the QA
team would have had proper information to do such checking." They
would ask for *data*, and they would get *data* - Ariane IV data.

> > b. That DBC would have caused the introduction of the critical
> > assertion. As quoted above, it in fact implies the opposite:
> > that "impossible" assertions may not in fact be introduced.
> 
> ???

See the analysis above, starting with: "There is also a general
argument for all of these points." COMPLETELY IGNORING EXECUTION
AND MEMORY, there are finite resources for CODING assertions.
Those which the coder considers "impossible" will likely not
get coded.

> 
> > c. That sufficient manual QA would have been done. The paper
> > does say that proper manual QA should be done. However,
> > it does not say how DBC supports this activity, either in
> > terms of educating management to the need for
> > this activity (a key issue in the Ariane 5 case), or in
> > terms of proper performance of this activity. (Apparently,
> > all that is needed is "salt" :)
> >
> > d. That sufficient automated verification would have
> > been done. Here is the paper's statement on testing:
> 
> Mixing up testing and verification, hmmmm? These may be identical in
> systems engineering, they are not in software engineering.

I've always assumed that verification is "The process of
evaluating the products of a given software development
activity to determine correctness and consistency with
respect to the products and standards provided as input to
that activity," and that methods to do verification
included testing, either as "demonstration, analysis,
or inspection." However, you can certainly choose different
terminology if you wish. I will be pleased to rephrase
the point as:

"d. That sufficient testing would have been done. Here
is the paper's statement on testing."

> 
> > "Is it a testing error? Not really... if one can test
> > more one cannot test all. Testing, we all know, can show
> > the presence of errors, not their absence. And the only
> > fully 'realistic' test is to launch..."
> >
> > This, to me, is not a particularly strong endorsement of
> > testing!
> >
> > So, clearly, DBC would not have been *sufficient* in this
> > case. You emphasized this point later in your post (although,
> > unfortunately, not in the paper):
> >
> > So, if there are people who do not consider this a "platitiude"
> > (as was obviously true for Ariane 5), and such considerations
> > are essential to the use of DBC, why does the paper not state this
> > explicitly?
> 
> Are you joking? Default reasoning.

However, this "default reasoning", according to Mr. Meyer,
is often not considered by others. This seems to contradict
my understand of "default".

> 
> > So, the only argument remaining is: is DBC *necessary* for
> > the Ariane 5 case? I would say, no. If the proper flight
> > trajectory had been provided, and the proper test would have
> > been performed, then the SRI error would have been detected
> > before launch.
> 
> Yes, that is true for flight 501. This again is casuistry. Testing would
> have remedied indeed, but so would verification with DBC. It seems you
> only rely on testing. But verification can catch bugs that are very
> difficult to catch with testing.

I can absolutely agree with this statement. Unfortunately, the paper
is written in the specific case of flight 501, not as a general
treatise on the advantages of testing + "verification" vs.
testing alone.

I am glad that we now agree with the two central statements of my
response:

  a. DBC, by itself, would not have avoided the Ariane V catastrophy.
     It is "default reasoning" that many other process errors would also
     have to be avoided.

  b. DBC was not *necessary* in the specific case of Ariane 501.
     For the *particular* problem identified, a commonly-accepted
     test would have detected the problem on the ground and avoided
     the crash.

Again, feel free to state that DBC is a useful adjunct to other
processes,
and that DBC is a useful methodology. However, in the *specific* case of
the Ariane V, which is the subject of the paper, it was not the only
answer,
nor was it the full answer. Compare this conclusion with the statement:

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

This statement could lead the casual reader to believe that DBC was
both necessary and sufficient, as DBC is described in the paper, for
the specific error in the Ariane V crash. Perhaps a better statement
would have been:

"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? By itself, possibly not. However,
in the context of a well-managed system and software engineering
process, DBC provides additional capabilities to detect problems of
this class before they cause a serious impact."

This statement could be debated, but it isn't provably false. 

> The paper by M&J was one from a
> software engineering point of view, and an interesting one from that
> perspective. And 501 is an good illustration of a software engineering
> pitfall that can be avoided with DBC. This is noted in the final report.

Actually, the phrase "software engineering" does not appear in the final
report. The report does state:

"The failure of the Ariane 501 was caused by the complete loss of
guidance
and attitude information 37 seconds after start of the main engine
ignition
sequence (30 seconds after lift- off). This loss of information was due
to
specification and design errors in the software of the inertial
reference
system.

"The extensive reviews and tests carried out during the Ariane 5
Development
Programme did not include adequate analysis and testing of the inertial
reference system or of the complete flight control system, which could
have
detected the potential failure."

Based on my reading of the final report, and my knowledge of this field,
I do not interpret "specification" in the sense of module-level DBC
specifications, but a much higher system/software specification done
well before specific modules are identified. Similarly, "testing"
is described in the final report as being more than just the type of
testing that DBC/assertions support. In fact, of the fourteen report
recommendations, only R5 seems to be related to DBC.

> > Note that this
> > is not an issue of 20/20 hindsight; as several people familiar
> > with such systems have noted, such a test is standard practice.
> > One could argue that the proper use of assertions would have been
> > able to more easily isolate and correct the problem, or that some other
> > system fault might have been detected through the use of DBC,
> > but both arguments are irrelevant to the subject of the
> > paper: that DBC would have saved the Ariane 5 from the *specific*
> > fault which destroyed it. So, if the paper had emphasized that
> > proper system engineering and verification testing had been done,
> > it would have further weakened it's own case. It is not
> > surprising, then, that no such statement is in the paper.
> 
> ???? should one comment???
> 
> > Unfortunately, continuing to claim that the paper answers these
> > criticisms, without providing any details as to *how* they are
> > answered, does not provide me with any confidence that your
> > paper is valid. Perhaps your paper is not directed at practitioners
> > in the flight controls or inertial reference fields. If so, then
> > I could understand why you would ignore the arguments made by
> > those practitioners, such as myself and Mr. White.
> 
> (Speaking only for myself) I think the paper is directed at a wider
> audience than only practitioners in flight controls and IR fields. It
> will help them and others to understand to problems of software reuse.
> It is not the case that there is a software engineering for flight
> control and a different software engineering for other disciplines.

No, but it is the case that, when analyzing a *specific* application
of software engineering practices, it helps to have experience in that
field. This is the topic of this paper: the use of a software
engineering
practice in a *specific* field.

This seems to be the most difficult point to grasp in my argument: that
the topic of this paper is the exception raised during the first flight
of the Ariane V. It is not a general treatise on software engineering.
Therefore, it should be evaluated in terms of the field it attempts to
explore, at least I would think!

> 
> I appreciate your replies, because they illustrate the complexities of
> feedback systems, complex closed loop simulations, fail behaviour, etc.,
> but I do not think that they invalidate M&J's claims.

We will have to agree to disagree, then. They make three claims in
support
of their statement. I have addressed all three, as well as your
rebuttals.

> 
> > In any case, I have posted these arguments several times without
> > response. If you do not respond to this post, I will assume that
> > no response is possible.
> 
> This is a silly and childish way of exchanging ideas. Maybe you are the
> one that needs to be convinced :-).

???

My point is that Mr. Meyer and I are not exchanging ideas. I have posted
three different times my concerns, without direct response. I have sent
one private e-mail, without response. I have also been told by someone
else, a developer of IRS software, that he has also sent similar
concerns
to Mr. Meyer without response. The only public comment Mr. Meyer wishes
to make is that he is misunderstood, and that the responses to these
criticisms are "obviously" in the paper. I can't really consider this an
exchange.

In any case, I appreciate your specific and thoughtful comments to my
criticisms. Please consider a further response.

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

Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

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


In article <333C4396.795@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> In any case, I have posted these arguments several times without
> response. If you do not respond to this post, I will assume that
> no response is possible.

Sorry, I've been away from some time, and I'll be again soon.
Don't draw hasty conclusions from lack of answers from the net: like you, I
also have real work to do...

BTW, it seems that other (e.g. Karel Th�nissen) did try to answer your points:

>> is that it provides an additional technique for obtaining quality
>> software, not an replacement for testing.
>
>I disagree. I believe the paper strongly implies that DBC was
>*sufficient*
>for solving this problem. The following statements support that claim.

OK, DBC is like a tool, and as for all tools, it must be used properly to be effective.

>It is true that Mr. Meyer has made many statements *outside* of the
>paper
>that support your statement. I would like to see some of those
>qualifiers
>*inside* the paper. I am, after all, critiquing the paper, not an
>individual!

If that's so important to you, may I suggest that you sum up your points and write a
letter to the editor of "Computer"? It seems that B. Meyer used to put these letters
along with the copy of our paper on his Web site. He might consider keeping on
with this practice. Is that fair to you?

But leaving away the casuistics, I'm not sure we really disagree that much 
on the most important points. We 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:"

You said:
>Perhaps a better statement would have been:
>
>"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? By itself, possibly not. However,
>in the context of a well-managed system and software engineering
>process, DBC provides additional capabilities to detect problems of
>this class before they cause a serious impact."
>
>This statement could be debated, but it isn't provably false. 

Was the difference between both statements worth dozens of messages?
Is it not obvious that without "a well-managed system and software engineering
process", you cannot expect a lot of benefits from any software engineering principle?

Regards,

-- 
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: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jeffrey W. Stulin]

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


Hi there:

As my father is fond of saying "You�ve got to play the percentages." By 
this he simply means that while nothing in life is guaranteed, it is 
still a good idea to attempt to arrange matters to give them the best 
opportunity of working out in your favor. And that is the answer to 
Ken�s questions.

If the Ariane software engineers had the reuse mindset, NOT the specific 
mechanisms of Eiffel, but the design by contract reuse mindset, then 
they MAY have written the assertion, and MAY have noticed, while 
integrating the modules, that the assertion would not have been met.

I often specify "impossible" assertions because, human nature being what 
it is, the impossible will happen, and it is exactly these non intuitive 
circumstances which cause the most trouble.

Now 95% of what Ken has stated about testing and so forth is perfectly 
correct. And indeed there is no guarantee that the MAYs above would have 
come to pass. However, it is not unreasonable to speculate that if the 
integrators had been trained with emphasis on the problems of reuse, the 
specification error might have been found. Perhaps likely to be found is 
a bit strong, but I don�t find that stretch much of a sin.

 Furthermore, the papers primary between-the-lines claim, that we better 
learn a reuse mindset since we are (finally) entering the age of 
software reuse, and that the penalties for a reuse error could be 
disastrous, is not a stretch at all. It is simple common sense.

I also find little fault with the implied notion that Eiffel is the 
language which would have had the best chance of finding this particular 
error. My reasoning is simple:  Eiffel is a thin surface for an idea, 
the idea of how to specify and reuse software (design by contract etc.). 
That�s what Eiffel is. Now there may be many areas where Ada would have 
strengths in solving problems and Eiffel would fall flat on its face. 
But not on issues of software reuse. Eiffel is simply the best.

Finally, I have no problem with Ken�s Putting BM & Co. feet to the 
flames. I enjoy seeing ideas stress tested and especially enjoy reading 
about the practical view of those involved in a particular industry. I 
do, however, object to Ken�s tone in some of his postings. As a reader I 
feel that I am being shouted at, and I don�t like it. Please keep 
posting Ken, but post calmer.


Thanks,

Jeffrey W. Stulin 

   

Re: Trust but verify (was 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: 3067 bytes --]


Jeffrey W. Stulin wrote:
> 
> Hi there:
> 
> As my father is fond of saying "You�ve got to play the percentages." By
> this he simply means that while nothing in life is guaranteed, it is
> still a good idea to attempt to arrange matters to give them the best
> opportunity of working out in your favor. And that is the answer to
> Ken�s questions.
> 
> If the Ariane software engineers had the reuse mindset, NOT the specific
> mechanisms of Eiffel, but the design by contract reuse mindset, then
> they MAY have written the assertion, and MAY have noticed, while
> integrating the modules, that the assertion would not have been met.
> 
> I often specify "impossible" assertions because, human nature being what
> it is, the impossible will happen, and it is exactly these non intuitive
> circumstances which cause the most trouble.
> 
> Now 95% of what Ken has stated about testing and so forth is perfectly
> correct. And indeed there is no guarantee that the MAYs above would have
> come to pass. However, it is not unreasonable to speculate that if the
> integrators had been trained with emphasis on the problems of reuse, the
> specification error might have been found. Perhaps likely to be found is
> a bit strong, but I don�t find that stretch much of a sin.
> 
>  Furthermore, the papers primary between-the-lines claim, that we better
> learn a reuse mindset since we are (finally) entering the age of
> software reuse, and that the penalties for a reuse error could be
> disastrous, is not a stretch at all. It is simple common sense.
> 
> I also find little fault with the implied notion that Eiffel is the
> language which would have had the best chance of finding this particular
> error. My reasoning is simple:  Eiffel is a thin surface for an idea,
> the idea of how to specify and reuse software (design by contract etc.).
> That�s what Eiffel is. Now there may be many areas where Ada would have
> strengths in solving problems and Eiffel would fall flat on its face.
> But not on issues of software reuse. Eiffel is simply the best.
> 
> Finally, I have no problem with Ken�s Putting BM & Co. feet to the
> flames. I enjoy seeing ideas stress tested and especially enjoy reading
> about the practical view of those involved in a particular industry. I
> do, however, object to Ken�s tone in some of his postings. As a reader I
> feel that I am being shouted at, and I don�t like it. Please keep
> posting Ken, but post calmer.

Sorry about that. Paraphrasing Twain: "I would have written calmer, but
I ran out of time."

I have no stong objection to the claim that I think you're making:
that DBC _might_ have improved the odds in this case. However, I think
there's a long way to go, for *this particular case*, to make the claim
that DBC would _probably_ have avoided the error. Improving the odds to
20%, for example, is still not "probably"!

> 
> Thanks,
> 
> Jeffrey W. Stulin
> 
> 

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

Re: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[the one and only real true kibo]

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

On Tue, 25 Mar 1997 20:46:02 -0800 in article <3338AA0A.7A79CB24@eiffel.com> posted to comp.lang.eiffel, Bertrand Meyer <bertrand@eiffel.com> wrote:
> Robert S. White wrote:
>  
> > So don't think it is just him that has been put off by people
> > saying that "Design By Contract with the Eiffel language"
> > would have (alone - without simulation or HWIL) testing)
> > prevented the [Ariane] 5 disaster.

> In this particular case there is good reason to think that good
> use of Design by Contract would in fact have evidenced the bug
> early in the development cycle, long before any simulation or
> testing. I think anyone that has practiced the method will agree.
> To repeat the basic point of our (Jezequel's and mine) paper:
> do not reuse without a contract.

> But of course this is not a reason to say there should not be
> simulation, testing, inspections, independent reviews etc. etc.
> I don't recall anyone even coming close to suggesting this in the
> present thread. And our paper certainly does not say anything of
> the sort.

> 	(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.)
>  
> > And it is normal industry practice to have different (from the
> > designers/coders) personnel do the qualification tests (HWIL) test
> > procedures and conduct the tests using the "Black Box" requirements.

> Agreed. Not only normal but excellent practice.

> I like the modified thread title of your message:
> "Trust but verify" although I would make it stronger:
> "Make it trustable, then DON'T trust it" (and so verify it).
> It would be as absurd to use Design by Contract or other
> a priori relability techniques as an excuse not to do a posteriori V & V
> (testing, simulation etc.),
> as it would be to develop in a sloppy way with the expectation that
> testing will uncover any problems.

> If a priori reliability techniques - Design by Contract, static typing,
> genericity, automatic memory management etc. - were a substitute for
> testing, why would Eiffel environments bother to include debugging
> tools? Engineering reliability can only result from the combination of
> several techniques approaching the product from different angles:
> some a priori (building the product right in the first place),
> some a posteriori (not believing that it is right, and test it
> extensively). That this is not an either-or situation
> is so obvious as to be almost a platitude (although one does
> encounter people, including software engineering authors,
> who believe in only the a priori part or only the
> a posteriori part).

> But the need for a posteriori verification 
> is too often an excuse for not applying the proven a priori
> reliability techniques, such as Design by Contract. This is not
> only silly but a recipe for disaster of Ariane-5 proportions.

> It's been amazing in this discussion how some postings have taken
> to task our paper for ideas that are not there.
> The points that it makes are pretty simple, and there for everyone
> to examine (http://www.eiffel.com, link to "Ariane 5 paper");
> after reading most of the discussion, and re-reading the paper,
> I think that its arguments and conclusion are perfectly in line with
> many useful comments made by people who thought they disagreed with it.
> Please check what it really has to say.

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

Bertrand Meyer is a liar and a crook - never misses the opportunity
to peddle his non-working software via his moronic .sig.

Bertrand Meyer will end up in jail one of these days.

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

iQCVAwUBMz1McKlPvImbzLKZAQHi7wP+Jpb/Dpedlozbz/4CRix2JmMApbdIkNMz
ISyckV6ov/R3Cdoa1n0chK5zjWg6C6y1NSW8tA6P1ElbwA1TpgbpPmNENmTq/3vV
Jyz02JWsckhpT9kBTWbsZ7Ar0Ll3/aSNqjbCEYUJrg2qNmDJSNaIXthO4mCHCXIW
2Q2DCinpTEs=
=Ndl+
-----END PGP SIGNATURE-----

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
> 
> >   2. No one ran a full integration test with realistic flight data,
> >which would have
> >      alerted them to the mistake made in #1. Particularly for a
> >distributed mission-
> >      critical system, this should be considered an absolute
> >requirement.
> 
> Yes, this is true. But you have to understand that the mere design of the SRI
> made it very difficult to test it in an other way that performing a launch.
> This is because of the tight integration of hard-to-fool hardware with software
> in a black box functional unit.

We have exactly the same coupling of inertials to flight controls on a
current project, and
we are able to test the coupled system in a black box environment in our
labs, with pilots in the loop, performing the same flight profiles we
expect to see in operation.

Interestingly enough, the IRS for the this project is also "reused" from
a different platform, and there was a proposal to minimize testing of
the system because it had already
been "proven." We were able to quash that "cost-savings" measure before
it gained much
support. However, in an environment with Cost As an Independent Variable
(CAIV), I can
certainly see how easy it would be to adopt such ideas.

> What can be your test strategy for a black box
> containing an inertial central? If the software had been designed with less coupling
> on this particular hardware, you could have test the software vs. a simulation of the
> hardware and its environment. Here, the launch was the test.

Is this what Aerospatiale told you?

> 
> >Although I like some of Mr. Meyer's columns, I found this particular
> >column not only wrong,
> >but dangerous, since it continues the trend of denigrating sound test
> >strategy and common
> >sense system engineering in favor of a software-centric approach.
> 
> I don't see where it denigrates sound testing. IMHO, sound testing *is* needed.
> And testing is effective only if you have a sound test strategy.
> Even more when you use programming by contract. In the paper,
> we just recall that you cannot rely on tests only.

Then why in your message on comp.lang.ada, did you say that to a "lesser
extent"
this was an integration test problem? Not doing this testing was a
*critical*
part of the problem!

Although I think programming by contract is worthwhile, I still contend
that there
is no compelling reason to believe it would have avoided *this
particular problem*, for
two reasons:

1. There is strong evidence to believe that the Ariane IV SRI team did
not see this
   as a particularly important assertion to make (otherwise, they would
not have
   suppressed the check). In the context of what they knew (the Ariane
IV flight
   profile), their opinion was at least understandable if not
justifiable.

2. There is some evidence to indicate that the Ariane V team would not
have considered
   themselves in violation of the assertion, even if it had been
explictly coded. Apparently,
   they did not challenge the decision of the Ariane IV team to suppress
the exception
   checks for the unit. Based on my experience in similar situations, it
is sometimes
   difficult to translate such high-level information as a flight
profile to the specific
   range of parameters to be passed to a particular unit. Additionally,
there is no
   evidence that the software team, reading the source code, had
sufficient systems
   knowledge and experience to detect the violation of the assertion
strictly from reading
   the code.

Based on my experience with aerospace systems, and in particular
integrated inertial and
flight control systems (from the flight controls side), I see this
scenario as entirely
possible. In this case, no amount of documentation at the code level
would have solved
the problem, and no amount of embedded run-time checks would solve the
problem in the
absence of realistic testing.
> 
> --
> 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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robert S. White]

In article <33302A36.7434@lmtas.lmco.com>, GarlingtonKE@lmtas.lmco.com says...

   ...snip...

>We have exactly the same coupling of inertials to flight controls on a
>current project, and
>we are able to test the coupled system in a black box environment in our
>labs, with pilots in the loop, performing the same flight profiles we
>expect to see in operation.

  ...snip...

  I agree with Ken.  At work, we also test inertial systems with 
simulated IMU (IRU) inputs to the INS (IRS) along with GPS satellite 
RF signals.  We do NOT consider our GPS/INS software qualified unless 
it exhibits correct behaviour under all specified high dynamic flight 
profile conditions.  I fail to understand statements that it was not 
possible to test the IRS under normal Ariane-5 launch dynamics.  Just 
model the delta velocities and delta angles as a function of time, feed 
them into the INS (IRS) software and flight control software and see 
if the system performs to spec.  I'll bet you could pay for developing 
several simulation labs (with hardware in the loop) for the cost of 
the failed Ariane 5 launch.

  Any explicit conversions from wide range to narrow range MUST be 
thoroughly tested with simulations if one is going to avoid simple
run time checks (which checks Ada makes very easy to do).  I fail to 
grasp how Eiffel (or PL/1) does a better job at this than Ada.  Ada 
makes you work extra hard to force such a conversion causing the coders 
to always question them.  It seems in this case they were explicitly told
by the systems engineers that there would not be a problem...which
proved to be wrong for the case of the Ariane 5 flight dynamics. In my
experience I would have required that inertial alignment stop immediately
upon rocket release.  Still don't understand why alignment was deliberatly 
continued for the early part of the flight.  Once you are moving. stop
aligning, simple as that.
_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Martin Tom Brown]

In article <5gq97v$iks@flood.weeg.uiowa.edu>
           WhiteR@CRPL.Cedar-Rapids.lib.IA.US "Robert S. White" writes:

> proved to be wrong for the case of the Ariane 5 flight dynamics. In my
> experience I would have required that inertial alignment stop immediately
> upon rocket release.  Still don't understand why alignment was deliberatly 
> continued for the early part of the flight.  Once you are moving. stop
> aligning, simple as that.

According to the report it was a fixup put in to allow Arianne 4
countdowns to hold and restart at the last minute without incurring 
large time penalties for pre-launch reallignment. 

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

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Wolfgang Gellerich]

...looking at this thread's length, you actually _started_ a language war!

  Wolfgang

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robert S. White]

In article <858850946snz@nezumi.demon.co.uk>, Martin@nezumi.demon.co.uk says...

>> continued for the early part of the flight.  Once you are moving. stop
>> aligning, simple as that.
>
>According to the report it was a fixup put in to allow Arianne 4
>countdowns to hold and restart at the last minute without incurring 
>large time penalties for pre-launch reallignment. 

  Sorry, I'm dense.  I had previously (months ago) read the above rationale.  
But it (the question) still festers.  Just how do you do a restart after the 
rocket has been released and left the pad.  Or do you mean that it (the IRS 
software) could not sense exactly when it had been released from the pad?
 
_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[John L. Ahrens]

Robert S. White wrote:

[snip]

> upon rocket release.  Still don't understand why alignment was deliberatly
> continued for the early part of the flight.  Once you are moving. stop
> aligning, simple as that.

I believe that the 40 alignment was to allow for holds of up to 30 sec
after alignment started (at something like T-8 sec) on the Ariane 4.

This requirement didn't exist on the Ariane 5.
-- 
---------------------------------------------------------------------------
John L. Ahrens      206 237-0132  | Everyone should be quick to read,
john@misfit.ca.boeing.com   94-26 | slow to hit 'Reply'
I don't speak for my employer     | and slow to flame.
				  | James 1:19 (internet version)
---------------------------------------------------------------------------

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Roger T.]

In general I agree wholeheartedly with Ken's comments but thought I would
add some extra comments.

Ken Garlington <GarlingtonKE@lmtas.lmco.com> wrote in article 
> Jean-Marc Jezequel wrote:
> > In article <332ED8AB.21E7@lmtas.lmco.com>, Ken Garlington 
> > 
> > >   2. No one ran a full integration test with realistic flight data,
which would have
> > >      alerted them to the mistake made in #1. Particularly for a
distributed mission-
> > >      critical system, this should be considered an absolute
> > >     requirement.
> > 
> > Yes, this is true. But you have to understand that the mere design of
the SRI
> > made it very difficult to test it in an other way that performing a
launch.

The above statement is patently untrue and reflects a shocking ignorance of
the hardware-in-the-loop simulation practices that have been standard in
aerosystems development for decades.

The idea of launching a vehicle *WITH PAYLOAD* and saying that the flight
is meant for testing is ...is ........, gad I am *speechless* at the
idea!!!

> > This is because of the tight integration of hard-to-fool hardware with
software
> > in a black box functional unit.

Bull. 

*All* modern launch systems, on-orbit systems, aeronautical systems,
nautical systems, missile systems that have embedded realtime control
software components should be tested extensively in both all-digital
simulation and hardware-in-the-loop simulation against *every*
mathematically conceivable operational parameter set.

Hardware is in fact *not* hard to fool. I personally have developed
extensive 6DOF HWIL testing facilities that used rate tables, 3DOF tables,
wind tunnels, enviro chambers, etc., etc.. to test missile systems, launch
systems and robotic vehicles in realistic environments.

If you develop intelligent Monte Carlo testing programs covering the entire
range of operational parameters you will catch these simple flaws.

> We have exactly the same coupling of inertials to flight controls on a
> current project, and
> we are able to test the coupled system in a black box environment in our
> labs, with pilots in the loop, performing the same flight profiles we
> expect to see in operation.

Absolutely. This is standard procedure.

> Interestingly enough, the IRS for the this project is also "reused" from
> a different platform, and there was a proposal to minimize testing of
> the system because it had already
> been "proven." We were able to quash that "cost-savings" measure before
> it gained much
> support. However, in an environment with Cost As an Independent Variable
> (CAIV), I can
> certainly see how easy it would be to adopt such ideas.

It is possible to do targeted testing that recognizes previous testing but
that can only be done if the systems analysis shows that the assumptions
used for minimizing testing are valid ones.

> > What can be your test strategy for a black box
> > containing an inertial central?

Real-time HWIL rate table and 3DOF table simulation testing. The output
data from these tests would have immediately shown a trajectory failure
when the problematic profiles were simulated.
 
> If the software had been designed with less coupling
> > on this particular hardware, you could have test the software vs. a
simulation of the
> > hardware and its environment. 

Test both together in full operation.

>Here, the launch was the test.

Brain damage.
 
> Is this what Aerospatiale told you?

;-)
  
> > I don't see where it denigrates sound testing. IMHO, sound testing *is*
needed.
> > And testing is effective only if you have a sound test strategy.
> > Even more when you use programming by contract. In the paper,
> > we just recall that you cannot rely on tests only.

But in this case the flaw would have *IMMEDIATELY* jumped out at any
qualified engineer performing proper HWIL testing.
 
> Although I think programming by contract is worthwhile, I still contend 
that there
> is no compelling reason to believe it would have avoided *this particular
problem*, for
> two reasons:
> 
> 1. There is strong evidence to believe that the Ariane IV SRI team did
> not see this as a particularly important assertion to make (otherwise,
they would

Also even if assertions are included it is still possible that the list of
assertions could suddenly become incomplete when the module is used in
another context.

It all comes back to incomplete domain analysis.

> 2. There is some evidence to indicate that the Ariane V team would not
> have considered  themselves in violation of the assertion, even if it had
been
> explictly coded. Based on my experience in similar situations, it
> is sometimes difficult to translate such high-level information as a
flight
> profile to the specific  range of parameters to be passed to a particular
unit. 

Absolutely right. Which is why HWIL testing of full up flight profiles,
with and without hardware in the loop, is considered standard procedure in
complex dynamic systems development.

>Additionally, there is no evidence that the software team, reading the
source code, had
> sufficient systems knowledge and experience to detect the violation of
the assertion
> strictly from reading the code.

Dead on. 

> Based on my experience with aerospace systems, and in particular
> integrated inertial and flight control systems (from the flight controls
side), I see this
> scenario as entirely possible. In this case, no amount of documentation
at the code 
> level would have solved the problem, and no amount of embedded run-time
checks >would solve the problem in the absence of realistic testing.

Absolutely. 

And realistic testing is only possible if you have engineers, I mean real
engineers not CS people, with knowledge and experience in control theory,
signal processing, orbital mechanics, aeromechanics, structures, materials,
finite element analysis, etc. These people should be integrally involved in
all software design that affects the dynamic performance of a vehicle.

CS people are too willing to put in some hack to that solves a minor
programming problem without realizing that the change may propagate through
the control loops and cause problems with overall performance.

I have seen it firsthand many times. 

For example. When designing target tracking software for guided missiles I
have seen CS trained people start randomly add filtering logic to the
tracking algorithms because of track-lock instabilities. They were baffled
when I told them that their "filter", from a system perspective, was a
feedback compensator and caused the missile to be unable to achieve
intercept.

It tracked beautifully until the end game. But in end-game their software
filter was removing the high rate information that was needed for closure
on a now wildly maneuvering target. The missile tracked wonderfully until
about 200 ft. from the aircraft. It then lost track and flew harmlessly
past the target.

The problem is not the language or the lack or presence of assertions. The
problem is having people doing design who don't understand dynamic systems,
especially feedback.

Roger T.

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Roger T. wrote:
> 
> The problem is not the language or the lack or presence of assertions. The
> problem is having people doing design who don't understand dynamic systems,
> especially feedback.

I appreciate the wisdom of anyone who agrees with me ;) but I do want to
make
sure that my comments are not misunderstood. Even with a highly-trained
team
who has a great deal of knowledge about their product (in this case, an
inertial reference system), it is very easy to have insufficient
information
on, or experience in, the *total* system (missile, aircraft, etc.) in
which
the IRS is used. In fact, the final report makes it clear that useful
data on the Ariane V was left out of the specification. Furthermore,
even
if the information were available, it is very difficult to translate
such
high-level system information into the detailed data necessary to
determine
such things as parameter ranges.

To summarize: I am not saying the IRS team was stupid, lazy, etc. I am
saying
that this is a difficult business. I consider myself a reasonably
confident
flight controls software engineer. However, I also consider myself
human,
and capable of mistakes. That is why I would never permit my work to be
used
without extensive testing by an independent group, including the end
user
(a pilot, in my case).

> 
> Roger T.

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

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jean-Marc Jezequel]

In article <01bc356c$e3aae860$371883cc@beast.advancedsw.com>, "Roger T." <roger@advancedsw.com> writes:
>In general I agree wholeheartedly with Ken's comments but thought I would

>> Although I think programming by contract is worthwhile, I still contend 
>that there
>> is no compelling reason to believe it would have avoided *this particular
>problem*, for
>> two reasons:
>Also even if assertions are included it is still possible that the list of
>assertions could suddenly become incomplete when the module is used in
>another context.

The point is that it works the other way round:
pre/post/inv serve as documenting the assumption *made in the code*, not about the environment.
It is the job of the integration team to check it against the environment.
This can be done either by manual verification when
it is easy as in this particular Araine501 case, or through costly software tests or even
more costly hard/soft tests (Ariane is a commercial program, not a strategic defence program: the
budget constraints are not the same to say the least).

>It all comes back to incomplete domain analysis.

It is clear that we are in a disagreement here. I claim that domain analysis is 
necessarily incomplete (i.e. can you prove that your domain analysis is complete?).
Meanwhile, it is possible to explicitely get all the assumptions present in the code (i.e.
software is not, despite many appearences, black magic). BTW making all the assumptions explicit 
about what does a piece of code is the mere definition of Design by Contract. 
Despite your apparent anger about CS people, can you see my point?


>CS people are too willing to put in some hack to that solves a minor
>programming problem without realizing that the change may propagate through
>the control loops and cause problems with overall performance.

...

>The problem is not the language or the lack or presence of assertions. The
>problem is having people doing design who don't understand dynamic systems,
>especially feedback.

I think you're a bit off-topic here. There are many problems in system design, and 
nobody claimed that design by contract solved them all. I repeat again, because it
seems it does not make it through the brain of some people: the point of the paper
on Ariane 5 was that reusing a component without checking its specification can lead
to a catastroph. Design by contract helps in getting the proper specification of a component.
It replaces by itself neither V&V, system engineering, floral art...

-- 
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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> I repeat again, because it
> seems it does not make it through the brain of some people: the point of the paper
> on Ariane 5 was that reusing a component without checking its specification can lead
> to a catastroph. Design by contract helps in getting the proper specification of a component.

I absolutely agree with both statements:

1. "reusing a component without checking its specification can lead to a
catastrophy."

2. "Design by contract helps in getting the proper specification of a
component."

However, don't you see that #2 does not necessarily lead to #1? This is
the underlying
flaw of your paper, that getting a better specification at the code
level was the critical
factor in getting the Ariane V development team to check the module
specification before reuse.
It certainly may be the case that #2 is useful, possibly even necessary
(although I could
debate the point) to get to #1. However, as the final report makes
clear,
IN THE CASE OF ARIANE 5, #2 WOULD NOT HAVE CAUSED #1. There were simply
too many other
barriers, as explicitly stated in the final report. For example:

1. The Ariane 5 flight profile was not specified to the Ariane IRS
development team. (No
human or machine can check something that they don't know about!)

2. The IRS development team did not see this as an assertion that could
be violated, which
reduces the chance they would have included it - particularly in the
presence of the 80%
throughput factor. (This would not be an issue if the assertion were
static, or was
turned on during test and off during operation, but neither of these
scenarios are proposed
by your paper.)

3. Although testing could have been done to detect the problem, it was
not done. This would
effectively defeat any exectuable assertion.

4. The overall culture was that the software worked on Ariane 4, so it
was not necessary to
do analysis for Ariane 5. In *this* environment, assertions are easily
defeated.

> It replaces by itself neither V&V, system engineering, floral art...

This statement completely contracts your paper, where you say that
Design by Contract would
have saved the Ariane 5. If you wish to claim that Design by Contract,
*coupled* with effective
V&V, system engineering, (and floral art? :) would have saved the
system, then this would
be a much more effective paper. Of course, I would argue that effective
V&V alone would have
saved the system, but the paper would at least have made some sense!

You cannot have it both ways. Either you discuss Design by Contract
(Eiffel) in the abstract,
or you discuss it in terms of the concrete case of Ariane 5. Your paper
attempts to do both,
and gibberish results.

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

[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

[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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

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

> In article <dewar.858568071@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> >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!
>
>  I agree with Robert Dewar.  Please do not start a language war! It

Agreed.  That sort of moronicy is the _last_ thing we need.

> is made crystal clear in the paper that
> *THIS IS NOT A LANGUAGE PROBLEM*
> let me repeat it in case it is not clear:
> *THIS IS NOT A LANGUAGE PROBLEM*

Exactly.  And this has been discussed to death and the same
conclusions reached several times.


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

Yes, CORBA style interface specifications are no help here whatsoever.
None.  Zero.  The problem revolves around explicitly capturing the
semantic context of the "components" so that (re)usage of them will
not go beyond that prescribed scope.  This is non trivial and NO,
repeat NO, programming language currently has more than the most
primitive support for even the most rudimentary aspects required for
this.  While certainly better than nothing, pre and post conditions
should be seen as merely an example of such rudimentary capability.


> I'm willing to discuss this last point, but I will not answer any
> language issue in this thread.

Seems reasonable to me.


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

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Kent Tong]

jsa@alexandria (Jon S Anthony) wrote:

>Yes, CORBA style interface specifications are no help here whatsoever.
>None.  Zero.  The problem revolves around explicitly capturing the
>semantic context of the "components" so that (re)usage of them will
>not go beyond that prescribed scope.  This is non trivial and NO,
>repeat NO, programming language currently has more than the most
>primitive support for even the most rudimentary aspects required for
>this. ...

This is a rather uninformed statement. Have you seen anything
about the B method and the Abstract Machine Notation it uses?
Its support for pre/post conditions even goes further to include
component refinements/implementations.


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Re: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Ranan Fraer]

Kent Tong writes:

|> This is a rather uninformed statement. Have you seen anything
|> about the B method and the Abstract Machine Notation it uses?
|> Its support for pre/post conditions even goes further to include
|> component refinements/implementations.

I'd like to add that the B method is very close to Eiffel in stressing
the role of assertions in program development (not surprisingly, Bertrand Meyer 
and Jean-Raymond Abrial, the inventor of the B method have worked together).

However, the B method goes one step further by requiring to effectively prove
the validity of each assertion. A great deal of the proofs can be dealt with
automatically, but some of them have to be tackled interactively by the user.
Although very tedious, this approach might increase the confidence in the
final product and some standards already require formal proof in the development
of safety-critical systems.

Nonetheless, to fully exploit the potential of the B method one would have to
drop the existing code and redesign all of it from a formal specification.
This was out of question in the case of Ariane, so an alternative would
have been to do plain program verification in the Floyd-Hoare style by
annotating the existing code with assertions and using a program verifier
for Ada like Penelope/Larch.

--- Ranan Fraer
e-mail: rfraer@sophia.inria.fr  
WWW page : http://www.inria.fr/croap/personnel/Ranan.Fraer.html

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

[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

[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

[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

[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

[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

Programming language fanaticism!

[Louis Bastarache]

Anders Pytte wrote:
> 
> 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.

Since programming language design is often based on an ideal vision of
progamming and programs, a pro-language bias is easily confused with a
pro-ideas viewpoint.

Even if I don't use Eiffel, I DID NOT detected a so strong pro-Eiffel
bias in the papers we're discussing. I'd rather like to think it's
pro-idea instead.

It's sad to realize that we can't discuss interesting design ideas if
they're too closely tied to specific language. In this case, the thread
goes crazy and we completly loose focus on the ideas that started the
whole thing. Maybe some day...

-- 
Louis Bastarache                                  Tel:    (418) 656-9109
Evolution Informatique                            Fax:    (418) 656-0558
CP 9338 succ Ste-Foy                            Email: Evolution@ACM.ORG
Quebec (Canada) G1V 4B5

Re: Programming language fanaticism!

[Anders Pytte]

In article <33301728.77D6@acm.org>, evolution@acm.org wrote:

> It's sad to realize that we can't discuss interesting design ideas if
> they're too closely tied to specific language. In this case, the thread
> goes crazy and we completly loose focus on the ideas that started the
> whole thing. Maybe some day...


I agree whole heartedly - that is why I retracted my statements.

I have gotten wound up in the past over the obstinacy of some of my
correspondents whose fervent loyalty to one particular language or another
blinds them to the fact that good programming is more a matter of good
practices that a choice of language. For this reason I was too quick to
respond heatedly to the article which, I admit, stopped short of
explicitly saying that the language was the problem.

I will not waste everyones time by listing the subtle ways in which,
never-the-less, that thesis was implied.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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: FUD (Re: Papers on the Ariane-5 crash and Design by Contract)

[Alexander Anderson]

In article <1997Mar24.174050.14814@schbbs.mot.com>, Brad Appleton
<appleton@chiefs.northbrook.aieg.mot.com> writes

>Probably all of the above. There is a collection of Turing Award
>lectures put out by the ACM called "ACM Turing Award Lectures: The
>First 20 Years (1966-1985)". See the following URL for more info:
>
>   http://www.acm.org/catalog/books/702870.html
>   http://www.acm.org/catalog/books/homepage.html


    Is this online somewhere?


    Do they have the copyright for the lecture?




Sandy

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

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

[Alexander Anderson]

In article <3336010c.1734454@nntp.ix.netcom.com>, William Grosso
<apuleius@ix.netcom.com> writes

>>P.S. By the way, regardless of your views on Ada and on
>>exceptions, Hoare's Turing Award lecture is a masterpiece.
>>Every software engineeer, in my opinion, should have read it
>>
>
>And how do we get hold of a copy ? Is there a book (something
>like "The Turing Lectures") or is it in Hoare's collected papers
>or was it a journal article or .....


    I have no idea when this was, but is this video'd?


    Or available on tape?


    I suspect he's one of those people who holds an audience like
Richard Feynmann.




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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

["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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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
   

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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]

"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]

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

[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

[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

[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

[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

[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

[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

[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

[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

["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

[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

[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

[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

[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

[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

[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: Ariane-5 crash , Eiffel and Ada

[Nick Leaton]

rajt@gco.apana.org.au 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:"
> 
> I must regretfully agree that although the paper started off fairly
> well, it rapidly degenerated into a ( fairly poor ) PR piece for
> Eiffel.
> 
> Considering that "design by contract" ( Meyer's term for the use of
> pre and post conditions ) is
> 1. an _option_ in Eiffel
> 2. equally available ( true the semantics and the integration are
> _different_ from those in Eiffel ) in Ada
> it seems fatuous to claim that Eiffel would have been the silver
> bullet.

An option in all other languages. In practice working on a system
developed in Eiffel, I write assertions, and so do others on the project
because they work. Initially I was skeptical, but I have been convinced.

Equally available is not correct. With different semantics they are not
equally available. When assertions get checked, and how they interact
with inheritance crucial, and you will have a hard job implementing this
in C++, (I'm not sure about Ada as I have never used it but I suspect
that this is also true here)


Nick

Re: Ariane-5 crash , Eiffel and Ada

[Jeffrey W. Stulin]

In article <3345cd60.2092398@news.sydney.apana.org.au>, 
rajt@gco.apana.org.au says...

>
>I must regretfully agree that although the paper started off fairly
>well, it rapidly degenerated into a ( fairly poor ) PR piece for
>Eiffel.
>
>Considering that "design by contract" ( Meyer's term for the use of
>pre and post conditions ) is
>1. an _option_ in Eiffel
>2. equally available ( true the semantics and the integration are 
>_different_ from those in Eiffel ) in Ada
>it seems fatuous to claim that Eiffel would have been the silver
>bullet.
>
>Raj Thomas

The article is a PR piece not for Eiffel, but for the adoption of a 
reuse mindset. Those with a reuse mindset would properly use the 
pre/post conditions etc. Meyer, of course, believes that Eiffel is the 
best implementation language for the principles of a reuse mindset. I 
think he is correct.

Jeffrey W. Stulin 

Re: Ariane-5 crash , Eiffel and Ada

[AdaWorks]

rajt@gco.apana.org.au 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:"

: I must regretfully agree that although the paper started off fairly
: well, it rapidly degenerated into a ( fairly poor ) PR piece for
: Eiffel.

: Considering that "design by contract" ( Meyer's term for the use of
: pre and post conditions ) is
: 1. an _option_ in Eiffel
: 2. equally available ( true the semantics and the integration are 
: _different_ from those in Eiffel ) in Ada
: it seems fatuous to claim that Eiffel would have been the silver
: bullet.

: Raj Thomas
: __________________________________________________________________________

: "It is a tremendous Mitzvah to always be happy! "
:  Reb Nachman of Breslov
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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: Design by Contract in C++ (was Re: Papers on the Ariane-5 crash and Design by Contract)

[Anders Pytte]

On Mon, Mar 24, 1997 4:15 AM, Paul Johnson <mailto:paul.johnson@gecm.com>
wrote: 
>In article <milkweed-2203971952320001@port9.chester.smallmedia.com>, 
>milkweed@plainfield.bypass.com says...
>
>>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!
>
>How well do they handle redefinition and the inheritance of pre and post
>conditions?  Supposing I try to do any of the following:
>
>1: Weaken the precondition of a routine.
>2: Strengthen the precondition of a routine.
>3: Weaken the postcondition of a routine.
>4: Strengthen the postcondition of  a routine.
>5: Weaken the invariant of a class.
>6: Strengthen the invariant of a class.
>
>Eiffel allows me to do 1, 4 and 6.  The others are prohibited by the
>language.  This is an important part of Eiffel, not just a nuance.  Can
>your C++ assertions do the same?
>
>Incidentally, how would it actually handle routine redefinition?  Do I
>have to copy all the assertions from the old version by hand?
>

You have some excellent points, although none of them are applicable to
the Arriane case (regarding which I posted my note). And as I noted, we
did not try to develop all the functionality of Eiffel's assertions - we
were not even thinking of Eiffel at the time. I think the essence of your
point is that the rules for assertion in Eiffel are designed to promote
"design by constract", while my protean assertions place a heavier burden
on the engineer.

You are absolutely right! My point was simply that an engineer with a
strong understanding of "design by constract" could, with care, easily
implement much of the functionality of Eiffel's assertions. Having
actually used most the techniques I describe, I can confidently say that
they work better than an Eiffel engineer might expect!

For example, regarding your final point.

If when hiding behavior (i.e. override and not call the inherited
behavior) then one needs to re-implement assertions. But often the
contract has changed in this case. Otherwise, cut and copy is not that
tedious! When modifying behavior (i.e. override and call the inherited
behavior), one usually wants all of the original assertions in place.

Items 1-6 could be easily accomplished by redefining assertions in the
manner I described, in method overrides. But the language itself would not
report 2, 3 or 5 as an error. The engineer obviously must know what s/he
is doing!

Another danger of the C++ macros which you overlooked regards multiple
returns from a C++ function. One must take steps to ensure that ENSURE is
actually called! Again, I am not claiming C++ is equal to Eiffel; I am
merely objecting to claims that "design by contract" is an impracticle
strategy using alternatives to Eiffel.

Anders.


--

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

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

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Karel Th�nissen]

nouser@nohost.nodomain wrote:
> 
> There are multiple ways of reducing the probability of a catastrophic
> software defect like Ariane 5.  Two of them are the following.
> (1) You can test more, enable runtime checks, and implement multiple
> levels of exception handling and recovery.  (2) You can adopt a Design
> by Contract methodology.
> 
> (1) strikes me as more fundamental and powerful than (2).  Design
> by Contract is clearly useful, but secondary if a system isn't built
> on a solid and safe substrate in the first place.  Of course, (1)
> costs more money and may also reduce payloads, but that additional
> expense is paid back in lowered risk.

I disagree: ASSERTIONS COULD HAVE DISQUALIFIED THE SOFTWARE EVEN BEFORE
TESTING,
THE USE OF ASSERTIONS DURING TESTING DEPENDS ON THE QUALITY OF THE TEST
SET
AND ON-FLIGHT THERE IS NO USE WHATSOEVER FOR ASSERTIONS 

The problem is: no amount of runtime checks, tests, contracts or
assertions can gracefully handle on-flight the type of error that
occurred. It is just impossible to convert a 64-bit number with at least
17 significant bits into 16-bit representation. This 16-bit software (as
far as the representation of flight data is concerned) should not have
been taken into space. Truncation or provision of best guesses instead
of exact data would not have stalled the system, but the error in
trajectory calculations would accumulate to such heights that self
destruction becomes inevitable, albeit perhaps a few seconds later than
now.

THERE COULD NOT POSSIBLY HAVE BEEN A ROLE FOR ASSERTIONS ON-FLIGHT

a) Having the assertions unchecked will cause exceptions somewhere later
in the program (with probably the same disasterous effect) or give
erroneous results. Very likely, either case will give raise to the
destruction of the launcher. The only thing we do know for sure then is
that program behaviour becomes hard to predict. As the software was not
performing an essential task (oh irony), the latter may not have given
problems for this launch (by luck rather than science), but from a
software engineering point of view that makes no difference. It was
known that the calculations were, in fact, superfluous, but the software
was believed to be reliable and harmless and that was proven wrong. This
time, it was an exception gone astray in the superfluous subsystem, next
time it is in an essential part.

b) Having the assertions checked on flight does not bring us much
further either, because there is no way to handle the conversion
problem, except by having a similar routine with, say, 32-bit
representation. But if we expect that 32-bit routine to be used, we
would not use the 16-bit software in the first place. And still then,
there is always a risc that even more bits than 32 may be needed. At
this point an assumption about the maximum horizontal bias has to be
made and any assumption about the outside world can prove wrong. It was
assumed that 16 bits were sufficient, and under that assumption the
software was correct. And for the programming team there was no reason
to believe that the 16 bit representation would cause problems, as the
software was developed for Ariane 4. Unfortunately, that assumption was
neither specified as a clear ex-ante or ex-post specification for the
software. This allowed for reuse outside the applicability range of the
software.

!!! THIS SOFTWARE SHOULD NOT HAVE BEEN TAKEN INTO FLIGHT FOR ARIANE 5,
NO MATTER HOW MANY SAFEGUARDS !!!

However, assertions and the like can be very useful on the ground.
Proper tools can signify the assumptions and report them as ex-post
specifications of the software module as a whole. Assumptions are all
those assertions that raise exceptions that are not properly caught and
handled by exception handlers. Then during assembly for Ariane 5, one
would have seen that one of the assumptions regarding the SRI was not
met. Assertions in this respect can be viewed as reporting aid from the
programmer who made an essential design decision somewhere deep down in
the software (it was documented somewhere, so the programmer(s) were
aware of this design decision), up to those who are going to test,
verify or use the software. Any tester or verifier worth his income
would have noticed the invalid assumption (for Ariane 5) that emerged
from the implementation.

Of course, there still is the possibility that these ex-post
specifications would not be used, but that at least supposes an extra
level of incompentency or negligence (by this I do not want to insult
the people on the Ariane project by suggesting that currently there is
incompetence or negligence).

Notice, that hand-crafted documentation or free formatted in-code
comments are too unreliable for this purpose and that normal condition
testings in the software do not necessarily signify assumptions.
Therefore, assertions as a means of documentation add an additional
layer of security that could not easily and reliably be obtained by
other coding practices.

Of course, there are a lot of spots in the entire SRI project where
different decisions at the time may have saved the launcher. But most
decisions seemed perfectly reasonable, both the decisions during the
development of the system and later for its reuse.

Testing might have revealed the software fault, this time, but next time
a fault will get uncaught. Surely, now that we know the bug, it is
simple to think of nice tests that would have relealed the bug
cheaplier. Testing can reveale the presence of bugs not the absence. At
some point one must stop testing, and the team thought it had arived at
that point. Testing was not forgotten, but argued obsolete. Maybe this
is not entirely true:

FLIGHT 501 WAS A TEST FLIGHT, SO THE SOFTWARE WAS TESTED, AND THE
PRESENCE OF BUGS WAS PROVEN, THEREFORE TEST FLIGHT 501 WAS A SUCCESS.

Any piece of software has a applicability scope. Outside this scope the
software becomes indeterminate. Assertions are an important (and
automatic!) aid in the documentation of this applicabilty scope. NEVER
DO WITHOUT THEM.

Groeten, Karel

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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Nick Leaton]

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


Karel Th�nissen wrote:


> THERE COULD NOT POSSIBLY HAVE BEEN A ROLE FOR ASSERTIONS ON-FLIGHT
> 
> a) Having the assertions unchecked will cause exceptions somewhere later
> in the program (with probably the same disasterous effect) or give
> erroneous results. Very likely, either case will give raise to the
> destruction of the launcher. The only thing we do know for sure then is
> that program behaviour becomes hard to predict. As the software was not
> performing an essential task (oh irony), the latter may not have given
> problems for this launch (by luck rather than science), but from a
> software engineering point of view that makes no difference. It was
> known that the calculations were, in fact, superfluous, but the software
> was believed to be reliable and harmless and that was proven wrong. This
> time, it was an exception gone astray in the superfluous subsystem, next
> time it is in an essential part.

If I generalise what you say, running production code with assertions 
will not make a difference. However, there are things you can do. If
there
was an exception handler built, then it can make choices. In the Ariane
case,
an exception from the SRI post launch can be ignored. If you were
writting
a system that involved file handling then it could, perhaps try
something
to make a file handle or space available. For example, prompt the user
to empty a trash can.

> However, assertions and the like can be very useful on the ground.
> Proper tools can signify the assumptions and report them as ex-post
> specifications of the software module as a whole. Assumptions are all
> those assertions that raise exceptions that are not properly caught and
> handled by exception handlers. Then during assembly for Ariane 5, one
> would have seen that one of the assumptions regarding the SRI was not
> met. Assertions in this respect can be viewed as reporting aid from the
> programmer who made an essential design decision somewhere deep down in
> the software (it was documented somewhere, so the programmer(s) were
> aware of this design decision), up to those who are going to test,
> verify or use the software. Any tester or verifier worth his income
> would have noticed the invalid assumption (for Ariane 5) that emerged
> from the implementation.
> 
> Of course, there still is the possibility that these ex-post
> specifications would not be used, but that at least supposes an extra
> level of incompentency or negligence (by this I do not want to insult
> the people on the Ariane project by suggesting that currently there is
> incompetence or negligence).
> 
> Notice, that hand-crafted documentation or free formatted in-code
> comments are too unreliable for this purpose and that normal condition
> testings in the software do not necessarily signify assumptions.
> Therefore, assertions as a means of documentation add an additional
> layer of security that could not easily and reliably be obtained by
> other coding practices.

From personal experience I have found this to be the case. Being able to
test your comments is very useful!


-- 

Nick

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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Karel Th�nissen]

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


Nick Leaton wrote:
> 
> Karel Th�nissen wrote:
> 
> > THERE COULD NOT POSSIBLY HAVE BEEN A ROLE FOR ASSERTIONS ON-FLIGHT

> If I generalise what you say, running production code with assertions
> will not make a difference. However, there are things you can do. If
> there
> was an exception handler built, then it can make choices. In the Ariane
> case,
> an exception from the SRI post launch can be ignored. If you were
> writting
> a system that involved file handling then it could, perhaps try
> something
> to make a file handle or space available. For example, prompt the user
> to empty a trash can.

True, I am sorry, let me clarify this a bit more. I fully agree that
exception handling in production code is in general very valuable (and
often the only reasonble way to go), and the examples you gave point out
this fine. And indeed in the case of the SRI system, the exception could
have been confined to the allignment software, as it was superfluous at
that point. But what if it was not in superfluous subsystem? You cannot
shut down the module that calculates the flight data. This bug could
have creeped in there just as well, because testing for both subsystems
was as strict. Or what about a file system that prompts for human
interaction in a overnight batch run? Sometimes there are no
possibilities for recovery. And IMHO this conversion problem is an
example of just that. But very likely there are a lot of exceptions
handlers in this SRI software which do their work as intended and that
could not be left out.

> From personal experience I have found this to be the case. Being able to
> test your comments is very useful!
>  
> Nick

I fully agree, and every one should do this. But do you get this taught
in software engineering class or do software engineering methods or
languages enforce this? Do project managers require this?
To further clarify my/our point. Right now tens of thousands of
programmers wish that assumptions were more accurately documented in the
code - on the spot - if only by means of informal comments. These
programmers are making our software ready for the Y2000, they know the
assumptions made, if only they could easily find those spots.

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Nick Leaton]

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


Karel Th�nissen wrote:
 
> > From personal experience I have found this to be the case. Being able to
> > test your comments is very useful!
> 
> I fully agree, and every one should do this. But do you get this taught
> in software engineering class or do software engineering methods or
> languages enforce this? Do project managers require this?
> To further clarify my/our point. Right now tens of thousands of
> programmers wish that assumptions were more accurately documented in the
> code - on the spot - if only by means of informal comments. These
> programmers are making our software ready for the Y2000, they know the
> assumptions made, if only they could easily find those spots.

I was very sceptical about assertions until I started using Eiffel. I am
now converted.

I would however be interested in a discussion on how exceptions should
be handled.

1) Report and fail
2) Have logic. In the Ariane case, just shut down the SRI after launch
3) Fix and retry - could just be wait and retry
4) Try method B

Are there any others?

-- 

Nick

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: Please do not start a language war (was Re: Papers on the Ariane-5 crash and Design by Contract

[Jon S Anthony]

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

> It is clear that we are in a disagreement here. I claim that domain
> analysis is necessarily incomplete (i.e. can you prove that your
> domain analysis is complete?).  Meanwhile, it is possible to
> explicitely get all the assumptions present in the code (i.e.
> software is not, despite many appearences, black magic). BTW making
> all the assumptions explicit about what does a piece of code is the
> mere definition of Design by Contract.

Sort of.  But if you think that any more than a few percent of these
assumptions can be called out via such rudimentary means as simple
minded pre/post/inv on signatures, or that the Ariane case is one of
them, you and Meyer are smoking some pretty potent dope.

/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

[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

["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

[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

[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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Stuart Yeates]

Nick Leaton (nickle@calfp.co.uk) wrote:

: 1) Report and fail
: 2) Have logic. In the Ariane case, just shut down the SRI after launch
: 3) Fix and retry - could just be wait and retry
: 4) Try method B

5) (2) and report
6) (3) and report
7) (4) and report

stuart
-- 
         stuart yeates <stuart@cosc.canterbury.ac.nz> aka `loam'
                  you are a child of the kernel space 
            no less than the daemons and the device drivers,
                   you have a right to execute here.

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

[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

[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

[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: FUD (Re: Papers on the Ariane-5 crash and Design by Contract)

[Bertrand Meyer]

Dale Stanbrough writes:

>> Oh dear, more FUD being spread

FUD, if I am not mistaken, means "Fear, Uncertainty and Doubt"
and I am the one who, in Mr. Stanbrough's view, is spreading it
to unsuspecting Usenet readers. Pretty nasty stuff!
 
A bit of rhetorical exaggeration perhaps? The case in point:
I quoted verbatim a 1980 text where Tony Hoare criticizes Ada
exceptions. Mr. Stanbrough quotes a 1987 book preface in which
Hoare appears more gracious about Ada.

I am grateful to Mr. Stanbrough for bringing up the second text,
which I did not know (although I am curious about what was
in the numerous ellipses "..." of his extract).

But in what way does the existence of that later Hoare
text make me a spreader of Fear, Uncertainty
and Doubt? I did not write "Tony Hoare is against Ada";
I stated that Hoare has criticized Ada exceptions. This is 
for everyone to see in either the text of his 1980 Turing lecture,
available in the Communications of the ACM and also
republished for example in "Essays in Computing Science"
(the collection of his major papers), ed. by Cliff B. Jones,
Prentice Hall, 1989, where it figures very prominently
(first place, regardless of the chronological order used for
the other articles), and which does not include the 1987 preface,
not even quoted in the book's bibliography.

I hope that without calling each other names we can agree
that:

        - Some people have criticized the Ada exception
          mechanism (my original point, a small aside in
          a text on something else).

        - Hoare was one of them (although, as I pointed out
          in my second message, it is not clear on further
          examination whether his objections were to exceptions
          in general or just those of Ada).

        - He has, more recently, made positive comments
          about Ada in at least one text, a preface to a book
          on Ada.

All this seems fairly obvious (the third point thanks to
Mr. Stanbrough) and factual, rather than subject to fighting.
Since the whole thing was, as pointed out, started by a 10-word
aside ("Although it is possible to criticize the Ada exception
mechanism")in the paper by Jean-Marc Jezequel and myself
at http://www.eiffel.com and in IEEE Computer ,
there does not seem to be much reason for more rhetoric
on this particular point.

P.S. By the way, regardless of your views on Ada and on
exceptions, Hoare's Turing Award lecture is a masterpiece.
Every software engineeer, in my opinion, should have read it
-- 
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: FUD (Re: Papers on the Ariane-5 crash and Design by Contract)

[William Grosso]

On Sun, 23 Mar 1997 18:08:53 -0800, Bertrand Meyer
<bertrand@eiffel.com> wrote:
>
>P.S. By the way, regardless of your views on Ada and on
>exceptions, Hoare's Turing Award lecture is a masterpiece.
>Every software engineeer, in my opinion, should have read it
>

And how do we get hold of a copy ? Is there a book (something
like "The Turing Lectures") or is it in Hoare's collected papers
or was it a journal article or .....


Cheers,

Andy

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

[Brad Appleton]

In article <3336010c.1734454@nntp.ix.netcom.com>,
apuleius@ix.netcom.com (William Grosso) writes:
>On Sun, 23 Mar 1997 18:08:53 -0800, Bertrand Meyer
><bertrand@eiffel.com> wrote:
>>
>>P.S. By the way, regardless of your views on Ada and on
>>exceptions, Hoare's Turing Award lecture is a masterpiece.
>>Every software engineeer, in my opinion, should have read it
>>
>
>And how do we get hold of a copy ? Is there a book (something
>like "The Turing Lectures") or is it in Hoare's collected papers
>or was it a journal article or .....

Probably all of the above. There is a collection of Turing Award
lectures put out by the ACM called "ACM Turing Award Lectures: The
First 20 Years (1966-1985)". See the following URL for more info:

   http://www.acm.org/catalog/books/702870.html
   http://www.acm.org/catalog/books/homepage.html

Cheers!
-- 
 Brad Appleton <bradapp@enteract.com> | http://www.enteract.com/~bradapp/
  "And miles to go before I sleep."   |  2400+ WWW links on CS & Sw-Eng

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

[William Clodius]

William Grosso wrote:
> 
> <snip>
> And how do we get hold of a copy ? Is there a book (something
> like "The Turing Lectures") or is it in Hoare's collected papers
> or was it a journal article or .....
> <snip>

The Turing Award lecture is generally (always?) published in
Communications of the ACM. The first twenty years of lectures, including
that of Hoare, is published in

Robert Ashenhurst and Susan Graham, "ACM Turing Award Lectures: The
First 20 Years (1966-1985)," ACM Press, New York,  1987. ISBN:
0-89791-183-0 

It can be ordered at any bookstore or via ACM directly 

http://www.acm.org/catalog/books/homepage.html

-- 

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: FUD (Re: Papers on the Ariane-5 crash and Design by Contract)

[Bertrand Meyer]

William Grosso wrote:
  
> And how do we get hold of a copy 
> [of Hoare's Turing lectures]?
> Is there a book (something
> like "The Turing Lectures") or is it in Hoare's
> collected papers
> or was it a journal article or .....

All of the above:


C.A.R. Hoare, The Emperor's Old Clothes
	Communications of the ACM
	vol. 24, no. 2, pages 75-83
	February 1981

Also as chapter 1 of:

	C.A.R. Hoare and Cliff B. Jones (eds)
	Pages 1-18
	Essays in Computing Science
	Prentice Hall, International Series in Comp. Sc.
	Hemel Hempstead (U.K.)
	1989

and in
	ACM Turing Award lectures
	The first twenty years: 1966-1985
	Pages 143-161
	ACM Press / Addison-Wesley
	1987
-- 
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

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

Manners (was Re: Papers on the Ariane-5 crash and Design by Contract)

[Bertrand Meyer]

Robert Dewar wrote:
 
> 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.

No, no, it's not that simple. What you write is applicable to
the crazies and hate-mongerers. My complaint was about
the case of someone who sounds reasonable (probably is), makes
sensible arguments (you may think he is wrong, even dead
wrong, but he is worth listening to and answering) - and suddenly
loses his good manners and starts throwing invectives at you.
Then killfiles and the like won't do the job, if only the person
may have gained some credibility, and may in fact deserve it.

I apologize for using bandwidth for such meta-comments; it
seems inevitable that once in a while we have to spend a little
time (a *little* time) on the terms of the debate rather
than the debate itself, which remains the only goal.


-- 
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: Manners (was Re: Papers on the Ariane-5 crash and Design by Contract)

[the one and only real true kibo]

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

On Mon, 24 Mar 1997 13:22:44 -0800 in article <3336F0A4.5656AEC7@eiffel.com> posted to comp.lang.eiffel, Bertrand Meyer <bertrand@eiffel.com> wrote:
> Robert Dewar wrote:
>  
> > 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.

> No, no, it's not that simple. What you write is applicable to
> the crazies and hate-mongerers. My complaint was about
> the case of someone who sounds reasonable (probably is), makes
> sensible arguments (you may think he is wrong, even dead
> wrong, but he is worth listening to and answering) - and suddenly
> loses his good manners and starts throwing invectives at you.
> Then killfiles and the like won't do the job, if only the person
> may have gained some credibility, and may in fact deserve it.

Bertrand Meyer never said anything sensible in his life and has
no credibility.  Killfile the dumb motherfucker.


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

iQCVAwUBMzc4AalPvImbzLKZAQEUUwQAxao/z0ydC0wyvDIpa/88uclZI+3YgWRJ
IxkW9pxu9GTaeEc5KrPXTExxHQg4OlhRRXRyfLwy2DYQh6/CijTZH9q6poqPxjEn
a5bmfS1WvFk754VW8PYEbaAONYuBfsARm9bdos4iTLERPFnUAXOcJknvAQUoR/Jv
F+RDnJoXKtU=
=aVEl
-----END PGP SIGNATURE-----

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

[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

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

Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Wolfgang Reddig]

[request for Eiffel-stype assertion macros deleted]

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


But these macros dont cover some of the most important aspects of Eiffel-style
assertions. In Eiffel, require, ensure and the class invariants are only
triggered for "remote-calls" (if I remember well that's what B. Meyer calls it).
Methods that directly or indirectly call methods with current (this,
self, ...) as the receiver wont re-trigger any assertions. This is important
because it 1) prevents endless loops caused by assertions and 2) allows
objects to be inconsistent between entrance end exit of a "remote call".
Consider a 'Car' class having an invariant which states that cars have
either two or four doors. Lets assume there is a method 'make_limousine', which
adds two doors (forgive the C++ notation, but I'm not very familiar with 
the syntax of Eiffel):

void Car::make_limousine()
{
   require(no_of_doors() == 2)
   ensure(no_of_doors() == 4)

   add_door(); // this would (incorrectly) cause an invariant failure!
   add_door();
}

In short, C/C++ asserts do not only lack inheritance of assertions, they
also dont support this kind of transaction-like concept. In fact, you
can simulate much of Eiffel-style assertions in C++, but it requires
a little more work in order to be (nearly) as powerful as Eiffel. For example,
the 'require' macro may declare a local object whose constructor increments
a counter in the object. If the counter is equal to 1, then check the
expression passed to 'require' etc. The destructor should of course decrement
the counter and can automatically trigger the invariant if the counter
equals 1.

Regards,
Wolfgang
+---------------------------------------------------------------------+
|  Wolfgang Reddig                |  e-mail:                          |
|  Institut fuer Informatik III   |  wolfgang@informatik.uni-bonn.de  |
|  Roemerstrasse 164              |                                   |
|  53117 Bonn                     |  Tel.: (49) 228 / 73-4513         |
|  Germany                        |  Fax:  (49) 228 / 73-4382         |
+---------------------------------------------------------------------+

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Anders Pytte]

In article <5h6jc0$jvu@news.rhrz.uni-bonn.de>,
wolfgang@uran.informatik.uni-bonn.de (Wolfgang Reddig) wrote:

> But these macros dont cover some of the most important aspects of Eiffel-style
> assertions. In Eiffel, require, ensure and the class invariants are only
> triggered for "remote-calls" (if I remember well that's what B. Meyer
calls it).
> Methods that directly or indirectly call methods with current (this,
> self, ...) as the receiver wont re-trigger any assertions. This is important
> because it 1) prevents endless loops caused by assertions and 2) allows
> objects to be inconsistent between entrance end exit of a "remote call".
> Consider a 'Car' class having an invariant which states that cars have
> either two or four doors. Lets assume there is a method
'make_limousine', which
> adds two doors (forgive the C++ notation, but I'm not very familiar with 
> the syntax of Eiffel):
> 
> void Car::make_limousine()
> {
>    require(no_of_doors() == 2)
>    ensure(no_of_doors() == 4)
> 
>    add_door(); // this would (incorrectly) cause an invariant failure!
>    add_door();
> }
> 
> In short, C/C++ asserts do not only lack inheritance of assertions, they
> also dont support this kind of transaction-like concept. In fact, you
> can simulate much of Eiffel-style assertions in C++, but it requires
> a little more work in order to be (nearly) as powerful as Eiffel. For example,
> the 'require' macro may declare a local object whose constructor increments
> a counter in the object. If the counter is equal to 1, then check the
> expression passed to 'require' etc. The destructor should of course decrement
> the counter and can automatically trigger the invariant if the counter
> equals 1.


Good observation! Since I had not actually tried out my suggested approach
to class invariance, I had not encountered the limitation you pointed out.
Since posting my suggestions, I thought of some of other problems with my
approach. As you say, "it requires a little more work in order to be
(nearly) as powerful as Eiffel".

Sigh - my apologies to anyone who thought i had worked out all of the
details. I hope the changes suggested below will make this technique more
useful.

For one thing, I need to push the instantiation onto the stack of
assertions along with the identifier, so that hiding only occurs when
calling inherited (i.e. the same method on the same instance). Also, if
the identifiers were to be scoped (allowing use of the same identifier in
different methods or classes), I would need to push the method or class
signature on the stack as well. 

Thanks for the suggestion of adding a counter to distinguish remote calls.
While I agree something like that is necessary for enforcing invariance,
could you explain why it is desirable for require and ensure? I have not
encountered such a need in my use of these.

Instead of incrementing a counter, I suggest the following. ENTER pushes a
lock on invariant assertions onto the assertion stack(lock_invariance).
EXIT pops the immediate lock_invariance off the stack, then tests to see
if invariance was previously locked for this instance. I suppose
ENTER_INVARIANT and EXIT_INVARIANT could be used anywhere the object is
known to stay consistent, but they are intended just for use in
CheckInvariants() to avoid recursion.

enum EAssertionType {eRequire, eEnsure, eInvariant, eCheck};

#define ENTER_INVARIANT                                           \
   long assertionStackSize = globalAssertionStack->GetSize()      \

#define EXIT_INVARIANT                                            \
   globalAssertionStack->SetSize(assertionStackSize)              \
 
#define ENTER                                                     \
   long assertionStackSize = globalAssertionStack->GetSize()      \
   globalAssertionStack->Push(this, lock_invariance);             \

#define EXIT                                                      \
   globalAssertionStack->SetSize(assertionStackSize)              \
   if (!globalAssertionStack->Contains(this, lock_invariance))    \
      CheckInvariants();                                          \
 
#define REQUIRE(identifier, expression)                           \
   if (!globalAssertionStack->Contains(this, identifier))         \
   {                                                              \
      globalAssertionStack->Push(this,  identifier);              \
      if (!(expression))                                          \
         (AssertionFailed(__FILE__, __LINE__, eRequire,           \
            #identifier, #expression));                           \
  }                                                               \

And so on for ENSURE, CHECK and INVARIANT. Here is how I would apply these
macros:

class Person: public LifeForm
{
private:

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

protected:

   virtual void CheckInvariants()
   {
      ENTER_INVARIANT;

      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));
      
      LifeForm::CheckInvariants();
      
      EXIT_INVARIANT;
   }

public:

   void Marry (Person other)
   {
      ENTER;

      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;
   }
}

As has been pointed out by Paul Johnson, there is no protection in this
scheme of overriding assertions against strengthening a require or
weakening an ensure or invariant. Neither are requires and ensures
automatically inherited in a method override. So the engineer must beware!

Anders.

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

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Wolfgang Reddig]

In article <milkweed-2403972252230001@port2.chester.smallmedia.com>, milkweed@plainfield.bypass.com (Anders Pytte) writes:
>In article <5h6jc0$jvu@news.rhrz.uni-bonn.de>,
>wolfgang@uran.informatik.uni-bonn.de (Wolfgang Reddig) wrote:
>
>> But these macros dont cover some of the most important aspects of Eiffel-style
>> assertions. In Eiffel, require, ensure and the class invariants are only
>> triggered for "remote-calls" (if I remember well that's what B. Meyer
>calls it).
>> Methods that directly or indirectly call methods with current (this,
>> self, ...) as the receiver wont re-trigger any assertions. This is important
>> because it 1) prevents endless loops caused by assertions and 2) allows
>> objects to be inconsistent between entrance end exit of a "remote call".
>> Consider a 'Car' class having an invariant which states that cars have
>> either two or four doors. Lets assume there is a method
>'make_limousine', which
>> adds two doors (forgive the C++ notation, but I'm not very familiar with 
>> the syntax of Eiffel):
>> 
>> void Car::make_limousine()
>> {
>>    require(no_of_doors() == 2)
>>    ensure(no_of_doors() == 4)
>> 
>>    add_door(); // this would (incorrectly) cause an invariant failure!
>>    add_door();
>> }
>> 
>> In short, C/C++ asserts do not only lack inheritance of assertions, they
>> also dont support this kind of transaction-like concept. In fact, you
>> can simulate much of Eiffel-style assertions in C++, but it requires
>> a little more work in order to be (nearly) as powerful as Eiffel. For example,
>> the 'require' macro may declare a local object whose constructor increments
>> a counter in the object. If the counter is equal to 1, then check the
>> expression passed to 'require' etc. The destructor should of course decrement
>> the counter and can automatically trigger the invariant if the counter
>> equals 1.
>
>
>Good observation! Since I had not actually tried out my suggested approach
>to class invariance, I had not encountered the limitation you pointed out.
>Since posting my suggestions, I thought of some of other problems with my
>approach. As you say, "it requires a little more work in order to be
>(nearly) as powerful as Eiffel".
>
>Sigh - my apologies to anyone who thought i had worked out all of the
>details. I hope the changes suggested below will make this technique more
>useful.
>
>For one thing, I need to push the instantiation onto the stack of
>assertions along with the identifier, so that hiding only occurs when
>calling inherited (i.e. the same method on the same instance). Also, if
>the identifiers were to be scoped (allowing use of the same identifier in
>different methods or classes), I would need to push the method or class
>signature on the stack as well. 
>
>Thanks for the suggestion of adding a counter to distinguish remote calls.
>While I agree something like that is necessary for enforcing invariance,
>could you explain why it is desirable for require and ensure? I have not
>encountered such a need in my use of these.

A must admit that I cannot come up with a practical exmaple, though I'm sure
that I had this problem sonme time ago. But consider a method 'f' which 
(directly or indirectly) calls a method 'g' in its 'require' clause and 
vice versa - you have an endless loop. Another problem might occur with 
'old' expressions: if the system were to check postconditions not only for 
remote calls, a stack of shallow copies would have to be maintained per 
object. This could at least lead to performance problems.

(BTW, calls from within a require, ensure or invariant are completely un-
checked in my implementation - is that what Eiffel compilers do, too?)

>
>Instead of incrementing a counter, I suggest the following. ENTER pushes a
>lock on invariant assertions onto the assertion stack(lock_invariance).

In our projects this would probably lead to performance problems. Accessing
counters, however, is fast. Remember that the counters need to be
in/decremented in each and every non-static member function.

>EXIT pops the immediate lock_invariance off the stack, then tests to see
>if invariance was previously locked for this instance. I suppose
>ENTER_INVARIANT and EXIT_INVARIANT could be used anywhere the object is
>known to stay consistent, but they are intended just for use in
>CheckInvariants() to avoid recursion.
>
>enum EAssertionType {eRequire, eEnsure, eInvariant, eCheck};
>
>#define ENTER_INVARIANT                                           \
>   long assertionStackSize = globalAssertionStack->GetSize()      \
>
>#define EXIT_INVARIANT                                            \
>   globalAssertionStack->SetSize(assertionStackSize)              \
> 
>#define ENTER                                                     \
>   long assertionStackSize = globalAssertionStack->GetSize()      \
>   globalAssertionStack->Push(this, lock_invariance);             \
>
>#define EXIT                                                      \
>   globalAssertionStack->SetSize(assertionStackSize)              \
>   if (!globalAssertionStack->Contains(this, lock_invariance))    \
>      CheckInvariants();                                          \
> 
>#define REQUIRE(identifier, expression)                           \
>   if (!globalAssertionStack->Contains(this, identifier))         \
>   {                                                              \
>      globalAssertionStack->Push(this,  identifier);              \
>      if (!(expression))                                          \
>         (AssertionFailed(__FILE__, __LINE__, eRequire,           \
>            #identifier, #expression));                           \
>  }                                                               \
>
>And so on for ENSURE, CHECK and INVARIANT. Here is how I would apply these
>macros:
>
>class Person: public LifeForm
>{
>private:
>
>   EGender gender;
>   EStatus status;
>   Boolean married;
>   Person spouse;
>
>protected:
>
>   virtual void CheckInvariants()
>   {
>      ENTER_INVARIANT;
>
>      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));
>      
>      LifeForm::CheckInvariants();
>      
>      EXIT_INVARIANT;
>   }
>
>public:
>
>   void Marry (Person other)
>   {
>      ENTER;
>
>      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;
>   }
>}

But the 'ENTER' and 'EXIT' macros are not really needed. In fact, if the
programmer forgets 'EXIT', no more checks are performed until the program
terminates? That's why my 'require' macro constructs a local object whose
destructor triggers the invariant.

void Person::Marry(Person other)
{
   require(!married && !other.married && 
           gender != other.gender)
   ensure(married && spouse == other)

   // the wedding...
   Return;
}

One of the ugly things in our approach is the 'Return' - it is needed to
trigger the postcondition check. On the other hand, there is no problem
with multiple exits.

>
>As has been pointed out by Paul Johnson, there is no protection in this
>scheme of overriding assertions against strengthening a require or
>weakening an ensure or invariant. Neither are requires and ensures
>automatically inherited in a method override. So the engineer must beware!

Absolutely true. I dont program anything without my assertions, but they
are far from the power of Eiffel.

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

Regards,
Wolfgang

+---------------------------------------------------------------------+
|  Wolfgang Reddig                |  e-mail:                          |
|  Institut fuer Informatik III   |  wolfgang@informatik.uni-bonn.de  |
|  Roemerstrasse 164              |                                   |
|  53117 Bonn                     |  Tel.: (49) 228 / 73-4513         |
|  Germany                        |  Fax:  (49) 228 / 73-4382         |
+---------------------------------------------------------------------+

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Anders Pytte]

In article <5h8uja$p9o@news.rhrz.uni-bonn.de>,
wolfgang@uran.informatik.uni-bonn.de (Wolfgang Reddig) wrote:

> 
> But the 'ENTER' and 'EXIT' macros are not really needed. In fact, if the
> programmer forgets 'EXIT', no more checks are performed until the program
> terminates? That's why my 'require' macro constructs a local object whose
> destructor triggers the invariant.
> 
> void Person::Marry(Person other)
> {
>    require(!married && !other.married && 
>            gender != other.gender)
>    ensure(married && spouse == other)
> 
>    // the wedding...
>    Return;
> }
> 
> One of the ugly things in our approach is the 'Return' - it is needed to
> trigger the postcondition check. On the other hand, there is no problem
> with multiple exits.
> 
> >
> >As has been pointed out by Paul Johnson, there is no protection in this
> >scheme of overriding assertions against strengthening a require or
> >weakening an ensure or invariant. Neither are requires and ensures
> >automatically inherited in a method override. So the engineer must beware!
> 
> Absolutely true. I dont program anything without my assertions, but they
> are far from the power of Eiffel.
> 


I tried to think of a way to use local object destruction for ensure;
would be a great way to deal with multiple returns. But I could not figure
out how to give the object access to local variables or class members.
Will you give me a hint (if not a code sample)? Also, how are you testing
for invariance? Do you have a mechanism for overriding/hiding assertions,
and if so how?

Local object destruction is an excellent idea for making sure every ENTER
is balanced with an EXIT. Something like:

class AssertionMixin
{
private:
   friend class AssertionFrame;

   Identifier* identifierStack;

   AssertionMixin(); // Create stack for assertion identifiers.
   ~AssertionMixin(); // Delete stack.

   long GetStackSize();
   void SetStackSize(long stackSize);

   void PushAssertion(Identifier id);           // Adds to end of stack.
   Boolean ContainsAssertion(Identifier id);    // Searches entire stack.

   virtual void CheckInvariants() {}   // abstract
}

class AssertionFrame
{
private:
   AssertionMixin* currentObject;
   long assertionStackSize;

public:
   AssertionFrame(AssertionMixin* object)
   {
      currentObject = object;
      assertionStackSize = currentObject->GetStackSize();
      currentObject->PushAssertion(lock_invariance);
   }

   ~AssertionFrame()
   {
      currentObject->SetSize(assertionStackSize);
      if (!currentObject->ContainsAssertion(lock_invariance))
          currentObject->CheckInvariants();
   }

   void PushAssertion(Identifier id)
      { currentObject->PushAssertion(id); }

   Boolean ContainsAssertion(Identifier id);
      { return currentObject->ContainsAssertion(id); }
}

#define REQUIRE(identifier, expression)                           \
   if (!frame.ContainsAssertion(identifier))                      \
   {                                                              \
      frame.PushAssertion(identifier);                            \
      if (!(expression))                                          \
         (AssertionFailed(__FILE__, __LINE__, eRequire,           \
            #identifier, #expression));                           \
   }                                                              \

#define FRAME_ASSERTIONS                                          \
   AssertionFrame frame(this);                                    \


Note that the reference to AssertionFrame::ContainsAssertion in REQUIRE
forces the programmer to declare an AssertionFrame in their method before
they can use require! This is a nice safety feature. Also, the
AssertionFrame members may be inlined.

Adding the mixin class is a nuisance, but extending it to create a
separate assertion stack for every class instance means we don't need to
push the current object on the stack. This strategy also improves
execution speed, though at the cost of more overall memory usage.
Unfortunately, one would probably want to turn all this functionality off
for production code.

Usage:

void Person::Marry(Person other) : public AssertionMixin
{
      FRAME_ASSERTIONS;

      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);
}

Anders.

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

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Joachim Durchholz]

> (BTW, calls from within a require, ensure or invariant are completely un-
> checked in my implementation - is that what Eiffel compilers do, too?)

This is standard - to avoid endless recursion and performance problems <g>.

Regards,
Joachim

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Alan Brain]

Wolfgang Reddig wrote:

> Consider a 'Car' class having an invariant which states that cars have
> either two or four doors. Lets assume there is a method 'make_limousine', which
> adds two doors (forgive the C++ notation, but I'm not very familiar with
> the syntax of Eiffel):
> 
> void Car::make_limousine()
> {
>    require(no_of_doors() == 2)
>    ensure(no_of_doors() == 4)
> 
>    add_door(); // this would (incorrectly) cause an invariant failure!
>    add_door();
> }

But surely there's another way. Consider the following reasoning:

Cars, for our purposes, have either 2 or 4 doors, never 3, never 5.

So we can have:

type CAR_DOOR_NUMBER_TYPE is ( Two, Four );

type CAR_RECORD_TYPE is
record
  -- some data about the car, make, model etc here
  --
  NUMBER_OF_DOORS : CAR_DOOR_NUMBER_TYPE;
  --
  -- and maybe some more data here
  --
end record;

-- then for the code
ADD_TWO_DOORS (ToCar : CAR_RECORD_TYPE ) is

begin

  ToCar.NUMBER_OF_DOORS := CAR_RECORD_TYPE'SUCC (
ToCar.NUMBER_OF_DOORS);
  --
  -- or, if you want to 'Fail Safe'
  --
  -- ToCar.NUMBER_OF_DOORS := Four;
  --

exception

  when CONSTRAINT_ERROR => -- There already WERE Four Doors!
  -- if you want to 'Fail Safe'
    ToCar.NUMBER_OF_DOORS := Four;

  -- if you want to crash and burn, or destroy the rocket
  --  raise;

  when others =>           -- Has to be a hardware problem, or some
                           -- C program overrunning its array bounds,
                           -- or a bug in the compiler -
    null;                  -- Try keeping fingers crossed and hoping
                           -- for the best?

end ADD_TWO_DOORS;

No apologies for the Ada-83 syntax. Ada supplies the tools to "Judo" the
problem, avoid the concept of a 3-door car from being expressible. But
as Ariane-5 showed, having the capability to do this /= actually doing
it. 
C++'s enums appear similar, but that's another matter. 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Simulating Eiffel-style assertions (was: Papers on the Ariane-5 crash and Design by Contract)

[Wolfgang Reddig]

In article <3339F210.69E3@dynamite.com.au>, Alan Brain <aebrain@dynamite.com.au> writes:
>Wolfgang Reddig wrote:
>
>> Consider a 'Car' class having an invariant which states that cars have
>> either two or four doors. Lets assume there is a method 'make_limousine', which
>> adds two doors (forgive the C++ notation, but I'm not very familiar with
>> the syntax of Eiffel):
>> 
>> void Car::make_limousine()
>> {
>>    require(no_of_doors() == 2)
>>    ensure(no_of_doors() == 4)
>> 
>>    add_door(); // this would (incorrectly) cause an invariant failure!
>>    add_door();
>> }
>
>But surely there's another way. Consider the following reasoning:
>
>Cars, for our purposes, have either 2 or 4 doors, never 3, never 5.
>
>So we can have:
>
>type CAR_DOOR_NUMBER_TYPE is ( Two, Four );
>
>type CAR_RECORD_TYPE is
>record
>  -- some data about the car, make, model etc here
>  --
>  NUMBER_OF_DOORS : CAR_DOOR_NUMBER_TYPE;
>  --
>  -- and maybe some more data here
>  --
>end record;
>
>-- then for the code
>ADD_TWO_DOORS (ToCar : CAR_RECORD_TYPE ) is
>
>begin
>
>  ToCar.NUMBER_OF_DOORS := CAR_RECORD_TYPE'SUCC (
>ToCar.NUMBER_OF_DOORS);
>  --
>  -- or, if you want to 'Fail Safe'
>  --
>  -- ToCar.NUMBER_OF_DOORS := Four;
>  --
>
>exception
>
>  when CONSTRAINT_ERROR => -- There already WERE Four Doors!
>  -- if you want to 'Fail Safe'
>    ToCar.NUMBER_OF_DOORS := Four;
>
>  -- if you want to crash and burn, or destroy the rocket
>  --  raise;
>
>  when others =>           -- Has to be a hardware problem, or some
>                           -- C program overrunning its array bounds,
>                           -- or a bug in the compiler -
>    null;                  -- Try keeping fingers crossed and hoping
>                           -- for the best?
>
>end ADD_TWO_DOORS;
>
>No apologies for the Ada-83 syntax. Ada supplies the tools to "Judo" the
>problem, avoid the concept of a 3-door car from being expressible. But
>as Ariane-5 showed, having the capability to do this /= actually doing
>it. 
>C++'s enums appear similar, but that's another matter. 

Yes, one can simulate some assertions by subtype constraints. However,
perhaps things get more difficult if you have an invariant clause such as:

   no_of_doors = 4 implies horse_powers > 100

(I hope I got the syntax right).

As for C++ enums: the bad news is that C++ compilers don't initialize
enum data members. If you forget to initialize them in an constructor,
you have arbitrary garbage. Thus, there is no guarantee whatsoever that
the values of enums are in range at runtime.

>-- 
>aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
>| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
>| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
>100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
>                    By pulling MAERKLIN Wagons, in 1/220 Scale
>See http://www.z-world.com/graphics/z/master/8856.gif for picture
>

Regards,
Wolfgang

+---------------------------------------------------------------------+
|  Wolfgang Reddig                |  e-mail:                          |
|  Institut fuer Informatik III   |  wolfgang@informatik.uni-bonn.de  |
|  Roemerstrasse 164              |                                   |
|  53117 Bonn                     |  Tel.: (49) 228 / 73-4513         |
|  Germany                        |  Fax:  (49) 228 / 73-4382         |
+---------------------------------------------------------------------+

How old time languages survive

[EJon]

It occurred to me that one reason that many old, old languages
have survived is that they consistently "pilfer" styles and
features from newer langauges and eventually squash attempts
by these "upstart" languages to gain foothold and territory
by encroaching on areas where these older languages have 
longer existence and usage.
 
For instance, PL/1 has acquired some oo features.  Cobol 
keeps promising to deliver these.  Can OO Fortran be far
behind (yes, I read the DDJ on OO Fortran...)?  C/C++ 
stole ideas from ADA for its ++ attitude and "pointers"
from PL/1.

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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Ken Garlington]

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


Nick Leaton wrote:
> 
> Karel Th�nissen wrote:
> 
> > > From personal experience I have found this to be the case. Being able to
> > > test your comments is very useful!
> >
> > I fully agree, and every one should do this. But do you get this taught
> > in software engineering class or do software engineering methods or
> > languages enforce this? Do project managers require this?
> > To further clarify my/our point. Right now tens of thousands of
> > programmers wish that assumptions were more accurately documented in the
> > code - on the spot - if only by means of informal comments. These
> > programmers are making our software ready for the Y2000, they know the
> > assumptions made, if only they could easily find those spots.
> 
> I was very sceptical about assertions until I started using Eiffel. I am
> now converted.
> 
> I would however be interested in a discussion on how exceptions should
> be handled.
> 
> 1) Report and fail
> 2) Have logic. In the Ariane case, just shut down the SRI after launch
> 3) Fix and retry - could just be wait and retry
> 4) Try method B
> 
> Are there any others?

I wouldn't recommend #2 in the Ariane 5 case, since that is exactly what
the SRI did in response to the exception!!!!!

In reality, there is no "one size fits all" response to exceptions. Each
case must be analyzed separately - which is part of what makes writing
good assertions so difficult.

> 
> --
> 
> Nick

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

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[William Clodius]

Ken Garlington wrote:
> <snip>
> I don't understand this argument at all. I can see only three ways in
> which
> assertions provide benefit:
> 
> 1. Documentation for the human reader. However, if "free formatted
> in-code
> comments are too unreliable for this purpose", then this cannot be the
> primary benefit?

The benefits can certainly be enhanced if the programming environment
provides means to automatically extract the information and provide it
in a clearly summarized form. This is the main benefit of Eiffel style
assertions.

-- 

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

[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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Nick Leaton]

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


Ken Garlington wrote:
> 
> Nick Leaton wrote:
> >
> > Karel Th�nissen wrote:
> >
> > > > From personal experience I have found this to be the case. Being able to
> > > > test your comments is very useful!
> > >
> > > I fully agree, and every one should do this. But do you get this taught
> > > in software engineering class or do software engineering methods or
> > > languages enforce this? Do project managers require this?
> > > To further clarify my/our point. Right now tens of thousands of
> > > programmers wish that assumptions were more accurately documented in the
> > > code - on the spot - if only by means of informal comments. These
> > > programmers are making our software ready for the Y2000, they know the
> > > assumptions made, if only they could easily find those spots.
> >
> > I was very sceptical about assertions until I started using Eiffel. I am
> > now converted.
> >
> > I would however be interested in a discussion on how exceptions should
> > be handled.
> >
> > 1) Report and fail
> > 2) Have logic. In the Ariane case, just shut down the SRI after launch
> > 3) Fix and retry - could just be wait and retry
> > 4) Try method B
> >
> > Are there any others?
> 
> I wouldn't recommend #2 in the Ariane 5 case, since that is exactly what
> the SRI did in response to the exception!!!!!
> 
> In reality, there is no "one size fits all" response to exceptions. Each
> case must be analyzed separately - which is part of what makes writing
> good assertions so difficult.


You misunderstand me, probably because 2) is not as explicit as I
originally intended.

SRI raises exception. 
Exception handler receives exception.
Exception handler checks launch status and finds out that
the rocket is launched. Since SRI is used for alignment, it is
now redundant so can be shutdown/ignored.


-- 

Nick

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

[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

[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

[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]

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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Ken Garlington]

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


Karel Th�nissen wrote:
> 
> The problem is: no amount of runtime checks, tests, contracts or
> assertions can gracefully handle on-flight the type of error that
> occurred. It is just impossible to convert a 64-bit number with at least
> 17 significant bits into 16-bit representation. 

Actually, it's quire trivial - so long as you are willing to give up
precision. We do it all the time with our flight software.

> This 16-bit software (as
> far as the representation of flight data is concerned) should not have
> been taken into space. Truncation or provision of best guesses instead
> of exact data would not have stalled the system, but the error in
> trajectory calculations would accumulate to such heights that self
> destruction becomes inevitable, albeit perhaps a few seconds later than
> now.

Many times sensors, particularly those not purpose-built for a
particular
airframe, generate precision far in excess of what is needed for a given
environment. I don't know for sure that was the case here, but given my
experience with IRS/flight control coupling, I would be willing to bet
it was so.

> b) Having the assertions checked on flight does not bring us much
> further either, because there is no way to handle the conversion
> problem, except by having a similar routine with, say, 32-bit
> representation.

Actually, in this particular case, it may have been sufficient to
terminate the routine that was doing the alignment, since you can't
generally do alignments while the platform is in motion (one obvious
exception is aligning aircraft on a Navy carrier, which can get
alignment data from the carrier). However, I do agree that there are
cases where in-flight exceptions have no obvious resolution.

> But if we expect that 32-bit routine to be used, we
> would not use the 16-bit software in the first place. And still then,
> there is always a risc that even more bits than 32 may be needed. At
> this point an assumption about the maximum horizontal bias has to be
> made and any assumption about the outside world can prove wrong. It was
> assumed that 16 bits were sufficient, and under that assumption the
> software was correct. And for the programming team there was no reason
> to believe that the 16 bit representation would cause problems, as the
> software was developed for Ariane 4. Unfortunately, that assumption was
> neither specified as a clear ex-ante or ex-post specification for the
> software. This allowed for reuse outside the applicability range of the
> software.
> 
> !!! THIS SOFTWARE SHOULD NOT HAVE BEEN TAKEN INTO FLIGHT FOR ARIANE 5,
> NO MATTER HOW MANY SAFEGUARDS !!!
> 
> However, assertions and the like can be very useful on the ground.
> Proper tools can signify the assumptions and report them as ex-post
> specifications of the software module as a whole. Assumptions are all
> those assertions that raise exceptions that are not properly caught and
> handled by exception handlers. Then during assembly for Ariane 5, one
> would have seen that one of the assumptions regarding the SRI was not
> met. 

Only if the assertion was exercised on the ground, of course (assuming
the assertion is not static, as was the case here.) There was no attempt
to provide realistic flight data to the IRS, so any non-static
assertions
in the code would have been left unexercised.

> Assertions in this respect can be viewed as reporting aid from the
> programmer who made an essential design decision somewhere deep down in
> the software (it was documented somewhere, so the programmer(s) were
> aware of this design decision), up to those who are going to test,
> verify or use the software. Any tester or verifier worth his income
> would have noticed the invalid assumption (for Ariane 5) that emerged
> from the implementation.

If the assertion were exercised, this would be the case. Of course, if
the assertion were left out, but the test executed as if the assertion
were there, the test team would have seen the IRS go off-line (as in
flight) and taken action.

> Of course, there still is the possibility that these ex-post
> specifications would not be used, but that at least supposes an extra
> level of incompentency or negligence (by this I do not want to insult
> the people on the Ariane project by suggesting that currently there is
> incompetence or negligence).
> 
> Notice, that hand-crafted documentation or free formatted in-code
> comments are too unreliable for this purpose and that normal condition
> testings in the software do not necessarily signify assumptions.
> Therefore, assertions as a means of documentation add an additional
> layer of security that could not easily and reliably be obtained by
> other coding practices.
> 
> Of course, there are a lot of spots in the entire SRI project where
> different decisions at the time may have saved the launcher. But most
> decisions seemed perfectly reasonable, both the decisions during the
> development of the system and later for its reuse.
> 
> Testing might have revealed the software fault, this time, but next time
> a fault will get uncaught.

I don't understand this argument at all. I can see only three ways in
which
assertions provide benefit:

1. Documentation for the human reader. However, if "free formatted
in-code
comments are too unreliable for this purpose", then this cannot be the
primary benefit?

2. Static analysis by automated means. This is certainly useful (in
fact,
it's one of the primary reasons why I use Ada). However, in this case,
such
analysis would have to either reject a working case (the Ariane 4) or
miss
a failure case (Ariane 5).

3. Dynamic analysis by automated means. In order for dynamic analysis to
work,
useful input data must be provided (at least, as far as I can tell).
This was
not done for Ariane 5.

Moreover, given that #2 and #3 are examples of testing, it's clear to me
that testing is an essential part of making assertions useful. The claim
that testing does not detect all errors is certainly true, but since
this
claim is also quite true for assertions (Design By Contract or
otherwise),
what does it prove?

> Surely, now that we know the bug, it is
> simple to think of nice tests that would have relealed the bug
> cheaplier. Testing can reveale the presence of bugs not the absence. At
> some point one must stop testing, and the team thought it had arived at
> that point.

Note that the exact same claim is true for assertions: At some point,
you
have to stop writing them, for several reasons:

  a. There is a finite amount of time to do the analysis to generate the
     assertions. For executable assertions, there is a finite amount of
     time to exercise them on the ground.

  b. Exectuable assertions (on the ground or in the air) affect timing,
both
     gross throughput margin and interprocess dependencies, which may
affect
     the system's success.

  c. Particularly for highly-critical software, there is a desire to
keep things
     as simple as possible. Adding code provides opportunities to
generate
     errors via compiler bugs, for example. This is particularly true
for the
     case where testing is done with executable assertions active, and
then
     they are turned off just prior to delivery in order to mitigate
item "b". If
     the code is correct with assertions active, but incorrect with
assertions
     suppressed (and I have seen cases of this!), then a serious problem
will
     result.

  d. From a documentation standpoint, excessive assertions may cause
"reader
     fatigue."

As a result, a human being must decide which assertions are meaningful,
and
which aren't. Which leads us right back to the Ariane 5 disaster.

With respect to testing, it is important to keep in mind that the
testing that
was not done is considered a normal and routine test for such a system.
It is
not hindsight to say that it was a bad idea to skip the test. In fact, I
have
been a part of a system where this idea was suggested, and have helped
shoot
it down personally - BEFORE the Ariane 5 accident!

> Testing was not forgotten, but argued obsolete. Maybe this
> is not entirely true:
> 
> FLIGHT 501 WAS A TEST FLIGHT, SO THE SOFTWARE WAS TESTED, AND THE
> PRESENCE OF BUGS WAS PROVEN, THEREFORE TEST FLIGHT 501 WAS A SUCCESS.
> 
> Any piece of software has a applicability scope. Outside this scope the
> software becomes indeterminate. Assertions are an important (and
> automatic!) aid in the documentation of this applicabilty scope. NEVER
> DO WITHOUT THEM.

Never say "never"! :)

> 
> Groeten, Karel

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

[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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Ken Garlington]

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


Nick Leaton wrote:
> 
> Ken Garlington wrote:
> >
> > Nick Leaton wrote:
> > >
> > > Karel Th�nissen wrote:
> > >
> > > > > From personal experience I have found this to be the case. Being able to
> > > > > test your comments is very useful!
> > > >
> > > > I fully agree, and every one should do this. But do you get this taught
> > > > in software engineering class or do software engineering methods or
> > > > languages enforce this? Do project managers require this?
> > > > To further clarify my/our point. Right now tens of thousands of
> > > > programmers wish that assumptions were more accurately documented in the
> > > > code - on the spot - if only by means of informal comments. These
> > > > programmers are making our software ready for the Y2000, they know the
> > > > assumptions made, if only they could easily find those spots.
> > >
> > > I was very sceptical about assertions until I started using Eiffel. I am
> > > now converted.
> > >
> > > I would however be interested in a discussion on how exceptions should
> > > be handled.
> > >
> > > 1) Report and fail
> > > 2) Have logic. In the Ariane case, just shut down the SRI after launch
> > > 3) Fix and retry - could just be wait and retry
> > > 4) Try method B
> > >
> > > Are there any others?
> >
> > I wouldn't recommend #2 in the Ariane 5 case, since that is exactly what
> > the SRI did in response to the exception!!!!!
> >
> > In reality, there is no "one size fits all" response to exceptions. Each
> > case must be analyzed separately - which is part of what makes writing
> > good assertions so difficult.
> 
> You misunderstand me, probably because 2) is not as explicit as I
> originally intended.
> 
> SRI raises exception.
> Exception handler receives exception.
> Exception handler checks launch status and finds out that
> the rocket is launched. Since SRI is used for alignment, it is
> now redundant so can be shutdown/ignored.

Actually, the SRI is used during the entire flight profile. There
was an alignment *function* that was contained *within* the SRI
that should have been shut down as soon as the Ariane took off
(alignment functions do not typically work well with moving
platforms!) It would probably have been reasonable to shut down
the process doing the alignment function of the SRI, assuming the
processes were partitioned in a way that allowed the other
necessary functions to continue, although there was no need to
wait until an exception was raised to do this.

So, in this particular case, it was probably reasonable to shut
down part (but not all) of the SRI. Other parts of the SRI may not
be able to shutdown under ANY circumstances.

> 
> --
> 
> Nick

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

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Ken Garlington]

William Clodius wrote:
> 
> Ken Garlington wrote:
> > <snip>
> > I don't understand this argument at all. I can see only three ways in
> > which
> > assertions provide benefit:
> >
> > 1. Documentation for the human reader. However, if "free formatted
> > in-code
> > comments are too unreliable for this purpose", then this cannot be the
> > primary benefit?
> 
> The benefits can certainly be enhanced if the programming environment
> provides means to automatically extract the information and provide it
> in a clearly summarized form. This is the main benefit of Eiffel style
> assertions.

However, there are several environments that can do the same with
comments,
(e.g. SPARK) so this can't be an inherent advantage of Eiffel
assertions.
One could claim that having it defined in the language, as opposed to an
add-on, enhances standardization (but does Eiffel have a standard that
defines the "clearly summarized form" of these assertions?).

However, even with this, I have several problems with assuming that
documentation in the code, as opposed to a separate document, would have
made a significant difference in the Ariane V case, for the reasons
previously cited (low probability that the assertion would have been
defined, insufficient data available to the human via the spec
to analyze the assertion on reuse, difficulties in translating
high-level
flight profile data into specific parameter profiles for analysis on
reuse,
and general culture on the project regarding reusability.)

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

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

Re: Ariane-5: can you clarify? (Re: Please do not start a language war)

[David Starr]

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I say the crash was caused by the requirement for the inertial nav 
software to shut down and enter hardware test mode upon exception.  In 
other words, the program did what it was asked to do, and it was asked to 
destroy the rocket upon any kind of unforseen problem.  Be careful what 
you ask for, you might get it.
   If the inertial nav software had been required to press on regardless 
there is an excellent chance the mission would have flown.
   I don't think a clever programming language could be so good as to 
guarantee no exceptions ever.  The software was required to shut down 
upon exeception.  It got an exception and it shut down.  

David Starr

Nick Leaton wrote:
> > >
> > > I would however be interested in a discussion on how exceptions should
> > > be handled.
> > >
> > > 1) Report and fail
> > > 2) Have logic. In the Ariane case, just shut down the SRI after launch
> > > 3) Fix and retry - could just be wait and retry
> > > 4) Try method B
> > >
> > > Are there any others?
> >
> > I wouldn't recommend #2 in the Ariane 5 case, since that is exactly what
> > the SRI did in response to the exception!!!!!
> >
> > In reality, there is no "one size fits all" response to exceptions. Each
> > case must be analyzed separately - which is part of what makes writing
> > good assertions so difficult.
> 
> You misunderstand me, probably because 2) is not as explicit as I
> originally intended.
> 
> SRI raises exception.
> Exception handler receives exception.
> Exception handler checks launch status and finds out that
> the rocket is launched. Since SRI is used for alignment, it is
> now redundant so can be shutdown/ignored.
> 
> --
> 
> Nick

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

[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

[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

[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: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <3338AA0A.7A79CB24@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

  > But of course this is not a reason to say there should not be
  > simulation, testing, inspections, independent reviews etc. etc.
  > I don't recall anyone even coming close to suggesting this in the
  > present thread. And our paper certainly does not say anything of
  > the sort.

  But the Final Report on the Ariane 5 failure does say that there
were NO simulation, testing, inspections, independent reviews
etc. etc.  for the Ariane 5.  Not minimal, not inadequate, none.  And
this is where your paper misleads.  Any "reasonable" methods would be
better than no testing, no inspections, and no reviews.

  > It would be as absurd to use Design by Contract or other a priori
  > relability techniques as an excuse not to do a posteriori V & V
  > (testing, simulation etc.), as it would be to develop in a sloppy
  > way with the expectation that testing will uncover any problems.

  But in this case, effectively both excuses were used.  No
requirements review was done because there would be full up testing,
then the full-up test was cancelled because the software had not
changed!

  > But the need for a posteriori verification is too often an excuse
  > for not applying the proven a priori reliability techniques, such
  > as Design by Contract. This is not only silly but a recipe for
  > disaster of Ariane-5 proportions.

    Yep, and doing neither is not a recipe, it is a guarantee.

  > I think that its arguments and conclusion are perfectly in line with
  > many useful comments made by people who thought they disagreed with it.
  > Please check what it really has to say.

    What Bertrand Meyer continues to miss, probably because it is so
difficult to believe, is that the software (and hardware) were reused
without any requirements review or testing.  None.  Not inadequate
review or incomplete testing, none.  His paper assumes that review
and testing occured but missed a subtle point.  There were several
glaringly obvious problems that would not have been missed by any
competent engineer--they probably wouldn't have been missed by a
teenager whose only experience was in model rocketry:

    1) The alignment software continued running for 40 seconds after
launch, for reasons documented in the code but totally irrelevant to
Ariane 5.

    2) The permissible engine deflection angles were based on Ariane 4
requirements, and could (and did) result in destruction of an Ariane
5.  (Would lesser max deflection values have met Ariane 5 requirements
for crosswind tolerance and wind shear?  No clue, the analysis wasn't
done.)

    3) There were several other analyses that depended on knowledge of
Ariane 4 flight paths and physical limits.  Again these were very
invalid but not redone.  (This includes the failure that triggered the
entire chain of events.)

    4) The assumption--well documented--in the code that any Ada
exception not locally handled was due to hardware not software
failure.  In Ariane 4, this assumption may be correct.  But in Ariane
5, the decision should have been reconsidered, at least for the first
test flight.

    I was determined that I had made my last post on this subject, but
I got sucked in again.  I want to make sure that no one misunderstands
the nature of this failure--it was a failure of management, not of
software engineering.  And it wasn't even software management that
failed, the politics that caused the failure occured at a much higher
management level.

   In this it was very similar to the Apollo fire and the Challenger
disaster.  In the Apollo fire, two tests with very different
requirements were merged to "speed things up."  Three psi oxygen and
three psi above ambient atmosphere are two very different things.  But
the tests were merged after the safety engineers had signed off on
them separately.

   George Low was brought in to take over the Apollo program after the
fire, and he instituted procedures to prevent anything similar from
ever happening again on a manned test or manned flight.  These
procedures were followed until STS 25.  (Although there were a number
of leaks of "pressure to maintain the launch schedule" heard before
then, the final flight worthiness decision for the shuttle and all
subsystems was always made by an engineer.)

--

					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 <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: Trust but verify (was Re: Papers on the Ariane-5 crash and Design by Contract

[Robert I. Eachus]

In article <5hfdh8$b7d@news-central.tiac.net> jws@tiac.net (Jeffrey W. Stulin) writes:

  > If the Ariane software engineers had the reuse mindset, NOT the
  > specific mechanisms of Eiffel, but the design by contract reuse
  > mindset, then they MAY have written the assertion, and MAY have
  > noticed, while integrating the modules, that the assertion would
  > not have been met.

  > I often specify "impossible" assertions because, human nature
  > being what it is, the impossible will happen, and it is exactly
  > these non intuitive circumstances which cause the most trouble...

  Hmm.  Let me try to get the picture across.  Do you remember the
Saturn V moon launches?  The stack seemed to sit there on the pad for
the longest time, because the thrust at liftoff was almost exactly 1
G.  (I seem to remember 1.03 G at t=0.) As the engines burned off
kerosene and LOx the stack slowly accelerated.  (And at about the
point you thought you couldn't take it anymore, the noise starts to
decrease, but I digress.)

  Now go watch a space shuttle launch.  Once the solids light up, the
shuttle grabs for the sky.  (Varies from mission to mission, but the
thrust is about 1.4 G as I recall.)  The shuttle even has to throttle
back to keep max Q within limits.

  The Ariane 4 takes off like the Saturn V, the Ariane 5 like the
shuttle.  I don't know the actual numbers, but how would you document
a "potential problem" where a rocket that couldn't get more than a
kilometer from the pad in the first minute was 10 Km away at t=40
seconds?  You would decide as the Ariane 4 developers did--any such
indication had to be indicative of hardware failure of one sort or
another.
--

					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]

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: Ariane-5: can you clarify? (Re: Please do not start a language war)

[Jon S Anthony]

In article <01bc3389$46204f70$b280400a@gavinspc> "Gavin Collings" <gcollings@sperry-sun.com> writes:

> (2) To treat the software as intrinsically more reliable than the
> hardware seems to go against all experience and indeed against
> common sense.

Truer words have never been spoken or written in software circles.
This should be framed and required to be hung on the wall in all such
circles.


/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

[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

[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

[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

[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

[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

[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

[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

[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

[Nick Roberts]

Add kibo to your killfile. Nick.