Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!mcnc!duke!romeo!crm From: crm@romeo.cs.duke.edu (Charlie Martin) Newsgroups: comp.software-eng Subject: Re: Reuse and Abstraction (was: reu Summary: logical flaws and differences in terminology Message-ID: <19948@duke.cs.duke.edu> Date: 31 May 90 17:13:34 GMT References: <4979@stpstn.UUCP> <102100009@p.cs.uiuc.edu> <5132@stpstn.UUCP> Sender: news@duke.cs.duke.edu Lines: 107 In article <19848@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes: > >It is afulyy hard sometimes to educate people to write a specification >that doesn't express their idea of how the software is to be designed. >I agree with you: computer scientists should educate themselves. Couldn't it be that we're looking through the wrong end of the telescope with all this emphasis on mathematics? *Everybody* deals with with the distinctions between requirement, specification, and implementation, even common-sense individuals like plumbers, waiters, etc. It certainly *could* be, but I don't think we *are*. The problem here is that we are often dealing with something other than common-sense objects when we deal with software. At the lowest level, we're dealing with an arbitrary instruction set; at higher levels, we are often dealing with abstractions that purport to be mathematical objects: integers. "real" numbers, Sets, OrderedSets.... The only meaningful specification for these is inherently mathematical. The behavior of a "float" in calculations often has nothing common-sensical about it whatsoever. They don't work as we expect from the arithmetic we learned in 3rd grade, and they screw up the rules we learned in 9th grade algebra -- sometimes. Higher level abstractions often get worse, not better. I admit that we can make up some kind of reasonable expectation about typing into a window on a screen, based on our knowledge of typing on paper (but even then, we don't actually build systems that work that way, although a few old text editors did) but there is no common-sense to appeal to about what happens when we double-click a mouse. [T]he common-sense meaning of these terms is precisely the meaning that I've been using. An implementation is *correct* if it complies to its *specification* within an acceptable tolerance. There's nothing mathematical about it. Come on Brad, you're contradicting yourself in-line, here. "...within an acceptable tolerance" is a mathematical statement, and it's interpreted as such in ANY form of engineering. If I design a gear and I want it milled to within one-one-thousandth of an inch, I am stating a measure, and stating a numerical value against which the measured gear can be compared by measuring. If I want to do QA on gears, I state a statistical distribution and acceptable variance. These are all mathematical statements. For a wonderful treatise on this topic, read "Zen and the Art of Motorcycle Maintenance; An Inquiry into Values". It winds up being about a definition of *quality*, which is close to *correctness*. Won't repeat his arguments here...but really try to read this book! If anyone is reading this who *hasn't* read Persig's book, then for Ghod's sake stop at the library on the way home. But, as much as I like and admire the book, its major premise is that Quality (Persig's way of denoting the special thing he is talking about) is something that can't be measured or quantified in any way -- that any attempt to do so is *maya*, illusion, part of the world of words, not the world of things. So this leads to the implication that Brad is saying that Correctness is also something that can't be measured or quantified in any way. I can see the argument, which is one reason that I wish the formal methods folks had chosen some other word -- say "compliance" -- for the concept of "meets the specification in all cases." (After all, it is not in some sense correct unless the user *likes* it; the only measure for this is if they then *pay* for it, and this can be a very indirect one.) However, attractive as it is philosophically, it's not a useful idea for engineering. It comes down to arguing that whether or not an implementation meets its specification is something that is not mathematical, not quantifiable or measurable in any way. (Notice that this excludes *testing* just as much as it does proof). If Correctness really *is* like Persig's Quality, then there is only the ability of a trained eye to directly perceive the wondrous Correctness of the result of one's engineering efforts. I don't think that is suitable in any kind of engineering: I certainly wouldn't want to drive across a bridge whose capacity couldn't be measured. The difficulty of a purely testing-based approach to "correctness" as Brad is apparently advocating, is that we CAN'T in all cases depend on the common-sense behavior of the system in question. To steal an example from your paper (which I got today, thanks!) a gunsmith can be satisfied with testing a gunbarrel by putting four times the charge into the barrel and then firing it BECAUSE he can depend that a barrel which doesn't explode with 1000 grains of powder is very very unlikely to explode with 995 grains of powder, or 250 grains of powder. But there are real bugs in real systems that manifest by the system working fine for values 1..236, failing for values 237, 559, and 623, then working perfectly on every other value on up to 1000. In this situation, assuming that all these values are equiprobable in use, then the probability of failure over all is 3 in 1000 -- but testing with a value of 1000 doesn't tell us that. Nor does testing with a value of 4000, even if it works. 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. 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