DOCSLIB.ORG

Grammar-Based Testing Using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Grammar-Based Testing Using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet To cite this version: Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet. Grammar-Based Testing using Realistic Domains in PHP. A-MOST 2012, 8th Workshop on Advances in Model Based Testing, joint to the ICST’12 IEEE Int. Conf. on Software Testing, Verification and Validation, Jan 2012, Canada. pp.509–518. hal-00931662 HAL Id: hal-00931662 https://hal.archives-ouvertes.fr/hal-00931662 Submitted on 16 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Fred´ eric´ Dadeau, Alain Giorgetti and Fabrice Bouquet Institut FEMTO-ST UMR CNRS 6174 - University of Franche-Comte´ - INRIA CASSIS Project 16 route de Gray - 25030 Besanc¸on cedex, France Email: fivan.enderlin,frederic.dadeau,alain.giorgetti,[email protected] Abstract—This paper presents an integration of grammar- Contract-based testing [5] has been introduced in part to based testing in a framework for contract-based testing in PHP. address these limitations. It is based on the notion of Design It relies on the notion of realistic domains, that make it possible by Contract (DbC) [6] introduced by Meyer with Eiffel [7]. to assign domains to data, by means of contract assertions written inside the source code of a PHP application. Then a test A contract is a way to embed a piece of model inside the generation tool uses the contracts to generate relevant test data code of a program. It mainly consists of two kinds of simple for unit testing. Finally a runtime assertion checker validates the modelling elements: invariants describe properties that should assertions inside the contracts (among others membership of data hold at each step of the execution, pre- and postconditions to realistic domains) to establish the conformance verdict. We respectively represent the conditions that have to hold for an introduce here the possibility to generate and validate complex textual data specified by a grammar written in a dedicated operation/method to be invoked, and the conditions that have grammar description language. This approach is tool-supported to hold after the execution of the operation/method. and experimented on the validation of web applications. Various contract languages extend programming languages, Keywords-Grammar-based testing, contracts, realistic domains, such as JML for Java [8], ACSL for C [9], Spec# for PHP, random generation, rule coverage. C# [10]. The advantages of contracts are numerous: they make it possible to introduce formal properties inside the code I. INTRODUCTION of a program, using annotations. Besides, the properties are Model-based testing [1] is a technique according to which a expressed in the same formalism as the code, without any (preferably formal) model of the System Under Test (SUT) is gap due to the abstraction level. Moreover, properties can be employed in order to validate it. In this context, the model can exploited for (unit) testing. Indeed, the information contained be of two uses. First, it can be used to compute the test cases in invariants and preconditions can be used to generate test by providing an exploitable abstraction of the SUT from which data. In addition, these assertions can be checked at run time test data or even test sequences can be computed. Second, the (preconditions and invariants are checked at the beginning of model can provide the test oracle, namely the expected result the method, postconditions and invariants at their end) and against which the execution of the SUT is checked. Model- thus provide a (partial) test oracle for free. The test succeeds based testing makes it possible to automate the test generation. if no assertion is violated, and fails otherwise. It is implemented in many tools, based on various modelling In a previous work, we have introduced Praspel, a tool- languages or notations [2]. In addition, model-based testing is supported specification language for contract-based testing also an efficient approach for testing software evolution and in PHP [11]. Praspel extends contracts with the notion of regression, mainly by facilitating the maintainability of the test realistic domain, which makes it possible to assign a domain of repository [3]. values to data (class attributes or method parameters). Realistic Even though model-based testing is very convenient in domains present two useful features for testing: predicability, theory, its application is often restricted to critical and/or which is the possibility to check that a data belongs to its embedded software that require a high level of validation [4]. associated domain, and samplability, which is the possibility Several causes can be identified. First, the design of the to automatically generate a data from a realistic domain. A formal model represents an additional cost, and is sometimes library for predefined basic realistic domains (mainly scalar more expensive than the manual validation cost. Second, the domains, strings, arrays) is already available along with a design of the model is a complex task that requires modelling test environment.1 It is to be noted that one of the main skills and understanding of formal methods, thus necessitating arguments against annotation languages is that they require the dedicated skilled engineers for being put into practice. Finally, source code of the application to be employed, which prevents as the model represents an abstraction of the SUT, the distance them from being used in a black-box approach. Nevertheless, between the model and the considered system may vary and applying contract-based testing to interpreted languages, such thus an additional step of test concretization is often required as PHP, makes full sense, since this limitation does not apply. to translate abstract test cases (computed from the model) into Validating PHP web applications often involves the gen- executable test scripts (using the API provided by the SUT and the concrete data that it operates). 1Freely available at http://hoa-project.net. class EmailAddress extends String f eration of structured textual test data (e.g. specific pieces of HTML code produced by a web application, email addresses, public function predicate($q) f // regular expression for email addresses SQL or HTTP queries, or more complex messages). To facili- // see. RFC 2822, 3.4.1. address specs. tate the use of Praspel in this context, we provide a grammar- $regexp = ’:::’; // it is a string. based testing [12] mechanism that makes it possible to express return false === parent::predicate($q) and validate structured textual data. // it is an email address. && 0 !== preg_matches($regexp, $q); The contributions of this paper are twofold. First, we g introduce a grammar description language to be use with public function sample() f PHP, named PP (for PHP Parser). This language makes it // string of authorized chars $chars = ’ABCDEFGHIJKL:::’; possible to describe tokens and grammar rules, that are then // array of possible domain extensions exploited by a dedicated PHP interpreter to validate a text $doms = array(’net’,’org’,’edu’,’com’); $q = ’’; w.r.t. the expected syntax given by the grammar. Second, we $nbparts = mt_rand(2, 4); provide grammar-based testing mechanisms that automatically for($i = 0; $i < $nbparts; ++$i) f generate instances of text using various data generators. These if($i > 0) two contributions are gathered into two new realistic domains // add separator dot or arobase that can be used in Praspel annotations in a PHP program: a $q .= ($i == $nbparts - 1) ? ’@’ : ’.’; realistic domain for regular expressions and a realistic domain // generate firstname or name or domain name for grammars, parameterized by a grammar description file. $len = rand(1,10); The paper is organized as follows. Section II explains the for($j=0; $j < $len; ++$j) f $index = rand(0, strlen($chars) - 1); notion of realistic domain and presents its implementation in $q .= $chars[$index]; Praspel for PHP. Then, the PP language and its semantics are g defined in Section III. Section IV proposes data generation g algorithms from grammars. Then, we report in Section V $q .= ’.’ . $doms[rand(0, count($doms) - 1)]; return $q; some experiments aiming at validating our tool and showing g its usefulness and efficiency in practice. Related works are g presented in Section VI. Finally, Section VII concludes and Fig. 1. PHP code of a realistic domain for email addresses presents future works. 2) Samplability: The second feature of a realistic domain II. REALISTIC DOMAINS AND PRASPEL is to propose a value generator, called the sampler, that makes This section presents the notion of realistic domain and its it possible to generate values in the realistic domain. The data application to PHP programs [11]. Realistic domains are de- value generator can be of many kinds: a random generator, a signed for test generation purposes. They specify which values walk in the domain, an incrementation of values, etc. can be assigned to a data in a given program. Realistic domains are well-suited to PHP, since this language is dynamically B. Realistic Domains in PHP typed (i.e. no types are assigned to data) and realistic domains thus introduce a specification of data types that are mandatory In PHP, we have implemented realistic domains as classes for test data generation. We first introduce general features of providing at least two methods, corresponding to the two realistic domains, and then present their application to PHP.
Load more

Recommended publications
  • Génération Automatique De Tests Unitaires Avec Praspel, Un Langage De Spécification Pour PHP the Art of Contract-Based Testing in PHP with Praspel
    CORE Metadata, citation and similar papers at core.ac.uk Provided by HAL - Université de Franche-Comté G´en´erationautomatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP Ivan Enderlin To cite this version: Ivan Enderlin. G´en´eration automatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP. Informatique et langage [cs.CL]. Universit´ede Franche-Comt´e,2014. Fran¸cais. <NNT : 2014BESA2067>. <tel-01093355v2> HAL Id: tel-01093355 https://hal.inria.fr/tel-01093355v2 Submitted on 19 Oct 2016 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. Thèse de Doctorat école doctorale sciences pour l’ingénieur et microtechniques UNIVERSITÉ DE FRANCHE-COMTÉ No X X X THÈSE présentée par Ivan Enderlin pour obtenir le Grade de Docteur de l’Université de Franche-Comté K 8 k Génération automatique de tests unitaires avec Praspel, un langage de spécification pour PHP The Art of Contract-based Testing in PHP with Praspel Spécialité Informatique Instituts Femto-ST (département DISC) et INRIA (laboratoire LORIA) Soutenue publiquement
    [Show full text]
  • Assertions, Pre/Post- Conditions and Invariants
    9/14/12 Assertions, pre/post- conditions and invariants Section 2.1 in Walls and Mirrors Section 4.5 Rosen Programming as a contract n Specifying what each method does q Specify it in a comment before method's header n Precondition q What is assumed to be true before the method is executed q Caller obligation n Postcondition q Specifies what will happen if the preconditions are met q Method obligation 1 9/14/12 Class Invariants n A class invariant is a condition that all objects of that class must satisfy while it can be observed by clients n What about Points in Cloud? q boundaries? q center? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } // what could you state here? 2 9/14/12 What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //more? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //n is the smallest power of 2 >= limit 3 9/14/12 assert Using assert: assert n == 1; while (n < limit) { n = 2 * n; } assert n >= limit; When to use Assertions n We can use assertions to guarantee the behavior.
    [Show full text]
  • Chapter 23 Three Design Principles
    23 Three Design Principles Chapter 23 ContaxT / Kodax Tri-X Nunnery — Chichen Itza, Mexico Three Design Principles Learning Objectives • List the preferred characteristics of an object-oriented application architecture • State the definition of the Liskov Substitution Principle (LSP) • State the definition of Bertrand Meyer's Design by Contract (DbC) programming • Describe the close relationship between the Liskov Substitution Principle and Design by Contract • State the purpose of class invariants • State the purpose of method preconditions and postconditions • Describe the effects weakening and strengthening preconditions have on subclass behavior • Describe the effects weakening and strengthening postconditions have on subclass behavior • State the purpose and use of the Open-Closed Principle (OCP) • State the purpose and use of the Dependency Inversion Principle (DIP) • State the purpose of Code Contracts and how they are used to enforce preconditions, postconditions, and class invariants C# For Artists © 2015 Rick Miller and Pulp Free Press — All Rights Reserved 757 Introduction Chapter 23: Three Design Principles Introduction Building complex, well-behaved, object-oriented software is a difficult task for several reasons. First, simply programming in C# does not automatically make your application object-oriented. Second, the pro- cess by which you become proficient at object-oriented design and programming is characterized by expe- rience. It takes a lot of time to learn the lessons of bad software architecture design and apply those lessons learned to create good object-oriented architectures. The objective of this chapter is to help you jump-start your object-oriented architectural design efforts. I begin with a discussion of the preferred characteristics of a well-designed object-oriented architecture.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Contracts for Concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S
    Contracts for concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff To cite this version: Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff. Contracts for concurrency. Formal Aspects of Computing, Springer Verlag, 2008, 21 (4), pp.305-318. 10.1007/s00165-007-0063-2. hal-00477897 HAL Id: hal-00477897 https://hal.archives-ouvertes.fr/hal-00477897 Submitted on 30 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. DOI 10.1007/s00165-007-0063-2 BCS © 2007 Formal Aspects Formal Aspects of Computing (2009) 21: 305–318 of Computing Contracts for concurrency Piotr Nienaltowski1, Bertrand Meyer2 and Jonathan S. Ostroff3 1 Praxis High Integrity Systems Limited, 20 Manvers Street, Bath BA1 1PX, UK E-mail: [email protected] 2 ETH Zurich, Zurich, Switzerland 3 York University, Toronto, Canada Abstract. The SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP 97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism.
    [Show full text]
  • Implementing Closures in Dafny Research Project Report
    Implementing Closures in Dafny Research Project Report • Author: Alexandru Dima 1 • Total number of pages: 22 • Date: Tuesday 28th September, 2010 • Location: Z¨urich, Switzerland 1E-mail: [email protected] Contents 1 Introduction 1 2 Background 1 2.1 Closures . .1 2.2 Dafny . .2 3 General approach 3 4 Procedural Closures 5 4.1 Procedural Closure Type . .5 4.2 Procedural Closure Specifications . .6 4.3 A basic procedural closure example . .6 4.3.1 Discussion . .6 4.3.2 Boogie output . .8 4.4 A counter factory example . 13 4.5 Delegation example . 17 5 Pure Closures 18 5.1 Pure Closure Type . 18 5.2 A recursive while . 19 6 Conclusions 21 6.1 Limitations . 21 6.2 Possible extensions . 21 6.3 Acknowledgments . 21 2 BACKGROUND 1 Introduction Closures represent a particularly useful language feature. They provide a means to keep the functionality linked together with state, providing a source of ex- pressiveness, conciseness and, when used correctly, give programmers a sense of freedom that few other language features do. Smalltalk's standard control structures, including branches (if/then/else) and loops (while and for) are very good examples of using closures, as closures de- lay evaluation; the state they capture may be used as a private communication channel between multiple closures closed over the same environment; closures may be used for handling User Interface events; the possibilities are endless. Although they have been used for decades, static verification has not yet tack- led the problems which appear when trying to reason modularly about closures.
    [Show full text]
  • Study on Eiffel
    Study on Eiffel Jie Yao Anurag Katiyar May 11, 2008 Abstract This report gives an introduction to Eiffel, an object oriented language. The objective of the report is to draw the attention of the reader to the salient features of Eiffel. The report explains some of these features in brief along with language syntax. The report includes some code snippets that were written in the process of learning Eiffel. Some of the more detailed tutorials, books and papers on Eiffel can be found at www.eiffel.com 1 Contents 1 Introduction 3 2 Eiffel Constructs and Grammar 3 2.1 ”Hello World” . 3 2.2 Data Types . 3 2.3 Classes . 3 2.4 Libraries . 4 2.5 Features . 4 2.6 Class relations and hierarchy . 4 2.7 Inheritance . 4 2.8 Genericity . 5 2.9 Object Creation . 5 2.10 Exceptions . 6 2.11 Agents and Iteration . 6 2.12 Tuples . 6 2.13 Typing . 6 2.14 Scope . 7 2.15 Memory Management . 7 2.16 External software . 7 3 Fundamental Properties 7 3.1 ”Has” Properties . 8 3.2 ”Has no” Properties . 9 4 Design principles in Eiffel 10 4.1 Design by Contract . 10 4.2 Command Query Separation . 11 4.3 Uniform Access Principle . 11 4.4 Single Choice Principle . 11 5 Compilation Process in Eiffel 11 6 Exception Handling in the compiler 12 7 Garbage Collection for Eiffel 12 7.1 Garbage Collector Structure . 12 7.2 Garbage Collector in Action . 13 8 Eiffel’s approach to typing 13 8.1 Multiple inheritance .
    [Show full text]
  • 3. Design by Contract
    3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class — Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Bertrand Meyer is a French computer scientist who was a Professor at ETH Zürich (successor of Niklaus Wirth) from 2001-2015. He is best known as the inventor of “Design by Contract”, and as the designer of the Eiffel programming language, which provides built-in for DbC. DbC was first described in a technical report by Meyer in 1986: https://en.wikipedia.org/wiki/Design_by_contract Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? 3 DbC makes clear the “contract” between a supplier (an object or “component”) and its client. When something goes wrong, the contract states whose fault it is. This simplifies both design and debugging. Why DbC? > Design by Contract —documents assumptions (what do objects expect?) —simplifies code (no special actions for failure) —aids debugging (identifies who’s to blame) 4 As we shall see, DbC improves your OO design in several ways. First, contracts make explicit the assumptions under which an object (supplier) will work correctly. Second, they simplify your code, since no special action is required when things go wrong — the exception handling framework provides the necessary tools. Third, contracts help in debugging since errors are caught earlier, when contracts are violated, not when your program crashes because of an invalid state, and it is clear where to lay the blame for the violation (i.e., in the object or its client).
    [Show full text]
  • Verification of Object Oriented Programs Using Class Invariants
    Verification of Object Oriented Programs Using Class Invariants Kees Huizing and Ruurd Kuiper and SOOP?? Eindhoven University of Technology, PO Box 513, 5600 MB Eindhoven, The Netherlands, [email protected], [email protected] Abstract A proof system is presented for the verification and derivation of object oriented pro- grams with as main features strong typing, dynamic binding, and inheritance. The proof system is inspired on Meyer’s system of class invariants [12] and remedies its unsound- ness, which is already recognized by Meyer. Dynamic binding is treated in a flexible way: when throughout the class hierarchy overriding methods respect the pre- and post- conditions of the overridden methods, very simple proof rules for method calls suffice; more powerful proof rules are supplied for cases where one cannot or does not want to follow this restriction. The proof system is complete relative to proofs for properties of pointers and the data domain. 1 Introduction Although formal verification is not very common in the discipline of object oriented programming, the importance of formal specification is generally ac- knowledged ([12]). With the increased interest in component based develop- ment, it becomes even more important that components are specified in an un- ambiguous manner, since users or buyers of components often have no other knowledge about a component than its specification and at the same time rely heavily on its correct functioning in their framework. The specification of a class, sometimes called contract, usually contains at least pre- and postcondi- tions for the public mehtods and a class invariant. A class invariant expresses which states of the objects of the class are consis- tent, or “legal”.
    [Show full text]
  • You Say 'JML' ? Wikipedia (En)
    You say 'JML' ? Wikipedia (en) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 06 Jan 2014 09:58:42 UTC Contents Articles Java Modeling Language 1 Design by contract 5 Formal methods 10 References Article Sources and Contributors 15 Image Sources, Licenses and Contributors 16 Article Licenses License 17 Java Modeling Language 1 Java Modeling Language The Java Modeling Language (JML) is a specification language for Java programs, using Hoare style pre- and postconditions and invariants, that follows the design by contract paradigm. Specifications are written as Java annotation comments to the source files, which hence can be compiled with any Java compiler. Various verification tools, such as a runtime assertion checker and the Extended Static Checker (ESC/Java) aid development. Overview JML is a behavioural interface specification language for Java modules. JML provides semantics to formally describe the behavior of a Java module, preventing ambiguity with regard to the module designers' intentions. JML inherits ideas from Eiffel, Larch and the Refinement Calculus, with the goal of providing rigorous formal semantics while still being accessible to any Java programmer. Various tools are available that make use of JML's behavioral specifications. Because specifications can be written as annotations in Java program files, or stored in separate specification files, Java modules with JML specifications can be compiled unchanged with any Java compiler. Syntax JML specifications are added to Java code in the form of annotations in comments. Java comments are interpreted as JML annotations when they begin with an @ sign.
    [Show full text]
  • Precondition Enforcement Analysis for Quality Assurance
    Precondition Enforcement Analysis for Quality Assurance Nadja Beeli Submitted to the degree of Master of Science ETH in Computer Science Supervised by Prof. Dr. Bertrand Meyer and Dr. Karine Arnout April - October 2004 Abstract The crash of Ariane 5 dramatically showed the importance of correctness in software and that the goal to produce reliable software has not yet been achieved. Therefore, this master thesis targets the development of a static analysis, which ensures preconditions and thus enhances a sound reuse of software. As a result, we could determine many preconditions to be fulfilled, especially preconditions of a certain class, which are used most often. This confirms that static analysis is justified in a development process of quality software. Acknowledgements I would like to deeply thank Dr. Karine Arnout for her support and explanations on the subject of the thesis, and her prompt answers. Furthermore I thank Prof. Dr. Bertrand Meyer, who gave me the opportunity to accomplish my master thesis in the field of Design by Contract, and for his introduction on the static analysis of preconditions. A special thank goes to Éric Bezault, who introduced me to GOBO Eiffel, and swiftly answered my questions. 2 Table of Contents Chapter 1 - Concept of Contracts ........................................................................................6 1.1. The Crash of Ariane 5.............................................................................................6 1.2. Design by Contract in Context of Ariane 5..............................................................6
    [Show full text]
  • VERIFICATION of OBJECT-ORIENTED PROGRAMS with INVARIANTS at Least to Hoare’S 1972 Paper on Data-Representation Correctness [19]
    Vol. 3, No. 6 Special issue: ECOOP 2003 workshop on FTfJP Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich¨ , K. Rustan M. Leino, Wolfram Schulte Microsoft Research, Redmond, WA, USA An object invariant defines what it means for an object’s data to be in a consis- tent state. Object invariants are central to the design and correctness of object- oriented programs. This paper defines a programming methodology for using object invariants. The methodology, which enriches a program’s state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesting object-oriented programs to be specified and verified. Lending itself to sound modular verification, the methodology also provides a solution to the problem of determining what state a method is allowed to modify. 1 INTRODUCTION Writing and maintaining software is difficult and error prone, in part because it requires coping with many details. Mechanical programming tools can relieve some of this bur- den. For example, an important and pervasive tool is the type checker, which allows the programmer to describe in broad-brush terms the set of values each program vari- able can take. Using these descriptions, the type checker mechanically checks all reads and writes of program variables to ensure that no variable takes on a forbidden value. The type checker is usually built into the compiler, which also checks other details. For example, the compiler may check that every variable use is preceded by an assignment, that any read-only variable is not changed after its initial assignment, or that variables declared in certain scopes or with certain access modifiers are not referenced from inap- propriate places.
    [Show full text]