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

[rkaiser@dimensional.com (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