A Software Bill of Materials (SBOM) is becoming an essential tool for effective software dependency management. An SBOM is a list of components used in software, including details such as component names, versions, and licenses. Using SBOMs, developers can quickly identify software components and assess whether their software depends on vulnerable libraries. Numerous tools support software dependency management through SBOMs, which can be broadly categorized into two types: tools that generate SBOMs and tools that utilize SBOMs. A substantial collection of accurate SBOMs is required to evaluate tools that utilize SBOMs. However, there is no publicly available dataset specifically designed for this purpose, and research on SBOM consumption tools remains limited. In this paper, we present a dataset of SBOMs to address this gap. The dataset we constructed comprises 46 SBOMs generated from real-world Java projects, with plans to expand it to include a broader range of projects across various programming languages. Accurate and well-structured SBOMs enable researchers to evaluate the functionality of SBOM consumption tools and identify potential issues. We collected 3,271 Java projects from GitHub and generated SBOMs for 798 of them using Maven with an open-source SBOM generation tool. These SBOMs were refined through both automatic and manual corrections to ensure accuracy, currently resulting in 46 SBOMs that comply with the SPDX Lite profile, which defines minimal requirements tailored to practical workflows in industries. This process also revealed issues with the SBOM generation tools themselves. The dataset is publicly available on Zenodo (DOI: 10.5281/zenodo.14233414).

In recent years, Automated Program Repair (APR), which focuses on automatically fixing source code without human intervention, has become a hot topic in the field of software engineering, leading to the proposal of various automatic repair techniques. Additionally, Lapvikai et al. introduced a new software quality metric called “Autorepairability.” Autorepairability is a metric that indicates how easily bugs in the target source code can be fixed using APR techniques. By utilizing Autorepairability, it becomes possible to pre-check whether the program repair techniques will work effectively on the target software and to perform refactoring to improve Autorepairability. However, in the past two to three years, program repair using large language models (LLMs) has become more prevalent, and several studies have revealed that these models exhibit superior repair capabilities compared to traditional APR techniques. In this study, we applied Autorepairability to compare the performance of multiple APR techniques. Specifically, we measured and compared Autorepairability using ChatGPT and Gemini, which are representative large language models, as well as kGenProg, a traditional APR technique. The results demonstrated that Gemini exhibited higher repair capabilities compared to both ChatGPT and the traditional APR technique kGenProg. The five code functionalities that Gemini offers higher Autorepairability scores than ChatGPT include (1) geographic and mathematic operations, (2) validation, comparison, and searching operations, (3) data conversion operations, (4) data extraction and comparison operations, and (5) encoding operations.

Avstract-A code clone is a code snippet identical or similar to another in the source code. The presence of code clones causes the spread of bugs, which means that efficient code clone detection and appropriate refactoring are necessary. Code clone detection using large language models (in short, LLMs) is more accurate than conventional tools that do not use LLMs for code clones with low syntactic similarity. However, even for LLM-based clone detection tools, detecting such code clones is still difficult, and there is room for improvement. In this study, we improved the accuracy of LLM-based code clone detection through fine-tuning using FEMPDataset. The results showed that our fine-tuning improved the accuracy of code clone detection.

Spectrum-Based Fault Localization (in short, SBFL) is one of the popular techniques to localize faulty statements of a given program. SBFL utilizes the information about which statements are executed in each of the successful or failed test cases. Even if multiple programs have the same functionality, the accuracy of SBFL can differ due to their structural variations. Thus, changing program structures to be suitable for SBFL may improve the accuracy of fault localization while maintaining functionality. In previous research by Sasaki et al, SBFL-Score was proposed to discover program structures suitable for SBFL. SBFL-Score is one of the metrics used to evaluate how well a program is suitable for SBFL. Furthermore, the previous research measured SBFL-Scores for pairs of programs with different structures but the same functionality, and obtained a program structure suitable for SBFL. However, a small number of programs and a small number of mutation operators used in the experiments were shortcomings. Thus, in this study, we conducted an experiment with approximately 36 times more programs and about 2.5 times more mutation operators than in the previous research. As a result of this experiment, we identified four new program structures suitable for SBFL.

Current software development takes advantage of many external libraries, but it entails security and copyright risks. While the use of the Software Bill of Materials (SBOM) has been encouraged to cope with this problem, its adoption is still insufficient. In this research, we analyzed the challenges that developers faced in practicing SBOM use by examining questions about SBOM utilization on Stack Overflow, a Q&A site for developers. As a result, we found that (1) the proportion of resolved questions about SBOM use is 15.0% which is extremely low, (2) the number of new questions has increased steadily from 2020 to 2023, and (3) SBOM users have three major challenges on SBOM tools.

Currently, many competitive programming contests have been held. These contests are composed of several problems of a wide range of difficulty levels. Novice programmers must approach problems based on their experience and levels to avoid losing confidence and motivation to learn programming skills. In some programming contests, the difficulty level of a problem is given as a numerical value. However, each contest site assigns difficulty levels based on its criteria, making comparing levels among two or more contest sites impossible. This study proposes a method to estimate the difficulty level from the problem description and example solution information. Specifically, we attempted to estimate the difficulty of the problems using GPT-3.5 Turbo, which was fine-tuned with the problem descriptions and example solutions. The experiment was conducted on the fine-tuned GPT-3.5 Turbo under five conditions to evaluate the performance of difficulty estimation. As a result, a model that was fine-tuned with problem descriptions and estimated difficulty from the problem description had the best performance. In addition, the performance of the model fine-tuned with problem descriptions only was better than that of the model fine-tuned with problem descriptions and example solutions.

Libraries have become integral to modern software development, yet their management often falls short, resulting in issues such as delayed responses to vulnerabilities. To address these issues, the use of a Software Bill of Materials (SBOM) is recommended. Despite the recommendation, there is a lack of tools supporting software management using SBOM. In this paper, we present “Osmy”, a tool designed to facilitate effective software management using SBOM in the SPDX format-one of the major SBOM formats. Osmy is designed to simplify and streamline SBOM-based software management for end users. It automates vulnerability assessment and file integrity verification, operating periodically to ensure continuous protection. Users receive timely notification of any identified issues, ensuring a proactive approach to software security. Osmy is available at https://github.com/higolab/Osmy.

Currently, research on automated program repair (in short, APR) is actively being conducted. APR techniques have been applied to many bugs in open-source software, but the probability of a successful fix is not very high. The authors consider that not only should APR techniques be developed, but software systems should be developed so that bugs can be easily fixed with APR techniques. In this paper, we propose autorepairability, a new characteristic of software quality, that shows how effective automated program repair techniques are for a specific code fragment, file, or project. We also show an approach to automatically measure autorepairability from the source code of a target project, and present experimental results on 1,282 Java method pairs. The use of autorepairability allows many studies to be conducted. For example, research on the development process for developing software systems with high autorepairability and research on refactoring, which transforms software with low autorepairability into software systems with high autorepairability, will be possible.

Legacy systems pose significant challenges to companies. Software modernization approaches have been proposed to address this issue. However, a lack of standardization and reliance on ad hoc processes often lead to software modernization failures. Incremental modernization, a strategy that improves software systems in a step-by-step manner rather than attempting to simultaneously overhaul the entire system, aims to mitigate the risk of failure. However, this approach can increase costs owing to the complexity of integrating legacy and modernized products. In this paper, we present a case study that employs a cost-benefit estimation analysis in a large-scale industrial project that underwent incremental modernization in the past. We compare the actual and estimated cost-benefit values in the context of incremental modernization. As a result, we confirmed that the cost estimates were valid, but we could not judge whether the benefit estimates were valid.

Over the years, Stack Overflow (SO) has accumulated numerous code snippets, with developers going to SO for problem solutions and code references. However, in the case of the Python programming language, Python 3 is not necessarily backward compatible with Python 2. The major implication of this versioning problem is that code written in Python 2 may not be interpreted by Python 3 without modifications. This issue may affect the usability of Python code snippets on SO. We investigate how many Python code snippets on SO suffer from version compatibility issues, and find that about 10% of the snippets exhibit this problem. Moreover, of the code snippets that are interpretable only by Python 2 or Python 3, less than 17% are tagged with the Python version.In this paper, we present a Chrome extension called PyVerDetector. This extension allows the user to select a given version of Python and verifies whether the code snippets on a given SO question are compatible with the user’s selected Python version, providing error messages if not. The tool parses snippets and can determine versioning errors due to differences in syntax and also provides the user with a list of Python versions capable of interpreting each code snippet.

Since programming languages offer a wide variety of grammers, desired functions can be implemented in a variety of ways. We consider that there is a large amount of source code that has different implementations of the same functions, and that those can be compiled into a dataset useful for various research in software engineering. In this study, we construct a dataset of functionally equivalent Java methods from about 36 million lines of source code. The constructed dataset is available at https://zenodo.org/record/5912689.

Debugging is a costly process in software development, and computer-aided debugging is expected to reduce the cost. In debugging, fault localization is used to identify the location of potentially faulty code. Spectrum-based fault localization (SBFL) identifies program statements that contain faults based on program spectra collected during the execution of the test cases. Conventional SBFL treats all test cases as having equal importance. A weighting technique that assigns importance to test cases based on the similarity of program spectra (where higher similarity indicates higher importance) has been proposed. However, this technique does not significantly improve fault localization accuracy. We attribute this lack of improvement to the presence of sequential program statements, which negatively affect the weighting. In this study, we apply blocking and the weighting of spectra to improve accuracy. We conduct experiments to compare the proposed technique with conventional SBFL and a recent SBFL technique. We show that the proposed technique identifies faulty program statements with higher accuracy than previous SBFL techniques. Weighting based on the similarity of spectra after blocking is thus effective.

End-to-end test automation is critical in modern web application development. However, test automation techniques used in industry face challenges in implementing and maintaining test scripts. It is difficult to determine and maintain the locators needed by test scripts to identify web elements on web pages. The reason is that locators depend on the metadata of web elements and the structure of each web page. One effective way to solve such a problem of locators is to allow test cases written in natural language to be executed without test scripts. In this study, we propose a technique to identify web elements that should be operated on a web page by interpreting natural-language-like test cases. The test cases are written in a domain-specific language that independents on the metadata of web elements and the structural information of web pages. We leverage natural language processing techniques to understand the semantics of web elements. We also create heuristic search algorithms to explore web pages and find promising test procedures. To evaluate the proposed technique, we applied it to test cases for two open-source web applications. The experimental results show that our technique was able to successfully identify about 94% of web elements to be operated in the test cases. Our approach also succeeded in identifying all the web elements that were operated in 68% of the test cases.

In the field of software development, version control systems such as Git are imperative tools that help software teams manage source code. Git can detect a change history of each file individually. Even if a file was renamed in the past, Git can identify and track the before renamed file based on content similarities, which are calculated as the ratio of lines that match pre- and post-change files to the total number of lines. However, line-based comparison techniques do not consider source code structures and have coarse granularity, which can result in misidentifying pre-change files and tracking interruptions. To resolve these problems, this paper proposes a technique that calculates file content similarities using source code differences based on an abstract syntax tree. In experiments conducted on 197 open source Java-based projects, we found that the number of rename detections increased 3.3 %, and that, on average, our technique tracked commits 1.37 times more frequently than previous technique. We also measured accuracy levels and found that the maximum F - measure was 0.943, which is higher than the 0.926 maximum value of the line-based technique.

In software development, source code is repeatedly changed due to various reasons. Similar code changes are called change patterns. Identifying change patterns is useful to support software development in a variety of ways. For example, change patterns can be used to collect ingredients for code completion or automated program repair. Many research studies have proposed various techniques that detect change patterns. For example, Negara et al. proposed a technique that derives change patterns from the edit scripts. Negara's technique can detect fine-grained change patterns, but we consider that there is room to improve their technique. We found that Negara's technique occasionally generates change patterns from structurally-different changes, and we also uncovered that the reason why such change patterns are generated is that their technique performs text comparisons in matching changes. In this study, we propose a new change mining technique to detect change patterns only from structurally-identical changes by taking into account the structure of the abstract syntax trees. We implemented the proposed technique as a tool, TC2P, and we compared it with Negara's technique. As a result, we confirmed that TC2P was not only able to detect change patterns more adequately than the prior technique but also to detect change patterns that were not detected by the prior technique.

Automated program generation (APG) is a concept of automatically making a computer program. Toward this goal, transferring automated program repair (APR) to APG can be considered. APR modifies the buggy input source code to pass all test cases. APG regards empty source code as initially failing all test cases, i.e., containing multiple bugs. Search-based APR repeatedly generates program variants and evaluates them. Many traditional APR systems evaluate the fitness of variants based on the number of passing test cases. However, when source code contains multiple bugs, this fitness function lacks the expressive power of variants. In this paper, we propose the application of a multi-objective genetic algorithm to APR in order to improve efficiency. We also propose a new crossover method that combines two variants with complementary test results, taking advantage of the high expressive power of multi-objective genetic algorithms for evaluation. We tested the effectiveness of the proposed method on competitive programming tasks. The obtained results showed significant differences in the number of successful trials and the required generation time.

End-to-end test automation is important in modern web application development. However, existing test automation techniques have challenges in implementing and maintaining test scripts. It is difficult to keep correct locators, which test scripts require to identify web elements on web pages. The reason is that locators depend on the metadata in web elements or the structure of each web page. One efficient way to solve the problem of locators is to make test cases written in natural language executable without test scripts. As the first step of script-free testing, we propose a technique to identify web elements to be operated and to determine test procedures by interpreting test cases. The test cases are written in a domain-specific language without relying on the metadata of web elements or the structural information of web pages. We leverage natural language processing techniques to understand the semantics of web elements. We also create heuristic search algorithms to find promising test procedures. To evaluate our proposed technique, we applied it to two open-source web applications. The experimental results show that our technique successfully identified 94% of web elements to be operated in the test cases.

A code clone (in short, clone) is a code fragment that is identical or similar to other code fragments in source code. Clones generated by a large number of changes to copy-and-pasted code fragments are called large-variance (modifications are scattered) or large-gap (modifications are in one place) clones. It is difficult for general clone detection techniques to detect such clones and thus specialized techniques are necessary. In addition, with the rapid growth of software development, scalable clone detectors that can detect clones in large codebases are required. However, there are no existing techniques for quickly detecting large-variance or large-gap clones in large codebases. In this paper, we propose a scalable clone detection technique that can detect large-variance clones from large codebases and describe its implementation, called NIL. NIL is a token-based clone detector that efficiently identifies clone candidates using an N-gram representation of token sequences and an inverted index. Then, NIL verifies the clone candidates by measuring their similarity based on the longest common subsequence between their token sequences. We evaluate NIL in terms of large- variance clone detection accuracy, general Type-1, Type-2, and Type- 3 clone detection accuracy, and scalability. Our experimental results show that NIL has higher accuracy in terms of large-variance clone detection, equivalent accuracy in terms of general clone detection, and the shortest execution time for inputs of various sizes (1–250 MLOC) compared to existing state-of-the-art tools.

Bug prediction is expected to reduce the cost of quality assurance. To build a reliable bug prediction model, we should use realistic settings that satisfy all three of the following conditions. (1) We should build a dataset in a way that allows us to evaluate the prediction performance of the model correctly. (2) We should adopt the optimal granularity of bug prediction to minimize the cost of quality assurance. (3) We should use a dependent variable that correctly represents the presence or absence of bugs in the software modules to be predicted. However, no research has been conducted on bug prediction models built under the above realistic settings. Consequently, we established the following two objectives in this research. (1) We experimentally evaluate the prediction performance of bug prediction models built under realistic settings. (2) We propose techniques to improve the prediction performance of bug prediction models built under realistic settings. The first objective has now been achieved. Our experimental results show that the F-Measure of the bug prediction models built under realistic settings is only 0.19. Thus, there are still some issues to be solved to build a high-performance bug prediction model under realistic settings.

Many programming languages have a system of garbage collection to automate memory management. Problems such as unexpected memory leak still may occur due to the automation of memory management. Weak reference has been proposed as a solution to such problems. However, the use of weak reference often requires consideration of memory release timing, which is difficult for developers. In this study, we investigate the use of weak reference on open source projects. More concretely, we investigated the domain of software projects where the weak reference was used, the timing of the introduction of the weak reference, the usage method, the presence or absence of the test code for weak reference, and the case of failure to introduce weak reference in the Java language. The survey showed that weak references were used in 73 repositories, about one-third of the total 202 repositories, and that weak references were most common in test code.

A code clone (clone) is known as one of the factors that makes software maintenance difficult. Thus, in software maintenance, clone modification is essential. An existing study proposed a tool that notifies developers of information about clone changes so that the developers can modify clones efficiently. However, the existing tool is premised on regular execution and not designed to be triggered by external factors except for time. Hence, the existing tool is difficult to be executed triggered by development workflow, such as modifying source code or merging branches, and we think this causes some issues. Consequently, in this study, we propose a new clone modification support technique aimed to integrate into pull request (PR) based development for solving those issues. The proposed technique detects code fragments that need modifications by tracking clones at the time of creating PRs. Moreover, we made three improvements for more accurate clone change tracking. Additionally, we implemented the proposed technique as a software tool, CLIONE. To evaluate CLIONE, we investigated the proportion of PRs in which clones have been modified non-simultaneously, and also we compared the results of clone change tracking with the existing tool. As a result, 11.9%~30.4% of PRs included non-simultaneously modified clones, and we confirmed that CLIONE was able to track clone changes more accurately than the existing tool. CLIONE is available at https://github.com/T45K/CLIONE.

Developers occasionally conduct some source code changes that do not affect program behavior. We call such changes nonbehavioral changes. In this research, we propose a technique for determining whether a given commit includes only nonbehavioral changes or not by checking the differences of bytecode on the commit. If the bytecode is not affected by the commit, the proposed technique determines that the commit includes only nonbehavioral changes. As a result of experiments on six Java open source projects, out of the commits in which Java source files were changed, the commits of 8.6~22.4% consisted of only nonbehavioral changes. We also found new 25 patterns of nonbehavioral changes compared to a previous study.

Spectrum-Based Fault Localization (in short, SBFL) is one of the popular techniques to localize faulty code fragments of a given program. SBFL utilizes the information about which statements are executed by each of the success or failure test cases. There are various implementation ways for the same functionality if we use high-level programming languages. The authors consider that differences in these implementation ways may affect the efficiency of localizing faults using SBFL. In this paper, we define a characteristic to what extent a program is suitable for SBFL as SBFL-Suitability, and we propose a technique for measuring SBFL-Suitability. The proposed technique generates many slightly-variant programs from a given program with Mutation Testing, and then it measures how accurately SBFL detects the changed program statements in the variant programs. We conducted an experiment to investigate how SBFL-Suitability differs depending on the differences in source code structures. As a result, we found that (1) the fewer statements in the same nesting level, the higher SBFL-Suitability tends to be, and (2) the presence of Early Return improves SBFL-Suitability.

In software development, developers often need to understand source code differences in their activities. GumTree is a tool that detects tree-based source code differences. GumTree constructs abstract syntax trees from the source code before and after a given change, and then, it identifies inserted/deleted/moved subtrees and updated nodes. Source code differences are detected based on the four kinds of information in GumTree. However, GumTree calculates the difference for each file individually, so that it cannot detect moves of code fragments across files. In this research, we propose (1) to construct a single abstract syntax tree from all source files included in a project and (2) to perform a staged tree matching to detect across-file code moves efficiently and accurately. We have already conducted a pilot experiment on open source projects with our technique. As a result, we were able to detect code moves across files in all the projects, and the number of such code moves was 76,600 in total.

The sufficiency of test cases is essential for spectrum-based fault localization (in short, SBFL). If a given set of test cases is not sufficient, SBFL does not work. In such a case, we can improve the reliability of SBFL by adding new test cases. However, adding many test cases without considering their properties is not appropriate in the context of automated program repair (in short, APR). For example, in the case of GenProg, which is the most famous APR tool, all the test cases related to the bug module are executed for each of the mutated programs. Execution results of test cases are used for checking whether they pass all the test cases and inferring faulty statements for a given bug. Thus, in the context of APR, it is important to add necessary minimum test cases to improve the accuracy of SBFL. In this paper, we propose three strategies for selecting some test cases from a large number of automatically-generated test cases. We conducted a small experiment on bug dataset Defect4J and confirmed that the accuracy of SBFL was improved for 56.3% of target bugs while the accuracy was decreased for 17.3% in the case of the best strategy. We also confirmed that the increase of the execution time was suppressed to 1.5 seconds at the median.

Abstract Finding and fixing buggy code is an important and cost-intensive maintenance task, and static analysis (SA) is one of the methods developers use to perform it. SA tools warn developers about potential bugs by scanning their source code for commonly occurring bug patterns, thus giving those developers opportunities to fix the warnings (potential bugs) before they release the software. Typically, SA tools scan for general bug patterns that are common to any software project (such as null pointer dereference), and not for project specific patterns. However, past research has pointed to this lack of customizability as a severe limiting issue in SA. Accordingly, in this paper, we propose an approach called , which is based on statically analyzing changes across the development history of a project, as a means to identify project-specific bug patterns. Furthermore, the bug patterns identified by our tool do not relate to just one developer or one specific commit, they reflect the project as a whole and compliment the warnings from other SA tools that identify general bug patterns. Herein, we report on the application of our implemented tool and approach to four Java projects: , , , and . The results obtained show that our tool could detect 19 project specific bug patterns across those four projects. Next, through manual analysis, we determined that six of those change patterns were actual bugs and submitted pull requests based on those bug patterns. As a result, five of the pull requests were merged.

Method-level historical information is useful in various research on mining software repositories such as fault-prone module detection or evolutionary coupling identification. An existing technique named Historage converts a Git repository of a Java project to a finer-grained one. In a finer-grained repository, each Java method exists as a single file. Treating Java methods as files has an advantage, which is that Java methods can be tracked with Git mechanisms. The biggest benefit of tracking methods with Git mechanisms is that it can easily connect with any other tools and techniques build on Git infrastructure. However, Historage’s tracking has an issue of accuracy, especially on small methods. More concretely, in the case that a small method is renamed or moved to another class, Historage has a limited capability to track the method. In this paper, we propose a new technique, FinerGit, to improve the trackability of Java methods with Git mechanisms. We implement FinerGit as a system and apply it to 182 open source software projects, which include 1,768K methods in total. The experimental results show that our tool has a higher capability of tracking methods in the case that methods are renamed or moved to other classes.

A code clone (in short, clone) is a code fragment that is identical or similar to other code fragments in source code. The presence of clone is known as bad smell, which is phenomena of source code to be refactored. A motivation of refactoring (merging) clones is to reduce the size of source code. An existing study proposed a technique to estimate reduced lines of code by merging clones; however, there are two issues in the existing technique: (1) the existing technique does not consider the refactorability of clones in spite that it is difficult or even impossible to merge some clones due to the limitation of programming languages; (2) in the case that multiple clones are overlapping, the existing technique only considers one of them can be merged. Due to the above issues, estimated reducible LoC is occasionally different from the actual number. Consequently, in this research, we propose a new technique to calculate a reducible LoC. The proposed technique is free from the two issues, and it calculates a reducible LoC fully automatically. The proposed technique performs a loop processing of (a) detecting clones, (b) merging them, (c) compiling the edited source files, and (d) testing them. After finishing the loop, reducible LoC is calculated from the edited source files. This paper also includes comparison results of the proposed technique and the existing one. In the comparisons, we confirmed that a reducible LoC which was calculated with considering refactorability is 25% of a reducible LoC which was estimated without considering refactorability. We also confirmed that the proposed technique was able to merge clones that were not counted in the existing technique.

Programming education focusing on the correctness of program behavior is often conducted with automated testing. However, it is difficult to instruct students about internal program quality since automated testing confirms only the external behavior of the program. Although there are a lot of quality measuring tools, results in these tools are so detailed or complicated that students cannot handle them. Besides, these tools do not give explicit criteria to judge the quality of the given program, thus students cannot figure out how high their program quality is. As a result, using these tools does not lead to improving the program quality. In this paper, we propose an educational method in which visualize the program quality by introducing a concept called achievement. We also introduce an implemented prototype system, Ave, to realize the proposed method.

Daylight saving time (DST) is observed in many countries and regions. DST is not considered on some software systems at the beginning of their developments, for example, software systems developed in regions where DST is not observed. However, such systems may have to consider DST at the requests of their users. Before now, there has been no study about the impacts of DST on software development. In this paper, we study the impacts of DST on software development by mining the repositories on GitHub. We analyze the date when the code related to DST is changed, and we analyze the regions where the developers applied the changes live. Furthermore, we classify the changes into some patterns.

On development using a version control system, understanding differences of source code is important. Edit scripts (in short, ES) represent differences between two versions of source code. One of the tools generating ESs is GumTree. GumTree takes two versions of source code as input and generates an ES consisting of insert, delete, update and move nodes of abstract syntax tree (in short, AST). However, the accuracy of move and update actions generated by GumTree is insufficient, which makes ESs more difficult to understand. A reason why the accuracy is insufficient is that GumTree generates ESs from only information of AST. Thus, in this research, we propose to generate easier-to-understand ESs by using not only structures of AST but also information of line differences. To evaluate our methodology, we applied it to some open source software, and we confirmed that ESs generated by our methodology are more helpful to understand the differences of source code than GumTree.

Automated program repair (in short, APR) techniques that utilize genetic algorithm (in short, GA) have a capability of repairing programs even if the programs require multiple code fragments to be changed. Those techniques repeat program generation, program evaluation, and program selection until a generated program passes all given test cases. Those techniques occasionally generate a large number of programs before a repaired program is generated. Thus, it is difficult to understand how an input program is evolved in the loop processing of genetic algorithm. In this paper, we are inspired by genealogy and propose a new technique to visualize program evolution in the process of automated program repair. We have implemented the proposed technique as a software tool for kGenProg, which is one of GA-based APR tools. We evaluated the proposed technique with the developers of kGenProg. In the evaluation, the developers found latent issues in kGenProg's processing and came up with new ideas to improve program generation. From those results, we conclude that our visualization is useful to understand program evolution in the APR process.

Browser-based volunteer computing (BBVC) is one of the distributed computing paradigms, attracting researchers' and developers' attention for its portability and extraordinary potential of computing power. However, BBVC still has two significant challenges: low programmability and performance. These challenges are a heavy burden for users and prevent BBVC from wide-spreading. In this paper, we propose a novel BBVC framework to solve the challenges by using MapReduce and WebAssembly. Our framework reduces the total execution time by 64% compared with a traditional BBVC mechanism. We also show a practical scenario and its performance.

In this paper, we introduce our tool, kGenProg, which is a new automated program repair system. kGenProg has several remarkable features. Thanks to the features, kGenProg got achieved high performance, high Extensibility, and high portability.

Refactoring evaluation is a challenging research topic because right and wrong of refactoring depend on various aspects of development context such as developers' skills, development cost, deadline and so on. Many techniques have been proposed to evaluate refactoring objectively. However, those techniques do not consider individual contexts of software development. Currently, the authors are trying to evaluate refactoring automatically and objectively with considering development contexts. In this paper, we propose to evaluate refactoring with code naturalness. Our technique is based on a hypothesis: if a given refactoring raises the naturalness of existing code, the refactoring is beneficial. In this paper, we also report our pilot study on open source software.

Recently, a variety of studies have been conducted on source code analysis. If auto-generated code is included in the target source code, it is usually removed in a preprocessing phase because the presence of auto-generated code may have negative effects on source code analysis. A straightforward way to remove auto-generated code is searching special comments that are included in the files of auto-generated code. However, it becomes impossible to identify auto-generated code with the way if such special comments have disappeared for some reasons. It is obvious that it takes too much effort to see source files one by one manually. In this paper, we propose a new technique to identify auto-generated code by using the naturalness of auto-generated code. We used a golden set that includes thousands of hand-made source files and source files generated by four kinds of compiler-compilers. Through the evaluation with the dataset, we confirmed that our technique was able to identify auto-generated code with over 99% precision and recall for all the cases.

Automated program repair (in short, APR) has been attracting much attention. A variety of APR techniques have been proposed, and they have been evaluated with actual bugs in open source software. Currently, the authors are trying to introduce APR techniques to industrial software development (in short, ISD) to reduce development cost drastically. However, at this moment, there are no studies that report evaluations of APR techniques on ISD. In this paper, we report our ongoing application of APR techniques to ISD and discuss some barriers that we found on the application.

When we use code repositories, each commit should include code changes for only a single task and code changes for a single task should not be scattered over multiple commits. There are many studies on the former violation-often referred to as tangled commits- but the latter violation has been out of scope for MSR research. In this paper, we firstly investigate how much and what kinds of inappropriately partitioned commits in Java projects. Then, we propose a simple technique to detect such commits automatically. We also report evaluation results of the proposed technique.

Each commit in repositories of version control systems should include code changes for only a single task. However, in real repositories, there are many commits for multiple tasks and tasks split into multiple commits. We call the latter split commits. In this research, we firstly investigate how many and what kinds of split commits are included in repositories. Then, we classify the found split commits into three categories. Based on the classification, we propose a new technique to detect split commits automatically. This is the first research that proposes a technique to detect split commits. To evaluate the proposed technique, we apply it to repositories of two open source software. The results show that the proposed technique detects split commits with high accuracy (precision is 0.8 and F-measure is 0.7).

Refactoring is an important technique to improve maintainability of software, and developers often use this technique during a development process. Before now, researchers have proposed some techniques finding refactoring opportunities for developers. Finding refactoring opportunities means identifying locations to be refactored. However, there are no specific criteria for developers to determine where they should refactor because the criteria differ from project to project and from developer to developer. In this study, we propose a technique to find refactoring opportunities in source code by using machine learning techniques. Machine learning techniques enable to flexibly find refactoring opportunities by the characteristics of target projects and developers. Our proposed technique learns information on the features of refactorings conducted in the past. Then, based on this information, it suggests some refactorings on given the source code to developers. We investigated three research questions with five open source projects. As a result, we confirmed that the proposed technique was able to find refactorings with high accuracy.

Automated program repair (in short, APR) is a truly desired technique because it can reduce debugging costs drastically. A well-known technique in APR is a reuse-based approach, which inserts existing program statements in a given program to suspicious code for an exposed bug. Some reports show the reuse-based approach was able to fix many bugs in open source software. However, the existing approach often takes very long time to fix bugs. Its main factor is that so many variant programs are generated by insertions and so many test cases are executed for the variant programs before a fixed program is generated. In order to shorten fixing time with the reuse-based approach, a fixed program must be generated much more efficiently. In this paper, we propose two strategies to generate a fixed program more efficiently. We also implement the two strategies and confirm that there are real bugs which the two strategies contribute to shortening fixing time.

When we measure code metrics or analyze source code, code normalization is occasionally performed as a preprocessing. Code normalization means removing untargeted program elements, formatting source code, or transforming source code with specific rules. Code normalization makes measurement and analysis results more significant. Existing code normalization mainly targets program elements not influencing program behavior (e.g., code comments and blank lines) or program tokens (e.g., variable names and literals). In this paper, we propose a new code normalization technique targeting program structure. Our proposed technique transforms a complex program statement to simple ones. We call this transformation flattening. By flattening code, we can obtain source code including only simple program statements. As applications of the code flattening, we report how it changes LOC metric and clone detection results.

In software development, there are many situations in which developers need to understand given source code changes in detail. Until now, a variety of techniques have been proposed to support understanding source code changes. Tree-based differencing techniques are expected to have better understandability than text-based ones, which are widely used nowadays (e.g., diff in Unix). In this paper, we propose to consider copy-and-paste as a kind of editing action forming tree-based edit script, which is an editing sequence that transforms a tree to another one. Software developers often perform copy- and-paste when they are writing source code. Introducing copy- and-paste action into edit script contributes to not only making simpler (more easily understandable) edit scripts but also making edit scripts closer to developers' actual editing sequences. We conducted experiments on an open dataset. As a result, we confirmed that our technique made edit scripts shorter for 18% of the code changes with a little more computational time. For the other 82% code changes, our technique generated the same edit scripts as an existing technique. We also confirmed that our technique provided more helpful visualizations.

It is generally said that we should not perform code changes for multiple tasks in a single commit. Such code changes are called tangled ones. Committing tangled changes is harmful to developers. For example, it is costly to merge a part of tangled changes with other commits. Moreover, the presence of such tangled changes hinders analyzing code repositories. That is because most of the mining software repository approaches are designed under the assumption that every commit includes only changes for a single task. In this paper, we propose a technique which informs developers that they are about to commit tangled changes. The technique also suggests how to split a given commit into multiple commits by using past code changes. The proposed technique allows developers to determine whether they accept the suggestion or commit as it stands. By providing such support to developers, they can avoid committing tangled changes.

Automated program repair is a way to reduce costs on program debuggingto a large extent. Repair techniques using genetic programming havebeen attracting much attention. They were applied to actual softwaresystems and they were able to fix several dozen of actual faults. However, programs generated by such techniques often include some sourcecode changes not related to fixing a given fault even if they pass allgiven test cases. Furthermore, some researchers found that suchtechniques occasionally induce new faults which are not covered byexisting test cases. The reason why those problems arise is that suchtechniques consider only given test cases. On the other hand, developers consider program behaviors not covered by test cases. Thus, those problems arise less frequently in programs modified by developers. Consequently, the authors suppose that if we make automated programmodifications close to developers' ones, we may be able to relieve thoseproblems. At this moment, there is no research study investigatingdifferences between automated modifications and developers' ones. Inthis paper, we compare GenProg's modifications with developers'ones for the same faults. As a result, we found that developers tend to(1) change more different functions, (2) change control flows in sourcecode, and (3) add/delete more code lines.

Methods not having side effects (pure methods) are beneficial in some situations. For example, data race does not occur among pure methods in multi-thread programs. Another example is that there are some cases where developers expect methods are pure, such as equals, hashCode, and getter methods in Java. This paper presents a tool finding code changes where methods become pure/impure. This tool can prevent developers from inducing purity-related bugs to methods. The authors have applied the tool to two open source systems and found (1) a dozen of methods moved to pure/impure repeatedly and (2) there were many cases where purity of methods had changed without code changes.

In evaluating code clone detection tools, a benchmark is created to measure their precision and recall. Benchmarks in previous research have either of the following issues: the first one is that they depend on the code clone definitions of benchmark creators; the second one is that they are not code clones occurring in actual development process. To get rid of both the two issues, we propose a methodology that creates code clone references based on code clones occurring in development process without any human judgements. More concretely, we use multiple revisions included in the source code repository of target software to identify merged methods in the past development process. We regard merged methods as real code clones. The authors' benchmark can evaluate detection accuracy of code clone detection tools more objectivity.

In software evolution, many bugs occur and developers spend a long time to fix them. Program debugging is a costly and difficult task. Automated program repair is a promising way to reduce costs on program debugging dramatically. Several repair techniques reusing existing code lines have been proposed in the past. They reuse code lines already existing in the source code to generate variant source code of a given source code (if an inserted code line to fix a given bug is identical to any of the code lines in existing source code, we call the code line graftable). However, there are many bugs that such techniques cannot automatically repair. One of the reasons is that many bugs require code lines not existing in the source code of the software. In order to mitigate this issue, we are conducting our research with two ideas. The first idea is using a large dataset of source code to reuse code lines. The second idea is reusing only structures of code lines. Vocabularies are obtained from faulty code regions. In this paper, we report the feasibilities of the two ideas. More concretely, we found that the first and second ideas improved graftability of code lines to 43-59% and 56-64% from 34-54%, respectively. If we combine both the ideas, graftability was improved to 64-69%. In cases where we used the second idea, 24-49% variables used in reused code lines were able to be retrieved from the surrounding code of given faulty code regions.

Refactoring source code requires preserving a certain level of semantic behaviors, which are difficult to be checked by IDEs. Therefore, IDEs generally check syntactic pre-conditions instead before applying refactoring, which are often too restrictive than checking semantic behaviors. On the other hand, there are pure functions in the source code that do not have observable side-effects, of which semantic behaviors are more easily to be checked. In this research, we propose purity-guided refactoring, which applies high-level refactoring such as memoization on pure functions that can be detected statically. By combining our purity analyzing tool purano with refactoring, we can ensure the preservation of semantic behaviors on these detected pure functions, which is impossible through previous refactoring operations provided by IDEs. As a case study of our approach, we applied memorization refactoring on several open-source software in Java. We observed improvements of the performance and preservation of semantics by profiling their bundled test cases.

Many research studies have been conducted to help simultaneous code changes on multiple code fragments. Code clones and logical couplings are often utilized in such research studies. However, most of them have been evaluated on only open source projects or students' software. In this paper, we report our academic-industrial collaboration with a software company. The collaboration is intended to suggest multiple code fragments to be changed simultaneously when a developer specifies a keyword such as variable names on source code. In the collaboration, we propose to use code clones and logical couplings information to reorder the code fragments. We confirmed that code clones and logical couplings worked well on helping simultaneous code changes on three projects that have being developed in the company.

Existing techniques have succeeded to help developers implement new code. However, they are insufficient to help to change existing code. Previous studies have proposed techniques to support bug fixes but other kinds of code changes such as function enhancements and refactorings are not supported by them. In this paper, we propose a novel system that helps developers change existing code. Unlike existing techniques, our system can support any kinds of code changes if similar code changes occurred in the past. Our research is still on very early stage and we have not have any implementation or any prototype yet. This paper introduces our research purpose, an outline of our system, and how our system is different from existing techniques.

Programmers often copy and paste code fragments when they would like to reuse them. Although copy-and-paste operations enable programmers to realize rapid developments of software systems, it makes code clones. Some clones have negative impacts on software developments. For example, if we modify a code fragment, we have to check whether its clones need the same modification. In this case, programmers often use tools that take a code fragment as input and take its clones as output. However, when programmers use such existing tools, programmers have to open a number of source code and move up/down a scroll bar for browsing the detected clones. In order to reduce the cost of browsing the detected clones, we developed a tool that visualizes clones by using Circle Packing, named ClonePacker. As a result of an experiment with participants, we confirmed that participants using ClonePacker reported the locations of clones faster than an existing tool.

Results from code clone detectors may contain plentiful useless code clones, but judging whether each code clone is useful varies from user to user based on a user’s purpose for the clone. In this research, we propose a classification model that applies machine learning to the judgments of each individual user regarding the code clones. To evaluate the proposed model, 32 participants completed an online survey to test its usability and accuracy. The result showed several important observations on the characteristics of the true positives of code clones for the users. Our classification model showed more than 70 % accuracy on average and more than 90 % accuracy for some particular users and projects.

Changing source code is not an easy task. Developers occasionally change source code incorrectly. Such mistakes entail additional cost in having to reedit the source code correctly, and repeated changes themselves can be a vulnerability to software quality. We are conducting research into realizing automated code changing as a countermeasure for human errors. As the first step of this research, we propose a technique to predict the types of program elements deleted and added in a next change to Java methods. This technique is designed to support developers in deciding how to change source code after they have identified a method to be changed. We evaluated predictions using the proposed technique with two thresholds, which are sizes of source code changes. For predictions with the smaller threshold where only a single type of program element was added or deleted, the accuracy of the proposed technique was 74% -- 85%. However, for the larger threshold, where 5 or fewer types of program elements were added or deleted, the accuracy was 44% -- 48%.

This paper proposes a novel technique for clustering commits for understanding the intents of implementation. Such a classification of commits should be able to assist developers to understand commits related to particular requirements, for example, how and why has this function been implemented, or has this function suffered from any bugs? Our technique adopts a clustering algorithm on identifier names that are related to changes in each commit. Such an approach allows us to take the semantics of each commit into account without commit messages, and so our approach is robust for the situation where some commits lack accurate descriptions. We conducted a pilot study to confirm that our idea answers to our objective. The pilot study found some good examples that showed the usefulness of our approach, and there were some undesirable results that gave some ideas to improve it.

Although there is a principle that states a commit should only include changes for a single task, it is not always respected by developers. This means that code repositories often include commits that contain tangled changes. The presence of such tangled changes hinders analyzing code repositories because most mining software repository (MSR) approaches are designed with the assumption that every commit includes only changes for a single task. In this paper, we propose a technique to inform developers that they are in the process of committing tangled changes. The proposed technique utilizes the changes included in the past commits to judge whether a given commit includes tangled changes. If it determines that the proposed commit may include tangled changes, it offers suggestions on how the tangled changes can be split into a set of untangled changes.

Unintended inconsistencies are caused by missing a modification task that requires code changes on multiple locations in program source code. In order to identify such inconsistencies efficiently, we proposed a new technique. It firstly learns how code fragments were changed in the past modification tasks, and then, it identifies where inconsistencies exist at the latest version. In this paper, we focus on an aspect of the tool that we developed and shows a case study that we conducted with the tool. A video of the tool is available at http://youtu.be/a7_PVVZ4-vo.

This paper introduces a new dataset of clone references, which is a set of correct clones consisting of their locational information with their gapped lines. Bellon's dataset is one of widely used clone datasets. Bellon's dataset contains many clone references, thus the dataset is useful for comparing accuracies among clone detectors. However, Bellon's dataset does not have locational information of gapped lines. Thus, Bellon's benchmark does not evaluate some Type-3 clones correctly. In order to resolve the problem, we added locational information of gapped lines to Bellon's dataset. The new dataset is available at ``http://sdl.ist.osaka-u.ac.jp/~h-murakm/2014_clone_references_with_gaps/''.

Program source code is one of the main targets of software engineering research. A wide variety of research has been conducted on source code, and many studies have leveraged structural, vocabulary, and method signature similarities to measure the functional sameness of source code. In this research, we conducted an empirical study to ascertain how we should use three similarities to measure functional sameness. We used two large datasets and measured the three similarities between all the method pairs in the datasets, each of which included approximately 15 million Java method pairs. The relationships between the three similarities were analyzed to determine how we should use each to detect functionally similar code. The results of our study revealed the following. (1) Method names are not always useful for detecting functionally similar code. Only if there are a small number of methods having a given name, the methods are likely to include functionally similar code. (2) Existing file-level, method-level, and block-level clone detection techniques often miss functionally similar code generated by copy-and-paste operations between different projects. (3) In the cases we use structural similarity for detecting functionally similar code, we obtained many false positives. However, we can avoid detecting most false positives by using a vocabulary similarity in addition to a structural one. (4) Using a vocabulary similarity to detect functionally similar code is not suitable for method pairs in the same file because such method pairs use many of the same program elements such as private methods or private fields.

In the last decade, a variety of studies on mining software repositories has been conducted. Mining repositories has a potential to obtain useful knowledge for the future development and maintenance. When software repositories are mined, large commits in them are often excluded from mining targets because large commits include merging and we believe that large commits include peripheral modifications, which may affect negative impacts on mining code repositories. However, if large commits include code modifications, excluding large commits loses such modifications unintentionally. Moreover, such data cleansing assumes that there are no peripheral modifications in small commits. In this paper, we investigate how much peripheral modifications are included in commits in code repositories. As a result, we found that excluding large commits is insufficient to remove hindrances in commits for mining code repositories.

Code reuse is attracting much attention as a promising technique for efficient software development. However, code reuse itself requires human resources: for example, searching and opening source files including code fragments that users would like to reuse, or considering keywords in using code search systems. The present paper proposes a novel technique that hardly requires such reuse cost. In the proposed technique, what programmers have to do for obtaining reusable code is just inputting a trigger key for code reuse on their development environments. Also, this paper describes some applications on OSS with a prototype tool working on Eclipse.

A variety of methods detecting code clones has been proposed before. In order to detect gapped code clones, AST-based technique, PDG-based technique, metric-based technique and text-based technique using the LCS algorithm have been proposed. However, each of those techniques has limitations. For example, existing AST-based techniques and PDG-based techniques require costs for transforming source files into intermediate representations such as ASTs or PDGs and comparing them. Existing metric-based techniques and text-based techniques using the LCS algorithm cannot detect code clones if methods or blocks are partially duplicated. This paper proposes a new method that detects gapped code clones using the Smith-Waterman algorithm to resolve those limitations. The Smith-Waterman algorithm is an algorithm for identifying similar alignments between two sequences even if they include some gaps. The authors developed the proposed method as a software tool named CDSW, and confirmed that the proposed method could resolve the limitations by conducting a quantitative evaluation with Bellon's benchmark.

A variety of application results of code clone detection and analysis has been reported. There are many reports of code clone detection and analysis on open source software whereas few reports on industrial systems are open to the public. This paper reports an experience of code clone analysis on a governmental project. In the project, a software system was developed by multiple Japanese vendors. We detected and analyzed code clones in the system, and found that there were many code clones in the project, however we concluded that the presence of the code clones did not have negative impacts on the maintenance of the system because of the following reasons: (1) when different modules are similar to each other in the design document, they also share many code clones in the source code, (2) code clones located in trusted modules, which are libraries maintained by one of the companies.

It is difficult to keep consistent source code. Unintended inconsistencies occur unless we recognize all the code fragments that need to modify in a given bug fix or functional addition. Before modifying source code, keyword-based search tools like grep or code clone detection tools can be used to prevent code fragments from being overlooked. However, once inconsistencies occur in the source code, such tools cannot help us adequately. In this paper, we propose a new method to identify unintended inconsistencies in source code automatically. The proposed method analyzes source code modifications in a repository to derive modification patterns. A modification pattern indicates what kind of code and how it was modified. The derived modification patterns are queries to identify unintended inconsistencies from the latest version of source files. We implemented the proposed method and applied it to FreeBSD and Apache HTTPD. As a result, we identified many overlooked code fragments for bug fixes, functional enhancements, and refactorings. The precisions were 73.4% and 88.9% for the two systems, respectively.

In order to reduce coupling and increase cohesion, we refactor program source code. Previous research efforts for suggesting candidates of such refactorings are based on static analysis, which obtains relations among classes or methods from source code. However, these approaches cannot obtain runtime information such as repetition count of loop, dynamic dispatch and actual execution path. Therefore, previous approaches might miss some refactoring opportunities. To tackle this problem, we propose a technique to find refactoring candidates by analyzing method traces. We have implemented a prototype tool based on the proposed technique and evaluated the technique on two software systems. As a result, we confirmed that the proposed technique could detect some refactoring candidates, which increase code quality.

Refactoring is important for efficient software maintenance. However, manual operations for refactoring are complicated, and human-related errors easily occur. Tool support can help users to apply such a complicated refactoring. This paper proposes a refactoring support tool with Form Template Method pattern. The developed tool automatically identifies method pairs that can be refactored with Form Template Method, and suggests information that is required for Form Template Method application. It also has a function that metrics-based filtering for detected method pairs. The function helps users to select method pairs that should be refactored.

A variety of code clone detection methods have been proposed before now. However, only a small part of them is widely used. Widely-used methods are line-based and token-based ones. They have high scalability because they neither require deep source code analysis nor constructing complex intermediate structures for the detection. High scalability is one of the big advantages in code clone detection tools. On the other hand, line/token-based detections yield many false positives. One of the factors is the presence of repeated instructions in the source code. For example, herein we assume that there are consecutive three printf statements in C source code. If we apply a token-based detection to them, the former two statements are detected as a code clone of the latter two statements. However, such overlapped code clones are redundant and so not useful for developers. In this paper, we propose a new detection method that is free from the influence of the presence of repeated instructions. The proposed method transforms every of repeated instructions into a special form, and then it detects code clones using a suffix array algorithm. The transformation prevents many false positives from being detected. Also, the detection speed remains. The proposed detection method has already been developed as a software tool, FRISC. We confirmed the usefulness of the proposed method by conducting a quantitative evaluation of FRISC with Bellon's oracle.

In recent years, the increased failure originated in the software defects, in various information systems causes a serious social problem. In order to build a high-quality software, cultivation of ICT (Information and Communication Technology) human resources like a software engineer is required. A software development PBL (Project-based Learning) is the educational technique which lets students acquire knowledge and skill spontaneously through practical software development. In PBL, on the other hand, it is difficult to evaluate not only the quality of the product but also the quality of the development process in the project. In this paper, we propose the student evaluation metrics to assess the development process in PBL. The student evaluation metrics represent LOC (Lines of Code) and development time for each product developed by a student. By using online storage, these metrics can be measured and visualized automatically. We conducted an experiment to evaluate the accuracy of the metrics about development time. As a result, we confirmed that development time metrics can be measured with approximately 20% of error.

This paper proposes a new mechanism to measure a variety of source code metrics at low cost. The proposed mechanism is very promising because it realizes to add new metrics as necessary. Users do not need to use multiple measurement tools for measuring multiple metrics. The proposed mechanism has been implemented as an actual software tool MASU. This paper shows how using MASU makes it easy and less costly to develop plugins of the CK metrics suite.

Most code clones are generated by copy-and paste programming. Copy-and-paste programming shortens a time required for implementation because pasted code is a template of the required functionality. However, it sometimes brings on new bugs to the source code. After copy-and-paste, pasted code is somewhat changed fitting for the context of the region surrounding the pasted code. For example, some identifiers are replaced with other identifiers or a few statements are inserted, deleted, or changed. If such modifications are incorrectly performed, bugs occur in code clones. However, not all code clones are problematic, many code clones have decent reasons for their existence. Consequently, simple code clone detection is inefficient for identifying problematic code clones. Firstly, this paper proposes a classification scheme for dividing problematic code clones from non problematic ones. Secondly, it proposes a method for extracting specific code clones classified as problematic ones. Thirdly, it presents results of case studies conducted for evaluating the proposed method. The proposed method uses multiple code clone detection tools, and it doesn't directly analyze program source code. After multiple detections, simple operations are performed to extract code clones that are likely to be problematic. In the case studies conducted on an open source software system, the proposed method could actually identify 22 problematic code clones.

Abstract A code clone is a code fragment that has other code fragments identical or similar to it in the source code. The presence of code clones is generally regarded as one factor that makes software maintenance more difficult. For example, if a code fragment with code clones is modified, it is necessary to consider whether each of the other code clones has to be modified as well. Removing code clones is one way of avoiding problems that arise due to the presence of code clones. This makes the source code more maintainable and more comprehensible. This paper proposes a set of metrics that suggest how code clones can be refactored. As well, the tool Aries, which automatically computes these metrics, is presented. The tool gives metrics that are indicators for certain refactoring methods rather than suggesting the refactoring methods themselves. The tool performs only lightweight source code analysis; hence, it can be applied to a large number of code lines. This paper also describes a case study that illustrates how this tool can be used. Based on the results of this case study, it can be concluded that this method can efficiently merge code clones. Copyright © 2008 John Wiley & Sons, Ltd.

Maintaining software systems becomes more difficult as their size and complexity increase. One factor that makes software maintenance more difficult is the presence of code clones. A code clone is defined as a code fragment occurring more than once in identical or similar form into a software system. For example, the presence of code clones is a big factor of overlooking some places that should be modified simultaneously. One technique that helps the number of code clones is refactoring. There are several research efforts that provide support to refactor code clones, but unfortunately some code clones cannot or should not be refactored (ex. stereotyped process, absence of abstraction functionality, performance enhancement). In order to support maintaining the consistency among code clones, we propose a simultaneous modification support method. Given a software system, firstly, a maintainer identifies a code fragment that must be modified. Then, only the code clones between the identified code fragment and the source files of the software system are detected. We developed a simultaneous modification support tool, Libra, and applied it to open source software systems. The results showed that Libra was a good searching tool as much as grep, which is a useful tool of UNIX.

The increasing performance-price ratio of computer hardware makes possible to explore a distributed approach at code clone analysis. This paper presents D-CCFinder, a distributed approach at large-scale code clone analysis. D-CCFinder has been implemented with 80 PC workstations in our student laboratory, and a vast collection of open source software with about 400 million lines in total has been analyzed with it in about 2 days. The result has been visualized as a scatter plot, which showed the presence of frequently used code as easy recognizable patterns. Also, D-CCFinder has been used to analyze a single software system against the whole collection in order to explore the presence of code imported from open source software.

The authors describe a new research framework for applying empirical software engineering methods in industrial practice and accomplishments in using it. The selected target for applying the framework is a governmentally funded software development project involving multiple vendors. This project involved in-process project data measurement in real time, data sharing with industry and academia, data analysis, and feedback to the project members. Today the project is in the system integration process. This paper shows the value of this research framework and describes issues of empirical data sharing between industry and academia which have emerged while using it. This experiment raised two major issues. One is the necessity of a new research framework for project measurement called the "Macro Measurement Tool". The other is effects of the software industry structure on this framework.