Abstract

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.

Highlights

  • The benefits of model-driven engineering (MDE) hinge on the assumption that models remain consistent

  • We discuss how to use inconsistencies as guides for completing changes by (1) suggesting changes to parts of the model that repair the given inconsistencies, (2) systematically exploring further changes that repair inconsistencies caused by the changes in (1), and (3) by ensuring that the resulting sequence of changes is faithful to the initial, incomplete changes the developer made

  • RQ2: How many consistent model states does our approach find, what is the average length of the found repair sequences, and how much time did it take to compute the model state trees? This aims to investigate the performance and scalability as well as the correctness of our approach, when a developer change has been successfully propagated through the model

Read more

Summary

Introduction

The benefits of model-driven engineering (MDE) hinge on the assumption that models remain consistent. We discuss how to use inconsistencies as guides for completing changes (i.e., for consistent change propagation) by (1) suggesting changes to (not yet modified) parts of the model that repair the given inconsistencies, (2) systematically exploring further changes that repair inconsistencies caused by the changes in (1), and (3) by ensuring that the resulting sequence of changes is faithful to the initial, incomplete changes the developer made (which convey the developers’ intention). This paper introduces a method and corresponding implementation that explores the propagation of initial developer changes by systematically trying alternatives for repairing arising inconsistencies. This is done by computing a model state tree for each developer change, where every model state represents the application of exactly one repair. In cases where models have hundreds of possible repairs to propagate changes, we sorted them by the number of necessary repair steps from shortest to longest repair sequences, i.e., "fewer is better" is often considered a desirable sorting strategy

Running example
Definitions
Background
Relations of the defined terms
Consistency checking
Repair generation
11: Collect all ch with corresponding trees
3: Stop propagation if there are too many tree levels return
Stage 3
Research questions
Evaluation
Results
External validity
Internal validity
Related work
Conclusion and future work
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call