Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00093
Zeinab Abou Khalil
The majority of the software development effort is spent on software maintenance. Bug handling constitutes one of the major software maintenance activities. Earlier studies have empirically investigated various aspects of bug handling, such as bug triaging, bug fixing, and bug process analysis. However, results from previous studies may not be applicable to contemporary agile software development practices.Moreover, these studies did not investigate how changes in the development policies and supporting tools impact the bug handling process. Therefore, our main goal is to investigate the impact of such changes on the bug handling process performance. To do so, we are conducting empirical studies on large and long-lived open source software projects. We report on our current research findings and outline the ongoing Ph.D. research project of the first author.
{"title":"Studying the Impact of Policy Changes on Bug Handling Performance","authors":"Zeinab Abou Khalil","doi":"10.1109/ICSME.2019.00093","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00093","url":null,"abstract":"The majority of the software development effort is spent on software maintenance. Bug handling constitutes one of the major software maintenance activities. Earlier studies have empirically investigated various aspects of bug handling, such as bug triaging, bug fixing, and bug process analysis. However, results from previous studies may not be applicable to contemporary agile software development practices.Moreover, these studies did not investigate how changes in the development policies and supporting tools impact the bug handling process. Therefore, our main goal is to investigate the impact of such changes on the bug handling process performance. To do so, we are conducting empirical studies on large and long-lived open source software projects. We report on our current research findings and outline the ongoing Ph.D. research project of the first author.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"24 1","pages":"590-594"},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"86297369","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00020
A. S. Klusener, A. Mooij, J. Ketema, Hans van Wezep
When software components are developed iteratively, code frequently evolves in an inductive manner: a unit (class, method, etc.) is created and is then copied and modified many times. Such development often happens when variation points and, hence, proper domain abstractions are initially unclear. As a result, there may be substantial amounts of code duplication, and the code may be difficult to understand and maintain, warranting a redesign. We apply a model-based process to semi-automatically redesign an inductively-evolved industrial adapter component written in C++: we use reverse engineering to obtain models of the component, and generate redesigned code from the models. Based on our experience, we propose to use three models to help recover understanding of inductively-evolved components, and transform the components into redesigned implementations. Guided by a reference design, a component's code is analyzed and a legacy model is extracted that captures the component's functionality in a form close to its original structure. The legacy model is then unfolded, creating a flat model which eliminates design decisions by focusing on functionality in terms of external interfaces. Analyzing the variation points of the flat model yields a redesigned model and fresh domain abstractions to be used in the new design of the component.
{"title":"Reducing Code Duplication by Identifying Fresh Domain Abstractions","authors":"A. S. Klusener, A. Mooij, J. Ketema, Hans van Wezep","doi":"10.1109/ICSME.2018.00020","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00020","url":null,"abstract":"When software components are developed iteratively, code frequently evolves in an inductive manner: a unit (class, method, etc.) is created and is then copied and modified many times. Such development often happens when variation points and, hence, proper domain abstractions are initially unclear. As a result, there may be substantial amounts of code duplication, and the code may be difficult to understand and maintain, warranting a redesign. We apply a model-based process to semi-automatically redesign an inductively-evolved industrial adapter component written in C++: we use reverse engineering to obtain models of the component, and generate redesigned code from the models. Based on our experience, we propose to use three models to help recover understanding of inductively-evolved components, and transform the components into redesigned implementations. Guided by a reference design, a component's code is analyzed and a legacy model is extracted that captures the component's functionality in a form close to its original structure. The legacy model is then unfolded, creating a flat model which eliminates design decisions by focusing on functionality in terms of external interfaces. Analyzing the variation points of the flat model yields a redesigned model and fresh domain abstractions to be used in the new design of the component.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"45 1","pages":"569-578"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73764437","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00053
Matthieu Jimenez, Maxime Cordy, Yves Le Traon, Mike Papadakis
Recent research shows that language models, such as n-gram models, are useful at a wide variety of software engineering tasks, e.g., code completion, bug identification, code summarisation, etc. However, such models require the appropriate set of numerous parameters. Moreover, the different ways one can read code essentially yield different models (based on the different sequences of tokens). In this paper, we focus on n-gram models and evaluate how the use of tokenizers, smoothing, unknown threshold and n values impact the predicting ability of these models. Thus, we compare the use of multiple tokenizers and sets of different parameters (smoothing, unknown threshold and n values) with the aim of identifying the most appropriate combinations. Our results show that the Modified Kneser-Ney smoothing technique performs best, while n values are depended on the choice of the tokenizer, with values 4 or 5 offering a good trade-off between entropy and computation time. Interestingly, we find that tokenizers treating the code as simple text are the most robust ones. Finally, we demonstrate that the differences between the tokenizers are of practical importance and have the potential of changing the conclusions of a given experiment.
{"title":"On the Impact of Tokenizer and Parameters on N-Gram Based Code Analysis","authors":"Matthieu Jimenez, Maxime Cordy, Yves Le Traon, Mike Papadakis","doi":"10.1109/ICSME.2018.00053","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00053","url":null,"abstract":"Recent research shows that language models, such as n-gram models, are useful at a wide variety of software engineering tasks, e.g., code completion, bug identification, code summarisation, etc. However, such models require the appropriate set of numerous parameters. Moreover, the different ways one can read code essentially yield different models (based on the different sequences of tokens). In this paper, we focus on n-gram models and evaluate how the use of tokenizers, smoothing, unknown threshold and n values impact the predicting ability of these models. Thus, we compare the use of multiple tokenizers and sets of different parameters (smoothing, unknown threshold and n values) with the aim of identifying the most appropriate combinations. Our results show that the Modified Kneser-Ney smoothing technique performs best, while n values are depended on the choice of the tokenizer, with values 4 or 5 offering a good trade-off between entropy and computation time. Interestingly, we find that tokenizers treating the code as simple text are the most robust ones. Finally, we demonstrate that the differences between the tokenizers are of practical importance and have the potential of changing the conclusions of a given experiment.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"65-66 1","pages":"437-448"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77205592","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00091
Sandra L. Ramirez-Mora, H. Oktaba
A main goal in Agile Software Development (ASD) is the productivity improvement: Organizations want to increase the amount of developed software and reduce the software development costs. Nevertheless, there are many factors impacting productivity in ASD. After conducting a Systematic Mapping Study, it was noted that many of the factors affecting productivity in ASD are related to team aspects. Social science states that mature teams can reach high productivity levels, but in Software Engineering there is a lack of research on that topic. Due to the above, a study was designed to determine the impact of team maturity on productivity in ASD. This work describes the research proposal.
{"title":"Team Maturity in Agile Software Development: The Impact on Productivity","authors":"Sandra L. Ramirez-Mora, H. Oktaba","doi":"10.1109/ICSME.2018.00091","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00091","url":null,"abstract":"A main goal in Agile Software Development (ASD) is the productivity improvement: Organizations want to increase the amount of developed software and reduce the software development costs. Nevertheless, there are many factors impacting productivity in ASD. After conducting a Systematic Mapping Study, it was noted that many of the factors affecting productivity in ASD are related to team aspects. Social science states that mature teams can reach high productivity levels, but in Software Engineering there is a lack of research on that topic. Due to the above, a study was designed to determine the impact of team maturity on productivity in ASD. This work describes the research proposal.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"54 1","pages":"732-736"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"78837380","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00061
Felipe Ebert, F. C. Filho, Nicole Novielli, Alexander Serebrenik
During code review, developers request clarifications, suggest improvements, or ask for explanations about the rationale behind the implementation choices. We envision the emergence of tools to support developers during code review based on the automatic analysis of the argumentation structure and communicative intentions conveyed by developers' comments. As a preliminary step towards this goal, we conducted an exploratory case study by manually classifying 499 questions extracted from 399 Android code reviews to understand the real communicative intentions they convey. We observed that the majority of questions actually serve information seeking goals. Still, they represent less than half of the annotated sample, with other questions being used to serve a wider variety of developers' communication goals, including suggestions, request for action, and criticism. Based on our findings we formulate hypotheses on communicative intentions in code reviews that should be confirmed or rejected by follow-up studies.
{"title":"Communicative Intention in Code Review Questions","authors":"Felipe Ebert, F. C. Filho, Nicole Novielli, Alexander Serebrenik","doi":"10.1109/ICSME.2018.00061","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00061","url":null,"abstract":"During code review, developers request clarifications, suggest improvements, or ask for explanations about the rationale behind the implementation choices. We envision the emergence of tools to support developers during code review based on the automatic analysis of the argumentation structure and communicative intentions conveyed by developers' comments. As a preliminary step towards this goal, we conducted an exploratory case study by manually classifying 499 questions extracted from 399 Android code reviews to understand the real communicative intentions they convey. We observed that the majority of questions actually serve information seeking goals. Still, they represent less than half of the annotated sample, with other questions being used to serve a wider variety of developers' communication goals, including suggestions, request for action, and criticism. Based on our findings we formulate hypotheses on communicative intentions in code reviews that should be confirmed or rejected by follow-up studies.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"42 1","pages":"519-523"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"80559905","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00083
Jirayus Jiarpakdee, C. Tantithamthavorn, Christoph Treude
This artefact is the implementation of AutoSpearman, an automated metric selection approach based on correlation analyses. The goal of AutoSpearman is to automatically mitigate correlated metrics prior to constructing analytical models. This artefact is implemented as an R package and is available in the GitHub repository. We provide descriptions and R code snippets for the installation of AutoSpearman and usage examples.
{"title":"Artefact: An R Implementation of the AutoSpearman Function","authors":"Jirayus Jiarpakdee, C. Tantithamthavorn, Christoph Treude","doi":"10.1109/ICSME.2018.00083","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00083","url":null,"abstract":"This artefact is the implementation of AutoSpearman, an automated metric selection approach based on correlation analyses. The goal of AutoSpearman is to automatically mitigate correlated metrics prior to constructing analytical models. This artefact is implemented as an R package and is available in the GitHub repository. We provide descriptions and R code snippets for the installation of AutoSpearman and usage examples.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"18 1","pages":"711-711"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"79705962","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00078
R. Wen, David Gilbert, Michael G. Roche, Shane McIntosh
Code review is an integral part of modern software development, where patch authors invite fellow developers to inspect code changes. While code review boasts technical and non-technical benefits, it is a costly use of developer time, who need to switch contexts away from their current development tasks. Since a careful code review requires even more time, developers often make intuition-based decisions about the patches that they will invest effort in carefully reviewing. Our key intuition in this paper is that patches that impact mission-critical project deliverables or deliverables that cover a broad set of products may require more reviewing effort than others. To help developers identify such patches, we introduce BLIMP Tracer, a build impact analysis system that we developed and integrated with the code review platform used by a globally distributed product team at Dell EMC, a large multinational corporation. BLIMP Tracer operates on a Build Dependency Graph (BDG) that describes how each file in the system is processed to produce the set of intermediate and output deliverables. For a given patch, BLIMP Tracer then traverses the BDG to identify the deliverables that are impacted by the change. Finally, the results are reported directly within the code review interface. To evaluate BLIMP Tracer, we conducted a qualitative study with 45 developers, observing that BLIMP Tracer not only improves the speed and accuracy of identifying the set of deliverables that are impacted by a patch, but also helps the community to better understand the project architecture.
{"title":"BLIMP Tracer: Integrating Build Impact Analysis with Code Review","authors":"R. Wen, David Gilbert, Michael G. Roche, Shane McIntosh","doi":"10.1109/ICSME.2018.00078","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00078","url":null,"abstract":"Code review is an integral part of modern software development, where patch authors invite fellow developers to inspect code changes. While code review boasts technical and non-technical benefits, it is a costly use of developer time, who need to switch contexts away from their current development tasks. Since a careful code review requires even more time, developers often make intuition-based decisions about the patches that they will invest effort in carefully reviewing. Our key intuition in this paper is that patches that impact mission-critical project deliverables or deliverables that cover a broad set of products may require more reviewing effort than others. To help developers identify such patches, we introduce BLIMP Tracer, a build impact analysis system that we developed and integrated with the code review platform used by a globally distributed product team at Dell EMC, a large multinational corporation. BLIMP Tracer operates on a Build Dependency Graph (BDG) that describes how each file in the system is processed to produce the set of intermediate and output deliverables. For a given patch, BLIMP Tracer then traverses the BDG to identify the deliverables that are impacted by the change. Finally, the results are reported directly within the code review interface. To evaluate BLIMP Tracer, we conducted a qualitative study with 45 developers, observing that BLIMP Tracer not only improves the speed and accuracy of identifying the set of deliverables that are impacted by a patch, but also helps the community to better understand the project architecture.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"1 1","pages":"685-694"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89390075","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00071
J. Fischer, S. Bougouffa, Alexander Schlie, Ina Schaefer, B. Vogel‐Heuser
Software product line engineering (SPLE) provides a systematic approach to manage variants and versions arising throughout the development of software systems. While SPLE is successfully applied for variant management in the domain of software engineering, the approach is still not widely spread in industrial automated production systems (aPS). Previous studies highlight the interdisciplinary nature of aPS as a reason for not applying SPLE, since control software variants and versions also result from changes in other disciplines such as the mechanical engineering department (i.e. exchange of a sensor). Additionally, the software may evolve over decades at the customer site. In order to gain a better understanding of the challenges in the development of aPS and the constraints hindering the use of SPLE, we conducted several interviews with software development engineers from the domain of aPS. The interviews main aim was to get an overview of the current state of variability management and applied planned and unplanned software reuse strategies. Based on these insights, we summarize the main results useable for a transition from currently deployed variability management concepts in aPS to the SPLE approach.
{"title":"A Qualitative Study of Variability Management of Control Software for Industrial Automation Systems","authors":"J. Fischer, S. Bougouffa, Alexander Schlie, Ina Schaefer, B. Vogel‐Heuser","doi":"10.1109/ICSME.2018.00071","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00071","url":null,"abstract":"Software product line engineering (SPLE) provides a systematic approach to manage variants and versions arising throughout the development of software systems. While SPLE is successfully applied for variant management in the domain of software engineering, the approach is still not widely spread in industrial automated production systems (aPS). Previous studies highlight the interdisciplinary nature of aPS as a reason for not applying SPLE, since control software variants and versions also result from changes in other disciplines such as the mechanical engineering department (i.e. exchange of a sensor). Additionally, the software may evolve over decades at the customer site. In order to gain a better understanding of the challenges in the development of aPS and the constraints hindering the use of SPLE, we conducted several interviews with software development engineers from the domain of aPS. The interviews main aim was to get an overview of the current state of variability management and applied planned and unplanned software reuse strategies. Based on these insights, we summarize the main results useable for a transition from currently deployed variability management concepts in aPS to the SPLE approach.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"89 1","pages":"615-624"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"90582912","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00062
S. Thorve, Chandani Sreshtha, Na Meng
A flaky test is a test that may fail or pass for the same code under testing (CUT). Flaky tests could be harmful to developers because the non-deterministic test outcome is not reliable and developers cannot easily debug the code. A prior study characterized the root causes and fixing strategies of flaky tests by analyzing commits of 51 Apache open source projects, without analyzing any Android app. Due to the popular usage of Android devices and the multitude of interactions of Android apps with third-party software libraries, hardware, network, and users, we were curious to find if the Android apps manifested unique flakiness patterns and called for any special resolution for flaky tests as compared to the existing literature. For this paper, we conducted an empirical study to characterize the flaky tests in Android apps. By classifying the root causes and fixing strategies of flakiness, we aimed to investigate how our proposed characterization for flakiness in Android apps varies from prior findings, and whether there are domain-specific flakiness patterns. After mining GitHub, we found 29 Android projects containing 77 commits that were relevant to flakiness. We identified five root causes of Android apps' flakiness. We revealed three novel causes - Dependency, Program Logic, and UI. Five types of resolution strategies were observed to address the flaky behavior. Many of the examined commits show developers' attempt to fix flakiness by changing software implementation in various ways. However, there are still 13% commits that simply skipped or removed the flaky tests. Our observations provide useful insights for future research on flaky tests of Android apps.
{"title":"An Empirical Study of Flaky Tests in Android Apps","authors":"S. Thorve, Chandani Sreshtha, Na Meng","doi":"10.1109/ICSME.2018.00062","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00062","url":null,"abstract":"A flaky test is a test that may fail or pass for the same code under testing (CUT). Flaky tests could be harmful to developers because the non-deterministic test outcome is not reliable and developers cannot easily debug the code. A prior study characterized the root causes and fixing strategies of flaky tests by analyzing commits of 51 Apache open source projects, without analyzing any Android app. Due to the popular usage of Android devices and the multitude of interactions of Android apps with third-party software libraries, hardware, network, and users, we were curious to find if the Android apps manifested unique flakiness patterns and called for any special resolution for flaky tests as compared to the existing literature. For this paper, we conducted an empirical study to characterize the flaky tests in Android apps. By classifying the root causes and fixing strategies of flakiness, we aimed to investigate how our proposed characterization for flakiness in Android apps varies from prior findings, and whether there are domain-specific flakiness patterns. After mining GitHub, we found 29 Android projects containing 77 commits that were relevant to flakiness. We identified five root causes of Android apps' flakiness. We revealed three novel causes - Dependency, Program Logic, and UI. Five types of resolution strategies were observed to address the flaky behavior. Many of the examined commits show developers' attempt to fix flakiness by changing software implementation in various ways. However, there are still 13% commits that simply skipped or removed the flaky tests. Our observations provide useful insights for future research on flaky tests of Android apps.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"51 1","pages":"534-538"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"86649572","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}
Pub Date : 2018-09-01DOI: 10.1109/ICSME.2018.00011
A. Sawant, Guangzhe Huang, Gabriel Vilén, Stefan Stojkovski, Alberto Bacchelli
In this study, we investigate why API producers deprecate features. Previous work has shown us that knowing the rationale behind deprecation of an API aids a consumer in deciding to react, thus hinting at a diversity of deprecation reasons. We manually analyze the Javadoc of 374 deprecated methods pertaining four mainstream Java APIs to see whether the reason behind deprecation is mentioned. We find that understanding the rationale from just the Javadoc is insufficient; hence we add other data sources such as the source code, issue tracker data and commit history. We observe 12 reasons that trigger API producers to deprecate a feature. We evaluate an automated approach to classify these motivations.
{"title":"Why are Features Deprecated? An Investigation Into the Motivation Behind Deprecation","authors":"A. Sawant, Guangzhe Huang, Gabriel Vilén, Stefan Stojkovski, Alberto Bacchelli","doi":"10.1109/ICSME.2018.00011","DOIUrl":"https://doi.org/10.1109/ICSME.2018.00011","url":null,"abstract":"In this study, we investigate why API producers deprecate features. Previous work has shown us that knowing the rationale behind deprecation of an API aids a consumer in deciding to react, thus hinting at a diversity of deprecation reasons. We manually analyze the Javadoc of 374 deprecated methods pertaining four mainstream Java APIs to see whether the reason behind deprecation is mentioned. We find that understanding the rationale from just the Javadoc is insufficient; hence we add other data sources such as the source code, issue tracker data and commit history. We observe 12 reasons that trigger API producers to deprecate a feature. We evaluate an automated approach to classify these motivations.","PeriodicalId":6572,"journal":{"name":"2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"38 1","pages":"13-24"},"PeriodicalIF":0.0,"publicationDate":"2018-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"74948696","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：