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.

Model-Based Systems Engineering (MBSE) has emerged with great potential to fulfill the non-linearly rising demand in interdisciplinary engineering, e.g., product development. However, the variety and complexity of MBSE tools pose difficulties in particular industrial applications. This paper tries to serve as a guideline to find the ideal tool for a specific industrial application as well as to highlight the key criteria that an industry might consider. For this purpose, we propose a logical framework for MBSE tool selection, which is based on market research, the approaches of Quality Function Deployment (QFD), and decision matrix. As customers are at the center of any product, accordingly the needs of MBSE tool users are addressed within this research as the fundamental starting point. Market research and extensive discussions with MBSE tool vendors and academia show the current situation of MBSE tools. To compare the performance of the considered tools, a set of user needs is defined. QFD is performed to analyze the user needs with respect to evaluable technical properties. Subsequently each tool performance is assessed using a decision matrix. Through this process, a well-defined functional structure of MBSE tools is sketched, and in order to identify the properties of an ideal tool, all the attributes of different MBSE tools are mapped to a common platform. For the purpose of evaluation, we apply our proposed logical framework to select an exemplary MBSE tool for interdisciplinary application.

Developers change models with clear intentions-e.g., for refactoring, defects removal, or evolution. However, in doing so, developers are often unaware of the consequences of their changes. Changes to one part of a model may affect other parts of the same model and/or even other models, possibly created and maintained by other developers. The consequences are incomplete changes and with it inconsistencies within or across models. Extensive works exist on detecting and repairing inconsistencies. However, the literature tends to focus on inconsistencies as errors in need of repairs rather than on incomplete changes in need of further propagation. Many changes are non-trivial and require a series of coordinated model changes. As developers start changing the model, intermittent inconsistencies arise with other parts of the model that developers have not yet changed. These inconsistencies are cues for incomplete change propagation. Resolving these inconsistencies should be done in a manner that is consistent with the original changes. We speak of consistent change propagation. This paper leverages classical inconsistency repair mechanisms to explore the vast search space of change propagation. Our approach not only suggests changes to repair a given inconsistency but also changes to repair inconsistencies caused by the aforementioned repair. In doing so, our approach follows the developer's intent where subsequent changes may not contradict or backtrack earlier changes. We argue that consistent change propagation is essential for effective model-driven engineering. Our approach and its tool implementation were empirically assessed on 18 case studies from industry, academia, and GitHub to demonstrate its feasibility and scalability. A comparison with two versioned models shows that our approach identifies actual repair sequences that developers had chosen. Furthermore, an experiment involving 22 participants shows that our change propagation approach meets the workflow of how developers handle changes by always computing the sequence of repairs resulting from the change propagation.

When software models change, developers often fail in keeping them consistent. Automated support in repairing inconsistencies is widely addressed. Yet, merely enumerating repairs for developers is not enough. A repair can as a side effect cause new unexpected inconsistencies (negative) or even fix other inconsistencies as well (positive). To make matters worse, repairing negative side effects can in turn cause further side effects. Current approaches do not detect and track such side effects in depth, which can increase developers' effort and time spent in repairing inconsistencies. This paper presents an automated approach for detecting and tracking the consequences of repairs, i.e. side effects. It recursively explores in depth positive and negative side effects and identifies paths and cycles of repairs. This paper further ranks repairs based on side effect knowledge so that developers may quickly find the relevant ones. Our approach and its tool implementation have been empirically assessed on 14 case studies from industry, academia, and GitHub. Results show that both positive and negative side effects occur frequently. A comparison with three versioned models showed the usefulness of our ranking strategy based on side effects. It showed that our approach's top prioritized repairs are those that developers would indeed choose. A controlled experiment with 24 participants further highlights the significant influence of side effects and of our ranking of repairs on developers. Developers who received side effect knowledge chose far more repairs with positive side effects and far less with negative side effects, while being 12.3% faster, in contrast to developers who did not receive side effect knowledge.

Transformations constitute significant key components of an automated model-driven engineering solution. As metamodels evolve, model transformations may need to be co-evolved accordingly. A conducted experiment on transformations' co-evolution highlighted the existing gap in the literature where only limited few co-evolution scenarios are covered without supporting alternatives that occur in practice. To make matters worse, when a developer needs to drift apart from the proposed co-evolution, no automatic support is provided to the developer. This paper first proposes a change propagation-based co-evolution of transformations. The premise is that knowledge of the metamodel evolution can be propagated by means of resolutions to drive the transformation co-evolution. To deal with particular cases where developers must drift from the proposed resolutions, we introduce a composition-based mechanism that allows developers to compose resolutions meeting their needs. Our work is evaluated on 14 case studies consisting in original and evolved metamodels and ETL Epsilon transformations. A comparison of our co-evolved transformations with the 14 versioned ones showed the usefulness of our approach that reached an average 96% of correct co-evolution. On three other case studies, our composition-based co-evolution showed to be useful to eight developers in selecting resolutions that best meet their needs. Among the applied resolutions, four developers applied six resolutions that were the direct result of a composition.

Metamodels, like any other software artifacts evolve throughout time. As a consequence, all dependent artifacts may need to be co-evolved accordingly, including model transformations. Transformations are a key component of an automated development solution, thus it is crucial to automate their co-evolution while guaranteeing that they remain correct. However, there is little known about what aspects and characteristics must be automated in a manual co-evolution and in particular how it should be correctly automated. Few approaches exist, but it is not clear to what extent those approaches are able to automate the manual co-evolution of model transformations. In this paper, we report on an exploratory experiment we conducted to better understand the co-evolution of transformations in practice and to assess the usefulness of the current existing techniques. 15 participants were involved in our experiment to monitor how they co-evolve transformation rules in response to metamodel evolution. Our analysis results show that while existing approaches support the user with an automatic impact analysis, they do not consider proposing a very large spectrum of alternative resolutions. Among the 14 resolutions that occurred in our experiment, on average only 4 (up to 6) were supported by the existing approaches.

A common task performed in model-driven software engineering is evolving models. This task is typically performed manually during the design or implementation phase of software projects and is known to cause inconsistencies. Despite extensive research on consistency checking, existing approaches either provide abstract (i.e., incomplete) repairs only, or they require manually predefined strategies on how to repair inconsistencies. In this paper, we present a novel approach that provides concrete (i.e., executable) repairs without the need of predefined repair strategies. Furthermore, our approach proposes functions which automate the generation of concrete repairs at runtime. An empirical assessment of the approach on six case studies from industry, academia and GitHub demonstrates its feasibility, and shows that the provided concrete repairs are relevant and can fix their corresponding inconsistencies automatically.

In today's engineering projects, companies continuously have to adapt their systems to changing customer or market requirements. This requires a flexible, iterative development process in which different parts of the system under construction are built and updated concurrently. However, concurrent engineering is quite problematic in domains where different engineering domains and different engineering tools come together. In this paper, we discuss experiences with Van Hoecke Automation, a leading company in the areas of production automation and product processing, in maintaining the consistency between electrical models and the corresponding software controller when both are subject to continuous change. The paper discusses how we let engineers describe the relationships between electrical model and software code in form of links and consistency rules, and how through continuous consistency checking our approach then notified those engineers of the erroneous impact of changes in either electrical model or code.

Today's software projects face an environment of continuous change and evolution. In order to handle evolution in development environments (e.g., requirements, technology) effectively, over the last decades well-established development processes have been adapted significantly and new process models have been proposed. For example, there is a wide range of agile processes which are risk-driven and which not only handle but embrace frequent change. However, agile and risk-driven processes still suffer from a lack of support for automatic and generic identification of certain risks.