Abstract Design Pattern Detection (DPD) tools are useful to support to the comprehension and maintenance of software systems. Although several DPD tools have been introduced over the years, they typically focus on a limited set of design patterns and programming languages. This paper aims to investigate (i) the reasons that motivate DPD tool designers to target specific design patterns and programming languages, and (ii) how potential users perceive the usefulness of DPD tools in practical software development scenarios. We conducted two online surveys. For the first survey, we reached out to designers of 42 DPD tools selected from a systematic literature review to obtain their perspectives on design decisions about pattern and language coverage, receiving 22% of such responses. For the second survey, we recruited 28 student and senior developers to help us understand their expectations, perceived benefits, and concerns related to the use of DPD tools. Within our sample, the findings suggest that participating tool designers often prioritize design patterns whose internal structure facilitates automated detection, while language support is frequently motivated by popularity and expected demand. From the perspective of tool users, DPD tools are expected to support development activities, such as program comprehension and software quality improvement. Unfortunately, usability difficulties, limited accuracy, and insufficient documentation often discourage them from adopting a tool. The responses suggest that some design decisions reported by participating DPD tool designers are aligned with practical and industrial considerations. However, the recurring lack of adequate documentation and usability support is a major barrier to wider usage. Taken as indicative evidence, these results suggest that future DPD tools should better balance detection capabilities and usability concerns, especially to meet the need of less experienced developers. Given the limited number of tool-designer respondents, conclusions about design rationale should be interpreted as indicative rather than representative of all DPD tool designers.

The detection of code smells is a critical task in software engineering, as it helps identify design issues that can compromise code quality and maintainability. With the advancement of large-scale language models (LLMs), such as Google Gemini, there is an opportunity to automate this detection more efficiently. This paper investigates the effectiveness of Gemini in identifying code smells in Java projects. We used a dataset (MLCQ) containing four types of code smells (Blob, Data Class, Feature Envy, and Long Method), classified into three severity levels. We then applied two types of prompts: a generic and a detailed one. To evaluate Gemini, we proposed three research questions related to its effectiveness with the different types of prompts used. Our results show that Gemini is more likely to provide correct results when using a detailed prompt compared to a generic one. Additionally, Gemini identified some code smells not highlighted by ChatGPT, suggesting their different detection capabilities. However, the accuracy of these additional detections still needs to be validated. We conclude that Google Gemini is a promising tool for code smell detection, but further studies are needed to understand its accuracy and the influence of the type of prompt used. This work paves the way for future research on the application of LLMs in software quality improvement.

Large Language Models (LLMs) have gained attention for addressing coding problems, but their effectiveness in fixing code maintainability remains unclear. This study evaluates LLMs capability to resolve 127 maintainability issues from 10 GitHub repositories. We use zero-shot prompting for Copilot Chat and Llama 3.1, and few-shot prompting with Llama only. The LLM-generated solutions are assessed for compilation errors, test failures, and new maintainability problems. Llama with few-shot prompting successfully fixed 44.9 % of the methods, while Copilot Chat and Llama zero-shot fixed 32.29 % and 30 %, respectively. However, most solutions introduced errors or new maintainability issues. We also conducted a human study with 45 participants to evaluate the readability of 51 LLM-generated solutions. The human study showed that 68.63 % of participants observed improved readability. Overall, while LLMs show potential for fixing maintainability issues, their introduction of errors highlights their current limitations.

ABSTRACT Given the multidisciplinary complexity of embedded Internet of Things (IoT) projects and the demand for qualified professionals, this study investigates the influence of continuous integration and continuous delivery (CI/CD) skills and developers' perceptions regarding applying these practices in this domain. We conducted a quasi‐experiment with 98 students from three undergraduate courses at two Brazilian federal universities, analyzing the impact of developer skills on CI/CD. The results showed that developers with no previous CI/CD skills faced more significant difficulties in practical activities. It was interesting to note that most participants in our sample already had some experience with real software development projects. However, most have never had real experience with an embedded IoT project or CI/CD tools. The approach we followed resulted in 92% success. Attendees expressed interest in more hands‐on training on CI/CD pipeline, DevOps, and embedded IoT projects. We also noticed a great need for them to have more practical experience with Git, GitHub, GitHub Actions, and GNU/Linux.

Code smells are symptoms in the source code that indicate code quality degradation and, consequently, may affect code comprehension and maintenance. Moreover, when two or more code smells occur on the same piece of code, forming an agglomeration, they may be more harmful to the code quality. Although the impact of smells in isolation is well known, the impact of their agglomeration is still underexplored. Our goal with this study is to provide evidence of how agglomerations impact code stability, i.e. we investigate if agglomeration suffers more modifications along the system evolution, and in which intensity. For this purpose, we mined two years of commit history from 30 open-source Java systems from GitHub. To analyze code stability, we considered four measurements: the number of commits, lines of modified code, rate of modified classes, and the proportion of changes. We examined these measurements from two perspectives: by system and by aggregating all system data. Additionally, we further considered how a class created/deleted in this time span impacts our results. Our main findings are: (i) classes with two or more code smells of different types change more frequently and in more intensity than classes with a single smell or no smell; (ii) the stability of the class varies greatly with the system under analysis; (iii) when a smelly class was deleted in our time range, they usually had several lines of code added until it became unsustainable. We can conclude that agglomerations change with more frequency and intensity, raising maintenance and evolution costs. Consequently, this information can be used to prioritize code refactoring.

Identifying code smells in projects is a non-trivial task, and it is often a subjective activity since developers have different understandings about them. The use of machine learning techniques to predict code smells is gaining attention. In this replication study, our goals are: (i) verify if previous model's performance maintain when we extract data from updated systems; and (ii) explore and provide evidences of how the use of different feature engineering and resampling techniques can enhance code smell prediction model's performance. For these purposes, we evaluate four smells: God Class, Refused Bequest, Feature Envy and Long Method. We first replicate a previous study that focus on the algorithm's performance to identify the best models for each smell using a different dataset composed of 30 Java systems. This first experiment provides us a baseline model that is used in the second experiment. In the second experiment, we compare the performance of the baseline model with other models tuned with polynomial features and resample techniques. Our main results are: for datasets with imbalances lower than a ratio of 1:100, such as God Class and Long Method, the use of oversample techniques yielded better results. For datasets with more severe imbalance, like Refused Bequest and Feature Envy, the undersample techniques performed better. The feature selection technique, despite a minor impact on the results, provided insights. For instance, we need new features to represent some code smells, such as Long Method and Feature Envy.

Data science is a field of knowledge that exploits various methods of collecting and analyzing data.Nowadays, data-driven software development is getting more common and multiple experts take part of the process, such as data scientists and software developers.Nevertheless, locating professionals who possess strong technical skills as a data scientist may be a difficult task because such data are not easy to verify.This paper explores the activity of data scientists in software repositories, such as commits, to identify their technical skills.By analyzing 18 data science projects, we identified 69 data scientists.A data science proficiency measurement was then conducted by counting and categorizing the number and types of applied changes.Our results shows that 68% of the data scientists are mono languages; i.e., they use a single programming language (Python).

Summary Software defect prediction is a subject of study involving the interplay of software engineering and machine learning. The current literature proposed numerous machine learning models to predict software defects from software data, such as commits and code metrics. Further, the most recent literature employs explainability techniques to understand why machine learning models made such predictions (i.e., predicting the likelihood of a defect). As a result, developers are expected to reason on the software features that may relate to defects in the source code. However, little is known about the developers' perception of these machine learning models and their explanations. To explore this issue, we focus on a survey with experienced developers to understand how they evaluate each quality attribute for the defect prediction. We chose the developers based on their contributions at GitHub, where they contributed to at least 10 repositories in the past 2 years. The results show that developers tend to evaluate code complexity as the most important quality attribute to avoid defects compared with the other target attributes such as source code size, coupling, and documentation. At the end, a thematic analysis reveals that developers evaluate testing the code as a relevant aspect not covered by the static software features. We conclude that, qualitatively, there exists a misalignment between developers' perceptions and the outputs of machine learning models. For instance, while machine learning models assign high importance to documentation, developers often overlook documentation and prioritize assessing the complexity of the code instead.

Abstract Software defect and code smell prediction help developers identify problems in the code and fix them before they degrade the quality or the user experience. The prediction of software defects and code smells is challenging, since it involves many factors inherent to the development process. Many studies propose machine learning models for defects and code smells. However, we have not found studies that explore and compare these machine learning models, nor that focus on the explainability of the models. This analysis allows us to verify which features and quality attributes influence software defects and code smells. Hence, developers can use this information to predict if a class may be faulty or smelly through the evaluation of a few features and quality attributes. In this study, we fill this gap by comparing machine learning models for predicting defects and seven code smells. We trained in a dataset composed of 19,024 classes and 70 software features that range from different quality attributes extracted from 14 Java open-source projects. We then ensemble five machine learning models and employed explainability concepts to explore the redundancies in the models using the top-10 software features and quality attributes that are known to contribute to the defects and code smell predictions. Furthermore, we conclude that although the quality attributes vary among the models, the complexity, documentation, and size are the most relevant. More specifically, Nesting Level Else-If is the only software feature relevant to all models.

Mutation testing is a fault-based testing criterion that is used to measure the quality of the test suites of software systems. Due to its inherent high computational cost, many studies were published in the last decades aiming at reducing computational cost and human-effort for the mutation analysis. One of the most promising areas is searching for Strongly Subsuming Higher-Order Mutants (SSHOMs), which are rare and harder to kill than their constituent first-order mutants (FOMs). Therefore, they are valuable especially because they can replace their FOMs without loss of effectiveness in the mutation testing process. One of the explanations for the SSHOMs to be harder to kill than their constituent FOMs is that the single faults (mutations) can partially mask one another, so that the combination of them is harder to detect than any of the individual faults. However, we did not find in the literature an investigation of the masking phenomenon. Therefore, the goal of this paper is to start filling this gap. More specifically, for a mutation to mask the other one, it is necessary firstly that the execution of a test case reaches all involved mutations. Therefore, we designed two complementary studies to accomplish our goal. Study #1 focuses on searching for Strongly-Subsuming Second-Order Mutants (SS2OMs) and then analyzes reaching characteristics of their constituent FOMs. We found that almost half of the SS2OMs constituent FOMs are not even reaching the other FOM. In Study #2, we designed a search strategy that considers a second-order mutant killed only if both of their mutations are reached by a failing test case execution. This strategy found much more SS2OMs than in the first study.

Context: The success of Open Source Software (OSS) projects typically depends on simultaneous contributions of several developers. These contributions often affect the same changing source files and may lead to merge conflicts when integrated. Previous studies investigated the reduction of conflicting merge scenarios. However, empirical evidence on the involvement of OSS contributors in conflicting merge scenarios is scarce. Objective: We aim to fill this gap with a large-scale quantitative study with the goal of understanding: 1) the extent in which OSS contributors are involved in conflicting merge scenarios; 2) characteristics of these contributors; and 3) characteristics of changing source files. Method: We collect both contributor data and contribution data from 66 popular GitHub projects and analyze data of 2972 distinct contributors who were involved in at least one conflicting merge scenario. We rely on both descriptive and inferential statistics to address our research questions. Results: About 80% of the analyzed contributors are involved in only one or two conflicting merge scenarios. Additionally, 42 out of the 66 projects had its top-one contributor as the one mostly involved in conflicting merge scenarios. Finally, only a small set of changing source files are involved in conflicting merge scenarios. Conclusions: We advocate that training the typically small group of contributors involved in conflicting merge scenarios could significantly reduce the number of merge conflicts.

Abstract With the emergence of social coding platforms, collaboration has become a key and dynamic aspect to the success of software projects. In such platforms, developers have to collaborate and deal with issues of collaboration in open‐source software development. Although collaboration is challenging, collaborative development produces better software systems than any developer could produce alone. Several approaches have investigated collaboration challenges, for instance, by proposing or evaluating models and tools to support collaborative work. Despite the undeniable importance of the existing efforts in this direction, there are few works on collaboration from perspectives of developers. In this work, we aim to investigate the perceptions of open‐source software developers on collaborations, such as motivations, techniques, and tools to support global, productive, and collaborative development. Following an ad hoc literature review, an exploratory interview study with 12 open‐source software developers fromGitHub, our novel approach for this problem also relies on an extensive survey with 121 developers to confirm or refute the interview results. We found different collaborative contributions, such as managing change requests. Besides, we observed that most collaborators prefer to collaborate with the core team instead of their peers. We also found that most collaboration happens in software development (60%) and maintenance (47%) tasks. Furthermore, despite personal preferences to work independently, developers still consider collaborating with others in specific task categories, for instance, software development. Finally, developers also expressed the importance of the social coding platforms, such asGitHub, to support maintainers, and contributors in making decisions and developing tasks of the projects. Therefore, these findings may help project leaders optimize the collaborations among developers and reduce entry barriers. Moreover, these findings may support the project collaborators in understanding the collaboration process and engaging others in the project.

Summary Software developers must collaborate at all stages of the software life‐cycle to create successful complex software systems. To enable this collaboration, social coding platforms, for example, GitHub, include an increasing number of tools to support collaboration. However, for large projects with hundreds of dynamic developers, such as several successful open–source projects, it can be complex to find developers with the same interest and familiarity and thus, gain suitable collaborations and new insights. In this context, resources and efforts may be wasted, discouraging many developers from contributing. Moreover, it can be costly to manage many contributions, which is another challenge for the maintainer who wants to take advantage of this small, timid, but valuable contribution made by a volunteer developer in a short time. In this context, this paper presents an empirical study aiming to evaluate two strategies to recommend collaborators based on co‐changed files. Inspired in the TF–IDF (Term Frequency–Inverse Document Frequency) weighting scheme established in the Information Retrieval field, these strategies first estimate the importance of relevant files modified by developers and use these estimates to represent each developer “profile”. As a second step, they estimate the similarity between developers using the Cosine metric, providing top‐ranked developers according to this measure as recommendations. We evaluated these strategies based on an extensive survey with 102 real–world developers. We observed that developers have interest and familiarity with the co‐changed files for all strategies evaluated. These considerations are of relevance because many opportunities for contributions to the project are linked to coding. Thus, theses results may indicate one less barrier for improving collaboration among developers. Overall, the strategies present an acceptance rate of up to 81%, contributing to the discovery of further collaborators.

Successful software projects require engaged collaborators interacting with each other across the entire development life-cycle. Unfortunately, for social coding platforms, e.g., GitHub, identifying a suitable collaborator to strengthen their ties and improve their engagement in the project is challenging, given that reliable information for collaborator identification is often not readily available. In this work, we propose and evaluate a collaborator recommendation tool - CoopFinder - to help developers find collaborators in a specific project based on similar interests related to co–changed files. We design our Web prototype–tool using visualization techniques. As a result of the preliminary user study, we observed that 95% of the participants had positive impressions of the tool. Furthermore, 75% of participants stated that they would use the tool in their daily lives or recommend it to others. Repository: https://github.com/kattiana/CoopFinder;

Building an application using third-party libraries is a common practice in software development. As any other system, software libraries and their APIs evolve. To support version migration and ensure backward compatibility, a recommended practice during development is to deprecate API. Different from other popular programming languages such as Java and C#, JavaScript has no native support to deprecate API elements. However, several strategies are commonly adopted to communicate that an API should be avoided, such as the project documentation, JSDoc annotation, code comment, console message, and deprecation utility. Indeed, there have been many studies on deprecation strategies and evolution mostly on Java, C#, and Python. However, to the best of our knowledge, there are no detailed studies aiming at analyzing how API deprecation changes over time in the JavaScript ecosystem. This paper provides an empirical study on how API deprecation evolves in JavaScript by analyzing 1,918 releases of 50 popular packages. Results show that close to 60% have rising trends in the number of deprecated APIs, while only 9.4% indicate a downward trend. Also, most deprecation occurrences are both added and removed on minor releases instead of removed on major releases, as recommended by best practices.

Abstract Software Product Lines (SPLs) are rarely developed from scratch. Commonly, they emerge from one product when there is a need to create tailored variants, or from existing variants created in an ad-hoc way once their separated maintenance and evolution become challenging. Despite the vast literature about re-engineering systems into SPLs and related technical approaches, there is a lack of detailed analysis of the process itself and the effort involved. In this paper, we provide and analyze empirical data of the extraction processes of two open-source case studies, namely ArgoUML and Phaser. Both cases emerged from the transition of a monolithic system into an SPL. The analysis relies on information mined from the version control history of their respective source-code repositories and the discussion with developers that took part in the process. Unlike previous works that focused mostly on the structural results of the final SPL, the contribution of this study is an in-depth characterization of the processes. With this work, we aimed at providing a deeper understanding of the strategies for SPL extraction and their implications. Our results indicate that the source code changes can range from almost a fourth to over half of the total lines of code. Developers may or may not use branching strategies for feature extraction. Additionally, the problems faced during the extraction process may be due to lack of tool support, complexity on managing feature dependencies and issues with feature constraints. We made publicly available the datasets and the analysis scripts of both case studies to be used as a baseline for extractive SPL adoption research and practice.

In collaborative software development, merge conflicts arise when developers integrate concurrent code changes. Practitioners seek to minimize the number of merge conflicts because resolving them is difficult, time consuming, and often an error-prone task. Despite a substantial number of studies investigating merge conflicts, the challenges in merge conflict resolution are not well understood. Our goal is to investigate which factors make merge conflicts longer to resolve in practice. To this end, we performed a two-phase study. First, we analyzed 66 projects containing around 81 thousand merge scenarios, involving 2 million files and over 10 million chunks. For this analysis, we use rank correlation, principal component analysis, multiple regression model, and effect-size analysis to investigate which independent variables (e.g., number of conflicting chunks and files) mostly influence our dependent variable (i.e., time to merge). We found that the number of chunks, lines of code, conflicting chunks, developers involved, conflicting lines of code, conflicting files, and the complexity of the conflicting code influence the merge conflict resolution time. Second, we surveyed 140 developers from our subject projects aiming at cross-validating our results from the first phase of our study. As main results, (i) we found that committing small chunks makes merge conflict resolution faster when leaving other independent variables untouched, (ii) we found evidence that merge scenario characteristics (e.g., the number of lines of code or chunks changed in the merge scenario) are stronger correlated with our dependent variable than merge conflict characteristics (e.g., the number of lines of code or chunks in conflict), (iii) we devise a taxonomy of four types of challenges in merge conflict resolution, and (iv) we observed that the inherent dependencies among conflicting and non-conflicting code is one of the main factors influencing the merge conflict resolution time.

Mutation testing is a fault-based technique commonly used to evaluate the quality of test suites in software systems. It consists of introducing syntactical changes, called mutations, into source code and checking whether the test cases distinguish them. Since there are dozens of distinct mutation types, one of the most challenging problems is the high computational effort required to test the whole test suite against each mutant. Since mutation testing is proposed, researchers have presented techniques aiming at effort reduction in the phases of its process. This study focuses on the potential reduction in the number of mutants provided by a special set of mutants generated by the introduction of two syntactical changes (strongly subsuming second-order mutants). In this work, we exhaustively searched for those second-order mutants Our results show that they (i) are frequently generated by the "expression removal" mutation, (ii) are likely to be killed by the same test cases that kill their constituent mutants, and (iii) have the potential to reduce the number of mutants to be executed by about 22.3%.

In globally distributed software development, many software developers have to collaborate and deal with issues of collaboration. Although collaboration is challenging, collaborative development produces better software than any developer could produce alone. Unlike previous work which focuses on the proposal and evaluation of models and tools to support collaborative work, this paper presents an interview study aiming to understand (i) the motivations, (ii) how collaboration happens, and (iii) the challenges and barriers of collaborative software development. After interviewing twelve experienced software developers from GitHub, we found different types of collaborative contributions, such as in the management of requests for changes. Our analysis also indicates that the main barriers for collaboration are related to non-technical, rather than technical issues.

Bad smells are symptoms of bad design choices implemented on the source code. They are one of the key indicators of technical debts, specifically, design debt. To manage this kind of debt, it is important to be aware of bad smells and refactor them whenever possible. Therefore, several bad smell detection tools and techniques have been proposed over the years. These tools and techniques present different strategies to perform detections. More recently, machine learning algorithms have also been proposed to support bad smell detection. However, we lack empirical evidence on the accuracy and efficiency of these machine learning based techniques. In this paper, we present an evaluation of seven different machine learning algorithms on the task of detecting four types of bad smells. We also provide an analysis of the impact of software metrics for bad smell detection using a unified approach for interpreting the models' decisions. We found that with the right optimization, machine learning algorithms can achieve good performance (F1 score) for two bad smells: God Class (0.86) and Refused Parent Bequest (0.67). We also uncovered which metrics play fundamental roles for detecting each bad smell.

GitHub repository issues can be “tagged” with labels to provide better understanding, organization, classification and to make information retrieval easier for both users and project managers. GitHub provides nine default labels and allows users to create, edit, and delete labels to fit the project maintainers' management goals. Such labels can, for example, help users to find open source projects that are open for new collaborators since they are able to search for the default label good first issuein GitHub's search engine. However, such a mechanism would be more powerful if the platform knew semantically similar customized labels and also reaches projects with them. In this study, we investigate two NBNE-based approaches and another based on Word2Vec algorithm to represent labels as embeddings (i.e., as vectors on a multidimensional space), so that semantically similar labels get closer. As a result, we found that Word2Vec is better indicated for this task, although it actually deserves further investigation.

Software defect prediction represents an area of interest in both academia and the software industry. Thus, software defects are prevalent in software development and might generate numerous difficulties for users and developers apart. The current literature offers multiple alternative approaches to predict the likelihood of defects in the source code. Most of these studies concentrate on predicting defects from a broad set of software features. As a result, the individual discriminating power of software features is still unknown as some perform well only with specific projects or metrics. In this study, we applied machine learning techniques in a popular dataset. This data has information about software defects in five Java projects, containing 5,371 classes and 37 software features. To this aim, we convey an exploratory investigation that produced hundreds of thousands of machine learning models from a diverse collection of software features. These models are random in the sense that they promptly select the features from the entire pool of features. Even though the immense majority of models are ineffective, we could produce several models that yield accurate predictions, thus classifying defects from Java project classes. Among these accurate models, our results indicate that change metric features are more present than entropy or class-level metrics. We concentrated our analysis on models that rank a randomly chosen defective class higher than a casually selected clean class with over 80% accuracy. We also report and discuss some features contributing to the explanation of model decisions. Therefore, our study promotes reasoning on which features support predicting defects in these projects. Finally, we present the implications of our work to practitioners.

Higher-order mutation has the potential for improving major drawbacks of traditional first-order mutation, such as by simulating more realistic faults or improving test-optimization techniques. Despite interest in studying promising higher-order mutants, such mutants are difficult to find due to the exponential search space of mutation combinations. State-of-the-art approaches rely on genetic search, which is often incomplete and expensive due to its stochastic nature. First, we propose a novel way of finding a complete set of higher-order mutants by using variational execution, a technique that can, in many cases, explore large search spaces completely and often efficiently. Second, we use the identified complete set of higher-order mutants to study their characteristics. Finally, we use the identified characteristics to design and evaluate a new search strategy, independent of variational execution, that is highly effective at finding higher-order mutants even in large codebases.

Building an application using third-party libraries is a common practice in software development. As any other software system, code libraries and their APIs evolve over time. In order to help version migration and ensure backward compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to investigate deprecation in some programming languages, such as Java and C#, there are no detailed studies on API deprecation in the JavaScript ecosystem. This paper provides an initial assessment of API deprecation in JavaScript by analyzing 50 popular software projects. Initial results suggest that the use of deprecation mechanisms in JavaScript packages is low. However, we find five different ways that developers use to deprecate API in the studied projects. Among these solutions, deprecation utility (i.e., any sort of function specially written to aid deprecation) and code comments are the most common practices in JavaScript. Finally, we find that the rate of helpful message is high: 67% of the deprecations have replacement messages to support developers when migrating APIs.

Since software engineering is globalized and not a homogeneous whole, we expect that development practices are differently adopted across domains. However, little is known about how practices are followed in different software domains (e.g., healthcare, banking, and Oil and gas). In this paper, we report the results of an exploratory and inductive research, in which we seek differences and similarities regarding the adoption of several widespread practices across 13 domains. We interviewed 19 worldwide developers with experience in multiple domains (i.e., cross-domain developers) from large multinational companies, such as Facebook, Google, and Macy's. We also run a Web survey to confirm (or not) the interview results. Our findings show that, in fact, different domains adopt practices in a different fashion. We identified that continuous integration practices are interrupted during important commerce periods (e.g., Black Friday) in the financial domains. We also noticed the company's culture and policies strongly influence the adopted practices, instead of the domain itself. Our study also has important implications for global software engineering practices. For instance, companies should provide targeted training for their development teams and new interdisciplinary courses in software engineering and other domains, such as healthcare, are highly recommended.

Code changes are performed differently in the mobile and non-mobile platforms. Prior work has investigated the differences in specific platforms. However, we still lack a deeper understanding of how code changes evolve across different software platforms. In this paper, we present a study aiming at investigating the frequency of changes and how source code, build and test changes co-evolve in mobile and non-mobile platforms. We developed regression models to explain which factors influence the frequency of changes and applied the Apriori algorithm to find types of changes that frequently co-occur. Our findings show that non-mobile repositories have a higher number of commits per month and our regression models suggest that being mobile significantly impacts on the number of commits in a negative direction when controlling for confound factors, such as code size. We also found that developers do not usually change source code files together with build or test files. We argue that our results can provide valuable information for developers on how changes are performed in different platforms so that practices adopted in successful software systems can be followed.

The use of games and game elements in software engineering education is not new. In fact, their use in Software Engineering education is found in research papers since 1974, with a notorious increase after 2000. However, there is little information about the actual adoption of these approaches in software engineering education. Therefore, the goal of this paper is to investigate the use of games and game elements in software engineering education, in the perspective of educators. To achieve this goal, this study proposes and analyzes the results of a survey answered by 88 software engineering professors. We sample the participants by inviting 285 educators mined from one hundred well-stablished universities and educational institutions of different regions of Brazil. The goal of the survey is (i) to collect information about the use of games and gamification in classrooms and (ii) to understand the relation of ACM/IEEE knowledge areas and the used game-related methods. The results show that most of the professors are aware of these educational approaches, the games were adopted by only 21 participants and game elements were only adopted by 19 participants. Games are most used to cover “Software Process” and “Project Management”. The most used game elements are Points, Quizzes, and Challenges. The results also show that the main reasons for not adopting the resources are the lack of knowledge, lack of information about relevant games for teaching software engineering, and the lack of time to plan and include these approaches in the classroom. Finally, results show a positive tendency towards the future adoption of these game-related approaches by the software engineering professors.

The worldwide demand for software developers are increasing, however, students are facing problems to learn programming at universities. To make things worse, the failure and dropout rates are high, especially in introductory computer programming courses. To address this type of problem, new strategies have been proposed to engage students in programming courses. One strategy is to use game elements to learn programming. Game elements are important for the success or failure of an educational serious game. In the same way, the students' learning process may benefit from proper use of game elements. In this work, we aim to identify and evaluate which game elements contribute to the students' learning in programming education. We performed 19 user studies to investigate the impact on learning of game elements present in two serious games for learning programming. The study was carried out with students from introductory periods of the undergraduate program in Information Systems. Our results identify some game elements that have positive effect on learning programming. The students' feedback also indicates that game elements help them staying focused, engaged and that games are useful complementary resource for learning process.

Software metrics and thresholds provide means to quantify several quality attributes of software systems. Indeed, they have been used in a wide variety of methods and tools for detecting different sorts of technical debts, such as code smells. Unfortunately, these methods and tools do not take into account characteristics of software domains, as the intrinsic complexity of geo-localization and scientific software systems or the simple protocols employed by messaging applications. Instead, they rely on generic thresholds that are derived from heterogeneous systems. Although derivation of reliable thresholds has long been a concern, we still lack empirical evidence about threshold variation across distinct software domains. To tackle this limitation, this paper investigates whether and how thresholds vary across domains by presenting a large-scale study on 3,107 software systems from 15 domains. We analyzed the derivation and distribution of thresholds based on 8 well-known source code metrics. As a result, we observed that software domain and size are relevant factors to be considered when building benchmarks for threshold derivation. Moreover, we also observed that domain-specific metric thresholds are more appropriated than generic ones for code smell detection.

Code smells are symptoms that something may be wrong with the app.Aiming at removing code smells and improving the maintainability and performance of the app, we may apply the refactoring technique, which could reduce hardware resource use, such as CPU and memory.However, a few studies have evaluated the impacts of the refactoring in Android.This paper presents a study to assess the effects of smartphone resource use caused by refactoring of 3 classic code smells: God Class, God Method, and Feature Envy.To this purpose, we selected 9 apps from GitHub.The results show that refactoring used in desktop software may not be appropriate for Android apps.For example, the refactoring of God Method had increased CPU consumption by more than 47%, while the refactoring of the 3 code smells reduced memory consumption in average 6.51%, 8.4%, and 6.37%, respectively, in one app.Our results can support the community in conducting research and future implementation of new tools.Also, it guides app developers in refactoring and thus improving the quality of their apps.

Feature location is a traceability recovery activity to identify the implementation elements associated to a characteristic of a system. Besides its relevance for software maintenance of a single system, feature location in a collection of systems received a lot of attention as a first step to re-engineer system variants (created through clone-and-own) into a Software Product Line (SPL). In this context, the objective is to unambiguously identify the boundaries of a feature inside a family of systems to later create reusable assets from these implementation elements. Among all the case studies in the SPL literature, variants derived from ArgoUML SPL stands out as the most used one. However, the use of different settings, or the omission of relevant information (e.g., the exact configurations of the variants or the way the metrics are calculated), makes it difficult to reproduce or benchmark the different feature location techniques even if the same ArgoUML SPL is used. With the objective to foster the research area on feature location, we provide a set of common scenarios using ArgoUML SPL and a set of utils to obtain metrics based on the results of existing and novel feature location techniques.

The Software Product Line (SPL) configuration field is an active area of research and has attracted both practitioners and researchers attention in the last years. A key part of an SPL configuration is a feature model that represents features and their dependencies (i.e., SPL configuration rules). This model can be extended by adding Non-Functional Properties (NFPs) as feature attributes resulting in Extended Feature Models (EFMs). Configuring products from an EFM requires considering the configuration rules of the model and satisfying the product functional and non-functional requirements. Although the configuration of a product arising from EFMs may reduce the space of valid configurations, selecting the most appropriate set of features is still an overwhelming task due to many factors including technical limitations and diversity of contexts. Consequently, configuring large and complex SPLs by using configurators is often beyond the users' capabilities of identifying valid combinations of features that match their (non-functional) requirements. To overcome this limitation, several approaches have modeled the product configuration task as a combinatorial optimization problem and proposed constraint programming algorithms to automatically derive a configuration. Although these approaches do not require any user intervention to guarantee the optimality of the generated configuration, due to the NP-hard computational complexity of finding an optimal variant, exact approaches have inefficient exponential time. Thus, to improve scalability and performance issues, we introduced the adoption of a greedy heuristic algorithm and a biased random-key genetic algorithm (BRKGA). Our experiment results show that our proposed heuristics found optimal solutions for all instances where those are known. For the instances where optimal solutions are not known, the greedy heuristic outperformed the best solution obtained by a one-hour run of the exact algorithm by up to 67.89%. Although the BRKGA heuristic slightly outperformed the greedy heuristic, it has shown larger running times (especially on the largest instances). Therefore, to ensure a good user experience and enable a very fast configuration task, we extended a state-of-the-art configurator with the proposed greedy heuristic approach.

Dynamic software product lines demand self-adaptation of their behavior to deal with runtime contextual changes in their environment and offer a personalized product to the user. However, taking user preferences and context into account impedes the manual configuration process, and thus, an efficient and automated procedure is required. To automate the configuration process, context-aware recommendation techniques have been acknowledged as an effective mean to provide suggestions to a user based on their recognized context. In this work, we propose a collaborative filtering method based on tensor factorization that allows an integration of contextual data by modeling an N-dimensional tensor User-Feature-Context instead of the traditional two-dimensional User-Feature matrix. In the proposed approach, different types of non-functional properties are considered as additional contextual dimensions. Moreover, we show how to self-configure software product lines by applying our N-dimensional tensor factorization recommendation approach. We evaluate our approach by means of an empirical study using two datasets of configurations derived for medium-sized product lines. Our results reveal significant improvements in the predictive accuracy of the configuration over a state-of-the-art non-contextual matrix factorization approach. Moreover, it can scale up to a 7-dimensional tensor containing hundred of configurations in a couple of milliseconds.

Gamification is the application of game-design elements and game principles in non-game contexts. Gamification is a relatively new trend that has been applied in various domains, including Software Engineering. However, few studies have explored the potential of gamification in the context of Software Engineering education. In this paper, we describe an experience of introducing two game elements, namely badges and leaderboards, in an introductory Software Engineering course. Our goal is to evaluate the students' perception on the impact of these elements in their motivation towards the course. We conducted a survey with 18 participants for quantitative results, and a series of interviews with 6 participants for a qualitative perspective on the results. We observed that students received badges positively, while there were mixed results about the use of leaderboards in our strategy. The main benefits on the use of these elements is that they provide social recognition rewards for students. In addition, the use of badges establishes further objectives for students to strive for, besides grades and approval.

Bad smells are symptoms that something may be wrong in the system design or code. There are many bad smells defined in the literature and detecting them is far from trivial. Therefore, several tools have been proposed to automate bad smell detection aiming to improve software maintainability. However, we lack a detailed study for summarizing and comparing the wide range of available tools. In this paper, we first present the findings of a systematic literature review of bad smell detection tools. As results of this review, we found 84 tools; 29 of them available online for download. Altogether, these tools aim to detect 61 bad smells by relying on at least six different detection techniques. They also target different programming languages, such as Java, C, C++, and C#. Following up the systematic review, we present a comparative study of four detection tools with respect to two bad smells: Large Class and Long Method. This study relies on two software systems and three metrics for comparison: agreement, recall, and precision. Our findings support that tools provide redundant detection results for the same bad smell. Based on quantitative and qualitative data, we also discuss relevant usability issues and propose guidelines for developers of detection tools.

Software metrics provide basic means to quantify quality of software systems. However, the effectiveness of the measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to know, for instance, whether a given metric value indicates a potential problem in a class implementation. There are several methods proposed in literature to derive thresholds for software metrics. However, most of these methods (i) do not respect the skewed distribution of software metrics and (ii) do not provide a supporting tool. Aiming to fill the second gap, we propose a tool, called TDTool, to derive metric thresholds. TDTool is open source and supports four different methods for threshold derivation. This paper presents TDTool architecture and illustrates how to use it. It also presents the thresholds derived using each method based on a benchmark of 33 software product lines.

In the last decades, software product lines (SPL) have proven to be an efficient software development technique in industries due its capability to increase quality and productivity and decrease cost and time-to-market through extensive reuse of software artifacts. To achieve these benefits, tool support is fundamental to guide industries during the SPL development life-cycle. However, many different SPL tools are available nowadays and the adoption of the appropriate tool is a big challenge in industries. In order to support engineers choosing a tool that best fits their needs, this paper presents the results of a controlled empirical study to assess two Eclipse-based tools, namely FeatureIDE and pure::variants. This empirical study involved 84 students who used and evaluated both tools. The main weakness we observe in both tools are the lack adequate mechanisms for managing the variability, such as for product configuration. As a strength, we observe the automated analysis and the feature model editor.

Online courses are a method of lecturing whose application in education is not bounded by space and location constraints. They include features such as video lectures and online questionnaires. There are a few online courses to teach subjects related to Software Engineering. However, for the best of our knowledge, there is no online course to teach software process, which is a key area of Software Engineering. More important, there is no systematic study to investigate whether this way of teaching is efficient and viable to teach software process. This paper presents an empirical study to evaluate whether and how online features support the learning of software process in the light of an online Software Engineering course with 61 video lectures, 16 online questionnaires, and a discussion forum. This study relies on data of 100 undergraduate students over three consecutive years: 2014, 2015, and 2016. Data of this study suggest that students answer online questionnaires in order to review for face-to-face exams. Our results also show that videos and online questionnaires contribute to the improvement of up to 15% of student grades in software process questions when compared with students who neither watch videos nor answer online questionnaires. However, based on two exam questions that repeated over the three years, we verify that the grade improvement seems to be mostly related to video lectures watched, rather than to online questionnaires answered.

A software product line (SPL) is a set of software systems that share a common and variable set of features. Software metrics provide basic means to quantify several modularity aspects of SPLs. However, the effectiveness of the SPL measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to actually know whether a given metric value indicates a potential problem in the feature implementation. There are several methods to derive thresholds for software metrics. However, there is little understanding about their appropriateness for the SPL context. This paper aims at comparing three methods to derive thresholds based on a benchmark of 33 SPLs. We assess to what extent these methods derive appropriate values for four metrics used in product-line engineering. These thresholds were used for guiding the identification of a typical anomaly found in features' implementation, named God Class. We also discuss the lessons learned on using such methods to derive thresholds for SPLs.

Open online courses are a method of online lecturing whose application in education is not bounded by space and location constraints. The successful implementation of open courses requires conceptual changes in how instructors and students behave in open unbounded education environment. There are some emerging open courses for teaching specific topics of Software Engineering. However, it is still limited the knowledge about the best practices for learning Software Engineering processes, methods, and tools in such an open environment. To address this limitation, this paper presents and evaluates an open course for Introduction to Software Engineering. The presented open course has over 250 online students registered and is based on a face-to-face equivalent. The online course is currently composed of 44 video lectures, 160 questions in 16 quizzes, and several discussion topics. We evaluate this course by comparing the students' performance in online vs. face-to-face equivalent courses. Our results indicated that students who had access to online content achieve similar or better performance than students taking only the face-to-face course.

According to recent studies, architecture degradation is to a large extent a consequence of the introduction of code anomalies as the system evolves. Many approaches have been proposed for detecting code anomalies, but none of them has been efficient on prioritizing code anomalies that represent real problems in the architecture design. In this sense, our work aims to investigate whether the prioritization of instances of three types of classical code anomalies, Divergent Change, God Class and Shotgun Surgery, can be improved when supported by architecture blueprints. These blueprints are informal models often available in software projects, and they are used to capture key architecture decisions. Moreover, we are also investigating what information may be useful in the design blueprints to help developers on prioritizing the most critical software anomalies. In many cases, developers indicated that it would be interesting the insertion of additional information on the blueprints in order to detect architecturally-relevant anomalies.

Refactoring object-oriented (OO) code to aspects is an error-prone task. To support this task, this paper presents ConcernReCS, an Eclipse plug-in to help developers to avoid recurring mistakes during software aspectization. Based on a map of concerns, ConcernReCS automatically finds and reports error-prone scenarios in OO source code; i.e., before the concerns have been refactored to aspects.

This paper presents the results of an exploratory study on the fault-proneness of aspect-oriented programs. We analysed the faults collected from three evolving aspect-oriented systems, all from different application domains. The analysis develops from two different angles. Firstly, we measured the impact of the obliviousness property on the fault-proneness of the evaluated systems. The results show that 40% of reported faults were due to the lack of awareness among base code and aspects. The second analysis regarded the fault-proneness of the main aspect-oriented programming (AOP) mechanisms, namely pointcuts, advices and intertype declarations. The results indicate that these mechanisms present similar fault-proneness when we consider both the overall system and concern-specific implementations. Our findings are reinforced by means of statistical tests. In general, this result contradicts the common intuition stating that the use of pointcut languages is the main source of faults in AOP.

It is often claimed that inaccurate modularisation of crosscutting concerns hinders program comprehension and, as a consequence, leads to harmful software instabilities. However, recent studies have pointed out that crosscutting concerns are not always harmful to design stability. Hence, software maintainers would benefit from well documented patterns of crosscutting concerns and a better understanding about their actual impact on design stability. This paper presents a catalogue of crosscutting concern patterns recurrently observed in software systems. These patterns are described and classified based on an intuitive vocabulary that facilitates their recognition by software engineers. We analysed instances of the crosscutting patterns in object-oriented and aspect-oriented versions of three evolving programs. The outcomes of our exploratory evaluation indicated that: (i) a certain category of crosscutting patterns seems to be good indicator of harmful instabilities, and (ii) aspect-oriented solutions were unable to modularise concerns matching some crosscutting patterns.

Crosscutting concerns can hinder maintainability of a design because they do not adhere to a system's underlying modular structure. Developers, therefore, may wish to refactor designs to improve modularisation or to implement crosscutting concerns as aspects. However, few tools currently exist that assist developers in detecting and classifying crosscutting concerns in their code. Classification is important because, as recent studies have shown, crosscutting concerns are not always harmful. This paper describes a tool, ConcernMorph, for identifying crosscutting concerns and classifying them into one of a number of predefined crosscutting patterns.

Abstract This paper presents an in‐depth study of the adequacy of the AspectJ language for modularizing and reusing exception‐handling code. The study consisted of refactoring existing applications so that the code responsible for implementing error‐handling strategies was moved to newly created exception handler aspects. We have performed quantitative assessments of five systems—four object‐oriented and one aspect‐oriented—based on four key quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi‐perspective analysis of the refactored systems, including (i) the extent to which error‐handling aspects can be reused, (ii) the beneficial and harmful aspectization scenarios for exception handling, and (iii) the scalability of AOP to support the modularization of exception handling in the presence of other aspects. Copyright © 2009 John Wiley & Sons, Ltd.

Software product lines (SPLs) enable modular, large-scale reuse through a software architecture addressing multiple core and varying features. To reap the benefits of SPLs, their designs need to be stable. Design stability encompasses the sustenance of the product line’s modularity properties in the presence of changes to both the core and varying features. It is usually assumed that aspect-oriented programming promotes better modularity and changeability of product lines. However, there is no empirical evidence on its efficacy to prolong design stability of product lines in realistic development scenarios. This paper reports a quantitative study that evolves two SPLs to assess various facets of design stability of aspect-oriented implementations. Our investigation focused upon a multi-perspective analysis of the evolving product lines in terms of modularity, change propagation, and feature interaction.

It is usually assumed that the implementation of exception handling can be better modularized by the use of aspect-oriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the AspectJ language for modularizing exception handling code. The study consisted in refactoring existing applications so that the code responsible for implementing heterogeneous error handling strategies was moved to separate aspects. We have performed quantitative assessments of four systems - three object-oriented and one aspect-oriented - based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi-perspective analysis of the refactored systems, including (i) the reusability of the aspectized error handling code, (ii) the beneficial and harmful aspectization scenarios, and (iii) the scalability of AOP to aspectize exception handling in the presence of other crosscutting concerns.