Abstract The productivity of software developers is influenced by various factors encompassing technical, organizational, and individual aspects. Among these factors, mental health has emerged as a critical element for sustaining performance and well-being in this context. This work primary focus lies in understanding developers’ perceptions and acceptance of metrics related to mental health and productivity. Firstly, a mapping study was conducted to map the existing knowledge in this area. A total of 178 papers were retrieved using a predefined search string. After applying strict inclusion and exclusion criteria, five secondary studies were selected and 99 factors influencing productivity and/or mental health in the workplace were identified. Secondly, a metrics catalog was developed based on these influencing factors, combining established indicators from literature with new metrics designed to monitor developers’ mental health and productivity. The catalog includes 12 metrics along with their respective measurement formulas. Thirdly, an assessment of this catalog was performed through a survey and structured interviews with industry professionals, gathering insights on the applicability and relevance of the proposed metrics. The survey was completed by 47 software developers, 22 of whom also participated in the interviews. Our results reveal that while developers largely recognized the value of the catalog, resistance emerged when these metrics were positioned as evaluative mechanisms in the workplace.

Abstract Social coding platforms like GitHub facilitate collaborative software development through pull requests (PRs), which generate discussions that significantly impact code quality, requirements, and design. Such conversations become a rich source of insights for improving development practices and predicting project outcomes and are subject to several human aspects that have been linked to code quality and PR acceptance. Sentiment analysis is one of the many ways to try to understand these human aspects. However, PR discussions are multifaceted, often involving technical jargon and aspects which limits the utility of general-purpose sentiment analysis tools. This has led to the creation of SE-specific tools, but recent studies have also observed that they demonstrate limited effectiveness. Thus, this study explores the potential of using large language models (LLMs) for this purpose, given their enhanced contextual understanding and ability to process technical language. We evaluated ten LLMs across proprietary and open-source categories, using two complementary datasets: a curated Gold dataset and the PRemo dataset, which captures real-world PR discussions. The models were assessed under zero-shot, few-shot and chain-of-thought prompting techniques on 8,913 messages. In addition, we establish baselines by evaluating fine-tuned transformer-based models. Results show that GPT-4o achieved the highest overall performance across the LLMs, though smaller models, such as Mistral Small and Deepseek-R1 32B delivered competitive results. Transformer-based models achieved excellent performance on the Gold dataset but exhibited degradation on the PRemo dataset. Finally, we conducted a qualitative analysis of misclassified instances, revealing recurring challenges related to technical terminology, sentiment-charged keywords, message length, and contextual ambiguity. These findings suggest that model selection should balance performance requirements against practical constraints, rather than defaulting to the largest available models.

Open software development platforms, such as GitHub, foster developers’ collaboration in coding tasks through pull requests (PR). PRs serve as a mechanism for code contributions and structured discussions. These discussions often involve developers exchanging messages that contain questions. Despite the importance of questions, existing studies have not gathered insights on what are recurring types of questions in GitHub PR discussions. In this paper, we address this gap by leveraging the well-established 5W2H framework, which consists of seven questions classes. Our goal is to analyze the distribution of these question types within GitHub PRs and assess whether language models, specifically GPT-3.5 and GPT-4o, can accurately classify them. We conducted our study using a dataset derived from nine GitHub projects from the Netflix and Google ecosystems. Our findings reveal that both GPT-3.5 and GPT-4o perform well in identifying What and Who classes, which were the most frequently occurring question types in developers’ discussions. However, both models struggled with less common categories, failing to detect How Much, and showing inconsistencies in classifying Where, When, Why, and How. These findings suggest that improving classification accuracy may require incorporating domain-specific context and refining prompt engineering techniques.

Refactoring is a common practice in software development, aimed at improving the internal code structure in order to make it easier to understand and modify. Consequently, it is often assumed that refactoring makes the code less prone to bugs. However, in practice, refactoring is a complex task and applied in different ways (e.g., various refactoring types, single vs. composite refactorings) and with a variety of purposes (e.g., root-canal vs. floss refactoring). Therefore, certain refactorings can inadvertently make the code more prone to bugs. Unfortunately, there is limited research in the literature on the long-term relationship between the different characteristics of refactorings and bugs. This paper presents a longitudinal study of 12 open source software projects, where 27,450 refactorings, 6,051 reported bugs, and 49,250 bugs detected with static analysis tools were analyzed. While our study confirms the common intuition that refactored code is less bug-prone than non-refactored code, we also extend or contradict existing body of knowledge in other ways. First, a code element that undergoes multiple refactorings is not less bug-prone than an element that undergoes a single refactoring. A single refactoring is the one not performed in conjunction with other refactorings in the same commit. Second, single refactorings often induce the occurrence of bugs across all analyzed projects. Third, code elements affected by refactorings made in conjunction with other non-refactoring changes in the same commit (i.e., floss refactorings) are often bug-prone. Finally, many of such bugs induced by refactoring cannot be revealed with state-of-the-art techniques for detecting behavior-preserving refactorings.

Refactoring is a practice widely adopted during software maintenance and evolution. Due to its importance, there is extensive work on the effectiveness of refactoring in achieving code quality. However, developer’s intentions are usually overlooked. A more recent area of study involves the concept of self-affirmed refactoring (SAR), where developers explicitly state their intent to refactor. While studies on SAR have made valuable contributions, they provide little insights into refactoring complexity and effectiveness, as well as the refactorings’ relations to specific non-functional requirements. A study by Soares et al. published in 2020 addressed such aspects, but it relied on a quite small sample of studied subject systems and refactoring instances (in addition to other limitations). Following the empirical method of replication, we expanded the scope of Soares et al.’s study by doubling the number of projects analyzed (eight in total), and a significantly larger set of validated refactorings (8,408). Our findings only partially align with the original study. We observed that when developers explicitly state their refactoring intent, the resulting changes typically involve a combination of different refactoring types, making them more complex. Additionally, we confirmed that such complex refactorings positively impact code’s internal quality attributes. Yet, while refactorings targeting non-functional requirements generally enhance code quality compared to refactorings without this explicit concern, our observations only partially confirm the original study’s conclusions. Furthermore, our results contradict the original study in various aspects. For example, we interestingly found that SARs (compared to non-SARs) tend to produce fewer negative effects on internal quality attributes despite their quite frequent complexity. These findings highlight the need for reducing the complexity of refactorings while maximizing their positive effects. They also underscore the importance of explicitly stating refactoring intentions, as this provides a clear mental framework that guides effective refactoring efforts.

Modern software development relies on cloud-based collaborative platforms (e.g., GitHub and GitLab). In these platforms, developers often employ a pull-based development approach, proposing changes via pull requests and engaging in communication via asynchronous message exchanges. Since communication is key for software development, studies have linked different types of sentiments embedded in the communication to their effects on software projects, such as bug-inducing commits or the non-acceptance of pull requests. In this context, sentiment analysis tools are paramount to detect the sentiment of developers’ messages and prevent potentially harmful impact. Unfortunately, existing state-of-the-art tools vary in terms of the nature of their data collection and labeling processes. Yet, there is no comprehensive study comparing the performance and generalizability of existing tools utilizing a dataset that was designed and systematically curated to this end, and in this specific context. Therefore, in this study, we design a methodology to assess the effectiveness of existing sentiment analysis tools in the context of pull request discussions. For that, we created a dataset that contains ≈ 1.8K manually labeled messages from 36 software projects. The messages were labeled by 19 experts (neuroscientists and software engineers), using a novel and systematic manual classification process designed to reduce subjectivity. By applying these existing tools to the dataset, we observed that while some tools ]perform acceptably, their performance is far from ideal, especially when classifying negative messages. This is interesting since negative sentiment is often related to a critical or unfavorable opinion. We also observed that some messages have characteristics that can make them harder to classify, causing disagreements between the experts and possible misclassifications by the tools, requiring more attention from researchers. Our contributions include valuable resources to pave the way to develop robust and mature sentiment analysis tools that capture/anticipate potential problems during software development.

Context: There is a growing belief in the literature that large language models (LLMs), such as ChatGPT, can mimic human behavior in surveys. Gap: While the literature has shown promising results in social sciences and market research, there is scant evidence of its effectiveness in technical fields like software engineering. Objective: Inspired by previous work, this paper explores ChatGPT’s ability to replicate findings from prior software engineering research. Given the frequent use of surveys in this field, if LLMs can accurately emulate human responses, this technique could address common methodological challenges like recruitment difficulties, representational shortcomings, and respondent fatigue. Method: We prompted ChatGPT to reflect the behavior of a ‘mega-persona’ representing the demographic distribution of interest. We replicated surveys from 2019 to 2023 from leading SE conferences, examining ChatGPT’s proficiency in mimicking responses from diverse demographics. Results: Our findings reveal that ChatGPT can successfully replicate the outcomes of some studies, but in others, the results were not significantly better than a random baseline. Conclusions: This paper reports our results so far and discusses the challenges and potential research opportunities in leveraging LLMs for representing humans in software engineering surveys.

Refactoring is a non-trivial maintenance activity. Developers spend time and effort refactoring code to remove structural problems, i.e., code smells. Recent studies indicated that developers often apply composite refactoring (composite, for short), i.e., two or more interrelated refactorings. However, prior studies revealed that only 10% of composite refactorings are considered complete, i.e., those fully removing code smells. Many incomplete refactorings can even replace or introduce smells, requiring additional effort for their removal later in the project. Moreover, existing refactoring recommendations are not well-detailed and do not alert developers about these possible side effects. To address these gaps, we conducted a large-scale study involving more than 250k refactorings from 42 software projects, including both open-source and closed-source projects. Our goal is to investigate how the most common complete composites are combined and their side effects in the practice. Our results reveal that the current recommendation to apply Extract Method(s) with fine-grained refactoring types needs refinements. We found that certain fine-grained refactorings like Change Variable Types and Change Return Types can introduce up to 45% of Brain Methods when combined with Extract Method(s). Moreover, Ex-tract Method(s) and Move Method(s), a common recommendation to remove Feature Envy, may inadvertently introduce about 30% of Lazy Classes and approximately 70% of Data Classes. Despite these potential side effects, existing refactoring catalogs and tools' recommenders do not alert developers about these side effects. Finally, we consolidate our findings into a catalog to provide clear guidance for developers and researchers on effectively applying composite refactorings to fully remove code smells.

Robustness is critical for ensuring that software functions correctly under adverse conditions. Exception-handling mechanisms in programming languages enable developers to deal with these adverse conditions. However, implementing exception-related code can present significant challenges to developers. We investigated exception-related code contributions across Java projects in the Apache ecosystem. We analyzed exception-related pull requests (exception-PRs), which were detected using a validated heuristic. We produced a comprehensive dataset of 988 exception-PRs. We observed no statistically significant differences in complexity metrics between exception-PRs and non-exception-PRs. We also found no significant differences in developers' behavior metrics, indicating consistent engagement regardless of whether the pull request addressed exception-related code. A manual analysis revealed that most exception-PRs focused on system improvements rather than bug fixes, suggesting proactive efforts to enhance software robustness. Moreover, the most frequently addressed aspects of exceptional code in these exception-PRs were: (i) the external representation of adverse situations to end-users (more than 40% of the PRs) and (ii) the implementation of effective error-handling actions (nearly 35% of the PRs) to promote program recoverability. Interestingly, a significant proportion of exception-PRs simultaneously addressed multiple aspects. By understanding the nature and characteristics of exception-PRs, we expect to better support developers in managing erroneous conditions and improving software robustness.

The modernization of monolithic legacy systems with microservices has been a trend in recent years. As part of this modernization, identifying microservice candidates starting from legacy code is challenging, as maintainers may consider many criteria simultaneously. Multi-objective search-based approaches represent a promising state-of-the-art solution to support this decision-making process. However, the rationale to adopt each microservice candidate automatically identified by these approaches is poorly investigated in industrial cases. Furthermore, studies with these approaches have not carefully investigated how maintainers reason and make decisions when designing microservice architectures from legacy systems. To address this gap, we conducted an on-site case study with maintainers of an industrial legacy system to investigate the usefulness of automatically generated microservice architectures. We analyze design decisions pointed out by the maintainers when reasoning about microservice candidates using several criteria at the same time. Our study is the first to assess a search-based approach involving actual maintainers conceiving microservice architectures in an industrial setting. Therefore, firstly, we considered individual evaluation of microservice candidates to understand the rationale for identifying a service. Secondly, we conducted a focus group study with maintainers with the goal of investigating design decisions at an architectural level. The results show that:(i)the automated approach is able to identify useful microservices;(ii)the criteria observed by previous studies are, in fact, considered by maintainers; and(iii)the maintainer profiles, i.e., the preferred granularity for microservice, highly affect design decisions. Finally, we observed the maintainers needed little effort in adjusting the automatically identified microservices to make them adoptable. In addition to indicating a promising potential of search-based approaches to generate microservice architectures, our findings highlight the need for:(i)interactive and/or customizable approaches that enable maintainers to include their preferences during the search process, and(ii)flexible or automated selection of criteria that fits the scenario in which the modernization is taking place.

Background: Code development is done collaboratively in platforms such as GitHub and GitLab, following a pull-based development model. In this model, developers actively communicate and share their knowledge through conversations. Pull request conversations are affected by social aspects such as communication dynamics among developers, discussion content, and organizational dynamics. 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, characterizing in terms of three different social aspects: discussion content, organizational and communication dynamics. We considered 18 social metrics to these three social aspects, and analyzed how they associate with design decay. 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. Organizational growth and gender diversity prevent decay. Each software community has its unique aspects that can be used to detect and prevent design decay. Also, 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.

Refactoring is a common software maintenance practice. The literature defines standard code modifications for each refactoring type and popular IDEs provide refactoring tools aiming to support these standard modifications. However, previous studies indicated that developers either frequently avoid using these tools or end up modifying and even reversing the code automatically refactored by IDEs. Thus, developers are forced to manually apply refactorings, which is cumbersome and error-prone. This means that refactoring support may not be entirely aligned with practical needs. The improvement of tooling support for refactoring in practice requires understanding in what ways developers tailor refactoring modifications. To address this issue, we conduct an analysis of 1,162 refactorings composed of more than 100k program modifications from 13 software projects. The results reveal that developers recurrently apply patterns of additional modifications along with the standard ones, from here on called patterns of customized refactorings. For instance, we found customized refactorings in 80.77% of the Move Method instances observed in the software projects. We also investigated the features of refactoring tools in popular IDEs and observed that most of the customization patterns are not fully supported by them. Additionally, to understand the relevance of these customizations, we conducted a survey with 40 developers about the most frequent customization patterns we found. Developers confirm the relevance of customization patterns and agree that improvements in IDE's refactoring support are needed. These observations highlight that refactoring guidelines must be updated to reflect typical refactoring customizations. Also, IDE builders can use our results as a basis to enable a more flexible application of automated refactorings. For example, developers should be able to choose which method must handle exceptions when extracting an exception code into a new method.

In collaborative software development, multiple contributors frequently change the source code in parallel to implement new features, fix bugs, refactor existing code, and make other changes. These simultaneous changes need to be merged into the same version of the source code. However, the merge operation can fail, and developer intervention is required to resolve the conflicts. Studies in the literature show that 10 to 20 percent of all merge attempts result in conflicts, which require the manual developer's intervention to complete the process. In this paper, we concern about a specific type of change that affects the structure of the source code and has the potential to increase the merge effort: code refactorings. We analyze the relationship between the occurrence of refactorings and the merge effort. To do so, we applied a data mining technique called association rule extraction to find patterns of behavior that allow us to analyze the influence of refactorings on the merge effort. Our experiments extracted association rules from 40,248 merge commits that occurred in 28 popular open-source projects. The results indicate that: (i) the occurrence of refactorings increases the chances of having merge effort; (ii) the more refactorings, the greater the chances of effort; (iii) the more refactorings, the greater the effort; and (iv) parallel refactorings increase even more the chances of having effort, as well as the intensity of it. The results obtained may suggest behavioral changes in the way refactorings are implemented by developer teams. In addition, they can indicate possible ways to improve tools that support code merging and those that recommend refactorings, considering the number of refactorings and merge effort attributes.

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.

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.

Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide higher modularization. However, bad DI practices often lead to negative consequences, such as increasing coupling. Although white literature conjectures about the existence of DI anti-patterns, there is no evidence on their practical relevance, usefulness, and generality. The objective of this study is to propose and evaluate a catalog of DI anti-patterns and associated refactorings. We reviewed existing reported DI anti-patterns in order to analyze their completeness. The limitations found in literature motivated proposing a novel catalog of 12 DI anti-patterns. We developed a tool to statically analyze the occurrence level of the candidate DI anti-patterns in both open-source and industry projects. Next, we survey practitioners to assess their perception on the relevance, usefulness, and their willingness on refactoring anti-pattern instances of the catalog. Our static code analyzer tool showed a relative recall of 92.19% and high average precision. It revealed that at least 9 different DI anti-patterns appeared frequently in the analyzed projects. Besides, our survey confirmed the perceived relevance of the catalog and developers expressed their willingness to refactor instances of anti-patterns from source code. The catalog contains DI anti-patterns that occur in practice and that are perceived as useful. Sharing it with practitioners may help them to avoid such anti-patterns, thus improving source-code quality.

Recent studies have revealed that developers often apply composite refactorings (or, simply, composites). A composite consists of two or more interrelated refactorings applied together. Previous studies investigated the effect of composites on code smells. A composite is considered “complete” whenever it completely removes one target code smell. They proposed descriptions of complete composites with recommendations to remove certain code smell types, such as Long Methods and Feature Envies. These studies also present different recommendations to remove the same code smell type. However, these studies: (i) are limited to composites only consisting of a small subset of Fowler's refactoring types, (ii) do not detail the scenarios in which each recommendation can be applied to remove the code smell, and (iii) fail in reporting possible side effects of the described composites, such as adversely introducing certain smell types. This paper aims to cover these limitations by performing a systematic analysis of 618 complete composites on removing four common smell types identified in 20 software projects. Our results indicated that: (i) 64% complete composites consisted of refactoring types not covered by existing descriptions of complete composites, and (ii) 36% complete composites formed by Extract Methods can introduce Feature Envies and Intensive Couplings. This information is not documented by existing descriptions, and it can alert developers about alternatives to remove Feature Envy, mainly in methods that are fully envious. These results suggest existing descriptions of complete composites should be either revisited or enhanced to explicitly highlight known side effects. We present a catalog of composites with details about side effects, recommendations to remove or minimize them, and some scenarios in which each recommendation can be applied to remove the code smell. Our catalog can be useful to improve existing tooling support for refactorings, such as IDEs, informing about possible side effects when refactorings are composed.

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.

Microservices are small and autonomous services that communicate through lightweight protocols. Companies have often been adopting microservices to incrementally redesign legacy systems as part of a modernization process. Microservices promote better reuse and customization of existing features while increasing business capabilities, if appropriate design decisions are made. There are some partially-automated approaches supporting the re-design of legacy features into microservices. However, they fail in covering two key aspects: (i) provide an architectural design of the features being redesigned, and (ii) simultaneously support relevant criteria, e.g., feature modularization and decrease of network communication overhead. Also, these two aspects tend to be poorly discussed along industrial case studies. To fulfill these gaps, we propose a redesign strategy to support the re-engineering of features legacy code as microservices. This strategy covers key possibly-conflicting criteria on microservice-based architectures. We employ search-based optimization to deal with such conflicting criteria. The output of the strategy is a set of redesign candidates of legacy features as microservices. We reflect upon the benefits and drawbacks of the proposed strategy through an industrial case study. In particular, we perform an in-depth analysis of the resulting microservice candidates, and a discussion about their potential for customization and reuse. The reflections/discussions are also supported by observations of developers involved in the process.

Abstract Substantial research is available on detectinginfluencerson social media platforms. In contrast, comparatively few studies exists on the role ofonline activists, defined informally as users who actively participate in socially-minded online campaigns. Automatically discovering activists who can potentially be approached by organisations that promote social campaigns is important, but not easy, as they are typically active only locally, and, unlike influencers, they are not central to large social media networks. We make the hypothesis that such interesting users can be found on Twitter within temporally and spatially localisedcontexts. We define these as small but topical fragments of the network, containing interactions about social events or campaigns with a significant online footprint. To explore this hypothesis, we have designed an iterative discovery pipeline consisting of two alternating phases of user discovery and context discovery. Multiple iterations of the pipeline result in a growing dataset of user profiles for activists, as well as growing set of online social contexts. This mode of exploration differs significantly from prior techniques that focus on influencers, and presents unique challenges because of the weak online signal available to detect activists. The paper describes the design and implementation of the pipeline as a customisable software framework, where user-defined operational definitions of online activism can be explored. We present an empirical evaluation on two extensive case studies, one concerning healthcare-related campaigns in the UK during 2018, the other related to online activism in Italy during the COVID-19 pandemic.

Microservices are small and independently deployable services. They can be developed on different platforms and communicate via lightweight protocols, what makes them highly interoperable. The interoperability between microservices, as well as their reuse and customization needs make this kind of systems adequate to constitute a Software Product Line. However, there is no automatic approach to support the designing of Microservices-Based Product Lines (MBPLs). To move towards the development of MBPLs, this work presents an approach, named MOEA4MBPL, to extract Feature Models (FMs) from a set of microservices-based systems. These FMs intent to leverage interoperability, enabling the practitioners to reason about reuse and/or customization of functionalities. The proposed approach is based on multi-objective evolutionary algorithms, optimizing three objectives, namely precision and recall of products denoted by an FM, and conformance with existing dependencies between microservices. MOEA4MBPL was evaluated with six microservices-based systems, using the algorithms NSGA-II and SPEA2. Our approach was capable of finding FMs with good trade-off values of precision and recall, satisfying all dependencies among the microservices. SPEA2 found better fronts of solutions than NSGA-II, but the latter always executed faster and could find single solutions closer to an ideal solution than the former.

The expensive maintenance of legacy systems leads companies to migrate such systems to microservice architectures. This migration requires the identification of system's legacy parts to become microservices. However, the successful identification of microservices, which are promising to be adoptable in practice, requires the simultaneous satisfaction of many criteria, such as coupling, cohesion, reuse and communication overhead. Search-based microservice identification has been recently investigated to address this problem. However, state-of-the-art search-based approaches are limited as they only consider one or two criteria (namely cohesion and coupling), possibly not fulfilling the practical needs of developers. To overcome these limitations, we propose toMicroservices, a many-objective search-based approach that considers five criteria, the most cited by practitioners in recent studies. Our approach was evaluated in a real-life industrial legacy system undergoing a microservice migration process. The performance of toMicroservices was quantitatively compared to a baseline. We also gathered qualitative evidence based on developers' perceptions, who judged the adoptability of the recommended microservices. The results show that our approach is both: (i) very similar to the most recent proposed approach on optimizing the traditional criteria of coupling and cohesion, but (ii) much better when taking into account all the five criteria. Finally, most of the microservice candidates were considered adoptable by practitioners.

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.

Program refactoring consists of code changes applied to improve the internal structure of a program and, as a consequence, its comprehensibility. Recent studies indicate that developers often perform composite refactorings, i.e., a set of two or more interrelated single refactorings. Recent studies also recommend certain patterns of composite refactorings to fully remove poor code structures, i.e, code smells, thus further improving the program comprehension. However, other recent studies report that composite refactorings often fail to fully remove code smells. Given their failure to achieve this purpose, these composite refactorings are considered incomplete, i.e, they are not able to entirely remove a smelly structure. Unfortunately, there is no study providing an in-depth analysis of the incompleteness nature of many composites and their possibly partial impact on improving, maybe decreasing, internal quality attributes. This paper identifies the most common forms of incomplete composites, and their effect on quality attributes, such as coupling and cohesion, which are known to have an impact on program comprehension. We analyzed 353 incomplete composite refactorings in 5 software projects, two common code smells (Feature Envy and God Class), and four internal quality attributes. Our results reveal that incomplete composite refactorings with at least one Extract Method are often (71%) applied without Move Methods on smelly classes. We have also found that most incomplete composite refactorings (58%) tended to at least maintain the internal structural quality of smelly classes, thereby not causing more harm to program comprehension. We also discuss the implications of our findings to the research and practice of composite refactoring.

Refactoring is a widely adopted practice for improving code comprehension and for removing severe structural problems in a project. When refactorings affect the system architecture, they are called architectural refactorings. Unfortunately, developers usually do not know when and how they should apply refactorings to remove architectural problems. Nevertheless, they might be more susceptible to applying architectural refactoring if they rely on code smells and code refactoring -- two concepts that they usually deal with through their routine programming activities. To investigate if smells can serve as indicators of architectural refactoring opportunities, we conducted a retrospective study over the commit history of 50 software projects. We analyzed 52,667 refactored elements to investigate if they had architectural problems that could have been indicated by automatically-detected smells. We considered purely structural refactorings to identify elements that were likely to have architectural problems. We found that the proportion of refactored elements without smells is much lower than those refactored with smells. By analyzing the latter, we concluded that smells can be used as indicators of architectural refactoring opportunities when the affected source code is deteriorated, i.e., the code hosting two or more smells. For example, when God Class or Complex Class appear together with other smells, they are indicators of architectural refactoring opportunities. In general, smells that often co-occurred with other smells (67.53%) are indicators of architectural refactoring opportunities in most cases (88.53% of refactored elements). Our study also enables us to derive a catalog with patterns of smells that indicate refactoring opportunities to remove specific types of architectural problems. These patterns can guide developers and make them more susceptible to apply architectural refactorings.

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.

Refactoring consists of a transformation applied to improve the program internal structure, for instance, by contributing to remove code smells. Developers often apply multiple interrelated refactorings called composite refactoring. Even though composite refactoring is a common practice, an investigation from different points of view on how composite refactoring manifests in practice is missing. Previous empirical studies also neglect how different kinds of composite refactorings affect the removal, prevalence or introduction of smells. To address these matters, we provide a conceptual framework and two heuristics to respectively characterize and identify composite refactorings within and across commits. Then, we mined the commit history of 48 GitHub software projects. We identified and analyzed 24,911 composite refactorings involving 104,505 single refactorings. Amongst several findings, we observed that most composite refactorings occur in the same commit and have the same refactoring type. We found that several refactorings are semantically related to each other, which occur in different parts of the system but are still related to the same task. Our study is the first to reveal that many smells are introduced in a program due to "incomplete" composite refactorings. Our study is also the first to reveal 111 patterns of composite refactorings that frequently introduce or remove certain smell types. These patterns can be used as guidelines for developers to improve their refactoring practices as well as for designers of recommender systems.

The adoption of Continuous Deployment (CD) aims at allowing software systems to quickly evolve to accommodate new features. However, structural changes to the database schema are frequent and may incur in systems' services downtime. This encompasses the proper maintenance of both schema and source code, including rewrites of all outdated queries that use the same database. Previous solutions try to mitigate the burdening task of manually rewriting outdated queries. Unfortunately, a software team must still interact with some tools to properly fix the affected queries. Moreover, the team still has to locate and modify all the impacted code, which are often error-prone tasks. Thus, a project may not experience CD benefits when changes impact various code regions. In this paper we present an alternative approach, called LESSQL, whose goal is to improve queries' stability in the presence of structural schema changes over time. LESSQL supports queries that are less dependent on the database schema since they do not include the FROM clause. An underlying framework intercepts each LESSQL query and generates a corresponding SQL query for the current schema. It also locates the query attributes in the current schema and generates proper expressions to join the required tables. LESSQL supports unsupervised, supervised and hybrid configurations to process mappings of attributes to a newer schema version. We conducted experiments in the context of a popular open-source project, which experienced many diverse structural schema changes. Experiments outcomes indicate that our approach is effective in significantly reducing the modifications required for applying schema changes, allowing to better reap the benefits of CD. While supervised and hybrid configurations achieved a success rate higher than 95% with a minor query generation overhead, the unsupervised configuration was also successful for certain types of structural schema changes. These results show that LESSQL effectively favours CD and keeps queries running after database schema changes without services interruption.

As collaborative coding environments make it easier to contribute to software projects, the number of developers involved in these projects keeps increasing. This increase makes it more difficult for code reviewers to deal with buggy contributions. Collaborative environments like GitHub provide a rich source of data on developers' contributions. Such data can be used to extract information about developers regarding technical (e.g., their experience) and social (e.g., their interactions) factors. Recent studies analyzed the influence of these factors on different activities of software development. However, there is still room for improvement on the relation between these factors and the introduction of bugs. We present a broader study, including 8 projects from different domains and 6,537 bug reports, on relating five technical, three social factors, and the introduction of bugs. The results indicate that technical and social factors can discriminate between buggy and clean commits. But, the technical factors are more determining than social ones. Particularly, the developers' habits of not following technical contribution norms and the developer's commit bugginess are associated with an increase on commit bugginess. On the other hand, project's establishment, ownership level of developers' commit, and social influence are related to a lower chance of introducing bugs.

Background: Replication is essential to build knowledge in empirical science. Experiment replications reported in the software engineering context present variabilities on their design elements, e.g., variables, materials. The understanding of these variabilities is required to plan experimental replications within a research program. However, the lack of an explicit representation of experiments' variabilities and commonalities is likely to hamper their understanding and replication planning. Aims: The goal of this paper is to explore the use of Variability Modeling Approaches (VMAs) to represent experiment families (i.e., an original study and its replications) and to investigate the feasibility of using VMAs to support experiment replication planning. Method: We selected two experiment families, analyzed their commonalities and variabilities, and represented them using a set of well-known VMAs: Feature Model, Decision Model, and Orthogonal Variability Model. Based on the resulting models, we conducted a preliminary comparison of using such alternative VMAs to support replication planning. Results: Subjects were able to plan consistent experiment replications with the VMAs as support. Additionally, through a qualitative analysis, we identified and discuss advantages and limitations of using the VMAs. Conclusions: It is feasible to represent experiment families and to plan replications using VMAs. Based on our emerging results, we conclude that the Feature Model VMA provides the most suitable representation. Furthermore, we identified benefits in a potential merge between the Feature Model and Decision Model VMAs to provide more details to support replication planning.

Background: Code refactoring aims to improve code structures via code transformations. A single transformation rarely suffices to fully remove code smells that reveal poor code structures. Most transformations are applied in batches, i.e. sets of interrelated transformations, rather than in isolation. Nevertheless, empirical knowledge on batch application, or batch refactoring, is scarce. Such scarceness helps little to improve current refactoring practices. Aims: We analyzed 57 open and closed software projects. We aimed to understand batch application from two perspectives: characteristics that typically constitute a batch (e.g., the variety of transformation types employed), and the batch effect on smells. Method: We analyzed 19 smell types and 13 transformation types. We identified 4,607 batches, each applied by the same developer on the same code element (method or class); we expected to have batches whose transformations are closely interrelated. We computed (1) the frequency in which five batch characteristic manifest, (2) the probability of each batch characteristics to remove smells, and (3) the frequency in which batches introduce and remove smells. Results: Most batches are quite simple: although most batches are applied on more than one method (90%), they are usually composed of the same transformation type (72%) and only two transformations (57%). Batches applied on a single method are 2.6 times more prone to fully remove smells than batches affecting more than one method. Surprisingly, batches mostly ended up introducing (51%) or not fully removing (38%) smells. Conclusions: The batch simplicity suggests that developers have sub-explored the combinations of transformations within a batch. We summarized some batches that may fully remove smells, so that developers can incorporate them into current refactoring practices.

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 question-naire, 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.

Root canal refactoring is a software development activity that is intended to improve dependability-related attributes such as modifiability and reusability. Despite being an activity that contributes to these attributes, deciding when applying root canal refactoring is far from trivial. In fact, finding which elements should be refactored is not a cut-and-dried task. One of the main reasons is the lack of consensus on which characteristics indicate the presence of structural degradation. Thus, we evaluated whether the density and diversity of multiple automatically detected symptoms can be used as consistent indicators of the need for root canal refactoring. To achieve our goal, we conducted a multi-case exploratory study involving 6 open source systems and 2 systems from our industry partners. For each system, we identified the classes that were changed through one or more root canal refactorings. After that, we compared refactored and non-refactored classes with respect to the density and diversity of degradation symptoms. We also investigated if the most recurrent combinations of symptoms in refactored classes can be used as strong indicators of structural degradation. Our results show that refactored classes usually present higher density and diversity of symptoms than non-refactored classes. However, root canal refactorings that are performed by developers in practice may not be enough for reducing degradation, since the vast majority had little to no impact on the density and diversity of symptoms. Finally, we observed that symptom combinations in refactored classes are similar to the combinations in non-refactored classes. Based on our findings, we elicited an initial set of requirements for automatically recommending root canal refactorings.

A design problem is the result of design decisions that negatively impact quality attributes. For example, a stakeholder introduces a design problem when he decides to addresses multiple unrelated responsibilities in a single class, impacting the modifiability and reusability of the system. Given their negative consequences, design problems should be identified and refactored. The literature still lacks evidence on which symptoms' characteristics can be used as strong indicators of design problems. For example, it is unknown if the density and diversity of certain symptoms (e.g., violations of object-oriented principles) are correlated with the occurrence of design problems. Thus, in this paper, we report a case study involving two C# systems. We evaluated the impact of refactoring, focused on removing design problems, on the density and diversity of symptoms. Results indicate that refactored classes usually present higher density and diversity of symptoms. However, the density and diversity of some symptoms, such as the violation of object-oriented principles, was not predominantly higher in refactored classes. Moreover, contrary to our expectations, refactorings caused almost no positive impact on the density and diversity of symptoms.

Defects in requirements specifications can have severe consequences during the software development lifecycle. Some of them result in overall project failure due to incorrect or missing quality characteristics such as security. There are several concerns that make security difficult to deal with; for instance, (1) when stakeholders discuss general requirements in meetings, they are often unaware that they should also discuss security-related topics, and (2) they typically do not have enough expertise in security. This often leads to unspecified or ill-defined security-related aspects. These concerns become even more challenging in agile contexts, where lightweight documentation is typically involved. The goal of this paper is to design and evaluate an approach for reviewing security-related aspects in agile requirements specifications of web applications. The approach considers user stories and security specifications as input and relates those user stories to security properties via Natural Language Processing. Based on the related security properties, our approach then identifies high-level security requirements from the Open Web Application Security Project to be verified and generates a reading technique to support reviewers in detecting defects. We evaluate our approach via two controlled experiment trials. We compare the effectiveness and efficiency of novice inspectors verifying security aspects in agile requirements using our approach against using the complete list of high-level security requirements. The (statistically significant) results indicate that using our approach has a positive impact (with large effect size) on the performance of inspectors in terms of effectiveness and efficiency.

Developers of widely used Java Virtual Machines (JVMs) implement and test the Java Reflection API based on a Javadoc, which is specified using a natural language. However, there is limited knowledge on whether Java Reflection API developers are able to systematically reveal i) underdetermined specifications; and ii) non-conformances between their implementation and the Javadoc. Moreover, current automatic test suite generators cannot be used to detect them. To better understand the problem, we analyze test suites of two widely used JVMs, and we conduct a survey with 130 developers who use the Java Reflection API to see whether the Javadoc impacts on their understanding. We also propose a technique to detect underdetermined specifications and non-conformances between the Javadoc and the implementations of the Java Reflection API. It automatically creates test cases, and executes them using different JVMs. Then, we manually execute some steps to identify underdetermined specifications and to confirm whether a non-conformance candidate is indeed a bug. We evaluate our technique in 439 input programs. Our technique identifies underdetermined specification and non-conformance candidates in 32 Java Reflection API public methods of 7 classes. We report underdetermined specification candidates in 12 Java Reflection API methods. Java Reflection API specifiers accept 3 underdetermined specification candidates (25%). We also report 24 non-conformance candidates to Eclipse OpenJ9 JVM, and 7 to Oracle JVM. Eclipse OpenJ9 JVM developers accept and fix 21 candidates (87.5%), and Oracle JVM developers accept 5 and fix 4 non-conformance candidates.

This paper presents an extended abstract incorporated as a journal-first paper into the ICSE'18 program.

The prevalence of design problems may cause re-engineering or even discontinuation of the system. Due to missing, informal or outdated design documentation, developers often have to rely on the source code to identify design problems. Therefore, developers have to analyze different symptoms that manifest in several code elements, which may quickly turn into a complex task. Although researchers have been investigating techniques to help developers in identifying design problems, there is little knowledge on how developers actually proceed to identify design problems. In order to tackle this problem, we conducted a multi-trial industrial experiment with professionals from 5 software companies to build a grounded theory. The resulting theory offers explanations on how developers identify design problems in practice. For instance, it reveals the characteristics of symptoms that developers consider helpful. Moreover, developers often combine different types of symptoms to identify a single design problem. This knowledge serves as a basis to further understand the phenomena and advance towards more effective identification techniques.

Summary The manifestation of code anomalies in software systems often indicates symptoms of architecture degradation. Several approaches have been proposed to detect such anomalies in the source code. However, most of them fail to assist developers in prioritizing anomalies harmful to the software architecture of a system. This article presents an investigation on how developers, when supported by architecture blueprints, are able to prioritize architecturally relevant code anomalies. First, we performed a controlled experiment where participants explored both blueprints and source code to reveal architecturally relevant code anomalies. Although the use of blueprints has the potential to improve code anomaly prioritization, the participants often made several mistakes. We found these mistakes might occur because developers miss relationships between implementation and blueprint elements when they prioritize anomalies in an ad hoc manner. Furthermore, the time spent on the prioritization process was considerably high. Aiming to improve the accuracy and effectiveness of the process, we provided means to automate the prioritization process. In particular, we explored 3 prioritization criteria, which establish different ways of relating the blueprint elements with code anomalies. These criteria were implemented in the JSpIRIT tool. The approach was evaluated in the context of 2 applications with satisfactory precision results.

Empirical evidence suggests exception handling is not reliably implemented. Most faults in exception handling are related to global exceptions violating the intended exception handling design. However, repairing these violations is a cumbersome and error-prone task. It requires knowing the intended design and understanding how the source code violates it. It also requires changing the source code to make it compliant with the intended design. But changing the exception handling code is a difficult task, since changes in exception handling requires changing different parts of a program. Currently, there is still no solution to assist the repair of this type of violations. To bridge this gap, we present RAVEN, a heuristic strategy aware of the global context of exceptions that produces recommendations of how violations in exception handling may be repaired. This strategy takes advantage of explicit specifications of the intended design, although their availability is not mandatory. Our results revealed RAVEN provides recommendations able to repair violations in 69 percent of the cases when policy specifications are not available and in 97 percent of the cases when specifications are available. Thus, development teams may benefit from RAVEN, even when exception handling design decisions are not documented in their projects.

Context: Code smells are symptoms in the source code that represent poor design choices. Professional developers often perceive several types of code smells as indicators of actual design problems. However, the identification of code smells involves multiple steps that are subjective in nature, requiring the engagement of humans. Human factors are likely to play a key role in the precise identification of code smells in industrial settings. Unfortunately, there is limited knowledge about the influence of human factors on smell identification. Goal: We aim at investigating whether the precision of smell identification is influenced by three key human factors, namely reviewer's professional background, reviewer's module knowledge and collaboration of reviewers during the task. We also aim at deriving recommendations for allocating human resources to smell identification tasks. Method: We performed 19 comparisons among different subsamples from two trials of a controlled experiment conducted in the context of an empirical study on code smell identification. One trial was conducted in industrial settings while the other had involved graduate students. The diversity of the samples allowed us to analyze the influence of the three factors in isolation and in conjunction. Results: We found that (i) reviewers' collaboration significantly increases the precision of smell identification, but (ii) some professional background is required from the reviewers to reach high precision. Surprisingly, we also found that: (iii) having previous knowledge of the reviewed module does not affect the precision of reviewers with higher professional background. However, this factor was influential on successful identification of more complex smells. Conclusion: We expect that our findings are helpful to support researchers in conducting proper experimental procedures in the future. Besides, they may also be useful for supporting project managers in allocating resources for smell identification tasks.

Code smells indicate poor implementation choices that may hinder program comprehension and maintenance. Their informal definition allows developers to follow different heuristics to detect smells in their projects. Machine learning has been used to customize smell detection according to the developer's perception. However, such customization is not guided (i.e. constrained) to consider alternative heuristics used by developers when detecting smells. As a result, their customization might not be efficient, requiring a considerable effort to reach high effectiveness. In fact, there is no empirical knowledge yet about the efficiency of such unguided approaches for supporting developer-sensitive smell detection. This paper presents Histrategy, a guided customization technique to improve the efficiency on smell detection. Histrategy considers a limited set of detection strategies, produced from different detection heuristics, as input of a customization process. The output of the customization process consists of a detection strategy tailored to each developer. The technique was evaluated in an experimental study with 48 developers and four types of code smells. The results showed that Histrategy is able to outperform six widely adopted machine learning algorithms - used in unguided approaches - both in effectiveness and efficiency. It was also confirmed that most developers benefit from using alternative heuristics to: (i) build their tailored detection strategies, and (ii) achieve efficient smell detection.

The C preprocessor is a simple, effective, and language-independent tool. Developers use the preprocessor in practice to deal with portability and variability issues. Despite the widespread usage, the C preprocessor suffers from severe criticism, such as negative effects on code understandability and maintainability. In particular, these problems may get worse when using undisciplined annotations, i.e., when a preprocessor directive encompasses only parts of C syntactical units. Nevertheless, despite the criticism and guidelines found in systems like Linux to avoid undisciplined annotations, the results of a previous controlled experiment indicated that the discipline of annotations has no influence on program comprehension and maintenance. To better understand whether developers care about the discipline of preprocessor-based annotations and whether they can really influence on maintenance tasks, in this paper we conduct a mixed-method research involving two studies. In the first one, we identify undisciplined annotations in 110 open-source C/C++ systems of different domains, sizes, and popularity GitHub metrics. We then refactor the identified undisciplined annotations to make them disciplined. Right away, we submit pull requests with our code changes. Our results show that almost two thirds of our pull requests have been accepted and are now merged. In the second study, we conduct a controlled experiment. We have several differences with respect to the aforementioned one, such as blocking of cofounding effects and more replicas. We have evidences that maintaining undisciplined annotations is more time consuming and error prone, representing a different result when compared to the previous experiment. Overall, we conclude that undisciplined annotations should not be neglected.

Code smells in a program represent indications of structural quality problems, which can be addressed by software refactoring. However, refactoring intends to achieve different goals in practice, and its application may not reduce smelly structures. Developers may neglect or end up creating new code smells through refactoring. Unfortunately, little has been reported about the beneficial and harmful effects of refactoring on code smells. This paper reports a longitudinal study intended to address this gap. We analyze how often commonly-used refactoring types affect the density of 13 types of code smells along the version histories of 23 projects. Our findings are based on the analysis of 16,566 refactorings distributed in 10 different types. Even though 79.4% of the refactorings touched smelly elements, 57% did not reduce their occurrences. Surprisingly, only 9.7% of refactorings removed smells, while 33.3% induced the introduction of new ones. More than 95% of such refactoring-induced smells were not removed in successive commits, which suggest refactorings tend to more frequently introduce long-living smells instead of eliminating existing ones. We also characterized and quantified typical refactoring-smell patterns, and observed that harmful patterns are frequent, including: (i) approximately 30% of the Move Method and Pull Up Method refactorings induced the emergence of God Class, and (ii) the Extract Superclass refactoring creates the smell Speculative Generality in 68% of the cases.

Design problems affect every software system. Diverse software systems have been discontinued or reengineered due to design problems. As design documentation is often informal or nonexistent, design problems need to be located in the source code. The main difficulty to identify a design problem in the implementation stems from the fact that such problem is often scattered through several program elements. Previous work assumed that code anomalies -- popularly known as code smells -- may provide sufficient hints about the location of a design problem. However, each code anomaly alone may represent only a partial embodiment of a design problem. In this paper, we hypothesize that code anomalies tend to "flock together" to realize a design problem. We analyze to what extent groups of inter-related code anomalies, named agglomerations, suffice to locate design problems. We analyze more than 2200 agglomerations found in seven software systems of different sizes and from different domains. Our analysis indicates that certain forms of agglomerations are consistent indicators of both congenital and evolutionary design problems, with accuracy often higher than 80%.

Current software projects deal with exceptions in implementation and maintenance phases without a clear definition of exception handling policies. We call an exception handling policy the set of design decisions that govern the use of exceptions in a software project. Without an explicit exception handling policy, developers can remain unaware of the originally intended use of exceptions. In this paper, we present Exception Handling Policies Language (EPL), a domain-specific language to specify and verify exception handling policies. The evaluation of EPL was based on a user-centric observational study and case studies. The user-centric study was performed to observe how potential users of the language actually use it. With this study, we could better understand the trade-offs related to different language design decisions based on concrete and well-documented observations and experiences reported by participants. We identified some language characteristics that hindered its use and that motivated new language constructs. In addition, we performed case studies with one open-source project and two industry-strength systems to investigate how specifying and verifying exception handling policies may assist in detecting exception handling problems. The results show that violations of exception handling policies help to indicate potential faults in the exception handling code.

Exception handling mechanisms have been introduced into programming languages in an effort to help deal with runtime irregularities. These mechanisms aim to improve code reliability by providing constructs for sectioning code into exception scopes (e.g. Java try blocks) and exception handlers (e.g. Java catch blocks). Whilst exception handling mechanisms have been the focus of much research over the past years, empirical studies have only focused on characterising exception handling code of Java and C# programs. There exists little empirical evidence on how exception handling mechanisms are used to develop software with other programming languages. Moreover, to date there exists no empirical study which has examined the structure of exception scopes across software projects. We address these shortcomings by examining the commonalities and differences of both exception scopes and handlers implemented with a wider range of languages. To this end, we analysed 50 software projects, containing code developed in C++, JavaScript, PHP, Java and C#. More than 9 million lines of code and over 20,000 exceptional code blocks were analysed. Our findings revealed significant differences in the frequency, structure and length of exception scopes and exception handlers across languages. This finding suggests that certain exception handling mechanisms are less explored by programmers using certain programming languages. However, regardless of language, exception handlers remained simplistic and in general only ever one handler was associated with each scope. Finally, our analysis confirms the existing belief that developers often pay little attention to developing exception scoping and handling behaviour.

Software Testing (ST) is one of the least known aspects of software development. Yet, software engineers often argue that it demands more than half of the costs of a software project. Thus, proper testing education is of paramount importance. In fact, the mere exposition to ST knowledge might have an impact on programming skills. In particular, it can encourage the production of more reliable code. Although this is intuitive, to the best of our knowledge, there are no empirical studies about such effects. Evidence on this matter is important to motivate - or demotivate - classical testing education. Concerned with this, we have conducted a study to investigate the possible impact of ST knowledge on the production of reliable code. Our controlled experiment involved 28 senior-level Computer Science students, 8 auxiliary functions with 92 test cases, and a total of 112 implementations. Results show that code delivered after the exposition to ST knowledge is, on average, 20% more reliable (a significant difference at the 0.01 level). Also, implementations delivered afterwards are not significantly larger in terms of lines of code. This indicates that ST knowledge can make developers produce more reliable software with no additional overhead in terms of program size.

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.

The progressive insertion of code anomalies in evolving programs may lead to architecture degradation symptoms. Several approaches have been proposed aiming to detect code anomalies in the source code, such as God Class and Shotgun Surgery. However, most of them fail to assist developers on prioritizing code anomalies harmful to the software architecture. These approaches often rely on source code analysis and do not provide developers with useful information to help the prioritization of those anomalies that impact on the architectural design. In this context, this paper presents a controlled experiment aiming at investigating how developers, when supported by architecture blueprints, are able to prioritize different types of code anomalies in terms of their architectural relevance. Our contributions include: (i) quantitative indicators on how the use of blueprints may improve process of prioritizing code anomalies, (ii) a discussion of how blueprints may help on the prioritization processes, (iii) an analysis of whether and to what extent the use of blueprints impacts on the time for revealing architecturally relevant code anomalies, and (iv) a discussion on the main characteristics of false positives and false negatives observed by the actual developers.

Mainstream programming languages provide built-in exception handling mechanisms to support robust and maintainable implementation of exception handling in software systems. Most of these modern languages, such as C#, Ruby, Python and many others, are often claimed to have more appropriated exception handling mechanisms. They reduce programming constraints on exception handling to favor agile changes in the source code. These languages provide what we call maintenance-driven exception handling mechanisms. It is expected that the adoption of these mechanisms improve software maintainability without hindering software robustness. However, there is still little empirical knowledge about the impact that adopting these mechanisms have on software robustness. This paper addressed this gap by conducting an empirical study aimed at understanding the relationship between changes in C# programs and their robustness. In particular, we evaluated how changes in the normal and exceptional code were related to exception handling faults. We applied a change impact analysis and a control flow analysis in 119 versions of 16 C# programs. The results showed that: (i) most of the problems hindering software robustness in those programs are caused by changes in the normal code, (ii) many potential faults were introduced even when improving exception handling in C# code, and (iii) faults are often facilitated by the maintenance-driven flexibility of the exception handling mechanism. Moreover, we present a series of change scenarios that decrease the program robustness.

Exception handling mechanisms (EHM) were conceived as a means to improve maintainability and reliability of programs that have to deal with exceptional situations. Amongst the different implementations of built-in EHM, we classify them in two main categories: reliability-driven and maintenance-driven. Some programming languages, such as Java, provide built-in exception handling mechanisms that promote reliability-driven EHMs. Maintenance-driven EHMs, on the other hand, promote software maintainability by not forcing developers to specify exception handling constraints. Most of modern languages, such as C#, Ruby, Python and many others support this approach. Developers usually have to choose between maintainability-driven and reliability-driven approaches to structure exception handling in their applications. However, there is still little empirical knowledge about the impact that adopting these mechanisms have on software robustness and maintenance. This paper addressed this gap by conducting an empirical study aimed at understanding the relationship between changes in Java and C# programs and their robustness. In particular, we evaluated how changes in the normal and exceptional code were related to exception handling faults. We applied a change impact analysis and a control flow analysis in 116 versions of 16 C# programs and 112 versions of 16 Java programs.

Model composition plays a central role in many software engineering activities, e.g., evolving design models to add new features. To support these activities, developers usually rely on model composition heuristics. The problem is that the models to-be-composed usually conflict with each other in several ways and such composition heuristics might be unable to properly deal with all emerging conflicts. Hence, the composed model may bear some syntactic and semantic inconsistencies that should be resolved. As a result, the production of the intended model is an error-prone and effort-consuming task. It is often the case that developers end up examining all parts of the output composed model instead of prioritizing the most critical ones, i.e., those that are likely to be inconsistent with the intended model. Unfortunately, little is known about indicators that help developers (1) to identify which model is more likely to exhibit inconsistencies, and (2) to understand which composed models require more effort to be invested. It is often claimed that software systems remaining stable over time tends to have a lower number of defects and require less effort to be fixed than unstable systems. However, little is known about the effects of software stability in the context of model evolution when supported by composition heuristics. This paper, therefore, presents an exploratory study analyzing stability as an indicator of inconsistency rate and resolution effort on model composition activities. Our findings are derived from 180 compositions performed to evolve design models of three software product lines. Our initial results, supported by statistical tests, also indicate which types of changes led to lower inconsistency rate and lower resolution effort.

SUMMARY Establishing explicit mappings between features and their implementation elements in code is one of the critical factors to maintain and evolve software systems successfully. This is especially important when developers have to evolve program families, which have evolved from one single core system to similar but different systems to accommodate various requirements from customers. Many techniques and tools have emerged to assist developers in the feature mapping activity. However, existing techniques and tools for feature mapping are limited as they operate on a single program version individually. Additionally, existing approaches are limited to recover features on demand, that is, developers have to run the tools for each family member version individually. In this paper, we propose a cohesive suite of five mapping heuristics addressing those two limitations. These heuristics explore the evolution history of the family members in order to expand feature mappings in evolving program families. The expansion refers to the action of automatically generating the feature mappings for each family member version by systematically considering its previous change history. The mapping expansion starts from seed mappings and continually tracks the features of the program family, thus eliminating the need of on demand algorithms. Additionally, we present the MapHist tool that provides support to the application of the proposed heuristics. We evaluate the accuracy of our heuristics through two evolving program families from our industrial partners. Copyright © 2013 John Wiley & Sons, Ltd.

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.

Program comprehension is an essential activity to perform software maintenance and evolution. Comprehensibility often encompasses the analysis of individual logical units, called features, which are often scattered through many program modules. Understanding how the feature code is implemented along the software evolution history is essential, for instance, to perform refactoring activities. However, existing tools do not provide means to comprehend the feature code evolution. To overcome this shortcoming, this paper presents a tool called Source Miner Evolution (SME) that provides multiple interactive and coordinated views to comprehend feature code evolution. SME implements a feature-sensitive comparison of multiple program versions. Our usability assessment with experienced developers indicated that SME allows them to efficiently perform recurring comprehension tasks on evolving feature code. The developers' performance was influenced by the combination of visual SME mechanisms, such as colors, tool tips and menu-popup interactions over the features' code elements.

SUMMARY When reflecting upon driving system requirements such as security and availability, software architects often face decisions that have a broadly scoped impact on the software architecture. These decisions are the core of the architecting process because they typically have implications intertwined in a multitude of architectural elements and across multiple views. Without a modular representation and management of those crucial choices, architects cannot properly communicate, assess and reason about their crosscutting effects. The result is a number of architectural breakdowns, such as misinformed architectural evaluation, time‐consuming trade‐off analysis and unmanageable traceability. This paper presents an architectural documentation approach in which aspects are exploited as a natural way to capture widely‐scoped design decisions in a modular fashion. The approach consists of a simple high‐level notation to describe crosscutting decisions, and a supplementary language that allows architects to formally define how such architectural decisions affect the final architectural decomposition according to different views. On the basis of two case studies, we have systematically assessed to what extent our approach: (i) supports the description of heterogeneous forms of crosscutting architecture decisions, (ii) improves the support for architecture modularity analysis, and (iii) enhances upstream and downstream traceability of crosscutting architectural decisions. Copyright © 2012 John Wiley & Sons, Ltd.

To achieve large-scale reuse and accelerate time-to-market, integration of multiple software product lines (SPLs) is becoming a trend. The integration of independently-developed SPLs enables the derivation of new products on demand in a particular domain. The basic goal is to foster the reuse of previously-implemented features across a family of independently-developed SPLs. The programming technique employed in this context should promote the reuse of feature code across the SPLs with minimum change effort. Otherwise, the stability of the target SPLs would be compromised. This paper presents an exploratory study on the stepwise integration of three product lines from the board game domain. We investigate how the programming mechanisms supported by aspect-oriented and feature-oriented programming impacted the reuse and stability of those product lines. In particular, we also analyse and compare how the use of these mechanisms made possible to reach a better tradeoff of reuse and stability of the SPL designs.

A product-line architecture (PLA) entails a design reused by a family of products sharing several features. The long-term stability of a PLA largely depends on the modularization of each feature from the design outset. As many features of a product-line crosscut the PLA decomposition, their modularity and stability are often improved with aspect-orientation according to recent studies. However, the use of this technique in proactive design of PLAs is challenging and has rarely been investigated. The problem is that information about the crosscutting nature of features is limited in this case. This paper presents a first study aimed at analyzing the feasibility of deriving stable aspect-oriented PLAs through a proactive design method. Our study relies on a product line and presents an in-depth exploratory analyse. We compare the stability of aspect-oriented and alternative candidates for proactively-designed PLAs. The results indicate that it is possible to derive aspect-oriented PLAs with superior stability based on a proactive design method. In addition, it is possible to anticipate pros and cons of PLAs with aspects when the latter are incorporated at an early design stage.

Composition code defines the binding of two or more modules in a program. Post object-oriented programming techniques are increasingly providing expressive mechanisms to enable the flexible definition of composition code. Such composition mechanisms are intended to support programmers in factoring out the complexity of a program and facilitate its evolution. However, the properties of composition code might introduce new flavours of complexity, and in turn cause side effects on program evolvability. Unfortunately, the role of composition code properties on evolving software systems is not yet well understood. This gap is mostly due to the lack of a measurement framework to characterize and quantify composition code. Existing metrics suites are focused on quantifying properties of programs and their modules only. Therefore, programmers are not able to analyse and understand the impact of particular composition properties on program evolvability. This paper presents a framework aimed at characterizing and computing composition code properties. The proposed framework consists of terminology and a metrics suite, which can be used in programs structured with diverse sets of composition mechanisms. We also empirically studied the role of the measurement framework through 22 versions of 4 software projects. Our evaluation revealed that the measurement framework provided consistent indicators of program instabilities observed in history of the evolving compositions

A considerable part of software systems is comprised of functions that support the main modules, such as array or string manipulation and basic math computation. These auxiliary functions are usually considered less complex, and thus tend to receive less attention from developers. However, failures in these functions might propagate to more critical modules, thereby affecting the system's overall reliability. Given the complementary role of auxiliary functions, a question that arises is whether agile practices, such as pair programming and test-first programming, can improve their correctness without affecting time-to-market. This paper presents an empirical assessment comparing the application of these agile practices with more traditional approaches. Our study comprises independent experiments of pair versus solo programming, and test-first versus test-last programming. The first study involved 85 novice programmers who applied both traditional and agile approaches in the development of six auxiliary functions within three different domains. Our results suggest that the agile practices might bring benefits in this context. In particular, pair programmers delivered correct implementations much more often, and test-first programming encouraged the production of larger and higher coverage test sets. On the downside, the main experiment showed that both practices significantly increase total development time. A replication of the test-first experiment with professional developers shows similar results.

Program comprehension is a key activity through maintenance and evolution of large-scale software systems. The understanding of a program often requires the evolution analysis of individual functionalities, so-called features. The comprehension of evolving features is not trivial as their implementations are often tangled and scattered through many modules. Even worse, existing techniques are limited in providing developers with direct means for visualizing the evolution of features' code. This work presents a proactive and interactive visualization strategy to enable feature evolution analysis. It proactively identifies code elements of evolving features and provides multiple views to present their structure under different perspectives. The novel visualization strategy was compared to a lightweight visualization strategy based on a tree-structure. We ran a controlled experiment with industry developers, who performed feature evolution comprehension tasks on an industrial-strength software. The results showed that the use of the proposed strategy presented significant gains in terms of correctness and execution time for feature evolution comprehension tasks.

Code anomalies are likely to be critical to the systems' maintainability when they are related to architectural problems. Many tools have been developed to support the identification of code anomalies. However, those tools are restricted to only analyze source code structure and identify individual anomaly occurrences. These limitations are the main reasons why state-of-art tools are often unable to identify architecturally-relevant code anomalies, i.e. those related to architectural problems. To overcome these shortcomings we propose SCOOP, a tool that includes: (i) architecture-code traces in the analysis of the source code, and (ii) exploits relationships between multiple occurrences of code anomalies to detect the architecturally-relevant ones. Our preliminary evaluation indicated that SCOOP was able to detect anomalous code elements related to 293 out of 368 architectural problems found in 3 software systems.

Cohesion has been avidly recognized as a key property of software modularity. Ideally, a software module is considered to be cohesive if it represents an abstraction of a single concern of the software. Modules with several concerns may be harder to understand because developers must mentally separate the source code related to each concern. Also, modules implementing several concerns are more likely to undergo changes as much as distinct development tasks may target its different concerns. The most well-known cohesion metrics are defined in terms of the syntactical structure of a module, and as a consequence fail to capture the amount of concerns realized by the module. In this context, we investigated the potential of a new metric, called Lack of Concern-based Cohesion. This metric explicitly counts the number of concerns realized by each module. We compared this metric with other five structural cohesion metrics by applying them over six open source software systems. We studied how those metrics are associated with module changes by mining over 16,000 repository revisions. Our results pointed out that the concern-based metric captured a cohesion dimension that is not reflected by structural metrics, and, as a consequence, adds to the association of cohesion and change-proneness.

A program family might degenerate due to unplanned changes in its implementation, thus hindering the maintenance of family members. This degeneration is often induced by feature code that is changed individually in each member without considering other family members. Hence, as a program family evolves over time, it might no longer be possible to distinguish between common and variable features. One of the imminent activities to address this problem is the history-sensitive recovery of program family's features in the code. This recovery process encompasses the analysis of the evolution history of each family member in order to classify the implementation elements according to their variability nature. In this context, this paper proposes history-sensitive heuristics for the recovery of features in code of degenerate program families. Once the analysis of the family history is carried out, the feature elements are structured as Java project packages; they are intended to separate those elements in terms of their variability degree. The proposed heuristics are supported by a prototype tool called RecFeat. We evaluated the accuracy of the heuristics in the context of 33 versions of 2 industry program families. They presented encouraging results regarding recall measures that ranged from 85% to 100%; whereas the precision measures ranged from 71% to 99%.

Aspect-oriented programming (AOP) aims at facilitating program comprehension and maintenance in the presence of crosscutting concerns. Aspect code is often introduced and extended as the software projects evolve. Unfortunately, we still lack a good understanding of how faults are introduced in evolving aspect-oriented programs. More importantly, there is little knowledge whether existing metrics are related to typical fault introduction processes in evolving aspect-oriented code. This paper presents an exploratory study focused on the analysis of how faults are introduced during maintenance tasks involving aspects. The results indicate a recurring set of fault patterns in this context, which can better inform the design of future metrics for AOP. We also pinpoint AOP-specific fault categories which are difficult to detect with popular metrics for fault-proneness, such as coupling and code churn.

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.

Since software product lines (SPLs) increasingly have to satisfy additional requirements, their designs might degenerate over time. The degeneration is caused by various reasons. For instance, the features suddenly start to be realized and they evolved in inconsistent ways across multiple products. In an extreme case, the SPL code is fully or partially replicated and individually changed across several evolving products. In order to regain control of the SPL assets, a key activity is the design recovery of features from existing applications. However, existing techniques for feature analysis are not effective as they tend to explicitly rely on a single project history. They do not take into consideration change histories of features across multiple evolving products of a SPL. This research proposes a novel technique for history-sensitive feature recovery while repairing degenerated SPL designs. Our technique is ought to encompass a set of heuristics for facilitating SPL design recovery. We aim at investigating to what extent exploiting multi-product change histories allow accurate identification of: (i) code elements that contribute to each feature realization; and (ii) variability properties of the feature code. The empirical evaluation of our technique will be based on two industry case studies.

Coupling in software applications is often used as an indicator of external quality attributes such as fault-proneness. In fact, the correlation of coupling metrics and faults in object oriented programs has been widely studied. However, there is very limited knowledge about which coupling properties in aspect-oriented programming (AOP) are effective indicators of faults in modules. Existing coupling metrics do not take into account the specificities of AOP mechanisms. As a result, these metrics are unlikely to provide optimal predictions of pivotal quality attributes such as fault-proneness. This impacts further by restraining the assessments of AOP empirical studies. To address these issues, this paper presents an empirical study to evaluate the impact of coupling sourced from AOP-specific mechanisms. We utilise a novel set of coupling metrics to predict fault occurrences in aspect-oriented programs. We also compare these new metrics against previously proposed metrics for AOP. More specifically, we analyse faults from several releases of three AspectJ applications and perform statistical analyses to reveal the effectiveness of these metrics when predicting faults. Our study shows that a particular set of fine-grained directed coupling metrics have the potential to help create better fault prediction models for AO programs.

The four papers in this special section focus on topics related to exception handling.

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.

Architectural aspects are expected to modularize widely-scoped concerns that naturally crosscut the boundaries of system components at the software architecture level. However, there is no empirical knowledge about the positive and negative influences of aspectual decompositions on architecture stability. This paper analyzes the influence exerted by the aspect-oriented composition mechanisms in the stability of crosscutting concerns in an evolving multi-agent software architecture. Our investigation encompassed a comparative analysis of aspectual and non-aspectual decompositions based on different architectural styles. In particular, we assessed various facets of components' and compositions' stability through such alternative designs of the same multi-agent system using conventional quantitative indicators. The evaluation focused upon a number of architecturally-relevant changes that are typically performed through real-life maintenance tasks.

Abstract Mobile agents have come forward as a technique for tackling the complexity of open distributed applications. However, the pervasive nature of code mobility implies that it cannot be modularized using only object‐oriented (OO) concepts. In fact, developers frequently evidence the presence of mobility scattering in their system's modules. Despite these problems, they usually rely on OO application programming interfaces (APIs) offered by the mobility platforms. Such classical API‐oriented designs suffer a number of architectural restrictions, and there is a pressing need for empowering developers with an architectural framework supporting a flexible incorporation of code mobility in the agent applications. This work presents an aspect‐oriented software architecture, called ArchM, ensuring that code mobility has an enhanced modularization and variability in agent systems, and is straightforwardly introduced in otherwise stationary agents. It addresses OO APIs' restrictions and is independent of specific platforms and applications. An ArchM implementation also overcomes fine‐grained problems related to mobility tangling and scattering at the implementation level. The usefulness and usability of ArchM are assessed within the context of two case studies and through its composition with two mobility platforms. Copyright © 2008 John Wiley & Sons, Ltd.

Aspect-Oriented Requirements Engineering (AORE) aims at improving separation of concerns in the problem space by offering new ways of modularising requirements. Over recent years several AORE approaches have emerged by evolving contemporary requirements approaches such as viewpoints-, scenarios- and goal-based models. Due to the novelty of these techniques, there is a lack of systematic comparative studies analyzing the benefits and drawbacks they can offer to the requirements engineering practice. This paper presents a case study contrasting four eminent AORE approaches in terms of time effectiveness and accuracy of their produced outcome. We address challenges related to the heterogeneous definitions for AORE model concepts as well as the fact that they perform similar general requirements process activities in different ways. In order to address these challenges, we provide a mapping of the AORE approaches onto general RE activities and provide a common naming scheme. The case study results show that specification of aspect compositions in AORE presents an effort bottleneck that has to be carefully weighed against the added benefits of modularity and analysis of systemic properties offered by AORE. Consequently, our study provides an initial yet significant stepping stone towards improving the evaluation of AORE approaches and understanding their contribution to requirements engineering.

It is usually assumed that exception handling code can be better modularized by the use of aspect-oriented programming (AOP) techniques. However, recent studies argue that the ad hoc use of AOP can be detrimental to the quality of a system. When refactoring exception handling code to aspects, developers and maintainers need to follow clear and simple principles to obtain a well-structured system design. Otherwise, typical problems that stem from poorly designed/implemented error handling code will arise, e.g. resource leaking and swallowed exceptions. In this paper, we propose a classification for error handling code based on the factors that we found out have more influence on its aspectization. Moreover, we present a scenario catalog comprising combinations of these factors and analyze how these scenarios positively or negatively affect the task of aspectizing exception handling. We evaluated the proposed catalog through a case study where we used it to guide the aspectization of exception handling in two real systems.

Software is becoming present in every aspect of our lives, pushing us inevitably towards a world of ambient computing systems. Multi-agent systems (MAS) are a prominent technology which facilitates modeling and development of large-scale distributed systems. In recent years, software engineering research has focused on methodologies and techniques for improving MAS design and implementation. However, making large MAS dependable is still an open issue. The Fifth Workshop on Software Engineering for Large-Scale Multi-Agent Systems (SELMAS 2006) aims to bring together academic, industrial and commercial communities interested in agent-oriented software engineering topics to discuss the different technologies being defined and used in the development of dependable MAS.

This tutorial focuses on applying aspect-oriented software development (AOSD) concepts beyond the programming stage of the software development life cycle. Using concrete methods, tools, techniques and notations we discuss how to use AOSD techniques to systematically treat crosscutting concerns during requirements engineering (RE), architecture design and detailed design as well as the mapping between aspects at these stages. With a clear focus on composition, modelling, trade-off analysis and assessment methods, the tutorial imparts an engineering ethos for translation into day-to-day processes and practices.

One of the main promises of aspect-oriented programming (AOP) is to promote improved modularization of crosscutting concerns, thereby enhancing the software stability in the presence of changes. This paper presents a quantitative study that assesses the positive and negative effects of AOP on typical maintenance activities of a Web information system. The study consists of a systematic comparison between the object-oriented and the aspect-oriented versions of the same application in order to assess to what extent each solution provides maintainable software decompositions. Our analysis was driven by fundamental modularity attributes, such as coupling, cohesion, conciseness, and separation of concerns. We have found that the aspect-oriented design has exhibited superior stability and reusability through the changes, as it has resulted in fewer lines of code, improved separation of concerns, weaker coupling, and lower intra-component complexity

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.

is becoming present in every aspect of our lives, pushing us inevitably towards a world of distributed, context-aware computing systems. SELMAS'05, Software Everywhere - Context-Aware Agents, builds on the success of precedent SELMAS workshops, but with a special emphasis on the impact of the agent technology in the development of large context-aware systems. SELMAS has a track record of bringing together researchers and practitioners with a variety of perspectives in order to engage in lively discussion and debate.

The development of multiagent systems (MAS) is not a trivial task. In addition, with the advances in Internet technologies, MAS are undergoing a transition from closed to open architectures composed of a huge number of autonomous agents, which operate and move across different environments. In fact, openness introduces additional complexity to the system modeling, design and implementation. It also impacts on most quality attributes of MAS, including scalability, interoperability, reliability and adaptability. This paper brings together researchers and practitioners to discuss the current state and future direction of research in software engineering for open MAS. A particular interest is to understand those issues in the agent technology that make it difficult and/or improve the production of large open systems.

Abstract Software engineers of multi‐agent systems (MASs) are faced with different concerns such as autonomy, adaptation, interaction, collaboration, learning, and mobility, which are essentially different from classical concerns addressed in object‐oriented software engineering. MAS developers, however, have relied mostly on object‐oriented design techniques and programming languages, such as Java. This often leads to a poor separation of MAS concerns and in turn to the production of MASs that are difficult to maintain and reuse. This paper discusses software engineering approaches for MASs, and presents a new method for integrating agents into object‐oriented software engineering from an early stage of design. The proposed approach encourages the separate handling of MAS concerns, and provides a disciplined scheme for their composition. Our proposal explores the benefits of aspect‐oriented software development for the incorporation of agents into object‐oriented systems. We also illustrate our aspect‐oriented approach through the Portalware multi‐agent system, a Web‐based environment for the development of e‐commerce portals. Copyright © 2004 John Wiley & Sons, Ltd.

Objects and agents are abstractions that exhibit Points of similarity, but the development of multi-agent systems (MASs) poses other challenges to Software Engineering since software agents are inherently more complex entities. In addition, a large MAS needs to satisfy multiple stringent requirements such as reliability, trustability, security, interoperability, scalability, reusability, and maintainability. This workshop brings together researchers and practitioners to discuss the current state of the art and the future research directions in software engineering for large-scale MASs. A particular interest is to understand those issues in the agent technology that make it difficult and/or improve the production of complex distributed systems.

Objects and agents are abstractions that exhibit points of similarity, but the development of agent-based software poses other challenges to software engineering since software agents are inherently more complex entities. In addition, a large-scale multi-agent system needs to satisfy multiple stringent requirements such as reliability, security, interoperability, scalability, reusability, and maintainability. This workshop brought together researchers and practitioners to discuss the current state and future direction of research in software engineering for large-scale multi-agent systems. A particular interest was to understand those issues in the agent technology that difficult and/or improve the production of large-scale distributed systems.

Dependable object-oriented software systems are inherently complex and have to cope with an increasing number of exceptional conditions in order to meet system dependability requirements. This work proposes a software architecture which integrates uniformly both concurrent and sequential exception handling. The exception handling architecture is independent of programming language or exception handling mechanism, and its use can minimize the complexity caused by the handling of abnormal behavior. Our architecture provides, during the architectural design stage, the context in which more detailed design decisions related to exception handling are made in later development stages. This work also presents a set of design patterns which describes the static and dynamic aspects of the components of our software architecture. The patterns allow a clear separation of concerns between the system's functionality and the exception handling facilities, applying the computational reflection technique.

The current lack of effective error-handling techniques for developing dependable object-oriented software produces software components which are usually difficult to understand, to change and to maintain in the presence of faults. Ideally, such components should incorporate their exceptional activity in a structured and transparent manner so that the abnormal code would not be amalgamated into the normal code. In this context, we propose the design and implementation of an object-oriented exception handling mechanism based on a meta-level approach. The goal of our work is twofold: (i) to define an exception handling model which supports a clear and transparent separation of the normal activity of a component from its exceptional activity, and (ii) to provide a meta-level architecture which implements such mechanism. This mechanism does not require any special language support and was implemented within the Java programming language without any changes to the language itself by means of a meta-object protocol.