I. J. Hayes and C. B. Jones, "Specifications are not (necessarily) executable," IEE/BCS Software Engineering Journal, vol. 6, pp. 320-338, 1989.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....Discovery of specification inconsistencies and simple errors; and 3. Validation of functions and expected behaviour through executed test cases. For animation to be possible, the specification must be in an executable form. Hayes and Jones note the dangers of encouraging executable specifications [15], suggesting that useful specification strategies and styles are precluded and it is impossible to include assumptions or clauses that are not computable. Furthermore, executable specifications may not allow nondeterminism; a useful and sometimes necessary specification tool. They conclude that ....

I. J. Hayes and C. B. Jones, "Specifications are not (necessarily) executable," IEE/BCS Software Engineering Journal, vol. 6, pp. 320-338, 1989.

....in a wide range of publications without any agreement between the two factions. The non executable advocates concede the difficulties of relating specifications to a customer, but argue that better solutions should be sought other than presenting the customer with an executable model (see [64], for example) It is argued that, in general, a specification written in a notation that is not directly executable contains less implementation detail than an executable model. Matching such a specification to user requirements is, it is claimed, more straightforward since there are no additonal ....

I.J. Hayes and C.B. Jones. Specifications are not necessarily executable. Technical report, Department of Computing Science, University of Queensland, Australia, December 1989.

....techniques. As a final example on the extensive literature on executing formal specifications, we mention the work of Kans and Hayton [11] who succeed in prototyping a subset of VDM in ABC, a dialect of BASIC Perhaps in response to these efforts in executing specifications, Hayes and Jones [12] advocate that specifications are not (necessarily) executable. They consider various classes of problem and show the utility of specification notations involving inverses, negation, and quantifiers. They also consider different uses for nondeterminism, a useful specification device, but one which ....

....to the separable objective of prototyping . Implicitly they are arguing in favour of other methods of validation (reviews and proof) rather than execution. As a direct riposte, Norbert E Fuchs [14] argues that specifications are (preferably) executable . He takes examples from Hayes and Jones [12] and translates them into a logic specification language (LSL) which is more expressive than Prolog. The translation scheme was not automated. It is claimed that the translations are made on almost the same level of abstraction and without essentially altering their structure . While this claim ....

[Article contains additional citation context not shown here]

Hayes, I. J., Jones, C. B.: `Specifications are not (necessarily) executable', Software Engineering Journal, 1989, 4, (6), pp. 320-338

....many lower level implementation decisions have to be made and the errors detected from the prototype may not necessarily reflect those errors in the specification but those occurred in the prototyping process. Also this approach is not effective in addressing issues such as non deterministics [6]. Symbolic execution. This approach regards a specification as a state machine and symbolically execute the specification [7] The inputs are symbolic expressions stating the input constraints such as pre conditions. The outputs are also symbolic expressions propagated from an execution of a ....

Hayes, I.J. and Jones, C.B., "Specifications Are Not (Necessarily) Executable", Software Engineering Journal, 4(6):330-338, 1989.

....lower level implementation decisions have to be made and the errors detected from the prototype reflect possible errors in the specification indirectly and maybe simply errors occurred in the prototyping process. Also this approach is not effective in addressing issues such as non deterministisms [6]. Symbolic execution. This approach regards a specification as a state machine and symbolically execute the specification [7] The inputs are symbolic expressions stating the input constraints such as pre conditions. The outputs, which also symbolic expressions propagated from an execution of a ....

Hayes, I.J. and Jones, C.B., "Specifications Are Not (Necessarily) Executable", Software Engineering Journal, 4(6):330-338, 1989.

....animation can take place. This extremely limits the search space. In other words, this approach allows us to check particular cases (or scenarios ) instead of generating all possible solutions (which was the case in the previously presented approach) C. Problems with Animation Hayes and Jones [23] point out that executable specifications can unnecessarily constrain the choice of possible implementation since the developer might be tempted to use certain algorithmic details to ensure the executability of the specification. This temptation should certainly be avoided. However, as shown by ....

....the user input was correct. The ability to express noncomputable problems in a specification language is very important. This ability en IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. Y, MONTH 1999 4 ables the formulation of more general specifications. As Hayes and Jones point out [23], noncomputable clauses when conjoint with some other clauses can result in useful and computable specifications. These additional clauses refine the general specification and introduce some more implementation detail. The structure of a specification makes certain properties of the specified ....

[Article contains additional citation context not shown here]

I. J. Hayes and C. B. Jones, "Specifications are not (necessarily) executable," in Software Engineering Journal, vol. 4, no. 6, pages 330--338, 1989.

....approaches taken to them by their practitioners. 2.1 Programming its role and nature In what follows, we use the term programming in a specific way to refer to the construction of specifications of computations. This includes non executable formal specifications , in one dominant sense [7] of the term, as well as executable specifications, which objectively includes programs. Note that this extended view of programming differs from the programming as coding characterisation in two ways: first, because of the inclusion of other than executable code; and second, because of the ....

Hayes, I and Jones, C., "Specifications are not (Necessarily) Executable", Software Engineering Journal, vol. 4, no. 6, pp. 330-339 (1989).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC