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: Alan Brain Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/16 Message-ID: <33CD9227.4298@dynamite.com.au>#1/1 X-Deja-AN: 257182279 References: Organization: @Home Reply-To: aebrain@dynamite.com.au Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-16T00:00:00+00:00 List-Id: 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: type TRACK_RECORD_TYPE ( IS_VALID : boolean ) is record case IS_VALID is when false => null; when true => -- a whole heap of information -- such as relative bearing, time last updated, etc etc -- references to threat library, access types to FRAZ and DEMON grams -- and so on. end case; end record; -- assume you have a declared index type TRACK_INDEX_TYPE, typically a -- subtype of integer rather than anonymous, and with a range of about 1..1024 type TRACK_STORE_TYPE is array ( TRACK_INDEX_TYPE ) of TRACK_RECORD_TYPE; -- Then just declare however many track stores you need of this type... In use, of course, this meant that unless you made sure that the track was valid, an exception would be raised. Forex: if TRACK_STORE(THIS_TRACK).IS_VALID then -- do whatever is needed, the track is valid, so all the fields exist end if; If you missed out this test, then at run time, you'd get an exception raised, caused by the fact that if the track ain't valid, then such items as relative bearing etc are undefined, irrelevant, and just plain don't exist. Using this method, it's just not possible to assign a speed or whatever to an invalid track. 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? -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM 100026.2014 compuserve o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale See http://www.z-world.com/graphics/z/master/8856.gif for picture