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,a48e5b99425d742a X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,a48e5b99425d742a X-Google-Attributes: gidf43e6,public X-Google-Thread: ffc1e,a48e5b99425d742a X-Google-Attributes: gidffc1e,public X-Google-Thread: 103376,a48e5b99425d742a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,5da92b52f6784b63 X-Google-Attributes: gid1108a1,public X-Google-Thread: 107d55,a48e5b99425d742a X-Google-Attributes: gid107d55,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Papers on the Ariane-5 crash and Design by Contract Date: 1997/03/18 Message-ID: #1/1 X-Deja-AN: 226543210 Distribution: world References: <332B5495.167EB0E7@eiffel.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.programming.threads,comp.lang.ada,comp.lang.java.tech Date: 1997-03-18T00:00:00+00:00 List-Id: In article <5gll90$2qu$1@news.irisa.fr> jezequel@irisa.fr (Jean-Marc Jezequel) writes: > To answer Jon S Anthony, yes, all that could have been done in Ada using: > function Convert ( Horizontal_Bias: Integer ) return Integer is > subtype Bias_Constraint is Integer range 0..Maximum_Bias; > Require : Bias_Constraint := Horizontal_Bias; > > Ada's subtype declarations are a kind of contract, that could be > documented as such. Design by contract is not specific to > Eiffel. You can do it with any language, just because it is a way of > designing! Eiffel is, however, one of the few languages that provide > built-in support for it. You miss my point. Which is that this stuff is NOT sufficient to have prevented this error. And further, the evidence supports this position because the language used in fact _does_ have this capability but it was _not_ used. While design by contract is a good first step, it _too_ is simply insufficient as currently realized. It in no way captures any of the semantic context that scopes the usage scenarios that are assumed in the design and implementaion of "components". > Let's finally sum up what I perceive as the most important claims in > this paper: > - reusing a component without checking its full > specification is dangerous, which means that simple minded > CORBA-like approaches at building components for mission-critical > software are doomed. Agreed, but this too is simply way too simplistic. If "full specification" simply means signatures and their pre and post condition requirements, it does not capture the "full" scope of the problem. If it does include the various semantic aspects associated with "components", it is not and, what is more, _cannot_ be captured in signatures and assertions. > - using design by contract is an interesting > way to specify the behavior of a component Yes, but _only_ a rather _limited_ aspect. It is clearly better than nothing, but alone it could not prevent the sort of problem being discussed. > - at least in the case of > Ariane 501, simple assertions (a la Eiffel and other languages) > would have been expressive enough to specify the fatal hidden > assumption. This I simply don't believe. And the evidence does not support it either. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com