Design-by-Contract

ABSTRACT Classical views on testing and their associated testing models are not dealing with the question of fault repairing but only focus on fault detection. Diagnosis consists of determining the nature of a detected fault, of locating it and hopefully repairing it. Correlatively, the only standardized quality factors implied in the detection/repair aspects of software engineering are testability and maintainability: those quality factors are misleading since they do not pinpoint this question of the location/repairing effort, that can be identified under the concept of diagnosability. This paper is thus concerned with diagnosability, its definition and the axiomatization of its expected behavior. The paper aims at:•introducing and analysing diagnosability as a significant and complementary dimension of software testability,•producing a high-level definition and axiomatization of a diagnosability measurement generic enough to be adapted to various software paradigms: this property-based approach serves as a measurement “specification”, independent on the application context and thus reusable,•detailing a diagnosability measure dedicated to data-flow software and especially test strategies impact on diagnosis and testing effort (from measure implementation to case study),•illustrating the reuse of the high-level axiomatization to the specific question of measuring the impact of assertions (or contracts for a designed by contract OO system) on diagnosis effort and preciseness.Throughout the paper, the concepts are illustrated on a case study provided by an industrial partner. At last, the reusability of the axiomatization is illustrated by proposing a measure of the impact of assertions (or contracts in a design by contract approach) on global software diagnosability. Main lessons concern both the diagnosability significance as a quality factor and the interest of an axiomatization-based methodology for building trustable software measurement.

Object-Z is an object-oriented specification language which extends the Z language with classes, objects, inheritance and polymorphism that can be used to represent the specification of a complex system as collections of objects. There are a number of existing works that mapped Object-Z to C++ and Java programming languages. Since Python and Object-Z share many similarities, both are object-oriented paradigm, support set theory and predicate calculus moreover, Python is a functional programming language which is naturally closer to formal specifications, we propose a mapping from Object-Z specifications to Python code that covers some Object-Z constructs and express its specifications in Python to validate these specifications. The validations are used in the mapping covered preconditions, post-conditions, and invariants that are built using lambda function and Python's decorator. This work has found Python is an excellent language for developing libraries to map Object-Z specif...

The artifacts of Analysis and Design Methodologies are specified by means of modeling languages. In a relatively short period of time, UML has become the "lingua franca" in software engineering. Metamodeling and abstraction are among the concepts and techniques strongly promoted by UML. The Object Constraint Language, as a textual formalism of UML, plays a key role in understanding and

Statecharts constitute an executable language for modelling event-based reactive systems. The essential complexity of statechart models solicits the need for advanced model testing and validation techniques. In this article we propose a method aimed at enhancing statechart design with a range of techniques that have proven their usefulness to increase the quality and reliability of source code. The method is accompanied by a process that flexibly accommodates testing and validation techniques such as test-driven development, behaviour-driven development, design by contract, and property statecharts that check for violations of behavioural properties during statechart execution. The method is supported by the Sismic tool, an open source statechart interpreter library in Python, that supports all the aforementioned techniques. Based on this tooling, we carry out a controlled user study to evaluate the feasibility, usefulness and adequacy of the proposed techniques for statechart testing and validation.

In the last years, the concern with the correctness of programs has been leading programmers to enrich their programs with annotations following the principles of design-by-contract, in order to be able to guarantee their correct behaviour and to facilitate reuse of verified components without having to reconstruct proofs of correctness. In this paper we adapt the idea of specification-based slicing to the scope of (contract-based) program verification systems and behaviour specification languages. In this direction, we introduce the notion of contract-based slice of a program and show how any specification-based slicing algorithm can be used as the basis for a contract-based slicing algorithm.

Object-Z is an object-oriented specification language which extends the Z language with classes, objects, inheritance and polymorphism that can be used to represent the specification of a complex system as collections of objects. There are a number of existing works that mapped Object-Z to C++ and Java programming languages. Since Python and Object-Z share many similarities, both are object-oriented paradigm, support set theory and predicate calculus moreover, Python is a functional programming language which is naturally closer to formal specifications, we propose a mapping from Object-Z specifications to Python code that covers some Object-Z constructs and express its specifications in Python to validate these specifications. The validations are used in the mapping covered preconditions, post-conditions, and invariants that are built using lambda function and Python's decorator. This work has found Python is an excellent language for developing libraries to map Object-Z specifications to Python.

Predicate testing, also known as (branch) condition testing, is most often filed under structural (white box) test case design techniques. Nevertheless, contract-based specification techniques allow for adapting classical predicate testing as a functional (black box) design technique on the class resp. component test level, too. In this paper we discuss various predicate testing coverage criteria known from the literature, adapt them for functional test case design focusing on “design by contract” specifications, and report on a tool supporting both structural and functional predicate coverage testing for Java programs with OCL specifications for invariants and preand postconditions.

Testing is commonly used to check conformance in contract-based programs, as verification by formal proofs is hard to scale and static analysis is, sometimes, limited for detecting general nonconformances. Traditional test cases, with manually-provided data, may be ineffective in detecting subtle nonconformances that arise only after several instantiations and modifications in objects under test. Those nonconformances may signalize more subtle bugs, hindering the benefits of using contract-based programs. Random-generated tests with automatic test data generation, on the other hand, is a promising approach when more substantial testing is demanded. In this work, we propose and evaluate an approach, JMLOK 2.0, for automatically detecting and categorizing nonconformances, in the context of Java Modeling Language (JML). Our approach aims to help the programmer in the process of nonconformances correction. The detection is backed by Randomly-Generated Tests (RGT) approach. And the categorization is backed by heuristics-based approach. We perform two evaluations. First, we perform an evaluation of our detection approach and our manual categorization process: we detected 84 nonconformances in over 29 KLOC and 9 K lines of JML contracts (that we will refer as KLJML henceforth); applying our manual classification system we got that most detected nonconformances were classified as postcondition errors; we also observed that a nonconformance is detected after 2.54 top-level test case calls, in average, and the number of internal calls within the faulty test case call is an average of 2.23, providing evidence for the need of a more complex generated test structure in nonconformance detection; furthermore, we compare our approach with JET, an existing test-based approach for detecting nonconformances in JML programs, using a subset of programs from first study (6 KLOC and 5 KLJML). JMLOK 2.0 detected 30 nonconformances with Java coverage of 78.44% and JML coverage of 67.67%, while JET detected 9 nonconformances by covering 47.97% of Java and 56.97% of JML. Second, we perform an evaluation of our automatic categorization approach: we compare automatic and manual categorization and got a matches value of 0.73 (considering the nonconformances from first evaluation) indicating similarity between automatic and manual approaches; furthermore, we compare our results with the categorization performed by voluntary JML experts and we also observed some similarity.

ESpec is a suite of tools that facilitates the testing and veriflcation of object-oriented Eifiel programs in an integrated environment. The suite includes unit testing tools (ES-Test) and Fit tables (ES-Fit for customer requirements) that report contract failures. This paper describes ES-Verify (part of ESpec) for automatically verifying a signiflcant subset of Eifiel constructs written with a value semantics. The

Learning object design by contract is a proposal for formalization of learning object metadata in order to enhance the design of Web-based educational contents by augmenting their reusability. It basically consists of a formal notation that allows stating, in the form of declarations called contracts, the conditions under which a learning object can be used and the outcomes that might be expected from its use. Contracts become a very beneficial instrument when new educational resources are automatically generated from combining ...

... Index Terms—Object-oriented design methods, programming by contract, diagnostics, metrics. Ç 1 INTRODUCTION SEVERAL works advocate the use of assertions to improve software quality [1], [2], [3], [4], [5], but very few are actually interested in measuring this improvement. ...

Abstract Design by contract is the principle that the interfaces between modules of a software system-especially a mission-critical one-should be governed by precise specifications. The contracts cover mutual obligations (pre-conditions), benefits (post-conditions), and consistency constraints (invariants). Together, these properties are known as assertions, and are directly supported in some design and programming languages. A recent $500 million software error provides a sobering reminder that this principle is not ...