DOCSLIB.ORG

Applying “Design by Contract”

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Applying “Design by Contract” : Applying “Design by Contract” Bertrand Meyer Interactive Software Engineering s object-oriented techniques steadily gain ground in the world of software development. users and prospective users of these techniques are clam- oring more and more loudly for a “methodology” of object-oriented software construction - or at least for some methodological guidelines. This article presents such guidelines, whose main goal is to help improve the reliability of software systems. Reliability is here defined as the combination of correctness and robustness or. more prosaically, as the absence of bugs. Everyone developing software systems. or just using them, knows how pressing this question of reliability is in the current state of software engineering. Yet the rapidly growing literature on object-oriented analysis, design, and programming includes remarkably few contributions on how to make object-oriented software more reliable. This is surprising and regrettable, since at least three reasons justify devoting particular attention to reliability in the context of object-oriented devel- opment: l The cornerstone of object-oriented technology is reuse. For reusable compo- nents, which may be used in thousands of different applications, the potential consequences of incorrect behavior are even more serious than for application- specific developments. l Proponents of object-oriented methods make strong claims about their bene- ficial effect on software quality. Reliabi!ity is certainly a central component of any reasonable definition of quality as applied to software. *The object-oriented approach, based on the theory of abstract data types, Reliability is even more provides a particularly appropriate framework for discussing and enforcing important in object- reliability. oriented programming The pragmatic techniques presented in this article, while certainly not providing infallible ways to guarantee reliability, may help considerably toward this goal. than elsewhere. This They rely on the theory of design by contract. which underlies the design of the article shows how to Eiffel analysis, design, and programming language’ and of the supporting libraries, from which a number of examples will be drawn. reduce bugs by building The contributions of the work reported below include software components l a coherent set of nwthodological principles helping to produce correct and on the basis of carefully robust software; l a systematic approach to the delicate problem of how to deal with abnormal designed contracts. cases. leading to a simple and powerful exception-handling mechanism; and 40 *a better understanding of inherit- plexity and unwieldiness that often char- letter or package delivered to another ance and of the associated techniques acterizes software. Paris address, you may decide to deliver (redeclaration, polymorphism, and Obtaining and guaranteeing reliabil- it yourself, or you may contract out the dynamic binding) through the no- ity requires a more systematic approach. task to a courier service. tion of subcontract, allowing a sys- In particular, software elements should Two major properties characterize tematic approach to using these pow- be considered as implementations meant human contracts involving two parties: erful but sometimes dangerous to satisfy well-understood specifications, mechanisms. not as arbitrary executable texts. This is *Each party expects some benefits where the contract theory comes in. from the contract and is prepared to Most of the concepts presented here incur some obligations to obtain them. have appeared elsewhere. They were *These benefits and obligations are previewed in the book Object-Oriented The notion of contract documented in a contract document. Software Construction’; and a more com- plete exposition was presented in a re- Assume you are writing some pro- Table 1 shows an imaginary roster of cent book chapter,’ from which this ar- gram unit implementing a task to be obligations and benefits for the courier ticle has been adapted. More profoundly, performed at runtime. Unless the task service of the example. this work finds its root in earlier work is trivial, it involves a number of sub- A contract document protects both on systematic program development”.i tasks. For example, it might appear as sides: and abstract data types. h-XThis article focuses on the central ideas, introduc- my-task is l It protects the client by specifying ing them concisely for direct applica- d0 how much should be done: The client is tion by developers. subtask, ; entitled to receive a certain result. subtask? ; l It protects the contractor by speci- fying how little is acceptable: The con- Defensive programming subtask,, ; tractor must not be liable for failing to revisited end carry out tasks outside of the specified scope. a form that suffices for this discussion. Software engineering and program- although in many cases the control struc- As evidenced by this example, what is ming methodology textbooks that dis- ture linking the various subtasks is less an obligation for one party is usually a cuss reliability often emphasize the tech- simple than the mere sequencing shown benefit for the other. nique known as defensive programming, here. This example also suggests a some- which directs developers to protect ev- For each of these subtasks, you may what more subtle observation, which is ery software module against the slings either write the corresponding solution important in the following discussion and arrows of outrageous fortune. In in line as part of the body of my-task, or (and in studying the application of these particular, this encourages programmers rely on a call to another unit. The deci- ideas to concurrent computation). If the to include as many checks as possible, sion is a typical design trade-off: Too contract is exhaustive, every “obliga- even if they are redundant with checks much calling causes fragmentation of tion” entry also in a certain sense de- made by callers. Include them anyway, the software text: too little results in scribes a “benefit” by stating that the the advice goes; if they do not help. at overcomplex individual units. constraints given are the only relevant least they will not harm. Assume you decide to use a routine ones. For example, the obligation entry This approach suggests that routines call for one of the subtasks. This is sim- for the client indicates that a client who should be as general as possible. A par- ilar to the situation encountered in ev- satisfies all the constraints listed is enti- tial routine (one that works only if the eryday life when you decide to contract tled to the benefits shown in the next caller ensures certain restrictive condi- out for a certain (human) task rather entry. This is the No Hidden Clauses tions at the time of the call) is consid- than doing it yourself. For example. if rule: With a fully spelled out contract ered dangerous because it might pro- you are in Paris and want an urgent between honest parties, no requirement duce unwanted consequences if a caller does not abide by the rules. This technique, however, often de- Table 1. Example contract. feats its own purposes. Adding possibly redundant code “just in case” only con- Party Obligations Benefits tributes to the software’s complexity - the single worst obstacle to software Client Provide letter or package of no Get package delivered to quality in general. and to reliability in more than 5 kgs. each dimension recipient in four hours or particular. The result of such blind check- no more than 2 meters. less. ing is simply to introduce more soft- Pay 100 francs. ware. hence more sources of things that could go wrong at execution time, hence Supplier Deliver package to recipient No need to deal with the need for more checks, and so on ad in four hours or less. deliveries too big, too infinitum. Such blind and often redun- heavy, or unpaid. dant checking causes much of the com- October 1992 41 other than the contract’s offi- This is the contract en- cial obligations may be im- routine-name (argument declarations) is forced by put-child on any posed on the client as acondi- -- Header comment potential caller. It contains tion for obtaining the require the most important informa- contract’s official benefits. Precondition tion that can be given about do The No Hidden Clauses Routine body, ie. instructions the routine: what each party principle does not prevent us eusare in the contract must guaran- from including references. Postcondition tee for a correct call, and what implicit or explicit, to rules end each party is entitled to in not physically part of the con- return. Because this informa- tract. For example, general Figure 1. A routine equipped with assertions. tion is so crucial to the con- rules such as the relevant laws struction of reliable systems and common business prac- using such routines, it should tices are implicitly considered put-child (new: NODE) is be a formal part of the rou- to be part of every contract of -- Add new to the children of current node tine’s text (see Figure 2). a certain kind. even if not ex- require A few more details about plicitly repeated in the text of new /= Void the rules of object-oriented each contract. They apply to do programming as embodied in both client and supplier and . Insertion algorithm .. Eiffel should help make this will lead below to the notion ensure example completely clear: of class invariant. new.parent = Current; child-count = old child-count + 1 l A reference such as new end -- put-child is either void (not attached Assertions: to any object) or attached to Contracting for Figure 2. Assertions for child insertion routine. an object: In the first case, it equals the value Void. Here software - the precondition expresses assertion is a list of Boolean expres- that the reference new must not be void, It is not difficult to see how the pre- sions, separated by semicolons: here a as stated informally by the correspond- ceding ideas apply to software construc- semicolon is equivalent to a Boolean ing entry in Table 2.
Load more

Recommended publications
  • Contracts for System Design
    Contracts for System Design Albert Benveniste, Benoit Caillaud, Dejan Nickovic, Roberto Passerone, Jean-Baptiste Raclet, Philipp Reinkemeier, Alberto Sangiovanni-Vincentelli, Werner Damm, Thomas Henzinger, Kim Guldstrand Larsen To cite this version: Albert Benveniste, Benoit Caillaud, Dejan Nickovic, Roberto Passerone, Jean-Baptiste Raclet, et al.. Contracts for System Design. [Research Report] RR-8147, INRIA. 2012, pp.65. hal-00757488 HAL Id: hal-00757488 https://hal.inria.fr/hal-00757488 Submitted on 28 Nov 2012 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. Contracts for Systems Design Albert Benveniste, Benoît Caillaud, Dejan Nickovic Roberto Passerone, Jean-Baptiste Raclet, Philipp Reinkemeier Alberto Sangiovanni-Vincentelli, Werner Damm Tom Henzinger, Kim Larsen RESEARCH REPORT N° 8147 November 2012 Project-Teams S4 ISSN 0249-6399 ISRN INRIA/RR--8147--FR+ENG Contracts for Systems Design Albert Benveniste∗, Benoît Caillaudy, Dejan Nickovicz Roberto Passeronex, Jean-Baptiste Raclet{, Philipp Reinkemeierk Alberto Sangiovanni-Vincentelli∗∗, Werner Dammyy Tom Henzingerzz, Kim Larsen Project-Teams S4 Research Report n° 8147 — November 2012 — 64 pages This work was funded in part by the European STREP-COMBEST project number 215543, the European projects CESAR of the ARTEMIS Joint Undertaking and the European IP DANSE, the Artist Design Network of Excellence number 214373, the MARCO FCRP TerraSwarm grant, the iCyPhy program sponsored by IBM and United Technology Corporation, the VKR Center of Excellence MT-LAB, and the German Innovation Alliance on Embedded Systems SPES2020.
    [Show 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
    [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]
  • Cyber-Physical System Design Contracts
    Cyber-Physical System Design Contracts Patricia Derler Edward A. Lee Martin Törngren University of California, University of California, KTH Royal Institute of Berkeley Berkeley Technology [email protected] [email protected] [email protected] Stavros Tripakis University of California, Berkeley [email protected] ABSTRACT tinct disciplines such as control engineering, software engineer- This paper introduces design contracts between control and em- ing, mechanical engineers, network engineering, etc. The com- bedded software engineers for building Cyber-Physical Systems plexity and heterogeneity of all the different design aspects require (CPS). CPS design involves a variety of disciplines mastered by methodologies for bridging the gaps between the disciplines in- teams of engineers with diverse backgrounds. Many system prop- volved. This is known to be challenging since the disciplines have erties influence the design in more than one discipline. The lack of different views, encompassing terminology, theories, techniques clearly defined interfaces between disciplines burdens the interac- and design approaches. tion and collaboration. We show how design contracts can facilitate In this paper, we focus on interactions between control and em- interaction between 2 groups: control and software engineers. A bedded software engineers. A multitude of modeling, analysis and design contract is an agreement on certain properties of the system. synthesis techniques that deal with codesign of control functions Every party specifies requirements and assumptions on the system and embedded software have been developed since the 1970s. We and the environment. This contract is the central point of inter- use the term codesign for approaches that provide an awareness of domain communication and negotiation.
    [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]
  • Sound Invariant Checking Using Type Modifiers and Object Capabilities
    Sound Invariant Checking Using Type Modifiers and Object Capabilities. Isaac Oscar Gariano Victoria University of Wellington [email protected] Marco Servetto Victoria University of Wellington [email protected] Alex Potanin Victoria University of Wellington [email protected] Abstract In this paper we use pre existing language support for type modifiers and object capabilities to enable a system for sound runtime verification of invariants. Our system guarantees that class invariants hold for all objects involved in execution. Invariants are specified simply as methods whose execution is statically guaranteed to be deterministic and not access any externally mutable state. We automatically call such invariant methods only when objects are created or the state they refer to may have been mutated. Our design restricts the range of expressible invariants but improves upon the usability and performance of our system compared to prior work. In addition, we soundly support mutation, dynamic dispatch, exceptions, and non determinism, while requiring only a modest amount of annotation. We present a case study showing that our system requires a lower annotation burden compared to Spec#, and performs orders of magnitude less runtime invariant checks compared to the widely used ‘visible state semantics’ protocols of D, Eiffel. We also formalise our approach and prove that such pre existing type modifier and object capability support is sufficient to ensure its soundness. 2012 ACM Subject Classification Theory of computation → Invariants, Theory of computation → Program verification, Software and its engineering → Object oriented languages Keywords and phrases type modifiers, object capabilities, runtime verification, class invariants Digital Object Identifier 10.4230/LIPIcs.CVIT.2016.23 1 Introduction Object oriented programming languages provide great flexibility through subtyping and arXiv:1902.10231v1 [cs.PL] 26 Feb 2019 dynamic dispatch: they allow code to be adapted and specialised to behave differently in different contexts.
    [Show full text]
  • Defensive Programming Is Sometimes Referred to A
    Defensive Programming Is Sometimes Referred To A Is Muhammad cubical or giddier after all-star Clarke initiating so selflessly? Urethritic Weider dispersing else while Stefan always will his cassoulet solaces full, he decarbonise so aerobiologically. Reversed and lady-killer Neville never huts his chakra! The defensive programming is sometimes referred to defensive programming a developer to the max, the same approach can create a new and comments without affecting the demilitarization of As defensive programming are sometimes referred to discover which suggests that programs are crucial to break them? Like other codes, is then betatested in a simulated production environment. Throw argument is sometimes referred to refer to. Unexpected errors require interactive debugging to figure out what went wrong. You program is defensive programming in programs based on every type to. How rare you mind what note request is singing? Defensive Programming Assigning NULL to Dangling Pointers. Earth destroyed an Indian satellite in orbit three hundred kilometres away. Summary of defense is sometimes referred to refer to fail from inevitable bugs is! Making the software itself in a predictable manner despite unexpected inputs or user actions. Sign Up For Free! Ruby today, and States not easily agreeing on busy, and confirmed. Pseudocode is sometimes referred to refer to keep in programs stable after a program directly with errors that is often ripple back to contain it! Chapter 4 Defensive Programming NanoPDF. It is likely to internet, namely the rights, sometimes referred to. And now, it is important should be problem of their limitations and liabilities. When getting rid of other with little by the two problems in defensive programming is sometimes to a given me exactly mean that makes a debugging code avoid syntactic one.
    [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]
  • Buffer Overflow Attack Samanvay Gupta 4Th Year 1St Semester (Computer Science Department) Visvesvaraya College of Engineering & Technology
    IOSR Journal of Computer Engineering (IOSRJCE) ISSN : 2278-0661 Volume 1, Issue 1 (May-June 2012), PP 10-23 www.iosrjournals.org Buffer Overflow Attack Samanvay Gupta 4th year 1st semester (Computer Science Department) Visvesvaraya College of Engineering & Technology Abstract -- Exploits, vulnerabilities, and buffer-overflow techniques have been used by malicious hackers and virus writers for a long time. In order to attack and get the remote root privilege, using buffer overflow and suidprogram has become the commonly used method for hackers. This paper include vast idea and information regarding the buffer overflow as history of Vulnerabilities, buffers, stack, registers, Buffer Overflow Vulnerabilities and Attacks, current buffer over flow, Shell code, Buffer Overflow Issues, the Source of the Problem, prevention/detection of Buffer Overflow attacks and Finally how to react towards Buffer Overflows. The objective of this study is to take one inside the buffer overflow attack and bridge the gap between the “descriptive account” and the “technically intensive account” Introduction Buffer overflows have been documented and understood as early as 1972[23]. In computer security and programming, a buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety. Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited.
    [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 Contract Pattern Permission Granted to Copy for Plop ’97 Conference
    Copyright 1997, Michel de Champlain The Contract Pattern Permission granted to copy for PLoP ’97 Conference. All other rights reserved. Michel de Champlain Department of Computer Science University of Canterbury, Christchurch, New Zealand [email protected] http://www.cosc.canterbury.ac.nz/~michel 12 August 1997 Abstract This paper describes the Contract pattern, an idiom that lets you apply assertions to guarantee pre-conditions and post-conditions of methods and invariants on the state of objects. This pattern can be used to develop reliable classes by making the Design by Contract methodology—introduced by Meyer in the specific context of the Eiffel language—available in Java and possibly other object-oriented languages. Intent Provide an implementation of the Design by contract methodology [Meyer88] for developing reliable classes and create robust objects in Java. This programming pattern lets you apply assertions to guarantee the pre-conditions and post-conditions of methods and invariants on the state of objects. Also Known As Design by contract Motivation Sometimes it’s necessary to restrict a class interface because you don’t want to provide all the possible input combinations for all collaborators. One way to achieve this goal is to make minimal and consistent methods that impose pre-conditions on input parameters. Moreover, you might want to ensure the class behavior by imposing post-conditions before methods return. You might also need to make sure that the class is always in a stable state. Such an approach can result in reliable classes to create robust objects. Consider for example a bounded counter that has both a lower and upper bound.
    [Show full text]