From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,5528f4f0452fdf6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,5528f4f0452fdf6 X-Google-Attributes: gid103376,public From: jezequel@irisa.fr (Jean-Marc Jezequel) Subject: Re: Rebuttal to Ariane paper Date: 1997/08/22 Message-ID: <5tjh29$8oj$1@news.irisa.fr>#1/1 X-Deja-AN: 267853761 References: <199708180814.KAA28247@rising.irisa.fr> <33FA70EE.20DF@flash.net> Distribution: world Organization: Irisa, Rennes (FR) Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-08-22T00:00:00+00:00 List-Id: [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