Change-aware development environments can automatically record fine-grained code changes on a program and allow programmers to replay the recorded changes in chronological order. However, since they do not always need to replay all the code changes to investigate how a particular entity of the program has been changed, they often eliminate several code changes of no interest by manually skipping them in replaying. This skipping action is an obstacle that makes many programmers hesitate when they use existing replaying tools. This paper proposes a slicing mechanism that automatically removes manually skipped code changes from the whole history of past code changes and extracts only those necessary to build a particular class member of a Java program. In this mechanism, fine-grained code changes are represented by edit operations recorded on the source code of a program and dependencies among edit operations are formalized. The paper also presents a running tool that slices the operation history and replays its resulting slices. With this tool, programmers can avoid replaying nonessential edit operations for the construction of class members that they want to understand. Experimental results show that the tool offered improvements over conventional replaying tools with respect to the reduction of the number of edit operations needed to be examined and over history filtering tools with respect to the accuracy of edit operations to be replayed.

Developers often face difficulties while using APIs. API usage patterns can aid them in using APIs efficiently, which are extracted from source code stored in software repositories. Previous approaches have mined repositories to extract API usage patterns by simply applying data mining techniques to the collection of method invocations of API objects. In these approaches, respective functional roles of invoked methods within API objects are ignored. The functional role represents what type of purpose each method actually achieves, and a method has a specific predefined order of invocation in accordance with its role. Therefore, the simple application of conventional mining techniques fails to produce API usage patterns that are helpful for code completion. This paper proposes an improved approach that extracts API usage patterns at a higher abstraction level rather than directly mining the actual method invocations. It embraces a multilevel sequential mining technique and uses categorization of method invocations based on their functional roles. We have implemented a mining tool and an extended Eclipse's code completion facility with extracted API usage patterns. Evaluation results of this tool show that our approach improves existing code completion.

Recording source code changes comes to be well recognized as an effective means for understanding the evolution of existing software and making its future changes efficient. Therefore, modern integrated development environments (IDEs) tend to employ tools that record fine-grained textual changes of source code. However, there is still no satisfactory tool that accurately records textual changes. We propose ChangeMacroRecorder that automatically and silently records all textual changes of source code and in real time correlates those textual changes with actions causing them while a programmer is writing and modifying it on the Eclipse's Java editor. The improvement with respect to the accuracy of recorded textual changes enables both programmers and researchers to exactly understand how the source code was evolved. This paper presents detailed information on how ChangeMacroRecorder achieves the accurate recording of textual changes and demonstrates how accurate textual changes were recorded in our experiment consisting of nine programming tasks.

As network services become more diverse and powerful, service applications that perform such services are acquiring an ever-larger amount of complicated and changeable relationships. We present a network dependence graph (NDG) that captures both data and control flow relationships between components of service applications that work collaboratively. This graph is constructed based on analysis of both the behavior of each of the service applications and their configuration, which describes the device names they refer to, and allows network slicing to be implemented as a simple graph traversal. Network slicing is the extraction of necessary and minimum service components that may affect the execution of a specified service application; it helps a network manager to find the location of service faults lurking somewhere in the network. We also present a method for locating faults that uses network slicing and a system based on this method.

History data of edit operations are more beneficial than those stored in version control systems since they provide detailed information on how source code was changed. Meanwhile, a large number of recorded edit operations discourage developers and researchers from roughly understanding the changes. To assist with this task, it is desirable that they easily obtain traceability links for changed program elements over two source code snapshots before and after a code change. In this paper, we propose a graph representation called Operation History Graph (OHG), which presents code change information with such traceability links that are inferred from the history of edit operations. An OHG instance is generated by parsing any source code snapshot restored by edit histories and combining resultant abstract syntax trees (ASTs) into a single graph structure. To improve the performance of building graph instances, we avoided simply maintaining every program element. Any program element presenting the inner-structure of methods and non-changed elements are omitted. In addition, we adopted a lightweight static analysis for type name resolving to reduce required memory resource in the analysis while the accuracy of name resolving is preserved. Moreover, we assign a specific ID to each node and edge in the graph instance so that a part of the graph data can be separately stored and loaded on demand. These decisions make it feasible to build, manipulate, and store the graph with limited computer resources. To demonstrate the usefulness of the proposed operation history graph and verify whether detected traceability links are sufficient to reveal actual changes of program elements, we implemented tools to generate and manipulate OHG instances. The evaluation on graph generation performance shows that our tool can reduce the required computer resource as compared to another tool authors previously proposed. Moreover, the evaluation on traceability shows that OHG provides traceability links with sufficient accuracy as compared to the baseline approach using GumTree.

Recent IDEs have become more extensible tool platforms but do not concern themselves with how other tools running on them collaborate with each other. They compel developers to use proprietary representations or the classical abstract syntax tree (AST) to build source code tools. Although these representations contain sufficient information, they are neither portable nor extensible. This paper proposes a tool platform that manages commonly used, fined-grained, information about Java source code by using an XML representation. Our representation is suitable for developing tools which browse and manipulate actual source code, since the original code is annotated with tags based on its structure and retained within the tags. Additionally, it exposes information resulting from global semantic analysis, which is never provided by the typical AST. Our proposed platform allows the developers to extend the representation for the purpose of sharing or exchanging various kinds of information about the source code, and also enables them to build new tools by using existing XML utilities.

Understanding which refactoring transformations were performed is in demand in modern software constructions. Traditionally, many researchers have been tackling understanding code changes with history data derived from version control systems. In those studies, problems of the traditional approach are pointed out, such as entanglement of multiple changes. To alleviate the problems, operation histories on IDEs' code editors are available as a new source of software evolution data nowadays. By replaying such histories, we can investigate past code changes in a fine-grained level. However, the prior studies did not provide enough evidence of their effectiveness for detecting refactoring transformations. This paper describes an experiment in which participants detect refactoring transformations performed by other participants after investigating the code changes with an operation-replay tool and diff tools. The results show that both approaches have their respective factors that pose misunderstanding and overlooking of refactoring transformations. Two negative factors on divided operations and generated compound operations were observed in the operation-based approach, whereas all the negative factors resulted from three problems on tangling, shadowing, and out-of-order of code changes in the difference-based approach. This paper also shows seven concrete examples of participants' mistakes in both approaches. These findings give us hints for improving existing tools for understanding code changes and detecting refactoring transformations.