Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we 1 Introduction 1 1.1 Overview of Our Data Collection and Analysis ' 1.2 Overview of Contributions 1.3 Overview of Dissertation Contents 2 Related Work 2.1 Program Comprehension 2.1.1 Cognitive Models 2.1.2 Informing Tool Design 2.1.3 Analysis of Questions 2.2 Empirical Studies of Change Tasks 2.3 Summary iii 73 6.2 Eclipse Search Results View 73 6.3 SHriMP and Relo Visualizations 84 6.4 Eclipse Call Hierarchy 6.5 Sample output from the diff command line tools 7.1 Mockup of a search tool illustrating results 7.2 Distribution of question occurrences across studies by category 103 vii Research Council of Canada (NSERC), IBM and Intel. viii Dedication To Christina Jolayne for her patient and enthusiastic support through far too many years of school. ix Chapter 1 subroutine/procedure invoked? Johnson and Erdem studied questions asked to experts on a newsgroup [47]. Similarly, little is known about how programmers answer their questions and the role of tools in that process. Our aim is to build on this body of existing work with the goal of providing an empirical foundation for tool design based on an exploration of what programmers need to understand and of how they use tools to discover that information. We focus, in particular, on what programmers need to understand about a code base while performing a nontrivial change task to a software system. To this end, we undertook two qualitative studies. In each of these studies we observed programmers making source changes to medium (20 KLOC) to large-sized (over 1 million LOC) code bases. Based on a systematic analysis of the data from We collected data from two studies: our first study was carried out in a laboratory setting [85] and the second study was carried out in an industrial work setting [84]. Both were observational studies to which we applied qualitative analysis. The participants in the first study (NI... N9) we refer to as newcomers as they were working on a code base that was new to them. All nine participants in the first study were computer science graduate students with varying amounts of previous development experience, including experience with the Java programming language. In this first study, pairs of programmers performed change tasks on a moderately sized open-source system assigned by the experimenter. We chose to study pairs of programmers because we believed that the discussion between the pair as they worked on the change task would allow us to learn what information they were looking for and why particular action...

Though many tools are available to help programmers working on change tasks, and several studies have been conducted to understand how programmers comprehend systems, little is known about the specific kinds of questions programmers ask when evolving a code base. To fill this gap we conducted two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a medium-sized code base. The other study involved industrial programmers working on their own change tasks on code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on how they go about discovering that information. Based on this analysis we catalog and categorize 44 different kinds of questions asked by our participants. We also describe important context for how those questions were answered by our participants, including their use of tools.

A development task related to a crosscutting concern is challenging because a developer can easily get lost when exploring scattered elements of code and the complex tangle of relationships between them. In this paper we present a source browsing tool that improves the developer's ability to work with crosscutting concerns by providing better support for exploring code. Our tool helps the developer to remain oriented while exploring and navigating across a code base. The cognitive burden placed on a developer is reduced by avoiding disorienting view switches and by providing an explicit representation of the exploration process in terms of exploration paths.

This dissertation shows that existing functional tests of software features can be used by a developer unfamiliar with the software system to identify source code relevant to those features as well as understand why the source code is relevant.There have been prior techniques to locate features in source code which can be roughly broken down into techniques that use static analysis and those that use dynamic analysis.Features, being behaviors of a system, are dynamic in nature. Therefore, this dissertation focuses on dynamic techniques, rather than the use static techniques.The dynamic techniques all require significant knowledge about the system before the technique can be useful. Furthermore, they all suffer in one or both of these respects: they make binary judgments about which source code artifacts relate to a feature without determining to what extent they relate (meaning that the feature must be precisely characterized, or else the technique will return inaccurate results), or they do not provide an idea of why a piece of code is relevant to a feature.Our technique of creating Dynamic Feature Traces improves upon previous work 1) by taking advantage of an existing test suite thereby reducing the amount of system knowledge necessary to use the technique, 2) by ranking the source code artifacts by how strongly they are related to the feature, and 3) by retaining some part of the execution trace of the test suite so that developers can understand why a piece of code is part of a feature. We show that our technique provides benefit over other techniques by applying it to existing software systems and comparing its results to an existing technique.ii

Abstract. We propose to use a logic meta-system as a general framework for aspect-oriented programming. We illustrate our approach with the implementation of a simpli ed version of the cool aspect language for expressing synchronization of Java programs. Using this case as an example we illustrate the principle of aspect-oriented l o gic meta programming and how it is useful for implementing weavers on the one hand and on the other hand also allows users of aop to ne-tune, extend and adapt an aspect language to their speci c needs.

Modern IDEs have an open-ended plugin architecture to allow customizability. However, developing a plugin is costly in terms of effort and expertise required by the customizer. We present a two-pronged approach that allows for open-ended customizations while keeping the customization cost low. First, we explicitly limit the portion of the design space targeted by the configuration mechanism. This reduces customization cost by simplifying the configuration interface. Second, we use a declarative programming language as our configuration language. This facilitates open-ended specification of behavior without burdening the user with operational details.

Writing correct AspectJ pointcuts is hard. This is partly because of the complexity of the pointcut language and partly because it requires understanding how a pointcut matches across the entire code base.In this thesis, we present algorithms that compute two kinds of useful information that can help AspectJ developers diagnose and fix potential problems with their pointcuts. First, we present an algorithm to compute almost matched join points. Second we present algorithms to compute explanations of why a pointcut does not match (or does match) a specific join point.We implemented two tools using these algorithms. The first is an offline tool that analyzes a code base and produces a comprehensive report. Using this tool, we were able to find several real problems in existing, medium-sized AspectJ code bases.The second tool is an Eclipse plugin called PointcutDoctor. PointcutDoctor is a natural extension of AJDT, the mainstream IDE for AspectJ. It provides developers easy access to the same information from within their already familiar development environment.

No abstract