* Rebuttal to Ariane paper [not found] <199708180814.KAA28247@rising.irisa.fr> @ 1997-08-19 0:00 ` Ken Garlington 1997-08-22 0:00 ` Jean-Marc Jezequel 0 siblings, 1 reply; 4+ messages in thread From: Ken Garlington @ 1997-08-19 0:00 UTC (permalink / raw) To: Jean-Marc Jezequel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rebuttal to Ariane paper 1997-08-19 0:00 ` Rebuttal to Ariane paper Ken Garlington @ 1997-08-22 0:00 ` Jean-Marc Jezequel [not found] ` <33FFA706.1310@flash.net> 0 siblings, 1 reply; 4+ messages in thread From: Jean-Marc Jezequel @ 1997-08-22 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <33FFA706.1310@flash.net>]
[parent not found: <34018ec9.3850572@wizard.pn.com>]
* Re: Rebuttal to Ariane paper [not found] ` <34018ec9.3850572@wizard.pn.com> @ 1997-08-25 0:00 ` Jon S Anthony 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 4+ messages in thread From: Jon S Anthony @ 1997-08-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Rebuttal to Ariane paper [not found] ` <34018ec9.3850572@wizard.pn.com> 1997-08-25 0:00 ` Jon S Anthony @ 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 4+ messages in thread From: Don Harrison @ 1997-08-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1997-08-26 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199708180814.KAA28247@rising.irisa.fr> 1997-08-19 0:00 ` Rebuttal to Ariane paper Ken Garlington 1997-08-22 0:00 ` Jean-Marc Jezequel [not found] ` <33FFA706.1310@flash.net> [not found] ` <34018ec9.3850572@wizard.pn.com> 1997-08-25 0:00 ` Jon S Anthony 1997-08-26 0:00 ` Don Harrison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox