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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/18 Message-ID: #1/1 X-Deja-AN: 257495793 Sender: news@syd.csa.com.au X-Nntp-Posting-Host: dev50 References: <33CD9227.4298@dynamite.com.au> Organization: CSC Australia, Sydney Reply-To: donh@syd.csa.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-18T00:00:00+00:00 List-Id: Alan Brain wrote: :Don Harrison wrote: :> :> As an example, in our simulation, we have a vehicles object. This is implemented :> as an array of records (they should be variant records discriminated :> on validity, however..). Vehicles are activated and deactivated during the :> course of a "game" by setting a validity flag. I added preconditions to ensure :> that other attributes (such as heading) were not queried unless the vehicle was :> active. These simple checks caught a whole bunch of errors that may otherwise :> have gone unnoticed. In the absence of such a check, the problem may only :> have come to our attention if spurious behaviour was observed. : :Your experience parallels my own, even to the problem domain (I used to :work for STN Atlas Elektronik GmbH of Bremen, Germany makers of fine :machines-that-go-ping) : :The difference is that we _did_ use descriminant records. Something :along the lines of.. [example and explanation of contracting benefits elided] I agree the technique you describe is a useful one for enhancing reliability. In fact we *did* use this form of contracting (for that is what it is) liberally and found it very useful. :I realise you know all this (at least in theory) but this is to confirm :that it works in practice too. Many errors were caught this way. : :Any reason why descriminant records weren't used in you project? They weren't used in this specific object only due to the restricted scope of the rewriting activity. There was initially a high degree of paranoia about reworking functionality that was deemed out-of-scope. However, it was clear that the benefits (in terms of increased reliablity and maintainability and of meeting a tight schedule) meant that reworking some supposedly out-of-scope code was worthwhile. Where I considered reliability and timeliness (resulting from reduced debugging time) was likely to be enhanced rather than compromised, I stepped outside our charter and simplified code. Previous experience with this simulation helped in this regard. This strategy paid off in that a reliable foundation was laid down for higher level modules to build on. This was important in light of the generally low initial domain experience of team members with this simulation (a Hull-Mounted Sonar + its Operator Console). By applying assertions to low-level objects, correct usage in higher level modules was enforced which enhanced overall reliability. A significant number of errors were identified as a result of this strategy. [Alan, I visited Le Rendezvous where we used to have pizza when we were at C3. Unfortunately, it's gone glitzy. What a shame! In the 11 years since then I still haven't found a Mexicana to match theirs.] Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au