DOCSLIB.ORG

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

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
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 le 16 juillet 2014 devant le Jury composé de : Rapporteurs Lydie du Bousquet Professeur à l’Université Joseph Fourier Arnaud Gotlieb Chargé de recherche habilité à l’IRISA Examinateur Michel Rueher Professeur à l’Université de Nice Sophia Antipolis Directeurs Fabrice Bouquet Professeur à l’Université de Franche-Comté Frédéric Dadeau Maître de conférences à l’Université de Franche-Comté Alain Giorgetti Maître de conférences à l’Université de Franche-Comté Remerciements Je tiens à profiter de l’occasion qui m’est offerte pour remercier toutes les personnes qui ont été soutenantes. Je tiens à remercier avant tout mon Dieu, the Everlasting, pour cette épreuve, ses promesses et son soutien en tout temps. Merci. Je souhaite remercier ma petite femme, Hend, lady caramel, pour son éternel amour, sa patience, son écoute et son infini tendresse. Je t’aime. Q Ì .½J.k@ .ú ×XB@ AîEAJk C«ðAîEA@ ð Aë . C« YJë èñÊm '@ ð èQK QªË@ ú æ k. ðP Qº@ à@ YK P@ Je souhaite particulièrement remercier mes parents et beaux-parents, Nadine et Q Q Christophe, ÖÞ ð èA Jk, mes sœurs et belles-sœurs, Naomi et Joanna, ø Q å ð Pð ¯, ainsi que toute ma famille, pour leur présence et leur soutien. Merci à tous les amis de France, de Suisse, de Tunisie, du Maroc, d’Italie, de Grèce, du Brésil, du Kenya, de Belgique, du Mexique, de Macédoine et de partout, qui m’ont aidé dans ma thèse et qui m’aident dans Hoa. Par ordre alphabétique, un immense et sincère merci à Abdallah Ben O., Alexandre V., Alexis von G., Bap- Елизабета С tiste et Anne-Laure F., F.- ., Emmanuel T., Frédéric H., Guislain D., Gérard E., Isabelle et Yves D., ÈCg. YÒm×, Jean-Marie G., Julien B., Julien C., Julien L., Kalou C. C., Laura et Raphaël E., Lucie et á Ó@ M., María Aydeé S. S. et Cédric J., Marta P., Mikaël R., Naomy W., Nawo M., Ophélie et Matthieu C., Raphaëlle M., Σοφία και Κώστας Τ., Stéphane P., Sylvie et Kiko F., Sébastien H., Willy M., Wilma et Fabio S. (et toute la troupe !), Yohann D., toute la communauté de Hoa, d’atoum et de PHP, et tout ceux que j’aurais oublié. Et bien sûr, merci à mes encadrants : Fabrice B., Frédéric D. et Alain G. pour leur savoir, leur patience et être restés à mes côtés durant cette aventure ! y 10 5 x = 16 sin(t)3 −15 −10 −50 5 1015 x y = 13 cos(t)− 5 cos(2t)− 2 cos(3t)− cos(4t) −5 −10 −15 Table des matières 1 Introduction 1 1.1 Behavioral Interface Specification Language ................. 3 1.2 Contexte et problématique . 4 1.2.1 PHP: Hypertext Preprocessor .................... 4 1.2.2 Test unitaire . 5 1.2.3 Langage de spécification . 6 1.3 Contributions . 7 1.3.1 Praspel et les domaines réalistes . 7 1.3.2 Générateurs de données . 7 1.3.3 Critères de couverture des contrats . 8 1.4 Plan du mémoire . 8 2 État de l’art 9 2.1 Langages de contrat . 9 2.2 Contract-based Testing ............................ 13 2.3 Génération de données . 18 2.3.1 Technique de génération . 19 2.3.2 Données générées . 22 2.4 Synthèse . 24 3 Langage de spécification 27 3.1 Domaines réalistes . 27 3.1.1 Implémentation . 28 3.1.2 Hiérarchie et univers . 29 3.1.3 Paramètres . 29 3.1.4 Classification . 31 3.2 Praspel . 32 3.2.1 Clauses . 34 3.2.2 Expressions . 38 3.2.3 Description de tableaux . 41 3.3 Synthèse . 43 i ii Table des matières 4 Génération de données de test 45 4.1 Génération standard . 46 4.2 Génération à partir de propriétés sur les tableaux . 48 4.2.1 Étude des propriétés les plus utilisées . 49 4.2.2 Syntaxe des propriétés . 49 4.2.3 Sémantique ensembliste des propriétés . 52 4.2.4 Solveur de contraintes . 54 4.3 Génération à partir de grammaire pour les chaînes de caractères . 61 4.3.1 Langage de description de grammaire . 61 4.3.2 Compilateur de compilateurs LL(⋆) . 64 4.3.3 Algorithmes de génération à partir de grammaires . 69 4.4 Génération d’objets . 79 4.5 Synthèse . 81 5 Critères de couverture de contrat 83 5.1 Couverture de contrat . 84 5.1.1 Graphe d’une expression . 85 5.1.2 Graphe d’un contrat atomique . 87 5.1.3 Contrat atomique avec plusieurs clauses @throwable . 87 5.1.4 Graphe d’un contrat avec une clause @behavior . 89 5.1.5 Contrat avec plusieurs clauses @behavior . 90 5.1.6 Cas de la clause @default ..................... 90 5.1.7 Cas de la clause @invariant ................... 90 5.2 Définitions . 92 5.3 Critères de couverture . 95 5.3.1 Critère de Couverture de Clause . 97 5.3.2 Critère de Couverture de Domaine . 97 5.3.3 Critère de Couverture de Prédicat . 99 5.3.4 Combinaisons . 100 5.4 Synthèse . 101 6 Implémentations et outillage 103 6.1 Implémentation dans Hoa . 104 6.1.1 Hoa\Realdom ............................105 6.1.2 Hoa\Praspel ............................106 6.1.3 Hoa\Compiler et Hoa\Regex . 108 6.2 Praspel . 109 6.2.1 Analyses . 111 6.2.2 Modèle objet . 112 6.2.3 Exportation et importation . 114 Table des matières iii 6.2.4 Désassemblage . 114 6.2.5 Runtime Assertion Checker . 115 6.3 Intégration dans atoum . 117 6.3.1 Présentation d’atoum . 118 6.3.2 Extension : Praspel dans atoum . 120 6.4 Synthèse . 124 7 Expérimentations 125 7.1 Test à partir de grammaires . 126 7.1.1 Auto-validation du compilateur et des algorithmes . 126 7.1.2 Validation d’applications Web . 129 7.2 Solveur sur les tableaux . 130 7.3 Étude de cas : UniTestor . 132 7.3.1 Présentation générale . 132 7.3.2 Modus operandi et résultats . 134 7.4 Ingénieurs bénévoles . 134 7.4.1 Présentation générale . 135 7.4.2 Modi operandi ............................136 7.4.3 Couverture de code des suites de tests . 136 7.4.4 Temps de rédaction des suites de tests . 137 7.4.5 Génération de données de test . 138 7.4.6 Tests paramétrés . 140 7.4.7 Erreurs détectées . 141 7.4.8 Expertise humaine : discussion . 143 7.5 Performance et régression de PHP . 145 7.6 Synthèse . 146 8 Conclusions et perspectives 147 8.1 Recapitulare ..................................147 8.2 Summa summarum ..............................150 8.3 Perspectives . 150 8.3.1 Inclure de nouvelles méthodes de test . 150 8.3.2 Améliorer le langage . 152 8.3.3 Vers des outils industriels ? . 153 Annexes 155 1 Grammaire du langage Praspel en PP . 156 2 Grammaire du langage PP en langage PP . 162 3 Grammaire des PCRE en langage PP . 164 Bibliographie 167 Table des définitions 3.1 Caractéristiques d’un domaine réaliste . 28 4.1 Constraint Satisfaction Problem ....................... 52 4.2 Grammaire . 61 5.1 Graphe d’expression . 84 5.2 Graphe de contrat . 84 5.3 Graphe des domaines . 85 5.4 Graphe des prédicats . 86 5.5 Chemins dans un graphe de contrat . 92 5.6 Routes et sentiers dans un graphe de contrat . 93 5.7 Test unitaire, cas de test et suite de tests . 93 iv Table des figures 3.1 Début d’implémentation du domaine réaliste Boundinteger. 30 3.2 Univers des domaines réalistes. 30 3.3 Grammaire de Praspel : haut niveau. 33 3.4 Grammaire de Praspel : clauses. 33 3.5 Un contrat Praspel typique avec toutes les clauses. 35 3.6 Classe Filesystem.............................. 37 3.7 Grammaire de Praspel : expressions. 38 3.8 Grammaire de Praspel : construction des expressions. 39 4.1 Processus de génération des données pseudo-aléatoire. 47 4.2 Étude des fonctions sur les tableaux. 50 4.3.
Load more

Recommended publications
  • The Java Modeling Language
    The Java Modeling Language Software Fiável Mestrado em Engenharia Informática Mestrado em Informática Faculdade de Ciências da Universidade de Lisboa 2015/2016 Vasco T. Vasconcelos, Antónia Lopes Software Fiável The Java Modeling Language Contracts I The key ingredient of Design by contract, software design methodology promoted by Bertrand Meyer and the Eiffel programming language in 1986. I Inspired by assertions of Hoare logic, contracts place special obligations on both clients and suppliers of a procedure or method. I What does a method require from it’s caller? I What does the method ensure? Software Fiável The Java Modeling Language DBC DBC key idea is to associate a specification with every software element. These specifications (or contracts) govern the interaction of the element with the rest of the world. I Forces the programmer to write exactly what the method does and needs I No need to program defensively (defensive checks can be exensive and increases the complexity of the code of the method and worsen its maintainability) I Assigns blame: specifies who is to blame for not keeping the contract I Provides a standard way to document classes: client programmers are provided with a proper description of the interface properties of a class that is stripped of all implementation information but retains the essential usage information: the contract. Software Fiável The Java Modeling Language Language support for Contracts Language support for contracts exists in different forms: I Eiffel is an object-oriented language that includes contracts I JML adds contracts to the Java language. JML specifications are conventional Java boolean expressions, with a few extensions I Spec# adds contracts to C# I Code Contracts is an API (part of .NET) to author contracts In this course we focus on JML.
    [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]
  • 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].
    [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]
  • The Java Modeling Language
    The Java Modeling language JML Erik Poll Digital Security Radboud University Nijmegen JML • formal specification language for sequential Java by Gary Leavens et. al. – to specify behaviour of Java classes & interfaces – to record detailed design decisions by adding annotations to Java source code in Design-By- Contract style, using eg. pre/postconditions and invariants • Design goal: meant to be usable by any Java programmer Lots of info on http://www.jmlspecs.org Erik Poll, JML introduction - CHARTER meeting - 2 to make JML easy to use • JML annotations added as special Java comments, between /*@ .. @*/ or after //@ • JML specs can be in .java files, or in separate .jml files • Properties specified using Java syntax, extended with some operators \old( ), \result, \forall, \exists, ==> , .. and some keywords requires, ensures, invariant, .... Erik Poll, JML introduction - CHARTER meeting - 3 JML example public class ePurse{ private int balance; //@ invariant 0 <= balance && balance < 500; //@ requires amount >= 0; //@ ensures balance <= \old(balance); public debit(int amount) { if (amount > balance) { throw (new BankException("No way"));} balance = balance – amount; } Erik Poll, JML introduction - CHARTER meeting - 4 What can you do with this? • documentation/specification – record detailed design decisions & document assumptions (and hence obligations!) – precise, unambiguous documentation • parsed & type checked • use tools for – runtime assertion checking • eg when testing code – compile time (static) analyses • up to full formal program
    [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]