var bibbase_data = {"data":"\"Loading..\"\n\n
\n\n \n\n \n\n \n \n\n \n\n \n \n\n \n\n \n
\n generated by\n \n \"bibbase.org\"\n\n \n
\n \n\n
\n\n \n\n\n
\n\n Excellent! Next you can\n create a new website with this list, or\n embed it in an existing web page by copying & pasting\n any of the following snippets.\n\n
\n JavaScript\n (easiest)\n
\n \n <script src=\"https://bibbase.org/show?bib=https%3A%2F%2Fanderson-uchoa.github.io%2Fpublications%2FUchoaPapers.bib&jsonp=1&jsonp=1\"></script>\n \n
\n\n PHP\n
\n \n <?php\n $contents = file_get_contents(\"https://bibbase.org/show?bib=https%3A%2F%2Fanderson-uchoa.github.io%2Fpublications%2FUchoaPapers.bib&jsonp=1\");\n print_r($contents);\n ?>\n \n
\n\n iFrame\n (not recommended)\n
\n \n <iframe src=\"https://bibbase.org/show?bib=https%3A%2F%2Fanderson-uchoa.github.io%2Fpublications%2FUchoaPapers.bib&jsonp=1\"></iframe>\n \n
\n\n

\n For more details see the documention.\n

\n
\n
\n\n
\n\n This is a preview! To use this list on your own web site\n or create a new web site from it,\n create a free account. The file will be added\n and you will be able to edit it in the File Manager.\n We will show you instructions once you've created your account.\n
\n\n
\n\n

To the site owner:

\n\n

Action required! Mendeley is changing its\n API. In order to keep using Mendeley with BibBase past April\n 14th, you need to:\n

    \n
  1. renew the authorization for BibBase on Mendeley, and
  2. \n
  3. update the BibBase URL\n in your page the same way you did when you initially set up\n this page.\n
  4. \n
\n

\n\n

\n \n \n Fix it now\n

\n
\n\n
\n\n\n
\n \n \n
\n
\n  \n 2023\n \n \n (7)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n Recommendations for Developers Identifying Code Smells.\n \n \n \n \n\n\n \n de Mello, R.; Oliveira, R.; Uchôa, A.; Oizumi, W.; Garcia, A.; Fonseca, B.; and de Mello, F.\n\n\n \n\n\n\n IEEE Software, 40(02): 90-98. mar 2023.\n \n\n\n\n
\n\n\n\n \n \n \"RecommendationsPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n \n \n\n\n\n
\n
@article{9904005,\n  author = {R. de Mello and R. Oliveira and A. Uchôa and W. Oizumi and A. Garcia and B. Fonseca and F. de Mello},\n  journal = {IEEE Software},\n  title = {Recommendations for Developers Identifying Code Smells},\n  year = {2023},\n  volume = {40},\n  number = {02},\n  issn = {1937-4194},\n  pages = {90-98},\n  abstract = {Identifying code smells is a widely disseminated practice for preventing software systems from design problems and other maintainability issues. This task remains challenging and manual despite several catalogues and detection tools being available. The complexity involved in identifying a code smell requires the developer’s ability to analyse its surrounding context, reflecting on its actual incidence and need for removal. Despite the predominantly manual nature of the task, there is still quite limited knowledge of the human and social aspects involved. In this sense, we conducted several investigations centred on the community of software developers in recent years. The outcomes of this work provide a comprehensive view of the task and emerging findings, such as the developers’ major beliefs, values, and ideas about identifying code smells. Based on these outcomes, we present practical recommendations to developers to optimise efforts in identifying code smells.},\n  keywords = {codes;software;task analysis;software systems;frequency measurement;psychology;complexity theory},\n  doi = {10.1109/MS.2022.3203716},\n  url = {https://ieeexplore.ieee.org/document/9904005},\n  publisher = {IEEE Computer Society},\n  address = {Los Alamitos, CA, USA},\n  month = {mar}\n}\n\n
\n
\n\n\n
\n Identifying code smells is a widely disseminated practice for preventing software systems from design problems and other maintainability issues. This task remains challenging and manual despite several catalogues and detection tools being available. The complexity involved in identifying a code smell requires the developer’s ability to analyse its surrounding context, reflecting on its actual incidence and need for removal. Despite the predominantly manual nature of the task, there is still quite limited knowledge of the human and social aspects involved. In this sense, we conducted several investigations centred on the community of software developers in recent years. The outcomes of this work provide a comprehensive view of the task and emerging findings, such as the developers’ major beliefs, values, and ideas about identifying code smells. Based on these outcomes, we present practical recommendations to developers to optimise efforts in identifying code smells.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n What Factors Affect the Build Failures Correction Time? A Multi-Project Study.\n \n \n \n \n\n\n \n Ivens, G.; Bezerra, C.; Uchôa, A.; and Machado, I.\n\n\n \n\n\n\n In Proceedings of the 17th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2023, Campo Grande, MS, Brazil, 25-27 September 2023, pages 1–10, 2023. \n \n\n\n\n
\n\n\n\n \n \n \"WhatPaper\n  \n \n\n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 4 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{ivens2023factors,\n  title={What Factors Affect the Build Failures Correction Time? A Multi-Project Study},\n  author={Gustavo Ivens and Carla Bezerra and Anderson Uchôa and Ivan Machado},\n  booktitle={Proceedings of the 17th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2023, Campo Grande, MS, Brazil, 25-27 September 2023},\n  pages={1--10},\n  year={2023},\n  abstract={Continuous Integration (CI) is a widely adopted practice in modern software engineering that involves integrating developers' local changes with the project baseline daily. Despite its popularity, recent studies have revealed that integrating changes can be time-consuming, requiring significant effort to correct errors that arise. This can lead to development activities being paused, including the addition of new features and fixing bugs, while developers focus on analyzing and correcting build failures. In this study, we investigate the factors that influence the time taken to correct build failures in CI. Specifically, we analyze the impact of developer activity, project characteristics, and build complexity on build failure correction time. To conduct our analysis, we collected data from 18 industrial projects of a software company, calculating 13 metrics for each project based on the literature on build failures analysis. We used association rules, a data mining technique, to examine the relationship between the defined factors and build failure correction time. Our findings reveal significant correlations between the factors studied and the duration of build failure correction time. Specifically, we found that more experienced developers require less time to correct build failures, while build failures that originate in the early stages of the project are resolved more quickly. Additionally, we observed that build failures with more lines and modified files tend to have longer correction times. Overall, this study sheds light on the factors that impact build failure correction time in CI. By identifying these factors, our findings can help software development teams optimize their CI processes and minimize the impact of build failures on development activities.},\n  url = {https://anderson-uchoa.github.io/publications/ivens2023factors.pdf},\n\n}\n\n
\n
\n\n\n
\n Continuous Integration (CI) is a widely adopted practice in modern software engineering that involves integrating developers' local changes with the project baseline daily. Despite its popularity, recent studies have revealed that integrating changes can be time-consuming, requiring significant effort to correct errors that arise. This can lead to development activities being paused, including the addition of new features and fixing bugs, while developers focus on analyzing and correcting build failures. In this study, we investigate the factors that influence the time taken to correct build failures in CI. Specifically, we analyze the impact of developer activity, project characteristics, and build complexity on build failure correction time. To conduct our analysis, we collected data from 18 industrial projects of a software company, calculating 13 metrics for each project based on the literature on build failures analysis. We used association rules, a data mining technique, to examine the relationship between the defined factors and build failure correction time. Our findings reveal significant correlations between the factors studied and the duration of build failure correction time. Specifically, we found that more experienced developers require less time to correct build failures, while build failures that originate in the early stages of the project are resolved more quickly. Additionally, we observed that build failures with more lines and modified files tend to have longer correction times. Overall, this study sheds light on the factors that impact build failure correction time in CI. By identifying these factors, our findings can help software development teams optimize their CI processes and minimize the impact of build failures on development activities.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n CIRef: A Tool for Visualizing the Historical Data of Software Refactorings in Java Projects.\n \n \n \n \n\n\n \n Silva, M.; Nunes, M.; Bezerra, C.; Uchôa, A.; and Wessel, M.\n\n\n \n\n\n\n In Proceedings of the 37th Brazilian Symposium on Software Engineering (SBES), Tools Track, 2023, Campo Grande, MS, Brazil, 27-29 September 2023, pages 1–6, 2023. \n \n\n\n\n
\n\n\n\n \n \n \"CIRef:Paper\n  \n \n\n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 4 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{marcos2023ciref,\n  title={CIRef: A Tool for Visualizing the Historical Data of Software Refactorings in Java Projects},\n  author={Marcos Silva and Maykon Nunes and Carla Bezerra and Anderson Uchôa and Mairieli Wessel},\n  booktitle={Proceedings of the 37th Brazilian Symposium on Software Engineering (SBES), Tools Track, 2023, Campo Grande, MS, Brazil, 27-29 September 2023},\n  pages={1--6},\n  year={2023},\n  abstract={Context: Refactorings are actions developers do not often do in a standard way. One of the reasons is the lack of visualizations in current tools capable of identifying refactorings. Code visualizations can help developers make decisions about analyzing code quality and possible code refactorings. Objective: We present CIRef, a tool for visualizing the historical data of refactorings in Java projects. For a particular project, CIRef provides a wide range of visualizations including customizable rankings of the importance of different refactoring types, duels between developers to understand their profiles, and a timeline of the number of refactorings performed. Method: To validate the acceptance and perceived usefulness of CIRef, we conducted a study with eight developers using the Technology Acceptance Model (TAM). Results: The results indicate that 75% of the participants agreed with using the tool in the future and found it easy to use. Conclusions: Despite supporting developers in visualizing historical refactoring data, CIRef also has the potential for educational purposes. It can help teachers visualize the history of refactorings performed by students, especially in educational environments focused on programming and maintaining Java projects. Video link: https://figshare.com/s/99c9e2ca3fb227b649a1.},\n  url = {https://anderson-uchoa.github.io/publications/marcos2023ciref.pdf},\n\n}\n\n
\n
\n\n\n
\n Context: Refactorings are actions developers do not often do in a standard way. One of the reasons is the lack of visualizations in current tools capable of identifying refactorings. Code visualizations can help developers make decisions about analyzing code quality and possible code refactorings. Objective: We present CIRef, a tool for visualizing the historical data of refactorings in Java projects. For a particular project, CIRef provides a wide range of visualizations including customizable rankings of the importance of different refactoring types, duels between developers to understand their profiles, and a timeline of the number of refactorings performed. Method: To validate the acceptance and perceived usefulness of CIRef, we conducted a study with eight developers using the Technology Acceptance Model (TAM). Results: The results indicate that 75% of the participants agreed with using the tool in the future and found it easy to use. Conclusions: Despite supporting developers in visualizing historical refactoring data, CIRef also has the potential for educational purposes. It can help teachers visualize the history of refactorings performed by students, especially in educational environments focused on programming and maintaining Java projects. Video link: https://figshare.com/s/99c9e2ca3fb227b649a1.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Beyond the Code: Investigating the Effects of Pull Request Conversations on Design Decay.\n \n \n \n \n\n\n \n Barbosa, C.; Uchôa, A.; Coutinho, D.; Assunção, W. K. G.; Oliveira, A.; Garcia, A.; Fonseca, B.; de Oliveira Rabelo, M. F.; Coelho, J. E. M.; da Silva, E. C.; and Marques, P. H. S.\n\n\n \n\n\n\n In Proceedings of the 17th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2023, New Orleans, USA, 23-27 October 2023, pages 1–12, 2023. \n \n\n\n\n
\n\n\n\n \n \n \"BeyondPaper\n  \n \n\n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{barbosa2023beyond,\n  title={Beyond the Code: Investigating the Effects of Pull Request Conversations on Design Decay},\n  author={Caio Barbosa and Anderson Uchôa and Daniel Coutinho and Wesley K. G. Assunção and Anderson Oliveira and Alessandro Garcia and Baldoino Fonseca and Matheus Feitosa de Oliveira Rabelo and José Eric Mesquita Coelho and Eryka Carvalho da Silva and Paulo Henrique Santos Marques},\n  booktitle={Proceedings of the 17th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2023, New Orleans, USA, 23-27 October 2023},\n  pages={1--12},\n  year={2023},\n  abstract={Background: Code development is done collaboratively and supported by platforms, such as GitHub and GitLab. These platforms contribute to collaborative software development, offering a pull-based development model. In this model, developers actively communicate and share their knowledge through conversations. However, pull request conversations are affected by several social aspects, such as communication dynamics among developers, discussion content, and organizational dynamics, which may directly impact the quality of the software. Despite prior studies indicating that social aspects indeed impact software quality, it is still unknown to what extent social aspects influence design decay during software development. Thus, since social aspects are intertwined with design and implementation decisions, there is a need for investigating how social aspects contribute to avoiding, reducing, or accelerating design decay. Aims: To fill this gap, we performed a study aimed at investigating the effects of pull request conversation on design decay. Method: We investigated 10,746 pull request conversations from 11 open-source systems. The pull request conversations were characterized in terms of three different social aspects: discussion content, organizational and communication dynamics. We observed and characterized 18 social metrics to these three social aspects, and analyzed how they associate with design decay. To this end, we used a statistical approach to assess which social metrics are able to discriminate between impactful and unimpactful pull requests. Then, we employed a multiple logistic regression model to evaluate the influence of each social metric per social aspect in the presence of each other on design decay. Finally, we also observed how the combination of all social metrics influences the design decay. Results: Our findings reveal that social metrics related to the size and duration of a discussion, the presence of design-related keywords, the team size, and gender diversity can be used to discriminate between design impactful and unimpactful pull requests. Second, organizational growth and gender diversity prevent decay. Third, each software community has its unique set of social aspects that can be used to detect and prevent design decay. Finally, design improvements can be accomplished by timely feedback, engaged communication, and design-oriented discussions with the contribution of multiple participants who provide significant comments. Conclusion: The social aspects related to pull request conversations are useful indicators of design decay.},\n  url = {https://anderson-uchoa.github.io/publications/barbosa2023beyond.pdf},\n\n}\n\n
\n
\n\n\n
\n Background: Code development is done collaboratively and supported by platforms, such as GitHub and GitLab. These platforms contribute to collaborative software development, offering a pull-based development model. In this model, developers actively communicate and share their knowledge through conversations. However, pull request conversations are affected by several social aspects, such as communication dynamics among developers, discussion content, and organizational dynamics, which may directly impact the quality of the software. Despite prior studies indicating that social aspects indeed impact software quality, it is still unknown to what extent social aspects influence design decay during software development. Thus, since social aspects are intertwined with design and implementation decisions, there is a need for investigating how social aspects contribute to avoiding, reducing, or accelerating design decay. Aims: To fill this gap, we performed a study aimed at investigating the effects of pull request conversation on design decay. Method: We investigated 10,746 pull request conversations from 11 open-source systems. The pull request conversations were characterized in terms of three different social aspects: discussion content, organizational and communication dynamics. We observed and characterized 18 social metrics to these three social aspects, and analyzed how they associate with design decay. To this end, we used a statistical approach to assess which social metrics are able to discriminate between impactful and unimpactful pull requests. Then, we employed a multiple logistic regression model to evaluate the influence of each social metric per social aspect in the presence of each other on design decay. Finally, we also observed how the combination of all social metrics influences the design decay. Results: Our findings reveal that social metrics related to the size and duration of a discussion, the presence of design-related keywords, the team size, and gender diversity can be used to discriminate between design impactful and unimpactful pull requests. Second, organizational growth and gender diversity prevent decay. Third, each software community has its unique set of social aspects that can be used to detect and prevent design decay. Finally, design improvements can be accomplished by timely feedback, engaged communication, and design-oriented discussions with the contribution of multiple participants who provide significant comments. Conclusion: The social aspects related to pull request conversations are useful indicators of design decay.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Don't Forget the Exception! Considering Robustness Changes to Identify Design Problems.\n \n \n \n \n\n\n \n Oliveira, A.; Correia, J. L.; Sousa, L.; Assunção, W. K. G.; Coutinho, D.; Garcia, A.; Oizumi, W.; Barbosa, C.; Uchôa, A.; and Pereira, J. A.\n\n\n \n\n\n\n In Proceedings of the 20th International Conference on Mining Software Repositories (MSR), 2023, Melbourne, Australia, 15-16 May 2023, pages 1–12, 2023. \n \n\n\n\n
\n\n\n\n \n \n \"Don'tPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 8 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{oliveira2023dont,\n  title={Don't Forget the Exception! Considering Robustness Changes to Identify Design Problems},\n  author={Anderson Oliveira and João Lucas Correia and Leonardo Sousa and Wesley K. G. Assunção and Daniel Coutinho and Alessandro Garcia and Willian Oizumi and Caio Barbosa and Anderson Uchôa and Juliana Alves Pereira},\n  booktitle={Proceedings of the 20th International Conference on Mining Software Repositories (MSR), 2023, Melbourne, Australia, 15-16 May 2023},\n  pages={1--12},\n  year={2023},\n  doi = {10.1109/MSR59073.2023.00064},\n  abstract={Modern programming languages, such as Java, use exception-handling mechanisms to guarantee the robustness of software systems. Although important, the quality of exception code is usually poor and neglected by developers. Indiscriminate robustness changes (e.g., the addition of empty catch blocks) can indicate design decisions that negatively impact the internal quality of software systems. As it is known in the literature, multiple occurrences of poor code structures, namely code smells, are strong indicators of design problems. Still, existing studies focus mainly on the correlation of maintainability smells with design problems. However, using only these smells may not be enough since developers need more context (e.g., system domain) to identify the problems in certain scenarios. Moreover, these studies do not explore how changes in the exceptional code of the methods combined with maintainability smells can give complementary evidence of design problems. By covering both regular and exception codes, the developer can have more context about the system and find complementary code smells that reinforce the presence of design problems. This work aims to leverage the identification of design problems by tracking poor robustness changes combined with maintainability smells. We investigated the correlation between robustness changes and maintainability smells on the commit history of more than 160k methods from different releases of 10 open-source software systems. We observed that maintainability smells can be worsened or even introduced when robustness changes are performed. This scenario mainly happened for the smells Feature Envy, Long Method, and Dispersed Coupling. We also analyzed the co-occurrence between robustness and maintainability smells. We identified that the empty catch block and catch throwable robustness smells were the ones that co-occurred the most with maintainability smells related to the Concern Overload and Misplaced Concern design problems. The contribution of our work is to reveal that poor exception code, usually neglected by developers, negatively impacts the quality of methods and classes, signaled by the maintainability smells. Therefore, existing code smell detecting tools can be enhanced to leverage robustness changes to identify design problems.},\n  url = {https://anderson-uchoa.github.io/publications/oliveira2023dont.pdf},\n }\n\n
\n
\n\n\n
\n Modern programming languages, such as Java, use exception-handling mechanisms to guarantee the robustness of software systems. Although important, the quality of exception code is usually poor and neglected by developers. Indiscriminate robustness changes (e.g., the addition of empty catch blocks) can indicate design decisions that negatively impact the internal quality of software systems. As it is known in the literature, multiple occurrences of poor code structures, namely code smells, are strong indicators of design problems. Still, existing studies focus mainly on the correlation of maintainability smells with design problems. However, using only these smells may not be enough since developers need more context (e.g., system domain) to identify the problems in certain scenarios. Moreover, these studies do not explore how changes in the exceptional code of the methods combined with maintainability smells can give complementary evidence of design problems. By covering both regular and exception codes, the developer can have more context about the system and find complementary code smells that reinforce the presence of design problems. This work aims to leverage the identification of design problems by tracking poor robustness changes combined with maintainability smells. We investigated the correlation between robustness changes and maintainability smells on the commit history of more than 160k methods from different releases of 10 open-source software systems. We observed that maintainability smells can be worsened or even introduced when robustness changes are performed. This scenario mainly happened for the smells Feature Envy, Long Method, and Dispersed Coupling. We also analyzed the co-occurrence between robustness and maintainability smells. We identified that the empty catch block and catch throwable robustness smells were the ones that co-occurred the most with maintainability smells related to the Concern Overload and Misplaced Concern design problems. The contribution of our work is to reveal that poor exception code, usually neglected by developers, negatively impacts the quality of methods and classes, signaled by the maintainability smells. Therefore, existing code smell detecting tools can be enhanced to leverage robustness changes to identify design problems.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Composite refactoring: Representations, characteristics and effects on software projects.\n \n \n \n \n\n\n \n Bibiano, A. C.; Uchôa, A.; Assunção, W. K.; Tenório, D.; Colanzi, T. E.; Vergilio, S. R.; and Garcia, A.\n\n\n \n\n\n\n Information and Software Technology, 156: 107134. 2023.\n \n\n\n\n
\n\n\n\n \n \n \"CompositePaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{BIBIANO2023107134,\n  title = {Composite refactoring: Representations, characteristics and effects on software projects},\n  journal = {Information and Software Technology},\n  volume = {156},\n  pages = {107134},\n  year = {2023},\n  issn = {0950-5849},\n  doi = {https://doi.org/10.1016/j.infsof.2022.107134},\n  url = {https://www.sciencedirect.com/science/article/pii/S0950584922002439},\n  author = {Ana Carla Bibiano and Anderson Uchôa and Wesley K.G. Assunção and Daniel Tenório and Thelma E. Colanzi and Silvia Regina Vergilio and Alessandro Garcia},\n  keywords = {Code refactoring, Composite refactoring, Software maintenance, Software project, Systematic mapping},\n  abstract = {Context: code refactoring is a code transformation that aims to improve software quality. A composite refactoring (or, simply, composite) is defined by two or more interrelated refactorings, which is often applied by developers. Each composite needs to be somehow represented and has its own characteristics (e.g., code scope) as well as its effects on software quality. However, these basic elements of composites are rarely studied systematically. The lack of systematic knowledge also misguides the design of automated support tools for supporting composite refactoring. Thus, researchers might have controversial views about basic elements of composite refactorings. An example of these literature conflicts concerns the effect of composites: while some studies suggest composites more often remove code smells, other studies indicate composites often introduce code smells. Objective: in this sense, our study aims at analyzing the technical literature of composite refactoring and building a conceptual framework of the representation models, characteristics, and the effect of composite refactoring. Method: we conducted a systematic mapping with 140 primary empirical studies about refactoring. Our systematic mapping summarizes the current knowledge on composites and also presents a conceptual framework intended to characterize composite refactoring. Results: our conceptual framework presents seven representation models, nine characteristics, and thirteen effects of composites. We found out that studies used multidimensional representations, like graphs, to determine what refactoring(s) may be suggested and combined. On composite characteristics, studies mentioned developers often finish a composite in up to a month. However, these studies do not detail why and when composites span for several weeks. Then, we discussed other existing gaps on the current literature of composites. For instance, while most of the studies report the effect of composites on internal software quality, e.g., code smells, their effect on external software quality is little explored. Conclusion: our results can motivate future studies to more deeply investigate composite refactoring applications, and the improvement of tooling support for composite refactorings.}\n}\n
\n
\n\n\n
\n Context: code refactoring is a code transformation that aims to improve software quality. A composite refactoring (or, simply, composite) is defined by two or more interrelated refactorings, which is often applied by developers. Each composite needs to be somehow represented and has its own characteristics (e.g., code scope) as well as its effects on software quality. However, these basic elements of composites are rarely studied systematically. The lack of systematic knowledge also misguides the design of automated support tools for supporting composite refactoring. Thus, researchers might have controversial views about basic elements of composite refactorings. An example of these literature conflicts concerns the effect of composites: while some studies suggest composites more often remove code smells, other studies indicate composites often introduce code smells. Objective: in this sense, our study aims at analyzing the technical literature of composite refactoring and building a conceptual framework of the representation models, characteristics, and the effect of composite refactoring. Method: we conducted a systematic mapping with 140 primary empirical studies about refactoring. Our systematic mapping summarizes the current knowledge on composites and also presents a conceptual framework intended to characterize composite refactoring. Results: our conceptual framework presents seven representation models, nine characteristics, and thirteen effects of composites. We found out that studies used multidimensional representations, like graphs, to determine what refactoring(s) may be suggested and combined. On composite characteristics, studies mentioned developers often finish a composite in up to a month. However, these studies do not detail why and when composites span for several weeks. Then, we discussed other existing gaps on the current literature of composites. For instance, while most of the studies report the effect of composites on internal software quality, e.g., code smells, their effect on external software quality is little explored. Conclusion: our results can motivate future studies to more deeply investigate composite refactoring applications, and the improvement of tooling support for composite refactorings.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Negative effects of gamification in education software: Systematic mapping and practitioner perceptions.\n \n \n \n \n\n\n \n Almeida, C.; Kalinowski, M.; Uchôa, A.; and Feijó, B.\n\n\n \n\n\n\n Information and Software Technology, 156: 107142. 2023.\n \n\n\n\n
\n\n\n\n \n \n \"NegativePaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 35 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{ALMEIDA2023107142,\n  title = {Negative effects of gamification in education software: Systematic mapping and practitioner perceptions},\n  journal = {Information and Software Technology},\n  volume = {156},\n  pages = {107142},\n  year = {2023},\n  issn = {0950-5849},\n  doi = {https://doi.org/10.1016/j.infsof.2022.107142},\n  url = {https://www.sciencedirect.com/science/article/pii/S0950584922002518},\n  author = {Cláuvin Almeida and Marcos Kalinowski and Anderson Uchôa and Bruno Feijó},\n  keywords = {Gamification, Negative effects, Education, Learning, Systematic mapping, Snowballing, Focus group},\n  abstract = {Context: While most research shows positive effects of gamification, the focus on its adverse effects is considerably smaller and further understanding of these effects is needed. Objective: To provide a comprehensive overview on research reporting negative effects of game design elements and to provide insights into the awareness of developers on these effects and into how they could be considered in practice. Method: We conducted a systematic mapping study of the negative effects of game design elements on education/learning systems. We also held a focus group discussion with developers of a gamified software, discussing the mapping study results with regard to their awareness and perceptions on the reported negative effects in practice. Results: The mapping study revealed 87 papers reporting undesired effects of game design elements. We found that badges, leaderboards, competitions, and points are the game design elements most often reported as causing negative effects. The most cited negative effects were lack of effect, worsened performance, motivational issues, lack of understanding, and irrelevance. The ethical issues of gaming the system and cheating were also often reported. As part of our results, we map the relations between game design elements and the negative effects that they may cause. The focus group revealed that developers were not aware of many of the possible negative effects and that they consider this type of information useful. The discussion revealed their agreement on some of those potential negative effects and also some positive counterparts. Conclusions: Gamification, when properly applied, can have positive effects on education/learning software. However, gamified software is also prone to generate harmful effects. Revealing and discussing potentially negative effects can help to make more informed decisions considering their trade-off with respect to the expected benefits.}\n}\n\n
\n
\n\n\n
\n Context: While most research shows positive effects of gamification, the focus on its adverse effects is considerably smaller and further understanding of these effects is needed. Objective: To provide a comprehensive overview on research reporting negative effects of game design elements and to provide insights into the awareness of developers on these effects and into how they could be considered in practice. Method: We conducted a systematic mapping study of the negative effects of game design elements on education/learning systems. We also held a focus group discussion with developers of a gamified software, discussing the mapping study results with regard to their awareness and perceptions on the reported negative effects in practice. Results: The mapping study revealed 87 papers reporting undesired effects of game design elements. We found that badges, leaderboards, competitions, and points are the game design elements most often reported as causing negative effects. The most cited negative effects were lack of effect, worsened performance, motivational issues, lack of understanding, and irrelevance. The ethical issues of gaming the system and cheating were also often reported. As part of our results, we map the relations between game design elements and the negative effects that they may cause. The focus group revealed that developers were not aware of many of the possible negative effects and that they consider this type of information useful. The discussion revealed their agreement on some of those potential negative effects and also some positive counterparts. Conclusions: Gamification, when properly applied, can have positive effects on education/learning software. However, gamified software is also prone to generate harmful effects. Revealing and discussing potentially negative effects can help to make more informed decisions considering their trade-off with respect to the expected benefits.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2022\n \n \n (3)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n How do Trivial Refactorings Affect Classification Prediction Models?.\n \n \n \n \n\n\n \n Pinheiro, D.; Bezerra, C.; and Uchôa, A.\n\n\n \n\n\n\n In Proceedings of the 16th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2022, Uberlandia, Brazil, October 3–4, pages 81–90, 2022. \n Best Paper Award \n\n\n\n
\n\n\n\n \n \n \"HowPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 2 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{pinheiro2022how,\n  title={How do Trivial Refactorings Affect Classification Prediction Models?},\n  author={Darwin Pinheiro and Carla Bezerra and Anderson Uchôa},\n  booktitle={Proceedings of the 16th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2022, Uberlandia, Brazil, October 3--4},\n  pages = {81–90},\n  isbn = {9781450397452},\n  note={<font color="red"> Best Paper Award </font>},\n  year={2022},\n  abstract={Refactoring is defined as a transformation that changes the internal structure of the source code without changing the external behavior. Keeping the external behavior means that after applying the refactoring activity, the software must produce the same output as before the activity. The refactoring activity can bring several benefits, such as: removing code with low structural quality, avoiding or reducing technical debt, improving code maintainability, reuse or readability. In this way, the benefits extend to internal and external quality attributes. The literature on software refactoring suggests carrying out studies that invest in improving automated solutions for detecting and correcting refactoring. Furthermore, few studies investigate the influence that a less complex type of refactoring can have on predicting more complex refactorings. This paper investigates how less complex (trivial) refactorings affect the prediction of more complex (non-trivial) refactorings. To do this, we classify refactorings based on their triviality, extract metrics from the code, contextualize the data and train machine learning algorithms to investigate the effect caused. Our results suggest that: (i) machine learning with tree-based models (Random Forest and Decision Tree) performed very well when trained with code metrics to detect refactorings; (ii) separating trivial from non-trivial refactorings into different classes resulted in a more efficient model, indicative of improving the accuracy of automated solutions based on machine learning; and, (iii) using balancing techniques that increase or decrease samples randomly is not the best strategy to improve datasets composed of code metrics.},\n  doi = {10.1145/3559712.3559720},\n  url={https://anderson-uchoa.github.io/publications/pinheiro2022how.pdf}\n}\n\n
\n
\n\n\n
\n Refactoring is defined as a transformation that changes the internal structure of the source code without changing the external behavior. Keeping the external behavior means that after applying the refactoring activity, the software must produce the same output as before the activity. The refactoring activity can bring several benefits, such as: removing code with low structural quality, avoiding or reducing technical debt, improving code maintainability, reuse or readability. In this way, the benefits extend to internal and external quality attributes. The literature on software refactoring suggests carrying out studies that invest in improving automated solutions for detecting and correcting refactoring. Furthermore, few studies investigate the influence that a less complex type of refactoring can have on predicting more complex refactorings. This paper investigates how less complex (trivial) refactorings affect the prediction of more complex (non-trivial) refactorings. To do this, we classify refactorings based on their triviality, extract metrics from the code, contextualize the data and train machine learning algorithms to investigate the effect caused. Our results suggest that: (i) machine learning with tree-based models (Random Forest and Decision Tree) performed very well when trained with code metrics to detect refactorings; (ii) separating trivial from non-trivial refactorings into different classes resulted in a more efficient model, indicative of improving the accuracy of automated solutions based on machine learning; and, (iii) using balancing techniques that increase or decrease samples randomly is not the best strategy to improve datasets composed of code metrics.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n TEl-IoT: A Template for Eliciting IoT Software System Requirements.\n \n \n \n \n\n\n \n de Souza, S. R.; de Souza, B. P.; Uchôa, A.; and de O. Costa, D.\n\n\n \n\n\n\n In Proceedings of the XVIII Brazilian Symposium on Information Systems (SBSI), 2022, Curitiba, Brazil, May 16–19, pages 1–8, 2022. \n \n\n\n\n
\n\n\n\n \n \n \"TEl-IoT:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 5 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{souza2022tel,\n  title={TEl-IoT: A Template for Eliciting IoT Software System Requirements},\n  author={Sabrina R. de Souza and Bruno P. de Souza and Anderson Uchôa and Daniella de O. Costa},\n  booktitle={Proceedings of the XVIII Brazilian Symposium on Information Systems (SBSI), 2022, Curitiba, Brazil, May 16--19},\n  pages={1--8},\n  year={2022},\n  isbn = {9781450396981},\n  abstract={Context: The Internet of Things (IoT) is a network of physical objects and system connected through mutual communication protocols. IoT systems have specific characteristics such as, self-configuration, dynamic changes, device and software heterogeneity. Goal: As IoT systems incorporate several components of the software, hardware, communication, and other features, building requirements documents to such systems become a challenge for Requirements Engineering (RE). Thus, this paper presents TEl-IoT, a template to aid developers during the requirements elicitation activities for IoT systems. Method: We conducted three evidence-based studies. We first performed a literature review aiming to identify artifacts that support requirements elicitation and specification for IoT systems. Second, based on the literature review, we proposed the initial version of the TEl-IoT. Finally, we performed two empirical studies to assess the TEl-IoT: (i) feasibility study with industry regarding the first version of TEl-IoT, and (ii) an observational study to understand how students apply the TEl-IoT in an IoT project. Results: Our results showed that TEl-IoT is viable, and its use reduces the time spent on requirements elicitation, in comparison with the ad-hoc way. In addition, our qualitative results also suggested that the use of TEl-IoT facilitates the requirements elicitation for IoT systems. Conclusion: We expect our template to guide requirements elicitation for IoT systems in practice. Our results showed that TEl-IoT can support developers and contribute to the body of knowledge about RE applicable in the IoT context.},\n  url={https://anderson-uchoa.github.io/publications/souza2022tel.pdf},\n  doi = {10.1145/3535511.3535538}\n}\n\n
\n
\n\n\n
\n Context: The Internet of Things (IoT) is a network of physical objects and system connected through mutual communication protocols. IoT systems have specific characteristics such as, self-configuration, dynamic changes, device and software heterogeneity. Goal: As IoT systems incorporate several components of the software, hardware, communication, and other features, building requirements documents to such systems become a challenge for Requirements Engineering (RE). Thus, this paper presents TEl-IoT, a template to aid developers during the requirements elicitation activities for IoT systems. Method: We conducted three evidence-based studies. We first performed a literature review aiming to identify artifacts that support requirements elicitation and specification for IoT systems. Second, based on the literature review, we proposed the initial version of the TEl-IoT. Finally, we performed two empirical studies to assess the TEl-IoT: (i) feasibility study with industry regarding the first version of TEl-IoT, and (ii) an observational study to understand how students apply the TEl-IoT in an IoT project. Results: Our results showed that TEl-IoT is viable, and its use reduces the time spent on requirements elicitation, in comparison with the ad-hoc way. In addition, our qualitative results also suggested that the use of TEl-IoT facilitates the requirements elicitation for IoT systems. Conclusion: We expect our template to guide requirements elicitation for IoT systems in practice. Our results showed that TEl-IoT can support developers and contribute to the body of knowledge about RE applicable in the IoT context.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n On the Influential Interactive Factors on Degrees of Design Decay: A Multi-Project Study.\n \n \n \n \n\n\n \n Coutinho, D.; Uchôa, A.; Barbosa, C.; Soares, V.; Garcia, A.; Schots, M.; Pereira, J. A.; and Assunção, W. K. G.\n\n\n \n\n\n\n In Proceedings of the 29th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, Honolulu, Hawaii, March 15–18, pages 1–12, 2022. \n \n\n\n\n
\n\n\n\n \n \n \"OnPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 2 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{coutinho2022on,\n  title={On the Influential Interactive Factors on Degrees of Design Decay: A Multi-Project Study},\n  author={Daniel Coutinho and Anderson Uchôa and Caio Barbosa and Vinícius Soares and Alessandro Garcia and Marcelo Schots and Juliana Alves Pereira and Wesley K. G. Assunção},\n  booktitle={Proceedings of the 29th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, Honolulu, Hawaii, March 15--18},\n  pages={1--12},\n  year={2022},\n  abstract={Developers constantly perform code changes throughout the lifetime of a project. These changes may induce the introduction of design problems (design decay) over time, which may be reduced or accelerated by interacting with different factors (e.g., refactorings) that underlie each change. However, existing studies lack evidence about how these factors interact and influence design decay. Thus, this paper reports a study aimed at investigating whether and how (associations of) process and developer factors influence design decay. We studied seven software systems, containing an average of 45K commits in more than six years of project history. Design decay was characterized in terms of five internal quality attributes: cohesion, coupling, complexity, inheritance, and size. We observed and characterized 12 (sub-)factors and how they associate with design decay. To this end, we employed association rule mining. Moreover, we also differentiate between the associations found on modules with varying levels of decay. Process-and developer-related factors played a key role in discriminating these different levels of design decay. Then, we focused on analyzing the effects of potentially interacting factors regarding slightly-and largely-decayed modules. Finally, we observed diverging decay patterns in these modules. For example, individually, the developer-related sub-factor that represented first-time contributors, as well as the process-related one that represented the size of a change did not have negative effects on the changed classes. However, when analyzing specific factor interactions, we saw that changes in which both of these factors interacted tended to have a negative effect on the code, leading to decay.},\n  url={https://anderson-uchoa.github.io/publications/coutinho2022on.pdf},\n  doi = {10.1109/SANER53432.2022.00093}\n}\n\n
\n
\n\n\n
\n Developers constantly perform code changes throughout the lifetime of a project. These changes may induce the introduction of design problems (design decay) over time, which may be reduced or accelerated by interacting with different factors (e.g., refactorings) that underlie each change. However, existing studies lack evidence about how these factors interact and influence design decay. Thus, this paper reports a study aimed at investigating whether and how (associations of) process and developer factors influence design decay. We studied seven software systems, containing an average of 45K commits in more than six years of project history. Design decay was characterized in terms of five internal quality attributes: cohesion, coupling, complexity, inheritance, and size. We observed and characterized 12 (sub-)factors and how they associate with design decay. To this end, we employed association rule mining. Moreover, we also differentiate between the associations found on modules with varying levels of decay. Process-and developer-related factors played a key role in discriminating these different levels of design decay. Then, we focused on analyzing the effects of potentially interacting factors regarding slightly-and largely-decayed modules. Finally, we observed diverging decay patterns in these modules. For example, individually, the developer-related sub-factor that represented first-time contributors, as well as the process-related one that represented the size of a change did not have negative effects on the changed classes. However, when analyzing specific factor interactions, we saw that changes in which both of these factors interacted tended to have a negative effect on the code, leading to decay.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2021\n \n \n (4)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n Do Critical Components Smell Bad? An Empirical Study with Component-based Software Product Lines.\n \n \n \n \n\n\n \n Uchôa, A.; Assunção, W. K.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 15th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2021, Joinville, Brazil, September 27 to October 1, pages 1–10, 2021. \n Distinguished Paper Award – 2nd Place \n\n\n\n
\n\n\n\n \n \n \"DoPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 5 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{uchoa2021do,\n  title={Do Critical Components Smell Bad? An Empirical Study with Component-based Software Product Lines},\n  author={Anderson Uchôa and Wesley K.G. Assunção and Alessandro Garcia},\n  booktitle={Proceedings of the 15th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS), 2021, Joinville, Brazil, September 27 to October 1},\n  pages={1--10},\n  note={<font color="red"> Distinguished Paper Award -- 2nd Place </font>},\n  year={2021},\n  abstract={Component-based software product line (SPL) consists of a set of software products that share common components. For a proper SPL product composition, each component has to follow three principles: encapsulating a single feature, restricting data access, and be replaceable. However, it is known that developers usually introduce anomalous structures, i.e., code smells, along the implementation of components. These code smells might violate one or more component principles and hinder the SPL product composition. Thus, developers should identify code smells in component-based SPLs, especially those affecting highly interconnected components, which are called critical components. Nevertheless, there is limited evidence of how smelly these critical components tend to be in component-based SPLs. To address this limitation, this paper presents a survey with developers of three SPLs. We inquire these developers about their perceptions of a critical component. Then, we characterize critical components per SPL, and identify nine recurring types of code smells. Finally, we quantitatively assess the smelliness of the critical components. Our results suggest that: (i) critical components are ten times more prone to have code smells than non-critical ones; (ii) the most frequent code smell types affecting critical components violate several component principles together; and (iii) these smell types affect multiple SPL components.},\n  url={https://anderson-uchoa.github.io/publications/uchoa2021do.pdf},\n  doi = {10.1145/3483899.3483907}\n}\n\n
\n
\n\n\n
\n Component-based software product line (SPL) consists of a set of software products that share common components. For a proper SPL product composition, each component has to follow three principles: encapsulating a single feature, restricting data access, and be replaceable. However, it is known that developers usually introduce anomalous structures, i.e., code smells, along the implementation of components. These code smells might violate one or more component principles and hinder the SPL product composition. Thus, developers should identify code smells in component-based SPLs, especially those affecting highly interconnected components, which are called critical components. Nevertheless, there is limited evidence of how smelly these critical components tend to be in component-based SPLs. To address this limitation, this paper presents a survey with developers of three SPLs. We inquire these developers about their perceptions of a critical component. Then, we characterize critical components per SPL, and identify nine recurring types of code smells. Finally, we quantitatively assess the smelliness of the critical components. Our results suggest that: (i) critical components are ten times more prone to have code smells than non-critical ones; (ii) the most frequent code smell types affecting critical components violate several component principles together; and (iii) these smell types affect multiple SPL components.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n How do Code Smell Co-occurrences Removal Impact Internal Quality Attributes? A Developers' Perspective.\n \n \n \n \n\n\n \n Martins, J.; Bezerra, C.; Uchôa, A.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 35th Brazilian Symposium on Software Engineering (SBES), 2021, Joinville, Brazil, September 27 to October 1, pages 1–10, 2021. \n \n\n\n\n
\n\n\n\n \n \n \"HowPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 1 download\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{martins2021how,\n  title={How do Code Smell Co-occurrences Removal Impact Internal Quality Attributes? A Developers' Perspective},\n  author={Júlio Martins and Carla Bezerra and Anderson Uchôa and Alessandro Garcia},\n  booktitle={Proceedings of the 35th Brazilian Symposium on Software Engineering (SBES), 2021, Joinville, Brazil, September 27 to October 1},\n  pages={1--10},\n  year={2021},\n  abstract={Code smells are poor code structures that might harm the software quality and evolution. However, previous studies has shown that only individual occurrences of smells may not be enough to assess the real impact that these smells can bring on systems. In this context, the co-occurrences of code smells, i.e., occurrences of more than one code smell in the same class or same method, can be better indicators of design problems for software quality. Despite its importance as an indicator of design problems, we have little known about the impact of removing the co-occurrence of smells via software refactoring on internal quality attributes, such as coupling, cohesion, complexity, and inheritance. It is even less clear on what is the developers' perspective on the co-occurrences removal. We aim at addressing this gap through a qualitative study with 14 developers. To this end, we analyze the refactorings employed by developers during the removal of 60 code smells co-occurrences, during 3 months in 5 closed-source projects. We observe (i) impact of code smells co-occurrences on internal quality attributes, (ii) which are the most harmful co-occurrences from the developers’ perspective, (iii) developers' perceptions during the removal of code smells co-occurrence via refactoring activities; and (iv) what are the main difficulties faced by developers during the removal of code smells co-occurrences in practice. Our findings indicate that: (i) the refactoring of some types of code smells co-occurrences (e.g., Dispersed Coupling--God Class) indicated improvement for the quality attributes; (ii) refactoring code smells co-occurrences according to the developers is difficult mainly due to the understanding of the code and complexity refactoring methods; and (iii) developers still have insecurities regarding the identification and refactoring of code smells and their co-occurrences.},\n  url={https://anderson-uchoa.github.io/publications/julio2021how.pdf},\n  doi = {10.1145/3474624.3474642}\n}\n\n
\n
\n\n\n
\n Code smells are poor code structures that might harm the software quality and evolution. However, previous studies has shown that only individual occurrences of smells may not be enough to assess the real impact that these smells can bring on systems. In this context, the co-occurrences of code smells, i.e., occurrences of more than one code smell in the same class or same method, can be better indicators of design problems for software quality. Despite its importance as an indicator of design problems, we have little known about the impact of removing the co-occurrence of smells via software refactoring on internal quality attributes, such as coupling, cohesion, complexity, and inheritance. It is even less clear on what is the developers' perspective on the co-occurrences removal. We aim at addressing this gap through a qualitative study with 14 developers. To this end, we analyze the refactorings employed by developers during the removal of 60 code smells co-occurrences, during 3 months in 5 closed-source projects. We observe (i) impact of code smells co-occurrences on internal quality attributes, (ii) which are the most harmful co-occurrences from the developers’ perspective, (iii) developers' perceptions during the removal of code smells co-occurrence via refactoring activities; and (iv) what are the main difficulties faced by developers during the removal of code smells co-occurrences in practice. Our findings indicate that: (i) the refactoring of some types of code smells co-occurrences (e.g., Dispersed Coupling–God Class) indicated improvement for the quality attributes; (ii) refactoring code smells co-occurrences according to the developers is difficult mainly due to the understanding of the code and complexity refactoring methods; and (iii) developers still have insecurities regarding the identification and refactoring of code smells and their co-occurrences.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Unveiling Multiple Facets of Design Degradation in Modern Code Review.\n \n \n \n \n\n\n \n Uchôa, A.\n\n\n \n\n\n\n In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2021), 2021, Athens, Greece, August 23–28, pages 1615–1619, 2021. \n \n\n\n\n
\n\n\n\n \n \n \"UnveilingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 9 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{uchoa2021unveiling,\n  title={Unveiling Multiple Facets of Design Degradation in Modern Code Review},\n  author={Uchôa, Anderson},\n  booktitle={Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2021), 2021, Athens, Greece, August 23--28},\n  pages={1615–1619},\n  year={2021},\n  abstract={Software design is a key concern in code review through which developers actively discuss and improve each code change. Nevertheless, code review is predominantly a cooperative task influenced by both technical and social aspects. Consequently, these aspects can play a key role in how software design degrades as well as contributing to accelerating or reversing the degradation during the process of each single code change’s review. However, there is little understanding about such social and technical aspects relates to either the reduction or the increase of design degradation as the project evolves. Consequently, the scarce knowledge on this topic helps little in properly guiding developers along design-driven code reviews. Our goal in this Doctoral research is three-fold: (1)to characterize the impact of code review and their practices on design degradation over time; (2) to understand the contribution of technical and social aspects to design degradation; and (3) to propose a conceptual framework to support design-decision making during code review. Our preliminary results show that the majority of code reviews had little to no design degradation impact, and that technical and social aspects contribute to distinguishing and predicting design impactful changes.},\n  url={https://anderson-uchoa.github.io/publications/uchoa2021unveiling.pdf},\n  doi = {10.1145/3468264.3473099}\n}\n\n
\n
\n\n\n
\n Software design is a key concern in code review through which developers actively discuss and improve each code change. Nevertheless, code review is predominantly a cooperative task influenced by both technical and social aspects. Consequently, these aspects can play a key role in how software design degrades as well as contributing to accelerating or reversing the degradation during the process of each single code change’s review. However, there is little understanding about such social and technical aspects relates to either the reduction or the increase of design degradation as the project evolves. Consequently, the scarce knowledge on this topic helps little in properly guiding developers along design-driven code reviews. Our goal in this Doctoral research is three-fold: (1)to characterize the impact of code review and their practices on design degradation over time; (2) to understand the contribution of technical and social aspects to design degradation; and (3) to propose a conceptual framework to support design-decision making during code review. Our preliminary results show that the majority of code reviews had little to no design degradation impact, and that technical and social aspects contribute to distinguishing and predicting design impactful changes.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Predicting Design Impactful Changes in Modern Code Review: A Large-Scale Empirical Study.\n \n \n \n \n\n\n \n Uchôa, A.; Barbosa, C.; Coutinho, D.; Oizumi, W.; K. G. Assunção, W.; Regina Vergilio, S.; Alves Pereira, J.; Oliveira, A.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 18th International Conference on Mining Software Repositories (MSR 2021), 2021, Madrid, Spain, May 17–19, pages 1 – 12, 2021. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"PredictingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 33 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaBCOARVAPOG21,\n  title={Predicting Design Impactful Changes in Modern Code Review: A Large-Scale Empirical Study},\n  author={Uchôa, Anderson and Barbosa, Caio and Coutinho, Daniel and Oizumi, Willian and K. G. Assunção, Wesley and Regina Vergilio, Silvia and Alves Pereira, Juliana and Oliveira, Anderson and Garcia, Alessandro},\n  booktitle={Proceedings of the 18th International Conference on Mining Software Repositories (MSR 2021), 2021, Madrid, Spain, May 17--19},\n  pages={1 -- 12},\n  year={2021},\n  abstract={Companies have adopted modern code review as a key technique for continuously monitoring and improving the quality of software changes. One of the main motivations for this is the early detection of design impactful changes, to prevent that design-degrading ones prevail after each code review. Even though design degradation symptoms often lead to changes' rejections, practices of modern code review alone are actually not sufficient to avoid or mitigate design decay. Software design degrades whenever one or more symptoms of poor structural decisions, usually represented by smells, end up being introduced by a change. Design degradation may be related to both technical and social aspects in collaborative code reviews. Unfortunately, there is no study that investigates if code review stakeholders, e.g, reviewers, could benefit from approaches to distinguish and predict design impactful changes with technical and/or social aspects. By analyzing 57,498 reviewed code changes from seven open-source systems, we report an investigation on prediction of design impactful changes in modern code review. We evaluated the use of six ML algorithms to predict design impactful changes. We also extracted and assessed 41 different features based on both social and technical aspects. Our results show that Random Forest and Gradient Boosting are the best algorithms. We also observed that the use of technical features results in more precise predictions. However, the use of social features alone, which are available even before the code review starts (e.g., for team managers or change assigners), also leads to highly-accurate prediction. Therefore social and/or technical prediction models can be used to support further design inspection of suspicious changes early in a code review process. Finally, we provide an enriched dataset that allows researchers to investigate the context behind design impactful changes during the code review process.},\n  organization={IEEE Press},\n  url={https://anderson-uchoa.github.io/publications/UchoaBCOARVAPOG21.pdf},\n  doi = {10.1109/MSR52588.2021.00059}\n}\n\n
\n
\n\n\n
\n Companies have adopted modern code review as a key technique for continuously monitoring and improving the quality of software changes. One of the main motivations for this is the early detection of design impactful changes, to prevent that design-degrading ones prevail after each code review. Even though design degradation symptoms often lead to changes' rejections, practices of modern code review alone are actually not sufficient to avoid or mitigate design decay. Software design degrades whenever one or more symptoms of poor structural decisions, usually represented by smells, end up being introduced by a change. Design degradation may be related to both technical and social aspects in collaborative code reviews. Unfortunately, there is no study that investigates if code review stakeholders, e.g, reviewers, could benefit from approaches to distinguish and predict design impactful changes with technical and/or social aspects. By analyzing 57,498 reviewed code changes from seven open-source systems, we report an investigation on prediction of design impactful changes in modern code review. We evaluated the use of six ML algorithms to predict design impactful changes. We also extracted and assessed 41 different features based on both social and technical aspects. Our results show that Random Forest and Gradient Boosting are the best algorithms. We also observed that the use of technical features results in more precise predictions. However, the use of social features alone, which are available even before the code review starts (e.g., for team managers or change assigners), also leads to highly-accurate prediction. Therefore social and/or technical prediction models can be used to support further design inspection of suspicious changes early in a code review process. Finally, we provide an enriched dataset that allows researchers to investigate the context behind design impactful changes during the code review process.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2020\n \n \n (6)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n Visualizing the Maintainability of Feature Models in SPLs.\n \n \n \n \n\n\n \n Lima, L.; Uchôa, A.; Bezerra, C.; Coutinho, E.; and Rocha, L.\n\n\n \n\n\n\n In Proceedings of the 8th Workshop on Software Visualization, Evolution and Maintenance (VEM 2020), 2020, Natal, Brazil, Oct 19, pages 1 – 8, 2020. \n \n\n\n\n
\n\n\n\n \n \n \"VisualizingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 15 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{LimaUCCL20,\n  title={Visualizing the Maintainability of Feature Models in SPLs},\n  author={Lima, Luan and Uchôa, Anderson and Bezerra, Carla and Coutinho, Emanuel and Rocha, Lincoln},\n  booktitle={Proceedings of the 8th Workshop on Software Visualization, Evolution and Maintenance (VEM 2020), 2020, Natal, Brazil, Oct 19},\n  pages={1 -- 8},\n  year={2020},\n  abstract={This paper presents data visualizations obtained from the application of 15 measures used to support the maintainability evaluation of Software Product Line (SPL) and Dynamic SPL (DSPL) Feature Models (FMs). To identify these visualizations, we applied a survey to classify a set of 40 measures for evaluating the (D)SPL FMs maintainability. Five visualizations were designed from this classification to analyze the extensibility, static variability, dynamic variability, and structural complexity of the FMs. As result, the experts concluded the designed visualizations assist in FMs maintainability interpretation.},\n  url={https://anderson-uchoa.github.io/publications/LimaUCCL20.pdf},\n  doi = {10.5753/vem.2020.14522},\n}\n\n
\n
\n\n\n
\n This paper presents data visualizations obtained from the application of 15 measures used to support the maintainability evaluation of Software Product Line (SPL) and Dynamic SPL (DSPL) Feature Models (FMs). To identify these visualizations, we applied a survey to classify a set of 40 measures for evaluating the (D)SPL FMs maintainability. Five visualizations were designed from this classification to analyze the extensibility, static variability, dynamic variability, and structural complexity of the FMs. As result, the experts concluded the designed visualizations assist in FMs maintainability interpretation.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n On the Relation between Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Concerns.\n \n \n \n \n\n\n \n Soares, V.; Oliveira, A.; Farah, P.; Bibiano, A.; Coutinho, D.; Garcia, A.; Vergilio, S.; Schots, M.; Oliveira, D.; and Uchôa, A.\n\n\n \n\n\n\n In Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23, pages 788–797, 2020. ACM Press\n \n\n\n\n
\n\n\n\n \n \n \"OnPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 16 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{SoaresOFBCGVSOU20,\n  title={On the Relation between Complexity, Explicitness, Effectiveness of Refactorings and Non-Functional Concerns},\n  author={Soares, Vinícius and Oliveira, Anderson and Farah, Paulo and Bibiano, Ana and Coutinho, Daniel and Garcia, Alessandro and Vergilio, Silvia and Schots, Marcelo and Oliveira, Daniel and Uchôa, Anderson},\n  booktitle={Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23},\n  pages={788--797},\n  year={2020},\n  abstract={Developers need to consistently improve the internal structural quality of a program to address its maintainability and possibly other non-functional concerns. Refactoring is the main practice to improve code quality. Typical refactoring factors, such as their complexity and explicitness (i.e., their self-affirmation), may influence its effectiveness in improving key internal code attributes, such as enhancing cohesion or reducing its coupling, complexity and size. However, we still lack an understanding of whether such concerns and factors play a role on improving the code structural quality. Thus, this paper investigates the relationship between complexity, explicitness and effectiveness of refactorings and non-functional concerns in four projects. We study four non-functional concerns, namely maintainability, security, performance, and robustness. Our findings reveal that complex refactorings indeed have an impactful effect on the code structure, either improving or reducing the code structural quality. We also found that both self-affirmed refactorings and non-functional concerns are usually accompanied by complex refactorings, but tend to have a negative effect on code structural quality. Our findings can: (i) help researchers to improve the design of empirical studies and refactoring-related tools, and (ii) warn practitioners on which circumstances their refactorings may cause a negative impact on code quality.},\n  organization={ACM Press},\n  url={https://anderson-uchoa.github.io/publications/SoaresOFBCGVSOU20.pdf},\n  doi = {10.1145/3422392.3422439}\n}\n\n
\n
\n\n\n
\n Developers need to consistently improve the internal structural quality of a program to address its maintainability and possibly other non-functional concerns. Refactoring is the main practice to improve code quality. Typical refactoring factors, such as their complexity and explicitness (i.e., their self-affirmation), may influence its effectiveness in improving key internal code attributes, such as enhancing cohesion or reducing its coupling, complexity and size. However, we still lack an understanding of whether such concerns and factors play a role on improving the code structural quality. Thus, this paper investigates the relationship between complexity, explicitness and effectiveness of refactorings and non-functional concerns in four projects. We study four non-functional concerns, namely maintainability, security, performance, and robustness. Our findings reveal that complex refactorings indeed have an impactful effect on the code structure, either improving or reducing the code structural quality. We also found that both self-affirmed refactorings and non-functional concerns are usually accompanied by complex refactorings, but tend to have a negative effect on code structural quality. Our findings can: (i) help researchers to improve the design of empirical studies and refactoring-related tools, and (ii) warn practitioners on which circumstances their refactorings may cause a negative impact on code quality.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Are Code Smell Co-occurrences Harmful to Internal Quality Attributes? A Mixed-Method Study.\n \n \n \n \n\n\n \n Martins, J.; Uchôa, A.; Bezerra, C.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23, pages 52–61, 2020. ACM Press\n \n\n\n\n
\n\n\n\n \n \n \"ArePaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 13 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{MartinsABA20,\n  title={Are Code Smell Co-occurrences Harmful to Internal Quality Attributes? A Mixed-Method Study},\n  author={Martins, Júlio and Uchôa, Anderson and Bezerra, Carla and Garcia, Alessandro},\n  booktitle={Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23},\n  pages={52--61},\n  year={2020},\n  abstract={Previous studies demonstrated how code smells (i.e., symptoms of the presence of system degradation) impact the software maintainability. However, few studies have investigated which code smell types tend to co-occur in the source code. Moreover, it is not clear to what extent the removal of code smell co-occurrences -- through refactoring operations -- has a positive impact on quality attributes such as cohesion, coupling, inheritance, complexity, and size. We aim at addressing these gaps through an empirical study. By investigating the impact of the smells co-occurrences in 11 releases of 3 closed-source systems, we observe (i) which code smells tend to co-occur together, (ii) the impact of the removal of code smell co-occurrences on quality internal attributes before and after refactoring, and (iii) which are the most difficult co-occurrences to refactoring from the developers perspective. Our results show that 5 types of code smell generally tend to co-occur (e.g, Feature Envy, and Long Method). Moreover, we observed that the removal of code smells co-occurrences lead to a significant reduction in the complexity of the systems studied was obtained. Conversely, cohesion, coupling, and inheritance tend to increase. Based on our findings, we argue that further research is needed on the impact of co-occurrences of code smells on internal quality attributes.},\t\n  organization={ACM Press},\n  url={https://anderson-uchoa.github.io/publications/MartinsABA20.pdf},\n  doi = {10.1145/3422392.3422419}\n}\n\n
\n
\n\n\n
\n Previous studies demonstrated how code smells (i.e., symptoms of the presence of system degradation) impact the software maintainability. However, few studies have investigated which code smell types tend to co-occur in the source code. Moreover, it is not clear to what extent the removal of code smell co-occurrences – through refactoring operations – has a positive impact on quality attributes such as cohesion, coupling, inheritance, complexity, and size. We aim at addressing these gaps through an empirical study. By investigating the impact of the smells co-occurrences in 11 releases of 3 closed-source systems, we observe (i) which code smells tend to co-occur together, (ii) the impact of the removal of code smell co-occurrences on quality internal attributes before and after refactoring, and (iii) which are the most difficult co-occurrences to refactoring from the developers perspective. Our results show that 5 types of code smell generally tend to co-occur (e.g, Feature Envy, and Long Method). Moreover, we observed that the removal of code smells co-occurrences lead to a significant reduction in the complexity of the systems studied was obtained. Conversely, cohesion, coupling, and inheritance tend to increase. Based on our findings, we argue that further research is needed on the impact of co-occurrences of code smells on internal quality attributes.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Revealing the Social Aspects of Design Decay: A Retrospective Study of Pull Requests.\n \n \n \n \n\n\n \n Barbosa, C.; Uchôa, A.; Falcao, F.; Coutinho, D.; Brito, H.; Amaral, G.; Garcia, A.; Fonseca, B.; Ribeiro, M.; Soares, V.; and Sousa, L.\n\n\n \n\n\n\n In Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23, pages 364–373, 2020. ACM Press\n \n\n\n\n
\n\n\n\n \n \n \"RevealingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 38 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{BarbosaAFDHGAFMVL20,\n  title={Revealing the Social Aspects of Design Decay: A Retrospective Study of Pull Requests},\n  author={Barbosa, Caio and Uchôa, Anderson and Falcao, Filipe and Coutinho, Daniel and Brito, Hyago and Amaral, Guilherme and Garcia, Alessandro, and Fonseca, Baldoino, and Ribeiro, Marcio and Soares, Vinicius and Sousa, Leonardo},\n  booktitle={Proceedings of the 34th Brazilian Symposium on Software Engineering (SBES), 2020, Natal, Brazil, Oct 19-23},\n  pages={364--373},\n  year={2020},\n  abstract={The pull-based development model, popularized by social coding environments like GitHub, is widely used by open-source communities. In this model, developers actively communicate and share their knowledge or opinions through the exchange of comments. Their goal is to improve the change under development, including its positive impact on design structure. In this context, two central social aspects may contribute to combating or adversely amplifying design decay. First, design decay may be avoided, reduced or accelerated depending whether the communication dynamics among developers -- who play specific roles -- is fluent and consistent along a change. Second, the discussion content itself may be decisive to either improve or deteriorate the structural design of a system. Unfortunately, it has not been studied so far the role these key social aspects play on avoiding or amplifying design decay. Previous work either investigates technical aspects of design decay or confirms the high frequency of design discussions in pull-based software development. This paper reports a retrospective study aimed at understanding the role of communication dynamics and discussion content on design decay. We focused our analysis on 11 social metrics related to these two aspects as well as 4 control technical metrics typically used as indicators of design decay. We analyzed more than 11k pull request discussions mined from five large open-source software systems. Our findings reveal that many social metrics can be used to discriminate between design impactful and unimpactful pull requests. Second, various factors of communication dynamics are related to design decay. However, temporal factors of communication dynamics outperformed the participant roles' factors as indicators of design decay. Finally, we noticed certain social metrics tend to be indicators of design decay when analyzing both aspects together.},\t\n  organization={ACM Press},\n  url={https://anderson-uchoa.github.io/publications/BarbosaAFDHGAFMVL20.pdf},\n  doi = {10.1145/3422392.3422443}\n}\n\n
\n
\n\n\n
\n The pull-based development model, popularized by social coding environments like GitHub, is widely used by open-source communities. In this model, developers actively communicate and share their knowledge or opinions through the exchange of comments. Their goal is to improve the change under development, including its positive impact on design structure. In this context, two central social aspects may contribute to combating or adversely amplifying design decay. First, design decay may be avoided, reduced or accelerated depending whether the communication dynamics among developers – who play specific roles – is fluent and consistent along a change. Second, the discussion content itself may be decisive to either improve or deteriorate the structural design of a system. Unfortunately, it has not been studied so far the role these key social aspects play on avoiding or amplifying design decay. Previous work either investigates technical aspects of design decay or confirms the high frequency of design discussions in pull-based software development. This paper reports a retrospective study aimed at understanding the role of communication dynamics and discussion content on design decay. We focused our analysis on 11 social metrics related to these two aspects as well as 4 control technical metrics typically used as indicators of design decay. We analyzed more than 11k pull request discussions mined from five large open-source software systems. Our findings reveal that many social metrics can be used to discriminate between design impactful and unimpactful pull requests. Second, various factors of communication dynamics are related to design decay. However, temporal factors of communication dynamics outperformed the participant roles' factors as indicators of design decay. Finally, we noticed certain social metrics tend to be indicators of design decay when analyzing both aspects together.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n How Does Modern Code Review Impact Software Design Degradation? An In-depth Empirical Study.\n \n \n \n \n\n\n \n Uchôa, A.; Barbosa, C.; Oizumi, W.; Blenilio, P.; Lima, R.; Garcia, A.; and Bezerra, C.\n\n\n \n\n\n\n In Proceedings of the 36th International Conference on Software Maintenance and Evolution (ICSME), 2020, Adelaide, Australia, Sept 27-Oct 3, pages 511–522, 2020. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"HowPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 101 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaCWPRAC20,\n  title={How Does Modern Code Review Impact Software Design Degradation? An In-depth Empirical Study},\n  author={Uchôa, Anderson and Barbosa, Caio and Oizumi, Willian and Blenilio, Publio and Lima, Rafael and Garcia, Alessandro and Bezerra, Carla},\n  booktitle={Proceedings of the 36th International Conference on Software Maintenance and Evolution (ICSME), 2020, Adelaide, Australia, Sept 27-Oct 3},\n  pages={511--522},\n  year={2020},\n  abstract={Software design is an important concern in modern code review through which multiple developers actively discuss and improve each single code change. However, there is little understanding of the impact of such developers' reviews on continuously reducing design degradation over time. It is even less clear to what extent and how design degradation is reversed during the process of each single code change's review. In summary, existing studies have not assessed how the process of design degradation evolution is impacted along: (i) within each single review, and (ii) across multiple reviews. As a consequence, one cannot understand how certain code review practices consistently contribute to either reduce or further increase design degradation as the project evolves. We aim at addressing these gaps through a multi-project retrospective study. By investigating 14,971 code reviews from seven software projects, we report the first study that characterizes how the process of design degradation evolves within each review and across multiple reviews. Moreover, we analyze a comprehensive suite of metrics to enable us to observe the influence of certain code review practices on combating or even accelerating design degradation. Our results show that the majority of code reviews had little to no design degradation impact in the analyzed projects. Even worse, this observation also applies, to some extent, to reviews with an explicit concern on design. Surprisingly, the practices of long discussions and high proportion of review disagreement in code reviews were found to increase design degradation. Finally, we also discuss how the study findings shed light on how to improve the research and practice of modern code review.},\t\n  organization={IEEE Press},\n  url={https://anderson-uchoa.github.io/publications/UchoaCWPRAC20.pdf},\n  doi = {10.1109/ICSME46990.2020.00055}\n}\n\n
\n
\n\n\n
\n Software design is an important concern in modern code review through which multiple developers actively discuss and improve each single code change. However, there is little understanding of the impact of such developers' reviews on continuously reducing design degradation over time. It is even less clear to what extent and how design degradation is reversed during the process of each single code change's review. In summary, existing studies have not assessed how the process of design degradation evolution is impacted along: (i) within each single review, and (ii) across multiple reviews. As a consequence, one cannot understand how certain code review practices consistently contribute to either reduce or further increase design degradation as the project evolves. We aim at addressing these gaps through a multi-project retrospective study. By investigating 14,971 code reviews from seven software projects, we report the first study that characterizes how the process of design degradation evolves within each review and across multiple reviews. Moreover, we analyze a comprehensive suite of metrics to enable us to observe the influence of certain code review practices on combating or even accelerating design degradation. Our results show that the majority of code reviews had little to no design degradation impact in the analyzed projects. Even worse, this observation also applies, to some extent, to reviews with an explicit concern on design. Surprisingly, the practices of long discussions and high proportion of review disagreement in code reviews were found to increase design degradation. Finally, we also discuss how the study findings shed light on how to improve the research and practice of modern code review.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Behind the Intents: An In-depth Empirical Study on Software Refactoring in Modern Code Review.\n \n \n \n \n\n\n \n Paixao, M.; Uchôa, A.; Bibiano, A. C.; Oliveira, D.; Garcia, A.; Krinke, J.; and Arnovio, E.\n\n\n \n\n\n\n In Proceedings of the 17th International Conference on Mining Software Repositories (MSR), 2020, Seoul, South Korea, May, pages 1 – 11, 2020. ACM\n \n\n\n\n
\n\n\n\n \n \n \"BehindPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 27 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{PaixaoAADAJA20,\n  title={Behind the Intents: An In-depth Empirical Study on Software Refactoring in Modern Code Review},\n  author={Paixao, Matheus and Uchôa, Anderson and Bibiano, Ana Carla and Oliveira, Daniel and Garcia, Alessandro and Krinke, Jens and Arnovio, Emilio},\n  booktitle={Proceedings of the 17th International Conference on Mining Software Repositories (MSR), 2020, Seoul, South Korea, May},\n  pages={1 -- 11},\n  year={2020},\nabstract={Code refactorings are of pivotal importance in modern code review. Developers may preserve, revisit, add or undo refactorings through changes' revisions. Their goal is to certify that the driving intent of a code change is properly achieved. Developers' intents behind refactorings may vary from pure structural improvement to facilitating feature additions and bug fixes. However, there is little understanding of the refactoring practices performed by developers during the code review process. It is also unclear whether the developers’ intents influence the selection, composition, and evolution of refactorings during the review of a code change. Through mining 1,780 reviewed code changes from 6 systems pertaining to two large open-source communities, we report the first in-depth empirical study on software refactoring during code review. We inspected and classified the developers’ intents behind each code change into 7 distinct categories. By analyzing data generated during the complete reviewing process, we observe: (i) how refactorings are selected, composed and evolved throughout each code change, and (ii) how developers' intents are related to these decisions. For instance, our analysis shows developers regularly apply non-trivial sequences of refactorings that crosscut multiple code elements (i.e., widely scattered in the program) to support a single feature addition. Moreover, we observed that new developers’ intents commonly emerge during the code review process, influencing how developers select and compose their refactorings to achieve the new and adapted goals. Finally, we provide an enriched dataset that allows researchers to investigate the context and motivations behind refactoring operations during the code review process.},\t\n  organization={ACM},\n  url = {https://anderson-uchoa.github.io/publications/PaixaoAADAJA20.pdf},\n  doi = {10.1145/3379597.3387475}\n}\n\n
\n
\n\n\n
\n Code refactorings are of pivotal importance in modern code review. Developers may preserve, revisit, add or undo refactorings through changes' revisions. Their goal is to certify that the driving intent of a code change is properly achieved. Developers' intents behind refactorings may vary from pure structural improvement to facilitating feature additions and bug fixes. However, there is little understanding of the refactoring practices performed by developers during the code review process. It is also unclear whether the developers’ intents influence the selection, composition, and evolution of refactorings during the review of a code change. Through mining 1,780 reviewed code changes from 6 systems pertaining to two large open-source communities, we report the first in-depth empirical study on software refactoring during code review. We inspected and classified the developers’ intents behind each code change into 7 distinct categories. By analyzing data generated during the complete reviewing process, we observe: (i) how refactorings are selected, composed and evolved throughout each code change, and (ii) how developers' intents are related to these decisions. For instance, our analysis shows developers regularly apply non-trivial sequences of refactorings that crosscut multiple code elements (i.e., widely scattered in the program) to support a single feature addition. Moreover, we observed that new developers’ intents commonly emerge during the code review process, influencing how developers select and compose their refactorings to achieve the new and adapted goals. Finally, we provide an enriched dataset that allows researchers to investigate the context and motivations behind refactoring operations during the code review process.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2019\n \n \n (9)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n On Gamifying an Existing Software System: Method, Conceptual Model and Lessons Learned.\n \n \n \n \n\n\n \n Uchôa, A. G.\n\n\n \n\n\n\n Master's thesis, Pontifical Catholic University of Rio de Janeiro (PUC-Rio), 2019.\n \n\n\n\n
\n\n\n\n \n \n \"OnPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n\n \n  \n \n 10 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@mastersthesis{Uchoa19,\n  author    = {Anderson Gonçalves Uchôa}, \n  title     = {On Gamifying an Existing Software System: Method, Conceptual Model and Lessons Learned},\n  school    = {Pontifical Catholic University of Rio de Janeiro (PUC-Rio)},\n  year      = {2019},\n  doi = {https://doi.org/10.17771/PUCRio.acad.47298},\n  url       = {https://anderson-uchoa.github.io/publications/Uchoa19.pdf}\n}\n\n
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n REM4DSPL: A Requirements Engineering Method for Dynamic Software Product Lines.\n \n \n \n \n\n\n \n Sousa, A.; Uchôa, A.; Fernandes, E.; Bezerra, C. I.; Monteiro, J. M.; and Andrade, R.\n\n\n \n\n\n\n In Proceedings of the XVIII Brazilian Symposium on Software Quality (SBQS), 2019, Fortaleza, Brazil, Oct 28-Nov 1, pages 129–138, 2019. ACM\n \n\n\n\n
\n\n\n\n \n \n \"REM4DSPL:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 10 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{SousaAECJMRA19,\n  title={REM4DSPL: A Requirements Engineering Method for Dynamic Software Product Lines},\n  author={Sousa, Amanda and Uchôa, Anderson and Fernandes, Eduardo and Bezerra, Carla IM and Monteiro, José Maria and Andrade, Rossana},\n  booktitle={Proceedings of the XVIII Brazilian Symposium on Software Quality (SBQS), 2019, Fortaleza, Brazil, Oct 28-Nov 1},\n  pages={129--138},\n  year={2019},\nabstract={Context: Dynamic Software Product Line (DSPL) is a set of software products capable of self-adapt and configure in run-time. DSPL products have common features (commonalities) and varying features (managed in run-time according to context changes). Objective: DSPL requirements engineering is challenging. Requirements engineers have to carefully plan self-adaptation while eliciting, modeling, and managing variability requirements. This paper introduces a method for DSPL requirements engineering. Method: We relied on empirically-derived activities of DSPL requirements engineering to build our method. We selected techniques and templates used in other domains such as SPL for refinement and incorporation into the method. We asked DSPL experts on the method applicability. Result: We introduced the Requirements Engineering Method for DSPL (REM4DSPL). Elicitation is guided by supervised discussions. Modeling relies on feature models. Variability Management is tool-assisted and validated via feature model inspection. DSPL experts agreed on the method applicability and suggested improvements. Conclusion: REM4DSPL relies on empirically-derived activities, techniques that have been successfully used by previous work, and templates adapted to the DSPL context. We expect our method to guide requirements engineers in practice.},\t\n  organization={ACM},\nurl = {https://anderson-uchoa.github.io/publications/SousaAECJMRA19.pdf},\ndoi = {10.1145/3364641.3364656}\n}\n\n
\n
\n\n\n
\n Context: Dynamic Software Product Line (DSPL) is a set of software products capable of self-adapt and configure in run-time. DSPL products have common features (commonalities) and varying features (managed in run-time according to context changes). Objective: DSPL requirements engineering is challenging. Requirements engineers have to carefully plan self-adaptation while eliciting, modeling, and managing variability requirements. This paper introduces a method for DSPL requirements engineering. Method: We relied on empirically-derived activities of DSPL requirements engineering to build our method. We selected techniques and templates used in other domains such as SPL for refinement and incorporation into the method. We asked DSPL experts on the method applicability. Result: We introduced the Requirements Engineering Method for DSPL (REM4DSPL). Elicitation is guided by supervised discussions. Modeling relies on feature models. Variability Management is tool-assisted and validated via feature model inspection. DSPL experts agreed on the method applicability and suggested improvements. Conclusion: REM4DSPL relies on empirically-derived activities, techniques that have been successfully used by previous work, and templates adapted to the DSPL context. We expect our method to guide requirements engineers in practice.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Do Research and Practice of Code Smell Identification Walk Together? A Social Representations Analysis.\n \n \n \n \n\n\n \n de Mello, R.; Uchôa, A.; Oliveira, R.; Oizumi, W.; Souza, J.; Mendes, K.; Oliveira, D.; Fonseca, B.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 13th International Symposium on Empirical Software Engineering and Measurement (ESEM), 2019, Porto de Galinhas, Brazil, Sept 19-20., pages 1–6, 2019. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"DoPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 2 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{deMelloARWJKDBA19,\n  title={Do Research and Practice of Code Smell Identification Walk Together? A Social Representations Analysis},\n  author={Rafael de Mello and Anderson Uchôa and Roberto Oliveira and Willian Oizumi and Jairo Souza and Kleyson Mendes and Daniel Oliveira and Baldoino Fonseca and Alessandro Garcia},\n  booktitle={Proceedings of the 13th International Symposium on Empirical Software Engineering and Measurement (ESEM), 2019, Porto de Galinhas, Brazil, Sept 19-20.},\n  pages={1--6},\n  year={2019},\nabstract={Context: It is frequently claimed the need for bridging the gap between software engineering research and practice. In this sense, the theory of social representations may be useful to characterize the actual concerns of software developers. It comprises the system of values, behaviors, and practices of communities regarding a particular social object, such as the task of smell identification. Aim: To characterize the social representations of smell identification by software developers. Method: Based on the answers given to a questionnaire, we analyzed the associations made by the developers about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: We found that developers strongly associate smell identification with the practice of smell removal and with the incidence of bugs. They also frequently associate the task with the practice of inspection and with the need of having individual skills. Besides, we verified that the current state of the art on smell identification partially address the social representations of the software developers. Conclusion: There is a considerable gap between the research of smell identification and its practice. We propose directions to mitigating this gap.},\npublisher={IEEE Press},\nurl = {https://anderson-uchoa.github.io/publications/deMelloARWJKDBA19.pdf},\ndoi = {10.1109/ESEM.2019.8870141}\n}\n\n
\n
\n\n\n
\n Context: It is frequently claimed the need for bridging the gap between software engineering research and practice. In this sense, the theory of social representations may be useful to characterize the actual concerns of software developers. It comprises the system of values, behaviors, and practices of communities regarding a particular social object, such as the task of smell identification. Aim: To characterize the social representations of smell identification by software developers. Method: Based on the answers given to a questionnaire, we analyzed the associations made by the developers about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: We found that developers strongly associate smell identification with the practice of smell removal and with the incidence of bugs. They also frequently associate the task with the practice of inspection and with the need of having individual skills. Besides, we verified that the current state of the art on smell identification partially address the social representations of the software developers. Conclusion: There is a considerable gap between the research of smell identification and its practice. We propose directions to mitigating this gap.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Investigating the Social Representations of the Identification of Code Smells by Practitioners and Students from Brazil.\n \n \n \n \n\n\n \n de Mello, R.; Uchôa, A.; Oliveira, R.; Oliveira, D.; Oizumi, W.; Souza, J.; Fonseca, B.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 33nd Brazilian Symposium on Software Engineering (SBES), pages 457–466, 2019. ACM\n \n\n\n\n
\n\n\n\n \n \n \"InvestigatingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{deMelloARDWJBA2019,\n  title={Investigating the Social Representations of the Identification of Code Smells by Practitioners and Students from Brazil},\n  author={Rafael de Mello and Anderson Uchôa and Roberto Oliveira and Daniel Oliveira and Willian Oizumi and Jairo Souza and Baldoino Fonseca and Alessandro Garcia},\n  booktitle={Proceedings of the 33nd Brazilian Symposium on Software Engineering (SBES)},\n  pages={457--466},\n  year={2019},\nabstract={Context: The identification of code smells is one of the most subjective tasks in software engineering. A key reason is the influence of collective aspects of communities working on this task, such as their beliefs regarding the relevance of certain smells. However, collective aspects are often neglected in the context of smell identification. For this purpose, we can use the social representations theory. Social representations comprise the set of values, behaviors, and practices of communities associated with a social object, such as the task of identifying smells. Aim: To characterize the social representations behind smell identification. Method: We conducted an empirical study on the social representations of smell identification by two communities. One community is composed of postgraduate students from different Brazilian universities. The other community is composed of practitioners located in Brazilian companies, having different levels of experience in code reviews. We analyzed the associations made by the study participants about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: One of the key findings is that the community of students and practitioners have stronger associations with different types of code smells. Students share a strong belief that smell identification is a matter of measurement, while practitioners focus on the structure of the source code and its semantics. Besides, we found that only practitioners frequently associate the task with individual skills. This finding suggests research directions on code smells may be revisited. Conclusion: We found evidence that social representations theory allows identifying research gaps and opportunities by looking beyond the borders of formal knowledge and individual opinions. Therefore, this theory can be considered an important resource for conducting qualitative studies in software engineering.},\npublisher={ACM},\nurl = {https://anderson-uchoa.github.io/publications/deMelloARDWJBA19.pdf},\ndoi = {10.1145/3350768.3351794}\n}\n\n
\n
\n\n\n
\n Context: The identification of code smells is one of the most subjective tasks in software engineering. A key reason is the influence of collective aspects of communities working on this task, such as their beliefs regarding the relevance of certain smells. However, collective aspects are often neglected in the context of smell identification. For this purpose, we can use the social representations theory. Social representations comprise the set of values, behaviors, and practices of communities associated with a social object, such as the task of identifying smells. Aim: To characterize the social representations behind smell identification. Method: We conducted an empirical study on the social representations of smell identification by two communities. One community is composed of postgraduate students from different Brazilian universities. The other community is composed of practitioners located in Brazilian companies, having different levels of experience in code reviews. We analyzed the associations made by the study participants about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: One of the key findings is that the community of students and practitioners have stronger associations with different types of code smells. Students share a strong belief that smell identification is a matter of measurement, while practitioners focus on the structure of the source code and its semantics. Besides, we found that only practitioners frequently associate the task with individual skills. This finding suggests research directions on code smells may be revisited. Conclusion: We found evidence that social representations theory allows identifying research gaps and opportunities by looking beyond the borders of formal knowledge and individual opinions. Therefore, this theory can be considered an important resource for conducting qualitative studies in software engineering.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n On the Alternatives for Composing Batch Refactoring.\n \n \n \n \n\n\n \n Fernandes, E.; Uchôa, A.; Bibiano, A. C.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 3rd International Workshop on Refactoring (IWoR), pages 9–12, 2019. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"OnPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{FernandesAAA19,\n  title={On the Alternatives for Composing Batch Refactoring},\n  author={Eduardo Fernandes and Anderson Uchôa and Ana Carla Bibiano and Alessandro Garcia},\n  booktitle={Proceedings of the 3rd International Workshop on Refactoring (IWoR)},\n  pages={9--12},\n  year={2019},\nabstract={Code refactoring is often performed for improving code structures through code transformations. Many transformations, e.g., extracting or moving a method, are applied for at least partially removing code smells. Each code smell is a symptom of a poor code structure that makes hard to read and change the program. Developers often compose two or more interrelated transformations in conjunction (batch refactoring) rather than applying a single transformation. For instance, developers often compose method extractions with method motions to better organize the features realized by classes. We have recently observed cases of batch refactoring performed along with code review in open source projects. We then noticed that composing batches capable of fully removing code smells is quite challenging. Especially, it requires carefully discussing on how two or more transformations complement one another and what to expect from the batch effect on code smell. This position aims to reason about multiple alternatives to support developers on composing their batches. These alternatives should make it easier to compose batches that remove code smells. For this purpose, we exemplify the role of semi-automated tools in gradually recommending transformations, thereby guiding the batch composition in each alternative.},\nurl = {https://anderson-uchoa.github.io/publications/FernandesAAA19.pdf},\ndoi = {10.1109/IWoR.2019.00009},\npublisher={IEEE Press}\n}\n\n
\n
\n\n\n
\n Code refactoring is often performed for improving code structures through code transformations. Many transformations, e.g., extracting or moving a method, are applied for at least partially removing code smells. Each code smell is a symptom of a poor code structure that makes hard to read and change the program. Developers often compose two or more interrelated transformations in conjunction (batch refactoring) rather than applying a single transformation. For instance, developers often compose method extractions with method motions to better organize the features realized by classes. We have recently observed cases of batch refactoring performed along with code review in open source projects. We then noticed that composing batches capable of fully removing code smells is quite challenging. Especially, it requires carefully discussing on how two or more transformations complement one another and what to expect from the batch effect on code smell. This position aims to reason about multiple alternatives to support developers on composing their batches. These alternatives should make it easier to compose batches that remove code smells. For this purpose, we exemplify the role of semi-automated tools in gradually recommending transformations, thereby guiding the batch composition in each alternative.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Investigating the Social Representations of Code Smell Identification: A Preliminary Study.\n \n \n \n \n\n\n \n de Mello, R.; Uchôa, A.; Oliveira, R.; Tenorio, D.; Fonseca, B.; Garcia, A.; and de Mello, F.\n\n\n \n\n\n\n In Proceedings of the 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), pages 53–60, 2019. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"InvestigatingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 1 download\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{deMelloARDBAF19,\n  title={Investigating the Social Representations of Code Smell Identification: A Preliminary Study},\n  author={Rafael de Mello and Anderson Uchôa and Roberto Oliveira and Daniel Tenorio and Baldoino Fonseca and Alessandro Garcia and Fernanda de Mello},\n  booktitle={Proceedings of the 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE)},\n  pages={53--60},\n  year={2019},\nabstract={Context: The identification of code smells is one of the most subjective tasks in software engineering. A key reason is the influence of collective aspects of communities working on this task, such as their beliefs regarding the relevance of certain smells. However, collective aspects are often neglected in the context of smell identification. For this purpose, we can use the social representations theory. Social representations comprise the set of values, behaviors and practices of communities associated with a social object, such as the task of identifying smells. Aim: To characterize the social representations behind smell identification. Method: We conducted a preliminary study on the social representations of smell identification by two communities. One community is composed of postgraduate students involved in various investigations related to code smells. The other community is composed of practitioners from industry, with experience in code reviews. We analyzed the associations made by the study participants about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: One of the key findings is that only the community of practitioners strongly associates this task with semantic smells. This finding suggests research directions on code smells may be revisited, as they focus mostly on measurable or structural smells. Considering the novelty of using the social representations theory in software engineering, we also compiled a set of lessons learned. For instance, we observed some key challenges we faced in using the theory. These challenges include: (i) the predominance of associations with technical rather than non-technical concepts, and (ii) the fuzzy definitions of key concepts in our field. Conclusion: We found initial evidence that social representations analysis is a useful instrument to reveal discrepancies and commonalities on how different communities deal with a subjective task. Thus, we expect the experience reported in this paper may encourage and contribute to future studies of social representations in the field.},\nurl = {https://anderson-uchoa.github.io/publications/deMelloARDBAF19.pdf},\ndoi = {10.1109/CHASE.2019.00022},\npublisher={IEEE Press}\n}\n\n
\n
\n\n\n
\n Context: The identification of code smells is one of the most subjective tasks in software engineering. A key reason is the influence of collective aspects of communities working on this task, such as their beliefs regarding the relevance of certain smells. However, collective aspects are often neglected in the context of smell identification. For this purpose, we can use the social representations theory. Social representations comprise the set of values, behaviors and practices of communities associated with a social object, such as the task of identifying smells. Aim: To characterize the social representations behind smell identification. Method: We conducted a preliminary study on the social representations of smell identification by two communities. One community is composed of postgraduate students involved in various investigations related to code smells. The other community is composed of practitioners from industry, with experience in code reviews. We analyzed the associations made by the study participants about smell identification, i.e., what immediately comes to their minds when they think about this task. Results: One of the key findings is that only the community of practitioners strongly associates this task with semantic smells. This finding suggests research directions on code smells may be revisited, as they focus mostly on measurable or structural smells. Considering the novelty of using the social representations theory in software engineering, we also compiled a set of lessons learned. For instance, we observed some key challenges we faced in using the theory. These challenges include: (i) the predominance of associations with technical rather than non-technical concepts, and (ii) the fuzzy definitions of key concepts in our field. Conclusion: We found initial evidence that social representations analysis is a useful instrument to reveal discrepancies and commonalities on how different communities deal with a subjective task. Thus, we expect the experience reported in this paper may encourage and contribute to future studies of social representations in the field.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n On Gamifying an Existing Healthcare System: Method, Conceptual Model and Evaluation.\n \n \n \n \n\n\n \n Uchôa, A.; Fernandes, E.; Fonseca, B.; de Mello, R.; Barbosa, C.; Nunes, G.; Garcia, A.; and Teixeira, L.\n\n\n \n\n\n\n In Proceedings of the 1st International Workshop on Software Engineering for Healthcare (SEH), pages 1–8, 2019. IEEE Press\n \n\n\n\n
\n\n\n\n \n \n \"OnPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 9 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaEBRCGAL19,\n  title={On Gamifying an Existing Healthcare System: Method, Conceptual Model and Evaluation},\n  author={Anderson Uchôa and Eduardo Fernandes and Baldoino Fonseca and Rafael de Mello and Caio Barbosa and Gabriel Nunes and Alessandro Garcia and Leopoldo Teixeira},\n  booktitle={Proceedings of the 1st International Workshop on Software Engineering for Healthcare (SEH)},\n  pages={1--8},\n  year={2019},\nabstract={Software gamification aims at engaging users with software system features. User engagement is promoted via a gamification model that associates game elements (e.g., points) and rules (e.g., ranking policy) with each feature. Gamification has been increasingly explored in certain healthcare domains, such as chronic disease management and physical activity. However, there are currently two important literature gaps. First, certain healthcare domains in which user engagement is even more critical, such as the prevention of mosquito-transmitted diseases, have not systematically explored gamification yet. Healthcare systems of this domain largely depend on the wide engagement of the population, health professionals and authorities. Second, gamification is often introduced in existing systems developed without gamification in mind. Current methods are quite limited to support this task. In this paper, we report our experience while defining, incorporating, and evaluating a gamification model of an existing healthcare system called VazaZika. VazaZika is intended to assist the prevention of mosquito-transmitted diseases in economically emerging countries. We present and discuss the application of a method, adapted from a previous study, to support the design and incorporation of a gamification model in existing systems (VazaZika, in our case). We also present the resulting conceptual model based on 12 game elements and 16 rules. We evaluate this model with 20 users in terms of ease of use and potential for user engagement. Our results suggest that our conceptual model has resulted in an easy-to-use system with the potential of truly engaging users with critical healthcare-related features. We expect the method and its resulting model can be further reused and adapted to similar healthcare systems.},\nurl = {https://anderson-uchoa.github.io/publications/UchoaEBRCGAL19.pdf},\ndoi = {10.1109/SEH.2019.00009},\npublisher={IEEE Press}\n}\n\n
\n
\n\n\n
\n Software gamification aims at engaging users with software system features. User engagement is promoted via a gamification model that associates game elements (e.g., points) and rules (e.g., ranking policy) with each feature. Gamification has been increasingly explored in certain healthcare domains, such as chronic disease management and physical activity. However, there are currently two important literature gaps. First, certain healthcare domains in which user engagement is even more critical, such as the prevention of mosquito-transmitted diseases, have not systematically explored gamification yet. Healthcare systems of this domain largely depend on the wide engagement of the population, health professionals and authorities. Second, gamification is often introduced in existing systems developed without gamification in mind. Current methods are quite limited to support this task. In this paper, we report our experience while defining, incorporating, and evaluating a gamification model of an existing healthcare system called VazaZika. VazaZika is intended to assist the prevention of mosquito-transmitted diseases in economically emerging countries. We present and discuss the application of a method, adapted from a previous study, to support the design and incorporation of a gamification model in existing systems (VazaZika, in our case). We also present the resulting conceptual model based on 12 game elements and 16 rules. We evaluate this model with 20 users in terms of ease of use and potential for user engagement. Our results suggest that our conceptual model has resulted in an easy-to-use system with the potential of truly engaging users with critical healthcare-related features. We expect the method and its resulting model can be further reused and adapted to similar healthcare systems.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n Analyzing the Impact of Inter-smell Relations on Software Maintainability: An Empirical Study with Software Product Lines.\n \n \n \n \n\n\n \n Martins, J.; Bezerra, C.; and Uchôa, A.\n\n\n \n\n\n\n In Proceedings of the 15th Brazilian Symposium on Information Systems (SBSI), pages 1–8, 2019. ACM\n \n\n\n\n
\n\n\n\n \n \n \"AnalyzingPaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 2 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{JulioCA19,\n title={Analyzing the Impact of Inter-smell Relations on Software Maintainability: An Empirical Study with Software Product Lines},\nauthor={Júlio Martins and Carla Bezerra and Anderson Uchôa},\n  booktitle={Proceedings of the 15th Brazilian Symposium on Information Systems (SBSI)},\n  pages={1--8},\n  year={2019},\nabstract={A Software Product Line (SPL) consists of a systematic reuse strategy to construct systems with less effort as long as they belong to the same family that shares the same components and belong to the same domain of Marketplace. In this context, to support large-scale reuse, components of a Software Product Line should be easy to maintain. Thus, developers should be more concerned with anomalies known as code smells and more than that, co-occurrences known as Inter-smell deserve to be further studied to verify their real impact on maintainability in SPL. Thus, this paper conducts a study to investigate the impact of Inter-smell occurrences on maintainability in MobileMedia and HealthWatcher SPLs. The results show that the presence of co-occurrences of Inter-smell did not negatively impact the maintenance of MobileMedia and Health Watcher SPLs, unlike results found in other studies in the literature, and even more, our results indicate that the metric Lack of Cohesion of Methods is one of the most important for the maintainability of object-oriented SPLs.},\nurl = {https://anderson-uchoa.github.io/publications/JulioCA19.pdf},\ndoi = {10.1145/3330204.3330254},\npublisher={ACM}\n}\n\n
\n
\n\n\n
\n A Software Product Line (SPL) consists of a systematic reuse strategy to construct systems with less effort as long as they belong to the same family that shares the same components and belong to the same domain of Marketplace. In this context, to support large-scale reuse, components of a Software Product Line should be easy to maintain. Thus, developers should be more concerned with anomalies known as code smells and more than that, co-occurrences known as Inter-smell deserve to be further studied to verify their real impact on maintainability in SPL. Thus, this paper conducts a study to investigate the impact of Inter-smell occurrences on maintainability in MobileMedia and HealthWatcher SPLs. The results show that the presence of co-occurrences of Inter-smell did not negatively impact the maintenance of MobileMedia and Health Watcher SPLs, unlike results found in other studies in the literature, and even more, our results indicate that the metric Lack of Cohesion of Methods is one of the most important for the maintainability of object-oriented SPLs.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n VazaZika: A Software Platform for Surveillance and Control of Mosquito-Borne Diseases.\n \n \n \n \n\n\n \n Fernandes, E.; Uchôa, A.; Sousa, L.; Oliveira, A.; de Mello, R.; Barroca, L. P.; Carvalho, D.; Garcia, A.; Fonseca, B.; and Teixeira, L.\n\n\n \n\n\n\n In 16th International Conference on Information Technology: New Generations (ITNG), pages 617–620, 2019. Springer\n \n\n\n\n
\n\n\n\n \n \n \"VazaZika:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{FernandesALARLDABL19,\n  title={VazaZika: A Software Platform for Surveillance and Control of Mosquito-Borne Diseases},\n  author={Eduardo Fernandes and Anderson Uchôa and Leonardo Sousa and Anderson Oliveira and Rafael de Mello and Luiz Paulo Barroca and Diogo Carvalho and Alessandro Garcia and Baldoino Fonseca and Leopoldo Teixeira},\n  booktitle={16th International Conference on Information Technology: New Generations (ITNG)},\n  pages={617--620},\n  year={2019},\nabstract={Mosquito-borne diseases negatively affect economically emerging countries. Nevertheless, the current public healthcare solutions are insufficient to support disease surveillance and control. The citizen engagement in reporting mosquito breeding sites is hard to achieve but essential in preventing disease outbreaks. This paper introduces the VazaZika platform aimed to support the surveillance and control of mosquito-borne diseases. This platform evolves the VazaDengue legacy platform with gamification. Through game elements and rules, we aim to make enjoyable and challenging to report mosquito breeding sites via VazaZika. Citizens are continuously rewarded as they perform tasks in the platform. They progress in levels that enable new tasks and jump in rankings according to the citizens' location. Citizens can also join teams for engaging with challenges, which helps to develop a sense of belonging and connection against the spread of diseases. This paper reports the process of gamifying VazaDengue, the platform user interface and its conceptual model, aimed to support reuse.},\nurl = {https://anderson-uchoa.github.io/publications/FernandesALARLDABL19.pdf},\ndoi = {10.1007/978-3-030-14070-0_89},\npublisher={Springer}\n}\n\n
\n
\n\n\n
\n Mosquito-borne diseases negatively affect economically emerging countries. Nevertheless, the current public healthcare solutions are insufficient to support disease surveillance and control. The citizen engagement in reporting mosquito breeding sites is hard to achieve but essential in preventing disease outbreaks. This paper introduces the VazaZika platform aimed to support the surveillance and control of mosquito-borne diseases. This platform evolves the VazaDengue legacy platform with gamification. Through game elements and rules, we aim to make enjoyable and challenging to report mosquito breeding sites via VazaZika. Citizens are continuously rewarded as they perform tasks in the platform. They progress in levels that enable new tasks and jump in rankings according to the citizens' location. Citizens can also join teams for engaging with challenges, which helps to develop a sense of belonging and connection against the spread of diseases. This paper reports the process of gamifying VazaDengue, the platform user interface and its conceptual model, aimed to support reuse.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2018\n \n \n (2)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n The Buggy Side of Code Refactoring: Understanding the Relationship Between Refactorings and Bugs.\n \n \n \n \n\n\n \n Ferreira, I.; Fernandes, E.; Cedrim, D.; Uchôa, A.; Bibiano, A. C.; Garcia, A.; Correia, J. L.; Santos, F.; Nunes, G.; Barbosa, C.; Fonseca, B.; and de Mello, R.\n\n\n \n\n\n\n In Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings, of ICSE '18, pages 406–407, New York, NY, USA, 2018. ACM\n \n\n\n\n
\n\n\n\n \n \n \"ThePaper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 1 download\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@inproceedings{FerreiraIEDAAAJFGCBR18,\n author = {Ferreira, Isabella and Fernandes, Eduardo and Cedrim, Diego and Uchôa, Anderson and Bibiano, Ana Carla and Garcia, Alessandro and Correia, João Lucas and Santos, Filipe and Nunes, Gabriel and Barbosa, Caio and Fonseca, Baldoino and de Mello, Rafael},\n title = {The Buggy Side of Code Refactoring: Understanding the Relationship Between Refactorings and Bugs},\n booktitle = {Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings},\n series = {ICSE '18},\n year = {2018},\n isbn = {978-1-4503-5663-3},\n location = {Gothenburg, Sweden},\n pages = {406--407},\n numpages = {2},\nabstract={Code refactoring is widely practiced by software developers. There is an explicit assumption that code refactoring improves the structural quality of a software project, thereby also reducing its bug proneness. However, refactoring is often applied with different purposes in practice. Depending on the complexity of certain refactorings, developers might unconsciously make the source code more susceptible to have bugs. In this paper, we present a longitudinal study of 5 Java open source projects, where 20,689 refactorings, and 1,033 bug reports were analyzed. We found that many bugs are introduced in the refactored code as soon as the first immediate change is made on it. Furthermore, code elements affected by refactorings performed in conjunction with other changes are more prone to have bugs than those affected by pure refactorings.},\n url = {https://anderson-uchoa.github.io/publications/FerreiraEDA18.pdf},\ndoi = {10.1145/3183440.3195030},\n acmid = {3195030},\n publisher = {ACM},\n address = {New York, NY, USA},\n keywords = {bug proneness, empirical study, refactoring, software maintenance},\n}\n\n
\n
\n\n\n
\n Code refactoring is widely practiced by software developers. There is an explicit assumption that code refactoring improves the structural quality of a software project, thereby also reducing its bug proneness. However, refactoring is often applied with different purposes in practice. Depending on the complexity of certain refactorings, developers might unconsciously make the source code more susceptible to have bugs. In this paper, we present a longitudinal study of 5 Java open source projects, where 20,689 refactorings, and 1,033 bug reports were analyzed. We found that many bugs are introduced in the refactored code as soon as the first immediate change is made on it. Furthermore, code elements affected by refactorings performed in conjunction with other changes are more prone to have bugs than those affected by pure refactorings.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n VazaDengue: An information system for preventing and combating mosquito-borne diseases with social networks.\n \n \n \n \n\n\n \n Sousa, L.; de Mello, R.; Cedrim, D.; Garcia, A.; Missier, P.; Uchôa, A.; Oliveira, A.; and Romanovsky, A.\n\n\n \n\n\n\n Information Systems, 75: 26 - 42. 2018.\n \n\n\n\n
\n\n\n\n \n \n \"VazaDengue:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 1 download\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{SousaLRDAPAAA18,\ntitle = "VazaDengue: An information system for preventing and combating mosquito-borne diseases with social networks",\njournal = "Information Systems",\nvolume = "75",\npages = "26 - 42",\nyear = "2018",\nissn = "0306-4379",\ndoi = "10.1016/j.is.2018.02.003",\nurl = "https://anderson-uchoa.github.io/publications/SousaLRDAPAAA18.pdf",\nauthor = "Leonardo Sousa and Rafael de Mello and Diego Cedrim and Alessandro Garcia and Paolo Missier and Anderson Uchôa and Anderson Oliveira and Alexander Romanovsky",\nkeywords = "Dengue, Mosquito, Social media, Surveillance, Tweets",\nabstract = "Dengue is a disease transmitted by the Aedes Aegypti mosquito, which also transmits the Zika virus and Chikungunya. Unfortunately, the population of different countries has been suffering from the diseases transmitted by this mosquito. The communities should play an important role in combating and preventing the mosquito-borne diseases. However, due to the limited engagement of the population, new solutions need to be used to strengthen the mosquito surveillance. VazaDengue is one of these solutions, which offers the users a web and mobile platform for preventing and combating mosquito-borne diseases. The system relies on social actions of citizens reporting mosquito breeding sites and dengue cases, in which the reports are made available to the community and health agencies. In order to address the limited population engagement, the system proactively monitors social media network as Twitter to enrich the information provided by the system. It processes the natural language text from the network to classify the tweets according to a set of predefined categories. After the classification, the relevant tweets are provided to the users as reports. In this paper, we describe the VazaDengue features including its ability to harvest and classify tweets. Since the VazaDengue system aims to strengthen the entomological surveillance of the mosquito that transmits Dengue, Zika, and Chikungunya by providing geolocated reports, we present here two studies to evaluate its potential contributions. The first evaluation uses a survey conducted in the Brazilian community of health agents. The goal is to evaluate the relevance of the classified tweets according to the health agents’ perspective. The second study compares the official reports of the 2015–2016 epidemic waves in Brazil with the concentration of mosquito-related tweets found by VazaDengue. The goal is to verify if the concentration of tweets can be used for monitoring the mosquito manifestation in big cities. The results of these two evaluations are encouraging. For instance, we have found that the health agents tend to agree with the relevance of the classified tweets. Moreover, the concentration of tweets is likely to be effective for monitoring big cities. The results of these evaluations are helping us to improve the VazaDengue system further. These improvements will make the VazaDengue system even more useful for combating and preventing the mosquito-borne diseases."\n}\n\n
\n
\n\n\n
\n Dengue is a disease transmitted by the Aedes Aegypti mosquito, which also transmits the Zika virus and Chikungunya. Unfortunately, the population of different countries has been suffering from the diseases transmitted by this mosquito. The communities should play an important role in combating and preventing the mosquito-borne diseases. However, due to the limited engagement of the population, new solutions need to be used to strengthen the mosquito surveillance. VazaDengue is one of these solutions, which offers the users a web and mobile platform for preventing and combating mosquito-borne diseases. The system relies on social actions of citizens reporting mosquito breeding sites and dengue cases, in which the reports are made available to the community and health agencies. In order to address the limited population engagement, the system proactively monitors social media network as Twitter to enrich the information provided by the system. It processes the natural language text from the network to classify the tweets according to a set of predefined categories. After the classification, the relevant tweets are provided to the users as reports. In this paper, we describe the VazaDengue features including its ability to harvest and classify tweets. Since the VazaDengue system aims to strengthen the entomological surveillance of the mosquito that transmits Dengue, Zika, and Chikungunya by providing geolocated reports, we present here two studies to evaluate its potential contributions. The first evaluation uses a survey conducted in the Brazilian community of health agents. The goal is to evaluate the relevance of the classified tweets according to the health agents’ perspective. The second study compares the official reports of the 2015–2016 epidemic waves in Brazil with the concentration of mosquito-related tweets found by VazaDengue. The goal is to verify if the concentration of tweets can be used for monitoring the mosquito manifestation in big cities. The results of these two evaluations are encouraging. For instance, we have found that the health agents tend to agree with the relevance of the classified tweets. Moreover, the concentration of tweets is likely to be effective for monitoring big cities. The results of these evaluations are helping us to improve the VazaDengue system further. These improvements will make the VazaDengue system even more useful for combating and preventing the mosquito-borne diseases.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2017\n \n \n (3)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n Do Coupling Metrics Help Characterize Critical Components in Component-based SPL? An Empirical Study.\n \n \n \n \n\n\n \n Uchôa, A.; Fernandes, E.; Bibiano, A. C.; and Garcia, A.\n\n\n \n\n\n\n In Proceedings of the 5th Workshop on Software Visualization, Evolution and Maintenance (VEM'17), Fortaleza, Brazil, September 2017., pages 36–43, 2017. \n \n\n\n\n
\n\n\n\n \n \n \"DoPaper\n  \n \n\n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaFBA17,\n  title={Do Coupling Metrics Help Characterize Critical Components in Component-based SPL? An Empirical Study},\n  author={Uchôa, Anderson and Fernandes, Eduardo and Bibiano, Ana Carla and Garcia, Alessandro},\n  booktitle={Proceedings of the 5th Workshop on Software Visualization, Evolution and Maintenance (VEM'17), Fortaleza, Brazil, September 2017.},\n  pages={36--43},\n  year={2017},\n  abstract={In component-based software product lines (SPL), each component has to encapsulate features, restrict data access, and be replaceable. For critical components, with multiple features and dependencies, these criteria are fundamental for flexible product configuration. Previous work assume that coupling metrics help characterize critical components, but we lack empirical evidence for that assumption. By characterizing critical components, we could help developers identify components that require careful maintenance and evolution. This paper relies on five well-known coupling metrics to compose a strategy for characterizing critical components in component-based SPLs. Our results suggest reasonable strategy’s accuracy but the need for using additional metrics.},\nurl={https://anderson-uchoa.github.io/publications/UchoaFBA17.pdf}\t\n}\n\n
\n
\n\n\n
\n In component-based software product lines (SPL), each component has to encapsulate features, restrict data access, and be replaceable. For critical components, with multiple features and dependencies, these criteria are fundamental for flexible product configuration. Previous work assume that coupling metrics help characterize critical components, but we lack empirical evidence for that assumption. By characterizing critical components, we could help developers identify components that require careful maintenance and evolution. This paper relies on five well-known coupling metrics to compose a strategy for characterizing critical components in component-based SPLs. Our results suggest reasonable strategy’s accuracy but the need for using additional metrics.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n ReMINDER: An Approach to Modeling Non-Functional Properties in Dynamic Software Product Lines.\n \n \n \n \n\n\n \n Uchôa, A. G.; Bezerra, C. I. M.; Machado, I. C.; Monteiro, J. M.; and Andrade, R. M. C.\n\n\n \n\n\n\n In Proceedings of the 16th International Conference on Software Reuse (ICSR'17), Salvador, Brazil, May 2017., pages 65–73, 2017. Springer International Publishing\n \n\n\n\n
\n\n\n\n \n \n \"ReMINDER:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaMMMC17,\nauthor="Uchôa, Anderson G.\nand Bezerra, Carla I. M.\nand Machado, Ivan C.\nand Monteiro, José Maria\nand Andrade, Rossana M. C.",\ntitle="ReMINDER: An Approach to Modeling Non-Functional Properties in Dynamic Software Product Lines",\nbookTitle="Proceedings of the 16th International Conference on Software Reuse (ICSR'17), Salvador, Brazil, May 2017.",\nyear="2017",\npublisher="Springer International Publishing",\npages="65--73",\nabstract="This paper presents a systematic approach to modeling NFPs in DSPL feature models. In our proposed approach, feature models are annotated with the representation of NFPs, rules for the activation and deactivation of features, constraints between NFPs and features, and context adaptation scenarios. To evaluate the applicability of the proposed approach we carried out an empirical evaluation. The approach yielded good results at identifying NFPs in DSPLs.",\nisbn="978-3-319-56856-0",\ndoi="10.1007/978-3-319-56856-0_5",\nurl="https://anderson-uchoa.github.io/publications/UchoaMMMC17.pdf"\n}\n\n
\n
\n\n\n
\n This paper presents a systematic approach to modeling NFPs in DSPL feature models. In our proposed approach, feature models are annotated with the representation of NFPs, rules for the activation and deactivation of features, constraints between NFPs and features, and context adaptation scenarios. To evaluate the applicability of the proposed approach we carried out an empirical evaluation. The approach yielded good results at identifying NFPs in DSPLs.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n DyMMer-NFP: Modeling Non-functional Properties and Multiple Context Adaptation Scenarios in Software Product Lines.\n \n \n \n \n\n\n \n Uchôa, A. G.; Lima, L. P.; Bezerra, C. I. M.; Monteiro, J. M.; and Andrade, R. M. C.\n\n\n \n\n\n\n In Proceedings of the 16th International Conference on Software Reuse (ICSR'17), Salvador, Brazil, May 2017., pages 175–183, 2017. Springer International Publishing\n \n\n\n\n
\n\n\n\n \n \n \"DyMMer-NFP:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaPMMC17,\nauthor="Uchôa, Anderson G.\nand Lima, Luan P.\nand Bezerra, Carla I. M.\nand Monteiro, José Maria\nand Andrade, Rossana M. C.",\ntitle="DyMMer-NFP: Modeling Non-functional Properties and Multiple Context Adaptation Scenarios in Software Product Lines",\nbookTitle="Proceedings of the 16th International Conference on Software Reuse (ICSR'17), Salvador, Brazil, May 2017.",\nyear="2017",\npublisher="Springer International Publishing",\npages="175--183",\nabstract="In Software Product Lines (SPLs), the modeling of non-functional properties (NFPs) and context adaptation scenarios are important activities, once they make possible the identification of interdependencies constraints between functional requirements (FR) and NFP, according to a specific adaptation context scenario. However, there are few tools to help domain engineers to represent NFPs and context adaptation scenarios. To deal with this problem, we propose DyMMer-NFP, an extension of the DyMMer tool to support the modeling of NFPs and multiple contextual adaptation scenarios in feature models. DyMMer-NFP uses a catalog with 39 NFPs. Each NFP in this catalog were mapped according to each quality characteristic and sub-characteristics presented in the ISO/IEC 25010 SQuaRE product quality model. To specify the interdependencies between NFPs and features, DyMMer-NFP has used the concept of contribution links. In order to make it easier to evaluate DyMMer-NFP two datasets, called AFFOgaTO and ESPREssO, were made available for free.",\nisbn="978-3-319-56856-0",\ndoi="10.1007/978-3-319-56856-0_12",\nurl="https://anderson-uchoa.github.io/publications/UchoaPMMC17.pdf"\n}\n\n
\n
\n\n\n
\n In Software Product Lines (SPLs), the modeling of non-functional properties (NFPs) and context adaptation scenarios are important activities, once they make possible the identification of interdependencies constraints between functional requirements (FR) and NFP, according to a specific adaptation context scenario. However, there are few tools to help domain engineers to represent NFPs and context adaptation scenarios. To deal with this problem, we propose DyMMer-NFP, an extension of the DyMMer tool to support the modeling of NFPs and multiple contextual adaptation scenarios in feature models. DyMMer-NFP uses a catalog with 39 NFPs. Each NFP in this catalog were mapped according to each quality characteristic and sub-characteristics presented in the ISO/IEC 25010 SQuaRE product quality model. To specify the interdependencies between NFPs and features, DyMMer-NFP has used the concept of contribution links. In order to make it easier to evaluate DyMMer-NFP two datasets, called AFFOgaTO and ESPREssO, were made available for free.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2016\n \n \n (2)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n \n Modelagem de Requisitos Não-Funcionais em Modelos de Features de Linha de Produto de Software Dinâmicas.\n \n \n \n \n\n\n \n Uchôa, A. G; and Bezerra, C. I.\n\n\n \n\n\n\n In Proceedings of the 3rd Latin-American School on Software Engineering (ELA-ES), pages 73–76, 2016. \n Best Paper Award!\n\n\n\n
\n\n\n\n \n \n \"ModelagemPaper\n  \n \n\n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{UchoaM16,\n  title={Modelagem de Requisitos Não-Funcionais em Modelos de Features de Linha de Produto de Software Dinâmicas},\n  author={Uchôa, Anderson G and Bezerra, Carla IM},\n  booktitle={Proceedings of the 3rd Latin-American School on Software Engineering (ELA-ES)},\n  pages={73--76},\n  note={<font color="red">Best Paper Award!</font>},\n  year={2016},\n  abstract={This paper proposes a representation of non-functional requirements and context requirements for the feature model of DSPLs. The   representation extends the FODA notation of the feature model. The proposal will be implemented in DyMMer tool that already provides representation of features and context adaptations in a single feature model.},\n url={https://anderson-uchoa.github.io/publications/UchoaM16.pdf}\n}\n\n
\n
\n\n\n
\n This paper proposes a representation of non-functional requirements and context requirements for the feature model of DSPLs. The representation extends the FODA notation of the feature model. The proposal will be implemented in DyMMer tool that already provides representation of features and context adaptations in a single feature model.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n \n ReMINDER: Uma Abordagem para Modelagem de Propriedades Não-Funcionais em Linhas de Produto de Software Dinâmicas.\n \n \n \n \n\n\n \n Uchôa, A. G.\n\n\n \n\n\n\n 2016.\n BSc Thesis, Federal University of Ceará (UFC)\n\n\n\n
\n\n\n\n \n \n \"ReMINDER:Paper\n  \n \n\n \n \n doi\n  \n \n\n \n link\n  \n \n\n bibtex\n \n\n \n  \n \n abstract \n \n\n \n  \n \n 3 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@misc{UchoaR16,\n  author={Anderson Gonçalves Uchôa},\n  title={ReMINDER: Uma Abordagem para Modelagem de Propriedades Não-Funcionais em Linhas de Produto de Software Dinâmicas},\n  note={BSc Thesis, Federal University of Ceará (UFC)},\n  year={2016},\n  abstract = {Linhas de Produto de Software (LPS) representam um conjunto de sistemas de software que compartilham de um conjunto de features comuns e gerenciadas, que satisfazem as necessidades de um segmento de mercado particular ou missão. No entanto, a representação de variabilidade dos produtos gerados por LPSs é feita apenas de forma estática, ou seja, a adaptação ocorre em tempo de projeto. Contudo, com o surgimento de sistemas sensíveis ao contexto, a construção de sistemas tem se tornado mais complexa, dado as mudanças de requisitos e restrições conforme o ambiente no qual está inserido, exigindo um alto grau de adaptação em tempo de execução. Esses sistemas podem ser conceitualizados como Linhas de Produtos de Software Dinâmica (LPSD). Um dos desafios para construir um LPSD é desenvolver um mecanismo para incorporar cenários com adaptações de contexto e propriedades não-funcionais (PNFs). Para incorporar esses mecanismo ao modelo de features de LPSDs, uma boa estratégia consiste em utilizar uma abordagem para guiar a identificação e representação destes mecanismos. Neste cenário, o objetivo deste trabalho é representar PNFs e cenários de adaptações de contexto em modelos de features de LPSDs. Para isso, foi elaborada uma abordagem capaz de identificar PNFs, restrições e cenários de adaptações de contexto, ativação e desativação de features, denominada ReMINDER. Também foi desenvolvida uma extensão da ferramenta DyMMer, para suportar a abordagem. Para avaliação da abordagem e da ferramenta, foram realizados dois estudos. O primeiro foi um experimento controlado, para analisar o processo definido na abordagem ReMINDER, com a finalidade de caracterizar a sua aplicação, em relação à identificação de PNFs e cenários de adaptações de contexto, com suas respectivas restrições, para apoiar a modelagem de features e representação de PNFs em modelos de features de LPSDs. O segundo estudo foi a aplicação de um teste de usabilidade. Esse teste teve como objetivo avaliar a usabilidade da ferramenta estendida por meio da análise de quatro fatores: i) satisfação geral; ii) usabilidade da ferramenta; iii) qualidade da informação; e iv) qualidade da interface. De modo geral, após a análise e interpretação de todos os resultados obtidos, conclui-se que a abordagem auxiliou na identificação das PNFs e a sua relação com o comportamento do modelo de features por meio de restrições de interdependência. Além disso, também foi verificado que a ferramenta estendida possui um boa usabilidade, sendo útil para operacionalização da abordagem.},\n  url={https://anderson-uchoa.github.io/publications/UchoaR16.pdf},\n  doi = {http://www.repositorio.ufc.br/handle/riufc/24885}\n}\n
\n
\n\n\n
\n Linhas de Produto de Software (LPS) representam um conjunto de sistemas de software que compartilham de um conjunto de features comuns e gerenciadas, que satisfazem as necessidades de um segmento de mercado particular ou missão. No entanto, a representação de variabilidade dos produtos gerados por LPSs é feita apenas de forma estática, ou seja, a adaptação ocorre em tempo de projeto. Contudo, com o surgimento de sistemas sensíveis ao contexto, a construção de sistemas tem se tornado mais complexa, dado as mudanças de requisitos e restrições conforme o ambiente no qual está inserido, exigindo um alto grau de adaptação em tempo de execução. Esses sistemas podem ser conceitualizados como Linhas de Produtos de Software Dinâmica (LPSD). Um dos desafios para construir um LPSD é desenvolver um mecanismo para incorporar cenários com adaptações de contexto e propriedades não-funcionais (PNFs). Para incorporar esses mecanismo ao modelo de features de LPSDs, uma boa estratégia consiste em utilizar uma abordagem para guiar a identificação e representação destes mecanismos. Neste cenário, o objetivo deste trabalho é representar PNFs e cenários de adaptações de contexto em modelos de features de LPSDs. Para isso, foi elaborada uma abordagem capaz de identificar PNFs, restrições e cenários de adaptações de contexto, ativação e desativação de features, denominada ReMINDER. Também foi desenvolvida uma extensão da ferramenta DyMMer, para suportar a abordagem. Para avaliação da abordagem e da ferramenta, foram realizados dois estudos. O primeiro foi um experimento controlado, para analisar o processo definido na abordagem ReMINDER, com a finalidade de caracterizar a sua aplicação, em relação à identificação de PNFs e cenários de adaptações de contexto, com suas respectivas restrições, para apoiar a modelagem de features e representação de PNFs em modelos de features de LPSDs. O segundo estudo foi a aplicação de um teste de usabilidade. Esse teste teve como objetivo avaliar a usabilidade da ferramenta estendida por meio da análise de quatro fatores: i) satisfação geral; ii) usabilidade da ferramenta; iii) qualidade da informação; e iv) qualidade da interface. De modo geral, após a análise e interpretação de todos os resultados obtidos, conclui-se que a abordagem auxiliou na identificação das PNFs e a sua relação com o comportamento do modelo de features por meio de restrições de interdependência. Além disso, também foi verificado que a ferramenta estendida possui um boa usabilidade, sendo útil para operacionalização da abordagem.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n\n\n\n
\n\n\n \n\n \n \n \n \n\n
\n"}; document.write(bibbase_data.data);