DOCSLIB.ORG

Examples of Design by Contract in Java Using Contract, the Design by Contracttm Tool for Javatm

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Examples of Design by Contract in Java Using Contract, the Design by Contracttm Tool for Javatm Object World Berlin ‘99 Design & Components Berlin, May 17th-20th 1999 Examples of Design by Contract in Java using Contract, the Design by Contracttm Tool for Javatm Reto Kramer, [email protected] Java is a registered trademark of Sun Microsystems Inc. Design by Contract is a registered trademark of ISE Inc. Design by Contract - What is it ? n Classes of a system communicate with one another on the basis of precisely defined benefits and obligations. [Bertrand Meyer, CACM, Vol. 36, No 9, 1992] Cambridge Technology Partners © Reto Kramer, [email protected] Example - Class Person n /** n New comment-tags: * @invariant age_ > 0 @pre, @post, */ class Person { @invariant protected age_; n All instances of person /** must have a positive * @post return > 0 age. */ n Clients are promised int getAge() {..} that the age is /** positive provided that: * @pre age > 0 n */ Clients are obligated void setAge( int age ){..} to pass positive ages only. Service will be ...} denied otherwise. Cambridge Technology Partners © Reto Kramer, [email protected] Meaning of pre, post and invariant n If preconditions are n If any postcondition is not obeyed by the violated, it uncovers a client of the class’ problem on the service method, the service provider side. provider will deny its n If any class invariant service ! is violated it uncovers a problem on the service provider side. n The problem can be – implementation error – not specific enough preconditions Cambridge Technology Partners © Reto Kramer, [email protected] Benefits - Obligations Benefit Obligation - no need to check output values satisfy pre- - result guaranteed to conditions Client comply to postcondition 4 1 2 3 - no need to check input values satisfy post- - input guaranteed to conditions comply to Provider precondition Cambridge Technology Partners © Reto Kramer, [email protected] So, is it like “assert.h” ? n Assert statements are a great tool - design by contract even goes one step beyond them: – assert does not provide a contract – clients can not see asserts as part of the interface – does not have a semantic associated with it – not explicit whether they represent pre-, post- conditions or invariants – no OO support (e.g. inheritance), see later – does not lead to “automatic” documentation Cambridge Technology Partners © Reto Kramer, [email protected] Example - A Simple Interface n 1: interface Person { 1: class Employee implements Person { 2: 2: 3: /**age always positive 3: protected int age_; 4: * @post return > 0 4: 5: */ 5: public int getAge() { 6: int getAge(); 6: return age_; 7: 7: }; 8: /** age always positive 8: 9: * @pre age > 0 9: public void setAge( int age ) { 10: */ 10: age_ = age; 11: void setAge( int age ); 11: }; 12: } 12: } Cambridge Technology Partners © Reto Kramer, [email protected] Benefits - General n failures occur close to the faults (I.e. during integration tests and field use!) n interface documentation always up-to-date, can be trusted! n documentation can be generated automatically (iDoclet) n contract specification serves as a basis for black box testing of classes (test-driver spec) Cambridge Technology Partners © Reto Kramer, [email protected] Benefits - Abstraction and Precision Interface A Invariant … Precise Type (class) model with … precise meaning ... Precondition, Postcondition (design by contract) Type (class) model expections/ effects (pre-, post) inter- Use cases action diagrams Textual requirements business rules description (invariants) Ambiguous Abstract Terms Specific Terms Cambridge Technology Partners © Reto Kramer, [email protected] Benefits - Project Phases API Scope Analysis Design Subsystem API Subsystem Stub impl. use cases specification requirements functionality business case domain model subsystems Stub APIs APIs API Implementation Integration Unit Test against Stubs & Test Stub APIs APIs Acceptance Maintenance Rollout Test Extension Cambridge Technology Partners © Reto Kramer, [email protected] APIs Benefits - Project Roles n Class user n Project manager – postconditions – easier to preserve design guaranteed over a long time – can trust documentation – reduced maintenance n Class provider effort in the long run (failure close to fault) – preconditions guaranteed – enables unambiguous – automatic documentation interface specification n Test manager – lower documentation cost – more accurate test-effort – fearless reuse (enables estimation specification of reusable – black box spec for free classes) Cambridge Technology Partners © Reto Kramer, [email protected] References n iContract: http://www.reliable-systems.com n Books: – “Object Oriented Software Construction”, 2nd edition, Bertrand Meyer, Prentice Hall, 1997 – “Objects, Components and Frameworks with UML”, D.F. D’Souza, A. Cameron Wills, Addison Wesley, 1999 n Eiffel [Interactive Software Engineering, ISE] http://www.eiffel.com n UML 1.1 / Object Constraint Language (OCL) http://www.rational.com Cambridge Technology Partners © Reto Kramer, [email protected] iContract - the Tool n source code pre-processor n no run-time library required n compatible with OCL – old value, x@pre – return value – quantifiers: forall, exists n supports Java type extension mechanisms (contract propagation) Cambridge Technology Partners © Reto Kramer, [email protected] Tool Components Class Instrumentation source-code with @pre, @post and @invariant annotations in comment Instrumentation paragraphs Repository SOURCE-CODE 2 Used for type .class extension class mechanisms __REP_C iContract.Tool 1 javac .java class C 4 3 not .java _I.java instrumented class class C __REP_C javac instrumented 5 - instrumented source-code which checks pre-, postconditions and .class invariants. class C java Cambridge Technology Partners © Reto Kramer, [email protected] Performance Tuning n Check instrumentation n Files can be is done per .java file instrumented with any (public class) combination of checks n Performance critical for: classes can be excluded – pre- from the checks – post-conditions and – invariants n E.g. if implementation is tested thoroughly, only check preconditions Cambridge Technology Partners © Reto Kramer, [email protected] Java Language Support 2 Interface I packages implements A Q Interface J 1 extends package Interface K B R 3 implements Interface M 4 extends Interface L C X Interface N Innerclass Cambridge Technology Partners © Reto Kramer, [email protected] Java Language Support (con’t) n All but private methods n Default constructors are are instrumented with added to classes invariant checks. automatically, if needed n The finalize() method is n In constructors the not instrumented with delegation to this(…) and invariant checks. super(…) is put in front of n Invariant checks are the precondition check “synchronized” (javac demands this). n Recursive invariant checks are avoided automatically Cambridge Technology Partners © Reto Kramer, [email protected] Specification Language n Propositional logic with n Scope: quantifiers – as if the invariant were a n Any expression that method of the class, interface may appear in an if(...) – as if the pre- and condition may appear in postcondition were are a pre-, post- and statement of the method invariant expression Cambridge Technology Partners © Reto Kramer, [email protected] Specification Language (con’t) n forall Type t in <enumeration> | <expr> – <collection>->forAll(t | <expr>) n exists Type t in <enumeration> | <expr> – <collection>->exists(t | <expr>) n <a> implies <b> (same as OCL) – same as OCL n Differences between iContract and OCL – syntactic & iContract needs to know Type! Cambridge Technology Partners © Reto Kramer, [email protected] Specification Language (con’t) n In postconditions references to the following pseudo-variables are allowed: n return denotes the return value of a method – this is called “result” in OCL n <expression>@pre denotes the value of the expression (e.g. variable) when the method was entered - notation from UML / OCL “old value reference” – same as OCL Cambridge Technology Partners © Reto Kramer, [email protected] Example n Office Management System – Manage the rooms available to a company. Provide new hires with office and support employees that move from one office to another. n Focus on – Initial type model of domain (UML) – Add business constraints and rules (OCL) – Add precise meaning of operations (OCL) – Generate Java (iContract) Cambridge Technology Partners © Reto Kramer, [email protected] Office Management Example (hire) 1 2 Company void Company:hire(Employee e) - rooms->isEmpty() implies employees.isEmpty() pre: (e != null) && (!employees->includes(e)) - employees -> forAll (e | rooms -> includes(e.office)) post: - employees->forAll( e1 | - employees->includes(e) employees->forAll( e2 | (e1 != e2) implies (e1.room != e2.room)) - getAvailableRoom()@pre != getAvailableRoom() // hire must call an unspecified method that will // ensure that a new, available room is choosen 0..n Company Room rooms - e.office == getAvailableRoom() // SIDE EFFECT FREE! . boolean roomsAvailable() Room getAvailableRoom() . Room Company:getAvailableRoom() void hire(Employee e) void move(Employee e, Room newRoom) 1 office pre: roomsAvailable() post: 0..n employees - result != null - rooms->includes(result) Employee - !employees->exists(e | e.office == result) . - result == getAvailableRoom() // SIDE EFFECT FREE! . boolean Company:roomsAvailable() pre: TRUE post: result == rooms->exists( room | !employees->exists( e | e.office == room)) Cambridge Technology Partners © Reto Kramer, [email protected] Office Management Example (move) 3 4 0..n void Company:move(Employee e, Room newRoom)
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]
  • 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]
  • 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]
  • City Council Agenda Page 1
    CITY OF SANTA BARBARA CITY COUNCIL Helene Schneider James L. Armstrong Mayor City Administrator Randy Rowse Mayor Pro Tempore Grant House Stephen P. Wiley Ordinance Committee Chair City Attorney Dale Francisco Finance Committee Chair Frank Hotchkiss City Hall Cathy Murillo 735 Anacapa Street Bendy White http://www.SantaBarbaraCA.gov MAY 14, 2013 AGENDA ORDER OF BUSINESS: Regular meetings of the Finance Committee and the Ordinance Committee begin at 12:30 p.m. The regular City Council meeting begins at 2:00 p.m. in the Council Chamber at City Hall. REPORTS: Copies of the reports relating to agenda items are available for review in the City Clerk's Office, at the Central Library, and http://www.SantaBarbaraCA.gov. In accordance with state law requirements, this agenda generally contains only a brief general description of each item of business to be transacted or discussed at the meeting. Should you wish more detailed information regarding any particular agenda item, you are encouraged to obtain a copy of the Council Agenda Report (a "CAR") for that item from either the Clerk's Office, the Reference Desk at the City's Main Library, or online at the City's website (http://www.SantaBarbaraCA.gov). Materials related to an item on this agenda submitted to the City Council after distribution of the agenda packet are available for public inspection in the City Clerk’s Office located at City Hall, 735 Anacapa Street, Santa Barbara, CA 93101, during normal business hours. PUBLIC COMMENT: At the beginning of the 2:00 p.m. session of each regular City Council meeting, and at the beginning of each special City Council meeting, any member of the public may address the City Council concerning any item not on the Council's agenda.
    [Show full text]
  • Combining Design by Contract and Inference Rules of Programming Logic Towards Software Reliability
    Combining Design by Contract and Inference Rules of Programming Logic towards Software Reliability Nuha Aldausari*, Cui Zhang and Jun Dai Department of Computer Science, California State University, Sacramento, CA 95819, U.S.A. Keywords: Software Security, Software Reliability, Program Specifications, Error Detection, Design by Contract, Programming Logic. Abstract: Detecting errors in software products is very important to software reliability because many security vulnerabilities are caused by the defects in software. Design by contract (DBC) is an effective methodology that dynamically checks whether a program meets its specifications, which are also called design contracts, and whether there are errors in the program. The contracts for object-oriented programs are defined in terms of preconditions and postconditions for methods as well as invariants for classes. However, if there is an error in a large piece of code that has a design contract, it is still difficult to identify the exact location of that error. To address this issue, a tool named Subcontractor has been developed. Subcontractor is implemented in Eclipse environment using libraries such as Java Development Tools (JDT), Plugin Development Environment (PDE), and JFace. The tool Subcontractor is built upon an open source DBC tool, OpenJML Runtime Assertion Checking (RAC), which is a tool that verifies specifications at runtime. Subcontractor combines this DBC tool with inference rules of program logic for if-statements and loop- statements to automatically generate subcontracts for programs. When the programs, with subcontracts automatically generated and inserted by Subcontractor, are verified using OpenJML Runtime Assertion Checking (RAC), identification of errors in the code can be facilitated. 1 INTRODUCTION (University of Oldenburg, 2001), and Contracts for Java (C4J) (Bergström, 2012).
    [Show full text]
  • Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University
    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2006 Modular subclass verification: safely creating correct subclasses without superclass code Clyde Dwain Ruby Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ruby, Clyde Dwain, "Modular subclass verification: safely creating correct subclasses without superclass code " (2006). Retrospective Theses and Dissertations. 1877. https://lib.dr.iastate.edu/rtd/1877 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Modular subclass verification: Safely creating correct subclasses without superclass code by Clyde Dwain Ruby A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee Gary T. Leavens, Major Professor Samik Basu Clifford Bergman Shashi K. Gadia Jonathan D. H. Smith Iowa State University Ames, Iowa 2006 Copyright © Clyde Dwain Ruby, 2006. All rights reserved. UMI Number: 3243833 Copyright 2006 by Ruby, Clyde Dwain All rights reserved. UMI Microform 3243833 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, MI 48106-1346 ii TABLE OF CONTENTS ACKNOWLEDGEMENTS .
    [Show full text]