Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!munnari.oz.au!samsung!cs.utexas.edu!usc!ucsd!rutgers!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <20007@duke.cs.duke.edu>
Date: 4 Jun 90 18:14:02 GMT
References: <4979@stpstn.UUCP  <102100009@p.cs.uiuc.edu  <5132@stpstn.UUCP  <19948@duke.cs.duke.edu  <4467@castle.ed.ac.uk
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 17

In article <4467@castle.ed.ac.uk  db@lfcs.ed.ac.uk (Dave Berry) writes:
 In article <19948@duke.cs.duke.edu  crm@romeo.cs.duke.edu (Charlie Martin) writes:
  The advantage of formal methods in real use (it seems to me, either
  philosophically or as an engineer) is that it gives us an argument to
  raise our degree of certainty so that we *can* believe that a few tests
  really do lead to near certainty that our implementation is going to
  work for any specified input.
 
 Another advantage is that they can be quicker than testing.  Witness
 the use of formal methods by INMOS in the development of the floating
 point unit for the T800 transputer.
 
Oops, this is going to restart the Fetzer-dilemma argument: I assume you
are asserting that you can *eliminate* testing through formal analysis.
Charlie Martin (...!mcnc!duke!crm, crm@summanulla.mc.duke.edu)
O: NBSR/One University Place/Suite 250/Durham, NC  27707/919-490-1966
H: 13 Gorham Place/Durham, NC 27705/919-383-2256