Writing Simulatable Specifications in Special

Abstract

It is commonly accepted that most software systems contain large numbers of errors that are not detected until delivery and testing by the customer. Some studies have determined that errors are most likely to be introduced in the design phase; perhaps up to two-thirds of all system errors are design errors. Formal specifications can be a useful vehicle for exposing design errors by forcing attention early in the system development process on “what the system should do.” Although specifications are an improvement over, say, natural language for describing systems, even if carefully read they cannot be expected to eliminate all design errors. Fortunately, because specifications are supposed to be complete, it is in principle possible to execute them with test data exactly as one would execute code. We call such an execution of specifications module simulation, where the module is assumed to be the unit that is specified.

Our concern in this paper is with simulating specifications written in SPECIAL (SPECfication and Assertion Language). Many of the constructs in SPECIAL cannot be simulated, except very inefficiently with a theorem prover. However, there is a subset of SPECIAL that can still be used to produce attractive specifications, and that can be easily simulated. With several examples, we exhibit the trade-off between the elegance of a specification and its amenability to simulation.

The research reported in this paper was sponsored by the Rome Air Development Center and the Naval Ocean System Center under Contract N00123-76-C-0195.