Djamel Eddine Khelladi
email: djamel-eddine.khelladi@irisa.fr

Roland Kretschmer
email: roland.kretschmer@jku.at

Alexander Egyed
email: alexander.egyed@jku.at

Detecting and Exploring Side Effects when Repairing Model Inconsistencies

Keywords: engineering → Model-driven software engineering; Software maintenance tools Model Inconsistencies, Repairs, Consequences, Side effects

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

CCS Concepts • Software and its

Introduction

Model-Driven Engineering (MDE) has shown to be effective in the development and maintenance of large scale and embedded systems [START_REF] Hutchinson | Empirical assessment of MDE in industry[END_REF][START_REF] Liebel | Assessing the state-of-practice of model-based engineering in the embedded systems domain[END_REF]. MDE typically puts models as a central artifact in the various phases of the development process [START_REF] Hutchinson | Modeldriven engineering practices in industry[END_REF][START_REF] Douglas | Model-driven engineering[END_REF]. Indeed, models are used in all development stages, from specifying the customer's requirements, design, all the way to source code, with the benefits of increased productivity and reduced time to market [START_REF] Anastasakis | UML2Alloy: A challenging model transformation[END_REF][START_REF] Cicchetti | Automating co-evolution in model-driven engineering[END_REF][START_REF] Whittle | The state of practice in model-driven engineering[END_REF]. These benefits, however, hinge on the assumption that models remain consistent during development which is a problem when changes happen. Changes often do cause inconsistencies. If these inconsistencies are not recognized in a timely manner, then they cause subsequent errors. Moreover, if models are inconsistent, all automation (e.g., analysis [START_REF] Cabot | Incremental integrity checking of UML/OCL conceptual schemas[END_REF] or model transformation [START_REF] Lúcio | Model transformation intents and their properties[END_REF]) using them is untrustworthy and likely causes even more errors. Therefore, inconsistencies must not only be detected but ultimately be repaired [START_REF] Demuth | Introducing Traceability and Consistency Checking for Change Impact Analysis across Engineering Tools in an Automation Solution Company: An Experience Report[END_REF][START_REF] William | Software reuse research: Status and future[END_REF][START_REF] Whittle | The state of practice in model-driven engineering[END_REF].

Detecting and repairing model inconsistencies is widely addressed in the literature (e.g., [START_REF] Hegedüs | Quick fix generation for DSMLs[END_REF][START_REF] Kolovos | Detecting and Repairing Inconsistencies across Heterogeneous Models[END_REF][START_REF] Macedo | Model repair and transformation with Echo[END_REF][START_REF] Nentwich | Consistency Management with Repair Actions[END_REF][START_REF] Pinna Puissant | Resolving model inconsistencies using automated regression planning[END_REF][START_REF] Reder | Computing repair trees for resolving inconsistencies in design models[END_REF][START_REF] Taentzer | Change-Preserving Model Repair[END_REF][START_REF] Xiong | Supporting automatic model inconsistency fixing[END_REF], see related work section 6.). The existing approaches typically compute a set of repairs for each of the detected inconsistencies. Studies reported on the adoption of inconsistency detection and repair in various industries, such as by Thales a company in aeronautic, transport, and security [START_REF] Le Noir | Operation based model representation: experiences on inconsistency detection[END_REF], and Van Hoecke Automation a company in the areas of production automation and processing [START_REF] Demuth | Introducing Traceability and Consistency Checking for Change Impact Analysis across Engineering Tools in an Automation Solution Company: An Experience Report[END_REF]. In this paper, we argue that merely proposing repairs is not yet sufficient, and consequences of repairs must be handled too. In addition to fixing a given inconsistency, repairs can also cause side effects that software developers are not aware of (empirical evidence is given later in this paper). A side effect of a given repair either can repair other inconsistencies (referred to as a positive side effect) or can cause new inconsistencies (referred to as a negative side effect). For example, with two conflicting simple consistency rules (imagine they are about the number of lectures a student can enroll in) CR1[l > 5] and CR2[l < 15]. Repairing one inconsistency, e.g., of CR1 because l = 2, by changing l to l = 20, would cause another inconsistency (of CR2) as a negative side effect. To make matters worse, repairing a negative side effect can in turn cause additional side effects, e.g., CR2 by changing l = 20 to l = 4 which causes again CR1. This can lead to a path and a cycle of repairs causing successive negative side effects. A path is a sequence of repairs fixing their arising negative side effects. A cycle occurs when repairing a negative side effect causes a previously repaired inconsistency (i.e., a closed path), such as between CR1 and CR2. Not considering side effects can unfortunately increase developers' effort and time spent in repairing inconsistencies. Furthermore, when repairs are computed they are typically not ranked w.r.t. to the likelihood of usefulness to developers. To the best of our knowledge, no existing approach (e.g., [START_REF] Hegedüs | Quick fix generation for DSMLs[END_REF][START_REF] Kolovos | Detecting and Repairing Inconsistencies across Heterogeneous Models[END_REF][START_REF] Macedo | Model repair and transformation with Echo[END_REF][START_REF] Nentwich | Consistency Management with Repair Actions[END_REF][START_REF] Pinna Puissant | Resolving model inconsistencies using automated regression planning[END_REF][START_REF] Reder | Computing repair trees for resolving inconsistencies in design models[END_REF][START_REF] Taentzer | Change-Preserving Model Repair[END_REF][START_REF] Xiong | Supporting automatic model inconsistency fixing[END_REF]) explored side effects in depth nor ranked repairs based on the gained side effect knowledge when repairing model inconsistencies. Thus, leaving the burden of understanding and tracking the repairs consequences to the developers. Our novel approach fills this gap. Repairs causing side effects should not be filtered but rather considered and must be explored incrementally. Thus, guiding developers until the models are consistent.

Providing developers with information about side effects is crucial. On the one hand, developers can prioritize repairs with positive side effects, which reduces the repairing effort (i.e., 1 repair for n inconsistencies). On the other hand, developers can avoid, and most importantly be aware of, repairs with negative side effects and their possible paths and cycles. Ultimately, we aim to guide developers for a more efficient repairing process of inconsistencies. The novel contributions of this paper w.r.t. the state of the art are as follows:

• First, we identify positive side effects for each computed repair. This allows us to highlight to developers repairs that fix many inconsistencies at once. • Second, we identify negative side effects for each computed repair. This allows us to warn developers about repairs that cause additional inconsistencies. We also explore the negative side effects recursively and thus guiding developers step by step in repairing them. • Third, we identify paths and cycles of repairs caused by negative side effects. In so doing, we aim to prevent developers from being trapped in a cycle of repairs unknowingly.

• Fourth, we propose a ranking strategy of repairs based on the gained knowledge of side effects. This aims to rank repairs w.r.t. their likelihood of usefulness to developers.

We have empirically evaluated the performance, feasibility, and usefulness of our approach on 14 case studies. The evaluation results show that side effects not only exist but are frequent, where 398 repairs caused 12166 side effects and 151 cycles. Our evaluation also showed the usefulness of our ranking strategy as it correctly prioritized repairs that developers actually applied on our versioned models. Furthermore, we conducted a controlled experiment with 24 participants that highlighted a significant influence on developers when provided with side effect knowledge. Developers with side effect knowledge applied far more repairs with positive side effects [START_REF] Khelladi | A framework to formally verify conformance of a software process to a software method[END_REF] and far less with negative side effects [START_REF] Correa | Refactoring object constraint language specifications[END_REF], while being 12.3% faster. In contrast to developers without side effect knowledge who chose far less repairs with positive side effects (4) and far more with negative side effects [START_REF] Khelladi | A framework to formally verify conformance of a software process to a software method[END_REF].

Challenges and Motivation

To illustrate the issue of side effects when repairing model inconsistencies, we reuse the simple example of a video on demand (VOD) system from Egyed et al. [START_REF] Egyed | Instant consistency checking for the UML[END_REF] which is based on a client-server architecture. This example consists of three diagrams modeled with the Unified Modeling Language (UML) [START_REF] Omg | Unified Modeling Language[END_REF]. Figure 1 The class diagram represents the structure of a movie player. A User initiates the process of selecting and displaying a movie, a Display is used for visualizing movies and receiving user input and a Streamer is used for decoding movies. The sequence diagram describes the process of selecting and playing a movie, while showing the interaction between the instances of the classes User, Display, and Streamer. Here a user starts by selecting a movie (i.e., call of the operation select), and then the display starts streaming the movie (i.e., call of the operation stream). The Streamer object then sends frames to the Display instance via message draw. The streaming of the movie can also be paused with the message pause sent from Display to Streamer. The state chart diagram finally shows the states of the class Streamer in the VOD system, i.e., wait and stream.

Inconsistencies can be repaired if and only if they are detected [START_REF] Reder | Determining the Cause of a Design Model Inconsistency[END_REF]. An established practice for detecting inconsistencies is to express consistency rules on models, which are the foundation to understand their failure, i.e., presence of an inconsistency. The consistency rules can be specified with the well-established standard Object Constraint Language (OCL) [START_REF] Omg | Object Constraint Language[END_REF]. For the sake of simplicity, let us give an informal description of three structural consistency rules from the UML specification [START_REF] Omg | Object Management Group. Unified Modeling Language (UML)[END_REF]: Alternative repairs can be proposed for the two inconsistencies VI and VII meeting different developers needs. For instance, adding a message wait would repair VI. However, among those possible repairs, some may have either positive or negative side effects. For example, to repair VI one could rename the message pause to wait so that the transition wait has a corresponding message. This repairs VI Another possible repair of VI could be to rename the transition wait to pause, so that the transition would have a corresponding message. This repair has an undesired negative side effect that causes a new inconsistency VIII (see below) which must be repaired as well. This leads to a path of two subsequent repairs, the first one fixing VI and the second one fixing its negative side effect VIII. To make matters worst, repairing VIII can in turn cause a negative side effect. For example, repairing VIII by renaming the transition pause to wait would again cause the inconsistency VI. This situation might then lead to a cycle of repairs that would be continuously executed. The developer would be trapped in a cycle that would repair VI and VIII where repairing one causes the other. In such a simple case, cycles could be easily handled. However, cycles of multiple repairs are an issue in particular when the models are worked on by multiple developers that are unaware of each others' changes.

CR1
VIII Violation III of CR3 Transition pause has no corresponding operation in class Streamer.

The example depicted in Figure 1 already shows non trivial side effects occurring with few simple consistency rules. These phenomena are amplified the more consistency rules are defined and the more inconsistencies are detected. In particular, when consistency rules are interrelated where the same model elements are used by multiple consistency rules, e.g., the model element Transition in CR1 and CR3. This is indeed very common in practice as was observed by Nöhrer et al. [START_REF] Nöhrer | Positive effects of utilizing relationships between inconsistencies for more effective inconsistency resolution (NIER track)[END_REF]. There, it was found that relationships among the consistency rules, and thus among inconsistencies, not only exist but are common [START_REF] Nöhrer | Positive effects of utilizing relationships between inconsistencies for more effective inconsistency resolution (NIER track)[END_REF].

Therefore, it becomes crucial to not simply list repairs but also to detect their side effects, paths, and cycles to better support developers when repairing inconsistencies with relevant feedback and guidance. This paper aims to fill this gap.

Background

This section provides definitions and examples of the most important terms for a prompt understanding of this paper.

Definition 1. A model M consists of elements (e ∈ M) having properties accessible with the dot (.) operator, e.g., "e.p". Definition 2. A scope element is a model element and its corresponding properties (e.p) accessed during the validation of a consistency rule. A set of scope elements is called a scope. Definition 3. A cause i of an inconsistency (i) is all the scope elements that violate the corresponding consistency rule. Hence, a cause is a subset of a scope.

To detect inconsistencies, a given consistency rule is instantiated for each model element as the context of the consistency rules. For example, the consistency rule CR1 is instantiated for every transition wait and stream in the state machine diagram in Figure 1. We refer to such instances as validation trees which are defined as follows.

Definition 4. A validation tree consists of a set of hierarchical ordered (tree-based) expressions and represents the Abstract Syntax Tree of a consistency rule for a specific model element. An expression consists of its operation (op) (e.g, logical AND (∧), equals (=)), one or more children (children) which are also expressions, exactly one parent expression (parent) and values to be validated (se2v).

e := ⟨op, children, parent, se2v⟩

An example of a validation tree is shown in Figure 2 on the transition wait for the consistency rule CR1. Every validation tree validates to a boolean value in its root expression. Only those that validate to false are inconsistencies for which repairs are computed, e.g., the case transition wait in Figure 2. Note that the instances returning true are ignored when computing repairs but they are not removed because a repair could affect them as a side effect. The validation trees are used as a basis in the current approach to explore side effects. This will further be explained in the next Section 4. Definition 5. A repair action (ra) is a change to a model element property that resolves an inconsistency in part or full (often multiple repair actions are needed to resolve an inconsistency). A repair action contains the model element (e), the property (p) that is affected by the change, the type of change (ch), and a value (v), which can be a model element v ∈ M, or a primitive value v ∈ V. The following types of changes are possible: ⊕ adds, ⊖ deletes, and ⊙ updates.

ra := ⟨e, p, ch, v⟩, ch ∈ {⊕, ⊖, ⊙},
Note that it might be necessary to change multiple scope elements to fix an inconsistency. For that purpose, we define a group of repair actions as follows. Definition 6. A repair is a non empty collection of repair actions that is guaranteed to fix an inconsistency (i).

⟨i ∈ I, ra ⊆ RA i ⟩ As repairs may have side effects, we define them as follows.

Definition 7. A repair with a positive side effect (pse) is a repair that fixes more than one (≥ 2) inconsistency. Definition 8. A repair with a negative side effect (nse) is a repair that causes at least one (≥ 1) new inconsistency.

Note that a side effect can be caused by repairs from different inconsistencies. As repairing negative side effects can cause side effects, we define a graph of side effects. Definition 9. A side effect graph is a directed graph G = (V , E) where V is the set of all vertices and E the set of all directed edges. Vertices represent repairs and edges represent side effects (positive(+) or negative(-)) a repair has on another inconsistency, and thus on its repairs. We define an edge as the triple (v 1 , v 2 , +|-), where v 1 is the source vertex, v 2 is the target vertex and +|is the type of side effect (either positive (+) or negative(-)). Figure 3 shows an example of a constructed side effect graph. Definition 10. A path of repairs causing negative side effects is a sequence of consecutive edges ((v 1 , v 2 , -), (v 2 , v 3 , -), . . . , (v x , v y , -)) which only consists of edges with negative side effects (-). The start edge (v 1 , v 2 , -) and the end edge (v x , v y , -) must not be the same ((v 1 , v 2 ) (v x , v y ), no cycles allowed). Definition 11. A cycle of repairs causing negative side effects is a path ((v 1 , v 2 , -), . . . , (v x , v y , -)) where the start and end edge is the same ((v 1 , v 2 ) = (v x , v y )).

How do we Detect Inconsistencies?

In the validation tree, the root expression is expected to validate to true (i.e., consistent) and so its children expressions. For example, in Figure 2 the ∃ and = expressions are also expected to validate to true. If the root expression validates to false, then we detect an inconsistency. To compute the validation result of a validation tree, we start from the leafs (bottom) and start computing the validation result of the subexpressions (parent nodes) and continue this process until the root expression.

How do we Generate Repair Actions?

Before to compute the repairs, we first need to identify the cause of an inconsistency. The cause is all scope elements that are part of a violated expression, i.e., where validation result differs from ( ) expected result. The cause in the example of Figure 2 is the transition wait, messages pause and stream and the lifeline Streamer.To generate repair actions we iterate over every scope element in the cause and look for every violated expression were the scope element is used. We then generate a repair action so that the direct violated parent expression is validated.

Overall Approach

This section presents our approach that explores side effects when repairing inconsistencies, before to focus on evaluating it. First, it computes the repairs for the model inconsistencies. For that we use our previous work 1 . However, our current approach is designed to utilize repairs computed by any of the existing related approaches (in section VI). After that we identify the side effects for each computed repair and we explore the side effect recursively to identify paths and cycles of repairs. Finally, we propose to rank the repairs based on the gained side effect knowledge to better support developers in deciding how to repair their model inconsistencies.

Identifying Positive and Negative Side Effects

As introduced in Section 3, the validation trees are instantiations of consistency rules. Those that validate to false are treated as inconsistencies for which repairs are computed. For example, the instance of the consistency rule CR1 (from section 2) on the transition wait validates to false since it has no corresponding message. Whereas, the instance of the consistency rule CR3 on the transition wait validates to true since it has a corresponding operation.

Algorithm 1 presents our detection and exploration algorithm of side effects. It first computes a finite set of repairs 1 We omit references to comply with the double blind rules. end for 20: end function for the inconsistencies, and then simulates on an internal copy of the model each repair on its inconsistency (lines 2-4). After that we monitor which other validation trees validate to a different boolean value than before (lines 5-17). If so, a side effect is detected and further investigated. Otherwise, the repair is considered as a side effect free. Depending on how the validation of an instance changes (from true to false or from false to true), either a positive or a negative side effect is detected (lines 4-8).

Positive Side Effects

In case the validation results of other validation trees change from false to true (after simulating a given repair), this is then identified as a positive side effect (lines 6-10). In the example shown in section 2, repairing the inconsistency VI by renaming the message pause to wait also repairs the inconsistency VII. This repair is then listed as causing a positive side effect along with its affected inconsistencies (line 9).

Negative Side Effects

In case the validation results of other validation trees change from true to false after simulating a given repair, this is then identified as a negative side effect (lines 11-16). Again, on the example shown in section 2, repairing the inconsistency VI by renaming the message wait to pause also causes the inconsistency VIII. This repair is then listed as causing a negative side effect along with its affected inconsistencies (line 14). Note that when a negative side effect is identified, i.e., a new inconsistency is caused, we compute its repairs and in turn we explore recursively their side effects (line 15). This is crucial in particular when exploring the negative side effects in depth and also identifying paths and cycles of repairs that the developer might be trapped in.

Paths and Cycles Detection

Already while detecting the side effects for each repair, we incrementally construct a graph that links the different repairs from the different inconsistencies (line 17). The graph consists of nodes that are repairs and edges linking repairs pairwise. An edge can be of type positive side effect or of type negative side effect, as defined in Definition 9. Figure 3 gives an excerpt example of a graph based on the inconsistencies and repairs from section 2. The first repair for the inconsistency VI has a positive side effect on the repairs for VII. Whereas the third repair for VI has a negative side effect on the repairs for VIII which in turn has positive and negative side effects on respectively VII and VI. Here, even though a repair has several arrows to other repairs from the same inconsistency, such as VI-R1 in Figure 3, we do not count each edge as a different side effect. Instead we count them as one side effect on the inconsistency, e.g., the repair VI-R1 as one positive side effect on VII in Figure 3.

Note that we also represent the repairs for the negative side effects, i.e., new inconsistencies that would arise after the execution of a given repair (not present in the initial state of the model). This can be seen as a projection of the future states of the model after executing a given repair.

This graph now is used as a basis to detect paths and cycles of repairs due to negative side effects. To do so, we use the simple paths and cycles detection algorithms from the open source library JGraphT (http://jgrapht.org/).

Ranking the Repairs Based on Side Effect Knowledge

In our approach, we further propose to sort the computed repairs based on the gained knowledge of side effects. Similar idea was applied by Cuadrado et al. [START_REF] Sánchez Cuadrado | Quick fixing ATL transformations with speculative analysis[END_REF] and showed to be useful. The rationale behind our ranking mechanism is: i) to reduce the developer effort and time when repairing inconsistencies by prioritizing repairs with positive side effects, ii) warn developers about the presence of negative side effects, paths and cycles, and iii) guide developers in repairing all inconsistencies, in particular repairing the negative side effects. Thus, we propose to rank the repairs for each inconsistency as the following:

1. The repairs with only positive side effects are prioritized. This category of repairs receive the priority "very high". Note that herein the repairs are ranked from those with the most positive side effects to the least ones. 2. The repairs without side effects are then listed to the developer. This category of repairs receive the priority "high". We rank first the repairs with the least repair actions (lowest effort) up to those with the most repair actions (highest effort). 3. After that, we list the repairs that have both positive and negative side effects. This category of repairs receive the priority "medium". We compute the difference between the number of positive side effects and the number of negative side effects (di f f = #pse -#nse).

Then we rank the repairs based on their di f f value with a decreasing order (e.g., 10, 6, 2, -1, -3 ...). Thus, prioritizing repairs which cause more positive than negative side effects. 4. Finally, the repairs with only negative side effects are the least prioritized. This category of repairs receive the priority "low". First, we rank repairs from those with the least to the most number of negative side effects. Second, we list the repairs that trigger a path/cycle of negative side effects. We rank them from the smallest (with the least number of repairs) to the longest paths/cycles.

Repairs would thus be sorted and presented per inconsistency for developers. An example of our ranking strategy on the three repairs for the inconsistency VI in Figure 1 is as follows:

▷ Inconsistency VI #R1 Rename the message pause to wait -causes a positive side effect on VII. #R2 Add a message wait -no side effects. #R3 Rename the transition wait to pause -causes a negative side effect on VIII.

Note that in the end, only developers decide which repairs to apply. Repairs with negative side effects can be useful as well for developers. In that case, our approach ensures that developers track the side effects and repairs them later on.

Evaluation

This section evaluates our approach performance, feasibility and usefulness. Our evaluation consists of two parts.

At first, we assess the feasibility of our approach on 14 UML models (class, sequence, state chart, deployment, use case diagrams) taken from three different sources: academia (VOD), industry (eBullition, MVC, Micro, ATM, Course, Planner, Dice3, Home, Robot, Vacation) and GitHub (Pro11, FullAdder, ActMgr) [START_REF] Hebig | The quest for open source projects that use UML: mining GitHub[END_REF]. The domains of the models range from control of a micro wave oven and an inventory storage management system to a Vacation and Sick Leave System. The model sizes range from 284 to 4485 model elements (e.g., class, lifeline, message, state, transitions, their properties, etc.). To detect inconsistencies, we used 20 complex consistency rules taken from the UML specification [START_REF] Omg | Object Management Group. Unified Modeling Language (UML)[END_REF]. The number of inconsistencies ranges from 7 to 78, and the number of all repairs from 9 to 26682. Table 1 details our data set used in the evaluation, i.e., the number of model elements, number of inconsistencies, number of repairs, and their sources. Three of these models are from GitHub and have two versions each, where version one had inconsistencies that had been fixed in version two by a developer. This further allows us to assess the usefulness of our ranking strategy based on side effects, i.e. whether the manually applied repairs by the developers were among the prioritized ones with our ranking strategy or with the least prioritized. The time performance was also measured when detecting side effects in depth.

After that, we further assess with a controlled experiment the influence of the side effects that are detected by our approach on 24 participants divided in two groups. The first group receives side effect knowledge and ranked repairs (with our ranking strategy in section 4.3), and the second group not.

Note that our implementation has a compilation module integrated to check the syntactical correctness of the OCL consistency rules. The used dataset, consistency rules, and constructed side effects graphs can be found on our anonymized companion web page2 .

Research Questions

We formulate the following research questions:

RQ1 To what extent do positive side effects occur? This aims to investigate the frequency of positive side effects. RQ2 To what extent do negative side effects occur? And what are the path lengths of negative side effects that occur recursively? This also aims to investigate the frequency of negative side effects and their consequences. This aims to assess the time performances and scalability. RQ6 To what extent does side effect knowledge influence developers when repairing inconsistencies? This aims to determine whether developers behave differently when side effects knowledge is available and when it is not. This also aims to further assess our approach's usefulness.

Results

We first report on the initialization phase. Detecting inconsistencies (i.e., creation of validation trees) took milliseconds per inconsistency. After computing repairs, we created the side effects graphs, which took minutes to generate (<1 minute for VOD to 10 minutes for eBullition). Now we report on the obtained results when tracking side effects in depth. Figure 4 gives the number of repairs that do have side effects and repairs without side effects. The amount of repairs causing side effects varied from 2 (ActivityManager model) to 145 (MVC model) resulting in a total of 398 repairs with side effects in our case studies. Figure 5 further shows the numbers of all side effects for each case study 3 . The number of all side effects varied from 10 (ActivityManager model) to 7463 (MVC model) resulting in a total of 12166 side effects caused by 398 repairs. It is worth noting from Figures 4 and5 that only few repairs in each case study tend to result in a large number of side effects. For example, in the MVC model only 145 repairs resulted in 7463 side effects.

RQ1

The number of repairs causing positive side effects varied from 2 (ActivityManager model) to 145 (MVC model) in our case studies, as shown in Figure 6. Figure 7 further shows the number of identified positive side effects in all case studies. The number of positive side effects varied from 4 (VOD model) to 7460 (MVC model). Moreover, columns 2 and 3 of Table 2 gives the minimum and maximum number of positive side effects caused by a single repair in each case study, which was a minimum of 1 (MVC model) and a maximum of 74 (Vacation model). This shows that positive side effects are frequent and could benefit developers, in reducing time and effort, if they would be prioritized over the rest of repairs.

RQ2

The number of repairs that caused negative side effects varied from 1 (MVC model) to 27 (FullAdder model) in our case studies, as shown in Figure 6. Among our case studies the eight models ActivityManager, Pro11, Micro, Course, Planner, Dice3, Home, Vacation did not have negative side effects. Among the rest of the case studies, the number of the identified negative side effects varied from 3 (MVC model) to 199 (eBullition model), as shown in Figure 7. We also observed the number of negative side effects caused by a single repair in each case study which was a minimum of 1 (e.g., ATM model) and a maximum of 32 (eBullition model), as in columns 4 and 5 in Table 2.

Moreover, for each negative side effect we computed their repairs and explored their side effects recursively. Some repairs in turn resulted in negative side effects themselves, and thus resulting in a path of successive repairs. The minimum and maximum path length of negative side effects were respectively 1 and 8 (VOD model), as shown in columns 6 and 7 in Table 2. This confirms that successive negative side effects occur in practice and thus it is crucial to highlight them to developers.

It is worth noting that we encountered repairs that caused both positive and negative side effects. In particular, MVC, FullAdder, VOD, and ATM respectively had one, two, two, and three repairs with both positive and negative side effects.

RQ3

In addition to the identified paths of negative side effects, we detected 151 cycles in total varying from 3 (eBullition model) to 70 (VOD model), as shown in Figure 8. Similarly with the path length of negative side effects, we calculated the length of cycles which varied from 2 (minimum possible length of a cycle) to 6 (VOD model) repairs included in a cycle, as shown in columns 8 and 9 in Table 2. The results confirm that cycles are frequent, and hence, it is essential to detect them so that developers would not be trapped in them.

RQ4

To investigate the usefulness of our ranking strategy, we applied it to three versioned models (ActMgr, Pro11, and FullAdder) retrieved from GitHub. Every model contains inconsistencies in version 1 that the developer had manually fixed in version 2 (since the inconsistencies are not present anymore).We were able to extract the repairs performed by the developers. We thus could investigate if our approach would have prioritized those repairs with a high ranking.

We found that the applied repairs in ActMgr, Pro11, and FullAdder were all ranked in both the categories very high (with only positive side effects) and high (without side effects). In particular, 1) in ActMgr two repairs were applied where one caused positive side effects and one without side effects, 2) in Pro11 three repairs without side effects were applied (herein not all inconsistencies were repaired in the second version), and 3) in FullAdder three repairs were applied where two caused positive side effects (category high) and one without side effects. This shows that all three developers applied only repairs with positive side effects and without side effects. Our ranking strategy thus would have met the developers needs by indeed prioritizing the manually applied repairs among all computed alternative repairs in our three versioned models. This shows evidence of the usefulness of our performed ranking. However, for statistical evidence, more versioned models are needed for further evaluation.

RQ5

During evaluation we recorded time performances 4 while detecting side effects, paths, and cycles. We ran our evaluation on a desktop PC with an intel core i7-6700 3.4GHz

Processor and 32GB of RAM on Windows 10. Each side effect took us less than 0,1 milliseconds to detect, even in the biggest models. As shown in column 10 of Table 2, detecting the paths and cycles due to successive negative side effects took us less than 65 milliseconds in the worst case. Hence, showing that our approach scales on large models with a large number of repairs and side effects.

RQ6 -Controlled Experiment

In RQ4 we saw that the side effect knowledge showed to be useful in prioritizing the repairs that developers actually applied manually. However, that does not investigate the influence of side effects on developers when repairing inconsistencies. To gain more evidence we conducted a controlled experiment.

Experiment Set Up

Subjects selection. The controlled experiment was run with 24 participants (8 females and 16 males), all master 4 Not including the initialization phase, i.e., after generating the validation trees, repairs and side effects graphs (10min for the largest model). Nonetheless, the whole process of detecting inconsistencies, computing repairs with their side effects, summed together, remains a matter of couple of minutes for the largest models.

students in computer science at JKU university. All participants had knowledge in the field of modeling and consistency checking. Five had no professional programming experience and 19 had between 1 and 14 years of programming experience. Overall, they had an average of 2 years and 4 months of experience as developers. Experiment Design. Our participants were randomly assigned to a control and an experimental groups of 12 each. Hence, alleviating the threat of having all best participants in one group. Then, we checked that both groups were balanced w.r.t. to: i) professional programming experience, which was respectively 2.2 and 2.6 years, and ii) modeling experience which was respectively 2.4 and 2.5 years.

Experiment Task. We used a medium sized UML model consisting of Class, Sequence, and State chart diagrams, fitting for the limited time allocated for the experiment. This model is simple and similar to the VOD, yet exhibiting constructions present in our industry models. Each of the 24 participants had to repair a set of six inconsistencies from the three consistency rules shown in Section 2. Those inconsistencies are realistic as they occurred in our models from industry and their consistency rules are from the UML specification [START_REF] Omg | Object Management Group. Unified Modeling Language (UML)[END_REF]. For each inconsistency, a set of repairs was provided (a minimum of 8 repairs and a maximum of 14 repairs) from which one had to be chosen. A total of 68 repairs is given for the six inconsistencies. Among the 68 repairs, 12 have positive side effects, 24 have negative side effects, and 32 have no side effects. Thus, for the 24 participants and six inconsistencies, we had to analyze 144 chosen Table 3. Mean time spent to repair the inconsistencies.

Groups Repair Time Difference

With side effect knowledge 13 min 40 sec 1 min 55 sec Without side effect knowledge 15 min 35 sec repairs. The experimental group had side effect knowledge with ranked repairs (as described in section 4.3). The control group had not. The experiment thus set the initial condition to explore whether side effect knowledge can make a difference when repairing inconsistencies. At the end we gave a questionnaire about the complexity of tasks, and feedback on usefulness.

Variables. The experiment was aiming to measure the influence on subjects resolving inconsistencies when side effect knowledge was provided in contrast to when it was not. This was the independent variable we controlled, i.e., presence or not of side effects knowledge. To measure its effect, we observed two dependent variables, namely: the time developers took to repair the inconsistencies and the types of the chosen repairs, i.e., repairs with positive side effects, without side effects, and with negative side effects.

Experiment Results

We first checked for normality using the Shapiro-Wilk test [START_REF] Samuel | An analysis of variance test for normality (complete samples)[END_REF]. The recorded times passed the normality test. Table 3 shows the recorded mean time it took developers from both groups to repair all given inconsistencies. We observed that developers with side effect knowledge performed faster than those without, with a difference of roughly 2 minutes, i.e., 12.3% faster. This shows that relying on side effect knowledge seems to accelerate the decision time when repairing inconsistencies.

Moreover, from the 144 selected repairs we analyzed the number of repairs for the three categories, namely: with positive, with negative, and without side effects, as shown in Figure 9. On the one hand, developers with side effect knowledge favored 30 repairs with positive side effects and only selected 8 repairs with negative side effects, but repaired the new inconsistencies afterward. All of the 12 developers here applied at least 2 (and some applied at most 4) repairs with positive side effects. Only eight developers knowingly applied exactly 1 repair with negative side effects. On the other hand, developers without side effect knowledge chose only 4 repairs with positive side effects and selected 30 repairs with negative side effects, but did not repair the new inconsistencies since they were not even aware of them. Here all of the 12 developers applied at least 2 (and some applied at most 3) repairs with negative side effects. Only two developers unknowingly applied exactly 2 repairs with positive side effects. The number of repairs without side effect was relatively the same in both groups (34 vs 38). We also checked the position of the selected repairs. We observed that they were from different positions, and were not simply in the first or second position, which indicate a non-random choice of repairs. These results highlight the significant benefit and influence of side effect knowledge to developers, where the number of repairs with positive and negative side effects are proportionally inversed in both groups.

We further gave a questionnaire to the participants. Let us highlight the main observations. In the group that did not have side effect knowledge, (to the question 'Did you consider side effects when repairing the inconsistencies?') seven out of the 12 developers answered that they have considered possible side effects when selecting a repair. However, as shown in Figure 9, they nonetheless applied few repairs with positive side effects and many repairs with negative side effects. They failed in correctly tracking side effects, and hence, this emphasizes the necessity of an automatic detection and tracking approach of side effects. In the other group that did have side effect knowledge, (to the question 'How useful was the ranking of repairs based on side effect knowledge to choose a repair?'5 ) six out of the 12 developers graded our ranking strategy as 'useful', four graded it as 'very useful', and two graded it as 'extremely useful'. This further emphasizes the usefulness (discussed in RQ4) of ranking repairs based on side effect knowledge to developers. From our controlled experiment, we can conclude that the knowledge of side effects seems to positively influence the way developers repairs their inconsistencies, in both time and type of chosen repairs.

Threats to Validity

In this section we discuss internal, external and conclusion threats to validity according to Wohlin et. al. [START_REF] Wohlin | Experimentation in software engineering[END_REF].

Internal Validity

In our evaluation, the internal threats to validity are centered on the used consistency rules and the amount of repairs. The number of detected side effects depends on the used consistency rules and to what extent they are interrelated. We provided our used consistency rules for reproducibility purposes. The number of side effects also depends on the number of considered repairs. However, considering more repairs would only increase the number of side effects, and not the opposite. In this paper, we aimed to show that side effects are frequent and that we are able to efficiently explore them in depth. This threat is acceptable here. Moreover, our approach depends on the validation trees which are instances of OCL consistency rules specified by the user. We only check their syntactic correctness, but not their semantic correctness/completeness since only the user knows its intent. This might affect the detection of side effects. However, we took our consistency rules from the UML specification [START_REF] Omg | Object Management Group. Unified Modeling Language (UML)[END_REF]. In addition, by systematically simulating each repair and monitoring how the results of validation trees changes, we ensure the detection of all existing side effects.

External Validity

We implemented and evaluated our approach on UML/OCL and our previous work of repair computation. We cannot generalize our results to other modeling/constraint languages and other approaches of repair computation. However, the only requirement to reuse our approach is to have access to instances of consistency rules with an equivalence to the validation trees. Other constraint languages than OCL can be used. Moreover, as existing approaches computes similar repairs to ours (see definition 5). Reusing our detection algorithms of side effects, paths/cycles, and the ranking heuristic would be equally good as in the current approach. Nonetheless, further experimentation is necessary. In our experiment, we selected master students as participants. Recent studies [START_REF] Salman | Are students representatives of professionals in software engineering experiments?[END_REF][START_REF] Svahnberg | Using students as subjects-an empirical evaluation[END_REF] showed that students can be valid and well representative subjects for experiments and development tasks. Nonetheless, to further reduce this threat, we selected master students in their final year. They had an average of 2 Years and 4 months professional programming experience, which is near to a junior developer experience.

Conclusion Validity

Our evaluation gave promising results (quantitatively and qualitatively), demonstrating that our detection algorithms of side effects and paths/cycles is very fast and efficiently explores repairs' side effects. The evaluation results also showed evidence that our ranking strategy showed to be useful in prioritizing the developers applied repairs. These results are further emphasized by our controlled experiment that showed the benefit in giving side effect knowledge to developers. However, we only evaluated on 14 models (3 versioned ones) with a total of 32387 repairs in all our case studies, and only 24 students in our experiment. To have more statistical evidence, we plan to evaluate on more (versioned) models and reproduce our experiment with more participants.

Related Work

This section focuses on works most related to the topic of detecting and repairing model inconsistencies and exploring side effect. Many approaches proposed to co-evolve models [START_REF] Cicchetti | Automating co-evolution in model-driven engineering[END_REF][START_REF] Garcés | Managing model adaptation by precise detection of metamodel changes[END_REF][START_REF] Herrmannsdoerfer | COPE-automating coupled evolution of metamodels and models[END_REF][START_REF] Kessentini | Automated metamodel/model co-evolution: A search-based approach[END_REF][START_REF] Kessentini | Integrating the Designer in-the-loop for Metamodel/Model Co-Evolution via Interactive Computational Search[END_REF][START_REF] Wachsmuth | Metamodel adaptation and model coadaptation[END_REF], constraints [START_REF] Batot | Heuristic-Based Recommendation for Metamodel-OCL Coevolution[END_REF][START_REF] Correa | Refactoring object constraint language specifications[END_REF][START_REF] Djamel | A semi-automatic maintenance and co-evolution of OCL constraints with (meta) model evolution[END_REF][START_REF] Djamel | Metamodel and constraints coevolution: A semi automatic maintenance of ocl constraints[END_REF][START_REF] Kusel | Systematic Co-Evolution of OCL Expressions[END_REF], and model transformations [START_REF] Garcés | Adapting transformations to metamodel changes via external transformation composition[END_REF][START_REF] García | Model transformation co-evolution: A semi-automatic approach[END_REF][START_REF] Kessentini | Automated Co-evolution of Metamodels and Transformation Rules: A Search-Based Approach[END_REF][START_REF] Djamel | Change Propagation-based and Composition-based Co-evolution of Transformations with Evolving Metamodels[END_REF][START_REF] Djamel | An Exploratory Experiment on Metamodel-Transformation Co-Evolution[END_REF][START_REF] Kusel | Consistent co-evolution of models and transformations[END_REF]. However, coevolution approaches repair a particular type of inconsistencies w.r.t. metamodels conformance [START_REF] Hebig | Surveying the corpus of model resolution strategies for metamodel evolution[END_REF][START_REF] Hebig | Approaches to co-evolution of metamodels and models: A survey[END_REF]. Here we focus on model repair. All existing approaches to detect inconsistencies use various techniques. Briand et al. [START_REF] Lionel C Briand | Automated impact analysis of UML models[END_REF] proposed an approach to check UML consistency and by applying an impact analysis to identify consistencies in UML models. Konig et al. [START_REF] König | Efficient Consistency Checking of Interrelated Models[END_REF] proposed an algorithm for consistency checking on inter-related models to reduce cost of inconsistency detection due to model merging. There is also approaches that relies on formal methods to detect inconsistencies (e.g., [START_REF] Cabot | Verification of UML/OCL class diagrams using constraint programming[END_REF][START_REF] Khelladi | A framework to formally verify conformance of a software process to a software method[END_REF][START_REF] Snook | UML-B: Formal modeling and design aided by UML[END_REF]). However, those approaches do not propose repairs.

Nentwich et al. [START_REF] Nentwich | Consistency Management with Repair Actions[END_REF] provided an incremental approach for checking the consistency of distributed heterogeneous documents including models. They presented a method for generating repairs from the consistency rules. Xiong et al. [START_REF] Xiong | Supporting automatic model inconsistency fixing[END_REF] presented an approach that detects inconsistencies and allows users to predefine repair actions associated with each consistency rule. The consistency rules are defined with their proposed language Beanbag that defines a consistency relation between model elements similarly as in OCL. Kolovos et al. [START_REF] Kolovos | Detecting and Repairing Inconsistencies across Heterogeneous Models[END_REF] proposed to address inconsistencies across heterogeneous models and provide repair strategies for those constraints. They established a classification of the different types of relationships that exist between heterogeneous models and to identify the types of inconsistencies each relationship suffers from. Da Silva et al. [START_REF] Aurélio Almeida Da Silva | Towards Automated Inconsistency Handling in Design Models[END_REF] propose to compute repairs to resolve inconsistencies in their UML models. However, valid repairs that do have side effects are filtered. We argue that all valid repairs must be considered and side effects of a chosen repair by the developer should be repaired incrementally. Thus, guiding the engineer until the models are consistent once again. Hegedues et al. [START_REF] Hegedüs | Quick fix generation for DSMLs[END_REF] defined in a graphical notation consistency rules and uses a Constraint Satisfaction Problem solver to suggest repairs for inconsistencies for Domain Specific Modeling Languages. Egyed et al. [START_REF] Egyed | Automatically Detecting and Tracking Inconsistencies in Software Design Models[END_REF] proposed an automated approach for detecting and tracking inconsistencies in design models in real time. They do this by observing the behavior of consistency rules to understand how they are affected by model changes. Reder et al. [START_REF] Reder | Incremental Consistency Checking for Complex Design Rules and Larger Model Changes[END_REF] proposed an incremental consistency checking approach. Reder et al. [START_REF] Reder | Computing repair trees for resolving inconsistencies in design models[END_REF] further generate repairs for inconsistencies while pinpointing exactly which parts of an inconsistency must be repaired. Macedo et al. [START_REF] Macedo | Model repair and transformation with Echo[END_REF] rely on Alloy [START_REF] Jackson | Alloy: a lightweight object modelling notation[END_REF] to generate minimal repairs for inter-related models. Puissant et al. [START_REF] Pinna Puissant | Resolving model inconsistencies using automated regression planning[END_REF] proposed a planning technique to generate repair plans for inconsistencies while aiming at a fast computation of repairs without assessing the relevance of the repair plans. Taentzer et al. [START_REF] Taentzer | Change-Preserving Model Repair[END_REF] proposed to repair inconsistent models w.r.t. their metamodels. They do not explore all possible repairs by relying on the model change history which helps in reducing the amount of repairs.

Although, the above existing approaches [START_REF] Hegedüs | Quick fix generation for DSMLs[END_REF][START_REF] Kolovos | Detecting and Repairing Inconsistencies across Heterogeneous Models[END_REF][START_REF] Macedo | Model repair and transformation with Echo[END_REF][START_REF] Nentwich | Consistency Management with Repair Actions[END_REF][START_REF] Pinna Puissant | Resolving model inconsistencies using automated regression planning[END_REF][START_REF] Reder | Computing repair trees for resolving inconsistencies in design models[END_REF][START_REF] Taentzer | Change-Preserving Model Repair[END_REF][START_REF] Xiong | Supporting automatic model inconsistency fixing[END_REF] provide repairs to developers, no approach proposed to explore in depth the side effects of the computed model repairs, as it is achieved in this paper. Briand et al. [START_REF] Lionel C Briand | Automated impact analysis of UML models[END_REF], used the term of side effect. However, only in the sense of identifying inconsistencies caused by model changes. Reder et al. [START_REF] Reder | Computing repair trees for resolving inconsistencies in design models[END_REF] identify positive side effects by computing the intersection between repairs of different inconsistencies. However, they did not explore negative side effects. To the best of our knowledge, no related work in model repair addressed explicitly and completely the issue of exploring side effects in depth and detecting paths and cycles. Developers are left with the burden of understanding and tracking the repairs consequences (what side-effects? where? which impacted elements?) without even being aware of them.

However, existing works on repairing programs and transformations do explore side effects. Muslu et al. [START_REF] Muşlu | Speculative analysis of integrated development environment recommendations[END_REF] proposed to detect consequences of the code quick fixes but without exploring paths and cycles. Steimann et al. [START_REF] Steimann | Computing repair alternatives for malformed programs using constraint attribute grammars[END_REF] proposed to repair malformd programs. They explored the consequences (side effects) of the repairs successively, i.e., compute in advance paths of repairs. However, they do not explore nor detect the cycles of repairs. Both Muslu et al. [START_REF] Muşlu | Speculative analysis of integrated development environment recommendations[END_REF] and Steimann et al. [START_REF] Steimann | Computing repair alternatives for malformed programs using constraint attribute grammars[END_REF] also do not rank the repairs as we do in this paper. Cuadrado et al. [START_REF] Sánchez Cuadrado | Quick fixing ATL model transformations[END_REF] proposed to compute quick fixes for ATL transformations. They also proposed in [START_REF] Sánchez Cuadrado | Quick fixing ATL transformations with speculative analysis[END_REF] to detect positive and negative side effects for each quick fix. The main difference with our work is they do not explore negative side effect in depth and do not detect paths and cycles. Moreover, they further rank the quick fixes in a similar way as our strategy, but without distinguishing fixes with negative side effects that lead to paths and cycles from those that do not. To the best our of knowledge all existing approaches of model repair compute repairs without knowing their side effects and without ranking them w.r.t the likelihood of usefulness to developers, as we do in this work.

Conclusion

In this paper, we presented an approach for detecting and tracking positive and negative side effects. Then, based on the successive negative side effects, we detect paths and cycles of repairs to better guide and support developers in repairing model inconsistencies. Finally, we rank the repairs w.r.t. their usefulness to developers. Ultimately, to guide developers for a more efficient repairing process of inconsistencies.

In our evaluation, we applied 20 consistency rules to 14 models. The results show that side effects not only exist but they tend to be frequent. In our case studies, 398 repairs caused 12166 side effects and 151 cycles in total. Furthermore, to check the usefulness of our ranking strategy, we used 3 versioned models retrieved from GitHub and found that the repairs manually applied by the developers were indeed among the highest prioritized. Thus showing the usefulness of our ranking strategy. A conducted controlled experiment highlighted the significant influence and useful value of providing developers with side effect knowledge and ranking repairs based on it. Developers with side effect knowledge preferred far more repairs with positive side effects (30 vs 4) and far less with negative side effects (8 vs 30) in contrast to developers without side effect knowledge. While they also required less effort and time to repair the given inconsistencies (12.3% faster).

For future work, we plan to propose heuristics that would break cycles. We also plan to propose other alternative ranking strategies that would meet different developers needs. Finally, we plan to investigate propagation-based repair of inconsistencies. With our detection approaches [START_REF] Djamel | Ad-room: a tool for automatic detection of refactorings in objectoriented models[END_REF][START_REF] Djamel | Detecting complex changes during metamodel evolution[END_REF][START_REF] Djamel | Detecting complex changes and refactorings during (meta) model evolution[END_REF] of the models changes causing inconsistencies, we could propagate them to compute relevant repairs only. For example, it would allow us to not compute undo repairs.

  depicts the three UML diagrams of this system: class diagram, sequence diagram, and state chart diagram.

  Every transition in a state chart diagram has to have a corresponding message in a sequence diagram. CR2 Every message in a sequence diagram has to have a corresponding operation in the class diagram. CR3 Every transition in a state chart diagram has to have a corresponding operation in the class diagram. These consistency rules ensure that there are no undeclared transitions and messages. After checking the above consistency rules, two inconsistencies are detected, respectively: VI Violation I of CR1 Transition wait has no corresponding message in lifeline s:Streamer. VII Violation II of CR2 Message pause has no corresponding operation in class Streamer.

( a )

 a Class diagram. (b) Sequence diagram. (c) State chart diagram of the class Streamer.

Figure 1 .

 1 Figure 1. Side effects in repairing model inconsistencies: An example.

FalseFigure 2 .

 2 Figure 2. Example of validation tree of the transition wait for the Consistency rule CR1.

Figure 3 .

 3 Figure 3. Excerpt of graph construction of side effects for the inconsistency VI in section 2.

Figure 4 .

 4 Figure 4. Number of repairs that do have side effects and that do not have side effects.

Figure 5 .

 5 Figure 5. Number of all caused side effects.

Figure 6 .

 6 Figure 6. Number of repairs causing positive and negative side effects.

Figure 7 .

 7 Figure 7. Ratio of positive and negative side effects.

Figure 8 .

 8 Figure 8. Cycles of negative side effects per case study.

Figure 9 .

 9 Figure 9. Number of selected repairs with positive, negative and without side effects in both groups.

Table 1 .

 1 Model information.

	Model	#Model	#Incon-	#Repairs Source
	Name	Ele-	sisten-
		ments	cies
	ActMgr 1185	7	9	GitHub
	Pro11	284	7	18	GitHub
	FullAdder 992	12	65	GitHub
	Micro	2346	10	34	Industry
	VOD	467	9	46	Academia
	ATM	313	13	763	Industry
	MVC	1410	58	3530	Industry
	eBullition 1346	54	26682	Industry
	Course	1620	42	318	Industry
	Planner 868	17	73	Industry
	Dice3	4485	71	131	Industry
	Home	1882	60	578	Industry
	Robot	1471	24	48	Industry
	Vacation 1805	78	92	Industry

RQ3

To what extent do cycles of repairs occur in our case studies? What is the amount of repairs in a cycle? This aims to investigate the frequency and nature of cycles. RQ4 To what extent is our ranking strategy helpful for developers? This aims to assess the usefulness of our ranking strategy w.r.t. to the likelihood of usefulness to developers. RQ5 How fast can we detect side effects, paths, and cycles?

Table 2 .

 2 Number of positive/negative side effects per repair, length of paths and cycles, and time performances.

		2) Max number	3) Min number	4) Max number	5) Min number	6) Max path	7) Min path			10) Time
								8) Max	9) Min
	1) Case	of positive	of positive	of negative	of negative	length of	length of			detection
								cycle	cycle
	studies	side effects	side effects	side effects	side effects	negative	negative			of paths
		per repair	per repair	per repair	per repair	side effects	side effects	length	length	/cycle [ms]
	ActMgr	6	4	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	Pro11	6	5	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	FullAdder 7	6	7	1	5	1	4	2	1 ms
	Micro	9	6	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	VOD	2	2	3	1	8	1	6	2	3,9 ms
	ATM	11	11	6	1	6	1	4	2	2,1 ms
	MVC	54	1	3	3	1	1	0	0	0,3 ms
	eBullition 30	16	32	1	4	1	2	2	64 ms
	Course	34	20	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	Planner	17	9	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	Dice3	64	44	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	Home	56	31	n/a	n/a	n/a	n/a	n/a	n/a	n/a
	Robot	19	16	16	1	2	1	0	0	4,5 ms
	Vacation 74	44	n/a	n/a	n/a	n/a	n/a	n/a	n/a

https://figshare.com/s/e2c8c67bc94583897786

The number of side effects refers to the number of validation trees that are affected by a given repair, and not the graph edges.

Between 'useless -little useful-useful-very useful-extremely useful'.

Acknowledgment

We would like to thank all participants of the experiment study and our colleagues for the constructive feedback. The research leading to these results has received funding from the CNRS PEPS, and from the AIS Rennes Métropole under grant no. 190270. It is also funded by Pro2Future, a COMET K1-Centre of the Austrian Research Promotion Agency (FFG), grant no. 854184, the LIT Secure and Correct System Lab funded by the State of Upper Austria, and the Austrian Science Fund (FWF), grand no. P31989.


H Smahi

D Ameur
email: d.ameur@yahoo.fr

J Dib

I Raspo

Numerical Study of Adsorption for Fluids Mixture near Critical Point in a Micro-cavity

Keywords: Adsorption, mass transfer, microfluidic, supercritical mixture, Piston effect

L'objectif principal de cet article est l'étude d'une réaction d'adsorption et des transferts de masse associés dans un mélange binaire près du point critique du solvant. Le modèle physique consiste en un mélange dilué (naphtalène-CO 2 supercritique) contenu dans une cavité rectangulaire d'une hauteur de l'ordre de 1 mm et présentant sur sa paroi inférieure une plaque chauffée et adsorbante. Pour tirer parti des propriétés spécifiques du fluide supercritique et optimiser les conditions thermodynamiques permettant une meilleure adsorption avec un bon transfert de masse, les effets de la proximité du point critique et du chauffage font l'objet de plusieurs simulations numériques dans le présent travail. Le modèle mathématique utilisé est basé sur la résolution des équations de Navier-Stokes, couplées aux équations d'énergie et de diffusion des espèces ainsi qu'à l'équation d'état de Peng-Robinson. Afin de réduire les coûts de calcul, ces équations sont résolues dans le cadre de l'approximation à faible nombre de Mach. Le champ de vitesse, la perturbation de la fraction massique ainsi que l'évolution temporelle du nombre moyen de Sherwood sont présentés pour différents chauffages. L'effet de confinement est également analysé. Les résultats montrent que, dans le voisinage du point critique du mélange et pour un fort chauffage de la paroi, on obtient l'adsorption homogène du soluté.Parmi les autres résultats clés, citons que, dans les mêmes conditions optimisées, le transfert de masse sur la plaque adsorbante est meilleur.

perturbation of the mass fraction as well as the temporal evolution of the average Sherwood number are presented for different heatings. The confinement effect is also analysed. The results show that in the mixture critical point neighborhood and for a very high heated wall, the homogeneous adsorption of the solute is obtained. Among other key results, we cite that, under the same optimized conditions, the mass transfer on the adsorbent plate is better.

Introduction

Adsorption allows a selective transfer of species from fluid phase to a solid adsorbent. When an adsorbent is exposed to a fluid phase, the molecules of the fluid phase diffuse on its surface. The type of adsorption isotherm of a particular system can provide a source of information on the surface characteristics and pore properties of the adsorbent.The reversible type isotherm is obtained when the adsorption is limited to a few molecular layers. This condition is generally met for adsorption on microporous materials having small external surfaces such as activated carbons.

Adsorption from supercritical fluids on surfaces or inner surfaces of porous particles is more complex. Very close to the critical temperature, the adsorption isotherm can exhibit a sharp spike near the critical pressure while a decrease of the excess amount adsorbed is observed for larger pressures [START_REF] Do | Adsorption of supercritical fluid in non-porous and porous carbons ; analysis of adsorbed phase volume and density[END_REF]. Adsorption on activated carbon can be associated with Supercritical Fluid Extraction (SFE) for soil remediation. The SFE process has already been used in soil remediation using both propane and CO 2 as a solvent [START_REF] Hall | An overview of solvent extraction treatment technologies[END_REF]. It was applied to organic compounds of different chemical nature, mainly high molecular weight hydrocarbons [START_REF] Becnel | Supercritical fluid extraction of polycyclic aromatic hydrocarbon mixtures from contaminated soils[END_REF]. The extraction of various organics like naphthalene, anthracene, hexachlorobenzene, and phenol from soil using supercritical carbon dioxide has been reported [START_REF] Akgerman | Supercritical Extraction of Hexachlorobenzene from Soil[END_REF]5]. Environmental legislation demands low concentration of contaminants in the soil and therefore, when supercritical solvent is recirculated, the process has to be almost free of contaminant. With volatile pollutants, separation of solvent and solute by decompression is not efficient enough to reach the required low concentration in the soil and a second step of adsorption onto activated carbon is needed. In this context, Madras et al. [START_REF] Madras | Supercritical extraction of organic contaminants from soil combined with adsorption onto activated carbon[END_REF] proposed a process combining supercritical extraction and adsorption for remediation of soils contaminated with heavy molecular weight organic compounds [START_REF] Alonso | Scale-up for a process of supercritical extraction with adsorption of solute onto active carbon. Application to soil remediation[END_REF]. The organic pollutants are continuously extracted using supercritical carbon dioxide and then deposited on activated carbon. It was found that the process would operate in the optimum mode if the desorption of soil was performed at low temperatures followed by adsorption at high temperatures [START_REF] Reverchon | Modelling and simulation of the supercritical adsorption of complex terpene mixtures[END_REF].

A few theoretical or numerical studies were performed on adsorption from supercritical fluids. Lucas et al. [START_REF] Lucas | Mathematical Model of Supercritical CO 2 Adsorption on Activated Carbon Applied to Adsorption Scale-up[END_REF] proposed a model taking into account equilibrium (adsorption isotherm), diffusion in the solid (effective diffusion coefficient), mass transfer from the bulk of the fluid phase (supercritical solvent) to the surface of the solid, axial dispersion (effective dispersion coefficient) and a first order reversible adsorption/desorption reaction at the solid surface site. The three-parameter model proposed for supercritical CO 2 adsorption on activated carbon is able to adjust the experimental data (ethyl acetate for example) with a mean deviation lower than 8%. For a generic heterogeneous reaction (relevant for adsorption/desorption), Raspo et al. [START_REF] Raspo | Heterogeneous reaction induced by piston effect in supercritical binary mixtures[END_REF] showed by numerical simulations that the hydrodynamic behavior of supercritical fluids can couple with the critical behavior of the solubility of solids to trigger the reaction in dilute binary supercritical mixtures. More precisely, by heating the mixture at one side, the Piston effect (through the strong and homogeneous increase of pressure that it provokes in the whole fluid) causes the release of a heterogeneous reaction at the opposite plate that was kept at the initial temperature [START_REF] Raspo | Heterogeneous reaction induced by piston effect in supercritical binary mixtures[END_REF][START_REF] Raspo | Fast mass transfer at a solid-supercritical fluid interface by piston effect[END_REF]. Wannassi and Raspo [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF] investigated the adsorption in a model binary mixture, the naphtalene-CO 2 mixture, near the solvent's critical point in a side-heated cavity. The diverging behavior of the equilibrium constant and the Piston effect were taken into account and their influence on the adsorption process is highlighted. The results showed that, very close to the critical point, the increase of the wall heating remarkably affects the adsorbed amount at the two reactive boundaries and the mass fraction inside the cavity [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF].

To design an adsorption plant, it is necessary to have reliable mass-transfer models that allow the determination of optimum operating conditions and the scale-up. Nevertheless, few attempts have been performed to model the supercritical adsorption process [START_REF] Reverchon | Modelling and simulation of the supercritical adsorption of complex terpene mixtures[END_REF][START_REF] Lucas | Mathematical Model of Supercritical CO 2 Adsorption on Activated Carbon Applied to Adsorption Scale-up[END_REF][START_REF] Kikic | An experimental study of supercritical adsorption equilibria of salicylic acid on activated carbon[END_REF] and most of the efforts have been focused on supercritical fluid extraction [START_REF] Cocero | Mathematical model of supercritical extraction applied to oil seed extraction by CO2+saturated alcohol -I. Desorption model[END_REF]. In this paper, adsorption of a model solute from supercritical CO 2 is investigated in a small side-heated cavity by means of 2D numerical simulations.

Naphthalene was chosen as a model solute because its phase equilibria with CO 2 has been thoroughly studied [START_REF] Raspo | Heterogeneous reaction induced by piston effect in supercritical binary mixtures[END_REF][START_REF] Raspo | Fast mass transfer at a solid-supercritical fluid interface by piston effect[END_REF]. The effects of heating and confinement are discussed. The results show a strong influence of the cavity height.

Physical and mathematical model

The physical model consists of a dilute mixture (Naphthalene-CO 2 ) enclosed in a rectangular cavity of aspect ratio L/H=10 with a heated and adsorbent plate on a part of the bottom boundary as shown in figure 1. Two cavity heights H are considered: 1 and 0.5mm. An adiabatic boundary condition is applied on the non-reactive vertical walls. At time t=0, the fluid is considered in thermodynamic equilibrium at a constant temperature T i slightly above a particular mixture critical temperature T cm = 307.65K (T i = (1+ )) and stratified with the mean density equal to the mixture critical density ρ cm =470kg.m -3 .The parameter = (T i -T cm )/T cm defines the dimensionless proximity to this mixture critical point named the Lower Critical End Point (LCEP) that is slightly above the critical point of CO 2 . A weak heating is then gradually applied at the solid bottom plate defined byHxL-H. The temperature increases ΔT vary from 10mK up to 100mK. The phase diagram of binary mixtures of interest for SFE and adsorption exhibits a discontinuous mixture critical line (Fig. 2). The low temperature part ends at the LCEP that is the junction between the solid-liquid-vapor coexistence line and the mixture critical line starting at the critical point of the solvent (species 1). In the same way, the high temperature part starts at the critical point of the solute (species 2) and ends at the UCEP. For temperatures between T LCEP and T UCEP , the mixture exhibits an equilibrium between a solid phase of the solute only and a fluid phase of the mixture. Near the LCEP, the solubility of solids and the equilibrium constant of adsorption are very sensitive to variations of temperature and pressure. That is the reason why SFE and adsorption processes are usually performed in this region of the phase diagram. On the other hand, the derivative of the equilibrium constant with respect to pressure diverges as approaching the LCEP. As shown in [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF], this divergent behavior, coupled with the Piston effect, can induce a decrease in the adsorbed amount for increasing heating of the boundary.

The Naphthalene-CO 2 mixture was chosen as a reference system with the above-mentioned phase diagram because of the wide experimental data on solubility that can be found in literature, allowing an easier validation of the thermodynamic model [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF]. The physical properties of each pure compound are given in Table 1. We consider a dilute mixture of Naphthalene (the minority species) and supercritical CO 2 . Naphthalene is the species adsorbed on the bottom plate. The mathematical model is based on the 2D time-dependent and compressible Navier-Stokes equations, coupled with energy and mass diffusion equations and the Peng-Robinson equation of state. In order to reduce computational costs, these equations are solved in the framework of the low Mach number approximation [START_REF] Paolucci | On the filtering of sound from the Navier-Stokes equation[END_REF]. Thus, the total pressure P is split into two parts: a homogeneous thermodynamic part P th (t), which appears in the equation of state and in the energy equation and only depends on time t, and a non-homogeneous dynamic part P dyn (x, y, t), appearing in the momentum equation and which varies with time and space. We use the modification of the low Mach number approximation proposed by Accary et al [START_REF] Accary | An adaptation of the low Mach number approximation for supercritical fluid buoyant flows[END_REF] to account for the strong stratification in fluids near the critical point. We chose T cm as characteristic temperature, ρ cm as characteristic density, H as characteristic length, the Piston effect time scale t PE [START_REF] Raspo | Heterogeneous reaction induced by piston effect in supercritical binary mixtures[END_REF][START_REF] Raspo | Fast mass transfer at a solid-supercritical fluid interface by piston effect[END_REF][START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF] as characteristic time and the corresponding velocity V PE =H/t PE as characteristic velocity. The dimensionless governing equations are therefore:

T c (K)  c (kg.m -3 ) M (kg.mol -1 )  CO 2 (
(1) (2) (3) (4)
In the above equations, V is the velocity of components u and v in the x-and y-directions respectively, w is the mass fraction, γ is the ratio of the isobaric C p and isochoric C v specific heats calculated from the equation of state, and C v0 correspond to the values for a perfect gas ( = 1.3, C v0 = 3R/M 1 ) and the subscript i refers to values at the initial condition. The dimensionless parameters are the Mach number Ma, the Reynolds number Re, the Froude number Fr, the Prandtl number Pr and the Lewis number Le and are respectively defined by: ; ; ; ; where is the sound speed.

In Eq. ( 3), and are respectively the dimensionless partial molar internal energy and partial molar volume expressed as follows:

and for k=1, 2 with and the partial molar internal energy and partial molar volume, respectively, calculated from the Peng-Robinson equation [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF].

As we consider dilute mixtures, the thermal conductivity λ and the dynamic viscosity μ of the mixture are supposed to be those of the pure CO 2 . We use the values given by the NIST for μ and the correlation of Arai et al. [START_REF] Arai | Supercritical fluids: Molecular Interactions, Physical Properties and new Applications[END_REF] for λ. The binary mass diffusion coefficient D 21 is modeled using the Wilke-Chang equation [START_REF] Higashi | Diffusion coefficients of naphthalene and dimethylnaphthalene in supercritical carbon dioxide[END_REF].

The thermodynamic state of the mixture is described by thePeng-Robinson equation of state in the framework of the one-fluid theory:

(

Where:

(w)=1- with j=(1,2)
(j=1,2) with the acentric factor (Table 1). The binary interaction parameters and are determined so as to minimize the error between the calculated and experimental solubility data [START_REF] Raspo | Heterogeneous reaction induced by piston effect in supercritical binary mixtures[END_REF]. The superscript (*) refers to dimensionless parameters.

On the adsorbent plate, the adsorption reaction is modeled by a first order reaction. In order to avoid discontinuities between the plate and the isothermal and non-reactive parts of the bottom boundary y=0, the following boundary conditions are prescribed for temperature T and mass fraction w: (6) [START_REF] Alonso | Scale-up for a process of supercritical extraction with adsorption of solute onto active carbon. Application to soil remediation[END_REF] where Φ(x) is a function allowing a continuous transition between the plate and the other parts of the boundary. It is defined by: In Eq. ( 7), K a is the adsorption equilibrium constant that depends on temperature and pressure. Since small temperature differences ΔT are considered, K a is linearized as follows [START_REF] Cocero | Mathematical model of supercritical extraction applied to oil seed extraction by CO2+saturated alcohol -I. Desorption model[END_REF]: [START_REF] Reverchon | Modelling and simulation of the supercritical adsorption of complex terpene mixtures[END_REF]

Results

Simulations were performed for an initial temperature T i =308.15K, which corresponds to a distance to the mixture critical point equal to 0.5K. Four values of the bottom plate heating were considered: ΔT=10, 20, 50, 100mK, respectively.The mixture is saturated, which means that the initial mass fraction w i = 7.6751×10 -3 corresponds to the solubility of Naphthalene in CO 2 at 308.15K. The values of the various properties and transport coefficients at the initial state are:  i = 3.3402×10 -5 Pa.s -1 , λ i = 9.6172×10 -2 W.m -1 .K -1 , C Vi = 1306.27 J.kg -1 .K -1 , (D 21 ) i = 2.1969×10 -8 m².s -1 , β i = 2.3134×10 -1 K -1 , γ = 16.75. As already said in section 2, since the binary mixture is very dilute because of the low solubility of the solute, we can assume that the transport coefficients of the mixture are those of the pure solvent. Thus, the thermal expansion coefficient β and the ratio of heat capacities γ were calculated from the Peng-Robinson equation for pure CO 2 . For T i =308K, the derivatives of the adsorption constant in Eq. ( 8) are (∂K a /∂T) = 0.295 and (∂K a /∂P) = -2.90×10 -6 . The Damköhler number was fixed to Da=HK ai /(D 21 ) i =10 -5 , which is a pertinent value for an adsorption reaction.

Influence of the heating:

In this section, we present the system's response to the heating of the bottom plate. Figure 3 shows the isolines of temperature and mass fraction perturbation for the four values of heating T. The times correspond to 5t PE and 120t PE for all the cases. The solutions obtained for the various values of T at 5t PE are similar. The temperature field at this time is governed by the Piston effect, as in pure CO 2 [START_REF] Accary | An adaptation of the low Mach number approximation for supercritical fluid buoyant flows[END_REF], with three distinct zones: a hot boundary layer along the heated plate, cold boundary layers along isothermal walls and the cavity bulk which is homogeneously heated by the Piston effect. The mass fraction perturbation just shows mass transfer by diffusion along the adsorbent plate. For t≥28.40s, the isoline map of the mass fraction does not evolve anymore. However,it must be underlined that w-w i keeps on increasing while the adsorption reaction still goes on. As expected, for t=28.40s, the temperature field is very different depending on the T. Indeed, because of the diverging behavior of the thermal expansion coefficient β, the Rayleigh number strongly increases with the heating: Ra=3.4×10 4 for T=10mK, Ra=6.8×10 4 for T=20mK, Ra=1.7×10 5 for T=50mK and Ra=3.4×10 5 for T=100mK. As a consequence, the convective flow is much more intense for T=100mK, allowing a better mixing inside the cavity. The distribution of the convective cells directly affects the mass fraction field as it is revealed in figure 4 showing the velocity field together with the isolines of w-w i . The jet flow between contrarotative rolls is much weaker for T=10 and 20mK (Fig. 4.(a-b)). For T=50 and 100mK (Fig. 4(c-d)), in contrast, the very intense convective cells restrict the diffusion of the solute in the boundary layer along the plate. The convection flow has also a strong influence on the adsorbed amount of solute. Figure 5 presents the profile of the relative mass fraction perturbation (w-w i )/w i on the bottom boundary for the four T.

It reveals that the profile is more homogenous for large T (50mK and 100mK) than for small ones.

Therefore, in the framework of adsorption processes for example, a more homogeneous material can be obtained for large T. On the other hand, the magnitude of adsorbed amount decreases when T increases. As was shown in [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF], this decrease is due to the Piston effect, coupled with the divergent behavior of the derivative (∂K a /∂P) that is negative andinduces a decrease of the adsorption constant (Eq. ( 8)). The larger T is, the larger the pressure increase generated by the Piston effect is and the smaller the adsorption constant is. It must be noted that the divergence of infinite-dilution properties of the solute (that is responsible for the divergence of the adsorption equilibrium constant derivative) is not specific of Naphthalene but it is a universal behavior for dilute mixtures [START_REF] Wannassi | Numerical study of non-isothermal adsorption of Naphthalenein supercritical CO 2 : Behavior near critical point[END_REF].

FIGURE5. Profiles of the relative mass fraction perturbation on the bottom boundary for the four T (H=1 mm).

Finally, the effect of the variation of T on the mass transfer at the adsorbent plate was considered.

For this purpose, we calculated the mean Sherwood number on the plate. This dimensionless number, which characterizes the mass transfer at a boundary, is defined by: FIGURE6. Temporal evolution of the mean Sherwood number for four T (H=1 mm).

Figure 6 shows the temporal evolution of the Sherwood number for the four T. A strong value of Sh is observed at the very beginning of the simulations because of the increase of the plate temperature from T i to T i +ΔT. Then, the Sherwood number rapidly decreases to reach its steady state value. The drop observed between around 2s and 3s for T=100mK is due to the impact of a large cold thermal plume on the heated plate. Figure 6 reveals that the Sherwood number in the steady solution strongly increases when increasing the heating of the plate.

Influence of the height

In this section, we study the effect of confinement by decreasing the height of the cavity to H=0.5mm.

The same four values of T as in the previous sectionare considered. As shown in Fig. 7, the decrease of H leads to thicker thermal and mass diffusion boundary layers.

Obviously, this thickening is just due to a scale effect since the thermal diffusivity and mass diffusion coefficient only vary with the distance to the critical point. The temperature fields and the isolines of the mass fraction perturbation are clearly different from those obtained in the cavity of height H=1mm.

In particular, the number of thermal plumes is multiplied by 2, except for T=100mK, and mass diffusion can transfer the solute in the whole cavity. But the more important effect is that the confinement decreases the intensity of convection and regular convective cells are obtained even for the largest heating as shown in Fig. 8. This is because, for a same value of T, the Rayleigh number is smaller than in the cavity of height H=1mm. This less chaotic velocity field directly influences the profiles of the relative mass fraction perturbation (w-w i )/w i on the bottom boundary (Fig. 9). The magnitude difference between profiles obtained with the four values of T is much smaller compared to the case H=1mm (Fig. 5), and the maximum of adsorbed amount for T≥20mK is larger. Therefore, in a smaller cavity, it is possible to increase the amount of solute adsorbed, which is very interesting in the framework of chemical engineering processes. On the other hand, the profiles reveal that the adsorption of the solute is strongly inhomogeneous for all cases.

The effect of the less intense convection is also visible on the temporal evolution of the mean Sherwood number (Fig. 10). The evolution is more continuous compared with Fig. 6 but, on the other hand, the steady value is smaller than in the cavity of height H=1mm: for T=50mK, we obtain Sh≈30 while Sh≈35 in the higher cavity and for T=100mK, we obtain Sh≈35 while Sh≈40 in the higher cavity. Therefore, reducing the cavity height leads to a decrease of the mass transfer at the bottom plate.

FIGURE9. Profiles of the relative mass fraction perturbation on the bottom boundary for the four T (H=0.5 mm).

FIGURE10. Temporal evolution of the mean Sherwood number for four T (H =0.5 mm).

Conclusion

In this paper, we presented a numerical study of heat and mass transfer in a dilute near-critical binary mixture enclosed in a rectangular cavity with a heated and adsorbent plate on the bottom boundary. The Naphthalene-CO 2 mixture was chosen as a model mixture because of the substantial experimental data on solubility of Naphthalene, allowing a correct determination of binary parameters in the mixing rules of the equation of state. However, since the diverging behavior of transport coefficients and equilibrium constant near the critical point is universal, we believe that the conclusions of our study could be applied to any binary mixture exhibiting the same kind of phase diagram. The results showed that, because of the divergence of the thermal expansion coefficient, a more homogeneous adsorption profile can be obtained when increasing the heating. However, due to the piston effect and the divergence of the derivative of the adsorption constant, the magnitude of the adsorbed amount decreases at the same time. Decreasing the cavity height reduces the decrease of the adsorbed amount of solute for large values of the heating but, on the other hand, the convection flow is less intense and leads to less homogeneous adsorption profile.

FIGURE 1 :

 1 FIGURE 1: Physical configuration

FIGURE 2 :

 2 FIGURE 2 : Phase diagram of binary mixtures of interest (CP: critical point; LCEP: Lower Critical End Point; UCEP: Upper Critical End Point; S=L: solid-liquid equilibrium curve; S 2 LG: solid-liquid-gas curve; dotted lines: liquid-gas critical lines of the mixture).

FIGURE3.

  FIGURE3. Isolines of temperature (left column) and mass fraction perturbation w-w i (right column) for the four values of T (20, 30, 50 and 100mK respectively) for H=1mm.

  field together with the isolines of w-w i in the central part of the cavity (above the heated plate) for (a) T=10mK, (b) T=20mK, (c) T=50mK and (d) T=100mK, and for H=1mm.

FIGURE 7 .

 7 FIGURE 7. Isolines of temperature (left column) and mass fraction perturbation w-w i (right column) for the four heated (20, 30, 50 and 100mK respectively) in the same T i =308.15K and for H=0.5 mm.

FIGURE8.

  FIGURE8. Velocity field together with the isolines of w-w i in the central part of the cavity (above the heated plate) for (a) T=10mK, (b) T=20mK, (c) T=50mK and (d) T=100mK, and for H=0.5 mm.

Table 1 :

 1 Pure component properties (critical temperature and density T c and 

	1)	304.21	467.8	4.401×10 -2	0.225
	Naphthalene (2) 748.40	314.9	1.282×10 -1	0.302

c , molecular weight M and acentric factor ω).