Explicitly stated program invariants can help programmers by identifying program properties that must be preserved when modifying code. In practice, however, these invari-ants are usually implicit. An alternative to expecting pro-grammers to fully annotate code with invariants is to au-tomatically infer invariants from the program itself. This research focuses on dynamic techniques for discovering in-variants from execution traces. This paper reports two results. First, it describes techniques for dynamically discovering invariants, along with an instru-menter and an inference engine that embody these tech-niques. Second, it reports on the application of the engine to two sets of target programs. In programs from Gries’s work on program derivation, we rediscovered predefined in-variants. In a C program lacking explicit invariants, we dis-covered invariants that assisted a software evolution task.

Assertions play an important role in the construction of robust software. Their use in programming languages dates back to the 1970s. Eiffel, an object-oriented programming language, wholeheartedly adopted assertions and developed the "Design by Contract" philosophy. Indeed, the entire object-oriented community recognizes the value of assertion-based contracts on methods.

Abstract not found

Program slicing is a technique for automatically identifying all the lines in a program which affect a selected subset of variables. A large program can be divided into a number of smaller programs (its slices), each constructed for different variable subsets. The slices are typically simpler than the original program, thereby simplifying the process of testing a property of the program which only concerns a subset of its variables. Some aspects of a program's computation are not captured by a set of variables, rendering slicing inapplicable. To overcome this difficulty we make a program introspective, adding assignments to denote these `implicit' computations. Initially this makes the program longer. However, slicing can now be applied to the introspective program, forming a slice concerned solely with the implicit computation. We improve the simplification power of slicing using program transformation. To illustrate our approach we consider the implicit computation which ...

After a system is deployed, fixes, enhancements, and modifications all occur that change the components that make up the system. Unfortunately, new versions of components can introduce new errors and break existing, depended-upon behavior. When this happens, the old component version could have provided the correct behavior, but it is no longer part of the system. We propose a framework for upgrading system components that, instead of removing the old version of the component, keeps multiple versions of a component running. Doing so allows behavior to be utilized from all versions, and maintains system integrity and correctness even in the presence of newly introduced errors. This framework ensures that the move towards dynamic, configurable software systems does not lessen, but rather provides capabilities to enhance, the reliability that software will achieve through the next century. 1 INTRODUCTION Users fear upgrades. This unfortunate but true statement reflects the current para...

This paper illustrates how software can be described precisely using LD-relations, how these descriptions can be presented in a readable manner using tabular notations, and one way such descriptions can be used to test programs. We describe an algorithm that can be used to generate a test oracle from program documentation, and present the results of using a tool based on it to help test part of a commercial network management application. The results demonstrate that these methods can be effective at detecting errors and greatly increase the speed and accuracy of test evaluation when compared with manual evaluation. Such oracles can be used for unit testing, --in situ testing, constructing self-checking software and ensuring consistency between code and documentation. Index Terms---Program testing, test oracle, formal specification, finite state machine. u 1 Introduction The Software Engineering Research Group at McMaster University is studying ways to improve the quality and...

Abstract not found

The state of knowledge in how to specify sequential programs in object-oriented languages such as Java and C# and the state of the art in automated verification tools for such programs have made measurable progress in the last several years. This paper describes several remaining challenges and approaches to their solution.

Checking pre- and post-conditions of procedures and methods at runtime helps improve software reliability. In the procedural world, pre- and post-conditions have a straightforward interpretation. If a procedure's pre-condition doesn't hold, the caller failed to establish the proper context. If a post-condition doesn't hold, the procedure failed to compute the expected result. In the object-oriented world, checking pre- and post-conditions for methods, often called contracts in this context, posescomplex problems. Because methods may be overridden, it is not sufficient to check only pre- and post-conditions. In addition, the contract hierarchy must be checked to ensure that the contracts on overridden methods are properly related to the contracts on overriding methods. Otherwise, a class hierarchy may violate the substitution principle, that is, it may no longer be true that an instance of a class is substitutable for objects of the super-class. In this paper, we study the problem of contract enforcement in an object-oriented world from a foundational perspective. More specifically, we study contracts as refinements of types. Pushing the analogy further, we state and prove a contract soundness theorem that captures the essential properties of contract enforcement. We use the theorem to illustrate how most existing tools suffer from a fundamental flaw and how they can be improved. 1.

We present a formal methodology and tool for uncovering errors in the interaction of software modules. Our methodology consists of a suite of languages for de ning software interfaces, and algorithms for checking interface compatibility. We focus on interfaces that explain the method-call dependencies between software modules. Such an interface makes assumptions about the environment in the form of call and availability constraints. A call constraint restricts the accessibility of local methods to certain external methods.