Final Data Types and Their Specification

This paper addresses the problem of constructing test data sets from formal specifications. Starting from a notion of an ideal exhaustive test data set which is derived from the notion of satisfaction of the formal specification, it is shown how to select by refinements a practicable test set, i.e. computable, not rejecting correct programs (unbiased), and accepting only correct programs (valid), assuming some hypotheses. The hypotheses play an important role: they formalize common test practices and they express the gap between the success of the test and correctness ; the size of the test set depends on the strength of the hypotheses.The paper shows an application of this theory in the case of algebraic specifications and presents the actual procedures used to mechanically produce such test sets, using Horn clause logic. These procedures are embedded in an interactive system which, given some general hypotheses schemes and an algebraic specification, produces a test set and the corresponding hypotheses.

show abstract

“…This minimal hypothesis reflects the classical notion of correctness up to behavioural equivalence (as defined in [20,31] or [18] for instance).…”

Section: The Oraclementioning

confidence: 60%

Software testing based on formal specifications: a theory and a tool

1991

View full text Add to dashboard Cite

show abstract

“…The algebraic approach, which defines data types to be heterogeneous algebras [3], uses axioms to specify properties of programs and abstract data types, but the axioms are restricted to equations. Much work has been done on algebraic specifications for abstract data types [1,6,8,29,4,5,28,16]; we use more recent work on Larch specifications [10,11] for sequential program modules.…”

Section: Related Workmentioning

confidence: 99%

Axioms for concurrent objects

Herlihy

Wing

1987

Proceedings of the 14th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages - POPL '87

105

View full text Add to dashboard Cite

Specification and verification techniques for abstract data types that have been successful for sequential programs can be extended in a natural way to provide the same benefits for concurrent programs. We propose an approach to specifying and verifying concurrent objects based on a novel correctness condition, which we call linearizability.Linearizability provides the illusion that each operation takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object's operations can still be given by pre-and postconditions. In this paper, we will define and discuss linearizability, and then give examples of how to reason about concurrent objects and verify their implementations based on their (sequential) axiomatic specifications.

show abstract

“…This approach defines data types to be heterogeneous algebras [5]. Much work has been done on the algebraic specification of abstract data types [2,7,10,17,32,50,561, including the handling of error values [2,14,331, nondeterminism [33], and parameterization [ll, 15,491. Our work is related to both the axiomatic and algebraic approaches. In the interface language component of a two-tiered specification, we use an axiomatic approach.…”

Section: Focus Of This Papermentioning

confidence: 99%

Writing Larch interface language specifications

Wing

1987

ACM Trans. Program. Lang. Syst.

101

View full text Add to dashboard Cite

Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal specification languages has evolved to support a two-tiered approach to writing specifications. This approach separates the specification of state transformations and programming language dependencies from the specification of underlying abstractions. Thus, each member of the Larch family has a subset derived from a programming language and another subset independent of any programming languages. We call the former interface languages, and the latter the Larch Shared Language. This paper focuses on Larch interface language specifications. Through examples, we illustrate some salient features of Larch/CLU, a Larch interface language for the programming language CLU. We give an example of writing an interface specification following the two-tiered approach and discuss in detail issues involved in writing interface specifications and their interaction with their Shared Language components.

show abstract

Final Data Types and Their Specification

Cited by 69 publications

References 26 publications

Software testing based on formal specifications: a theory and a tool

Software testing based on formal specifications: a theory and a tool

Axioms for concurrent objects

Writing Larch interface language specifications

Contact Info

Product

Resources

About