\jotdetails

volume=19, number=1, articleno=e1, year=2020, license=ccby

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

Nils Weidmann Paderborn University, Paderborn, Germany Suganya Kannan Paderborn University, Paderborn, Germany Anthony Anjorin IAV GmbH Ingenieurgesellschaft Auto und Verkehr, Berlin, Germany

Abstract

Managing models in a consistent manner is an important task in the field of Model-Driven Engineering (MDE). Although restoring and maintaining consistency is desired in general, recent work has pointed out that always strictly enforcing consistency at any point of time is often not feasible in real-world scenarios, and sometimes even contrary to what a user expects from a trustworthy MDE tool. The challenge of tolerating inconsistencies has been discussed from different viewpoints within and outside the modelling community, but there exists no structured overview of existing and current work in this regard. In this paper, we provide such an overview to help join forces tackling the unresolved problems of tolerating inconsistencies in MDE. We follow the standard process of a Systematic Literature Review (SLR) to point out what tolerance means, how it relates to uncertainty, which examples for tolerant software systems have already been discussed, and which benefits and drawbacks tolerating inconsistencies entails. Furthermore, we propose a tool-chain that helps conducting SLRs in computer science and also eases the reproduction of results. Relevant meta-data of the collected sources is uniformly described in a textual modelling language and exported to the graph database Neo4j to query aggregated information.

keywords:

tolerance, model-driven engineering, systematic literature review, consistency management

^†^†articletype: manual

1 Introduction

In the domain of Model-Driven Engineering (MDE), consistency management is an important challenge when multiple semantically interrelated models are to be developed and maintained simultaneously. Consistency management involves multiple operations on models, such as (unidirectional) transformation, (concurrent) model synchronisation (propagating changes between models), and consistency checking. Up until now, fundamental research has focussed on preserving or restoring perfect consistency between the involved models when performing such operations on them. While eventually having consistent models in a software system is a desirable goal in general, several limitations reveal an apparent need for some form of fault-tolerance in practice. In prior work, Stevens Stevens (\APACyear2014) argues for tolerating inconsistencies by listing several convincing scenarios. In the simplest case, the underlying consistency relation is partial, which means it is not always possible for a model management tool to return a consistent pair of models. In more complex cases, a consistent solution might exist, but the tool might not be able to return it, e.g. due to time restrictions. There might be various consistent solutions, but it might be neither satisfactory to choose one of them at random, nor to present (potentially thousands of) equally good solutions to the user to choose one. Closely related, but yet significantly different, is the concept of uncertainty in models Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1). In contrast to (temporarily) working with imperfect models, support for working with uncertainty allows a range of possible solutions to be encoded into a single model. This can be useful as certain information might be unknown at design time or be about to change during the development process. As approaches proposing support for tolerance and uncertainty tackle similar problems, i.e. increasing the practicability of MDE techniques, it is difficult to draw the line between such approaches.

Although the topic has been addressed in many ways and from different viewpoints Balzer (\APACyear1991); Egyed (\APACyear2006); Stevens (\APACyear2014); Guerra \BBA de Lara (\APACyear2018), there does not yet exist an overview of research on tolerance in MDE. Such an overview would facilitate further research for several reasons: First of all, it can collect and aggregate already achieved results and thereby unify definitions, establish common examples, and motivate research that has been left open. Second, fault-tolerance is a problem with a much broader scope than software modelling. Proposed definitions, examples, and (dis-)advantages might originate from other software engineering domains. In the database community, for example, there has been long-term research on maintaining and restoring consistency, and performing operations in the presence of errors Decker \BBA Martinenghi (\APACyear2011); Decker (\APACyear2017). Consequently, to avoid reinventing the wheel, research from related fields should be taken into account, as long as it matches the problem domain and transferring results to MDE is possible. To achieve these goals, an overview of existing research should provide a proper definition of tolerance and delineate between the terms tolerance and uncertainty. A collection of formal and practical frameworks should be identified that support handling of fault-tolerance in software modelling. To motivate tolerant system behaviour, a range of plausible examples is essential, which can be used in future approaches to facilitate comparison to existing work. Finally, a critical discussion of taking tolerance into account when modelling software systems should also be included to identify opportunities and risks that are inherent to tolerant approaches.

To address these requirements, we present the results of a Systematic Literature Review (SLR) on tolerance in MDE conducted from October 2019 to September 2020 following the standard methodology proposed by Kitchenham et al. B. Kitchenham (\APACyear2004); B\BPBIA. Kitchenham \BOthers. (\APACyear2009). With this review, we particularly aim at answering the following research questions:

RQ1

Scope and Classification: How is (in)consistency defined? How do tolerance and uncertainty differ? What makes an approach or tool tolerant? Which different dimensions of tolerance are there and how can tolerance be classified?
RQ2

Examples and Application Domains: In which application domains is tolerance relevant? Which examples are used to demonstrate ideas and results?
RQ3

Benefits and Challenges: What are the benefits of tolerance? What are open questions and challenges?

As a second contribution, we propose a framework that supported us while conducting this SLR and which can be reused for creating future literature reviews in computer science. In consensus with previous findings Götz (\APACyear2018), we noticed that SLRs in general are conducted with little or no tool support (or at least lack a respective description), although they involve numerous steps that could be automated, leading to unnecessary manual effort. Likewise, it also requires a substantial amount of work to reproduce the results of an SLR, leading to opacity of findings due to time restrictions. The gathering and reproduction of results should thus be eased to better utilise human resources for tasks that require advanced knowledge of the problem domain. We propose a tool-chain for partly automating the review process, which involves an adapter for querying the research database, a transformation of the results to a modelling language processable by eMoflon::Neo¹¹1https://github.com/eMoflon/emoflon-neo, a model management tool that is a recent addition to the eMoflon tool suite Weidmann \BOthers. (\APACyear2019), and an export to the graph database Neo4j²²2https://neo4j.com/, which can be queried to analyse the results.

The remainder of this paper is structured as follows: Section 2 describes the survey procedure and sketches the used tooling. Summaries of the answers to the research questions are provided in Sect. 3, 4 and 5 (a more detailed tabular overview is available online³³3https://drive.google.com/file/d/1uSuOn3hX5BHpLhw3jaH2ZpVffgTxHOov). Section 6 briefly analyses meta-data of the included sources and motivates further research on tolerance in MDE. Section 7 gives an overview of related work, before Sect. 8 concludes the paper.

2 Survey Procedure

This section briefly presents the methodology we followed to conduct the SLR. As all results should be reproducible and easily accessible for researchers of the modelling community, we therefore followed the guidelines proposed by Kitchenham et al. B\BPBIA. Kitchenham \BOthers. (\APACyear2009) for literature reviews in the software engineering domain. The review was conducted from October 2019 to September 2020 and considers sources published until June 2020. We used DBLP as a research database due to its large amount of listed publications, its focus on computer science, and its well-described API for automated queries.⁴⁴4https://dblp.uni-trier.de/faq/13501473.html Following the proposed guidelines, an initial and a final set of sources was determined by applying search phrases, and criteria for inclusion, exclusion, and quality of the gathered sources, described in the following.

To form an initial set of sources, we defined six search strings inspired by the research questions and the domain MDE, of which at least two must appear in a title. Each of these strings has a wildcard (*) as suffix to take nouns, verbs and adjectives into account. We therefore decided to query the database with all pairs formed from the search strings model*, consisten*, inconsisten*, uncertain*, tolera* and flexib*. As a combined inclusion and quality criterion, we further require the respective sources to be published at a conference listed by the CORE ranking⁵⁵5http://portal.core.edu.au/conf-ranks/ and assigned to the research field 0803 (Software Engineering). Due to this requirement, the search is focussed on the software engineering domain and peer-reviewed publications, while journal and workshop papers are initially excluded. Due to the publishing behaviour in the computer science domain, we expect late-breaking research results to be published at conferences, whereas journal articles usually extend previously published results of conference papers in more depth. Furthermore, the list of journals at CORE⁶⁶6http://portal.core.edu.au/jnl-ranks/ was outdated when the review was conducted, making it difficult to apply equal criteria to journal and conference papers in the initial search step. Workshop papers often present work in progress and initial ideas to be published at conferences afterwards. To detect relevant papers which do not fulfil all criteria of the initial search, we applied snowballing at a subsequent step. In this manner, we retrieved 268 sources, which we denote in the following as core papers.

To compile a final set of sources, we distributed the core papers between three researchers and assessed their relevance based on the abstract. In case it remained unclear if the respective paper should be considered, introduction and conclusion were read as well. As suitable examples demonstrating the use of tolerant system behaviour are essential to answer RQ2, the remaining parts of the papers were skimmed for such examples. The assessment was based on inclusion, exclusion, and quality criteria. A paper was included in the further review process if it (1) presents an MDE or Programming Languages (PL) approach related to (in)consistency management, or (2) if it contains an example or application related to tolerance or uncertainty. We excluded a paper if any of the search terms has a different meaning than the one implied by the research questions, e.g. if model refers to the physical behaviour of a Cyber-Physical System (CPS). Papers written in other languages than English were also excluded, while this criterion never had to be applied, probably due to the choice of search strings. To ensure a high quality of the selected sources, prefaces and extended abstracts were excluded. In total, 114 relevant core papers were identified and added to the final set of sources.

In a second iteration, we applied snowballing to consider papers that were not detected in our first iteration but might be nonetheless relevant to answer the research questions. The corpus of this SLR was extended by all sources which are cited by at least one of the core papers, resulting in 3201 additional papers. To keep the number of paper for the second assessment phase manageable, we added a further inclusion criterion for these additional papers: a minimum citation count by relevant core papers, as papers cited more frequently are more likely to be relevant. As newer sources naturally have a lower citation count, the number of required citations was set in relation to the publication year. As papers published at Software Engineering (SE) venues should be preferred, the minimum citation count per year was set to 0.2 for SE papers and to 0.3 for all other papers. As a result, 53 papers from SE venues and 41 papers from other venues were evaluated according to the same inclusion, exclusion, and quality criteria as the core papers. After the second assessment phase, 23 papers from SE venues and 20 other sources were added, increasing the final set of sources to 157 papers. An overview of our assessment and selection process is depicted in Tab. 1. For each property, a check (✓) means that it is fulfilled by the respective category of papers, whereas a cross (✗) means the opposite. If the property is irrelevant, this is indicated by a hyphen (-). The rightmost two columns contain the number of papers per category identified as (not) relevant.

$\geq 2$ keywords	published at	min. annual	initially	rele-	not re-
in title?	an SE venue?	citation count	read?	vant	levant
✓	✓	-	✓	114	154
✗	✓	$\geq 0.2$	✓	23	30
✗	✓	$<0.2$	✗	0	1093
-	✗	$\geq 0.3$	✓	20	21
-	✗	$<0.3$	✗	0	2014

Table 1: Categorization of papers for the review

Although the survey procedure is well-defined and takes multiple objective measures into account in order to make results transparent and reproducible, several threats to validity have to be mentioned as well. Firstly, the naming conventions for conferences in the DBLP database and in the CORE ranking differ slightly. To overcome this problem, we matched the respective conferences if their acronym is the same, or if one name is a substring of the other. This method works well for venues listed in the latest version of the CORE ranking but, as conferences are renamed over time, older venues might not be identified as SE venues. While prefaces and extended abstracts were excluded, no distinction was made between different paper categories, such as full, short or tool paper. Even though late-breaking results are usually published as conference papers in the computer science domain, we might have missed results only published in journal papers, as those were not considered in the first assessment phase. Besides DBLP, the use of other research databases - such as Google scholar - could have helped to gather more sources for the SLR and to therefore minimise the risk of missing important work. Finally, although inclusion, exclusion and quality criteria were discussed between the involved researchers in detail before the review was conducted, only one researcher per paper evaluated its relevance, which might lead to biased results as the assessment of relevance depends on a single person.

Refer to caption — Figure 1: SLR Metamodel

In Fig. 1, the metamodel for the representation of results is depicted. A Paper is written by Authors and appears at a Venue. For each Paper, the title and the year of publication are extracted. Boolean values indicate whether the paper is a core paper, and whether it was identified as relevant for the SLR in the initial reading phase. A cites relation defines which Paper references which other Papers. For the Author, only the name is stored, whereas the Venue is additionally flagged as being an SE conference listed at DBLP or not. In Fig. 2, the architecture for transferring the bibliography data records to a graph database is depicted. The DBLP research database provides an interface to query records that match a specified search string containing logical connectors and wild cards. Additionally, we exported the list of venues assigned to the research field 0803 (SE) as a Comma-Separated Values (CSV) file. For each possible pair of the six keywords, the database was queried and its venue was compared to the list of SE venues. In this way, the core papers for this SLR are identified and saved as models typed over the metamodel of Fig. 1. After examining each of the core papers regarding its relevance for the research questions, the respective attribute was manually added in the bibliography model. In the last step, the files were exported from eMoflon::Neo to Neo4j (cf. Sect. 1), such that queries on the bibliography model can be used to analyse the collected data.

An important argument for the use of a database representation for the SLR was the snowballing step, which is - depending on the number of relevant papers - a time-consuming and error-prone task. To integrate citation information into the database, all papers referenced by the core papers were added via the database snapshot DBLP-Citation-network V12⁷⁷7https://www.aminer.org/citation which was created with the tool ArnetMiner Tang \BOthers. (\APACyear2008). Having extended the bibliography model with all papers cited from the initial set of sources, it is possible to collect all papers that fulfil the condition for being added within the snowballing step with a single database query.

3 Scope and Classification

In order to answer the first research question, definitions for the key terms of this SLR were gathered and aggregated while analysing the relevant sources. Besides a brief summary, feature models for consistency (Fig. 3), tolerance (Fig. 4) and uncertainty (Fig. 5) were created to provide an overview of the different dimensions involved.

3.1 Consistency

In general, consistency can be understood as a relation over sets of models, which can be specified in different ways Stevens (\APACyear2014); Sabetzadeh \BOthers. (\APACyear2008); Hamlaoui \BOthers. (\APACyear2014); Stevens (\APACyear2018\APACexlab\BCnt2, \APACyear2017, \APACyear2018\APACexlab\BCnt1); Cicchetti \BOthers. (\APACyear2010). Most frequently, consistency is specified by a provided set of constraints Kretschmer \BOthers. (\APACyear2018); Vierhauser \BOthers. (\APACyear2012); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt1); Shan \BBA Zhu (\APACyear2004); Sabetzadeh \BOthers. (\APACyear2007); Lytra \BOthers. (\APACyear2012); Decker (\APACyear2011); Mens \BOthers. (\APACyear2006); Blanc \BOthers. (\APACyear2008); Egyed \BOthers. (\APACyear2011); Egyed (\APACyear2007\APACexlab\BCnt1); Kretschmer \BOthers. (\APACyear2017); Egyed \BOthers. (\APACyear2008); Reder (\APACyear2011); Leblebici \BOthers. (\APACyear2017); Krishna \BOthers. (\APACyear2005); Dávid \BOthers. (\APACyear\bibnodate); Guerra \BBA de Lara (\APACyear2018); Jahanbanifar \BOthers. (\APACyear2016); Shan \BBA Zhu (\APACyear2006); Lytra \BOthers. (\APACyear2013); Balzer (\APACyear1991); Riedl-Ehrenleitner \BOthers. (\APACyear2014); Egyed (\APACyear2011); Nentwich \BOthers. (\APACyear2003); Zolotas \BOthers. (\APACyear2016); Egyed (\APACyear2006); Nuseibeh \BOthers. (\APACyear2000); Xiong \BOthers. (\APACyear2009); Link \BOthers. (\APACyear2001); Burdusel \BOthers. (\APACyear2019); Babikian \BOthers. (\APACyear2020); Khelladi \BOthers. (\APACyear2019); Gogolla \BOthers. (\APACyear2015); Hegedüs \BOthers. (\APACyear2011); Reder \BBA Egyed (\APACyear2013), which can be formulated in different ways. Often, the Object Constraint Language (OCL) is chosen for defining consistency, but also graph constraints and logical constraints, such as formulae of propositional or first-order logic or as Satisfiability Modulo Theories (SMT), are commonly used. Independent of the language in use, a model (or a proposed solution) is typically viewed as being consistent if it satisfies all constraints.

Consistency can also be defined constructively via a given model transformation $T$ , such that two models $A$ and $B$ are consistent if and only if $A=T(B)$ Wolfe \BOthers. (\APACyear2009); Macedo \BBA Cunha (\APACyear2013). Furthermore, multiple model transformations (e.g., syntactic changes) are often considered to be consistent if they implement the same underlying transformation (e.g., semantic change) Kusel \BOthers. (\APACyear2015). This is especially relevant in the context of co-evolution, where multiple interrelated transformations are concurrently conducted. There are also constructive definitions which define methodological consistency over the sequence of operations required to construct a model. As long as certain steps are followed in the construction or “design” process, the consistency of the resulting model(s) can be guaranteed Blanc \BOthers. (\APACyear2008); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt2). For example, a name must be assigned immediately after an element is created.

Besides these general consistency specifications, some definitions are also tailored to a specific application area. When modelling CPSs, a model is said to be consistent with the real world - or any other system for which this can be checked - if the model makes statements or reaches conclusions that are actually true Kyrkou \BOthers. (\APACyear2015). For goal-oriented modelling, “plan consistency” means that the achievement of sub-goals implies the achievement of their parent goal Friedrich (\APACyear2018). In the application domain of software product line engineering, a feature model is consistent if at least one valid configuration exists Barreiros \BBA Moreira (\APACyear2014).

The notions of consistency can be applied to both the intra- and inter-model case. 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 \BOthers. (\APACyear2012); Ehrig \BOthers. (\APACyear2008); Noyrit \BOthers. (\APACyear2010); Farias \BOthers. (\APACyear2012). Another important definition deals with the relationship between a model and its meta-model Perrouin \BOthers. (\APACyear2009); Rose \BOthers. (\APACyear2009); Morin \BOthers. (\APACyear2010); Trollmann \BOthers. (\APACyear2011); Küster \BBA Ryndina (\APACyear2007); Guerra \BBA de Lara (\APACyear2018); Hao \BOthers. (\APACyear1992); Hili \BBA Sottet (\APACyear2017); Hili (\APACyear2016); Schoenboeck \BOthers. (\APACyear2014); Demuth \BOthers. (\APACyear2016); Sottet \BBA Biri (\APACyear2016); Straeten \BOthers. (\APACyear2003); Burdusel \BOthers. (\APACyear2019); Babikian \BOthers. (\APACyear2020); Khelladi \BOthers. (\APACyear2019); Gogolla \BOthers. (\APACyear2015); Callow \BBA Kalawsky (\APACyear2013); Reder \BBA Egyed (\APACyear2013); Hegedüs \BOthers. (\APACyear2011). This notion can be handled on two levels: (i) structural consistency includes multiplicities, composition constraints, as well as the types of model elements. (ii) static semantics expressed, e.g. via OCL constraints. Finally, a set of constraints is often denoted as consistent if there exists at least one solution (e.g., a variable assignment) that satisfies all constraints B. Wang \BOthers. (\APACyear2010); C. Wang \BBA Cavarra (\APACyear2009); Gogolla \BOthers. (\APACyear2009); Hao \BOthers. (\APACyear1992); Straeten \BOthers. (\APACyear2003).

3.2 Tolerance

Based on the collected definitions of consistency, the term tolerance can be specified more concretely.

Building on the constraint-based definition of consistency, tolerance can be implemented by weakening the requirement of constraint satisfaction B. Wang \BOthers. (\APACyear2010); Perrouin \BOthers. (\APACyear2009); Barreiros \BBA Moreira (\APACyear2014); Petersen \BOthers. (\APACyear1997); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt2); Leblebici \BOthers. (\APACyear2017); Dávid \BOthers. (\APACyear\bibnodate); Vouk \BOthers. (\APACyear1990). Solutions that satisfy more important constraints are then “better”, i.e., more consistent than other solutions that might satisfy more but less important constraints. Tolerance here is, therefore, basically a ranking or weighting of constraints and a score for solutions based on how many weighted constraints are satisfied. This prioritisation and sorting process is often referred to as “relaxation”; the constraints are sometimes denoted as “soft constraints” as their violation no longer directly implies exclusion of the respective solution. By defining different classes of inconsistencies and measuring consistency as vectors over these dimensions, one can obtain a more fine-grained view of the extent to which consistency is achieved or improved with respect to each class Yu \BBA Vahdat (\APACyear2000); Kolovos \BOthers. (\APACyear2008). A similar approach divides the constraints or requirements into primary and non-primary, whereby non-primary constraints can be ignored in a tolerant scenario Höllrigl \BOthers. (\APACyear2010); Reder (\APACyear2011). The idea is to ignore inconsistencies that are “irrelevant”, e.g., concerning white space or time stamps, layout, etc.

Another important group of strategies for implementing tolerance involve temporal aspects. Most approaches assume that inconsistencies can be tolerated up to some point in time when consistency is restored, such that fixes are delayed up to this point Höllrigl \BOthers. (\APACyear2010); Yu \BBA Vahdat (\APACyear2000). For distributed systems, a variable threshold for inconsistencies is defined by a temporal window such that more inconsistencies are accepted at the beginning and fewer towards the end. These approaches aim at letting a system “stabilise” before demanding a high level of consistency.

In contrast to temporal strategies, a further group takes a spatial approach to implementing tolerance: case-based restoration guarantees that every part of the model that was consistent before is still consistent afterwards Stevens (\APACyear2014); Decker \BBA Martinenghi (\APACyear2008); Decker (\APACyear2011); Stevens (\APACyear2017); Egyed (\APACyear2006); Balzer (\APACyear1991). For efficiency reasons, only a subset of “relevant” cases can be determined, i.e., a scope of influence is computed for changes, and then checked as for case-based restorers. Measure-based restorers guarantee that a chosen measure of consistency is not reduced by the restoration process.

A frequently named property of fault-tolerant systems is that strategies are implemented to detect and fix inconsistencies either automatically or by interacting with the user Hamid \BBA Mosbah (\APACyear2005); Egyed \BOthers. (\APACyear2008); Guerra \BBA de Lara (\APACyear2018); Bagheri \BBA Ghorbani (\APACyear2007); Ebnenasir \BBA Cheng (\APACyear2007); Egyed (\APACyear2007\APACexlab\BCnt2); Link \BOthers. (\APACyear2001); Egyed (\APACyear2011); Vouk \BOthers. (\APACyear1990). Even if a system is brought into an inconsistent state, it can transition back to a consistent state by applying fix strategies. Consequently, an inconsistent state is temporarily acceptable, making it unnecessary to check if edits are consistency-preserving, or to propagate changes to other models immediately. However, it is often important to keep track of inconsistent model parts as this can speed up the consistency restoration later. In case of user involvement, this can also help to avoid overwhelming users with too many design decisions.

Overall, tolerant concepts can help ease the work flow for modelling tasks by not enforcing an immediate resolution of inconsistencies. Additionally, they can function as a mechanism to detect unresolved conflicts in the real world, or to rethink prematurely made design decisions Nuseibeh \BOthers. (\APACyear2000). Finally, tolerating and highlighting inconsistencies can be used to indicate misunderstandings or a potential disagreement of the involved developers Xiong \BOthers. (\APACyear2009).

3.3 Uncertainty

To help make a distinction between tolerance and uncertainty, we provide an overview of the most common notions of uncertainty in the following.

Modelling with uncertainty often involves encoding a range of possible values or alternatives into a single attribute value or part of a model Gao \BOthers. (\APACyear2011); Brambilla \BOthers. (\APACyear2017); Bucaioni \BOthers. (\APACyear2016); Famelis \BOthers. (\APACyear2015); Eramo \BOthers. (\APACyear2015); Famelis \BBA Santosa (\APACyear2013); Bagheri \BBA Ghorbani (\APACyear2007); Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1); Prasetya \BBA Klomp (\APACyear2019); Hansen \BBA Thomsen (\APACyear1999); Martinho \BOthers. (\APACyear2008). Additionally, the set of valid combinations of these parts must also be defined, which can possibly increase or reduce the range of valid alternatives. As a result, the designer is provided with a compact but expressive representation of all solution candidates. Furthermore, modelling with uncertainty can mean a probabilistic extension of a normal model made by adding probabilities to every assumed value, which are mostly attribute values Kyrkou \BOthers. (\APACyear2015); Vallecillo \BOthers. (\APACyear2016); Cheng \BOthers. (\APACyear2009); Mayerhofer \BOthers. (\APACyear2016); Tran \BBA Massacci (\APACyear2014). These probabilities are often referred to as confidence values.

Uncertainty can be used in different phases of the modelling process, and there are multiple strategies to eventually resolve uncertainty Förster \BBA Schneider (\APACyear2010); Famelis \BBA Santosa (\APACyear2013); Camilli \BOthers. (\APACyear2018); Hansen \BBA Thomsen (\APACyear1999); Bamgboye \BOthers. (\APACyear2018); Famelis \BOthers. (\APACyear2013); Garlan (\APACyear2010); Camilli \BOthers. (\APACyear2017); Ibrahim \BOthers. (\APACyear2009). The lack of information about the content of models is denoted as design-time uncertainty, which makes it impossible to select among alternative design decisions. This uncertainty can be captured in partial models consisting of a “base model” enriched with annotations that express the set of alternatives Salay, Chechik\BCBL \BBA Horkoff (\APACyear2012); Salay, Famelis\BCBL \BBA Chechik (\APACyear2012); Famelis \BOthers. (\APACyear2012\APACexlab\BCnt2). By refining the partial model, uncertainties can be resolved during the design phase Salay, Chechik\BCBL \BBA Gorzny (\APACyear2012). The residual uncertainty is denoted as run-time uncertainty and is resolved by the user via a selection out of all remaining alternatives.

Different sources of uncertainty can be distinguished regarding multiple dimensions Camilli \BOthers. (\APACyear2017); Goldsby \BBA Cheng (\APACyear2008); Ghezzi \BOthers. (\APACyear2013); Ramirez \BOthers. (\APACyear2012); Serban \BOthers. (\APACyear2020); Esfahani \BBA Malek (\APACyear2010); Zhang \BOthers. (\APACyear2019, \APACyear2017). The source of uncertainty can either be the system itself or its execution environment. System uncertainty includes uncertainty about input parameters, structural and algorithmic uncertainty due to approximations, or experimental uncertainty caused by variable measured values. Environmental uncertainty can originate from incomplete information about the behaviour of external components, which are provided by third-party organisations, or input data provided by sensors or wireless networks. Furthermore, the root cause of uncertainty can either be the lack of knowledge about one of the aforementioned factors or some non-determinism within the system. In general, as uncertainty forces the developer to make decisions based on assumptions, one is not able to guarantee the optimality of those decisions, involving various trade-offs.

In summary, modelling with uncertainty denotes a way of efficiently encoding multiple alternatives into a single representation, from which at least one valid, i.e. consistent, configuration should be derivable. Tolerance, in contrast, means being able to perform operations on models in the presence of inconsistencies, while the ultimate goal is still to eventually reach a consistent state. Both concepts aim at facilitating the work flow of system designers and developers by aligning the principles of MDE to practical requirements. Likewise, both tolerance and uncertainty involve a combination of automated and user-centric resolution strategies to finally obtain an unambiguous and consistent model.

4 Examples and Application Domains

This section gives an overview of examples related to tolerance and uncertainty in different application fields. Although the underlying notion for consistency is essential for understanding the proposed approaches to tolerating inconsistencies (cf. Sect. 3), the presented examples and mentioned (dis-)advantages mostly refer to concepts of tolerance and uncertainty building up on it. Instead, we also found examples and arguments for flexibility as a general term subsuming tolerance and uncertainty, such that we devote a further subsection to it in the following.

Research Domain	#	Research Domain	#
Aspect-oriented modelling	3	Process Modelling	4
(Meta-)model Co-Evolution	4	Product Line Engineering	7
Cyber-Physical Systems	7	Requirements Engineering	9
Databases	5	Service-Oriented Computing	3
Distributed Systems	4	Smart & Adaptive Systems	10
Language Engineering	4	Software Architecture	4
Mobile & Cloud Computing	3	Software Engineering (Other)	5
Model-Based Testing	7	Software Verification	4
Model-Driven Engineering	74	TOTAL	157

Table 2: Number of relevant papers per research domain

In Tab. 2, the number of relevant sources per research domain is depicted. Most of the sources are related to MDE and similar fields, such as co-evolution, model-based testing, process modelling, and aspect-oriented modelling. Especially uncertainty appears to play an important role for requirements engineering and adaptive systems. The relatively large number of papers concerning other sub-domains of software engineering such as language engineering, product line engineering, software architecture and service-oriented computing underpins the importance of tolerance and uncertainty for the entire field of research. Cyber-physical and distributed systems, as well as mobile computing, can be identified as relevant application domains due to the substantial impact of environmental conditions involved. Several papers concern multiple research domains, such that a prioritisation was necessary in these cases: When MDE concepts were applied to a concrete use case, the paper was allocated to the application domain. For papers which can be matched to different software engineering domains, the main focus was taken as decisive factor.

From the set of relevant sources 36 examples could be extracted, which can be used to illustrate approaches to tolerance, uncertainty, flexibility, or consistency management in general. 23 examples focus on a conceptual approach, 6 are used for tool demonstrations, and 7 cover both purposes equally. In the following, examples for tolerance, uncertainty, and flexibility are briefly sketched; a complete list including examples for consistency management and further classifications can be found online⁸⁸8https://drive.google.com/file/d/1uSuOn3hX5BHpLhw3jaH2ZpVffgTxHOov.

4.1 Tolerance

A frequently used example for tolerance is a simplified video-on-demand system modelled with Unified Modeling Language (UML) diagrams Egyed \BOthers. (\APACyear2011); Egyed (\APACyear2007\APACexlab\BCnt1); Kretschmer \BOthers. (\APACyear2017); Egyed \BOthers. (\APACyear2008); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt2); Egyed (\APACyear2007\APACexlab\BCnt2, \APACyear2011, \APACyear2006); Xiong \BOthers. (\APACyear2009); Khelladi \BOthers. (\APACyear2019). The system consists of a streamer retrieving and decoding the content, and a display showing the video and receiving user input. Each component is modelled with a state chart diagram, in addition to a common class and sequence diagram for both components. Design rules describe the semantic interrelations between state charts, class diagram, and sequence diagram, e.g. that a class method name be equal to the corresponding message name in the sequence diagram, or that a message sequence match the behaviour in the state chart. As a software tool cannot decide if the effects of fixing inconsistencies, probably introduced when changing one model, are desirable or not, a tolerant treatment is suggested.

Tolerating inconsistencies has been a long-term research topic for databases, which is illustrated by an example dealing with a project management tool storing information about the utilisation of employees for projects, as well as how many hours per week they should work Balzer (\APACyear1991). Constraints ensure that the sum of hours an employee works in all projects is equal to their regular working hours. The time an employee is needed for a project is maintained by project managers, whereas the regular working hours can only be changed by the business office. It is, therefore, not possible to change project plans or working hours without temporarily introducing inconsistencies.

In the requirements engineering domain, requirements can be described with model fragments that conform to a core requirements metamodel Perrouin \BOthers. (\APACyear2009). The complete specification for a library management system, in which books must be registered such that customers can borrow them, can be created by fusing all fragments into one model. As this procedure can clearly lead to inconsistencies and the loss of meta-model compliance, it is necessary to temporarily relax the metamodel regarding abstract classes, multiplicities, and containment relations. Metamodel conformance is later restored by fixing the remaining inconsistencies.

The DOPLER tool suite Vierhauser \BOthers. (\APACyear2012) is used in software product line engineering for sales support systems for product configuration. Based on Eclipse, the tool is able to manage consistency between a variability model, a calculation model, and document templates. All models can be edited in parallel via suitable editor windows. Inconsistencies are tolerated in a way that their immediate resolution is not enforced, but occurring problems are listed in the Eclipse error viewer.

Adaptive systems have to cope with the impact of environmental conditions; this is also reflected in their software models. For flood warning systems, it is important to predict floods as early as possible to reduce damage Goldsby \BBA Cheng (\APACyear2008). In a distributed system of sensors, water depth is calculated with pressure sensors, while flow speed is determined with camera sensors. The sensor nodes transmit the information to a gateway node, which forwards the predictions to an off-site server. The system needs to be fault-tolerant because signals can get lost, nodes can get disconnected, etc. Uncertainty is also involved regarding the execution environment and an appropriate trade-off between functional behaviour (e.g. prediction accuracy) and non-functional characteristics (e.g. energy efficiency) for changing environmental conditions.

4.2 Uncertainty

Another use case for systems that dynamically adapt to uncertain environmental conditions is a smart phone app for shop reviews, which provides users with information about lower prices for a product Ghezzi \BOthers. (\APACyear2013). The product’s bar code is scanned with the camera to identify the product, and the user’s position is determined to make suggestions for nearby shops, while an online search in web shops is performed simultaneously. However, the quality of the photo, the positioning system and the availability of mobile data represent sources of uncertainty that have to be taken into account when modelling the system.

Uncertainty in model-based testing is demonstrated by testing UML specifications for a video conference system Ji \BOthers. (\APACyear2018). The models store information about the number of connected participants and the video quality. Changing environmental conditions, such as packet loss in the network, or joining and leaving participants, are the primary sources of uncertainty.

The use of type systems can be substantially influenced by the uncertainty of measured values. In an illustrative case study, a toy car drives along a straight track, which is partitioned into multiple sections. Within this set-up, the car’s velocity and acceleration on each of the sections Mayerhofer \BOthers. (\APACyear2016) should be computed. The system model involves uncertainty regarding the length of the sections (at design-time) and the time measurements (at run-time). Besides these absolute values, also relative values, such as the velocity and acceleration of the car, are uncertain.

Several small-scale but useful examples for modelling with uncertainty originate from MDE research itself. In an e-commerce application for selling books, data about books, authors, comments on the books, and details on books and authors is shown to the user Brambilla \BOthers. (\APACyear2017). A user interaction model specifies how a user can navigate between the respective views with help of the Interaction Flow Modeling Language (IFML). Due to a combinatorial explosion, it is challenging to evaluate all possible alternative flows with usability tests. Integrating uncertainty in IFML models, however, can help to specify a compact encoding of all these alternatives.

Code refactorings can be expressed in software models in terms of transformation rules. This becomes especially challenging for models incorporating uncertainty Famelis \BOthers. (\APACyear2012\APACexlab\BCnt2). To explain transformation semantics on uncertain models, it is assumed that a modeller might not be sure whether an attribute should be added to the subclass or the superclass of an inheritance hierarchy. Furthermore, the model is to be refactored by adding get- and set-methods to both classes, which leads to an exponential growth of possible results, demonstrating the need for a compact encoding of uncertain values.

In a fictional automotive design project, modelling with uncertainty is motivated for UML class diagrams. The three involved classes represent controllers for engine, body, and security of the car Salay, Chechik\BCBL \BBA Gorzny (\APACyear2012). Similarly, a perception system for autonomous driving is used to demonstrate uncertainty occurring during object detection and position determination in a scene Serban \BOthers. (\APACyear2020). In a partial model (involving design uncertainty), each controller’s attributes are modelled as attribute sets, which can be refined to discrete attributes by partial model refinement. Besides attributes, this refinement step can affect the existence of an inheritance relation (e.g. between the classes car and vehicle) or the knowledge if car and vehicle are actually the same class Salay, Famelis\BCBL \BBA Chechik (\APACyear2012).

Smart home systems provide solutions for intrusion detection with sensors, which are however exposed to uncertainty on several levels. Both imprecise measurements on sensors, the network infrastructure which connects the sensors and the interactions between physical units can be sources of uncertainty, leading to false positives and negatives when triggering alarm signals Camilli \BBA Russo (\APACyear2020); Zhang \BOthers. (\APACyear2019).

The design of an automatic reasoning engine for logical expressions is taken as an example for design uncertainty Famelis \BOthers. (\APACyear2013). When the reasoning engine reaches an error state, a solver exception should be thrown, whose concrete implementation has some points of uncertainty. The exception may be an inner class of the solver, or an attribute could possibly provide more information about the error type. A similar example for uncertainty resulting from incomplete requirements is presented via an UML state chart for a bank ATM. Depending on the required level of strictness, the ATM can either be restarted or set to be out of service in case of errors Eramo \BOthers. (\APACyear2014).

Finally, a framework for model-based testing under uncertain conditions was presented in recent work Zhang \BOthers. (\APACyear2019) to cope with the inherent uncertainty of CPS components. Connecting it to a test ready model evolution framework Zhang \BOthers. (\APACyear2017), it is possible to generate further test cases for CPSs from evolved models.

4.3 Flexibility

Some of the considered examples illustrate the use of flexibility in software modelling, which can be seen as a generalisation of concepts including both tolerance and uncertainty. Motivating examples for flexibility with respect to metamodel conformance are proposed in co-evolution scenarios. When keeping class diagrams and relational databases consistent Kusel \BOthers. (\APACyear2015), refactorings on the metamodel make it necessary to adapt the transformation definition and the models, which should comply to this modified metamodel. As common examples for refactorings, deleting or moving attributes to other classes, introducing inheritance relations, or renaming references are listed.

In a similar setting, a family register is to be kept consistent with a persons register Sottet \BBA Biri (\APACyear2016), such that, for example, the first and last name of a family member should be consistent with the full name of the corresponding person. When the metamodel is adapted, e.g. by adding a nickname attribute to the family member or by fusing first and last name, it is useful to relax the conformance relation by (temporarily) deactivating type or cardinality checks.

Especially when working with EMF, co-evolving metamodels introduce problems and additional effort for the persons involved, which is illustrated by a small case study modelling the network infrastructure of an office, including all shared gadgets such as scanners, photocopiers and fax machines Rose \BOthers. (\APACyear2009). As the EMF editor always enforces strict metamodel conformance, it is not possible to work with models conforming to older versions of the metamodel. A common workaround is the trial-and-error strategy of loading a model to get an error message from EMF, and then attempting to fix this error directly in the XMI document, obviously a tedious and error-prone task.

To model flexibility in software processes, the Eclipse Process Framework Composer (EPFC) was extended to ease the collaboration of the involved persons Martinho \BOthers. (\APACyear2008). The process engineers propose a flexible work flow, which can be adapted by other participants in a second step.

5 Benefits and Challenges

To investigate the third research question, arguments were collected that support or question the use of tolerance or uncertainty. As benefits and drawbacks differ, the two concepts were analysed separately. More general arguments, which deal with more flexibility in software engineering, concern both concepts and are discussed afterwards.

5.1 Tolerance

A range of benefits resulting from tolerating inconsistencies to some extent was identified during the SLR. In some application scenarios, such as distributed software systems, fault-tolerance is required to achieve availability and partition-tolerance Höllrigl \BOthers. (\APACyear2010); Hamid \BBA Mosbah (\APACyear2005); Decker (\APACyear2011); Balzer (\APACyear1991). Similarly, being able to handle inconsistencies is essential due to the modularity of applications and data sources in modern software systems; errors can easily occur when composing building blocks in a new way, even if each module is implemented correctly Fan \BOthers. (\APACyear2009); Decker \BBA Martinenghi (\APACyear2008). A frequently mentioned point is that temporarily tolerating inconsistencies can ease the work flow for system designers and testers as a fault-tolerant Integrated Development Environment (IDE) does not enforce the restoration of consistency before further modelling steps can be performed Vierhauser \BOthers. (\APACyear2012); Paradkar \BBA Klinger (\APACyear2004); Perrouin \BOthers. (\APACyear2009); Gabsi \BOthers. (\APACyear2016); Guerra \BBA de Lara (\APACyear2018); Jahanbanifar \BOthers. (\APACyear2016); Egyed (\APACyear2011); Schoenboeck \BOthers. (\APACyear2014). Usually, atomic changes such as graph edits can lead to inconsistent states in between, which should be tolerated at least until the entire edit sequence is completed Kretschmer \BOthers. (\APACyear2018); Stevens (\APACyear2014); Decker (\APACyear2011); Yu \BBA Vahdat (\APACyear2000); Gabsi \BOthers. (\APACyear2016); Vierhauser \BOthers. (\APACyear2010); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt2); Vouk \BOthers. (\APACyear1990); Guerra \BBA de Lara (\APACyear2018); de Souza \BOthers. (\APACyear2003); Egyed (\APACyear2011); Nuseibeh \BOthers. (\APACyear2000); Khelladi \BOthers. (\APACyear2019). From a practical point of view, improving consistency might be more helpful than enforcing it strictly. Often, the restoration process requires multiple changes that can each be regarded as an improving step towards consistency, while only the last one is able to finally restore consistency Stevens (\APACyear2014); Decker (\APACyear2011). Furthermore, a detected error often reveals another problem, which might be the root cause of multiple other defects. Therefore, information about inconsistencies is often more helpful than an automated fix that achieves consistency Egyed \BOthers. (\APACyear2008); Egyed (\APACyear2007\APACexlab\BCnt2); Khelladi \BOthers. (\APACyear2019). In fault-tolerant systems, the number of automated changes can be decreased, which can improve the tool’s trustworthiness for the designer Stevens (\APACyear2014). Even if automated changes are the preferred way of resolving conflicts, their application often relies on a central authority to define a policy for restoration steps. Especially when more than two models are involved, it is in general not possible to declare one of the models as the authoritative one, or prefer a certain type of changes over others due to, e.g., transitive consequences Friedrich (\APACyear2018); Stevens (\APACyear2018\APACexlab\BCnt2). It follows that, whenever a design decision is ambiguous, only the uncontroversial steps can be fully automated - leading to a possibly inconsistent state - before the user must participate in resolving the remaining inconsistencies Stevens (\APACyear2014); Egyed \BOthers. (\APACyear2011); Xiong \BOthers. (\APACyear2009). Another set of arguments refers to weaknesses of fixing-procedures. To maintain an acceptable level of efficiency, many approaches apply local fixes to restore consistency. This means that mechanisms don’t have a global view on the modelled system, and local fixes can have side-effects that are not monitored by the tool Egyed \BOthers. (\APACyear2011); Egyed (\APACyear2007\APACexlab\BCnt1); Hegedüs \BOthers. (\APACyear2011). Consequently, these fixes might introduce new inconsistencies, which are often hard to detect, and which have to be fixed at a later point Decker (\APACyear2011); Egyed (\APACyear2007\APACexlab\BCnt1); Egyed \BOthers. (\APACyear2008); Küster \BBA Ryndina (\APACyear2007); Egyed (\APACyear2011); Khelladi \BOthers. (\APACyear2019); Hegedüs \BOthers. (\APACyear2011). As multiple stakeholders are involved in the modelling of complex systems, their requirements can be contradictory. Without being able to tolerate these defects for a while, the modelling process gets stuck at this point and requires an instant resolution DeVries \BBA Cheng (\APACyear2016); Egyed (\APACyear2006). Last but not least, the consistency check itself can be erroneous, such that the respective tool finds false positives. While it is undisputed that the error has to be removed, tolerant behaviour could again ease the continuation of the modelling process Reder (\APACyear2011).

Despite this long list of advantages, many authors argue against involving tolerance in system design. It is questionable how long and to which extent inconsistencies should be tolerated, because a large number of factors have an influence on the value of fault-tolerance in a specific use case Höllrigl \BOthers. (\APACyear2010); Perrouin \BOthers. (\APACyear2009); Blanc \BOthers. (\APACyear2008); Egyed (\APACyear2007\APACexlab\BCnt1); Kretschmer \BOthers. (\APACyear2017); Ebnenasir \BOthers. (\APACyear2006). Certainly, one should not lose track of the goal of eventually restoring consistency. Assuming that it is always possible to fix inconsistencies at a later point, this might still involve additional effort and thus a higher cost Egyed (\APACyear2007\APACexlab\BCnt2, \APACyear2006); Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt1); Salay, Chechik\BCBL \BBA Horkoff (\APACyear2012); Hao \BOthers. (\APACyear1992); Khelladi \BOthers. (\APACyear2019). On the one hand, when consistency should eventually be restored, the developer might be confronted with so many errors at once that they are overwhelmed. On the other hand, errors might be caused by changes that occurred so long ago, that design decisions have to be completely revisited Egyed (\APACyear2006). As developers are usually willing to fix errors as soon as they are noticed, they will probably do the same when they detect inconsistencies that could actually be tolerated by the system. This means that such a tool’s potential for supporting tolerance will probably be ignored by its users Kolovos \BOthers. (\APACyear2008). Also, performing operations (e.g. model transformations) on inconsistent models likely introduces further errors Khelladi \BOthers. (\APACyear2019). Finally, many tools for model management are based on formal methods, which are not yet compatible with tolerant concepts Decker \BBA Martinenghi (\APACyear2008).

5.2 Uncertainty

An important argument for modelling with uncertainty is that it represents real-world scenarios more accurately. The input data and the behaviour of CPSs and adaptive systems is imprecise, e.g. their sensors and actuators provide the system with imprecise data, and this should be reflected in a model of the system Kyrkou \BOthers. (\APACyear2015); Mayerhofer \BOthers. (\APACyear2016); Goldsby \BBA Cheng (\APACyear2008); Vallecillo \BOthers. (\APACyear2016); Camilli \BOthers. (\APACyear2018); Prasetya \BBA Klomp (\APACyear2019); Bamgboye \BOthers. (\APACyear2018); Ali \BBA Yue (\APACyear2015); Camilli \BOthers. (\APACyear2017); Esfahani \BBA Malek (\APACyear2010). Similarly, information might not be available in distributed systems, or not accessible due to security restrictions or authentication problems Gao \BOthers. (\APACyear2011). In software and requirements engineering processes, uncertainty plays an important role, especially in early phases. When designing complex and widely heterogeneous systems, multiple stakeholders are involved, whose understanding of the final result may be incomplete Honda \BOthers. (\APACyear2013\APACexlab\BCnt1); Förster \BBA Schneider (\APACyear2010); Famelis \BOthers. (\APACyear2015); Famelis \BBA Santosa (\APACyear2013); Camilli \BOthers. (\APACyear2018); Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1); Ramirez \BOthers. (\APACyear2012); Jureta \BOthers. (\APACyear2010); Hansen \BBA Thomsen (\APACyear1999); Famelis \BOthers. (\APACyear2013); DeVries \BBA Cheng (\APACyear2017); Garlan (\APACyear2010); Camilli \BBA Russo (\APACyear2020); Eramo \BOthers. (\APACyear2014). Additionally, this incomplete information makes it necessary to continuously adapt the development process and the requirements Cheng \BOthers. (\APACyear2009); Mens \BOthers. (\APACyear2006); Salay, Chechik\BCBL \BBA Horkoff (\APACyear2012); Camilli \BOthers. (\APACyear2018); Ramirez \BOthers. (\APACyear2012); Garlan (\APACyear2010); Famelis \BOthers. (\APACyear2012\APACexlab\BCnt2); Salay, Chechik\BCBL \BBA Gorzny (\APACyear2012). Likewise, removing uncertainty too early can force the designer to commit to premature decisions that can increase cost and efforts to remove resulting errors later Famelis \BOthers. (\APACyear2013); Eramo \BOthers. (\APACyear2014), while ignoring uncertainty completely decreases the overall quality of the software Ibrahim \BOthers. (\APACyear2009); Esfahani \BBA Malek (\APACyear2010). An obvious alternative to model uncertainty is to list each alternative value explicitly, but this can quickly become infeasible. Uncertainty is an elegant way to encode alternatives and non-determinism, while still keeping models manageable Brambilla \BOthers. (\APACyear2017); Bucaioni \BOthers. (\APACyear2016); Eramo \BOthers. (\APACyear2015); Reder \BBA Egyed (\APACyear2013). Indeed, uncertain values are probably easier to maintain than a large set of alternatives Bucaioni \BOthers. (\APACyear2016); Ghezzi \BOthers. (\APACyear2013). In case some design choices are more likely to be applied than others, uncertainty is also useful to express these varying probabilities quantitatively Ou \BOthers. (\APACyear2009). From a practical point of view, uncertainty is often indirectly added to models via informal annotations in case its direct expression is not supported. Therefore, enabling the designer to model uncertainty in the given formal notation improves the verification and validation of such models Salay, Chechik\BCBL \BBA Gorzny (\APACyear2012).

Handling uncertainty, however, can also increase development cost as the encoded set of alternatives - which takes all possible combinations of values into account - can be much larger than the set of possible options in practice Cheng \BOthers. (\APACyear2009); Hansen \BBA Thomsen (\APACyear1999); Ibrahim \BOthers. (\APACyear2009). Following the same argument, the model space grows exponentially with the degree of uncertainty, which can cause performance problems for larger model sizes Ou \BOthers. (\APACyear2009); Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1); Esfahani \BBA Malek (\APACyear2010). Even though uncertainty is an appropriate way of expressing probabilities, it can be difficult to realistically quantify uncertainty measures, as empirical tests for these measures are often missing or cannot be conducted at all Ou \BOthers. (\APACyear2009); Esfahani \BBA Malek (\APACyear2010). Finally, operations on models are usually designed for single models, whereas uncertain models encode a whole set, restricting the applicability of standard tooling Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1).

5.3 Flexibility

It is possible that multiple consistent solutions exist, which deviate in their quality. As it is hard to specify which solution should be taken, the system should provide the flexibility to let the user make this final decision B. Wang \BOthers. (\APACyear2010). To keep the complexity of a system manageable, software is usually developed with an idealised environment in mind. However, the system is also expected to react robustly to environment changes and unforeseen circumstances at runtime Fraj \BOthers. (\APACyear2017); Wolfe \BOthers. (\APACyear2009); Hansen \BBA Thomsen (\APACyear1999); He \BOthers. (\APACyear2015). In application domains such as product line engineering, “hard constraints” can reduce the potential of the modelling language and therefore restrict the scope of action for the designer Barreiros \BBA Moreira (\APACyear2014); Aquino (\APACyear2009). In the area of model-metamodel co-evolution, some flexibility is necessary for a modelling tool to be appropriate for practical use. The temporary loss of metamodel conformance should not lead to a situation where the model cannot be modified or even loaded in the respective editor Rose \BOthers. (\APACyear2009); Hili \BBA Sottet (\APACyear2017); Hili (\APACyear2016); Atkinson \BOthers. (\APACyear2015); Hebig \BOthers. (\APACyear2016); Zolotas \BOthers. (\APACyear2016); Sottet \BBA Biri (\APACyear2016). Finally, the result of a model transformation is often not unique, requiring a flexible encoding Callow \BBA Kalawsky (\APACyear2013); Eramo \BOthers. (\APACyear2014).

A few arguments can also be found that question the benefits of flexibility. As tools are typically not built by the intended users, the developer might have a different understanding of flexibility, such that the user may ignore or even disregard any support for it Honda \BOthers. (\APACyear2013\APACexlab\BCnt2). The more flexibility is added to a system, the more complexity is involved as well, which can end up in a misinterpretation of functionality or a loss of overview while developing and maintaining the tool Shan \BBA Zhu (\APACyear2004); Farias \BOthers. (\APACyear2012); Famelis \BBA Santosa (\APACyear2013) Finally, in case of errors and other inconsistencies, software developers are currently used to instant feedback from IDEs for general purpose languages, and will probably expect similar behaviour from modelling tools. Transitioning to tolerant tooling will therefore require a certain retraining of users to ensure acceptance, and it is still unclear how challenging this will be in practice Egyed (\APACyear2006).

6 Result Analysis

This section provides an overview of aggregated meta-data of the considered sources, before directions for future research are sketched, which can be motivated by this SLR.

The distribution of all sources in the database, i.e. all core papers and all sources cited by them, is depicted in Fig. 6, whereby ten sources published before 1975 are not captured in the diagram. In total, 268 core papers, 1146 other papers at SE venues and 2055 other sources were found in the initial search step. The median (mean) publication year is 2010.5 (2009.78) for core papers, 2007 (2005.87) for other papers at SE venues and 2006 (2004.35) for the remaining sources. It follows that filtering the additional sources was necessary to keep the amount of work manageable, and also that being published at a venue listed as research area 0803 (software engineering) is a useful indicator for increased relevance; at least one third of the additional sources was published at such a venue. The differences between core papers and other sources with respect to the average publication year can be explained by the applied snowballing technique, by which only sources released prior to the initial source can be found. Furthermore, the set of sources published at non-SE venues include standard references in form of books and journal articles, which is probably the reason why the papers from SE venues are slightly newer on average.

When taking only those sources into account that were later identified as being relevant for answering the research questions, the majority of sources originates from the set of core papers (cf. Fig. 7). Besides 114 of the core papers, 23 papers published at SE venues and 20 other sources were classified as relevant. Compared to the full corpus, the relevant papers are newer on average: The median (mean) publication year is 2011 (2011.05) for core papers, 2012 (2011.08) for publications at SE venues, and 2012 (2011.29) for the remaining relevant sources. An explanation can be that the search terms are used in a different meaning more frequently in older sources, according to our experience. Furthermore, as the research field MDE became popular along with the emergence of the UML in the late 1990s, sources published before can only be relevant for our purposes if they describe transferable concepts or examples from other domains.

Table 3 gives an overview of the number of relevant papers per venue, listing those venues with at least four relevant papers. As this SLR deals with a subtopic of MDE, finding the MODELS conference at the top of the ranking is a result one would expect. Five papers published at co-located events were relevant for this SLR as well. ICSE and ASE as two top-ranked SE conferences in the list underpin the topic’s relevance for a broader audience. The appearance of important conferences for more specialised research fields, such as requirements engineering (RE), software language design (SLE) and software testing (ICST), shows that fault-tolerance concerns the entire software development process. The remaining well-known SE venues COMPSAC, SEKE, APSEC and FASE complete the list of venues with 4 or more relevant papers.

Rank	Acronym	Venue	#
1	MODELS	Model Driven Engineering: Languages and Systems	20
2	ICSE	International Conference on Software Engineering	15
3	COMPSAC	Computer Software and Applications Conference	10
4	ASE	Automated Software Engineering	8
5	SEKE	Software Engineering and Knowledge Engineering	7
6	FASE	Fundamental Approaches to Software Engineering	6
7	APSEC	Asia-Pacific Software Engineering Conference	5
7	RE	Intern. Conference on Requirements Engineering	5
7	-	MODELS Satellite Events	5
10	SLE	Software Language Engineering	4
10	ICST	International Conference on Software Testing	4

Table 3: Top 10 conferences by number of relevant papers

Although as a result of this SLR, many thorough definitions, useful examples and convincing arguments for tolerance in MDE could be extracted, a need for further research became apparent simultaneously. As tolerance was mostly defined intuitively, an extended formal framework (e.g. for softening domain constraints) would be helpful to prove properties of tolerant systems. This includes quantitative measures for (in)consistency, as well as quality criteria for the intermediate and final model states to assess the utility of proposed approaches. Up to now, it remains also unclear when exactly consistency shall be restored, up to which point errors can be tolerated, and how to deal with conflicting changes that were made in the meantime. Especially for more than two models, consistency restoration is a non-trivial problem because removing errors in one model can introduce other errors in different places. Further user studies could show to which extent user interaction is required to resolve such conflicts, and which restoration actions can be performed automatically. Several authors pointed out that some faults are too serious to be tolerated, but still strategies are needed to assess the severity of errors in a model, though. While model transformations in presence of uncertainty are already investigated, fault-tolerant consistency management is still an unsolved issue. Finally, although tolerance and uncertainty could be differentiated in spite of their common goal, it would be useful to specify which of the two concepts is more helpful in which particular scenarios.

7 Related Work

Studies that provide a structured overview of existing work on a particular topic are often conducted as SLRs B. Kitchenham (\APACyear2004) or as mapping studies Petersen \BOthers. (\APACyear2008). SLRs are a secondary study that identifies, analyses and interprets all available information related to one or more research questions. SLRs follow a predefined review protocol, such that the process of retrieving results is transparent and the introduced bias is minimised. Mapping studies categorise existing work, often leading to a visual mapping of categories that supports the understanding of what is already addressed in a specific domain.

Several of these studies of either type have been conducted in the MDE domain and related fields. Modelling languages were investigated with a focus on the Systems Modeling Language (SysML) language Wolny \BOthers. (\APACyear2020), the QVT Operational (QVTo) standard Gerpheide \BOthers. (\APACyear2014, \APACyear2016), and the application of modelling in Industry 4.0 Wortmann \BOthers. (\APACyear2020, \APACyear2017). Further MDE-related work investigates literature on models at runtime Szvetits \BBA Zdun (\APACyear2016), software testing process models Vukovic \BOthers. (\APACyear2018), articles that appeared in the Journal of Software and Systems Modelling Gray \BBA Rumpe (\APACyear2016), and quality in MDE Goulão \BOthers. (\APACyear2016). In the requirements engineering domain, studies on software tooling for requirement elicitation Iqbal \BOthers. (\APACyear2019) and software testing in the context of agile software development Coutinho \BOthers. (\APACyear2019) have been presented. For software product lines, existing work on the automated analysis of feature models Galindo \BOthers. (\APACyear2019), variability management Galster \BOthers. (\APACyear2014), and tool support Bashroush \BOthers. (\APACyear2017) has been already investigated. Context modelling Koç \BOthers. (\APACyear2014) and environment modelling Siavashi \BBA Truscan (\APACyear2015) are further topics of existing SLRs.

Multiple studies on consistency in modelling languages have been already presented. Awadid et al. Awadid \BBA Nurcan (\APACyear2019, \APACyear2016) composed an overview of consistency requirements of business process models by proposing a framework for the categorization of approaches and a road-map for future research on consistency requirements elicitation and management. The work of Muram et al. Muram \BOthers. (\APACyear2017) takes consistency checking of software behavioural models into account. Seven main categories for consistency checking in this domain were identified, and suggestions for future research in this direction were proposed. Hoisl et al. Hoisl \BBA Sobernig (\APACyear2015) conducted a literature review on consistency rules for UML-based language models, discussing frequently-named defects of such models and demanding more tool support for enforcing consistency rules in this setting. All of these studies focus on a sub-domain of MDE and do not take tolerance or uncertainty into account.

Only two studies on existing work relating fault-tolerance to software engineering problems could be found. Nascimento et al. Nascimento \BOthers. (\APACyear2014) analysed literature on the design of fault-tolerant Service-Oriented Architecture (SOA) using design diversity, deriving guidelines for fault-tolerant SOA design and proposing a taxonomy for useful techniques in this respect. A mapping study for fault-tolerant Internet of Things (IoT) applications Moghaddam \BBA Muccini (\APACyear2019) identifies key factors for tolerant systems, including the use of micro-services and the distribution of IoT components. Both studies are neither directly related to MDE nor address the problem of maintaining consistency.

In a study combining an SLR, semi-structured interviews, and an empirical evaluation, Marinho et al. M. Marinho \BOthers. (\APACyear2018); M\BPBIL\BPBIM. Marinho \BOthers. (\APACyear2015) propose and evaluate techniques to distinguish risks and uncertainties to reduce the latter in software projects. Salih et al. Salih \BOthers. (\APACyear2017) provide an overview of existing work on uncertainty involved in requirements engineering via a categorisation of relevant sources, while several questions are left open. Measurement uncertainty was studied in depth by da Silva Hack et al. da Silva Hack \BBA ten Caten (\APACyear2012), resulting in a classification of approaches and a list of methods for calculating uncertainty. However, these treatments focus solely on uncertainty, whereas tolerance and software modelling are not considered.

As previously mentioned, SLRs in computer science often lack adequate tool support; this issue has been identified and discussed by existing work. Götz proposes a tool for processing the findings of SLRs Götz (\APACyear2018), which enables the user to assign the relevant papers to formed categories, such that diagrams can be generated that visualize the characteristic values for one or two categories. The tool supports SLRs in a later phase, though, as the list of relevant sources is required as input data. The SLR-Tool by Fernández-Sáez et al. Fernández-Sáez \BOthers. (\APACyear2010) supports the process of conducting SLRs in different phases. Relevant meta-data can be stored for each source, a classification scheme can be created, and diagrams for result visualisation can be exported. In contrast to our tool-chain, the sources have to be imported manually in the beginning, and support for automated snowballing is not provided.

8 Conclusion and Future Work

We presented the results of an SLR on tolerance in MDE, which took 157 relevant sources into account. The key terms consistency, tolerance, and uncertainty were defined and represented in feature models, such that salient differences and commonalities between tolerance and uncertainty could be pointed out. Typical use cases for tolerant and uncertain modelling were sketched, and benefits and challenges of the respective concepts were discussed. To ease the reproducibility of our results and to support future SLRs in computer science, we proposed a model-driven tool-chain based on open-source components under active development.

Although some relevant journal articles and workshop papers were identified by the snowballing step, the set of sources can be further extended by more sources published at other venues. Since the CORE2020 journal ranking was recently made available, we plan to extend the literature review towards journal papers following the search strategies presented in this paper. To the same end, other research databases could be considered as well. The review has shown that there are indeed useful examples for applying tolerant concepts in MDE; a systematic benchmark for comparing tolerant approaches is, however, still an open issue.

Acknowledgements

We would like to thank all anonymous reviewers for their helpful feedback that improved the quality of this SLR.

References

Ali \BBA Yue (\APACyear2015) \APACinsertmetastarU-Test:Evolving{APACrefauthors}Ali, S.\BCBT \BBA Yue, T. \APACrefYearMonthDay201505. \BBOQ\APACrefatitleEvolving, Modelling and Testing Realistic Uncertain Behaviours of Cyber-Physical Systems Evolving, modelling and testing realistic uncertain behaviours of cyber-physical systems.\BBCQ \BIn \APACrefbtitleICST 2015. ICST 2015. \PrintBackRefs\CurrentBib
Aquino (\APACyear2009) \APACinsertmetastarAddingflexibilityinthemodel-drivenengineeringofuserinterfaces{APACrefauthors}Aquino, N. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleAdding flexibility in the model-driven engineering of user interfaces Adding flexibility in the model-driven engineering of user interfaces.\BBCQ \BIn \APACrefbtitleEICS 2009 EICS 2009 (\BPGS 329–332). \PrintBackRefs\CurrentBib
Atkinson \BOthers. (\APACyear2015) \APACinsertmetastarAmultilevelapproachtomodelinglanguageextensionintheEnterpriseSystemsDomain{APACrefauthors}Atkinson, C., Gerbig, R.\BCBL \BBA Fritzsche, M. \APACrefYearMonthDay201501. \BBOQ\APACrefatitleA multi-level approach to modeling language extension in the Enterprise Systems Domain A multi-level approach to modeling language extension in the enterprise systems domain.\BBCQ \APACjournalVolNumPagesInformation Systems54. \PrintBackRefs\CurrentBib
Awadid \BBA Nurcan (\APACyear2016) \APACinsertmetastarAwadid2016{APACrefauthors}Awadid, A.\BCBT \BBA Nurcan, S. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleA Systematic Literature Review of Consistency Among Business Process Models A systematic literature review of consistency among business process models.\BBCQ \BIn R. Schmidt, W. Guédria, I. Bider\BCBL \BBA S. Guerreiro (\BEDS), \APACrefbtitleBPMDS 2016 BPMDS 2016 (\BVOL 248, \BPGS 175–195). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Awadid \BBA Nurcan (\APACyear2019) \APACinsertmetastarAwadid2019{APACrefauthors}Awadid, A.\BCBT \BBA Nurcan, S. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleConsistency requirements in business process modeling: a thorough overview Consistency requirements in business process modeling: a thorough overview.\BBCQ \APACjournalVolNumPagesSoftware and Systems Modeling1821097–1115. \PrintBackRefs\CurrentBib
Babikian \BOthers. (\APACyear2020) \APACinsertmetastarAutomatedGenerationofConsistentGraphModelswithFirst-OrderLogicTheoremProvers{APACrefauthors}Babikian, A\BPBIA., Semeráth, O.\BCBL \BBA Varró, D. \APACrefYearMonthDay2020. \BBOQ\APACrefatitleAutomated Generation of Consistent Graph Models with First-Order Logic Theorem Provers Automated generation of consistent graph models with first-order logic theorem provers.\BBCQ \BIn \APACrefbtitleFASE 2020 FASE 2020 (\BPGS 441–461). \PrintBackRefs\CurrentBib
Bagheri \BBA Ghorbani (\APACyear2007) \APACinsertmetastarOntheCollaborativeDevelopmentofPara-ConsistentConceptualModels.{APACrefauthors}Bagheri, E.\BCBT \BBA Ghorbani, A\BPBIA. \APACrefYearMonthDay2007. \BBOQ\APACrefatitleOn the Collaborative Development of Para-Consistent Conceptual Models On the collaborative development of para-consistent conceptual models.\BBCQ \BIn \APACrefbtitleQSIC 2007 QSIC 2007 (\BPGS 336–341). \PrintBackRefs\CurrentBib
Balzer (\APACyear1991) \APACinsertmetastarToleratingInconsistency.{APACrefauthors}Balzer, R. \APACrefYearMonthDay1991. \BBOQ\APACrefatitleTolerating Inconsistency Tolerating inconsistency.\BBCQ \BIn \APACrefbtitleICSE 1991 ICSE 1991 (\BPGS 158–165). \PrintBackRefs\CurrentBib
Bamgboye \BOthers. (\APACyear2018) \APACinsertmetastarTowardsModellingandReasoningAboutUncertainDataofSensorMeasurementsforDecisionSupportinSmartSpaces.{APACrefauthors}Bamgboye, O., Liu, X.\BCBL \BBA Cruickshank, P. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleTowards Modelling and Reasoning About Uncertain Data of Sensor Measurements for Decision Support in Smart Spaces Towards modelling and reasoning about uncertain data of sensor measurements for decision support in smart spaces.\BBCQ \BIn \APACrefbtitleCOMPSAC 2018 COMPSAC 2018 (\BPGS 744–749). \PrintBackRefs\CurrentBib
Barreiros \BBA Moreira (\APACyear2014) \APACinsertmetastarFlexibleModelingandProductDerivationinSoftwareProductLines.{APACrefauthors}Barreiros, J.\BCBT \BBA Moreira, A. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleFlexible Modeling and Product Derivation in Software Product Lines Flexible modeling and product derivation in software product lines.\BBCQ \BIn \APACrefbtitleSEKE 2013 SEKE 2013 (\BPGS 67–70). \PrintBackRefs\CurrentBib
Bashroush \BOthers. (\APACyear2017) \APACinsertmetastarBashroush2017{APACrefauthors}Bashroush, R., Garba, M., Rabiser, R., Groher, I.\BCBL \BBA Botterweck, G. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleCASE Tool Support for Variability Management in Software Product Lines CASE tool support for variability management in software product lines.\BBCQ \APACjournalVolNumPagesACM Comput. Surv.50114:1–14:45. \PrintBackRefs\CurrentBib
Blanc \BOthers. (\APACyear2008) \APACinsertmetastarDetectingmodelinconsistencythroughoperation-basedmodelconstruction.{APACrefauthors}Blanc, X., Mounier, I., Mougenot, A.\BCBL \BBA Mens, T. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleDetecting model inconsistency through operation-based model construction Detecting model inconsistency through operation-based model construction.\BBCQ \BIn \APACrefbtitleICSE 2008 ICSE 2008 (\BPGS 511–520). \PrintBackRefs\CurrentBib
Brambilla \BOthers. (\APACyear2017) \APACinsertmetastarEnhancingFlexibilityinUserInteractionModelingbyAddingDesignUncertaintytoIFML.{APACrefauthors}Brambilla, M., Eramo, R., Pierantonio, A., Rosa, G.\BCBL \BBA Umuhoza, E. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleEnhancing Flexibility in User Interaction Modeling by Adding Design Uncertainty to IFML Enhancing flexibility in user interaction modeling by adding design uncertainty to IFML.\BBCQ \BIn \APACrefbtitleMODELS 2017, Workshop Proceedings MODELS 2017, workshop proceedings (\BPGS 435–440). \PrintBackRefs\CurrentBib
Bucaioni \BOthers. (\APACyear2016) \APACinsertmetastarHandlingUncertaintyinAutomaticallyGeneratedImplementationModelsintheAutomotiveDomain{APACrefauthors}Bucaioni, A., Cicchetti, A., Ciccozzi, F., Mubeen, S., Pierantonio, A.\BCBL \BBA Sjödin, M. \APACrefYearMonthDay2016Aug. \BBOQ\APACrefatitleHandling Uncertainty in Automatically Generated Implementation Models in the Automotive Domain Handling uncertainty in automatically generated implementation models in the automotive domain.\BBCQ \BIn \APACrefbtitleSEAA 2016 SEAA 2016 (\BPG 173-180). \PrintBackRefs\CurrentBib
Burdusel \BOthers. (\APACyear2019) \APACinsertmetastarAutomaticGenerationofAtomicConsistencyPreservingSearchOperatorsforSearch-BasedModelEngineering{APACrefauthors}Burdusel, A., Zschaler, S.\BCBL \BBA John, S. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleAutomatic Generation of Atomic Consistency Preserving Search Operators for Search-Based Model Engineering Automatic generation of atomic consistency preserving search operators for search-based model engineering.\BBCQ \BIn \APACrefbtitleMODELS 2019 MODELS 2019 (\BPGS 106–116). \PrintBackRefs\CurrentBib
Callow \BBA Kalawsky (\APACyear2013) \APACinsertmetastarAsatisficingbidirectionalmodeltransformationengineusingmixedintegerlinearprogramming{APACrefauthors}Callow, G.\BCBT \BBA Kalawsky, R. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleA Satisficing Bi-Directional Model Transformation Engine using Mixed Integer Linear Programming A satisficing bi-directional model transformation engine using mixed integer linear programming.\BBCQ \APACjournalVolNumPagesJ. Object Technol.1211: 1–43. \PrintBackRefs\CurrentBib
Camilli \BOthers. (\APACyear2018) \APACinsertmetastarOnlineModel-BasedTestingunderUncertainty.{APACrefauthors}Camilli, M., Bellettini, C., Gargantini, A.\BCBL \BBA Scandurra, P. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleOnline Model-Based Testing under Uncertainty Online model-based testing under uncertainty.\BBCQ \BIn \APACrefbtitleISSRE 2018 ISSRE 2018 (\BPGS 36–46). \PrintBackRefs\CurrentBib
Camilli \BOthers. (\APACyear2017) \APACinsertmetastarTowardsInverseUncertaintyQuantificationinSoftwareDevelopmentShortPaper{APACrefauthors}Camilli, M., Gargantini, A., Scandurra, P.\BCBL \BBA Bellettini, C. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleTowards Inverse Uncertainty Quantification in Software Development (Short Paper) Towards inverse uncertainty quantification in software development (short paper).\BBCQ \BIn A. Cimatti \BBA M. Sirjani (\BEDS), \APACrefbtitleSEFM 2017 SEFM 2017 (\BVOL 10469, \BPGS 375–381). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Camilli \BBA Russo (\APACyear2020) \APACinsertmetastarModel-BasedTestingUnderParametricVariabilityofUncertainBeliefs{APACrefauthors}Camilli, M.\BCBT \BBA Russo, B. \APACrefYearMonthDay2020. \BBOQ\APACrefatitleModel-Based Testing Under Parametric Variability of Uncertain Beliefs Model-based testing under parametric variability of uncertain beliefs.\BBCQ \BIn \APACrefbtitleSEFM 2020 SEFM 2020 (\BPGS 175–192). \PrintBackRefs\CurrentBib
Cheng \BOthers. (\APACyear2009) \APACinsertmetastarAGoal-BasedModelingApproachtoDevelopRequirementsofanAdaptiveSystemwithEnvironmentalUncertainty.{APACrefauthors}Cheng, B\BPBIH\BPBIC., Sawyer, P., Bencomo, N.\BCBL \BBA Whittle, J. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleA Goal-Based Modeling Approach to Develop Requirements of an Adaptive System with Environmental Uncertainty A goal-based modeling approach to develop requirements of an adaptive system with environmental uncertainty.\BBCQ \BIn \APACrefbtitleMODELS 2009 MODELS 2009 (\BPGS 468–483). \PrintBackRefs\CurrentBib
Cicchetti \BOthers. (\APACyear2010) \APACinsertmetastarJTLabidirectionalandchangepropagatingtransformationlanguage{APACrefauthors}Cicchetti, A., Ruscio, D\BPBID., Eramo, R.\BCBL \BBA Pierantonio, A. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleJTL: A Bidirectional and Change Propagating Transformation Language JTL: A bidirectional and change propagating transformation language.\BBCQ \BIn \APACrefbtitleSLE 2010 SLE 2010 (\BPGS 183–202). \PrintBackRefs\CurrentBib
Ciraci \BOthers. (\APACyear2012) \APACinsertmetastarAnApproachforDetectingInconsistenciesbetweenBehavioralModelsoftheSoftwareArchitectureandtheCode.{APACrefauthors}Ciraci, S., Sözer, H.\BCBL \BBA Tekinerdogan, B. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleAn Approach for Detecting Inconsistencies between Behavioral Models of the Software Architecture and the Code An approach for detecting inconsistencies between behavioral models of the software architecture and the code.\BBCQ \BIn \APACrefbtitleCOMPSAC 2012 COMPSAC 2012 (\BPGS 257–266). \PrintBackRefs\CurrentBib
Coutinho \BOthers. (\APACyear2019) \APACinsertmetastarCoutinho2019{APACrefauthors}Coutinho, J\BPBIC\BPBIS., de L. Andrade, W.\BCBL \BBA Machado, P\BPBID\BPBIL. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleRequirements Engineering and Software Testing in Agile Methodologies: a Systematic Mapping Requirements engineering and software testing in agile methodologies: a systematic mapping.\BBCQ \BIn I. do Carmo Machado, R. Souza, R\BPBIS\BPBIP. Maciel\BCBL \BBA C. Sant’Anna (\BEDS), \APACrefbtitleSBES 2019 SBES 2019 (\BPGS 322–331). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
da Silva Hack \BBA ten Caten (\APACyear2012) \APACinsertmetastarHack2012{APACrefauthors}da Silva Hack, P.\BCBT \BBA ten Caten, C\BPBIS. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleMeasurement Uncertainty: Literature Review and Research Trends Measurement uncertainty: Literature review and research trends.\BBCQ \APACjournalVolNumPagesIEEE Trans. Instrumentation and Measurement6182116–2124. \PrintBackRefs\CurrentBib
Dávid \BOthers. (\APACyear\bibnodate) \APACinsertmetastarModelingandEnactmentSupportforEarlyDetectionofInconsistenciesinEngineeringProcesses.{APACrefauthors}Dávid, I., Meyers, B., Vanherpen, K., Tendeloo, Y\BPBIV., Berx, K.\BCBL \BBA Vangheluwe, H. \APACrefYearMonthDay\bibnodate. \BBOQ\APACrefatitleModeling and Enactment Support for Early Detection of Inconsistencies in Engineering Processes Modeling and enactment support for early detection of inconsistencies in engineering processes.\BBCQ \BIn \APACrefbtitle(MODELS 2017, Workshop Proceedings (MODELS 2017, workshop proceedings (\BPGS 145–154). \PrintBackRefs\CurrentBib
Decker (\APACyear2011) \APACinsertmetastarDataQualityMaintenancebyIntegrity-PreservingRepairsthatTolerateInconsistency.{APACrefauthors}Decker, H. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleData Quality Maintenance by Integrity-Preserving Repairs that Tolerate Inconsistency Data quality maintenance by integrity-preserving repairs that tolerate inconsistency.\BBCQ \BIn \APACrefbtitleQSIC 2011 QSIC 2011 (\BPGS 192–197). \PrintBackRefs\CurrentBib
Decker (\APACyear2017) \APACinsertmetastarDecker2017{APACrefauthors}Decker, H. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleInconsistency-Tolerant Database Repairs and Simplified Repair Checking by Measure-Based Integrity Checking Inconsistency-tolerant database repairs and simplified repair checking by measure-based integrity checking.\BBCQ \APACjournalVolNumPagesTrans. Large Scale Data Knowl. Centered Syst.34153–183. \PrintBackRefs\CurrentBib
Decker \BBA Martinenghi (\APACyear2008) \APACinsertmetastarClassifyingintegritycheckingmethodswithregardtoinconsistencytolerance.{APACrefauthors}Decker, H.\BCBT \BBA Martinenghi, D. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleClassifying integrity checking methods with regard to inconsistency tolerance Classifying integrity checking methods with regard to inconsistency tolerance.\BBCQ \BIn \APACrefbtitlePPDP 2008 PPDP 2008 (\BPGS 195–204). \PrintBackRefs\CurrentBib
Decker \BBA Martinenghi (\APACyear2011) \APACinsertmetastarDecker2011{APACrefauthors}Decker, H.\BCBT \BBA Martinenghi, D. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleInconsistency-Tolerant Integrity Checking Inconsistency-tolerant integrity checking.\BBCQ \APACjournalVolNumPagesIEEE Trans. Knowl. Data Eng.232218–234. \PrintBackRefs\CurrentBib
Demuth \BOthers. (\APACyear2016) \APACinsertmetastarIntroducingTraceabilityandConsistencyCheckingforChangeImpactAnalysisacrossEngineeringToolsinanAutomationSolutionCompanyAnExperienceReport{APACrefauthors}Demuth, A., Kretschmer, R., Egyed, A.\BCBL \BBA Maes, D. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleIntroducing Traceability and Consistency Checking for Change Impact Analysis across Engineering Tools in an Automation Solution Company: An Experience Report Introducing traceability and consistency checking for change impact analysis across engineering tools in an automation solution company: An experience report.\BBCQ \BIn \APACrefbtitleICSME 2016 ICSME 2016 (\BPGS 529–538). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
de Souza \BOthers. (\APACyear2003) \APACinsertmetastarUsingCritiquingSystemsforInconsistencyDetectioninSoftwareEngineeringModels.{APACrefauthors}de Souza, C\BPBIR\BPBIB., Oliveira, H\BPBIL\BPBIR., da Rocha, C\BPBIR\BPBIP., Gonçalves, K\BPBIM.\BCBL \BBA Redmiles, D\BPBIF. \APACrefYearMonthDay2003. \BBOQ\APACrefatitleUsing Critiquing Systems for Inconsistency Detection in Software Engineering Models Using critiquing systems for inconsistency detection in software engineering models.\BBCQ \BIn \APACrefbtitleSEKE 2003 SEKE 2003 (\BPGS 196–203). \PrintBackRefs\CurrentBib
DeVries \BBA Cheng (\APACyear2016) \APACinsertmetastarAutomaticdetectionofincompleterequirementsviasymbolicanalysis{APACrefauthors}DeVries, B.\BCBT \BBA Cheng, B\BPBIH\BPBIC. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleAutomatic detection of incomplete requirements via symbolic analysis Automatic detection of incomplete requirements via symbolic analysis.\BBCQ \BIn B. Baudry \BBA B. Combemale (\BEDS), \APACrefbtitleMODELS 2016 MODELS 2016 (\BPGS 385–395). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
DeVries \BBA Cheng (\APACyear2017) \APACinsertmetastarUsingModelsatRunTimetoDetectIncompleteandInconsistentRequirements.{APACrefauthors}DeVries, B.\BCBT \BBA Cheng, B\BPBIH\BPBIC. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleUsing Models at Run Time to Detect Incomplete and Inconsistent Requirements Using models at run time to detect incomplete and inconsistent requirements.\BBCQ \BIn \APACrefbtitle(MODELS 2017, Workshop Proceedings (MODELS 2017, workshop proceedings (\BPGS 201–209). \PrintBackRefs\CurrentBib
Ebnenasir \BBA Cheng (\APACyear2007) \APACinsertmetastarPattern-BasedModelingandAnalysisofFailsafeFault-ToleranceinUML.{APACrefauthors}Ebnenasir, A.\BCBT \BBA Cheng, B\BPBIH\BPBIC. \APACrefYearMonthDay2007. \BBOQ\APACrefatitlePattern-Based Modeling and Analysis of Failsafe Fault-Tolerance in UML Pattern-based modeling and analysis of failsafe fault-tolerance in UML.\BBCQ \BIn \APACrefbtitleHASE 2007 HASE 2007 (\BPGS 275–282). \PrintBackRefs\CurrentBib
Ebnenasir \BOthers. (\APACyear2006) \APACinsertmetastarUseCase-BasedModelingandAnalysisofFailsafeFault-Tolerance.{APACrefauthors}Ebnenasir, A., Cheng, B\BPBIH\BPBIC.\BCBL \BBA Konrad, S. \APACrefYearMonthDay2006. \BBOQ\APACrefatitleUse Case-Based Modeling and Analysis of Failsafe Fault-Tolerance Use case-based modeling and analysis of failsafe fault-tolerance.\BBCQ \BIn \APACrefbtitleRE 2006 RE 2006 (\BPGS 336–337). \PrintBackRefs\CurrentBib
Egyed (\APACyear2006) \APACinsertmetastarInstantconsistencycheckingfortheUML{APACrefauthors}Egyed, A. \APACrefYearMonthDay2006. \BBOQ\APACrefatitleInstant consistency checking for the UML Instant consistency checking for the UML.\BBCQ \BIn L\BPBIJ. Osterweil, H\BPBID. Rombach\BCBL \BBA M\BPBIL. Soffa (\BEDS), \APACrefbtitleICSE 2006 ICSE 2006 (\BPGS 381–390). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Egyed (\APACyear2007\APACexlab\BCnt1) \APACinsertmetastarFixingInconsistenciesinUMLDesignModels.{APACrefauthors}Egyed, A. \APACrefYearMonthDay2007\BCnt1. \BBOQ\APACrefatitleFixing Inconsistencies in UML Design Models Fixing inconsistencies in UML design models.\BBCQ \BIn \APACrefbtitleICSE 2007 ICSE 2007 (\BPGS 292–301). \PrintBackRefs\CurrentBib
Egyed (\APACyear2007\APACexlab\BCnt2) \APACinsertmetastarUML/Analyzer-AToolfortheInstantConsistencyCheckingofUMLModels.{APACrefauthors}Egyed, A. \APACrefYearMonthDay2007\BCnt2. \BBOQ\APACrefatitleUML/Analyzer: A Tool for the Instant Consistency Checking of UML Models Uml/analyzer: A tool for the instant consistency checking of UML models.\BBCQ \BIn \APACrefbtitleICSE 2007 ICSE 2007 (\BPGS 793–796). \PrintBackRefs\CurrentBib
Egyed (\APACyear2011) \APACinsertmetastarAutomaticallyDetectingandTrackingInconsistenciesinSoftwareDesignModels{APACrefauthors}Egyed, A. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleAutomatically Detecting and Tracking Inconsistencies in Software Design Models Automatically detecting and tracking inconsistencies in software design models.\BBCQ \APACjournalVolNumPagesIEEE Trans. Software Eng.372188–204. \PrintBackRefs\CurrentBib
Egyed \BOthers. (\APACyear2011) \APACinsertmetastarFineTuningModelTransformationChangePropagationinContextofConsistencyCompletenessandHumanGuidance.{APACrefauthors}Egyed, A., Demuth, A., Ghabi, A., Lopez-Herrejon, R\BPBIE., Mäder, P., Nöhrer, A.\BCBL \BBA Reder, A. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleFine-Tuning Model Transformation: Change Propagation in Context of Consistency, Completeness, and Human Guidance Fine-tuning model transformation: Change propagation in context of consistency, completeness, and human guidance.\BBCQ \BIn \APACrefbtitleICMT 2011, Proceedings ICMT 2011, proceedings (\BPGS 1–14). \PrintBackRefs\CurrentBib
Egyed \BOthers. (\APACyear2008) \APACinsertmetastarGeneratingandEvaluatingChoicesforFixingInconsistenciesinUMLDesignModels.{APACrefauthors}Egyed, A., Letier, E.\BCBL \BBA Finkelstein, A. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleGenerating and Evaluating Choices for Fixing Inconsistencies in UML Design Models Generating and evaluating choices for fixing inconsistencies in UML design models.\BBCQ \BIn \APACrefbtitleASE 2008 ASE 2008 (\BPGS 99–108). \PrintBackRefs\CurrentBib
Ehrig \BOthers. (\APACyear2008) \APACinsertmetastarConsistentIntegrationofModelsBasedonViewsofVisualLanguages.{APACrefauthors}Ehrig, H., Ehrig, K., Ermel, C.\BCBL \BBA Prange, U. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleConsistent Integration of Models Based on Views of Visual Languages Consistent integration of models based on views of visual languages.\BBCQ \BIn \APACrefbtitleFASE 2008 FASE 2008 (\BPGS 62–76). \PrintBackRefs\CurrentBib
Eramo \BOthers. (\APACyear2014) \APACinsertmetastarUncertaintyinbidirectionaltransformations{APACrefauthors}Eramo, R., Pierantonio, A.\BCBL \BBA Rosa, G. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleUncertainty in bidirectional transformations Uncertainty in bidirectional transformations.\BBCQ \BIn \APACrefbtitleMiSE 2014 MiSE 2014 (\BPGS 37–42). \PrintBackRefs\CurrentBib
Eramo \BOthers. (\APACyear2015) \APACinsertmetastarManaginguncertaintyinbidirectionalmodeltransformations{APACrefauthors}Eramo, R., Pierantonio, A.\BCBL \BBA Rosa, G. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleManaging uncertainty in bidirectional model transformations Managing uncertainty in bidirectional model transformations.\BBCQ \BIn \APACrefbtitleSLE 2015 SLE 2015 (\BPGS 49–58). \PrintBackRefs\CurrentBib
Esfahani \BBA Malek (\APACyear2010) \APACinsertmetastarUncertaintyinSelfAdaptiveSoftwareSystems{APACrefauthors}Esfahani, N.\BCBT \BBA Malek, S. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleUncertainty in Self-Adaptive Software Systems Uncertainty in self-adaptive software systems.\BBCQ \BIn \APACrefbtitleSoftware Engineering for Self-Adaptive Systems II, 2010 Revised Selected and Invited Papers Software engineering for self-adaptive systems II, 2010 revised selected and invited papers (\BPGS 214–238). \PrintBackRefs\CurrentBib
Famelis \BOthers. (\APACyear2015) \APACinsertmetastarMu-Mmint:anIDEformodeluncertainty{APACrefauthors}Famelis, M., Ben-David, N., Di Sandro, A., Salay, R.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleMu-Mmint: An IDE for Model Uncertainty Mu-mmint: An ide for model uncertainty.\BBCQ \BIn \APACrefbtitleICSE 2015 ICSE 2015 (\BPGS 697–700). \APACaddressPublisherIEEE Press. \PrintBackRefs\CurrentBib
Famelis \BOthers. (\APACyear2012\APACexlab\BCnt1) \APACinsertmetastarPartialmodels-Towardsmodelingandreasoningwithuncertainty.{APACrefauthors}Famelis, M., Salay, R.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2012\BCnt1. \BBOQ\APACrefatitlePartial models: Towards modeling and reasoning with uncertainty Partial models: Towards modeling and reasoning with uncertainty.\BBCQ \BIn \APACrefbtitleICSE 2012 ICSE 2012 (\BPGS 573–583). \PrintBackRefs\CurrentBib
Famelis \BOthers. (\APACyear2012\APACexlab\BCnt2) \APACinsertmetastarThesemanticsofpartialmodeltransformations{APACrefauthors}Famelis, M., Salay, R.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2012\BCnt206. \BBOQ\APACrefatitleThe semantics of partial model transformations The semantics of partial model transformations.\BBCQ \BIn \APACrefbtitleMiSE 2012 MiSE 2012 (\BPG 64-69). \PrintBackRefs\CurrentBib
Famelis \BOthers. (\APACyear2013) \APACinsertmetastarTransformationofModelsContainingUncertainty.{APACrefauthors}Famelis, M., Salay, R., Sandro, A\BPBID.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleTransformation of Models Containing Uncertainty Transformation of models containing uncertainty.\BBCQ \BIn \APACrefbtitleMODELS 2013 MODELS 2013 (\BPGS 673–689). \PrintBackRefs\CurrentBib
Famelis \BBA Santosa (\APACyear2013) \APACinsertmetastarMAV-Vis:anotationformodeluncertainty{APACrefauthors}Famelis, M.\BCBT \BBA Santosa, S. \APACrefYearMonthDay201305. \BBOQ\APACrefatitleMAV-Vis: A notation for model uncertainty Mav-vis: A notation for model uncertainty.\BBCQ \BIn \APACrefbtitleICSE 2013, Workshop on Software Engineering for Adaptive and Self-Managing Systems ICSE 2013, workshop on software engineering for adaptive and self-managing systems (\BPG 7-12). \PrintBackRefs\CurrentBib
Fan \BOthers. (\APACyear2009) \APACinsertmetastarAMethodforModelingandAnalyzingFault-TolerantServiceComposition.{APACrefauthors}Fan, G., Yu, H., Chen, L.\BCBL \BBA Liu, D. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleA Method for Modeling and Analyzing Fault-Tolerant Service Composition A method for modeling and analyzing fault-tolerant service composition.\BBCQ \BIn \APACrefbtitleAPSEC 2009 APSEC 2009 (\BPGS 507–514). \PrintBackRefs\CurrentBib
Farias \BOthers. (\APACyear2012) \APACinsertmetastarEvaluatingtheImpactofAspectsonInconsistencyDetectionEffort-AControlledExperiment.{APACrefauthors}Farias, K., Garcia, A.\BCBL \BBA de Lucena, C\BPBIJ\BPBIP. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleEvaluating the Impact of Aspects on Inconsistency Detection Effort: A Controlled Experiment Evaluating the impact of aspects on inconsistency detection effort: A controlled experiment.\BBCQ \BIn \APACrefbtitleMODELS 2012 MODELS 2012 (\BPGS 219–234). \PrintBackRefs\CurrentBib
Fernández-Sáez \BOthers. (\APACyear2010) \APACinsertmetastarFernandez2010{APACrefauthors}Fernández-Sáez, A\BPBIM., Bocco, M\BPBIG.\BCBL \BBA Romero, F\BPBIP. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleSLR-Tool - A Tool for Performing Systematic Literature Reviews Slr-tool - A tool for performing systematic literature reviews.\BBCQ \BIn J\BPBIA\BPBIM. Cordeiro, M. Virvou\BCBL \BBA B. Shishkov (\BEDS), \APACrefbtitleICSOFT 2010 ICSOFT 2010 (\BPGS 157–166). \APACaddressPublisherSciTePress. \PrintBackRefs\CurrentBib
Förster \BBA Schneider (\APACyear2010) \APACinsertmetastarFlexible{APACrefauthors}Förster, M.\BCBT \BBA Schneider, D. \APACrefYearMonthDay201012. \BBOQ\APACrefatitleFlexible, Any-Time Fault Tree Analysis with Component Logic Models Flexible, any-time fault tree analysis with component logic models.\BBCQ \BIn \APACrefbtitleISSRE 2010 ISSRE 2010 (\BPG 51 - 60). \PrintBackRefs\CurrentBib
Fraj \BOthers. (\APACyear2017) \APACinsertmetastarAModelingApproachforFlexibleWorkflowApplicationsofCloudServices.{APACrefauthors}Fraj, I\BPBIB., Hlaoui, Y\BPBIB.\BCBL \BBA Ayed, L\BPBIJ\BPBIB. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleA Modeling Approach for Flexible Workflow Applications of Cloud Services A modeling approach for flexible workflow applications of cloud services.\BBCQ \BIn \APACrefbtitleCOMPSAC 2017 COMPSAC 2017 (\BPGS 175–180). \PrintBackRefs\CurrentBib
Friedrich (\APACyear2018) \APACinsertmetastarDeclarativeprojectplanningandcontrolling-aformalmodeltosupportthehandlingofunavoidableinconsistencies.{APACrefauthors}Friedrich, J. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleDeclarative project planning and controlling: a formal model to support the handling of unavoidable inconsistencies Declarative project planning and controlling: a formal model to support the handling of unavoidable inconsistencies.\BBCQ \BIn \APACrefbtitleICSSP 2018 ICSSP 2018 (\BPGS 61–69). \PrintBackRefs\CurrentBib
Gabsi \BOthers. (\APACyear2016) \APACinsertmetastarEMA2AOP-FromtheAADLErrorModelAnnextoaspectlanguagetowardsfaulttolerantsystems.{APACrefauthors}Gabsi, W., Zalila, B.\BCBL \BBA Jmaïel, M. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleEMA2AOP: From the AADL Error Model Annex to aspect language towards fault tolerant systems EMA2AOP: from the AADL error model annex to aspect language towards fault tolerant systems.\BBCQ \BIn \APACrefbtitleSERA 2016 SERA 2016 (\BPGS 155–162). \PrintBackRefs\CurrentBib
Galindo \BOthers. (\APACyear2019) \APACinsertmetastarGalindo2019{APACrefauthors}Galindo, J\BPBIA., Benavides, D., Trinidad, P., Gutiérrez-Fernández, A\BPBIM.\BCBL \BBA Ruiz-Cortés, A. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleAutomated analysis of feature models: Quo vadis? Automated analysis of feature models: Quo vadis?\BBCQ \APACjournalVolNumPagesComputing1015387–433. \PrintBackRefs\CurrentBib
Galster \BOthers. (\APACyear2014) \APACinsertmetastarGalster2014{APACrefauthors}Galster, M., Weyns, D., Tofan, D., Michalik, B.\BCBL \BBA Avgeriou, P. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleVariability in Software Systems - A Systematic Literature Review Variability in software systems - A systematic literature review.\BBCQ \APACjournalVolNumPagesIEEE Trans. Software Eng.403282–306. \PrintBackRefs\CurrentBib
Gao \BOthers. (\APACyear2011) \APACinsertmetastarDataUncertaintyModelforMashup.{APACrefauthors}Gao, X., Hu, W., Ye, W.\BCBL \BBA Zhang, S. \APACrefYearMonthDay201101. \BBOQ\APACrefatitleData Uncertainty Model for Mashup. Data uncertainty model for mashup.\BBCQ \BIn \APACrefbtitleSEKE 2011 Seke 2011 (\BPG 503-508). \PrintBackRefs\CurrentBib
Garlan (\APACyear2010) \APACinsertmetastarSoftwareengineeringinanuncertainworld{APACrefauthors}Garlan, D. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleSoftware engineering in an uncertain world Software engineering in an uncertain world.\BBCQ \BIn G. Roman \BBA K\BPBIJ. Sullivan (\BEDS), \APACrefbtitleFoSER 2010 FoSER 2010 (\BPGS 125–128). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Gerpheide \BOthers. (\APACyear2014) \APACinsertmetastarGerpheide2014{APACrefauthors}Gerpheide, C\BPBIM., Schiffelers, R\BPBIR\BPBIH.\BCBL \BBA Serebrenik, A. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleA Bottom-Up Quality Model for QVTo A bottom-up quality model for qvto.\BBCQ \BIn \APACrefbtitleQUATIC 2014 QUATIC 2014 (\BPGS 85–94). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Gerpheide \BOthers. (\APACyear2016) \APACinsertmetastarGerpheide2016{APACrefauthors}Gerpheide, C\BPBIM., Schiffelers, R\BPBIR\BPBIH.\BCBL \BBA Serebrenik, A. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleAssessing and improving quality of QVTo model transformations Assessing and improving quality of qvto model transformations.\BBCQ \APACjournalVolNumPagesSoftware Quality Journal243797–834. \PrintBackRefs\CurrentBib
Ghezzi \BOthers. (\APACyear2013) \APACinsertmetastarManagingnon-functionaluncertaintyviamodel-drivenadaptivity{APACrefauthors}Ghezzi, C., Pinto, L\BPBIS., Spoletini, P.\BCBL \BBA Tamburrelli, G. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleManaging non-functional uncertainty via model-driven adaptivity Managing non-functional uncertainty via model-driven adaptivity.\BBCQ \BIn D. Notkin, B\BPBIH\BPBIC. Cheng\BCBL \BBA K. Pohl (\BEDS), \APACrefbtitleICSE 2013 ICSE 2013 (\BPGS 33–42). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Gogolla \BOthers. (\APACyear2015) \APACinsertmetastarCheckingUMLandOCLModelConsistency-AnExperienceReportonaMiddle-SizedCaseStudy{APACrefauthors}Gogolla, M., Hamann, L., Hilken, F.\BCBL \BBA Sedlmeier, M. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleChecking UML and OCL Model Consistency: An Experience Report on a Middle-Sized Case Study Checking UML and OCL model consistency: An experience report on a middle-sized case study.\BBCQ \BIn \APACrefbtitleTAP 2015 TAP 2015 (\BPGS 129–136). \PrintBackRefs\CurrentBib
Gogolla \BOthers. (\APACyear2009) \APACinsertmetastarConsistencyIndependenceandConsequencesinUMLandOCLModels{APACrefauthors}Gogolla, M., Kuhlmann, M.\BCBL \BBA Hamann, L. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleConsistency, Independence and Consequences in UML and OCL Models Consistency, independence and consequences in UML and OCL models.\BBCQ \BIn \APACrefbtitleTAP 2009 TAP 2009 (\BPGS 90–104). \PrintBackRefs\CurrentBib
Goldsby \BBA Cheng (\APACyear2008) \APACinsertmetastarAutomaticallyGeneratingBehavioralModelsofAdaptiveSystemstoAddressUncertainty.{APACrefauthors}Goldsby, H.\BCBT \BBA Cheng, B\BPBIH\BPBIC. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleAutomatically Generating Behavioral Models of Adaptive Systems to Address Uncertainty Automatically generating behavioral models of adaptive systems to address uncertainty.\BBCQ \BIn \APACrefbtitleMoDELS 2008 MoDELS 2008 (\BPGS 568–583). \PrintBackRefs\CurrentBib
Götz (\APACyear2018) \APACinsertmetastarGoetz2018{APACrefauthors}Götz, S. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleSupporting systematic literature reviews in computer science: the systematic literature review toolkit Supporting systematic literature reviews in computer science: the systematic literature review toolkit.\BBCQ \BIn Ö. Babur \BOthers. (\BEDS), \APACrefbtitleMODELS 2018, Companion Proceedings MODELS 2018, companion proceedings (\BPGS 22–26). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Goulão \BOthers. (\APACyear2016) \APACinsertmetastarGoulao2016{APACrefauthors}Goulão, M., Amaral, V.\BCBL \BBA Mernik, M. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleQuality in model-driven engineering: a tertiary study Quality in model-driven engineering: a tertiary study.\BBCQ \APACjournalVolNumPagesSoftware Quality Journal243601–633. \PrintBackRefs\CurrentBib
Gray \BBA Rumpe (\APACyear2016) \APACinsertmetastarGray2016{APACrefauthors}Gray, J.\BCBT \BBA Rumpe, B. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleHow to write a successful SoSyM submission How to write a successful sosym submission.\BBCQ \APACjournalVolNumPagesSoftware and Systems Modeling154929–931. \PrintBackRefs\CurrentBib
Guerra \BBA de Lara (\APACyear2018) \APACinsertmetastarOntheQuestforFlexibleModelling.{APACrefauthors}Guerra, E.\BCBT \BBA de Lara, J. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleOn the Quest for Flexible Modelling On the quest for flexible modelling.\BBCQ \BIn \APACrefbtitleMODELS 2018 MODELS 2018 (\BPGS 23–33). \PrintBackRefs\CurrentBib
Hamid \BBA Mosbah (\APACyear2005) \APACinsertmetastarAFormalModelforFault-ToleranceinDistributedSystems.{APACrefauthors}Hamid, B.\BCBT \BBA Mosbah, M. \APACrefYearMonthDay2005. \BBOQ\APACrefatitleA Formal Model for Fault-Tolerance in Distributed Systems A formal model for fault-tolerance in distributed systems.\BBCQ \BIn \APACrefbtitleSAFECOMP 2005 SAFECOMP 2005 (\BPGS 108–121). \PrintBackRefs\CurrentBib
Hamlaoui \BOthers. (\APACyear2014) \APACinsertmetastarHeterogeneousModelsMatchingforConsistencyManagement.{APACrefauthors}Hamlaoui, M\BPBIE., Ebersold, S., Coulette, B., Nassar, M.\BCBL \BBA Anwar, A. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleHeterogeneous models matching for consistency management Heterogeneous models matching for consistency management.\BBCQ \BIn \APACrefbtitleRCIS 2014 RCIS 2014 (\BPGS 1–12). \PrintBackRefs\CurrentBib
Hansen \BBA Thomsen (\APACyear1999) \APACinsertmetastarThe’domainmodelconcealer’and’applicationmoderator’patterns:addressingarchitecturaluncertaintyininteractivesystems{APACrefauthors}Hansen, K\BPBIM.\BCBT \BBA Thomsen, M. \APACrefYearMonthDay1999. \BBOQ\APACrefatitleThe "Domain Model Concealer" and "Application Moderator" Patterns: Addressing Architectural Uncertainty in Interactive Systems The "domain model concealer" and "application moderator" patterns: Addressing architectural uncertainty in interactive systems.\BBCQ \BIn \APACrefbtitleTOOLS 1999 TOOLS 1999 (\BPGS 177–190). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Hao \BOthers. (\APACyear1992) \APACinsertmetastarPrototypinganInconsistencyCheckingToolforSoftwareProcessModels.{APACrefauthors}Hao, J., Trousset, F.\BCBL \BBA Jacques, J. \APACrefYearMonthDay1992. \BBOQ\APACrefatitlePrototyping an Inconsistency Checking Tool for Software Process Models Prototyping an inconsistency checking tool for software process models.\BBCQ \BIn \APACrefbtitleSEKE 1992 SEKE 1992 (\BPGS 227–234). \PrintBackRefs\CurrentBib
He \BOthers. (\APACyear2015) \APACinsertmetastarTowardsModel-DrivenVariability-BasedFlexibleServiceCompositions.{APACrefauthors}He, X., Fu, Y., Sun, C., Ma, Z.\BCBL \BBA Shao, W. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleTowards Model-Driven Variability-Based Flexible Service Compositions Towards model-driven variability-based flexible service compositions.\BBCQ \BIn \APACrefbtitleCOMPSAC 2015 COMPSAC 2015 (\BPGS 298–303). \PrintBackRefs\CurrentBib
Hebig \BOthers. (\APACyear2016) \APACinsertmetastarApproachestoCoEvolutionofMetamodelsandModelsASurvey{APACrefauthors}Hebig, R., Khelladi, D.\BCBL \BBA Bendraou, R. \APACrefYearMonthDay201609. \BBOQ\APACrefatitleApproaches to Co-Evolution of Metamodels and Models: A Survey Approaches to co-evolution of metamodels and models: A survey.\BBCQ \APACjournalVolNumPagesIEEE Transactions on Software EngineeringPP1-1. \PrintBackRefs\CurrentBib
Hegedüs \BOthers. (\APACyear2011) \APACinsertmetastarQuickfixgenerationforDSMLs{APACrefauthors}Hegedüs, Á., Horváth, Á., Ráth, I., Branco, M\BPBIC.\BCBL \BBA Varró, D. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleQuick fix generation for DSMLs Quick fix generation for dsmls.\BBCQ \BIn \APACrefbtitleVL/HCC 2011 VL/HCC 2011 (\BPGS 17–24). \PrintBackRefs\CurrentBib
Hili (\APACyear2016) \APACinsertmetastarAMetamodelingFrameworkforPromotingFlexibilityandCreativityOverStrictModelConformance{APACrefauthors}Hili, N. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleA Metamodeling Framework for Promoting Flexibility and Creativity Over Strict Model Conformance A metamodeling framework for promoting flexibility and creativity over strict model conformance.\BBCQ \BIn \APACrefbtitleFlexMDE@MoDELS 2016, Workshop Proceedings FlexMDE@MoDELS 2016, workshop proceedings (\BPGS 2–11). \PrintBackRefs\CurrentBib
Hili \BBA Sottet (\APACyear2017) \APACinsertmetastarTheConformanceRelationChallenge-BuildingFlexibleModellingFrameworks.{APACrefauthors}Hili, N.\BCBT \BBA Sottet, J. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleThe Conformance Relation Challenge: Building Flexible Modelling Frameworks The conformance relation challenge: Building flexible modelling frameworks.\BBCQ \BIn \APACrefbtitleMODELS 2017, Workshop Proceedings MODELS 2017, workshop proceedings (\BPGS 418–423). \PrintBackRefs\CurrentBib
Hoisl \BBA Sobernig (\APACyear2015) \APACinsertmetastarHoisl2015{APACrefauthors}Hoisl, B.\BCBT \BBA Sobernig, S. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleConsistency Rules for UML-based Domain-specific Language Models: A Literature Review Consistency rules for uml-based domain-specific language models: A literature review.\BBCQ \BIn I. Dragomir \BOthers. (\BEDS), \APACrefbtitleMoDELS 2015, Workshop Proceedings MoDELS 2015, workshop proceedings (\BVOL 1508, \BPGS 29–36). \APACaddressPublisherCEUR-WS.org. \PrintBackRefs\CurrentBib
Höllrigl \BOthers. (\APACyear2010) \APACinsertmetastarAConsistencyModelforIdentityInformationinDistributedSystems.{APACrefauthors}Höllrigl, T., Dinger, J.\BCBL \BBA Hartenstein, H. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleA Consistency Model for Identity Information in Distributed Systems A consistency model for identity information in distributed systems.\BBCQ \BIn \APACrefbtitleCOMPSAC 2010 COMPSAC 2010 (\BPGS 252–261). \PrintBackRefs\CurrentBib
Honda \BOthers. (\APACyear2013\APACexlab\BCnt1) \APACinsertmetastarAGeneralizedSoftwareReliabilityModelConsideringUncertaintyandDynamicsinDevelopment{APACrefauthors}Honda, K., Washizaki, H.\BCBL \BBA Fukazawa, Y. \APACrefYearMonthDay2013\BCnt1. \BBOQ\APACrefatitleA Generalized Software Reliability Model Considering Uncertainty and Dynamics in Development A generalized software reliability model considering uncertainty and dynamics in development.\BBCQ \BIn J. Heidrich, M. Oivo, A. Jedlitschka\BCBL \BBA M\BPBIT. Baldassarre (\BEDS), \APACrefbtitlePROFES 2013 PROFES 2013 (\BVOL 7983, \BPGS 342–346). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Honda \BOthers. (\APACyear2013\APACexlab\BCnt2) \APACinsertmetastarAmodel-drivenapproachtoflexiblemulti-levelcustomizationofSaaSapplications.{APACrefauthors}Honda, K., Washizaki, H.\BCBL \BBA Fukazawa, Y. \APACrefYearMonthDay2013\BCnt2. \BBOQ\APACrefatitleA Generalized Software Reliability Model Considering Uncertainty and Dynamics in Development A generalized software reliability model considering uncertainty and dynamics in development.\BBCQ \BIn J. Heidrich, M. Oivo, A. Jedlitschka\BCBL \BBA M\BPBIT. Baldassarre (\BEDS), \APACrefbtitlePROFES 2013 PROFES 2013 (\BVOL 7983, \BPGS 342–346). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Ibrahim \BOthers. (\APACyear2009) \APACinsertmetastarUncertaintymanagementinsoftwareengineeringPastpresentandfuture{APACrefauthors}Ibrahim, H., Far, B\BPBIH., Eberlein, A.\BCBL \BBA Daradkeh, Y. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleUncertainty management in software engineering: Past, present, and future Uncertainty management in software engineering: Past, present, and future.\BBCQ \BIn \APACrefbtitleCCECE 2009 CCECE 2009 (\BPGS 7–12). \PrintBackRefs\CurrentBib
Iqbal \BOthers. (\APACyear2019) \APACinsertmetastarIqbal2019{APACrefauthors}Iqbal, A., Khan, I\BPBIA.\BCBL \BBA Jan, S. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleA Review and Comparison of the Traditional Collaborative and Online Collaborative Techniques for Software Requirement Elicitation A review and comparison of the traditional collaborative and online collaborative techniques for software requirement elicitation.\BBCQ \BIn \APACrefbtitleICACS Proceedings ICACS proceedings (\BPGS 1–8). \APACaddressPublisherIEEE. \PrintBackRefs\CurrentBib
Jahanbanifar \BOthers. (\APACyear2016) \APACinsertmetastarRuntimeAdjustmentofConfigurationModelsforConsistencyPreservation.{APACrefauthors}Jahanbanifar, A., Khendek, F.\BCBL \BBA Toeroe, M. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleRuntime Adjustment of Configuration Models for Consistency Preservation Runtime adjustment of configuration models for consistency preservation.\BBCQ \BIn \APACrefbtitleHASE 2016 HASE 2016 (\BPGS 102–109). \PrintBackRefs\CurrentBib
Ji \BOthers. (\APACyear2018) \APACinsertmetastarUncoveringUnknownSystemBehaviorsinUncertainNetworkswithModelandSearch-BasedTesting.{APACrefauthors}Ji, R., Li, Z., Chen, S., Pan, M., Zhang, T., Ali, S.\BDBLLi, X. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleUncovering Unknown System Behaviors in Uncertain Networks with Model and Search-Based Testing Uncovering unknown system behaviors in uncertain networks with model and search-based testing.\BBCQ \BIn \APACrefbtitleICST 2018 ICST 2018 (\BPGS 204–214). \PrintBackRefs\CurrentBib
Jureta \BOthers. (\APACyear2010) \APACinsertmetastarTechneTowardsaNewGenerationofRequirementsModelingLanguageswithGoalsPreferencesandInconsistencyHandling{APACrefauthors}Jureta, I., Borgida, A., Ernst, N\BPBIA.\BCBL \BBA Mylopoulos, J. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleTechne: Towards a New Generation of Requirements Modeling Languages with Goals, Preferences, and Inconsistency Handling Techne: Towards a new generation of requirements modeling languages with goals, preferences, and inconsistency handling.\BBCQ \BIn \APACrefbtitleRE 2010 RE 2010 (\BPGS 115–124). \PrintBackRefs\CurrentBib
Khelladi \BOthers. (\APACyear2019) \APACinsertmetastarDetectingandexploringsideeffectswhenrepairingmodelinconsistencies{APACrefauthors}Khelladi, D\BPBIE., Kretschmer, R.\BCBL \BBA Egyed, A. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleDetecting and exploring side effects when repairing model inconsistencies Detecting and exploring side effects when repairing model inconsistencies.\BBCQ \BIn \APACrefbtitleSLE 2019 SLE 2019 (\BPGS 113–126). \PrintBackRefs\CurrentBib
B. Kitchenham (\APACyear2004) \APACinsertmetastarKitchenham2004{APACrefauthors}Kitchenham, B. \APACrefYearMonthDay200408. \BBOQ\APACrefatitleProcedures for Performing Systematic Reviews Procedures for performing systematic reviews.\BBCQ \APACjournalVolNumPagesKeele, UK, Keele Univ.33. \PrintBackRefs\CurrentBib
B\BPBIA. Kitchenham \BOthers. (\APACyear2009) \APACinsertmetastarSystematicliteraturereviewsinsoftwareengineering-Asystematicliteraturereview{APACrefauthors}Kitchenham, B\BPBIA., Brereton, P., Budgen, D., Turner, M., Bailey, J.\BCBL \BBA Linkman, S\BPBIG. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleSystematic literature reviews in software engineering - A systematic literature review Systematic literature reviews in software engineering - A systematic literature review.\BBCQ \APACjournalVolNumPagesInf. Softw. Technol.5117–15. \PrintBackRefs\CurrentBib
Koç \BOthers. (\APACyear2014) \APACinsertmetastarKoc2014{APACrefauthors}Koç, H., Hennig, E., Jastram, S.\BCBL \BBA Starke, C. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleState of the Art in Context Modelling - A Systematic Literature Review State of the art in context modelling - A systematic literature review.\BBCQ \BIn L\BPBIS. Iliadis, M\BPBIP. Papazoglou\BCBL \BBA K. Pohl (\BEDS), \APACrefbtitleCAiSE 2014, Workshop Proceedings CAiSE 2014, workshop proceedings (\BVOL 178, \BPGS 53–64). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Kolovos \BOthers. (\APACyear2008) \APACinsertmetastarDetectingandRepairingInconsistenciesacrossHeterogeneousModels.{APACrefauthors}Kolovos, D\BPBIS., Paige, R\BPBIF.\BCBL \BBA Polack, F. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleDetecting and Repairing Inconsistencies across Heterogeneous Models Detecting and repairing inconsistencies across heterogeneous models.\BBCQ \BIn \APACrefbtitleICST 2008 ICST 2008 (\BPGS 356–364). \PrintBackRefs\CurrentBib
Kretschmer \BOthers. (\APACyear2017) \APACinsertmetastarFromAbstracttoConcreteRepairsofModelInconsistencies-AnAutomatedApproach.{APACrefauthors}Kretschmer, R., Khelladi, D\BPBIE., Demuth, A., Lopez-Herrejon, R\BPBIE.\BCBL \BBA Egyed, A. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleFrom Abstract to Concrete Repairs of Model Inconsistencies: An Automated Approach From abstract to concrete repairs of model inconsistencies: An automated approach.\BBCQ \BIn \APACrefbtitleAPSEC 2017 APSEC 2017 (\BPGS 456–465). \PrintBackRefs\CurrentBib
Kretschmer \BOthers. (\APACyear2018) \APACinsertmetastarAnautomatedandinstantdiscoveryofconcreterepairsformodelinconsistencies.{APACrefauthors}Kretschmer, R., Khelladi, D\BPBIE.\BCBL \BBA Egyed, A. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleAn automated and instant discovery of concrete repairs for model inconsistencies An automated and instant discovery of concrete repairs for model inconsistencies.\BBCQ \BIn \APACrefbtitleICSE 2018 ICSE 2018 (\BPGS 298–299). \PrintBackRefs\CurrentBib
Krishna \BOthers. (\APACyear2005) \APACinsertmetastarLoosely-coupledConsistencybetweenAgent-orientedConceptualModelsandZSpecifications.{APACrefauthors}Krishna, A., Ghose, A\BPBIK.\BCBL \BBA Vilkomir, S\BPBIA. \APACrefYearMonthDay2005. \BBOQ\APACrefatitleLoosely-coupled Consistency between Agent-oriented Conceptual Models and Z Specifications Loosely-coupled consistency between agent-oriented conceptual models and Z specifications.\BBCQ \BIn \APACrefbtitleSEKE 2005 SEKE 2005 (\BPGS 455–460). \PrintBackRefs\CurrentBib
Kusel \BOthers. (\APACyear2015) \APACinsertmetastarConsistentco-evolutionofmodelsandtransformations.{APACrefauthors}Kusel, A., Etzlstorfer, J., Kapsammer, E., Retschitzegger, W., Schwinger, W.\BCBL \BBA Schönböck, J. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleConsistent co-evolution of models and transformations Consistent co-evolution of models and transformations.\BBCQ \BIn \APACrefbtitleMoDELS 2015 MoDELS 2015 (\BPGS 116–125). \PrintBackRefs\CurrentBib
Küster \BBA Ryndina (\APACyear2007) \APACinsertmetastarImprovingInconsistencyResolutionwithSide-EffectEvaluationandCosts.{APACrefauthors}Küster, J\BPBIM.\BCBT \BBA Ryndina, K. \APACrefYearMonthDay2007. \BBOQ\APACrefatitleImproving Inconsistency Resolution with Side-Effect Evaluation and Costs Improving inconsistency resolution with side-effect evaluation and costs.\BBCQ \BIn \APACrefbtitleMoDELS 2007 MoDELS 2007 (\BPGS 136–150). \PrintBackRefs\CurrentBib
Kyrkou \BOthers. (\APACyear2015) \APACinsertmetastarAcamerauncertaintymodelforcollaborativevisualsensornetworkapplications{APACrefauthors}Kyrkou, C., Christoforou, E., Theocharides, T., Panayiotou, C.\BCBL \BBA Polycarpou, M\BPBIM. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleA camera uncertainty model for collaborative visual sensor network applications A camera uncertainty model for collaborative visual sensor network applications.\BBCQ \BIn R. Carmona-Galán \BBA Á. Rodríguez-Vázquez (\BEDS), \APACrefbtitleICDSC 2015 ICDSC 2015 (\BPGS 86–91). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Leblebici \BOthers. (\APACyear2017) \APACinsertmetastarInter-modelConsistencyCheckingUsingTripleGraphGrammarsandLinearOptimizationTechniques.{APACrefauthors}Leblebici, E., Anjorin, A.\BCBL \BBA Schürr, A. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleInter-model Consistency Checking Using Triple Graph Grammars and Linear Optimization Techniques Inter-model consistency checking using triple graph grammars and linear optimization techniques.\BBCQ \BIn \APACrefbtitleFASE 2017 FASE 2017 (\BPGS 191–207). \PrintBackRefs\CurrentBib
Link \BOthers. (\APACyear2001) \APACinsertmetastarxlinkitaconsistencycheckingandsmartlinkgenerationservice{APACrefauthors}Link, S., Service, G., Nentwich, C., Capra, L.\BCBL \BBA Emmerich, W. \APACrefYearMonthDay200101. \BBOQ\APACrefatitlexlinkit: A Consistency Checking and Smart Link Generation Service xlinkit: A consistency checking and smart link generation service.\BBCQ \APACjournalVolNumPagesACM Transactions on Internet Technology (TOIT)2. \PrintBackRefs\CurrentBib
Lytra \BOthers. (\APACyear2012) \APACinsertmetastarConstraint-BasedConsistencyCheckingbetweenDesignDecisionsandComponentModelsforSupportingSoftwareArchitectureEvolution.{APACrefauthors}Lytra, I., Tran, H.\BCBL \BBA Zdun, U. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleConstraint-Based Consistency Checking between Design Decisions and Component Models for Supporting Software Architecture Evolution Constraint-based consistency checking between design decisions and component models for supporting software architecture evolution.\BBCQ \BIn \APACrefbtitleCSMR 2012 CSMR 2012 (\BPGS 287–296). \PrintBackRefs\CurrentBib
Lytra \BOthers. (\APACyear2013) \APACinsertmetastarSupportingConsistencybetweenArchitecturalDesignDecisionsandComponentModelsthroughReusableArchitecturalKnowledgeTransformations.{APACrefauthors}Lytra, I., Tran, H.\BCBL \BBA Zdun, U. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleSupporting Consistency between Architectural Design Decisions and Component Models through Reusable Architectural Knowledge Transformations Supporting consistency between architectural design decisions and component models through reusable architectural knowledge transformations.\BBCQ \BIn \APACrefbtitleECSA 2013 ECSA 2013 (\BPGS 224–239). \PrintBackRefs\CurrentBib
Macedo \BBA Cunha (\APACyear2013) \APACinsertmetastarImplementingQVTRbidirectionalmodeltransformationsusingalloy{APACrefauthors}Macedo, N.\BCBT \BBA Cunha, A. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleImplementing QVT-R Bidirectional Model Transformations Using Alloy Implementing QVT-R bidirectional model transformations using alloy.\BBCQ \BIn \APACrefbtitleFASE 2013 FASE 2013 (\BPGS 297–311). \PrintBackRefs\CurrentBib
M. Marinho \BOthers. (\APACyear2018) \APACinsertmetastarMarinho2018{APACrefauthors}Marinho, M., Sampaio, S.\BCBL \BBA de Moura, H\BPBIP. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleManaging uncertainty in software projects Managing uncertainty in software projects.\BBCQ \APACjournalVolNumPagesISSE143157–181. \PrintBackRefs\CurrentBib
M\BPBIL\BPBIM. Marinho \BOthers. (\APACyear2015) \APACinsertmetastarMarinho2015{APACrefauthors}Marinho, M\BPBIL\BPBIM., de Barros Sampaio, S\BPBIC., de Andrade Lima, T\BPBIL.\BCBL \BBA de Moura, H\BPBIP. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleUncertainty Management in Software Projects Uncertainty management in software projects.\BBCQ \APACjournalVolNumPagesJSW103288–303. \PrintBackRefs\CurrentBib
Martinho \BOthers. (\APACyear2008) \APACinsertmetastarATwo-StepApproachforModellingFlexibilityinSoftwareProcesses{APACrefauthors}Martinho, R., Varajão, J.\BCBL \BBA Domingos, D. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleA Two-Step Approach for Modelling Flexibility in Software Processes A two-step approach for modelling flexibility in software processes.\BBCQ \BIn \APACrefbtitleASE 2008 ASE 2008 (\BPGS 427–430). \PrintBackRefs\CurrentBib
Mayerhofer \BOthers. (\APACyear2016) \APACinsertmetastarAddinguncertaintyandunitstoquantitytypesinsoftwaremodels{APACrefauthors}Mayerhofer, T., Wimmer, M.\BCBL \BBA Vallecillo, A. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleAdding uncertainty and units to quantity types in software models Adding uncertainty and units to quantity types in software models.\BBCQ \BIn T. van der Storm, E. Balland\BCBL \BBA D. Varró (\BEDS), \APACrefbtitleSLE 2016 SLE 2016 (\BPGS 118–131). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Mens \BOthers. (\APACyear2006) \APACinsertmetastarDetectingandResolvingModelInconsistenciesUsingTransformationDependencyAnalysis.{APACrefauthors}Mens, T., Straeten, R\BPBIV\BPBID.\BCBL \BBA D’Hondt, M. \APACrefYearMonthDay2006. \BBOQ\APACrefatitleDetecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis Detecting and resolving model inconsistencies using transformation dependency analysis.\BBCQ \BIn \APACrefbtitleMoDELS 2006 MoDELS 2006 (\BPGS 200–214). \PrintBackRefs\CurrentBib
Moghaddam \BBA Muccini (\APACyear2019) \APACinsertmetastarMoghaddam2019{APACrefauthors}Moghaddam, M\BPBIT.\BCBT \BBA Muccini, H. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleFault-Tolerant IoT - A Systematic Mapping Study Fault-tolerant iot - A systematic mapping study.\BBCQ \BIn R. Calinescu \BBA F\BPBID. Giandomenico (\BEDS), \APACrefbtitleSERENE 2019 SERENE 2019 (\BVOL 11732, \BPGS 67–84). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Morin \BOthers. (\APACyear2010) \APACinsertmetastarFlexibleModelElementIntroductionPoliciesforAspect-OrientedModeling.{APACrefauthors}Morin, B., Klein, J., Kienzle, J.\BCBL \BBA Jézéquel, J. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleFlexible Model Element Introduction Policies for Aspect-Oriented Modeling Flexible model element introduction policies for aspect-oriented modeling.\BBCQ \BIn \APACrefbtitleMODELS 2010 MODELS 2010 (\BPGS 63–77). \PrintBackRefs\CurrentBib
Muram \BOthers. (\APACyear2017) \APACinsertmetastarMuram2017{APACrefauthors}Muram, F\BPBIU., Tran, H.\BCBL \BBA Zdun, U. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleSystematic Review of Software Behavioral Model Consistency Checking Systematic review of software behavioral model consistency checking.\BBCQ \APACjournalVolNumPagesACM Comput. Surv.50217:1–17:39. \PrintBackRefs\CurrentBib
Nascimento \BOthers. (\APACyear2014) \APACinsertmetastarNascimento2014{APACrefauthors}Nascimento, A\BPBIS., Rubira, C\BPBIM\BPBIF., Burrows, R., Castor, F.\BCBL \BBA Brito, P\BPBIH\BPBIS. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleDesigning fault-tolerant SOA based on design diversity Designing fault-tolerant SOA based on design diversity.\BBCQ \APACjournalVolNumPagesJ. Software Eng. R&D213. \PrintBackRefs\CurrentBib
Nentwich \BOthers. (\APACyear2003) \APACinsertmetastarConsistencymanagementwithrepairactions{APACrefauthors}Nentwich, C., Emmerich, W.\BCBL \BBA Finkelstein, A. \APACrefYearMonthDay2003. \BBOQ\APACrefatitleConsistency Management with Repair Actions Consistency management with repair actions.\BBCQ \BIn \APACrefbtitleICSE, 2003 ICSE, 2003 (\BPGS 455–464). \PrintBackRefs\CurrentBib
Noyrit \BOthers. (\APACyear2010) \APACinsertmetastarConsistentModelingUsingMultipleUMLProfiles.{APACrefauthors}Noyrit, F., Gérard, S., Terrier, F.\BCBL \BBA Selic, B. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleConsistent Modeling Using Multiple UML Profiles Consistent modeling using multiple UML profiles.\BBCQ \BIn \APACrefbtitleMODELS 2010 MODELS 2010 (\BPGS 392–406). \PrintBackRefs\CurrentBib
Nuseibeh \BOthers. (\APACyear2000) \APACinsertmetastarMakinginconsistencyrespectableinsoftwaredevelopment{APACrefauthors}Nuseibeh, B., Easterbrook, S.\BCBL \BBA Russo, A. \APACrefYearMonthDay200001. \BBOQ\APACrefatitleMaking Inconsistency Respectable in Software Development Making inconsistency respectable in software development.\BBCQ \APACjournalVolNumPagesJournal of Systems and Software58171-180. \PrintBackRefs\CurrentBib
Ou \BOthers. (\APACyear2009) \APACinsertmetastarAnEmpiricalApproachtoModelingUncertaintyinIntrusionAnalysis{APACrefauthors}Ou, X., Rajagopalan, S\BPBIR.\BCBL \BBA Sakthivelmurugan, S. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleAn Empirical Approach to Modeling Uncertainty in Intrusion Analysis An empirical approach to modeling uncertainty in intrusion analysis.\BBCQ \BIn \APACrefbtitleACSAC 2009 ACSAC 2009 (\BPGS 494–503). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Paradkar \BBA Klinger (\APACyear2004) \APACinsertmetastarAutomatedconsistencyandcompletenesscheckingoftestingmodelsforinteractivesystems{APACrefauthors}Paradkar, A\BPBIM.\BCBT \BBA Klinger, T. \APACrefYearMonthDay2004. \BBOQ\APACrefatitleAutomated Consistency and Completeness Checking of Testing Models for Interactive Systems Automated consistency and completeness checking of testing models for interactive systems.\BBCQ \BIn \APACrefbtitleCOMPSAC 2004 COMPSAC 2004 (\BPGS 342–348). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Perrouin \BOthers. (\APACyear2009) \APACinsertmetastarComposingModelsforDetectingInconsistencies-ARequirementsEngineeringPerspective.{APACrefauthors}Perrouin, G., Brottier, E., Baudry, B.\BCBL \BBA Traon, Y\BPBIL. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleComposing Models for Detecting Inconsistencies: A Requirements Engineering Perspective Composing models for detecting inconsistencies: A requirements engineering perspective.\BBCQ \BIn \APACrefbtitleREFSQ 2009 REFSQ 2009 (\BPGS 89–103). \PrintBackRefs\CurrentBib
Petersen \BOthers. (\APACyear2008) \APACinsertmetastarPetersen2008{APACrefauthors}Petersen, K., Feldt, R., Mujtaba, S.\BCBL \BBA Mattsson, M. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleSystematic Mapping Studies in Software Engineering Systematic mapping studies in software engineering.\BBCQ \BIn G. Visaggio, M\BPBIT. Baldassarre, S\BPBIG. Linkman\BCBL \BBA M. Turner (\BEDS), \APACrefbtitleEASE 2008. EASE 2008. \APACaddressPublisherBCS. \PrintBackRefs\CurrentBib
Petersen \BOthers. (\APACyear1997) \APACinsertmetastarFlexibleUpdatePropagationforWeaklyConsistentReplication.{APACrefauthors}Petersen, K., Spreitzer, M., Terry, D\BPBIB., Theimer, M.\BCBL \BBA Demers, A\BPBIJ. \APACrefYearMonthDay1997. \BBOQ\APACrefatitleFlexible Update Propagation for Weakly Consistent Replication Flexible update propagation for weakly consistent replication.\BBCQ \BIn \APACrefbtitleSOSP 1997 SOSP 1997 (\BPGS 288–301). \PrintBackRefs\CurrentBib
Prasetya \BBA Klomp (\APACyear2019) \APACinsertmetastarTestModelCoverageAnalysisUnderUncertainty.{APACrefauthors}Prasetya, I\BPBIS\BPBIW\BPBIB.\BCBT \BBA Klomp, R. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleTest Model Coverage Analysis Under Uncertainty Test model coverage analysis under uncertainty.\BBCQ \BIn \APACrefbtitleSEFM 2019 SEFM 2019 (\BPGS 222–239). \PrintBackRefs\CurrentBib
Ramirez \BOthers. (\APACyear2012) \APACinsertmetastarRelaxingclaims:copingwithuncertaintywhileevaluatingassumptionsatruntime{APACrefauthors}Ramirez, A\BPBIJ., Cheng, B\BPBIH\BPBIC., Bencomo, N.\BCBL \BBA Sawyer, P. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleRelaxing Claims: Coping with Uncertainty While Evaluating Assumptions at Run Time Relaxing claims: Coping with uncertainty while evaluating assumptions at run time.\BBCQ \BIn R\BPBIB. France, J. Kazmeier, R. Breu\BCBL \BBA C. Atkinson (\BEDS), \APACrefbtitleMODELS 2012 MODELS 2012 (\BVOL 7590, \BPGS 53–69). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Reder (\APACyear2011) \APACinsertmetastarInconsistencymanagementframeworkformodel-baseddevelopment.{APACrefauthors}Reder, A. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleInconsistency management framework for model-based development Inconsistency management framework for model-based development.\BBCQ \BIn \APACrefbtitleICSE 2011 ICSE 2011 (\BPGS 1098–1101). \PrintBackRefs\CurrentBib
Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt1) \APACinsertmetastarComputingrepairtreesforresolvinginconsistenciesindesignmodels.{APACrefauthors}Reder, A.\BCBT \BBA Egyed, A. \APACrefYearMonthDay2012\BCnt1. \BBOQ\APACrefatitleComputing repair trees for resolving inconsistencies in design models Computing repair trees for resolving inconsistencies in design models.\BBCQ \BIn \APACrefbtitleASE 2012 ASE 2012 (\BPGS 220–229). \PrintBackRefs\CurrentBib
Reder \BBA Egyed (\APACyear2012\APACexlab\BCnt2) \APACinsertmetastarIncrementalConsistencyCheckingforComplexDesignRulesandLargerModelChanges.{APACrefauthors}Reder, A.\BCBT \BBA Egyed, A. \APACrefYearMonthDay2012\BCnt2. \BBOQ\APACrefatitleIncremental Consistency Checking for Complex Design Rules and Larger Model Changes Incremental consistency checking for complex design rules and larger model changes.\BBCQ \BIn \APACrefbtitleMODELS 2012 MODELS 2012 (\BPGS 202–218). \PrintBackRefs\CurrentBib
Reder \BBA Egyed (\APACyear2013) \APACinsertmetastarDeterminingtheCauseofaDesignModelInconsistency{APACrefauthors}Reder, A.\BCBT \BBA Egyed, A. \APACrefYearMonthDay2013. \BBOQ\APACrefatitleDetermining the Cause of a Design Model Inconsistency Determining the cause of a design model inconsistency.\BBCQ \APACjournalVolNumPagesIEEE Trans. Software Eng.39111531–1548. \PrintBackRefs\CurrentBib
Riedl-Ehrenleitner \BOthers. (\APACyear2014) \APACinsertmetastarTowardsModel-and-CodeConsistencyChecking.{APACrefauthors}Riedl-Ehrenleitner, M., Demuth, A.\BCBL \BBA Egyed, A. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleTowards Model-and-Code Consistency Checking Towards model-and-code consistency checking.\BBCQ \BIn \APACrefbtitleCOMPSAC 2014 COMPSAC 2014 (\BPGS 85–90). \PrintBackRefs\CurrentBib
Rose \BOthers. (\APACyear2009) \APACinsertmetastarEnhancedAutomationforManagingModelandMetamodelInconsistency.{APACrefauthors}Rose, L\BPBIM., Kolovos, D\BPBIS., Paige, R\BPBIF.\BCBL \BBA Polack, F\BPBIA\BPBIC. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleEnhanced Automation for Managing Model and Metamodel Inconsistency Enhanced automation for managing model and metamodel inconsistency.\BBCQ \BIn \APACrefbtitleASE 2009 ASE 2009 (\BPGS 545–549). \PrintBackRefs\CurrentBib
Sabetzadeh \BOthers. (\APACyear2008) \APACinsertmetastarGlobalconsistencycheckingofdistributedmodelswithTReMer+.{APACrefauthors}Sabetzadeh, M., Nejati, S., Easterbrook, S\BPBIM.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleGlobal consistency checking of distributed models with TReMer+ Global consistency checking of distributed models with tremer+.\BBCQ \BIn \APACrefbtitleICSE 2008 ICSE 2008 (\BPGS 815–818). \PrintBackRefs\CurrentBib
Sabetzadeh \BOthers. (\APACyear2007) \APACinsertmetastarConsistencyCheckingofConceptualModelsviaModelMerging.{APACrefauthors}Sabetzadeh, M., Nejati, S., Liaskos, S., Easterbrook, S\BPBIM.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2007. \BBOQ\APACrefatitleConsistency Checking of Conceptual Models via Model Merging Consistency checking of conceptual models via model merging.\BBCQ \BIn \APACrefbtitleRE 2007 RE 2007 (\BPGS 221–230). \PrintBackRefs\CurrentBib
Salay, Chechik\BCBL \BBA Gorzny (\APACyear2012) \APACinsertmetastarTowardsaMethodologyforVerifyingPartialModelRefinements{APACrefauthors}Salay, R., Chechik, M.\BCBL \BBA Gorzny, J. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleTowards a Methodology for Verifying Partial Model Refinements Towards a methodology for verifying partial model refinements.\BBCQ \BIn G. Antoniol, A. Bertolino\BCBL \BBA Y. Labiche (\BEDS), \APACrefbtitleICST 2012 ICST 2012 (\BPGS 938–945). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Salay, Chechik\BCBL \BBA Horkoff (\APACyear2012) \APACinsertmetastarManagingrequirementsuncertaintywithpartialmodels{APACrefauthors}Salay, R., Chechik, M.\BCBL \BBA Horkoff, J. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleManaging requirements uncertainty with partial models Managing requirements uncertainty with partial models.\BBCQ \BIn M\BPBIP\BPBIE. Heimdahl \BBA P. Sawyer (\BEDS), \APACrefbtitleRE 2012 RE 2012 (\BPGS 1–10). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Salay, Famelis\BCBL \BBA Chechik (\APACyear2012) \APACinsertmetastarLanguageindependentrefinementusingpartialmodeling{APACrefauthors}Salay, R., Famelis, M.\BCBL \BBA Chechik, M. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleLanguage Independent Refinement Using Partial Modeling Language independent refinement using partial modeling.\BBCQ \BIn J. de Lara \BBA A. Zisman (\BEDS), \APACrefbtitleFASE 2012 FASE 2012 (\BVOL 7212, \BPGS 224–239). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Salih \BOthers. (\APACyear2017) \APACinsertmetastarSalih2017{APACrefauthors}Salih, A\BPBIM., Omar, M.\BCBL \BBA Yasin, A. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleUnderstanding Uncertainty of Software Requirements Engineering: A Systematic Literature Review Protocol Understanding uncertainty of software requirements engineering: A systematic literature review protocol.\BBCQ \BIn M. Kamalrudin, S. Ahmad\BCBL \BBA N. Ikram (\BEDS), \APACrefbtitleAPRES 2017 APRES 2017 (\BVOL 809, \BPGS 164–171). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Schoenboeck \BOthers. (\APACyear2014) \APACinsertmetastarCAREaconstraintbasedapproachforreestablishingconformancerelationships{APACrefauthors}Schoenboeck, J., Kusel, A., Etzlstorfer, J., Kapsammer, E., Schwinger, W., Wimmer, M.\BCBL \BBA Wischenbart, M. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleCARE - A Constraint-Based Approach for Re-Establishing Conformance-Relationships CARE - A constraint-based approach for re-establishing conformance-relationships.\BBCQ \BIn G. Grossmann \BBA M. Saeki (\BEDS), \APACrefbtitleAPCCM 2014 APCCM 2014 (\BVOL 154, \BPGS 19–28). \APACaddressPublisherAustralian Computer Society. \PrintBackRefs\CurrentBib
Serban \BOthers. (\APACyear2020) \APACinsertmetastarTowardsUsingProbabilisticModelstoDesignSoftwareSystemswithInherentUncertainty{APACrefauthors}Serban, A., Poll, E.\BCBL \BBA Visser, J. \APACrefYearMonthDay2020. \BBOQ\APACrefatitleTowards Using Probabilistic Models to Design Software Systems with Inherent Uncertainty Towards using probabilistic models to design software systems with inherent uncertainty.\BBCQ \BIn \APACrefbtitleECSA 2020 ECSA 2020 (\BPGS 89–97). \PrintBackRefs\CurrentBib
Shan \BBA Zhu (\APACyear2004) \APACinsertmetastarConsistencyCheckinModellingMulti-AgentSystems.{APACrefauthors}Shan, L.\BCBT \BBA Zhu, H. \APACrefYearMonthDay2004. \BBOQ\APACrefatitleConsistency Check in Modelling Multi-Agent Systems Consistency check in modelling multi-agent systems.\BBCQ \BIn \APACrefbtitle(COMPSAC 2004 (COMPSAC 2004 (\BPGS 114–119). \PrintBackRefs\CurrentBib
Shan \BBA Zhu (\APACyear2006) \APACinsertmetastarSpecifyingConsistencyConstraintsforModellingLanguages.{APACrefauthors}Shan, L.\BCBT \BBA Zhu, H. \APACrefYearMonthDay2006. \BBOQ\APACrefatitleSpecifying Consistency Constraints for Modelling Languages Specifying consistency constraints for modelling languages.\BBCQ \BIn \APACrefbtitleSEKE 2006 SEKE 2006 (\BPGS 578–583). \PrintBackRefs\CurrentBib
Siavashi \BBA Truscan (\APACyear2015) \APACinsertmetastarSiavashi2015{APACrefauthors}Siavashi, F.\BCBT \BBA Truscan, D. \APACrefYearMonthDay2015. \BBOQ\APACrefatitleEnvironment modeling in model-based testing: concepts, prospects and research challenges: a systematic literature review Environment modeling in model-based testing: concepts, prospects and research challenges: a systematic literature review.\BBCQ \BIn J. Lv, H\BPBIJ. Zhang\BCBL \BBA M\BPBIA. Babar (\BEDS), \APACrefbtitleEASE 2015 EASE 2015 (\BPGS 30:1–30:6). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Sottet \BBA Biri (\APACyear2016) \APACinsertmetastarJSMFaJavascriptFlexibleModellingFramework{APACrefauthors}Sottet, J\BHBIS.\BCBT \BBA Biri, N. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleJSMF: a Javascript Flexible Modelling Framework Jsmf: a javascript flexible modelling framework.\BBCQ \BIn \APACrefbtitleFlexMDE@MoDELS 2016 Flexmde@models 2016 (\BVOL 1694, \BPGS 42–51). \APACaddressPublisherCEUR-WS.org. \PrintBackRefs\CurrentBib
Stevens (\APACyear2014) \APACinsertmetastarBidirectionallyToleratingInconsistency-PartialTransformations.{APACrefauthors}Stevens, P. \APACrefYearMonthDay2014. \BBOQ\APACrefatitleBidirectionally Tolerating Inconsistency: Partial Transformations Bidirectionally tolerating inconsistency: Partial transformations.\BBCQ \BIn \APACrefbtitleFASE 2014 FASE 2014 (\BPGS 32–46). \PrintBackRefs\CurrentBib
Stevens (\APACyear2017) \APACinsertmetastarBidirectionalTransformationsintheLarge{APACrefauthors}Stevens, P. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleBidirectional Transformations in the Large Bidirectional transformations in the large.\BBCQ \BIn \APACrefbtitleMODELS 2017 MODELS 2017 (\BPGS 1–11). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Stevens (\APACyear2018\APACexlab\BCnt1) \APACinsertmetastarIsBidirectionalityImportant{APACrefauthors}Stevens, P. \APACrefYearMonthDay2018\BCnt1. \BBOQ\APACrefatitleIs Bidirectionality Important? Is bidirectionality important?\BBCQ \BIn \APACrefbtitleECMFA 2018 ECMFA 2018 (\BPGS 1–11). \PrintBackRefs\CurrentBib
Stevens (\APACyear2018\APACexlab\BCnt2) \APACinsertmetastarTowardssoundoptimalandflexiblebuildingfrommegamodels{APACrefauthors}Stevens, P. \APACrefYearMonthDay2018\BCnt2. \BBOQ\APACrefatitleTowards sound, optimal, and flexible building from megamodels Towards sound, optimal, and flexible building from megamodels.\BBCQ \BIn \APACrefbtitleMODELS 2018 MODELS 2018 (\BPGS 301–311). \PrintBackRefs\CurrentBib
Straeten \BOthers. (\APACyear2003) \APACinsertmetastarUsingDescriptionLogictoMaintainConsistencybetweenUMLModels{APACrefauthors}Straeten, R\BPBIV\BPBID., Mens, T., Simmonds, J.\BCBL \BBA Jonckers, V. \APACrefYearMonthDay2003. \BBOQ\APACrefatitleUsing Description Logic to Maintain Consistency between UML Models Using description logic to maintain consistency between UML models.\BBCQ \BIn P. Stevens, J. Whittle\BCBL \BBA G. Booch (\BEDS), \APACrefbtitleUML 2003 UML 2003 (\BVOL 2863, \BPGS 326–340). \APACaddressPublisherSpringer. \PrintBackRefs\CurrentBib
Szvetits \BBA Zdun (\APACyear2016) \APACinsertmetastarSzvetits2016{APACrefauthors}Szvetits, M.\BCBT \BBA Zdun, U. \APACrefYearMonthDay2016. \BBOQ\APACrefatitleSystematic literature review of the objectives, techniques, kinds, and architectures of models at runtime Systematic literature review of the objectives, techniques, kinds, and architectures of models at runtime.\BBCQ \APACjournalVolNumPagesSoftware and Systems Modeling15131–69. \PrintBackRefs\CurrentBib
Tang \BOthers. (\APACyear2008) \APACinsertmetastarArnetMiner:ExtractionAndMiningOfAcademicSocialNetworks{APACrefauthors}Tang, J., Zhang, J., Yao, L., Li, J., Zhang, L.\BCBL \BBA Su, Z. \APACrefYearMonthDay2008. \BBOQ\APACrefatitleArnetMiner: extraction and mining of academic social networks Arnetminer: extraction and mining of academic social networks.\BBCQ \BIn Y. Li, B. Liu\BCBL \BBA S. Sarawagi (\BEDS), \APACrefbtitleKDD 2008 KDD 2008 (\BPGS 990–998). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Tran \BBA Massacci (\APACyear2014) \APACinsertmetastarAnApproachforDecisionSupportontheUncertaintyinFeatureModelEvolution{APACrefauthors}Tran, L\BPBIM\BPBIS.\BCBT \BBA Massacci, F. \APACrefYearMonthDay201409. \BBOQ\APACrefatitleAn Approach for Decision Support on the Uncertainty in Feature Model Evolution An approach for decision support on the uncertainty in feature model evolution.\BBCQ \BIn \APACrefbtitleRE 2014 RE 2014 (\BPG 93-102). \PrintBackRefs\CurrentBib
Trollmann \BOthers. (\APACyear2011) \APACinsertmetastarFormalizingmodelconsistencybasedontheabstractsyntax.{APACrefauthors}Trollmann, F., Blumendorf, M., Schwartze, V.\BCBL \BBA Albayrak, S. \APACrefYearMonthDay2011. \BBOQ\APACrefatitleFormalizing model consistency based on the abstract syntax Formalizing model consistency based on the abstract syntax.\BBCQ \BIn \APACrefbtitleEICS 2011 EICS 2011 (\BPGS 79–84). \PrintBackRefs\CurrentBib
Vallecillo \BOthers. (\APACyear2016) \APACinsertmetastarExpressingMeasurementUncertaintyinSoftwareModels{APACrefauthors}Vallecillo, A., Morcillo, C.\BCBL \BBA Orue, P. \APACrefYearMonthDay2016Sep.. \BBOQ\APACrefatitleExpressing Measurement Uncertainty in Software Models Expressing measurement uncertainty in software models.\BBCQ \BIn \APACrefbtitleQUATIC 2016 QUATIC 2016 (\BPG 15-24). \PrintBackRefs\CurrentBib
Vierhauser \BOthers. (\APACyear2010) \APACinsertmetastarFlexibleandscalableconsistencycheckingonproductlinevariabilitymodels.{APACrefauthors}Vierhauser, M., Grünbacher, P., Egyed, A., Rabiser, R.\BCBL \BBA Heider, W. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleFlexible and scalable consistency checking on product line variability models Flexible and scalable consistency checking on product line variability models.\BBCQ \BIn \APACrefbtitleASE 2010 ASE 2010 (\BPGS 63–72). \PrintBackRefs\CurrentBib
Vierhauser \BOthers. (\APACyear2012) \APACinsertmetastarApplyingaConsistencyCheckingFrameworkforHeterogeneousModelsandArtifactsinIndustrialProductLines.{APACrefauthors}Vierhauser, M., Grünbacher, P., Heider, W., Holl, G.\BCBL \BBA Lettner, D. \APACrefYearMonthDay2012. \BBOQ\APACrefatitleApplying a Consistency Checking Framework for Heterogeneous Models and Artifacts in Industrial Product Lines Applying a consistency checking framework for heterogeneous models and artifacts in industrial product lines.\BBCQ \BIn \APACrefbtitleMODELS 2012 MODELS 2012 (\BPGS 531–545). \PrintBackRefs\CurrentBib
Vouk \BOthers. (\APACyear1990) \APACinsertmetastarModelingexecutiontimeofmulti-stageN-versionfault-tolerantsoftware.{APACrefauthors}Vouk, M\BPBIA., Paradkar, A\BPBIM.\BCBL \BBA McAllister, D\BPBIF. \APACrefYearMonthDay1990. \BBOQ\APACrefatitleModeling execution time of multi-stage N-version fault-tolerant software Modeling execution time of multi-stage n-version fault-tolerant software.\BBCQ \BIn \APACrefbtitleProceedings of the Fourteenth Annual International Computer Software and Applications Conference, COMPSAC 1990, Chicago, IL, USA, October 31 1990 - November 2, 1990 Proceedings of the fourteenth annual international computer software and applications conference, COMPSAC 1990, chicago, il, usa, october 31 1990 - november 2, 1990 (\BPGS 505–511). \PrintBackRefs\CurrentBib
Vukovic \BOthers. (\APACyear2018) \APACinsertmetastarVukovic2018{APACrefauthors}Vukovic, V., Djurkovic, J.\BCBL \BBA Trninic, J. \APACrefYearMonthDay2018. \BBOQ\APACrefatitleA Business Software Testing Process-Based Model Design A business software testing process-based model design.\BBCQ \APACjournalVolNumPagesInternational Journal of Software Engineering and Knowledge Engineering285701–750. \PrintBackRefs\CurrentBib
B. Wang \BOthers. (\APACyear2010) \APACinsertmetastarADynamic-PriorityBasedApproachtoFixingInconsistentFeatureModels.{APACrefauthors}Wang, B., Xiong, Y., Hu, Z., Zhao, H., Zhang, W.\BCBL \BBA Mei, H. \APACrefYearMonthDay2010. \BBOQ\APACrefatitleA Dynamic-Priority Based Approach to Fixing Inconsistent Feature Models A dynamic-priority based approach to fixing inconsistent feature models.\BBCQ \BIn \APACrefbtitleMODELS 2010 MODELS 2010 (\BPGS 181–195). \PrintBackRefs\CurrentBib
C. Wang \BBA Cavarra (\APACyear2009) \APACinsertmetastarCheckingModelConsistencyUsingData-FlowTesting.{APACrefauthors}Wang, C.\BCBT \BBA Cavarra, A. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleChecking Model Consistency Using Data-Flow Testing Checking model consistency using data-flow testing.\BBCQ \BIn \APACrefbtitleAPSEC 2009 APSEC 2009 (\BPGS 414–421). \PrintBackRefs\CurrentBib
Weidmann \BOthers. (\APACyear2019) \APACinsertmetastarWeidmann2019{APACrefauthors}Weidmann, N., Anjorin, A., Fritsche, L., Varró, G., Schürr, A.\BCBL \BBA Leblebici, E. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleIncremental Bidirectional Model Transformation with eMoflon: : IBeX Incremental bidirectional model transformation with emoflon: : Ibex.\BBCQ \BIn J. Cheney \BBA H. Ko (\BEDS), \APACrefbtitleBx@PLW 2019 Bx@PLW 2019 (\BVOL 2355, \BPGS 45–55). \APACaddressPublisherCEUR-WS.org. \PrintBackRefs\CurrentBib
Wolfe \BOthers. (\APACyear2009) \APACinsertmetastarAnIncrementalAlgorithmforHigh-PerformanceRuntimeModelConsistency.{APACrefauthors}Wolfe, C., Graham, T\BPBIC\BPBIN.\BCBL \BBA Phillips, W\BPBIG. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleAn Incremental Algorithm for High-Performance Runtime Model Consistency An incremental algorithm for high-performance runtime model consistency.\BBCQ \BIn \APACrefbtitleMODELS 2009 MODELS 2009 (\BPGS 357–371). \PrintBackRefs\CurrentBib
Wolny \BOthers. (\APACyear2020) \APACinsertmetastarWolny2020{APACrefauthors}Wolny, S., Mazak, A., Carpella, C., Geist, V.\BCBL \BBA Wimmer, M. \APACrefYearMonthDay2020. \BBOQ\APACrefatitleThirteen years of SysML: a systematic mapping study Thirteen years of sysml: a systematic mapping study.\BBCQ \APACjournalVolNumPagesSoftware and Systems Modeling191111–169. \PrintBackRefs\CurrentBib
Wortmann \BOthers. (\APACyear2020) \APACinsertmetastarWortmann2020{APACrefauthors}Wortmann, A., Barais, O., Combemale, B.\BCBL \BBA Wimmer, M. \APACrefYearMonthDay2020. \BBOQ\APACrefatitleModeling languages in Industry 4.0: an extended systematic mapping study Modeling languages in industry 4.0: an extended systematic mapping study.\BBCQ \APACjournalVolNumPagesSoftware and Systems Modeling19167–94. \PrintBackRefs\CurrentBib
Wortmann \BOthers. (\APACyear2017) \APACinsertmetastarWortmann2017{APACrefauthors}Wortmann, A., Combemale, B.\BCBL \BBA Barais, O. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleA Systematic Mapping Study on Modeling for Industry 4.0 A systematic mapping study on modeling for industry 4.0.\BBCQ \BIn \APACrefbtitleMODELS 2017 MODELS 2017 (\BPGS 281–291). \APACaddressPublisherIEEE Computer Society. \PrintBackRefs\CurrentBib
Xiong \BOthers. (\APACyear2009) \APACinsertmetastarSupportingautomaticmodelinconsistencyfixing{APACrefauthors}Xiong, Y., Hu, Z., Zhao, H., Song, H., Takeichi, M.\BCBL \BBA Mei, H. \APACrefYearMonthDay2009. \BBOQ\APACrefatitleSupporting automatic model inconsistency fixing Supporting automatic model inconsistency fixing.\BBCQ \BIn H. van Vliet \BBA V. Issarny (\BEDS), \APACrefbtitleESEC/SIGSOFT FSE 2009 ESEC/SIGSOFT FSE 2009 (\BPGS 315–324). \APACaddressPublisherACM. \PrintBackRefs\CurrentBib
Yu \BBA Vahdat (\APACyear2000) \APACinsertmetastarDesignandevaluationofacontinuousconsistencymodelforreplicatedservices{APACrefauthors}Yu, H.\BCBT \BBA Vahdat, A. \APACrefYearMonthDay2000. \BBOQ\APACrefatitleDesign and Evaluation of a Continuous Consistency Model for Replicated Services Design and evaluation of a continuous consistency model for replicated services.\BBCQ \BIn \APACrefbtitleOSDI 2000. OSDI 2000. \APACaddressPublisherUSAUSENIX Association. \PrintBackRefs\CurrentBib
Zhang \BOthers. (\APACyear2017) \APACinsertmetastarUncertaintywiseevolutionoftestreadymodels{APACrefauthors}Zhang, M., Ali, S., Yue, T.\BCBL \BBA Norgren, R. \APACrefYearMonthDay2017. \BBOQ\APACrefatitleUncertainty-wise evolution of test ready models Uncertainty-wise evolution of test ready models.\BBCQ \APACjournalVolNumPagesInf. Softw. Technol.87140–159. \PrintBackRefs\CurrentBib
Zhang \BOthers. (\APACyear2019) \APACinsertmetastarUncertaintyWiseCyberPhysicalSystemtestmodeling{APACrefauthors}Zhang, M., Ali, S., Yue, T., Norgren, R.\BCBL \BBA Okariz, O. \APACrefYearMonthDay2019. \BBOQ\APACrefatitleUncertainty-Wise Cyber-Physical System test modeling Uncertainty-wise cyber-physical system test modeling.\BBCQ \APACjournalVolNumPagesSoftw. Syst. Model.1821379–1418. \PrintBackRefs\CurrentBib
Zolotas \BOthers. (\APACyear2016) \APACinsertmetastarConstraintprogrammingfortypeinferenceinflexiblemodeldrivenengineering{APACrefauthors}Zolotas, A., Clarisó, R., Matragkas, N., Kolovos, D.\BCBL \BBA Paige, R. \APACrefYearMonthDay201612. \BBOQ\APACrefatitleConstraint Programming for Type Inference in Flexible Model-Driven Engineering Constraint programming for type inference in flexible model-driven engineering.\BBCQ \APACjournalVolNumPagesComputer Languages, Systems & Structures49. \PrintBackRefs\CurrentBib