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.

Abstract Metamodels, like many other software artifacts, evolve and exist in multiple versions. As a result, their instances, i.e., models, can become outdated and require adaptation. This process is known as model co-evolution. Co-evolution, however, typically uses an all-or-nothing approach that overlooks four key aspects: (a) preserving the history of the metamodel, (b) retaining the model’s history before co-evolution, (c) supporting the coexistence of models across multiple metamodel versions to allow delayed co-evolution and (d) lack of traceability between model and metamodel changes. In this paper, we introduce a novel, operation-based approach that supports versioning, records the complete history of metamodels and models, and enables the coexistence of different metamodel versions. Our approach allows engineers to delay model co-evolution without losing a model’s history. It further enables both forward co-evolution and reverse de-evolution of models. In addition to that, it establishes cross-layer traceability by linking model changes back to their corresponding metamodel changes, thus improving the maintainability and understandability of evolving systems. We evaluated our approach empirically using metamodels from different domains, demonstrating that it accurately records both model and metamodel histories, supports de-evolution, and correctly traces over 17 million model changes to their metamodel origins. Scalability measurements show that our approach handles co-evolution even in large-scale scenarios, successfully evolving models with over 88,000 elements and 2 million properties while tracking nearly 500,000 changes.

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.

Many businesses depend on legacy systems, which often use outdated technology that complicates maintenance and updates. Therefore, software modernization is essential, particularly data migration between different database schemas. Established methodologies, like model transformation and ETL tools, facilitate this migration. However, these methodologies require deep knowledge of database languages and both the source and target schemas. This necessity renders data migration an error-prone and cognitively demanding task. Our objective is to alleviate developers’ workloads during schema evolution by proposing DAMI-Framework. This framework incorporates a domain-specific language (DSL) and a parser to facilitate data migration between database schemas. DAMI-DSL simplifies schema mapping, while the parser automates SQL script generation. To evaluate DAMI-Framework, we conducted an empirical evaluation with 21 developers to assess their experiences using our DSL versus traditional SQL. The study allows us to measure their perceptions of the DSL properties and user experience. The participants praised DAMI-DSL for its readability and ease of use. The findings indicate that our framework has positive impact in data migration efforts compared to SQL scripts, by reducing the lines of code and characters required for the migration by 18.3% and 35.6%, respectively.

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.

Background: The rise of Large Language Models (LLMs) in software development has opened new possibilities for code generation. Despite the widespread use of this technology, it remains unclear how well LLMs generate code solutions in terms of software quality and how they compare to humanwritten code. Aims: This study compares the internal quality attributes of LLM-generated and human-written code. Method: Our empirical study integrates datasets of coding tasks, three LLM configurations (zero-shot, few-shot, and fine-tuning), and SonarQube to assess software quality. The dataset comprises Python code solutions across three difficulty levels: introductory, interview, and competition. We analyzed key code quality metrics, including maintainability and reliability, and the estimated effort required to resolve code issues. Results: Our analysis shows that LLM-generated code has fewer bugs and requires less effort to fix them overall. Interestingly, fine-tuned models reduced the prevalence of high-severity issues, such as blocker and critical bugs, and shifted them to lower-severity categories, but decreased the model's performance. In competition-level problems, the LLM solutions sometimes introduce structural issues that are not present in human-written code. Conclusion: Our findings provide valuable insights into the quality of LLM-generated code; however, the introduction of critical issues in more complex scenarios highlights the need for a systematic evaluation and validation of LLM solutions. Our work deepens the understanding of the strengths and limitations of LLMs for code generation.

Commit messages are valuable resources for describing why code changes are committed to repositories in version control systems (e.g., Git).They effectively help developers understand code changes and better perform software maintenance tasks.Unfortunately, developers often neglect to write high-quality commit messages in practice.Therefore, a growing body of work is proposed to generate commit messages automatically.These works all demonstrated that how to organize and represent code changes is vital in generating good commit messages, including the use of fine-grained graphs or embeddings to better represent code changes.In this study, we choose an alternative way to condense code changes before generation, i.e., proposing brief yet concise text templates consisting of the following three parts: (1) summarized code changes, (2) elicited comments, and (3) emphasized code identifiers.Specifically, we first condense code changes by using our proposed templates with the help of a heuristic-based tool named ChangeScribe, and then fine-tune CodeLlama-7B on the pairs of our proposed templates and corresponding commit messages.Our proposed templates better utilize pre-trained language models, while being naturally brief and readable to complement generated commit messages for developers.

Just-in-time defect prediction (JIT-DP) aims to predict the likelihood of code changes resulting in software defects at an early stage. Although code change metrics and semantic features have enhanced prediction accuracy, prior research has largely ignored code refactoring during both the evaluation and methodology phases, despite its prevalence. Refactoring and its propagation often tangle with bug-fixing and bug-inducing changes within the same commit and statement. Neglecting refactoring can introduce bias into the learning and evaluation of JIT-DP models. To address this gap, we investigate the impact of refactoring and its propagation on six state-of-the-art JIT-DP approaches. We propose Code chAnge Tactics (CAT) analysis to categorize code refactoring and its propagation, which improves labeling accuracy in the JIT-Defects4J dataset by $\mathbf{1 3. 7}$. Our experiments reveal that failing to consider refactoring information in the dataset can diminish the performance of models, particularly semantic-based models, by $\mathbf{1 8. 6}$ % and $\mathbf{3 7. 3} \%$ in F1-score. Additionally, we propose integrating refactoring information to enhance six baseline approaches, resulting in overall improvements in recall and $\mathbf{F 1}$-score, with increases of up to $43.2 \%$ and $32.5 \%$, respectively. Our research underscores the importance of incorporating refactoring information in the methodology and evaluation of JIT-DP. Furthermore, our CAT has broad applicability in analyzing refactoring and its propagation for software maintenance.

Continuous Integration (CI) is a widely adopted practice in software development to automatically verify code changes across diverse environments. However, executing the full test suite on every pull request update can lead to redundant runs, slower feedback loops, and inefficient utilization of CI resources. To address this issue, we introduce PrioTestCI, a prioritization technique within GitHub Actions that focuses on re-executing test cases that have previously failed. If these prioritized tests succeed, the remaining tests proceed; otherwise, the workflow terminates early, saving computation resources and providing early feedback to developers. PrioTestCI utilizes commit-to-commit test result tracking to inform future test runs, thereby reducing unnecessary repetition and accelerating validation cycles. We evaluated our technique on the Pytest project, a real-world open-source project with an extensive test matrix. PrioTestCI resulted in a CI runtime reduction of 1h57m39s compared to the normal workflow, with individual configuration improvements ranging from 63.75% to 91.94% (81.55% on average). Demo video: https://youtu.be/_3CF9LJdv0I?si=XyE_8mBnDxk1lMnD Repository: https://github.com/ShubhamDesai/CI-Optimization

One of the most important artifacts of Model-Driven Engineering (MDE) are metamodels. Like other software artifacts, they are expected to evolve. Consequently, their models thus become invalid and need to be fixed. The usual strategy is to adapt those models based on changes made to the metamodel, i.e., co-evolution. Co-evolution, however, depends on correctly recorded changes since even small deviations can impact the models that will be evolved. One problem is that those changes are usually not preserved or complete. The reason is that the most common way to record the history of metamodels is by using text-based version control systems, i.e., Git. This, however, hinders the detection of the concrete changes made to the metamodel, which are used for co-evolution. This aspect leads to problems in maintaining and evolving metamodels and their models in practice. In this paper, we propose a novel approach that allows engineers to reconstruct the history of metamodels with the help of ChangeTrees. These ChangeTrees recommend possible sequences of changes between two metamodel versions, i.e., evolved metamodels. We conducted an empirical study that detected changes to eight different metamodels across varying domains. The results show that our approach can correctly reconstruct the metamodel's history by detecting all possible changes between the two versions. Furthermore, performance results show that, in the worst case, our approach required 15.65 seconds to detect and generate a ChangeTree of a metamodel with more than 351 changes applied to it (between two versions), leading to 11,268 branching change paths (alternative sequences of changes).

Metamodel matching plays a crucial role in defining transformation rules in model-driven engineering by identifying correspondences between different metamodels, forming the foundation for effective transformations. Current techniques face significant challenges due to syntactical and structural heterogeneity. To address this, matching techniques often employ semantic similarity to identify correspondences. Traditional semantic matchers, however, rely on ontology matching tools or lexical databases, which often struggle when metamodels use different terminologies or hierarchical structures. Inspired by the contextual understanding capabilities of Large Language Models (LLMs), this paper explores the capability of GPT-4 potentials as a semantic matcher and alternative to existing methods for metamodel matching. However, metamodels can be large, which can overwhelm LLMs if provided in a single prompt, leading to reduced accuracy. Therefore, we propose prompting LLMs with fragments of the source and target metamodels, identifying correspondences through an iterative process. The fragments to be provided in the prompt are identified based on an initial mapping derived from their elements’ definitions. Through experiments with 10 metamodels, our results show that our LLMbased approach improves the accuracy of metamodel matching, achieving an average F-measure of $\approx 91 \%$, outperforming both the baseline and hybrid approaches, which have a maximum average F-measure of $\approx \mathbf{2 9 \%}$ and $\approx \mathbf{7 4 \%}$, respectively. Moreover, our approach surpasses single-prompt LLM-based matching, which has an average $\mathbf{F}$-measure of $\mathbf{8 0 \%}$, by approximately $\mathbf{1 1 \%}$.

Digital processes driven by data are the basis for industry operations nowadays. Despite relying on software for such processes, the industry faces significant challenges due to legacy systems. Legacy systems are pieces of software that, despite being vital for industry operations, have limitations in terms of performance and scalability needs. Thus, to ensuring that these systems can still continue to deliver business value, there is a need for re-engineering such legacy system. This is a situation faced by Volvo Group, with their system called SCORE, initially implemented in 2017, and used by HR teams and managers to manage team structures, employee data, and operational workflows. The SCORE system faces challenges related to performance issues, database inefficiencies, outdated user interface, lack of flexibility, and lack of modern software engineering practices. As a strategy to keep the business value of SCORE, Volvo has started using Large Language Models (LLMs) to speed up it re-engineering. This paper presents the experiences of using LLMs at Volvo Group. More specifically, we describe how GPT-4 and Claude AI were applied, with three learning strategies (i.e. zero shot, one shot, and few shot), to address the challenges of the legacy system. The prompts and examples of the responses given by the Foundations Models are presented and discussed. By adopting the insights provided by LLMs, we were able to reduce API response times from 20–30 seconds to 3 seconds, improve UI usability by restructuring elements for easier navigation, and enhance scalability with better database queries and code modularization. The CI/CD pipeline was also streamlined, enabling faster and more reliable deployments. As an additional contribution, we report six lessons learned, allowing other industries and researchers to comprehend the strategic value of integrating LLMs into legacy system modernization.

Web APIs are essential in modern software systems, with OpenAPI as the standard specification for describing RESTful APIs. Despite widespread adoption, OpenAPI specifications are mainly textual documents that become verbose, deeply nested, and difficult to navigate at scale. Current tools like Swagger Editor lack graphical design capabilities, impeding effective prototyping for large teams and non-technical users. To address this gap, we present APICAnvas, a visual design tool enabling users to interact with OpenAPI specifications through both editable YAML and graphical interfaces with bidirectional synchronization. We evaluated the tool with 13 participants across two tasks: creating new APIs and modifying existing ones. Results show 83% successfully created APIs from scratch and 75% correctly updated existing APIs, demonstrating the tool’s effectiveness across diverse experience levels.

practice to create software-intensive systems in several domains (e.g., aerospace, automotive, and robotics). However, when multiple engineers work concurrently, keeping all model artifacts synchronized and consistent is difficult. This is even harder when the engineering process relies on a myriad of tools and domains (e.g., mechanic, electronic, and software). Existing work tries to solve this issue from different perspectives, such as using trace links between different artifacts or computing change propagation paths. However, these solutions mainly provide additional information to engineers, still requiring manual work for propagating changes. Yet, most modeling tools are limited regarding the traceability between different domains, while also lacking the efficiency and granularity required during the development of software-intensive systems. Motivated by these limitations, in this work, we present a solution based on what we call "reactive links", which are highly granular trace links that propagate change between property values across models in different domains, managed in different tools. Differently from traditional "passive links", reactive links automatically propagate changes when engineers modify models, assuring the synchronization and consistency of the artifacts. The feasibility, performance, and flexibility of our solution were evaluated in three practical scenarios, from two partner organizations. Our solution is able to resolve all cases in which change propagation among models were required. We observed a great improvement of efficiency when compared to the same propagation if done manually. The contribution of this work is to enhance the engineering of software-intensive systems by reducing the burden of manually keeping models synchronized and avoiding inconsistencies that potentially can originate from collaborative engineering in a variety of tool from different domains.

Software modernization is a common activity in software engineering, since technologies advance, requirements change, and business models evolve. Differently from conventional software evolution (e.g., adding new features, enhancing performance, or adapting to new requirements), software modernization involves re-engineering entire legacy systems (e.g., changing the technology stack, migrating to a new architecture style, or programming paradigms). Given the pervasive nature of software today, modernizing legacy systems is paramount to provide customers with competitive and innovative products and services, while keeping companies profitable. Despite the prevalent discussion of software modernization in gray literature, and the many papers in the literature, there is no work presenting a “big picture” of contemporary software modernization, describing challenges, and providing a well-defined research agenda. The goal of this work is to describe the state of the art in software modernization in the past 10 years. We collect the state of the art by performing a rapid review (searching five digital libraries), identifying potential 3,460 studies, leading to a final set of 126. We analyzed these studies to understand which strategies are employed, the driving forces that lead organizations to modernize their systems, and the challenges that need to be addressed. The results show that studies in the last 10 years have explored eight strategies for modernizing legacy systems, namely cloudification, architecture redesign, moving to a new programming language, targeting reuse optimization, software modernization for new hardware integration, practices to leverage automation, database modernization, and digital transformation. Modernization is triggered by 14 driving forces, with the most common ones being reducing operational costs, improving performance and scalability, and reducing complexity. In addition, based on the analysis of existing literature, we present a detailed discussion of research opportunities in this field. The main challenges are providing tooling support, followed by defining a modernization process and considering better evaluation metrics. The main contribution of our work is to equip practitioners and researchers with knowledge of the current state of contemporary software modernization so that they are aware of practices and challenges to be addressed when deciding to modernize legacy systems.

With AI increasingly affecting software systems, there is a pressing need to prepare the next generation of software engineers to build AI-intensive systems proficiently. This work outlines our instructional approach in the “Engineering of AI-intensive Systems” course for postgraduate computer science students to bridge the knowledge gap between software engi-neering (SE) and artificial intelligence (AI) disciplines. Our paper elaborates on the course's framework, pedagogical strategies, and evaluation methods, emphasizing the benefits of this interdisci-plinary educational model.

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.

Traceability allows stakeholders to extract and comprehend the trace links among software artifacts introduced across the software life cycle, to provide significant support for software engineering tasks. Despite its proven benefits, software traceability is challenging to recover and maintain manually. Hence, plenty of approaches for automated traceability have been proposed. Most rely on textual similarities among software artifacts, such as those based on Information Retrieval (IR). However, artifacts in different abstraction levels usually have different textual descriptions, which can greatly hinder the performance of IR-based approaches (e.g., a requirement in natural language may have a small textual similarity to a Java class). In this work, we leverage the consensual biterms and transitive relationships (i.e., inner- and outer-transitive links) based on intermediate artifacts to improve IR-based traceability recovery. We first extract and filter biterms from all source, intermediate, and target artifacts. We then use the consensual biterms from the intermediate artifacts to enrich the texts of both source and target artifacts, and finally deduce outer and inner-transitive links to adjust text similarities between source and target artifacts. We conducted a comprehensive empirical evaluation based on five systems widely used in other literature to show that our approach can outperform four state-of-the-art approaches in Average Precision over 15% and Mean Average Precision over 10% on average.

Metamodels like many other software artifacts, are expected to evolve and exist in different versions. Consequently, the instances of these metamodels (models), become invalid and need fixing. The usual strategy for this is adapting models based on changes made to the metamodels, i.e., co-evolution. However, co-evolution usually adopts an all-or-nothing strategy that overlooks three important aspects: (a) preserving the history of the metamodel, (b) preserving the model's history before the co-evolution, and (c) supporting models to co-exist for different metamodel versions and delay their co-evolution. These aspects lead to problems for maintaining models in practice since often co-evolution gets driven by customer needs, e.g., the customer decides when to update. In this paper, we propose a novel approach that allows the creation of a metamodel version and records the history of metamodels and models by adopting an operation-based infrastructure. These metamodel versions allow engineers to delay the co-evolution of certain models by having co-existing metamodel versions. This notion of co-existence, in addition to the operation-based infrastructure, helps to preserve the complete history of metamodel and models, i.e., the history before and after co-evolving a model. To evaluate our approach, we conducted an empirical study, where we co-evolved models of varying domains. The results show that our approach correctly records the history of the metamodel and model. Furthermore, we measured the performance during co-evolution while having all versions co-existing in the same space. It shows that in the worst case, our approach required 887.91 seconds to co-evolve a model with more than 88,000 elements and 2,000,000 properties.

The adoption of microservice architecture has seen a considerable upswing in recent years, mainly driven by the need to modernize legacy systems and address their limitations. Legacy systems, typically designed as monolithic applications, often struggle with maintenance, scalability, and deployment in-efficiencies. This study investigates the motivations, activities, and challenges associated with migrating from monolithic legacy systems to microservices, aiming to shed light on common practices and challenges from a practitioner's point of view. We conducted a comprehensive study with 53 software practitioners who use mi-croservices, expanding upon previous research by incorporating diverse international perspectives. Our mixed-methods approach includes quantitative and qualitative analyses, focusing on four main aspects: (i) the driving forces behind migration, (ii) the ac-tivities to conduct the migration, (iii) strategies for managing data consistency, and (iv) the prevalent challenges. Thus, our results reveal diverse practices and challenges practitioners face when migrating to microservices. Companies are interested in technical benefits, enhancing maintenance, scalability, and deployment processes. Testing in microservice environments remains complex, and extensive monitoring is crucial to managing the dynamic nature of microservices. Database management remains challenging. While most participants prefer decentralized databases for autonomy and scalability, challenges persist in ensuring data consistency. Additionally, many companies leverage modern cloud technologies to mitigate network overhead, showcasing the importance of cloud infrastructure in facilitating efficient microservice communication.

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.

Consistency maintenance is paramount for software engineering, as it improves/guarantees the quality of artifacts (e.g., models) during maintenance and evolution. To perform this maintenance, consistency rules (CR) are commonly defined and applied to evaluate model elements according to desired properties. By empirical studies, it is known that CRs commonly evaluate similar model elements (e.g., multiple CRs checking the consistency of a UML class). Thus, we hypothesize that CRs can be used as a means to identify dependencies among inconsis-tencies and support consistency maintenance tasks. Currently, however, no study investigates to what extent dependencies can be identified and how they can be used to repair inconsistencies. In this paper, we explore dependencies between CRs to identify and group dependent inconsistencies. For that, we define a metamodel that allows dependencies to be expressed. Further-more, we propose a consistency maintenance and dependency analysis mechanism that uses such a metamodel. Additionally, the approach generates repairs for the inconsistencies, considering the groups of dependencies to identify overlapping and conflicting repairs. To evaluate the approach, we conducted an empirical study with 48 UML models and 27 CRs. The results show that our approach identifies dependencies between inconsistencies (46 % of the inconsistencies have dependencies), within a reasonable time, 10ms on average in the worst case. Results also show that dependent inconsistencies can be grouped and used together to identify repairs that are either overlapping (26 % on average) or conflicting (58 % on average).

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.

Repairing design models is a laborious task that requires a considerable amount of time and effort from developers. Repair recommendation (RR) approaches focus on reducing the effort and improving the quality of the repairs performed. Such approaches have been evaluated in terms of scalability, correctness, and minimalism. These evaluations, however, have not investigated how developers can benefit from using RRs and how they perceive the difficulty of applying RRs. Investigating and discussing the use of RRs from the developers’ perspective is important to demonstrate the benefits of applying such approaches in practice. We explore this opportunity by conducting a controlled experiment carried out with 24 developers where they repaired UML design models in eight different tasks, with and without RRs. The findings indicate that developers can benefit from RRs in complex tasks by improving their effectiveness and efficiency. The results also evidence that the use of RRs does not impact the developers’ perceived difficulty and confidence when repairing models. Furthermore, our findings show that not all developers choose the same RR, but rather, have varied preferences. Thus, the provision of RRs leads to developers considering additional alternatives to repair an inconsistency.

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.

A large number of bug reports are created during the evolution of a software system. Locating the source code files that need to be changed in order to fix these bugs is a challenging task. Information retrieval-based bug localization techniques do so by correlating bug reports with historical information about the source code (e.g., previously resolved bug reports, commit logs). These techniques have shown to be efficient and easy to use. However, one flaw that is nearly omnipresent in all these techniques is that they ignore code refactorings. Code refactorings are common during software system evolution, but from the perspective of typical version control systems, they break the code history. For example, a class when renamed then appears as two separate classes with separate histories. Obviously, this is a problem that affects any technique that leverages code history. This paper proposes a refactoring-aware traceability model to keep track of the code evolution history. With this model, we reconstruct the code history by analyzing the impact of code refactorings to correctly stitch together what would otherwise be a fragmented history. To demonstrate that a refactoring aware history is indeed beneficial, we investigated three widely adopted bug localization techniques that make use of code history, which are important components in existing approaches. Our evaluation on 11 open source projects shows that taking code refactorings into account significantly improves the results of these bug localization techniques without significant changes to the techniques themselves. The more refactorings are used in a project, the stronger the benefit we observed. Based on our findings, we believe that much of the state of the art leveraging code history should benefit from our work.

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.

Bug localization is the task of recommending source code locations (typically files) that probably contain the cause of a bug and hence need to be changed to fix the bug. Along these lines, information retrieval-based bug localization (IRBL) approaches have been adopted, which identify the most bug-prone files from the source code space. In current practice, a series of state-of-the-art IRBL techniques leverage the combination of different components, e.g., similar reports, version history, code structure, to achieve better performance. ABLoTS is a recently proposed approach with the core component, TraceScore, that utilizes requirements and traceability information between different issue reports, i.e., feature requests and bug reports, to identify buggy source code snippets with promising results. To evaluate the accuracy of these results and obtain additional insights into the practical applicability of ABLoTS, supporting of future more efficient and rapid replication and comparison, we conducted a replication study of this approach with the original data set and also on an extended data set. The extended data set includes 16 more projects comprising 25,893 bug reports and corresponding source code commits. While we find that the TraceScore component as the core of ABLoTS produces comparable results with the extended data set, we also find that the ABLoTS approach no longer achieves promising results, due to an overlooked side effect of incorrectly choosing a cut-off date that led to training data leaking into test data with significant effects on performance.

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.

Along the process of engineering a safety-critical system, software engineers produce various artifacts, ranging from requirements and change requests to source code and test cases. In order to aid the development of the system and to adhere to the complex safety regulations and standards in place, engineers are often required to maintain bidirectional and consistent traceability between the produced artifacts. However, such artifacts are rarely maintained in one single tool. Because of that, the cross-tool bidirectional traces have to frequently be manually maintained, which can easily become a very time-consuming or infeasible task. Through interviews and observations at our industry partners in regulated domains, we observed that a number of different strategies are used to deal with this challenge. The use of naming conventions, querying, or URL links is observed in the industry. However, they have their shortcomings and hinder engineers from realizing the full potential that traceability can offer. Knowing the challenges in the industry, we explored existing literature. A range of approaches in the literature aims at dealing with traceability, but often they are context-specific and not easily transferable into practice. Given this gap between the state-of-the-art and industry needs, we performed interviews with our industry partners and analyzed tertiary studies from the literature to obtain a better understanding of what traceability properties are needed to unleash the potential of traces. We identified properties that represent the shared challenges between the related work and the industry requirements: discoverability, type checks, flexibility, navigability, and extensibility. While each property is addressed by a subset of the available solutions, we propose a novel traceability approach to support all of them in a single tool.

Preprocessor-based software product lines (SPLs) are used to deal with evolution in space, in which features (so-called configuration options)—annotated in source code with #ifdefs—are included, removed, and systematically reused. Inevitably, feature implementations also evolve over time, i.e., when existing features are revised. Nowadays, Version control systems (VCSs) are well-integrated into SPL development processes for versioning support of releases. Changes to existing features in one version, a.k.a. release of an SPL, usually developed in a branch, frequently need to be propagated to other active releases. However, there is no automated support for analyzing and propagating features in SPL releases. For instance, VCSs can only propagate changes at the commit level, but miss support at the feature level, i.e., the building blocks of SPLs. Manually analyzing and propagating a version of a feature, i.e., a feature revision, through #ifdefs is risky, time-consuming, and error-prone because a feature can be interacting with multiple features and it can be spread in multiple blocks of code across different files. We thus present a novel and tool-supported approach for the analysis and propagation of feature revisions. We evaluated our approach quantitatively by computing its correct behavior and runtime. Our approach analyzes and propagates a feature implementation in ≈63 seconds, with, on average, precision and recall of 99%. In total, we propagated 3,134 features in space and time between 200 pairs of releases on four real-world preprocessor-based SPLs. In addition, we qualitatively evaluated the usefulness of our tool support by conducting interviews with five experienced core developers of three popular preprocessor-based SPLs. The qualitative results confirm that our tool support is useful to speed up the analysis and propagation of feature revisions.

Microservice architectures are an emergent service-oriented paradigm widely used in industry to develop and deploy scalable software systems. The underlying idea is to design highly independent services that implement small units of functionality and can interact with each other through lightweight interfaces. Even though microservices are often used with success, their design and maintenance pose novel challenges to software engineers. In particular, it is questionable whether the intended independence of microservices can actually be achieved in practice. So, it is important to understand how and why microservices evolve during a system’s life-cycle, for instance, to scope refactorings and improvements of a system’s architecture or to develop supporting tools. To provide insights into how microservices evolve, we report a large-scale empirical study on the (co-)evolution of microservices in 11 open-source systems, involving quantitative and qualitative analyses of 7,319 commits. Our quantitative results show that there are recurring patterns of (co-)evolution across all systems, for instance, “shotgun surgery” commits and microservices that are largely independent, evolve in tuples, or are evolved in almost all changes. We refine our results by analyzing service-evolving commits qualitatively to explore the (in-)dependence of microservices and the causes for their specific evolution. The contributions in this article provide an understanding for practitioners and researchers on how microservices evolve in what way, and how microservice-based systems may be improved.

In large code bases, locating the elements that implement concrete features of a system is challenging. This information is paramount for maintenance and evolution tasks, although not always explicitly available. In this work, motivated by the needs of locating features as a first step for feature-based Software Product Line adoption, we propose a solution for improving the performance of existing approaches. For this, relying on an automatic feature localization approach to locate features in single-systems, we propose approaches to deal with feature localization in the context of families of systems, e.g., variants created through opportunistic reuse such as clone-and-own. Our feature localization approaches are built on top of Spectrum-based feature localization (SBFL) techniques, supporting both dynamic feature localization (i.e., using execution traces as input) and static feature localization (i.e., relying on the structural decomposition of the variants’ implementation). Concretely, we provide (i) a characterization of different settings for dynamic SBFL in single systems, (ii) an approach to improve accuracy of dynamic SBFL for families of systems, and (iii) an approach to use SBFL as a static feature localization technique for families of systems. The proposed approaches are evaluated using the consolidated ArgoUML SPL feature localization benchmark. The results suggest that some settings of SBFL favor precision such as using the ranking metrics Wong2, Ochiai2, or Tarantula with high threshold values, while most of the ranking metrics with low thresholds favor recall. The approach to use information from variants increase the precision of dynamic SBFL while maintaining recall even with few number of variants, namely two or three. Finally, the static SBFL approach performs equally in terms of accuracy to other state-of-the-art approaches, such as Formal Concept Analysis and Interdependent Elements.

There are many repair alternatives for resolving model inconsistencies, each involving one or more model changes. Enumerating them all could overwhelm the developer because the number of possible repairs can grow exponentially. To address this problem, this paper focuses on the immediate cause of an inconsistency. By focusing on the cause, we can generate a repair tree with a subset of repair actions focusing on fixing this cause. This strategy identifies model elements that must be repaired, as opposed to additional model elements that may or may not have to be repaired later. Furthermore, our approach can provide an ownership-based filter for filtering repairs that modify model elements not owned by a developer. This filtering can further reduce the repair possibilities, aiding the developer when choosing repairs to be performed. We evaluated our approach on 24 UML models and four Java systems, using 17 UML consistency rules and 14 Java consistency rules. The evaluation data contained 39,683 inconsistencies, showing our approach's usability as the repair trees sizes ranged from five to nine on average per model. Also, these repair trees were generated in 0.3 seconds on average, showing our approach's scalability. Based on the results, we discuss the correctness and minimalism with regard to the cause of the inconsistency. Lastly, we evaluated the filtering mechanism, showing that it is possible to further reduce the number of repairs generated by focusing on ownership.

Effectively using software languages, be it programming or domain-specific languages, requires effective editing support. Modern IDEs, modeling tools, and code editors typically provide sophisticated support to create, comprehend, or modify instances---programs or models---of particular languages. Unfortunately, building such editing support is challenging. While the engineering of languages is well understood and supported by modern model-driven techniques, there is a lack of engineering principles and best practices for realizing their editing support. Especially domain-specific languages---often created by smaller organizations or individual developers, sometimes even for single projects---would benefit from better methods and tools to create proper editing support.

As the engineering world moves towards collaborative model-driven development, it is becoming increasingly difficult to keep all model artifacts synchronized and consistent across a myriad of tools and domains. The existing literature proposes a variety of solutions, from passive trace links to computing change propagation paths. However, these solutions require manual propagation and the use of a limited set of tools, while also lacking the efficiency and granularity required during the development of complex systems. To overcome these limitations, this paper proposes a solution based on reactive propagation links between property values across multi-domain models managed in different tools. As opposed to the traditional passive links, the propagation links automatically react to changes during engineering to assure the synchronization and consistency of the models. The feasibility and performance of our solution were evaluated in two practical scenarios. We identified a set of change propagation cases, all of which could be resolved using our solution, while also rendering a great improvement in terms of efficiency as compared to manual propagation. The contribution of our solution to the state of the practice is to enhance the engineering process by reducing the burden of manually keeping models synchronized, eliminating inconsistencies that can be originated in artifacts managed in a variety of tool from different domains.

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.

Abstract Software companies commonly develop and maintain variants of systems, with different feature combinations for different customers. Thus, they must cope with variability in space. Software companies further must cope with variability in time, when updating system variants by revising existing software features. Inevitably, variants evolve orthogonally along these two dimensions, resulting in challenges for software maintenance. Our work addresses this challenge with ECSEST (Extraction and Composition for Systems Evolving in Space and Time), an approach for locating feature revisions and composing variants with different feature revisions. We evaluated ECSEST using feature revisions and variants from six highly configurable open source systems. To assess the correctness of our approach, we compared the artifacts of input variants with the artifacts from the corresponding composed variants based on the implementation of the extracted features. The extracted traces allowed composing variants with 99-100% precision, as well as with 97-99% average recall. Regarding the composition of variants with new configurations, our approach can combine different feature revisions with 99% precision and recall on average. Additionally, our approach retrieves hints when composing new configurations, which are useful to find artifacts that may have to be added or removed for completing a product. The hints help to understand possible feature interactions or dependencies. The average time to locate feature revisions ranged from 25 to 250 seconds, whereas the average time for composing a variant was 18 seconds. Therefore, our experiments demonstrate that ECSEST is feasible and effective.

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

Legacy systems are long-lived applications, with obsolete technology and degraded architecture. These systems hamper digital transformation and innovation, and require a great amount of resources for maintenance. The modernization of monolithic legacy systems is a strategy to promote better evolution and maintenance, taking advantage of new technologies such as microservices. Microservice architectural style is a paradigm to develop systems as a suite of small and autonomous services, communicating through a lightweight protocol. However, the migration of legacy systems to microservices is complex. Although we can find several studies on this topic, they usually focus on specific activities, e.g., the identification of the microservice boundaries in the legacy code. Also, existing pieces of work do not cover real-world scenarios, since they do not take into account organizational, operational, and technical aspects. To overcome this limitation, in this paper we present a roadmap for modernizing monolithic legacy systems with microservices. The roadmap is distilled from the existing body of knowledge, describing common activities and input/output information. The proposed roadmap is composed of eight activities, grouped in four phases, namely initiation, planning, execution, and monitoring. The main contributions are: (i) serve as a basis for practitioners to plan, execute, and monitor the modernization process; (ii) be a reference for researchers to design new studies; and (iii) motivate tool builders to deal with existing needs.

Feature annotation based on preprocessor directives is the most common mechanism in Highly-Configurable Software Systems (HCSSs) to manage variability. However, it is challenging to understand, maintain, and evolve feature fragments guarded by #ifdef directives. Yet, despite HCSSs being implemented in Version Control Systems, the support for evolving features in space and time is still limited. To extend the knowledge on this topic, we analyze the feature life cycle in space and time. Specifically, we introduce an automated mining approach and apply it to four HCSSs, analyzing commits of their entire development life cycle (13 to 20 years and 37,500 commits). This goes beyond existing studies, which investigated only differences between specific releases or entire systems. Our results show that features undergo frequent changes, often with substantial modifications of their code. The findings of our empirical analyses stress the need for better support of system evolution in space and time at the level of features. In addition to these analyses, we contribute an automated mining approach for the analysis of system evolution at the level of features. Furthermore, we also make available our dataset to foster new studies on feature evolution in HCSSs.

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.

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 Product Line Architecture (PLA) is one of the most important artifacts of a Software Product Line. PLA designing has been formulated as a multi-objective optimization problem and successfully solved by a state-of-the-art search-based approach. However, the majority of empirical studies optimize PLA designs without applying one of the fundamental genetic operators: the crossover. An operator for PLA design, named Feature-driven Crossover, was proposed in a previous study. In spite of the promising results, this operator occasionally generated incomplete solutions. To overcome these limitations, this paper aims to enhance the search-based PLA design optimization by improving the Feature-driven Crossover and introducing a novel crossover operator specific for PLA design. The proposed operators were evaluated in two well-studied PLA designs, using three experimental configurations of NSGA-II in comparison with a baseline that uses only mutation operators. Empirical results show the usefulness and efficiency of the presented operators on reaching consistent solutions. We also observed that the two operators complement each other, leading to PLA design solutions with better feature modularization than the baseline experiment.

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 Product Lines Engineering (SPLE) is a software development approach intended for the development and maintenance of variable systems, i.e. systems that exist in many different variants. In the long run SPLE has many advantages. However, it requires a large upfront investment of time and money, which is why in practice Software Product Lines (SPLs) are rarely developed from scratch. Instead, they are often built using an extractive approach by which a set of existing system variants is consolidated (i.e. reverse engineered) into an SPL. A crucial part of this process is the construction of a variability model like a Feature Model (FM) that describes the common and variable parts of the system variants. In this paper we apply an approach for reverse engineering feature models based on a multi-objective optimization algorithm to the given challenge of constructing a feature model for a set of game variants and we present the results.

To effectively cope with increasing customization demands, companies that have developed variants of software systems are faced with the challenge of consolidating all the variants into a Software Product Line, a proven development paradigm capable of handling such demands. A crucial step in this challenge is to reverse engineer feature models that capture all the required feature combinations of each system variant. Current research has explored this task using propositional logic, natural language, and search-based techniques. However, using knowledge from the implementation artifacts for the reverse engineering task has not been studied. We propose a multi-objective approach that not only uses standard precision and recall metrics for the combinations of features but that also considers variability-safety, i.e. the property that, based on structural dependencies among elements of implementation artifacts, asserts whether all feature combinations of a feature model are in fact well-formed software systems. We evaluate our approach with five case studies and highlight its benefits for the software engineer.

Software Product Lines (SPLs) are families of related software systems developed for specific market segments or domains. Commonly, SPLs emerge from sets of existing variants when their individual maintenance becomes infeasible. However, current approaches for SPL migration do not support design models, are partially automated, or do not reflect constraints from SPL domains. To tackle these limitations, the goal of this doctoral research plan is to propose an automated approach to the SPL migration process at the design level. This approach consists of three phases: detection, analysis and transformation. It uses as input the class diagrams and lists of features for each system variant, and relies on search-based algorithms to create a product line architecture that best captures the variability present in the variants. Our expected contribution is to support the adoption of SPL practices in companies that face the scenario of migrating variants to SPLs.

During the inter-class test, a common problem, named Class Integration and Test Order (CITO) problem, involves the determination of a test class order that minimizes stub creation effort, and consequently test costs. The approach based on Multi-Objective Evolutionary Algorithms (MOEAs) has achieved promising results because it allows the use of different factors and measures that can affect the stubbing process. Many times these factors are in conflict and usually there is no a single solution for the problem. Existing works on MOEAs present some limitations. The approach was evaluated with only two coupling measures, based on the number of attributes and methods of the stubs to be created. Other MOEAs can be explored and also other coupling measures. Considering this fact, this paper investigates the performance of two evolutionary algorithms: NSGA-II and SPEA2, for the CITO problem with four coupling measures (objectives) related to: attributes, methods, number of distinct return types and distinct parameter types. An experimental study was performed with four real systems developed in Java. The obtained results point out that the MOEAs can be efficiently used to solve this problem with several objectives, achieving solutions with balanced compromise between the measures, and of minimal effort to test.