Detecting and exploring side effects when repairing model inconsistencies

Abstract

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. CCS Concepts • Software and its engineering → Model-driven software engineering; Software maintenance tools.

Transforming abstract to concrete repairs with a generative approach of repair values

“…among positive integers consider only odd values). Finally, as alternative repairs are proposed per inconsistency, in [42] we proposed one heuristic and evaluated it, we plan to provide other ranking heuristics to support the developers in quickly choosing repairs and to evaluate their benefit.…”

AI-powered model repair: an experience report—lessons learned, challenges, and opportunities

“…Alike repairs are grouped and presented to the user as repair options. Also tree-powered, Khelladi et al [37] present a model repair approach that ranks repairs depending on the positive or negative side-effect they produce by using a validation tree. They also identify alternative repair paths and cycles of repairs.…”

Tolerance in Model-Driven Engineering: A Systematic Literature Review with Model-Driven Tool Support

“…For inter-model consistency, multiple models are consistent if they are not in conflict regarding their overlapping parts, i.e., the same information contained in multiple models (Ciraci et al 2012;Ehrig et al 2008;Noyrit et al 2010;Farias et al 2012). Another important definition deals with the relationship between a model and its meta-model (Perrouin et al 2009;Rose et al 2009;Morin et al 2010;Trollmann et al 2011;Küster & Ryndina 2007;Guerra & de Lara 2018;Hao et al 1992;Hili & Sottet 2017;Hili 2016;Schoenboeck et al 2014;Demuth et al 2016;Sottet & Biri 2016;Straeten et al 2003;Burdusel et al 2019;Babikian et al 2020;Khelladi et al 2019;Gogolla et al 2015;Callow & Kalawsky 2013;Reder & Egyed 2013;Hegedüs et al 2011). This notion can be handled on two levels: (i) structural consistency includes multiplicities, composition constraints, as well as the types of model elements.…”

“…A frequently used example for tolerance is a simplified videoon-demand system modelled with Unified Modeling Language (UML) diagrams (Egyed et al 2011;Egyed 2007a;Kretschmer et al 2017;Egyed et al 2008;Reder & Egyed 2012b;Egyed 2007bEgyed , 2011Egyed , 2006Xiong et al 2009;Khelladi et al 2019).…”