Software requirements specifications (SRS) are essential to the success of software development. It is widely recognized that the quality of SRSs affects both the quality of their product and project results. IEEE 830 and ISO/IEC/IEEE 29148 are the international standards for the requirements process and SRSs. These standards provide recommended section structures and content of SRSs. However, a study has shown that many organizations have not adopted these standards due to a lack of knowledge or cost constraints. Indeed, there is a wide variety of SRS structures. This paper explores an approach for automatically converting SRSs with any structures into the standard structure. It is considered beneficial to standardize SRS structures. A key benefit is that it facilitates research on SRSs. It makes the assumption that SRSs in research follow the standard structure more realistic. As a matter of fact, some studies have assumed that sections of a SRS correspond to those of the standard structure. To achieve SRS structural standardization, we use a large language model (LLM) that demonstrates high natural language processing capability. We designed simple prompts and assessed the feasibility of an LLM. As a result, standardized SRSs contained about 80% of the required items in the standard structure, but they could not fully retain all information from the original SRSs. Observations of the results suggest that prompts should be designed to consider the size equivalence before and after standardization and relations between sections.

In this retrospective article of our TSE paper “CCFinder: A Multilinguistic Token-Based Code Clone Detection System for Large Scale Source Code” (Kamiya et al., 2002), we revisit the reasons why we became deeply involved in code clone research, and explore what has driven its frequent citation in many studies. Furthermore, we reflect on why not only our own lab, but also numerous researchers and tool developers have pursued code clone research and the development of related tools.

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.

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.

Abstract In software development, ad hoc solutions that are intentionally implemented by developers are called self-admitted technical debt (SATD). Because the existence of SATD spreads poor implementations, it is necessary to remove it as soon as possible. Meanwhile, container virtualization has been attracting attention in recent years as a technology to support infrastructure such as servers. Currently, Docker is the de facto standard for container virtualization. In Docker, a file describing how to build a container (Dockerfile) is a set of procedural instructions; thus, it can be considered as a kind of source code. Moreover, because Docker is a relatively new technology, there are few developers who have accumulated good or bad practices for building Docker container. Hence, it is likely that Dockerfiles contain many SATDs, as is the case with general programming language source code analyzed in previous SATD studies. The goal of this paper is to categorize SATDs in Dockerfiles and to share knowledge with developers and researchers. To achieve this goal, we conducted a manual classification for SATDs in Dockerfile. We found that about 3.0% of the comments in Dockerfile are SATD. In addition, we have classified SATDs into five classes and eleven subclasses. Among them, there are some SATDs specific to Docker, such as SATDs for version fixing and for integrity check. The three most common classes of SATD were related to lowering maintainability, testing, and defects.

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.

Software testing is being leveraged in programming education for automated assessment of programming assignments. When using software testing in programming education, program specifications are provided as unit or integration tests, and students create programs that pass these tests. Although this method has various advantages, such as ensuring objective program specifications and automating the operation check, it also has many disadvantages. For example, detecting innovations, such as original specifications and functional extensions by an individual student, is difficult. The purpose of this research is to automatically detect functional differences among student programs in programming education using tests. In our proposed method, automatic test generation is applied to student programs, and the generated tests are mutually executed for other student programs. Furthermore, we classify the tests based on the execution path to obtain sets of tests that are capable of detecting functional differences.

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.

The concept of the test smell represents potential problems with the readability and maintainability of the test code. Common test smells focus on static aspects of the source code, such as code length and complexity. These are easy to detect and do not cause problems in terms of test execution. On the other hand, dynamic smells, which are based on test runtime behavior, lead to misunderstanding of the test results. For example, rotten green tests give developers the false impression that the test was passed without any problems, even though the test was poorly executed. Therefore, we should detect dynamic smells and take countermeasures as early as possible through the development. In this paper, we introduce JTDog, a Gradle plugin for dynamic smell detection. JTDog has high portability due to its integration into the build tool. We applied JTDog to 150 projects on GitHub and confirmed that the JTDog plugin has high portability. In addition, JTDog detected 958 dynamic smells in 55 projects. JT-Dog is available at https://github.com/kusumotolab/JTDog, and the demo video is available at https://youtu.be/t374HYMCavI.

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.

Understanding program comprehension is one of the fundamental challenges of supporting software development. Although code writing is usually performed on programming specific environment, code reading is forced to be conducted in general environments such as physical paper. Our main hypothesis is that such a non-programming specific environment has some obstacles for program comprehension in terms of code presentation. The goal of this paper is to understand the effects on cognitive load caused by the obstacles. If our hypothesis will be proved and the goal will be achieved, we can provide the best practice of code presentation in non-programming specific environment.

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.

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.

Comparing and selecting the most appropriate JavaScript Framework (JSF) is an important activity for web application development. However, it is difficult to collect much information for comparison of JSFs. In this paper, we present a playground tool named Jact to support comprehension of individual JSF characteristics. By the concept of playground, users can freely run, edit, and share source code in their web browsers. Based on the concept, Jact enables developers to compare source codes and runtime performances of each JSF based on typical tasks in web development. Task-based comparison is useful for understanding the feature of each JSF. Furthermore, developers can submit tasks and source code which uses a specific JSF. By sharing tasks and source code written by not only administrators but also developers, Jact can continuously provide information relating to JSF, which includes benchmark and API usage. In order to evaluate the effectiveness of Jact, we conducted a subject experiment with 13 participants. Jact is currently available at http://13.231.18.92.

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.

Coding style is a representation of source code, which does not affect the behavior of program execution. The choice of coding style is purely a matter of developer preference. Inconsistency of coding style not only decreased readability but also can cause frustration during programming. In this paper, we propose a novel tool, called StyleCoordinator, to solve both of the following problems, which would appear to contradict each other: ensuring a consistent coding style for all source codes managed in a repository and ensuring the ability of developers to use their own coding styles in a local environment. In order to validate the execution performance, we apply the proposed tool to an actual software repository.

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.

In order to reduce software energy consumption, a lot of studies have been carried out focusing on the difference of implementation, such as API and algorithm. However, we hypothesize that there is a strong correlation between total energy consumption of a program and duration of its execution. If this hypothesis is correct, reducing energy consumption is equal to decreasing duration. Experimental results reveal that there is a strong positive correlation between them, and its correlation coefficient is higher than 0.9. We also find that memory usage is weakly correlated with total energy consumption. As a result, we conclude that if developers want to reduce software energy consumption, they should firstly decrease duration of execution, and secondly reduce memory usage.

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.

In recent years, Model-driven development (MDD) based techniques have emerged, and thus translation techniques such as translation from Object Constraint Language (OCL) to Java Modeling Language (JML) have gained much attention. We have been studying not only translation techniques from OCL to JML but also from JML to OCL in order to support Round-trip Engineering (RTE). Two directions of translation among OCL and JML are performed independently without considering unified and iterative translations in our previous work. For an OCL statement and another OCL statement which is obtained from a JML statement which was translated from the original OCL, our previous framework preserves only the meaning of the two statements, however, the forms of the OCL statements may change. It prevents us from RTE-based development. This paper proposes a translation technique between OCL and JML maintaining OCL code by describing their original forms in the comment area of the target languages. Our implementation has been evaluated on two projects used in our previous work and also seven additional open source projects.

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.

On the software development PBL (SDPBL), the implementation of firmly-fused development environment for students and monitoring environment for teachers are required in order to succeed in education. We have proposed the service, named "DaaS BADER" in compliance with demands from practical teachers to decrease the cost for preparation and maintenance of unified exercise environment and to monitor the progress of projects by teachers. In this paper, we have reported knowledge and information obtained by practical SDPBL and feedback contents for a student or group given by monitoring environment. Then, we have discussed the effectiveness of DaaS BADER from these results.

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.

Software visualization has attracted lots of attention. The techniques fall into two categories: visualization of software component relationships and visualization of software metrics.We have already proposed a hybrid method based on both of the two categories. The proposed method visualizes coincidence between specification and implementation from two aspects: static checking and ordinal testing by test suites. Each of the verification is performed in a method or function basis (unit testing). In the method, each ratio of the coincidence is shown by pie charts which represent classes of the target software. Whole software is represented in a weighted digraph structure.In this paper, we propose Priority Layout to emphasize important classes, and implemented our method into a tool. We have evaluated time in finding bug at source code and test cases between using Priority Layout, ISOM Layout and uncomplicated tables instead of graphs. As a result, time in finding bug at source code and test cases by proposed graph are a half of it using table.

This paper describes some examples and points about implementing a statistical quality control in developing business systems in Sumitomo Electric Industries, Ltd. and Sumitomo Electric Information Systems Co., Ltd. Although the X-R chart is often used in statistical quality control, it is recommended to introduce the u-chart if defects are to be controlled in future. If a defect detection process such as a review or a test does not reach a statistical steady state that indicates a process is stable on the control chart, an appropriate control could be conducted by not only further standardizing the process, but also reviewing the definition of size indicators. Quality prediction can be made possible by accumulating defect data collected to create a control chart and analyzing the distributions of introduced defect densities at an organization level. If the accuracy of quality prediction is low, it can be enhanced by carrying out improvements to narrow the widths of distributions of introduced defect densities.

This paper describes a system that supports to generate the software tag which makes software development visible to software purchaser (users). A software tag is a partial set of empirical data about a software development project shared between the purchaser and developer. The purchaser uses the software tag to evaluate the software project, allowing them to recognize the quality level of the processes and products involved. In order to implement the mechanism to use the software tag effectively, it is necessary to support generating the software tag. We have implemented a system named Collect Tag that supports to collect data and generate the software tag. We conducted a case study to evaluate the usefulness of Collect Tag and generated software tag. The results show that using Collect Tag requires low cost to generate the software tag.

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.

We design a mobility-aware data management (MoDA) scheme for mobile ad hoc networks (MANETs) composed by mobile nodes such as urban pedestrians and vehicles. By fully utilizing the knowledge about the trajectories of mobile nodes, MoDA determines how replicas of data are copied and transferred among mobile nodes to provide the required data accessibility. Experimental results have shown that MoDA could achieve the small number of data transfers among mobile nodes while keeping reasonable accessibility.

In this paper, we propose a routing protocol for MANETs called Contact-based Hybrid Routing (CHR) protocol where each node maintains potential routes to the nodes which it encountered. Only one route request message is forwarded along the potential route to the destination maintained by the source, and if a gap between two intermediate nodes is found on the potential route, it is filled by the potential routes maintained by the two nodes. Based on this idea, our goal is to reduce the number of route request messages by maintaining small amount of information at nodes. The experimental results in the RWP mobility and the disaster evacuation mobility have shown that CHR could reduce the number of messages while keeping reasonable reachability to the destinations.

In this paper, we present a QoS routing protocol called GVGrid for multi-hop mobile ad hoc networks constructed by vehicles, i.e., vehicular ad hoc networks (VANETs). GVGrid constructs a route on demand from a source (a fixed node or a base station) to vehicles that reside in or drive through a specified geographic region. The goal of GVGrid is to maintain a high quality route, i.e. a robust route for the vehicles movement. Such a route can be used for high quality communication and data transmission between roadsides and vehicles, or between vehicles. The experimental results have shown that GVGrid could provide routes with longer lifetime, compared with an existing routing protocol for VANETs

In this paper, we evaluate the performance of real-time data transmission by our routing protocol GVGrid. In Ref. [5], we have presented GVGrid, a position-based routing protocol for multi-hop mobile ad hoc networks constructed by vehicles. GVGrid constructs a route on demand from a source (a fixed node or a station) to vehicles that exist in a destination region. The experimental results have shown that GVGrid could achieve high quality data transmission in a region of a medium and high density of vehicles.

Assertion checking is a powerful tool to detect software faults during debugging, testing and maintenance. Although assertion documents the behavior of one component, it is hard to document relations and interactions among several objects since such assertion statements are spread across the modules. Therefore, we propose to modularize such assertion as an aspect in order to improve software maintainability. In this paper, taking Observer pattern as an example, we point out that some assertions tend to be crosscutting, and propose a modularization of such assertion with aspect-oriented language. We show a limitation of traditional assertion and effectiveness of assertion aspect through the case study, and discuss various situations to which assertion aspects are applicable.

Collections of already developed programs are important resources for efficient development of reliable software systems. In this paper, we propose a novel graph-representation model of a software component library (repository), called component rank model. This is based on analyzing actual usage relations of the components and propagating the significance through the usage relations. Using the component rank model, we have developed a Java class retrieval system named SPARS-J and applied SPARS-J to various collections of Java files. The result shows that SPARS-J gives a higher rank to components that are used more frequently. As a result, software engineers looking for a component have a better chance of finding it quickly. SPARS-J has been used by two companies, and has produced promising results.

Aspect-oriented programming (AOP) introduces a new software module unit named aspect to encapsulate crosscutting concerns. While AOP modularizes crosscutting concerns to improve maintainability and reusability, AOP introduces a new factor of complexity. It is difficult to find defects caused by an aspect modifying or preventing the behavior of other objects and aspects. We examine a method to support a debugging task in aspect-oriented software development. We propose an application of a call graph generation and program slicing to assist in debugging. A call graph visualizes control dependence relations between objects and aspects and supports the detection of an infinite loop. On the other hand, program slicing shows the user changes of dependence relations caused by aspects. We implement a program-slicing tool for AspectJ and apply it to certain programs. The experiment illustrates how our approach effectively helps developers understand the influence of aspects in a program.

Collections of already developed programs are important resources for efficient development of reliable software systems. In this paper, we propose a novel method of ranking software components, called Component Rank, based on analyzing actual use relations among the components and propagating the significance through the use relations. We have developed a component-rank computation system, and applied it to various Java programs. The result is promising such that non-specific and generic components are ranked high. Using the Component Rank system as a core part, we are currently developing Software Product Archiving, analyzing, and Retrieving System named SPARS.

In our research demonstration, we show two development support systems for Java programs. One is an Aspect-oriented Dynamic Analysis and Slice calculation system named ADAS, and another is a Software Product archiving, Analyzing, and Retrieving System for Java named SPARS-J.

It is generally accepted that a code clone is one factor making software maintenance difficult. A code clone is a code portion in source files that is identical or similar to another. Clones are introduced because of various reasons such as reusing code by 'copy-and-paste' and so on. Since developers usually modify the copied-and-pasted code portions, there are gaps between them and the original code portion. We call such code portions including gaps gapped code clones. Several code clone detection methods, which consider such gaps, have been proposed. However, it is costly to detect all gapped code clones. This paper proposes a new method to visualize gapped code clones as if they were actually detected, based on the detection results of conventional code clones. Using the proposed method, the developer can specify target clones efficiently. Moreover, we implement the proposed method in the maintenance support environment and conduct an experimental evaluation.

Function point analysis (FPA) was proposed to help measure the functionality of software systems. It is used to estimate the effort required for the software development. However, it has been reported that since function point measurement involves judgment on the part of the measurer, differences for the same product may occur even in the same organization. Also, if an organization tries to introduce FPA, FP will have to be measured from the past software developed there, and this measurement is cost-consuming. In this paper, we intend to examine the possibility to measure FP from source code automatically. At first, we propose measurement rules to count data and transactional functions for object-oriented program based on IFPUG method and develop the function point measurement tool. Then, we have applied the tool to practical Java programs in a computer company and examined the difference between the FP values obtained by the tool and those of an FP measurement specialist. As the results, the number of data and transactional functions extracted by the tool is similar to ones by the specialist though for the classification of each function there is some difference between them.

A code clone is a code portion in source files that is identical or similar to another. Since code clones are believed to reduce the maintainability of software, several code clone detection techniques and tools have been proposed. This paper proposes a new clone detection technique, which consists of the transformation of input source text and a token-by-token comparison. For its implementation with several useful optimization techniques, we have developed a tool, named CCFinder (Code Clone Finder), which extracts code clones in C, C++, Java, COBOL and other source files. In addition, metrics for the code clones have been developed. In order to evaluate the usefulness of CCFinder and metrics, we conducted several case studies where we applied the new tool to the source code of JDK, FreeBSD, NetBSD, Linux, and many other systems. As a result, CCFinder has effectively found clones and the metrics have been able to effectively identify the characteristics of the systems. In addition, we have compared the proposed technique with other clone detection techniques.

This paper describes two software maintenance support tools, CCFinder (Code Clone Finder) and JAAT (Java Alias Analysis Tool), for Java programs. CCFinder identifies code clones in Java programs, while JAAT executes alias analysis for Java programs.

Abstract Function‐point analysis was introduced to help measure the functionality of software systems. For more than a decade, function points have been widely used to measure the size of information systems, often as a part of estimating the effort required for software development and maintenance processes. Limiting the use of function point measurement have been concerns about variable judgements on the part of the personnel doing the measurement, yielding differences in function‐point measures for the same software product even in the same organization. Also, if an organization tries to introduce function‐point analysis, the process normally starts with measurements from the organization's own past software products—a time consuming task with start‐up costs. In this paper, we propose detailed function‐point analysis measurement rules using design specifications based on the Unified Modelling Language and describe a function‐point measurement tool, whose inputs are design specifications developed on Rational Rose®. Then in this paper, we report tool validation work on software involved in software evolution at an organization where we have applied the tool to actual design specifications and examined the differences between the function point values obtained by the tool and those of an experienced function point measurement specialist at the organization. Copyright © 2001 John Wiley & Sons, Ltd.

Function point analysis (FPA) was proposed to help measure the size of software systems and has been widely used in actual software development. However, it has been reported that since function point counting involves judgment on the part of the counter, some difference for the same product would be caused even in the same organization. The paper describes an actual experience of applying FPA to requirements specification at Hitachi Ltd. The authors propose a detailed FPA measurement method for the requirements specification analyzed using the requirements analysis system REQUARIO developed by Hitachi Ltd., and develop a measurement tool based on the method. They have also applied the tool to the actual requirements specification and show the applicability of the tool.

Article Call-mark slicing: an efficient and economical way of reducing slice Share on Authors: Akira Nishimatsu Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japan Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, JapanView Profile , Minoru Jihira Graduate School of Information Science, Nara Institute of Science and Technology, 8916-5, Takayama, Ikoma, Nara 630-0101, Japan Graduate School of Information Science, Nara Institute of Science and Technology, 8916-5, Takayama, Ikoma, Nara 630-0101, JapanView Profile , Shinji Kusumoto Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japan Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, JapanView Profile , Katsuro Inoue Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japan Graduate School of Engineering Science, Osaka University, 1-3 Machikaneyama, Toyonaka, Osaka 560-8531, JapanView Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 422–431https://doi.org/10.1145/302405.302674Online:16 May 1999Publication History 26citation284DownloadsMetricsTotal Citations26Total Downloads284Last 12 Months3Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

To analyse the complexity of object-oriented software, several metrics have been proposed. Among them, Chidamber and Kemerer's (1994) metrics are well-known object-oriented metrics. Also, their effectiveness has been empirically evaluated from the viewpoint of estimating the fault-proneness of object-oriented software. In the evaluations, these metrics were applied, not to the design specification but to the source code, because some of them measure the inner complexity of a class, and such information cannot be obtained until the algorithm and the class structure are determined at the end of the design phase. However, the estimation of the fault-proneness should be done in the early phase so as to effectively allocate effort for fixing the faults. This paper proposes a new method to estimate the fault-proneness of an object class in the early phase, using several complexity metrics for object-oriented software. In the proposed method, we introduce four checkpoints into the analysis/design/implementation phase, and we estimate the fault-prone classes using applicable metrics at each checkpoint.

In order to manage software projects quantitatively, we have presented a new model far software project based on generalized stochastic Petri-net model which can take influence of human factors into account, and we have already developed software project simulator based on GSPN model. This paper proposes methods for calculating model parameters in the new model and estimating the number of faults in the design and debug phases of software process. Then we present experimental evaluation of proposed method using a data of actual software development project on a certain company. As the result of case study, we confirmed its effectiveness with respect to estimating the number of faults in the software process.

This paper discusses safety analysis of design documents constructed by object-oriented development approaches. In our previously proposed method, whether design documents satisfy safety requirements is checked using some information tables, and these safety requirements are assumed to be given in advance. However, any systematic method that can derive such safety requirements from requirements specification and safety standards has not been developed. To overcome this problem, we propose a new FTA (Fault Tree Analysis)-based technique to derive safety requirements from requirements specification, component library, and design documents. Then, we apply the proposed method to typical examples taken from previous reports.

In this paper, we propose a new model for software projects and an estimation method for the quality, cost and delivery date.The new model consists of Project model and Process model.Project model focuses on three key components: activity, product and developer of the project.Process model includes a set of Activity models, each of which specifies design, coding, review, test, and debug activities respectively using GSPN.Moreover, the new model can take the influence of human factors into account by introducing the concept of "workload".Next, we develop a simulator which supports description of the target process, executes the process described by Activity model and analyses the simulation results statistically.Then, we apply the simulator to real software projects at certain organization and compare the estimated values with actual data.The experimental results show the applicability of the proposed simulator to manage real software project in the future.

We proposed new metrics for computing the program complexity of object oriented programs (E.M. Kim et al., 1994). In these metrics, we examined program complexity from three dimensional viewpoints in object oriented paradigm: syntax dimension, inheritance dimension and interaction dimension. We have defined attributes to evaluate three viewpoints quantitatively. We present some heuristics for computing actual values of the attributes, for which we have given only definitions in a previous paper. Then, we analytically evaluate the new metrics with regard to E.J. Weyuker's (1988) measurement principles. As a result, it is found that our metrics satisfy essential properties which any measure must have. Finally, we develop the tool to compute the values of the attributes automatically.

This paper describes an actual experience of software process improvement at OMRON corporation.posed procedure are proven to be effective for reclucing the development effort at OM RON corporation.

We try to develop a new design review method to verify bath safety and correctness of software product simultaneously. In the proposed method, we assume that requirement specification and design specification are given, and that designers and verifiers participate to build several kinds of information tables from the specifications. At the beginning, the designers construct a design table based on a design specification, and the verifiers construct two verification tables. One of the verification tables includes semantic information, some of which is taken from the knowledge and experience of the verifiers. Then, by comparing the items of three tables, the verifiers review a given design specification and try to detect faults in it. The information contained in the tables is relatively easily extracted from the requirement and design specifications. Finally, by applying the proposed method to the examples of software design specification, we show that faults can be detected in the design review.

The paper statistically analyzes the relationship between review and software quality and the relationship between review and productivity, utilizing software metrics on 36 actual projects executed in the OMRON Corporation from 1992 to 1994. Firstly, by examining the relationship between review effort and field quality (the number of faults after delivery) of each project, and the relationship between the number of faults detected in review and field quality of each project, we reasoned that: (1) greater review effort helps to increase field quality (decrease the number of faults after delivery); (2) source code review is more effective in order to increase field quality than design review; (3) if more than 10% of total design and programming effort is spent on review, one can achieve a quite stable field quality. We noticed that no relevant effects were recognized in productivity (LOC/staff month) with respect to a review rate of up to 20%. As a result of the analysis above, we recommended that 15% of review effort is a suitable percentage to use as a guideline for our software project management.

We present a new framework for analyzing the scope of metrics to evaluate complexity of object-oriented programs. In this framework, we examine in detail the metrics from the viewpoint of three key aspects in object-oriented paradigm: syntax complexity, inheritance complexity and interaction complexity. For each key aspect, we expand it to five attributes, which can be calculated qualitatively. Then, we apply our framework to conventional metrics for evaluating complexity of object-oriented programs. The metrics include the ones proposed by S.R. Chidamber and C.F. Kemerer (1991), R.C. Sharble and S.S. Cohen (1993), W. Li and S. Henry (1993), and E. Kim (1993). Finally, we present a new metric which satisfies almost all attributes of the proposed framework.>

A new metric for evaluating the cost effectiveness of technical reviews is described. The proposed metric is based on the degree to which testing costs are reduced by technical reviews. The metric can be interpreted as combining two conventional metrics. Using an experimental evaluation of the conventional metrics and the proposed metric for data collected in an industrial environment, the authors show the validity and usefulness of the proposed metric. In particular, they present a method to estimate a value of the proposed metric by using only the values obtained at review phase.>