Rebuttal to Ariane paper

Rebuttal to Ariane paper

[Ken Garlington]

Jean-Marc Jezequel wrote:
> 
> I've put on a page with a few Usenet comments about the paper, including a
> link to your paper. Please check it at:
> 
> http://www.irisa.fr/pampa/EPEE/Ariane5-comments.html

I'll add a link to this in my paper this weekend. Some notes:

- I've changed my address from kennieg@flash.net to
Ken.Garlington@computer.org.
It would help if you could make this change in your paper as well.

- In your critique, you state: "Stricly speaking, it is very clear that
DBC by
itself is neither sufficient (it needs to be integrated in a proper
system
and software engineering process) nor necessary...", where the "system
and
software engineering process" references your book. I could find no
reference
to your book in the Ariane paper, or to a system and software
engineering
process beyond DBC/Eiffel. It appears that you are agreeing with my
critique
of the _paper_ (as opposed to your _personal_ position, as described in
your
rebuttal).

- Looking at the table of contents of your book, only chapters 6 and 7
appear
to address a system and software engineering process. In particular, for
systems analysis, an "object oriented analysis" is defined. Is Eiffel
used
to describe this analysis (presumably done as part of OMT)? If not, then
what approach/notation is recommended, and where is this discussed in
the
Ariane paper?

- You also state: "In his critique, Ken seems to overlook the fact that
whereas assertions related to DBC are physically located inside the
code,
they logically belong to the specification of components. Tools are
available to extract this specification. When you want to reuse a
component
(let's say the perfectly valid Ariane4 SRI) in a new system
(let's say Ariane5) the engineer working in a DBC context would check 
with all possible means) whether the new system is happy with the
component
contract." This position is not "overlooked"; it is the entire basis of
section 3.1 of my paper! To date, no one has indicated any specific
flaws
with the argument in this section, so far as I can recall.

- I am also concerned that you quote Eiffel advocates without also
describing
my posted rebuttals to their arguments. In particular, the Ted Velikoff
post
is very misleading, as it addresses an issue that was not the topic of
discussion
at the time. The original post, to which I responded, said that Eiffel
assertions
were superior even if they were _never_ executed (either during test or
production use). Mr. Velikoff did not see this original post, and
assumed a
different topic of conversation.

- You also quote Robert S. White in this paper. I think his comments
reflect
those of Dr. Dewar, but as stated, they appear to support Eiffel/DBC
instead.
I will let Mr. White make any appropriate responses.

- I should also note that I find the Meyer response particularly
offensive, since
it attacks the motives of his critics, denigrates the skills and
knowledge
of aerospace professions that don't use Eiffel, and does not respond to
the
substance of the arguments (except to re-state his position once again).
However,
he has the right to be offensive, and so I'm not suggesting that the
quote be
changed or retracted. In fact, it contradicts your own personal
position: Note
the statement "The pitch, if any, is for the method of Design by
Contract..."
which once again reinforces my claim that the _paper_ is focused on
DBC/Eiffel,
not on a "system and software engineering process."

- Finally, is there any way your link could be posted on www.eiffel.com?
Your
server doesn't appear to be referenced from there, and so readers of the
Ariane
paper have no real way to find this supplemental information.

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

Re: Rebuttal to Ariane paper

[Jean-Marc Jezequel]

[Sorry for taking so long to answer. I didn't realized the mail I received from Ken
was also posted to Usenet]

>- In your critique, you state: "Stricly speaking, it is very clear that
>DBC by itself is neither sufficient (it needs to be integrated in a proper
>system and software engineering process) nor necessary...", where the "system
>and software engineering process" references your book. I could find no
>reference to your book in the Ariane paper, or to a system and software
>engineering process beyond DBC/Eiffel. 

Here is the reference: http://www.irisa.fr/pampa/EPEE/book.html

Remember the Ariane paper was a 2 pages so-called "column", copy-edited by Computer, as 
opposed to a regular technical paper with peer reviews, references, related work, etc.


>- Looking at the table of contents of your book, only chapters 6 and 7
>appear to address a system and software engineering process. In particular, for
>systems analysis, an "object oriented analysis" is defined. Is Eiffel
>used to describe this analysis (presumably done as part of OMT)? If not, then

No. But I hope it shows how DBC nicely fits with OMT and complement it (and many other
 OOAD methods, e.g., CRC, Fusion, etc.), and then tremendously helps V&V. 

>what approach/notation is recommended, and where is this discussed in
>the Ariane paper?

My book is 368 pages long. The Ariane paper is 2.

>- You also state: "In his critique, Ken seems to overlook the fact that
>whereas assertions related to DBC are physically located inside the
>code, they logically belong to the specification of components. Tools are
>available to extract this specification. When you want to reuse a
>component (let's say the perfectly valid Ariane4 SRI) in a new system
>(let's say Ariane5) the engineer working in a DBC context would check 
>with all possible means) whether the new system is happy with the
>component contract." 
>This position is not "overlooked"; it is the entire basis of
>section 3.1 of my paper! To date, no one has indicated any specific
>flaws with the argument in this section, so far as I can recall.

For example in section 3.1, you say:
> The review team would have to review the code, as opposed to other
>         documentation.

As it has been explained multiple times, this is not the case. What is true, 
is that the review team would had to review the *contract* of a component before 
even thinking about reusing it. In Eiffel, the contract can be *extracted* from 
the code with any compiler on the market (if you do not consider inheritance 
issues, the same thing can be done for other languages, see e.g., the AWT for 
Java. But today, only with Eiffel you can take inheritance into account when 
extracting the contract of a class. This is why people say that only Eiffel 
fully support DBC).


Maybe the Ariane crash is not an interesting lesson for some aerospace 
industry enginners, but it is definitively a good one for many software 
engineers, e.g., those who believe they can blindly reuse e.g., CORBA 
components, because "they were working for my previous application".


>- You also quote Robert S. White in this paper. I think his comments
>reflect those of Dr. Dewar, but as stated, they appear to support Eiffel/DBC
>instead. 

It was my error. It has been corrected.


As a conclusion, I remark that Ken does not seem to oppose to the following statement:
We think that there is a broad agreement on the fact that Ariane 5 is a striking example of working
with assumptions that are true at a point in time (Ariane 4) and no longer later on (Ariane 5). The
divergences on opinions lie on whether or not Eiffel style assertions would have been useful and
practicable for expressing these hidden assumptions. Many people familiar with DBC in the
context of Eiffel think that they would, others, like Ken Garlington, think that they wouldn't. 




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

Re: Rebuttal to Ariane paper

[Jon S Anthony]

In article <34018ec9.3850572@wizard.pn.com> leew@micrologic.com (Lee Webber) writes:

> always work well with time-critical code, and some external entities
> don't model well as well-behaved objects.  The first of these
> observations might make DBC somewhat less useful in HRT apps than
> elsewhere -- but certainly not useless.  The second observation, IMO,
> hits at all specification and testing methodologies, not just DBC.

WRT the latter: it is worth noting that this holds for "purely"
software entities as well.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Rebuttal to Ariane paper

[Don Harrison]

Lee Webber wrote:

:1. I am an Eiffel enthusiast; also, a developer with a generation's
:experience in networking and (mostly soft) real-time systems.
:
:2. I have however never actually used Eiffel in any project, much to
:my regret, because the existing systems have not been scaled to my
:platforms.  (Recent announcements, incluing Visual Eiffel and
:especially Embedded Eiffel, may change that.  We'll see if I can get
:out of my existing technical commitments.)
:
:3. I do agree with Ken that DBC per se wouldn't have saved Ariane,
:while any normal methodological diligence (with a methodology possibly
:including but not restricted to DBC) would have.
:
:4. I do think that the use of DBC in several projects might well have
:resulted in a design culture which would then have made Ariane less
:likely. However (as always with cultures) there is no inevitability
:about this.
:
:5. As for a couple of technical issues, executable assertions don't
:always work well with time-critical code, and some external entities
:don't model well as well-behaved objects.  The first of these
:observations might make DBC somewhat less useful in HRT apps than
:elsewhere -- but certainly not useless.  The second observation, IMO,
:hits at all specification and testing methodologies, not just DBC.
:
:6. As for reluctance, many Eiffelists (including myself) are simply
:not that qualified to speak to HRT issues.
:
:FWIW, YMMV. This is my first and last direct comment on Ariane.

Sensible comments.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison     nospam@thankyou.maam.com.au