Implementation and behavioural equivalence: A survey

Orejas, Fernando; Navarro, Marisa; Sánchez, Ana

doi:10.1007/3-540-56379-2_36

Cited by 21 publications

(15 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Following an observational approach [14], a system will be considered as a correct implementation of its specification if, as a model, it cannot be distinguished from a model of the specification. Since the system can only be observed through the observable formulas it satisfies, it is required to be equivalent to a model of the specification up to this notion of observability.…”

Section: Testing From Logical Specificationsmentioning

confidence: 99%

Integration Testing from Structured First-Order Specifications via Deduction Modulo

Longuet

Aiguier

2009

Theoretical Aspects of Computing - ICTAC 2009

View full text Add to dashboard Cite

Abstract. Testing from first-order specifications has mainly been studied for flat specifications, that are specifications of a single software module. However, the specifications of large software systems are generally built out of small specifications of individual modules, by enriching their union. The aim of integration testing is to test the composition of modules assuming that they have previously been verified, i.e. assuming their correctness. One of the main method for the selection of test cases from first-order specifications, called axiom unfolding, is based on a proof search for the different instances of the property to be tested, thus allowing the coverage of this property. The idea here is to use deduction modulo as a proof system for structured first-order specifications in the context of integration testing, so as to take advantage of the knowledge of the correctness of the individual modules.Testing is a very common practice in the software validation process. The principle of testing is to execute the software system on a subset of its possible inputs in order to detect failures. A failure is detected if the system behaves in a non-conformant way with respect to its specification.The testing process is usually decomposed into three phases: the selection of a relevant subset of the set of all the possible inputs of the system, called a test set; the submission of this test set to the system; the decision of the success or the failure of the test set submission, called the oracle problem. We focus here on the selection phase, which is the crucial point for the relevance and the efficiency of the testing process. In the approach called black-box testing, tests are selected from a (formal or informal) specification of the system, without any knowledge about the implementation.Our work follows the framework defined by Gaudel, Bernot and Marre [1], for testing from specifications expressed in a logical formalism. One approach to selection consists first in dividing an exhaustive test set into subsets, and then in choosing one test case in each of these subsets, thus building a finite test set which covers the initial exhaustive test set. One of the most studied selection method for testing from equational (and then first-order) specifications is known as axiom unfolding [1][2][3][4]. Its principle is to divide the initial exhaustive test set according to criteria derived from the axioms of the specification, using the well-known and efficient proof techniques associated to first-order logic.

show abstract

Section: Testing From Logical Specificationsmentioning

confidence: 99%

Integration Testing from Structured First-Order Specifications via Deduction Modulo

Longuet

Aiguier

2009

Theoretical Aspects of Computing - ICTAC 2009

View full text Add to dashboard Cite

show abstract

“…It must be noted that stating definition 10, we have changed the notion of satisfaction of a specification SP by a program P into a notion of behavioural satisfaction (more precisely, the "behavioural satisfaction I" of [25]), and we have kept the fact that the exhaustive test only considers those values which are finitely generated by ∑. Thus there is no more need that P defines a finitely generated ∑-algebra: it is sufficient that it can be observed as a finitely generated ∑-algebra via the observable contexts.…”

Section: T and U Of Sort S ∈ S O }mentioning

confidence: 99%

“…It is clear that other possibilities can arise: it may be possible to correctly decide whether two values of a type are equal even is there is not a built-in equality operation in the programming language. Remark 6: It is interesting to note that the restriction on the form of the specification introduced by definition 10 is mentioned in [25] as necessary to have a sensible definition of behavioural satisfaction based on the concept of observable consequence (our C(t) = C(t') are observable consequences of SP). It is clear that, depending on the kind of considered program, other observable exhaustive test sets could be defined, with some other kind of observation and thus a different notion of behavioural satisfaction.…”

Section: Remarkmentioning

confidence: 99%

Testing can be formal, too

Gaudel

1995

TAPSOFT '95: Theory and Practice of Software Development

202

147

View full text Add to dashboard Cite

Abstract. The paper presents a theory of program testing based on formal specifications. The formal semantics of the specifications is the basis for a notion of an exhaustive test set. Under some minimal hypotheses on the program under test, the success of this test set is equivalent to the satisfaction of the specification. The selection of a finite subset of the exhaustive test set can be seen as the introduction of more hypotheses on the program, called selection hypotheses. Several examples of commonly used selection hypotheses are presented. Another problem is the observability of the results of a program with respect to its specification : contrary to some common belief, the use of a formal specification is not always sufficient to decide whether a test execution is a success. As soon as the specification deals with more abstract entities than the program, program results may appear in a form which is not obviously equivalent to the specificied results. A solution to this problem is proposed in the case of algebraic specifications.

show abstract

“…In the framework of algebraic specifications this idea has been taken into account in many approaches in the literature proposing behavioral (or observational) refinement (or implementation) concepts; see e.g. [9,17,19,12,13,4] and, for an overview, [16,8]. However, due to the various different formalizations, there is still no clear picture of the relationships between the various approaches.…”

Section: Introductionmentioning

confidence: 99%

“…The general idea is then that the models of an implementing specification not necessarily have to lie in the model class of the specification to be implemented but it is sufficient if they lie in its "abstracted" model class (see e.g. [17,19,16,4]). Of course, there is again a variety of proposed behavioral abstraction operators which are either based on observational equivalences between algebras (see, e.g., [17,16]) or on observational equalities between the elements of algebras (see, e.g., [4]).…”

Section: Introductionmentioning

confidence: 99%

Externalized and Internalized Notions of Behavioral Refinement

Bidoit

Hennicker

2005

Theoretical Aspects of Computing – ICTAC 2005

View full text Add to dashboard Cite

Abstract.Many different behavioral refinement notions for algebraic specifications have been proposed in the literature but the relationship between the various concepts is still unclear. In this paper we provide a classification and a comparative study of behavioral refinements according to two directions, the externalized approach which uses an explicit behavioral abstraction operator that is applied to the specification to be implemented, and the internalized approach which uses a built-in behavioral semantics of specifications. We show that both concepts are equivalent under suitable conditions. The formal basis of our study is provided by the COL institution (constructor-based observational logic). Hence, as a side-effect of our study on internalized behavioral refinements, we introduce also a novel concept of behavioral refinement for COL-specifications.

show abstract

Implementation and behavioural equivalence: A survey

Cited by 21 publications

References 19 publications

Integration Testing from Structured First-Order Specifications via Deduction Modulo

Integration Testing from Structured First-Order Specifications via Deduction Modulo

Testing can be formal, too

Externalized and Internalized Notions of Behavioral Refinement

Contact Info

Product

Resources

About