Figure 3 - uploaded by Manuel Fähndrich
Content may be subject to copyright.
Source publication
Integrating tools and extensions into existing languages, compilers, debuggers, and IDEs can be difficult, work-intensive, and often results in a one-off integration. In this paper, we report on our experience of building and integrating the CodeContract tool set into an existing programming environment. The CodeContract tools enable 1) authoring o...
Context in source publication
Citations
... -Eiffel [29], a programming language, has a built-in specification language; -JML [10], the Java Modeling Language, expresses specifications for Java programs; -ACSL [7], the ANSI/ISO-C Specification Language, expresses specifications for ANSI-C programs, and the in-development ACSL++ specification language for C++; -SPARK [3] expresses specifications for the Ada programming language; -Spec# [4] expresses specifications for C#, with the following CodeContracts [20] system working for .NET environments; -Dafny [28] is a specification and programming language purpose-built for verification. ...
... -Spec# [4] was built as an extension of C# with non-null types as well as contracts, enforced by Eiffel-like run-time checks and by a static program verifier. En route to market, it became CodeContracts [20], a simplified and language-agnostic specification language for .NET with a tool to insert runtime checks and with a static analyzer to check certain properties statically. ...
Runtime assertion checking aspires to a similar level of sound and complete checking of software as does static deductive verification. Furthermore, for the same source language and specification language, runtime and static checking should implement as closely as possible the same semantics. We describe here the architecture used by two different systems to achieve this goal. We accompany that with descriptions of novel designs and implementations that add new capabilities to runtime assertion checking, bringing it closer to the feature coverage of static verification.
... We will use concrete/symbolic execution combined with constraint solving, to automatically verify produced patches, against their corresponding specifications captured as contracts. More precisely, we will translate patches into C#, and equip these with preand post-conditions captured using Code Contracts [7]; we will then search for inputs that violate these assertions via concrete/symbolic execution and SMT solving, using Pex [22]. ...
... In the senior-level course on software engineering, students learn the role of formal assertions in the context of specifying software interfaces. Students work in the Visual Studio environment and use Code Contracts[5]to check correctness of code with respect to specifications. The other is a graduate-level formal methods course that is focused exclusively on tools for model checking and software verification, such as Dafny, NuSMV, RESOLVE, and SPIN. ...
A central goal of computer science education is to teach students how to reason about the correctness of the code they write. Typically, students use a trial and error process and check that their logic "works" by running it on test inputs. Typically, instructors encour-age them towards logical reasoning through manual tracing of the code. Rarely reasoning tools are used in the process, at least partly because few instructors are familiar with them and fewer have the time to investigate and experiment. The purpose of this panel is to introduce the attendees to a variety of reasoning tools the presenters have used in their classrooms. In some cases, the tools have been used in only one or two classes of a course to illustrate specific points. In other cases, entire projects have been done using the tools. The courses range from the introductory sequence and dis-crete structures to software engineering and graduate-level courses. The tools are freely available on the web and attendees will be encouraged to experiment with the reasoning tools on their own laptops to solve simple reasoning problems.
... Previous research tried to ease the burden of learning a new specification language for each different DbC tool [13], [20] by embedding contracts into the programming language. SuperContra goes beyond such approaches to provide DbC that is both language and run-time agnostic. ...
This paper presents SuperContra - a Design-by-Contract (DbC) framework that can ship with future PaaS offerings to enforce lightweight contracts across different programming systems, as-a-service. SuperContra is unique in that developers employ a familiar, high-level language to write contracts regardless of the programming language used to implement the component under test. We evaluate SuperContra using widely used, open-source software and compare its performance against existing DbC frameworks. Our results show that SuperContra performs on par with non-service-based DbC approaches and in some cases similarly to code running without contracts.
... Even disregarding the initial amount of work that has to be put in to obtain a parser and semantic analyzer for an existing language, this tool now must be maintained and updated when a new language version comes out, or when bugfixes have been applied to the original tool. The authors of the Spec # verifier have experienced this maintenance problem, which led them to adopt a different strategy for the design of Code Contracts [16] . They stress that deviating from the official language should be avoided so that standard tools can be used. ...
Formal program verification tools check that a program correctly implements its specification. Existing specification languages for well-known programming languages (Ada, C, Java, C#) have been developed independently from the programming language to which they apply. As a result, specifications are expressed separately from the code, typically as stylized comments, and the verification tools often bear no direct relation to the production compiler. We argue that this approach is problematic, and that the compiler and the verification tools should be integrated seamlessly. Based on our current work on the Hi-Lite project to develop a formal verification tool for Ada2012, we show that in an integrated setting, the compiler becomes the centerpiece of the verification architecture, and supports both static proofs and run-time assertion checking. Such an environment does much to simplify software certification.
We present Deuterium---a framework for implementing Java methods as executable contracts. Deuterium introduces a novel, type-safe way to write method contracts entirely in Java, as a combination of imperative generators and declarative specifications (written in a first-order relational logic with transitive closure). Existing approaches are typically based on encoding both the specification and the program heap into a constraint language, and then using an off-the-shelf constraint solver---without any additional guidance---to search for a new program heap that satisfies the specification. Deuterium takes advantage of user-provided generators to prune the search space and reduce incurred overhead of constraint solving. Deuterium supports two ways of solving declarative constraints: SAT-based and search-based with in-memory state exploration. We evaluate our approach on a suite of data structures, established as a standard benchmark by prior work. Furthermore, we use random and sequence-based test generation to create a new benchmark designed to mimic realistic execution scenarios. Our results show that generators improve the performance of executable contracts and that in-memory state exploration is the algorithm of choice when heap sizes are small.
Formal program verification tools check that a program correctly implements its specification. Existing specification languages for well-known programming languages (Ada, C, Java, C#) have been developed independently from the programming language to which they apply. As a result, specifications are expressed separately from the code, typically as stylized comments, and the verification tools often bear no direct relation to the production compiler. We argue that this approach is problematic, and that the compiler and the verification tools should be integrated seamlessly. Based on our current work on the Hi-Lite project to develop a formal verification tool for Ada2012, we show that in an integrated setting, the compiler becomes the centerpiece of the verification architecture, and supports both static proofs and run-time assertion checking. Such an environment does much to simplify software certification.
As the use of concurrent software is increasing, we urgently need techniques to establish the correctness of such applications. Over the last years, significant progress has been made in the area of software verification, making verification techniques usable for realistic applications. However, much of this work concentrates on sequential software, and a next step is necessary to apply these results also on realistic concurrent software. In this paper, we outline a research agenda to realise this goal. We argue that current techniques for verification of concurrent software need to be further developed in multiple directions: extending the class of properties that can be established, improving the level of automation that is available for this kind of verification, and enlarging the class of concurrent programs that can be verified.
Contract programming is one of the most promising ways of enhancing the reliability of Python, which becomes increasingly desired. Higher-order contract systems that support fully specifying the behaviors of iterators and functions are desirable for Python but have not been presented yet. Besides, even with them, debugging with contracts in Python would still be burdensome because of delayed contract checking. To resolve this problem, we present PyBlame, a higher-order contract system in Python, and ccdb, a source-level debugger equipped with features dedicated to debugging with delayed contract checking. PyBlame and ccdb are designed on the basis of the standard of Python and thus friendly to many Python programmers. We have experimentally confirmed the advantage and the efficacy of PyBlame and ccdb through the web framework Bottle.
Contracts are a popular tool for specifying the functional behavior of software. This paper characterizes the contracts that developers write, the contracts that developers could write, and how a developer reacts when shown the difference.
This paper makes three research contributions based on an investigation of open-source projects' use of Code Contracts. First, we characterize Code Contract usage in practice. For example, approximately three-fourths of the Code Contracts are basic checks for the presence of data. We discuss similarities and differences in usage across the projects, and we identify annotation burden, tool support, and training as possible explanations based on developer interviews. Second, based on contracts automatically inferred for four of the projects, we find that developers underutilize contracts for expressing state updates, object state indicators, and conditional properties. Third, we performed user studies to learn how developers decide which contracts to enforce. The developers used contract suggestions to support their existing use cases with more expressive contracts. However, the suggestions did not lead them to experiment with other use cases for which contracts are better-suited.
In support of the research contributions, the paper presents two engineering contributions: (1) Celeriac, a tool for generating traces of .NET programs compatible with the Daikon invariant detection tool, and (2) Contract Inserter, a Visual Studio add-in for discovering and inserting likely invariants as Code Contracts.
