2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)最新文献

{"title":"Mining Historical Test Failures to Dynamically Batch Tests to Save CI Resources","authors":"Amir Hossein Bavand, Peter C. Rigby","doi":"10.1109/ICSME52107.2021.00026","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00026","url":null,"abstract":"Testing is a costly, time-consuming, and challenging part of modern software development. During continuous integration, after submitting each change, it is tested automatically to ensure that it does not break the system's functionality. A common approach to reducing the number of test case executions is to batch changes together for testing. For example, given four changes to test, if we group them in a batch and they pass we use one execution to test all four changes. However, if they fail, additional executions are required to find the culprit change that is responsible for the failure. We evaluate five batch culprit finding approaches: Dorfman, double pool testing, BatchBisect, BatchStop4, and our novel BatchDivide4. All prior works on batching use a constant batch size. In this work, we propose a dynamic batch size technique based on the weighted historical failure rate of the project. We simulate each of the batching strategies across 12 large projects on Travis with varying failures rate. We find that dynamic batching coupled with BatchDivide4 outperforms the other approaches. Compared to TestAll, this approach decreases the number of executions by 47.49% on average across the Travis projects. It outperforms the current state-of-the-art Batch4 by 5.17 percentage points. Our historical weighting approach leads us to a metric that describes the number of consecutive build failures. We find that the correlation between batch savings and FailureSpread is r = -0.97 with a p << 0.0001. This metric easily allows developers to determine the potential of batching on their project. We also contribute a theoretical limit for the savings that can be achieved by batch testing. We show that using dynamic batching, we achieve an across project average of 58.91% of the theoretical limit. Although batching is highly effective, there is still substantial room for improving batching relative to the theoretical batch savings limit. We make our scripts and data available for replication [1].","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"104 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127959271","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Look Ahead! Revealing Complete Composite Refactorings and their Smelliness Effects","authors":"Ana Carla Bibiano, W. K. Assunção, Daniel Coutinho, Kleber Santos, Vinícius Soares, Rohit Gheyi, Alessandro F. Garcia, B. Neto, Márcio Ribeiro, Daniel Oliveira, Caio Barbosa, João Lucas Marques, Anderson Oliveira","doi":"10.1109/ICSME52107.2021.00033","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00033","url":null,"abstract":"Recent studies have revealed that developers often apply composite refactorings (or, simply, composites). A composite consists of two or more interrelated refactorings applied together. Previous studies investigated the effect of composites on code smells. A composite is considered “complete” whenever it completely removes one target code smell. They proposed descriptions of complete composites with recommendations to remove certain code smell types, such as Long Methods and Feature Envies. These studies also present different recommendations to remove the same code smell type. However, these studies: (i) are limited to composites only consisting of a small subset of Fowler's refactoring types, (ii) do not detail the scenarios in which each recommendation can be applied to remove the code smell, and (iii) fail in reporting possible side effects of the described composites, such as adversely introducing certain smell types. This paper aims to cover these limitations by performing a systematic analysis of 618 complete composites on removing four common smell types identified in 20 software projects. Our results indicated that: (i) 64% complete composites consisted of refactoring types not covered by existing descriptions of complete composites, and (ii) 36% complete composites formed by Extract Methods can introduce Feature Envies and Intensive Couplings. This information is not documented by existing descriptions, and it can alert developers about alternatives to remove Feature Envy, mainly in methods that are fully envious. These results suggest existing descriptions of complete composites should be either revisited or enhanced to explicitly highlight known side effects. We present a catalog of composites with details about side effects, recommendations to remove or minimize them, and some scenarios in which each recommendation can be applied to remove the code smell. Our catalog can be useful to improve existing tooling support for refactorings, such as IDEs, informing about possible side effects when refactorings are composed.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129323867","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"FACER-AS: An API Usage-based Code Recommendation Tool for Android Studio","authors":"Maha Kamal, Ayman Abaid, Shamsa Abid, S. Shamail","doi":"10.26226/morressier.613b5418842293c031b5b5ee","DOIUrl":"https://doi.org/10.26226/morressier.613b5418842293c031b5b5ee","url":null,"abstract":"Android developers often need to search for example code to complete their development tasks. While existing code search systems for Android can deliver code against a search query, they do not recommend code for features that a developer might later need to implement. In this paper, we present FACER-AS (FACER for Android Studio); an Android Studio plugin, which uses FACER (Feature-driven API usage-based Code Examples Recommender) as its back-end code search and recommendation engine. FACER provides relevant code against natural language queries (Stage 1) and also recommends code of multiple related features (Stage 2) to facilitate opportunistic code reuse. To evaluate FACER-AS, we perform a user study involving one professional Android developer who uses our tool for the development of their ongoing live Android projects. We analyze the developer's usage of our tool over a span of seven days and find that FACER-AS achieves a 79% success rate for retrieving code against user queries (Stage 1) and a 41% success rate for recommending code for related features (Stage 2). We also observe a 43% reuse rate of Stage 1 recommendations and a 45% reuse rate of Stage 2 recommendations. Our tool's performance analysis and the developer's positive feedback show that FACER-AS can help Android developers with their coding activities. A video demonstration of our tool is available at https://youtu.be/3yN-39wP_FU and the source code of our tool is available at https://doi.org/10.5281/zenodo.5176816.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127408724","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Analysis of Non-Discrimination Policies in the Sharing Economy","authors":"Miroslav Tushev, Fahime Ebrahimi, Anas Mahmoud","doi":"10.1109/ICSME52107.2021.00016","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00016","url":null,"abstract":"Recent research has exposed a serious discrimination problem affecting applications of the Digital Sharing Economy (DSE), such as Uber, Airbnb, and TaskRabbit. To control for this problem, several DSE apps have crafted a new form of usage policies, known as non-discrimination policies (NDPs). These policies are intended to outline end-users' rights of equal treatment and describe how acts of bias and discrimination over DSE apps are identified and prevented. However, there is still a major knowledge gap in how such non-code artifacts can be formulated, structured, and evolved. To bridge this gap, in this paper, we introduce a first-of-its-kind framework for analyzing and evaluating the content of NDPs in the DSE market. Our analysis is conducted using a dataset of 108 DSE apps, sampled from a broad range of application domains. Our results show that, a) most DSE apps do not provide a separate NDP, b) the majority of existing policies are either extremely brief or combined as sub-statements of other usage policies, and c) most apps do not provide a clear statement of how their NDPs are enforced. Our analysis in this paper is intended to assist DSE app developers with drafting and evolving more comprehensive NDPs as well as help end-users of these apps to make more informed socioeconomic decisions in one of the fastest growing software ecosystems in the world.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"75 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114203793","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Can Differential Testing Improve Automatic Speech Recognition Systems?","authors":"Muhammad Hilmi Asyrofi, Zhou Yang, Jieke Shi, Chu Wei Quan, David Lo","doi":"10.26226/morressier.613b5418842293c031b5b5ef","DOIUrl":"https://doi.org/10.26226/morressier.613b5418842293c031b5b5ef","url":null,"abstract":"Due to the widespread adoption of Automatic Speech Recognition (ASR) systems in many critical domains, ensuring the quality of recognized transcriptions is of great importance. A recent work, CrossASR++, can automatically uncover many failures in ASR systems by taking advantage of the differential testing technique. It employs a Text-To-Speech (TTS) system to synthesize audios from texts and then reveals failed test cases by feeding them to multiple ASR systems for cross-referencing. However, no prior work tries to utilize the generated test cases to enhance the quality of ASR systems. In this paper, we explore the subsequent improvements brought by leveraging these test cases from two aspects, which we collectively refer to as a novel idea, evolutionary differential testing. On the one hand, we fine-tune a target ASR system on the corresponding test cases generated for it. On the other hand, we fine-tune a cross-referenced ASR system inside CrossASR++, with the hope to boost CrossASR++'s performance in uncovering more failed test cases. Our experiment results empirically show that the above methods to leverage the test cases can substantially improve both the target ASR system and CrossASR++ itself. After fine-tuning, the number of failed test cases uncovered decreases by 25.81% and the word error rate of the improved target ASR system drops by 45.81%. Moreover, by evolving just one cross-referenced ASR system, CrossASR++ can find 5.70%, 7.25%, 3.93%, and 1.52% more failed test cases for 4 target ASR systems, respectively.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"23 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121355315","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Cross-language Code Coupling Detection: A Preliminary Study on Android Applications","authors":"Bo Shen, Wei Zhang, Ailun Yu, Zhao Wei, Guangtai Liang, Haiyan Zhao, Zhi Jin","doi":"10.1109/ICSME52107.2021.00040","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00040","url":null,"abstract":"Framework-based multi-lingual software is increasingly prevalent, but it also brings negative effects and extra burden on software maintenance and evolution, because of the introduced cross-language code coupling, which are usually mixed with framework-specific conventions. Researchers have proposed various approaches to code coupling detection, but there is still a lack of necessary support for cross-language coupling detection in framework-based software development. In this paper, we present a preliminary study about cross-language coupling detection in software development based on the Android application framework. We investigate the characteristics of multi-lingual changes in the top-100 starred open-source Android repositories on GitHub, and find that multi-lingual commits are non-trivial: their code changes are more scattered, and more inclined to introduce bugs than other commits. To mitigate the side-effect of multi-lingual development, we propose Grace, a Graph-based cross-language co-change suggestion approach for Android application development. Grace (a) designs a language-agnostic graph to represent code elements from different languages, and (b) employs an entity-based collaborative filtering algorithm to detect and rank candidates of cross-language code couplings, from the graph representation of the latest version as well as the historical multi-lingual commits of a repository. To evaluate the effectiveness of Grace, we apply it to the two tasks of cross-language co-change suggestion and inconsistency checking. Results show that Grace (a) can effectively suggest cross-language co-changed files and types, and (b) can also find existing and potential bugs or code smells caused by inconsistent co-changes.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122411151","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"FeaRS: Recommending Complete Android Method Implementations","authors":"Fengcai Wen, Valentina Ferrari, Emad Aghajani, Csaba Nagy, Michele Lanza, G. Bavota","doi":"10.26226/morressier.613b5418842293c031b5b5ed","DOIUrl":"https://doi.org/10.26226/morressier.613b5418842293c031b5b5ed","url":null,"abstract":"Several techniques have been proposed in the literature to support code completion, showing excellent results in predicting the next few tokens a developer is likely to type given the current context. Only recently, approaches pushing the boundaries of code completion (e.g., by presenting entire code statements) have been proposed. In this line of research, we present FeaRS, a recommender system that, given the current code a developer is writing in the IDE, recommends the next complete method to be implemented. FeaRS has been deployed to learn “implementation patterns” (i.e., groups of methods usually implemented within the same task) by continuously mining open-source Android projects. Such knowledge is leveraged to provide method recommendations when the code written by the developer in the IDE matches an “implementation pattern”. Preliminary results of FeaRS’ accuracy show its potential as well as some open challenges to overcome.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"71 9","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114100947","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Evaluating The Energy Consumption of Java I/O APIs","authors":"Zakaria Ournani, Romain Rouvoy, P. Rust, J. Penhoat","doi":"10.1109/ICSME52107.2021.00007","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00007","url":null,"abstract":"The Java language is rich of native and third-party I/O APIs that most Java applications and software use. Such operations can even be considered core to most software as they allow the interaction with the user and its data in a nonvolatile way. Yet, the I/O captivate a lot of attention due to their importance, but also due to the cost that these relatively slow operations add to read and write precious data, most commonly from/to disks. In this context, the impact of these I/O operations on energy consumption didn't get as much attention. Of course, I/O operations are responsible for energy consumption at the level of the storage medium (HDD or SSD) but they also induce non-negligible costs -both performance and energy-wise- at the CPU level. However, only few works take into account the impact of I/O on the energy consumption, especially at the CPU-level. Hence, this paper elaborates a detailed study with two main objectives. First we aim at assessing the energy consumption of several well-known I/O libraries methods, and investigate if different read/write methods can exhibit different energy consumption. Concretely, we assess -using micro-benchmarks-the energy consumption of 27 I/O methods for several file sizes and establish the truth about the most and least energy efficient methods. The second objective is to validate the results of the first experiments on real Java projects by substituting their default I/O methods and measuring the before/after energy consumption. Our results showed that i) different I/O methods consume very different amounts of energy, such as NIO Channels that are 20% more efficient than other methods for read purposes ii) substituting the I/O method in a software by a more efficient one can save an important amount of energy, 15% of energy saving has been registered for K-nucleotide and 3% for Zip4j. We also showed that choosing the right I/O method can save more than 30% of energy consumption when using the Javax.crypto API. Our work offers direct conclusions and guidelines on which I/O methods to use in which situation (read all data, read specific data, write data, etc.) for a better energy efficiency. It also opens doors for other works to better optimize the energy consumption of the I/O APIs and methods.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"41 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125173733","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Message from the General Co-Chairs and Program Co-Chairs ICSME 2021","authors":"","doi":"10.1109/icsme52107.2021.00005","DOIUrl":"https://doi.org/10.1109/icsme52107.2021.00005","url":null,"abstract":"","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"T169 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125495710","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Revisiting Test Cases to Boost Generate-and-Validate Program Repair","authors":"Jingtang Zhang, Kui Liu, Dongsun Kim, Li Li, Zhe Liu, Jacques Klein, Tegawendé F. Bissyandé","doi":"10.1109/ICSME52107.2021.00010","DOIUrl":"https://doi.org/10.1109/ICSME52107.2021.00010","url":null,"abstract":"Fault localization produces bug positions as the basic input for many automated program repair (APR) systems. Given that test cases are the common means that automatic fault localization techniques leverage, we investigate the impact of their characteristics (in terms of quality and quantity) on APR. In particular, we analyze the statements that appear in crash stack traces when test cases fail (note that stack traces are available when an ordinary test case fails since its verdict is often made by assertions that produce errors such as AssertError in Java and JUnit), and explore the possibility of using some relevant crash information to enhance fault localization; this ultimately improves the effectiveness of APR tools. Our study reveals that the considered state-of-the-art APR systems achieve the best performance when fixing bugs associated with boolean type expected values (e.g., assertTrue ()) or assertFalse(). In contrast, they achieve their worst performance when addressing bugs related to null check assertions. Meanwhile, null check bugs as well as the bugs associated with boolean and string type expected values are still the main challenge that should be addressed by the future APR. For exception throwing bugs, existing APR systems present the best performance on fixing NullPointerException bugs, while the tough task of them is to resolve the bugs throwing developer-defined exceptions. The information in stack traces after executing the bug-triggering test cases can be used to effectively improve the performance on fault localization and program repair.","PeriodicalId":205629,"journal":{"name":"2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"74 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2021-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127480508","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}