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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: jtc@jupiter.milkyway.org (Jim Cochrane) Subject: Usefullness of design-by-contract (was Re: The stupidity of all the Ariane 5 analysts.) Date: 1997/07/21 Message-ID: <5r1drj$8ih@jupiter.milkyway.org> X-Deja-AN: 258079860 References: <33C835A5.362A@flash.net> <33CEAF05.6389@flash.net> <33D2827B.41C67EA6@eiffel.com> <33d38a16.195337670@news.geccs.gecm.com> Organization: Dimensional Communications Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-21T00:00:00+00:00 List-Id: In article <33d38a16.195337670@news.geccs.gecm.com>, Ian Begg wrote: >On Sun, 20 Jul 1997 14:26:19 -0700, Bertrand Meyer > wrote: > ... >> ... >> some of >> the Ada enthusiasts in these newsgroups have >> mistakenly taken the mention of Ariane as a personal >> affront on their language. The pitch, if any, is for >> the method of Design by Contract. > >How many languages support Design by Contract as part of the language >as in the case of Eiffel? I don't have experience of a broad range of >languages so I can't answer this. However, if the answer is only >Eiffel, (plus perhaps some other non relevant langauges) then it is >not difficult to see how people might interpret your motives as "OK we >can't be so obvious as to say Eiffel is the answer, but if we say >Design by Contract is the answer, people will need to find a language >to support it, hence Eiffel." You are the only person who knows your >real motives, but the discussions going on suggest some people are >interpreting your motives in this way. I have changed the subject line for this post becuase it is about the usefulness design by contract and does not address whether it would have helped with the Ariane 5 mishap. Regardless of what Dr. Meyer's motives are, I think there are some basic assumptions underlying this discussion that some people are implicitly questioning. The basic assumptions, as I see them, are: 1. Documenting precise specifications in the form of pre- and post-conditions and class invariants for all component interfaces and making this documentation easily available to anyone using the components will help in producing systems that fulfill their requirements correctly. 2. Coding as many of these specifications as possible helps in ensuring their precision and allows them to be checked while testing, further increasing the chances that the systems developed in this manner will fulfill their requirements correctly. 3. Using a language and environment that directly supports both the documentation and the coding of these specifications will make the specification process easier, more complete, and less error prone, thus further increasing the chances that the systems developed in this manner will fulfill their requirements correctly. One point of the discussion, I believe, is that the method implied in the above assumptions is a tool to use along with other valuable tools in producing high-quality software; it does not replace other usefull tools such as a good test method and plan - rather, it complements them. Now perhaps I am biased and am not aware of valid counterarguments, but I am not able to see how the method that would result from making use of these assumptions, called design-by-contract in this discussion, would not significantly increase the quality of a system of substantial size, in the sense of producing a system that correctly fulfills its requirements. Assuming that their are no valid counterarguments (if there are, I'm sure people will post them), the discussion comes down to how practical it is to implement and use an environment that supports design by contract. As far as assumption 1., applying precise specifications for component interfaces, the usefullness and practicality of this technique seems obvious and just visualizing the consequences of not doing this (for example, increased time spent figuring out what a component does, developers' time wasted informing other developers what the interface specification of a component is, errors in coding due to misunderstanding an undocumented specification) should be enough to convince anyone that it would be foolish not to apply this technique on any significant project. The practicality of applying assumptions 2 and 3 is perhaps not as obvious as the first assumption, but strong reasons do exist to support their practicality. First, coding interface specifications combined with a good test plan will increase the chance of uncovering defects and decrease the cost of fixing them (since it is well known that the later a defect is found, the more it will cost to fix). Also, using an environment that provides rich support for the documenting and coding of interface specifications will make it easier and less time consuming and thus more practical for developers to use this technique. Finally, using such an environment would provide an infrastructure that would allow development organizations to make the technique of design by contract a formal part of the development process and thus make the components of this technique - precise, complete, and testable specifications - a part of the culture of the development organization, so that the techniques used to produce high quality software become habitual (in a positive sense), rather than being something foreign that is forced upon the developers. As I see it, Eiffel is simply an evolutionary step in the maturing fields of computer science and software engineering. By directly supporting design by contract it increases the chances that a team of capable developers will produce a quality product. My guess is that other languages (besides Eiffel and Sather, the only ones I'm aware of that directly support design by contract) will appear that also support this technique and that chances are that at least one of them will become mainstream (in the sense of being perhaps as well-known as Java is today, hopefully without the hype). Some of these languages may provide even more complete and sophisticated support for design by contract than Eiffel and Sather. It will be interesting to see what languages and techniques are being used 20 or 30 years from now (for those of us who are not retired or dead, that is :-) ). Jim Cochrane jtc@dimensional.com