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

[jezequel@irisa.fr (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