vinoski@apollo.HP.COM (Stephen Vinoski) (08/14/90)
In article <5456@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >Where inheritance really belongs, and where it offers its greatest >potential, is in the (as-yet-nonexistent) specification tools; i.e. >specification language "compilers" that compile an input notation, the >specification, into but *tests*; executable code, or "gauges", that determine >(by testing) whether a given implementation is within tolerance to its >specification. You often use chip/board/system analogies to get your point across, so let me do the same. Even though chip designers today have a plethora of tools available to help them design, simulate, and lay out their chips, they still rely heavily on human ingenuity in order to perform design verification (sometimes called "architectural verification" or "implementation verification"). A chip designer usually provides complete specifications for his/her chip, including timing diagrams and logic equations; these specifications are far more complete than any specification I have ever seen for a software package. Yet the process of proving that such a design meets its specification is still costly and complex. In the latest issue of IEEE Design and Test (August 1990, volume 7, number 4) there is an article entitled "Verifying a Multiprocessor Cache Controller Using Random Test Generation" by David A. Wood, Garth A. Gibson, and Randy H. Katz. The paper describes the use of pseudorandom test sequences to verify the complex interactions between multiple processors in functional simulation. Here is a quote (without permission) from that paper: "In fault coverage, the goal is to select chips that are free from fabrication errors - usually by testing all circuit nodes for stuck-at-0 and stuck-at-1 faults. In this case, the coverage is merely the fraction of nodes tested. Conversely, in design verification, the goal is to verify that the circuit or functional specification implements the semantics defined by a higher level specification. Because the possible state space is so large and poorly defined, we have no definitive way to evaluate the coverage of these tests." IMHO this problem becomes worse for software systems because they are in general more abstract and flexible than hardware systems. While your "gauges" may work for trivial software components such as Stacks and Lists, they will be extremely difficult to implement for anything much more complex than that. This software industry could probably learn quite a bit just by looking at the verification problems involved in designing the machines on our desks instead of looking at 200 year old gunsmiths. -steve | Steve Vinoski (508)256-6600 x5904 | Internet: vinoski@apollo.com | | Testability and Diagnostics | UUCP: ...mit-eddie!apollo!vinoski| | HP Apollo Division, Chelmsford, MA 01824 | ...uw-beaver!apollo!vinoski| | Kuwait summer blockbuster: "Iraq-nophobia" -David Letterman |