Results 1 - 10
of
368
The Spec# Programming System: An Overview
, 2004
"... Spec# is the latest in a long line of work on programming languages and systems aimed at improving the development of correct software. This paper describes the goals and architecture of the Spec# programming system, consisting of the object-oriented Spec# programming language, the Spec# compiler ..."
Abstract
-
Cited by 542 (50 self)
- Add to MetaCart
(Show Context)
Spec# is the latest in a long line of work on programming languages and systems aimed at improving the development of correct software. This paper describes the goals and architecture of the Spec# programming system, consisting of the object-oriented Spec# programming language, the Spec# compiler, and the Boogie static program verifier. The language includes constructs for writing specifications that capture programmer intentions about how methods and data are to be used, the compiler emits run-time checks to enforce these specifications, and the verifier can check the consistency between a program and its specifications. The Spec#
Verification of Object-Oriented Programs with Invariants
- JOURNAL OF OBJECT TECHNOLOGY
, 2004
"... ... This paper defines a programming methodology for using object invariants. The methodology, which enriches a program's state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many inte ..."
Abstract
-
Cited by 224 (36 self)
- Add to MetaCart
(Show Context)
... This paper defines a programming methodology for using object invariants. The methodology, which enriches a program's state space to express when each object invariant holds, deals with owned object components, ownership transfer, and subclassing, and is expressive enough to allow many interesting object-oriented programs to be specified and verified. Lending itself to sound modular verification, the methodology also provides a solution to the problem of determining what state a method is allowed to modify.
A Simple and Practical Approach to Unit Testing: The JML and JUnit Way
- ECOOP 2002, volume 2374 of LNCS
, 2002
"... Abstract. Writing unit test code is labor-intensive, hence it is often not done as an integral part of programming. However, unit testing is a practical approach to increasing the correctness and quality of software; for example, the Extreme Programming approach relies on frequent unit testing. In t ..."
Abstract
-
Cited by 149 (30 self)
- Add to MetaCart
(Show Context)
Abstract. Writing unit test code is labor-intensive, hence it is often not done as an integral part of programming. However, unit testing is a practical approach to increasing the correctness and quality of software; for example, the Extreme Programming approach relies on frequent unit testing. In this paper we present a new approach that makes writing unit tests easier. It uses a formal specification language’s runtime assertion checker to decide whether methods are working correctly, thus automating the writing of unit test oracles. These oracles can be easily combined with hand-written test data. Instead of writing testing code, the programmer writes formal specifications (e.g., pre- and postconditions). This makes the programmer’s task easier, because specifications are more concise and abstract than the equivalent test code, and hence more readable
Eclat: Automatic generation and classification of test inputs
- In 19th European Conference Object-Oriented Programming
, 2005
"... Abstract. This paper describes a technique that selects, from a large set of test inputs, a small subset likely to reveal faults in the software under test. The technique takes a program or software component, plus a set of correct executions— say, from observations of the software running properly, ..."
Abstract
-
Cited by 137 (14 self)
- Add to MetaCart
(Show Context)
Abstract. This paper describes a technique that selects, from a large set of test inputs, a small subset likely to reveal faults in the software under test. The technique takes a program or software component, plus a set of correct executions— say, from observations of the software running properly, or from an existing test suite that a user wishes to enhance. The technique first infers an operational model of the software’s operation. Then, inputs whose operational pattern of execution differs from the model in specific ways are suggestive of faults. These inputs are further reduced by selecting only one input per operational pattern. The result is a small portion of the original inputs, deemed by the technique as most likely to reveal faults. Thus, the technique can also be seen as an error-detection technique. The paper describes two additional techniques that complement test input selection. One is a technique for automatically producing an oracle (a set of assertions) for a test input from the operational model, thus transforming the test input into a test case. The other is a classification-guided test input generation technique that also makes use of operational models and patterns. When generating inputs, it filters out code sequences that are unlikely to contribute to legal inputs, improving the efficiency of its search for fault-revealing inputs. We have implemented these techniques in the Eclat tool, which generates unit tests for Java classes. Eclat’s input is a set of classes to test and an example program execution—say, a passing test suite. Eclat’s output is a set of JUnit test cases, each containing a potentially fault-revealing input and a set of assertions at least one of which fails. In our experiments, Eclat successfully generated inputs that exposed fault-revealing behavior; we have used Eclat to reveal real errors in programs. The inputs it selects as fault-revealing are an order of magnitude as likely to reveal a fault as all generated inputs. 1
The Why/Krakatoa/Caduceus platform for deductive program verification
- In CAV ’07
, 2007
"... Abstract. We present the Why/Krakatoa/Caduceus set of tools for deductive veri cation of Java and C source code. 1 ..."
Abstract
-
Cited by 116 (16 self)
- Add to MetaCart
(Show Context)
Abstract. We present the Why/Krakatoa/Caduceus set of tools for deductive veri cation of Java and C source code. 1
Purity and side effect analysis for java programs
- IN VMCAI
, 2005
"... We present a new purity and side effect analysis for Java programs. A method is pure if it does not mutate any location that exists in the program state right before the invocation of the method. Our analysis is built on top of a combined pointer and escape analysis, and is able to determine that m ..."
Abstract
-
Cited by 95 (1 self)
- Add to MetaCart
(Show Context)
We present a new purity and side effect analysis for Java programs. A method is pure if it does not mutate any location that exists in the program state right before the invocation of the method. Our analysis is built on top of a combined pointer and escape analysis, and is able to determine that methods are pure even when the methods mutate the heap, provided they mutate only new objects. Our analysis provides useful information even for impure methods. In particular, it can recognize read-only parameters (a parameter is readonly if the method does not mutate any objects transitively reachable from the parameter) and safe parameters (a parameter is safe if it is read-only and the method does not create any new externally visible heap paths to objects transitively reachable from the parameter). The analysis can also generate regular expressions that characterize the externally visible heap locations that the method mutates. We have implemented our analysis and used it to analyze several applications. Our results show that our analysis effectively recognizes a variety of pure methods, including pure methods that allocate and mutate complex auxiliary data structures.
Beyond assertions: Advanced specification and verification with JML and ESC/Java2
- In Formal Methods for Components and Objects (FMCO) 2005, Revised Lectures, volume 4111 of LNCS
, 2006
"... Abstract. Many state-based specification languages, including the Java Modeling Language (JML), contain at their core specification constructs familiar to most computer science and software engineering undergraduates: e.g., assertions, pre- and postconditions, and invariants. Unfortunately, these co ..."
Abstract
-
Cited by 86 (17 self)
- Add to MetaCart
Abstract. Many state-based specification languages, including the Java Modeling Language (JML), contain at their core specification constructs familiar to most computer science and software engineering undergraduates: e.g., assertions, pre- and postconditions, and invariants. Unfortunately, these constructs are not sufficiently expressive to permit formal modular verification of programs written in modern object-oriented languages like Java. The necessary extra constructs for specifying an object-oriented module include the less familiar frame properties, datagroups, and ghost and model fields. These constructs help specifiers deal with potential problems related to, e.g., unexpected side effects, aliasing, class invariants, inheritance, and lack of information hiding. This tutorial focuses on these constructs, explaining their meaning while illustrating how they can be used to address the stated problems. 1
The Krakatoa Tool for Certification of Java/JavaCard Programs Annotated in JML
, 2003
"... We describe the basic structure of an environment for proving Java programs annotated with JML specications. Our method is generic with respect to the API, and thus well suited for JavaCard applets certication. It involves three distinct components: the Why tool, which computes proof obligations for ..."
Abstract
-
Cited by 80 (2 self)
- Add to MetaCart
We describe the basic structure of an environment for proving Java programs annotated with JML specications. Our method is generic with respect to the API, and thus well suited for JavaCard applets certication. It involves three distinct components: the Why tool, which computes proof obligations for a core imperative language annotated with pre- and post-conditions, the Coq proof assistant for modeling the program semantics and conducting the development of proofs, and nally the Krakatoa tool, a translator of our own, which reads the Java les and produces specications for Coq and a representation of the semantics of the Java program into Why's input language.
A Temporal Logic of Nested Calls and Returns
, 2004
"... Model checking of linear temporal logic (LTL) speci cations with respect to pushdown systems has been shown to be a useful tool for analysis of programs with potentially recursive procedures. LTL, however, can specify only regular properties, and properties such as correctness of procedures wit ..."
Abstract
-
Cited by 78 (14 self)
- Add to MetaCart
(Show Context)
Model checking of linear temporal logic (LTL) speci cations with respect to pushdown systems has been shown to be a useful tool for analysis of programs with potentially recursive procedures. LTL, however, can specify only regular properties, and properties such as correctness of procedures with respect to pre and post conditions, that require matching of calls and returns, are not regular. We introduce a temporal logic of calls and returns (CaRet) for speci cation and algorithmic veri cation of correctness requirements of structured programs. The formulas of CaRet are interpreted over sequences of propositional valuations tagged with special symbols call and ret. Besides the standard global temporal modalities, CaRet admits the abstract-next operator that allows a path to jump from a call to the matching return. This operator can be used to specify a variety of non-regular properties such as partial and total correctness of program blocks with respect to pre and post conditions. The abstract versions of the other temporal modalities can be used to specify regular properties of local paths within a procedure that skip over calls to other procedures. CaRet also admits the caller modality that jumps to the most recent pending call, and such caller modalities allow speci cation of a variety of security properties that involve inspection of the call-stack. Even though verifying contextfree properties of pushdown systems is undecidable, we show that model checking CaRet formulas against a pushdown model is decidable. We present a tableau construction that reduces our model checking problem to the emptiness problem for a Buchi pushdown system. The complexity of model checking CaRet formulas is the same as that of checking LTL formulas, namely, ...
