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.

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).

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.

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.

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).

Software engineering organizations in safety-critical domains require rigorous processes that include explicit software quality assurance measures (QA) to achieve high-quality and safe engineering artifacts. One major challenge for engineers is adhering to the correct process that is applicable in their specific working context, to understand which steps are ready to start, what actions are missing to complete their step, and when rework has happened. In this paper, we propose and evaluate ProGuide, a framework that provides actionable, light-weight process guidance by continuously assessing pre-conditions, post-conditions, and QA constraints. In case of a violation, it provides concrete repair actions. Evaluation on a safety-critical open source system and engineers from our industry partner Bosch showed that repairs are complete and small in number, and resulted in less frustration and fewer mistakes compared to being provided with no process guidance. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

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.

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.

Abstract Engineering projects involve a variety of artifacts such as requirements, design, or source code. These artifacts, many of which tend to be interdependent, are often manipulated concurrently. To keep artifacts consistent, engineers must continuously consider their work in relation to the work of multiple other engineers. Traditional consistency checking approaches reason efficiently over artifact changes and their consistency implications. However, they do so solely within the boundaries of specific tools and their specific artifacts (e.g., consistency checking between different UML models). This makes it difficult to examine the consistency between different types of artifacts (e.g., consistency checking between UML models and the source code). Global consistency checking can help addressing this problem. However, it usually requires a disruptive and time-consuming merging process for artifacts. This article presents a novel, cloud-based approach to global consistency checking in a multi-developer/-tool engineering environment. It allows for global consistency checking across all artifacts that engineers work on concurrently. Moreover, it reasons over artifact changes immediately after the change happened, while keeping the (memory/CPU) cost of consistency checking minimal. The feasibility and scalability of our approach were demonstrated by a prototype implementation and through an empirical validation.

Background: Systematic Reviews (SR) are crucial for collecting evidence related with a particular field or area. Hence, there are different protocols for conducting SR in software engineering. There is also several tools designed to provide support for these protocols. Aims: We understand that there is still a lack of a web-tool, fully integrating the features considered important for SR. Implementing such a tool would be a great contribution to the field. Method: We analyzed several studies discussing features for tools supporting SR. We defined design decisions based on these features. Results: We created Thoth, a web-based tool for SR. In this study we present a first version, containing a set of features. Before moving forward with the implementation, we conducted a quasi-experiment for evaluating and comparing Thoth with a similar tool. Conclusion: Despite being in the right direction for achieving our goal, the results of the quasi-experiment provided us with important evidence for improving Thoth.

Summary Software product lines (SPLs) are a well‐known solution to systematically create reusable software products. Among the approaches to create an SPL, the extractive approach is usually used when the organization already has a set of similar systems. These systems are analyzed to extract, categorize, and group their common and variant features throughout the SPL reengineering process. As there are different scenario variables, such as available artifacts and team experience, the activities and techniques used to perform these tasks may change. This may increase the effort and decrease the quality of retrieved features when users with low experience in SPL reengineering perform such tasks. However, there is a lack of a process supporting these tasks considering different scenarios. Therefore, we specify the Prepare, Assemble, and Execute Process for SPL Reengineering (PAxSPL), a process that provides support to prepare, assemble, and execute feature retrieval throughout the analysis of documentation and team experience. To initially evaluate PAxSPL, we conducted and reported an exploratory case study in a real development environment. The results indicated that our proposal helps in the assembly of a feature retrieval process according to user needs. Results were important to identify points for improvement in PAxSPL. We also could use the information gathered to improve the guidelines and provide this information to be used as basis of comparison for future users.