Software engineering involves a lot of change as code artifacts are not only created once but maintained over time. In the last 25 years, major paradigms of program development have arisen – agile development with refactorings, software product lines, moving sequential code to multicore or cloud, etc. Each is centered on particular kinds of change; their conceptual foundations rely on transformations that (semi-) automate these changes. We are exploring how transformations can be placed at the center of software development in future IDEs, and when such a view can provide benefits over the traditional view. COPE, a Change-Oriented Programming Environment, looks at 5 activities: (1) analyze what changes programmers typically make and how they perceive, recall, and communicate changes, (2) automate transformations to make it easier to apply and script changes, (3) develop tools that compose and manipulate transformations to make it easier to reuse them, (4) integrate transformations with version control to pro- vide better ways for archiving and understanding changes, and (5) develop tools that infer higher-level transformations from lower-level changes. Characterizing software develop- ment in terms of transformations is an essential step to take software engineering from manual development to (semi-) automated development of software.

One of the most difficult parts of building automated refactorings is ensuring that they preserve behavior. This paper proposes a new technique to check for behavior preservation; we call this technique differential precondition checking. It is simple yet expressive enough to implement the most common refactorings, and the core algorithm runs in linear time. However, the main advantage is that a differential precondition checker can be placed in a library and reused in refactoring tools for many different languages; the core algorithm can be implemented in a way that is completely language independent. We have implemented a differential precondition checker and used it in refactoring tools for Fortran (Photran), PHP, and BC.

Type qualifier inference tools usually operate in batch mode and assume that the program must not be changed except to add the type qualifiers. In practice, programs must be changed to make them type-correct, and programmers must understand them. Cascade is an interactive type qualifier inference tool that is easy to implement and universal (i.e., it can work for any type qualifier system for which a checker is implemented). It shows that qualifier inference can achieve better results by involving programmers rather than relying solely on automation.

Modern integrated development environments (IDEs) make many software engineering tasks easier by providing automated programming support such as code completion and navigation. However, such support -- and therefore IDEs as a whole -- operate on one revision of the code at a time, and leave handling of code history to external tools or plugins, such as EGit for Eclipse. For example, when a method is removed from a class, developers can no longer find the method through code completion. This forces developers to manually switch across different revisions or resort to using external tools when they need to learn about previous code revisions.We propose a novel approach of adding a temporal dimension to IDEs, enabling code completion and navigation to operate on multiple revisions of code at a time. We previously introduced the idea of temporal code completion and navigation, and presented a vision for how that idea may be realized. This paper realizes that vision by implementing and evaluating a prototype tool called Tempura. We describe our algorithm for processing and indexing historical code information from repositories for Tempura, and demonstrate Tempura's scalability with three large Eclipse projects. We also evaluate Tempura's usability through a controlled user study. The study participants learned about the code history with more accuracy when using Tempura compared to EGit. Although the sample size was not large enough to provide strong statistical significance, the results show a promising outlook for our approach.

Modern Integrated Development Environments (IDEs) support many refactorings. Yet, programmers greatly underuse automated refactorings. Recent studies have applied traditional usability testing methodologies such as surveys, lab studies, and interviews to find the usability problems of refactoring tools. However, these methodologies can identify only certain kinds of usability problems. The critical incident technique (CIT) is a general methodology that uncovers usability problems by analyzing troubling user interactions. We adapt CIT to refactoring tools and show that alternate refactoring paths are indicators of the usability problems of refactoring tools. We define an alternate refactoring path as a sequence of user interactions that contains cancellations, reported messages, or repeated invocations of the refactoring tool. We evaluated our method on a large corpus of refactoring usage data, which we collected during a field study on 36 programmers over three months. This method revealed 15 usability problems, 13 of which were previously unknown. We reported these problems and proposed design improvements to Eclipse developers. The developers acknowledged all of the problems and have already fixed four of them. This result suggests that analyzing alternate paths is effective at discovering the usability problems of interactive program transformation (IPT) tools.

Identifying repetitive code changes benefits developers, tool builders, and researchers. Tool builders can automate the popular code changes, thus improving the productivity of developers. Researchers can better understand the practice of code evolution, advancing existing code assistance tools and benefiting developers even further. Unfortunately, existing research either predominantly uses coarse-grained Version Control System (VCS) snapshots as the primary source of code evolution data or considers only a small subset of program transformations of a single kind - refactorings. We present the first approach that identifies previously unknown frequent code change patterns from a fine-grained sequence of code changes. Our novel algorithm effectively handles challenges that distinguish continuous code change pattern mining from the existing data mining techniques. We evaluated our algorithm on 1,520 hours of code development collected from 23 developers, and showed that it is effective, useful, and scales to large amounts of data. We analyzed some of the mined code change patterns and discovered ten popular kinds of high-level program transformations. More than half of our 420 survey participants acknowledged that eight out of ten transformations are relevant to their programming activities.

Actor programs are concurrent programs where concurrent entities communicate asynchronously by exchanging messages. Testing actor programs is challenging because the order of message receives depends on the non-deterministic scheduler and because exploring all schedules does not scale to large programs. This paper presents Bita, a scalable, automatic approach for testing non-deterministic behavior of actor programs. The key idea is to generate and explore schedules that are likely to reveal concurrency bugs because these schedules increase the schedule coverage. We present three schedule coverage criteria for actor programs, an algorithm to generate feasible schedules that increase coverage, and a technique to force a program to comply with a schedule. Applying Bita to real-world actor programs implemented in Scala reveals eight previously unknown concurrency bugs, of which six have already been fixed by the developers. Furthermore, we show our approach to find bugs 122× faster than random scheduling, on average.

Bug patterns are coding idioms that may make the code less maintainable or turn into bugs in future. The state-of-the-art tools for detecting concurrency bug patterns (CBPs) perform simple, intraprocedural analyses. While this simplicity makes the analysis fast, it does not provide protection against CBPs that involve aliasing or multiple methods. This paper introduces a practical and extensible framework, Keshmesh, which employs advanced static analysis for detecting CBPs. Keshmesh builds upon the points-to analysis of WALA, a static analysis framework, and the user interface of FindBugs, a popular bug pattern detection tool. Keshmesh detects five CBPs using interprocedural analyses and fixes two of them. The challenges in automatic detection of these CBPs include reducing the rate of false positives, scaling to large projects, and accurate propagation of unsafe accesses along the call graph up to synchronization constructs. Keshmesh found 40 previously unknown CBP instances and only 12 false positives in six open-source projects. Programmers fixed 11 of the 20 issues we reported. These results show that Keshmesh is applicable to large projects, finds CBPs that programmers want to fix, and reports few false positives.

Refactoring is a disciplined technique for restructuring code to improve its readability and maintainability. Almost all modern integrated development environments (IDEs) offer built-in support for automated refactoring tools. However, the user interface for refactoring tools has remained largely unchanged from the menu and dialog approach introduced in the Smalltalk Refactoring Browser, the first automated refactoring tool, more than a decade ago. As the number of supported refactorings and their options increase, invoking and configuring these tools through the traditional methods have become increasingly unintuitive and inefficient. The contribution of this paper is a novel approach that eliminates the use of menus and dialogs altogether. We streamline the invocation and configuration process through direct manipulation of program elements via drag-and-drop. We implemented and evaluated this approach in our tool, Drag-and-Drop Refactoring (DNDRefactoring), which supports up to 12 of 23 refactorings in the Eclipse IDE. Empirical evaluation through surveys and controlled user studies demonstrates that our approach is intuitive, more efficient, and less error-prone compared to traditional methods available in IDEs today. Our results bolster the need for researchers and tool developers to rethink the design of future refactoring tools.

Mixing the actor model with other concurrency models in a single program can break the actor abstraction. This increases the chance of creating deadlocks and data races--two mistakes that are hard to make with actors. Furthermore, it prevents the use of many advanced testing, modeling, and verification tools for actors, as these require pure actor programs. This study is the first to point out the phenomenon of mixing concurrency models by Scala developers and to systematically identify the factors leading to it. We studied 15 large, mature, and actively maintained actor programs written in Scala and found that 80% of them mix the actor model with another concurrency model. Consequently, a large part of real-world actor programs does not use actors to their fullest advantage. Inspection of the programs and discussion with the developers reveal two reasons for mixing that can be influenced by researchers and library-builders: weaknesses in the actor library implementations, and shortcomings of the actor model itself.

Despite the enormous success that manual and automated refactoring has enjoyed during the last decade, we know little about the practice of refactoring. Understanding the refactoring practice is important for developers, refactoring tool builders, and researchers. Many previous approaches to study refactorings are based on comparing code snapshots, which is imprecise, incomplete, and does not allow answering research questions that involve time or compare manual and automated refactoring. We present the first extended empirical study that considers both manual and automated refactoring. This study is enabled by our algorithm, which infers refactorings from continuous changes. We implemented and applied this algorithm to the code evolution data collected from 23 developers working in their natural environment for 1,520 hours. Using a corpus of 5,371 refactorings, we reveal several new facts about manual and automated refactorings. For example, more than half of the refactorings were performed manually. The popularity of automated and manual refactorings differs. More than one third of the refactorings performed by developers are clustered in time. On average, 30% of the performed refactorings do not reach the Version Control System.

Recent studies suggest that programmers greatly underuse refactoring tools, especially for complex refactorings. Complex refactorings tend to be tedious and error-prone to perform by hand. To promote the use of refactoring tools for complex changes, we propose a new paradigm for automating refactorings called compositional refactoring. The key idea is to perform small, predictable changes using a tool and manually compose them into complex changes. This paradigm trades off some level of automation by higher predictability and control. We show that this paradigm is natural, because our analysis of programmers’ use of the Eclipse refactoring tool in the wild shows that they frequently batch and compose automated refactorings. We then show that programmers are receptive to this new paradigm through a survey of 100 respondents. Finally, we show that the compositional paradigm is effective through a controlled study of 13 professional programmers, comparing this paradigm to the existing wizard-based one.

Identifying repetitive code changes benefits developers, tool builders, and researchers. Tool builders can automate the popular code changes, thus improving the productivity of developers. Researchers would better understand the practice of code evolution, advancing existing code assistance tools even further. Developers would particularly benefit if such tools can learn and support repetitive code changes that are in progress. Unfortunately, the existing tools that aim at detecting frequent code change patterns predominantly focus on analyzing the static source code of an application rather than dynamic code changes, and thus, they can not learn from the changes on-the-fly. We present the first approach that identifies previously unknown frequent code change patterns from a continuous sequence of code changes. Our novel algorithm effectively handles two major challenges that distinguish continuous code change pattern mining from the existing data mining techniques: overlapping transactions and transactions containing multiple instances of the same item kind. We evaluated our algorithm on 1,520 hours of code development collected from 23 developers, and showed that it is effective, useful, and scales to big amounts of data. We analyzed some of the mined code change patterns and discovered ten popular kinds of high level program transformations.

The Transactions on Pattern Languages of Programming subline aims to publish papers on patterns and pattern languages as applied to software design, development, and use, throughout all phases of the

ABSTRACTC preprocessor directives are heavily used in C programs because they provide useful and even necessary additions to the C language. However, they are usually executed and discarded before any analysis is applied on C programs. In refactoring, preprocessor directives must be preserved through the whole process of parsing, analysis and transformation to retain editable yet correct source code. We propose a new preprocessing approach and special program representations that allow a program to be analyzed and transformed without losing its preprocessor directives, but treating them as first‐class program entities. These representations are essential for a correct refactoring tool. We also describe the challenges that preprocessor directives bring to refactoring and how the program representations that we propose solve those challenges. Finally, we give details of two refactorings and present some case studies with our successfully applied solution. Copyright © 2013 John Wiley & Sons, Ltd.

Emerging applications in the domains of recognition, mining and synthesis (RMS); image and video processing; data warehousing; and automatic financial trading admit a particular style of parallelism termed flow-based parallelism. To help developers exploit flow-based parallelism, popular parallel libraries such as Groovy's GPars, Intel's TBB Flow Graph and Microsoft's TPL Dataflow have begun introducing many new and useful constructs. However, to reap the benefits of such constructs, developers must first use them. This involves refactoring their existing sequential code to incorporate these constructs - a manual process that overwhelms even experts. To alleviate this burden, we introduce a set of novel analyses and transformations targeting flow-based parallelism. We implemented these ideas in JFlow, an interactive refactoring tool integrated into the Eclipse IDE. We used JFlow to parallelize seven applications: four from a previously known benchmark and three from a suite of large open source projects. JFlow, with minimal interaction from the developer, can successfully parallelize applications from the aforementioned domains with good performance (offering up to 3.45x speedup on a 4-core machine) and is fast enough to be used interactively as part of a developer's workflow.