DOCSLIB.ORG

Foundations of Software Engineering Design by Contract

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Foundations of Software Engineering Design by Contract Foundations of Software Engineering Design by Contract Fall 2020 Department of Computer Science Ben-Gurion university Based on slides of: Mira Balaban Department of Computer Science Ben-Gurion university R. Mitchell and J. McKim: Design by Contract by Example Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” 2 Design by Contract Topics in Software Engineering, Fall 2019 Design by Contract The Design by Contract (DBC) software development technique ensures high quality software by guaranteeing that every component of a system lives up to its expectations. As a developer using DBC, you specify component contracts as part of the component's interface. The contract specifies what that component expects of clients and what clients can expect of it. 3 Design by Contract Topics in Software Engineering, Fall 2019 Design By Contract The term Design by Contract was coined by Bertrand Meyer while designing the Eiffel programming language within Eiffel Software company. Eiffel implements the Design by Contract principles. Bertrand Meyer won the 2006 ACM Software System Award for Eiffel The Eiffel Tower, built in 1887 for the 1889 World Fair, was completed on time and within budget, as will software projects written in Eiffel. 4 Design by Contract Topics in Software Engineering, Fall 2019 Design By Contract DbC is an approach for designing computer software. It prescribes that software designers should define precise verifiable interface specifications for software components based upon the theory of abstract data types and the conceptual metaphor of business contracts DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life: a client and a supplier agree on a contract. the contract defines obligations and benefits. 5 Design by Contract Topics in Software Engineering, Fall 2019 A contract There are two parties A Client - requests a service A Supplier - supplies the service A Contract is the agreement between the client and the supplier Two major characteristics of a contract Each party expects some benefits from the contract and is prepared to incur some obligations to obtain them These benefits and obligations are documented in a contract document Benefit of the client is the obligation of the supplier, and vice versa. 6 Design by Contract Topics in Software Engineering, Fall 2019 DbC – The idea and metaphor Motivation: Organize communication between software elements By organizing mutual obligations and benefits Do it by a metaphor of clients – request services from suppliers suppliers – supply services Client Supplier Obligation Satisfy supplier Guarantee service requirement Benefit Get service Impose requirements 7 Design by Contract Topics in Software Engineering, Fall 2019 DbC – The metaphor realization Obligations and benefits are specified using contracts Write contracts for classes and methods Methods: Preconditions Post-conditions Classes: Invariants Client Supplier Obligation Precondition Post-condition Benefit Post-condition Precondition 8 Design by Contract Topics in Software Engineering, Fall 2019 What happens when a Contract Breaks? If everyone does their job, there is no problem If the precondition is not satisfied – the Customer is wrong! (The client has a bug). If the precondition is satisfied, but the postcondition is not the Service is wrong (The service has a bug). From the Client’s perspective, “true” is the best precondition. In general, weaker preconditions are better. From the Server’s perspective, “false” is the best precondition. In general, stronger preconditions mean an easier job with the implementation. 9 Design by Contract Topics in Software Engineering, Fall 2019 DbC Nature DbC promotes software specification together with or prior to code writing Writing contracts needs some principles and guidelines The DbC principles tell us how to organize a class features (attributes, methods) The contract of a class is its interface 10 Design by Contract Topics in Software Engineering, Fall 2019 Design by Contract, by Example 11 Design by Contract Topics in Software Engineering, Fall 2019 Notations features attributes routines functions procedures creation other COMMANDS 12 Design by Contract Topics in Software Engineering, Fall 2019 Six Principles – the SIMPLE_STACK example Topics in Software Engineering, Fall Design by Contract 13 2019 SIMPLE_STACK example – initial try SIMPLE_STACK is a generic class, with type parameter G: Simple_stack of G. Features: G Queries – functions; No side effect: SIMPLE_STACK count(): Integer is_empty(): Boolean count() Initialization: is_empty() initialize() initialize() push(g:G) Commands: pop() push(g:G)no return value. pop(): out parameter g:G; no return value. 14 Design by Contract Topics in Software Engineering, Fall 2019 Example (1) Writing a contract for push: Takes a parameter g. Places g on the top of the stack. push(g:G) Purpose: Push g onto the top of the stack. ensure: g = pop ??? 15 Design by Contract Topics in Software Engineering, Fall 2019 Example (2) Writing a contract for push: Takes a parameter g. Places g on the top of the stack. push(g:G) Purpose: Push g onto the top of the stack. ensure: g = pop ??? but pop does not return a value. Just removes. Redesign pop: pop(): G purpose: Remove top item and return it. New push contract: push(g:G) Purpose: Push g onto the top of the stack. ensure: g = pop 16 Design by Contract Topics in Software Engineering, Fall 2019 A. Separate commands from queries (1) Serious problem: Evaluation of the post-condition changes the stack! Solution: Split pop into two operations: 1. Query: top(): G purpose: return the item at the top of the stack. 2. Command: delete() purpose: deletes the item at the top of the stack. push contract: push(g:G) purpose: Push g onto the top of the stack. ensure: top = g 17 Design by Contract Topics in Software Engineering, Fall 2019 A. Separate commands from queries (2) Standardize names: Class: SIMPLE_STACK Queries: count(): Integer purpose: No of items on the stack. item(): G purpose: The top item is_empty(): Boolean Boolean queries have purpose: Is the stack empty? names that invite a yes/no Creation commands: question initialize() purpose: Initialize a stack (new or old) to be empty. Operations (other commands): put(g:G) purpose: Push g on top of the stack. A standard name to add remove() /delete item from any purpose: Removes the top item of the stack. container class 18 Design by Contract Topics in Software Engineering, Fall 2019 A. Separate commands from queries Principle 1: Separate commands from queries. Queries: Return a result. No side effects. Pure functions. Commands: Might have side effects. No return value. Some operations are a mixture: pop() – removes the top item and returns it →Separate into two pore primitive command and query of which it is mixed 19 Design by Contract Topics in Software Engineering, Fall 2019 B. Separate basic queries from derived queries (1) is_empty(): Boolean Post-condition of is_empty: purpose: Is the stack empty? ensure: consistent_with_count: Result = (count()=0) Result is a contract built-in variable that holds the result that a function returns to its caller. The effect of is_empty() is defined in terms of the count query. → is_empty() is a derived query: It can be replaced by the test: count() = 0. → Contracts of other features can be defined in terms of basic queries alone. No need to state the status of derived queries – no need to state in the post-condition of put() that is_empty() is false. state: count is increased infer : is_empty=false from the contract of is_empty 20 Design by Contract Topics in Software Engineering, Fall 2019 Separate basic queries from derived queries (2) Principle 2: Separate basic queries from derived queries. Derived queries can be specified in terms of basic queries. Principle 3: For each derived query, write a post-condition that defines the query in terms of basic queries. 21 Design by Contract Topics in Software Engineering, Fall 2019 Specify how commands affect basic queries (1) Queries provide the interface of an object: all information about an object is obtained by querying it. Derived queries are defined in terms of basic queries (principle3). → The effect of a command on an object should be specified in terms of basic queries. For Simple_stack, define the effects of put() initialize() remove() in terms of the basic queries count() item() 22 Design by Contract Topics in Software Engineering, Fall 2019 Specify how commands affect basic queries (2) The put command: put() increases count by 1. put() affects the top item. put(g:G) Purpose: Push g onto the top of the stack. ensure: count_increased: count() = count()@pre + 1 g_on_top: item() = g “@pre” is borrowed from OCL (Object Constraint Language) count()@pre refers to the value of the query count() when put() is called. 23 Design by Contract Topics in Software Engineering, Fall 2019 Specify how commands affect basic queries (3) The initialize() command: Turns count() to 0: → post-condition count() = 0. initialize() purpose: Turns a stack (new or old) to be empty. ensure: stack_is_empty: count() = 0 Following initialization the stack includes no items. Therefore, no top item → The query item() cannot be applied. Implies a pre-condition for the query item: item() : G purpose: The top item on the stack. require: stack_is_not_empty: count() > 0 Together, the 2 contracts, guarantee that applying item after initialize is illegal! 24 Design by Contract Topics in Software Engineering, Fall 2019 Specify how commands affect basic queries (4) The remove() command: Two effects: Reduces the number of items by one. Removes the top item, and uncovers the item pushed before the top one. Pre-condition: Stack is not empty.
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]
  • 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]
  • 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]
  • 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]
  • 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]