ContExt
Fig.1 Our Approach
ContExt project explores ways to automatically extract a model directly from the program. The model is represented by constraints that are likely to hold at a particular point in the target program. Our approach to model extraction uses a combination of static analysis of source code and dynamic analysis of runtime state. We are currently researching ways to make the static and dynamic techniques compliment each other.
ContExt is a contraint detection tool. Its implementation makes use of Daikon for dynamic analysis and AbsInt for static analysis.
Note that in the traditional approach software is created from higher-level specifications. For example, Java source code may be generated from a language-independent UML class diagram. ContExt project follows the opposite direction and extracts a higher-level abstraction in the form of constraints from the program itself, as presented on Fig.1.
Application of the Extracted Constraints to Program Comprehensibility
The extracted contraints may be used in a variety of tasks, such as debugging, test case generation, automatic comments, and verification. Our goal is to explore program comprehensibility characterized by the constraints our tool produces.
Let us turn to the notion of good software design in order to elaborate on how we propose to use constraints for program comprehension. The quality of (structural) design often determines the success or failure of a software project. Obviously, we prefer good designs over bad ones. However, can we tell one from the other? We believe that the key aspect that characterizes good designs is that good designs are comprehensible. In other words, better designs are easier for a human developer to understand. This is, of course, a subjective notion. Now if we substitute "human developer" for an "automated constraint detector", the criterion for evaluating the structural quality of design becomes (almost) objective:
Hypothesis: An automated constraint detector tool produces more precise constraints for programs with better (structural) designs.
Our goal is to examine the above Hypothesis on a large number of programs with varying quality of design.
Science of Design
The central concern of software engineering is the development of methods and tools to repeatedly produce reliable software on time and within budget. The ability to meet these goals is the key aspect which depends on a science of design. While some techniques may work some of the time, the techniques most valued in software engineering are those that can be expected to work well in a wide variety of projects, and whose applicability to a specific project can be determined a priori. This is exactly what we may expect from a science of design: such a science will allow software engineers to understand why one approach works better than another and in what contexts.
In this light, our ContExt project is a small ship exploring the ocean of the science of design.