Daikon is an implementation of dynamic detection of likely invariants; that is, the Daikon invariant detector reports likely program invariants. An invariant is a property that holds at a certain point or points in a program; these are often used in assert statements, documentation, and formal specifications. Examples include being constant (x = a), non-zero (x ̸ = 0), being in a

Dynamic detection of likely invariants is a program analysis that generalizes over observed values to hypothesize program properties. The reported program properties are a set of likely invariants over the program, also known as an operational abstraction. Operational abstractions are useful in testing, verification, bug detection, refactoring, comparing behavior, and many other tasks. Previous techniques for...

A developer often needs to understand both the code structure and the execution structure of an object-oriented program. Class diagrams extracted from source are often sufficient to understand the code structure. However, existing static or dynamic analyses that produce raw graphs of objects and relations between them, do not convey design intent or readily scale to large programs. Imposing an ownership hierarchy on a program’s execution structure through ownership domain annotations provides an intuitive and appealing mechanism to obtain, at compile-time, a visualization of a system’s execution structure. The visualization conveys design intent, is hierarchical, and thus is more scalable than existing approaches that produce raw object graphs. We first describe the construction of the visualization and then evaluate it on two real Java programs of 15,000 lines of code each that have been previously annotated. In both cases, the automatically generated visualization fit on one page, and gave us insights into the execution structure that would be otherwise hard to obtain by looking at the code, at existing class diagrams, or at unreadable visualizations produced by existing compile-time approaches. 1.

We define the substitutability problem in the context of evolving software systems as the verification of the following two criteria: (i) previously established system correctness properties must remain valid for the new version of a system, and (ii) the updated portion of the system must continue to provide all (and possibly more) services o#ered by its earlier counterpart. We present a completely automated procedure based on learning techniques for regular sets to solve the substitutability problem for component based software. We have implemented and validated our approach in the context of the ComFoRT reasoning framework and report encouraging preliminary results on an industrial benchmark.

Abstract not found

This paper presents an automated and compositional procedure to solve the substitutability problem in the context of evolving software systems. Our solution

This paper is a survey of several techniques that have proven useful in establishing compatibility among behaviorally similar programs (e.g., system upgrades, object sub- and supertypes, system components produced by different vendors, etc.). We give a comparative analysis of the techniques by evaluating their applicability to various aspects of the compatibility problem.

Software errors often occur at the interfaces between separately developed components. Incompatibilities are an especially acute problem when upgrading software components, as new versions may be accidentally incompatible with old ones. As an inexpensive mechanism to detect many such problems, previous work proposed a technique that adapts methods from formal verification to use component abstractions that can be automatically generated from implementations. The technique reports, before performing the replacement or integrating the new component into a system, whether the upgrade might be problematic for that particular system. The technique is based on a rich model of components that support internal state, callbacks, and simultaneous upgrades of multiple components, and component abstractions may contain arbitrary logical properties including unbounded-state ones. This paper motivates this (somewhat non-standard) approach to component verification. The paper also refines the formal model of components, provides a formal model of software system safety, gives an algorithm for constructing a consistency condition, proves that the algorithm’s result guarantees system safety in the case of a single-component upgrade, and gives a proof outline of the algorithm’s correctness in the case of an arbitrary upgrade. 1.

This paper addresses the problem of identifying incompatibilities between two programs that operate in a producer/consumer relationship. It describes the techniques that are incorporated in a tool called PCCA (Producer-Consumer Conformance Analyzer), which attempts to (i) determine whether the consumer is prepared to accept all messages that the producer can emit, or (ii) find a counterexample: a message that the producer can emit and the consumer will reject. 1.

In the long run, programs should be written from the start with verification in mind. Programs written in such a way are likely to be much easier to verify. They will avoid hard-to-verify features, may have better designs, will be accompanied by full formal specifications, and may be annotated with verification information. However, even if programs should be written this way, not all of them will. In the short run, it is crucial to verify the legacy programs that make up our existing computing infrastructure, and to provide tools that assist programmers in performing verification tasks and — equally importantly — in shifting their mindset to one of program verification. I propose approaches to verification that may assist in reaching these goals. The key idea underlying the approaches is specification inference (Section 1). This is a machine learning technique that produces, from an existing program, a (likely) specification of that program. Specifications are very frequently missing from real-world programs, but are required for verification. The inferred specification can serve as a goal for verification. I discuss three different approaches that can use such inferred specifications. One uses a heavyweight proof assistant (Section 2), one uses an automated theorem prover (Section 3, and one requires no user interaction but provides no guarantee (Section 4). 1 Inference of likely specifications