Author

David Notkin

148 papers · 1976–2019

1976peak 11 in 20022019

Frequent co-authors

Papers

showing 1–25 of 148 RSS

Dynamically discovering likely program invariants to support program evolution

Michael D. Ernst, Jake Cockrell, William G. Griswold +1 more

Information Systems · 16 May 1999 · cited 1,048× · DOI ↗ · more like this ·

Article Free Access Share on Dynamically discovering likely program invariants to support program evolution Authors: Michael D. Ernst Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , Jake Cockrell Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , William G. Griswold Dept. of Computer Science & Engineering, University of California San Diego, 0114, La Jolla, CA Dept. of Computer Science & Engineering, University of California San Diego, 0114, La Jolla, CAView Profile , David Notkin Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science &…

An empirical study of code clone genealogies

Miryung Kim, Vibha Sazawal, David Notkin +1 more

Information Systems · September 2005 · cited 527× · DOI ↗ · more like this ·

It has been broadly assumed that code clones are inherently bad and that eliminating clones by refactoring would solve the problems of code clones. To investigate the validity of this assumption, we developed a formal definition of clone evolution and built a clone genealogy tool that automatically extracts the history of code clones from a source code repository. Using our tool we extracted clone genealogy information for two Java open source projects and analyzed their evolution. Our study contradicts some conventional wisdom about clones. In particular, refactoring may not always improve software with respect to clones for two reasons. First, many code clones exist in the system for only a short time; extensive refactoring of such short-lived clones may not be worthwhile if they are likely diverge from one another very soon. Second, many clones, especially long-lived clones that have…

Software reflexion models

Gail C. Murphy, David Notkin, Kevin Sullivan

Information Systems · October 1995 · cited 476× · DOI ↗ · more like this ·

article Software reflexion models: bridging the gap between source and high-level models Share on Authors: Gail C. Murphy Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , David Notkin Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , Kevin Sullivan Dept. of Computer Science, University of Virginia, Charlottesville VA Dept. of Computer Science, University of Virginia, Charlottesville VAView Profile Authors Info & Claims ACM SIGSOFT Software Engineering NotesVolume 20Issue 4Oct. 1995 pp 18–28https://doi.org/10.1145/222132.222136Published:01 October 1995 305citation2,070DownloadsMetricsTotal…

ArchJava

Jonathan Aldrich, Craig Chambers, David Notkin

Artificial Intelligence · 2002 · cited 449× · DOI ↗ · more like this ·

Software architecture describes the structure of a system, enabling more effective design, program understanding, and formal analysis. However, existing approaches decouple implementation code from architecture, allowing inconsistencies, causing confusion, violating architectural properties, and inhibiting software evolution. ArchJava is an extension to Java that seamlessly unifies software architecture with implementation, ensuring that the implementation conforms to architectural constraints. A case study applying ArchJava to a circuit-design application suggests that ArchJava can express architectural structure effectively within an implementation, and that it can aid in program understanding and software evolution.

Software reflexion models: bridging the gap between design and implementation

Gail C. Murphy, David Notkin, Kevin Sullivan

Information Systems · IEEE Transactions on Software Engineering · April 2001 · cited 393× · DOI ↗ · more like this ·

The artifacts constituting a software system often drift apart over time. We have developed the software reflexion model technique to help engineers perform various software engineering tasks by exploiting, rather than removing, the drift between design and implementation. More specifically, the technique helps an engineer compare artifacts by summarizing where one artifact (such as a design) is consistent with and inconsistent with another artifact (such as source). The technique can be applied to help a software engineer evolve a structural mental model of a system to the point that it is "good enough" to be used for reasoning about a task at hand. The software reflexion model technique has been applied to support a variety of tasks, including design conformance, change assessment, and an experimental reengineering of the million-lines-of-code Microsoft Excel product. We provide a…

Model checking large software specifications

Richard Anderson, Paul Beame, S.M. Burns +4 more

Computational Theory and Mathematics · October 1996 · cited 309× · DOI ↗ · more like this ·

In this paper we present our results and experiences of using symbolic model checking to study the specification of an aircraft collision avoidance system. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in the question of whether or not model checking techniques can be applied to large software specifications.To investigate this, we translated a portion of the finite-state requirements specification of TCAS II (Traffic Alert and Collision Avoidance System) into a form accepted by a model checker (SMV). We successfully used the model checker to investigate a number of dynamic properties of the system.We report on our experiences, describing our approach to translating the specification to the SMV language and our methods for achieving acceptable performance in model checking, and giving a summary of the properties that we were able…

Gandalf: Software development environments

A. N. Habermann, David Notkin

Information Systems · IEEE Transactions on Software Engineering · December 1986 · cited 302× · DOI ↗ · more like this ·

Different programming projects require different environments, but handcrafting a separate environment for each project is not economically feasible. Gandalf solves this problem by permitting environment designers to generate families of software development environments semiautomatically without excessive cost. Environments generated using Gandalf address programming environments, which help ease the programming process, as well as system development environments, which reduce the degree to which a software project is dependent on the good will of its members. Gandalf environments integrate programming and system development, permitting interactions not available in traditional environments. The paper covers the basic characteristics of Gandalf environments. The method used to generate these environments, the structure and function of several existing environments, and ongoing research…

Using role components in implement collaboration-based designs

Michael VanHilst, David Notkin

Artificial Intelligence · NSUWorks (Nova Southeastern University) · October 1996 · cited 258× · DOI ↗ · more like this ·

In this paper we present a method of code implementation that works in conjunction with collaboration and responsibility based analysis modeling techniques to achieve better code reuse and resilience to change. Our approach maintains a closer mapping from responsibilities in the analysis model to entities in the implementation. In so doing, it leverages the features of flexible design and design reuse found in collaboration-based design models to provide similar adaptability and reuse in the implementation. Our approach requires no special development tools and uses only standard features available in the C++ language. In an earlier paper we described the basic mechanisms used by our approach and discussed its advantages in comparison to the framework approach. In this paper we show how our approach combines code and design reuse, describing specific techniques that can be used in the…

Quickly detecting relevant program invariants

Michael D. Enst, Adam Czeisler, William G. Griswold +1 more

Information Systems · 2000 · cited 256× · DOI ↗ · more like this ·

Explicitly stated program invariants can help programmers by characterizing certain aspects of program execution and identifying program properties that must be preserved when modifying code. Unfortunately, these invariants are usually absent from code. Previous work showed how to dynamically detect invariants from program traces by looking for patterns in and relationships among variable values. A prototype implementation, Daikon, accurately recovered invariants from formally-specified programs, and the invariants it detected in other programs assisted programmers in a software evolution task. However, Daikon suffered from reporting too many invariants, many of which were not useful, and also failed to report some desired invariants.

An empirical analysis of c preprocessor use

Michael D. Ernst, Greg J. Badros, David Notkin

Information Systems · IEEE Transactions on Software Engineering · December 2002 · cited 225× · DOI ↗ · more like this ·

This is the first empirical study of the use of the C macro preprocessor, Cpp. To determine how the preprocessor is used in practice, this paper analyzes 26 packages comprising 1.4 million lines of publicly available C code. We determine the incidence of C preprocessor usage-whether in macro definitions, macro uses, or dependences upon macros-that is complex, potentially problematic, or inexpressible in terms of other C or C++ language features. We taxonomize these various aspects of preprocessor use and particularly note data that are material to the development of tools for C or C++, including translating from C to C++ to reduce preprocessor usage. Our results show that, while most Cpp usage follows fairly simple patterns, an effective program analysis tool must address the preprocessor. The intimate connection between the C programming language and Cpp, and Cpp's unstructured…

Proactive detection of collaboration conflicts

Yuriy Brun, Reid Holmes, Michael D. Ernst +1 more

Information Systems · 6 Sep 2011 · cited 199× · DOI ↗ · more like this ·

Collaborative development can be hampered when conflicts arise because developers have inconsistent copies of a shared project. We present an approach to help developers identify and resolve conflicts early, before those conflicts become severe and before relevant changes fade away in the developers' memories. This paper presents three results.

Model checking large software specifications

W. K. Chan, Richard Anderson, Paul Beame +4 more

Software · IEEE Transactions on Software Engineering · July 1998 · cited 199× · DOI ↗ · more like this ·

In this paper, we present our experiences in using symbolic model checking to analyze a specification of a software system for aircraft collision avoidance. Symbolic model checking has been highly successful when applied to hardware systems. We are interested in whether model checking can be effectively applied to large software specifications. To investigate this, we translated a portion of the state-based system requirements specification of Traffic Alert and Collision Avoidance System II (TCAS II) into input to a symbolic model checker (SMV). We successfully used the symbolic model checker to analyze a number of properties of the system. We report on our experiences, describing our approach to translating the specification to the SMV language, explaining our methods for achieving acceptable performance, and giving a summary of the properties analyzed. Based on our experiences, we…

Automated assistance for program restructuring

William G. Griswold, David Notkin

Information Systems · ACM Transactions on Software Engineering and Methodology · July 1993 · cited 188× · DOI ↗ · more like this ·

Maintenance tends to degrade the structure of software, ultimately making maintenance more costly. At times, then, it is worthwhile to manipulate the structure of a system to make changes easier. However, manual restructuring is an error-prone and expensive activity. By separating structural manipulations from other maintenance activities, the semantics of a system can be held constant by a tool, assuring that no errors are introduced by restructuring. To allow the maintenance team to focus on the aspects of restructuring and maintenance requiring human judgment, a transformation-based tool can be provided—based on a model that exploits preserving data flow dependence and control flow dependence—to automate the repetitive, error-prone, and computationally demanding aspects of restructuring. A set of automatable transformations is introduced; their impact on structure is described, and…

Dynamically discovering likely program invariants

Michael D. Ernst, David Notkin

Information Systems · 2000 · cited 184× · OpenAlex ↗ · more like this ·

This dissertation introduces dynamic detection of program invariants, presents techniques for detecting such invariants from traces, assesses the techniques' efficacy, and points the way for future research. Invariants are valuable in many aspects of program development, including design, coding, verification, testing, optimization, and maintenance. They also enhance programmers' understanding of data structures, algorithms, and program operation. Unfortunately, explicit invariants are usually absent from programs, depriving programmers and automated tools of their benefits. This dissertation shows how invariants can be dynamically detected from program traces that capture variable values at program points of interest. The user runs the target program over a test suite to create the traces, and an invariant detector determines which properties and relationships hold over both…

Discovering and representing systematic code changes

Miryung Kim, David Notkin

Information Systems · 2009 · cited 183× · DOI ↗ · more like this ·

Software engineers often inspect program differences when reviewing others' code changes, when writing check-in comments, or when determining why a program behaves differently from expected behavior after modification. Program differencing tools that support these tasks are limited in their ability to group related code changes or to detect potential inconsistencies in those changes. To overcome these limitations and to complement existing approaches, we built Logical Structural Diff (LSdiff), a tool that infers systematic structural differences as logic rules. LSdiff notes anomalies from systematic changes as exceptions to the logic rules. We conducted a focus group study with professional software engineers in a large E-commerce company; we also compared LSdiff's results with textual differences and with structural differences without rules. Our evaluation suggests that LSdiff…

Automated support for program refactoring using invariants

Yoshio Kataoka, Michael D. Ernst, William G. Griswold +1 more

Information Systems · 13 Nov 2002 · cited 170× · DOI ↗ · more like this ·

Program refactoring-transforming a program to improve readability, structure, performance, abstraction, maintainability, or other features-is not applied in practice as much as might be desired. One deterrent is the cost of detecting candidates for refactoring and of choosing the appropriate refactoring transformation. This paper demonstrates the feasibility of automatically finding places in the program that are candidates for specific refactorings. The approach uses program invariants: when a particular pattern of invariant relationships appears at a program point, a specific refactoring is applicable. Since most programs lack explicit invariants, an invariant detection tool called Daikon is used to infer the required invariants. We developed an invariant pattern matcher for several common refactorings and applied it to an existing Java code base. Numerous refactorings were detected…

Reconciling environment integration and software evolution

Kevin J. Sullivan, David Notkin

Artificial Intelligence · ACM Transactions on Software Engineering and Methodology · July 1992 · cited 162× · DOI ↗ · more like this ·

Common software design approaches complicate both tool integration and software evolution when applied in the development of integrated environments. We illustrate this by tracing the evolution of three different designs for a simple integrated environment as representative changes are made to the requirements. We present an approach that eases integration and evolution by preserving tool independence in the face of integration. We design tool integration relationships as separate components called mediators , and we design tools to implicitly invoke mediators that integrate them. Mediators separate tools from each other, while implicit invocation allows tools to remain independent of mediators. To enable the use of our approach on a range of platforms, we provide a formalized model and requirements for implicit invocation mechanisms. We apply this model both to analyze existing…

An empirical study of static call graph extractors

Gail C. Murphy, David Notkin, William G. Griswold +1 more

Information Systems · ACM Transactions on Software Engineering and Methodology · April 1998 · cited 152× · DOI ↗ · more like this ·

Informally, a call graph represents calls between entities in a given program. The call graphs that compilers compute to determine the applicability of an optimization must typically be conservative: a call may be omitted only if it can never occur in any execution of the program. Numerous software engineering tools also extract call graphs with the expectation that they will help software engineers increase their understanding of a program. The requirements placed on software engineering tools that compute call graphs are typically more relaxed than for compilers. For example, some false negatives—calls that can in fact take place in some execution of the program, but which are omitted from the call graph—may be acceptable, depending on the understanding task at hand. In this article, we empirically show a consequence of this spectrum of requirements by comparing the C call graphs…

Empirically revisiting the test independence assumption

Sai Zhang, Darioush Jalali, Jochen Wuttke +4 more

Software · 11 Jul 2014 · cited 151× · DOI ↗ · more like this ·

In a test suite, all the test cases should be independent: no test should affect any other test’s result, and running the tests in any order should produce the same test results. Techniques such as test prioritization generally assume that the tests in a suite are independent. Test dependence is a little-studied phenomenon. This paper presents five results related to test dependence.

ArchJava: connecting software architecture to implementation

Jonathan Aldrich, Craig Chambers, David Notkin

Artificial Intelligence · 25 Jun 2003 · cited 136× · DOI ↗ · more like this ·

Automatic Inference of Structural Changes for Matching across Program Versions

Miryung Kim, David Notkin, Dan Grossman

Information Systems · May 2007 · cited 134× · DOI ↗ · more like this ·

Mapping code elements in one version of a program to corresponding code elements in another version is a fundamental building block for many software engineering tools. Existing tools that match code elements or identify structural changes - refactorings and API changes - between two versions of a program have two limitations that we overcome. First, existing tools cannot easily disambiguate among many potential matches or refactoring candidates. Second, it is difficult to use these tools' results for various software engineering tasks due to an unstructured representation of results. To overcome these limitations, our approach represents structural changes as a set of high-level change rules, automatically infers likely change rules and determines method-level matches based on the rules. By applying our tool to several open source projects, we show that our tool identifies matches that…

Lightweight lexical source model extraction

Gail C. Murphy, David Notkin

Information Systems · ACM Transactions on Software Engineering and Methodology · July 1996 · cited 132× · DOI ↗ · more like this ·

Software engineers maintaining an existing software system often depend on the mechanized extraction of information from system artifacts. Some useful kinds of information—source models—are well known: call graphs, file dependences, etc. Predicting every kind of source model that a software engineer may need is impossible. We have developed a lightweight approach for generating flexible and tolerant source model extractors from lexical specifications. The approach is lightweight in that the specifications are relatively small and easy to write. It is flexible in that there are few constraints on the kinds of artifacts from which source models are extracted (e.g., we can extract from source code, structured data files, documentation, etc.). It is tolerant in that there are few constraints on the condition of the artifacts. For example, we can extract from source that cannot necessarily…

An ethnographic study of copy and paste programming practices in OOPL

Miryung Kim, L. Bergman, Tatiana Lau +1 more

Information Systems · 2004 · cited 116× · DOI ↗ · more like this ·

Although programmers frequently copy and paste code when they develop software, implications of common copy and paste (C&P) usage patterns have not been studied previously. We have conducted an ethnographic study in order to understand programmers' C&P programming practices and discover opportunities to assist common C&P usage patterns. We observed programmers using an instrumented Eclipse IDE and then analyzed why and how they use C&P operations. Based on our analysis, we constructed a taxonomy of C&P usage patterns. This paper presents our taxonomy of C&P usage patterns and discusses our insights with examples drawn from our observations. From our insights, we propose a set of tools that both can reduce software maintenance problems incurred by C&P and can better support the intents of commonly used C&P scenarios.

Reengineering with reflexion models: a case study

Gail C. Murphy, David Notkin

Information Systems · Computer · 1997 · cited 105× · DOI ↗ · more like this ·

Reengineering large and complex software systems is often very costly. The article presents a reverse engineering technique and relates how a Microsoft engineer used it to aid an experimental reengineering of Excel-a product that comprises about 1.2 million lines of C code. The reflexion technique is designed to be lightweight and iterative. To use it, the user first defines a high-level structural model, then extracts a map of the source code and uses a set of computation tools to compare the two models. The approach lets software engineers effectively validate their high-level reasoning with information from the source code. The engineer in this case study-a developer with 10-plus years at Microsoft-specified and computed an initial reflexion model of Excel in a day and then spent four weeks iteratively refining it. He estimated that gaining the same degree of familiarity with the…

Program element matching for multi-version program analyses

Miryung Kim, David Notkin

Software · 22 May 2006 · cited 104× · DOI ↗ · more like this ·

Multi-version program analyses require that elements of one version of a program be mapped to the elements of other versions of that program. Matching program elements between two versions of a program is a fundamental building block for multi-version program analyses and other software evolution research such as profile propagation, regression testing, and software version merging.In this paper, we survey matching techniques that can be used for multi-version program analyses and evaluate them based on hypothetical change scenarios. This paper also lists challenges of the matching problem, identifies open problems, and proposes future directions.