Antoy, S., Hamlet, D.: Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering 26(1) (2000) 55--69  Home/Search   Document Details and Download   Summary   Related Articles   Check

....implementation of the approach also becomes a partial proof of the achievement of my second goal that the runtime assertion checker can be used as a framework for developing other formal specification based tools. The essence of my approach is to view formal specifications as test oracles [2] [123] and to use a runtime assertion checker as the decision procedure for test oracles. The conventional way of implementing test oracles is to compare the test output to some pre calculated, presumably correct, output. However, my approach is to monitor the specified behavior of the method ....

....is to throw an appropriate exception when the argument is negative. Compare this with the specification and the faulty implementation shown in Figure 8.1. Several researchers have already noticed that if a program is formally specified, it should be possible to use the specification as an oracle [2] [123] Thus, the idea of automatically generating test oracles Actually, the tool generates a separate test method that checks whether the class under test was compiled with the JML compiler or not. In addition, it also generates a separate test method that checks for the initialization of ....

[Article contains additional citation context not shown here]

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

....In sum, the JML compiler brings programming benefits to formal interface specifications by allowing Java programmers to use JML specifications as practical and e#ective tools for debugging, testing, and design by contract. 3. 3 Unit Testing A formal specification can be viewed as a test oracle [37,2], and a runtime assertion checker can be used as the decision procedure for the test oracle [11] This idea has been implemented as a unit testing tool for Java (jmlunit) by combining JML with the popular unit testing tool JUnit for Java [4] The jmlunit tool, developed at Iowa State University, ....

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

....introduces one change ( mutations ) to a specification to check the coverage of a test set. Woodward s system includes a simple test generation method that uses the signatures of specifications. Algebraic specifications have been used successfully to test implementations of abstract data types [18, 40, 29, 4]. One of the more recent systems, Daistish [29] allows for the algebraic testing of OO programs in the presence of side e#ects. In Daistish, the user defines a mapping between an algebraic specification and an implementation of the specification. The system then checks whether the axioms hold, ....

....testing of OO programs in the presence of side e#ects. In Daistish, the user defines a mapping between an algebraic specification and an implementation of the specification. The system then checks whether the axioms hold, given user defined test vectors. Similarly, the system by Antoy et al. [4] requires the users to give explicit mappings between specification and implementation. Our system automatically generates both the mapping and the test suite. Our work builds upon Doong and Frankl s definition of observational equivalence and we were inspired by their algorithm for generating ....

S. Antoy and D. Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1), Jan. 2000.

....their arguments, so the programs to be tested were essentially restricted to be functional. Later work aims to relax this restriction: Antoy and Hamlet describe a technique for testing C classes against an algebraic speci cation, which is animated in order to predict the correct result [1]. The speci cation language must be somewhat restricted in order to guarantee that speci cations can be animated. The concrete and abstract states are related by a programmer de ned abstraction function, just as in this paper. Antoy and Hamlet do not address test case generation, leaving that ....

S. Antoy and R. Hamlet. Automatically checking an implementation against its formal speci cation. In Irvine Software Symposium, pages 29-48, March 1992.

....is that by using the EQN function to check outputs, in effect, we combine many Protest test cases into a single test case. On the other hand, Protest s handling of exceptions is certainly an important idea, which we would like to try to incorporate into future versions of ASTOOT. Antoy and Hamlet [2] have proposed a system that compares a class implementation to a more abstract representation which is based on term re writing and is derived directly from the specification. The user supplies an explicit representation function mapping the concrete representation to the abstract representation. ....

S. Antoy and D. Hamlet. Automatically checking an implementation against its formal specification. Technical Report TR 91--1, Rev. 1, Portland State University, Jan. 1992.

....with oracles, since each oracle is specific to test cases derived from a particular axiom. It cannot be used to derive general oracles for arbitrary test cases. 4.3. 2 Self checking ADTs A more recent approach to extracting test oracles from abstract data types, described by Antoy and Hamlet [AH00] treats the algebraic specification essentially as an alternative implementation whose behavior can be compared to the conventional by hand implementation. In contrast to DAISTS, this approach does not extract test cases along with the test oracles, but the derived oracles are general in the ....

....system ensures confluence and termination to make the rewriting process simpler and more efficient than it would be otherwise, though presumably still less efficient than a conventional implementation of the ADT. Example 19 Parts of an algebraic specification for the self checking ADTintset ( AH00] Constructors: empty(integer, integer) insert(integer, intset) empty creates an empty set by requiring its size and the upper bound for its elements. insert inserts a new integer in the intset set. Axioms: empty(M, R) M 1orR M empty must abort ( if( either the size M is less ....

[Article contains additional citation context not shown here]

Sergio Antoy and Richard G. Hamlet. Automatically Checking an Implementation against Its Formal Specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

....a result is correct, than to prove the algorithm correct that produces the result. For example, it is di#cult to factor an integer, but, given x and y , it is trivial to determine whether or not y is a factor of x . In our case the checker is the specification. Using this idea, Antoy and Hamlet [1] propose the use of algebraic specifications to specify software. Algebraic specifications use high level data structures, thus solving one of the aforementioned problems of pre post conditions. The price is that when checking the implementation against the specification one needs abstraction. ....

Sergio Antoy and Richard G. Hamlet. Automatically checking an implementation against its formal specification. Software Engineering, 26(1):55--69, 2000.

....the derived class is a complex mix of items de ned in the base class and those de ned in the derived class. We can try to address the problem in one of two di erent ways. First, we could try to recast the testing so that it too works at an abstract level; this is the approach of several authors [1, 5, 6], and we will discuss some of these in the next section. The second approach, the one we use in this paper, would be to work with a concrete speci cation of the class. We will see the complete details later in the paper, but in essence a concrete speci cation of a class B characterizes the ....

....to have available, the concrete speci cation of the class. This is not to suggest that when testing the client code, we should rely on the concrete speci cation of the class; for that purpose, we should of course rely only on the abstract view of the class perhaps using approaches such as those of [1]; we will return to this discussion in the nal section of the paper. The main contributions of this paper may be summarized as follows: It makes the case that a natural approach to speci cation based testing of OO systems, especially when dealing with derived classes, is to base the tests on ....

[Article contains additional citation context not shown here]

S. Antoy and D. Hamlet. Automatically checking an implementation against its formal specication. IEEE Trans. on Software Eng., 26:55-69, 2000.

....they include a powerful polymorphic type system such as OBJ or Larch. Finally, because the assertions are related to individual procedures, they are very homogeneous. 4.4. 2 Self Checking Objects Another approach for a testing tool based on algebraic specifications was taken by Antoy and Hamlet[AH92] Their self checking objects were specified with executable algebraic specifications and implemented in C . Consistency checking between the specification and the implementation checks that each object s representation of its abstract value is equivalent to an explicit abstraction function ....

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. In Richard W. Selby, editor, Proceedings of the 2nd Irvine Software Symposium, pages 29--48. The Irvine Research Unit in Software, University of California, Irvine, March 6, 1992.

....any specification. Most important, it is not always easy to find properties that uniquely and completely characterize the behavior of an operation. What is missing in these approaches is a satisfactory degree of independence between the code and its assertions. A more sophisticated approach [5] based on the direct implementation of a specification achieves this goal of independence. The specification is directly implemented with the intent of running it together with the code that it specifies. The direct implementation is no longer a prototype in the classical sense, but it coexists ....

....is invoked, and we must deal with two different representations for the type sequence: the representation chosen by the class implementer, that we refer to as concrete, and the representation generated by the direct implementation scheme, that we refer to as abstract. The solution discussed in [5] maintains both representations of an object. The test for equality performed by an assertion is between abstract representations. The concrete representation of an object at the end of the execution of a method is mapped to its abstract counterpart using what in [18] is called a representation ....

[Article contains additional citation context not shown here]

S. Antoy and D. Hamlet. Automatically checking an implementation against its formal specifications. In 2nd Irvine Software Symposium, pages 29--48, Irvine, CA, March 6 1992.

No context found.

Antoy, S., Hamlet, D.: Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering 26(1) (2000) 55--69

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal speci cation. IEEE Transactions on Software Engineering, 26(1):55-69, January 2000. Lilian Burdy et al.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000. Lilian Burdy et al.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

No context found.

Antoy S, Hamlet D (2000) Automatically checking an implementation against its formal specification. IEEE Trans Softw Eng 26(1):55--69

No context found.

S. Antoy and D. Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1), Jan. 2000.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000. Lilian Burdy et al.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal speci cation. IEEE Transactions on Software Engineering, 26(1):55-69, January 2000. Lilian Burdy et al.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

No context found.

S. Antoy and D. Hamlet, Automatically Checking an Implementation against its Formal Specification, IEEE Transactions on Software Engineering, Vol. 26(1), January 2000, pp.55--69.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal specification. IEEE Transactions on Software Engineering, 26(1):55--69, January 2000.

No context found.

Sergio Antoy and Dick Hamlet. Automatically checking an implementation against its formal speci cation. IEEE Transactions on Software Engineering, 26(1):55-69, January 2000.

No context found.

S. Antoy and D. Hamlet, "Automatically Checking an Implementation Against its Formal Specification," IEEE Transactions on Software Engineering, v. 26, n. 1, January 2000, pp. 55-69.

No context found.

S. Antoy and R. Hamlet. Automatically checking an implementation against its formal specification. In Irvine Software Symposium, pages 29--48, Irvine, CA, March 1992.

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