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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Joachim Durchholz Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/21 Message-ID: <33FC5FA3.207146DB@munich.netsurf.de>#1/1 X-Deja-AN: 267866080 References: <5siqrr$3of@jupiter.milkyway.org> <5smgts$p68$1@miranda.gmrc.gecm.com> <33EFCCE4.4CE0@flash.net> <5sq3fh$frg@wdl1.wdl.lmco.com> <33F9C7BD.794BDF32@eiffel.com> <33FAB260.7E0CD1D1@calfp.co.uk> X-Priority: 3 (Normal) Organization: ccn - computer consultant network GmbH Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-21T00:00:00+00:00 List-Id: Nick Leaton wrote: > However if I write print ("Cest un crado error") you may complain that > it is an intelligible error message. OK, it may be for you. But if you > cannot express specifications and requirements in code, how can you > write a system? > > Take the example of useability. What 'exactly' does it mean? How do > you > measure it? At the end of the day you have to write something which is > decomposing 'useablility' into code. I don't see why you can do the > same > with DBC. Although, you may omit some of the checks for pragmatic > reasons. That's exactly what's being done - such assertions are written as comments (which doesn't mean they don't bind the caller or the routine). Though stuff like usability is difficult to express even as a comment that's better than "this routine is user-friendly" - no wonder usability labs are in existence. > For another example. I write software for a bank. A requirement is > that > we help prevent the bank going bust. A very valid requirement. > However, > this is a very woolly spec, and needs to be decomposed into smaller, > manageable requirements. Same case as above. Such assertions go to the currently perceived top-level function of the system. In practice, the top-level function isn't too important (it will change as soon as we go from batch to interactive, add another service to the system, etc. etc. ...) If the top-level function is unimportant, so are its assertions :) Regards, Joachim -- Please don't send unsolicited ads.