Discussion

In this section, we discuss the usefulness of the approach in more general settings.

3.7.1 User Interaction

Rule systems have the advantage to allow incremental processes that can be controlled by user interaction. During each step of the algorithm, it is easily possible to enable the user to choose which of the applicable rules to execute at which match. This includes the resolution of the kind of non-determinism that was already mentioned at the end of Section 3.3.1. In this way, the user is enabled to repair an instance in a more meaningful fashion.

In our developed tool, we restrict user interaction to choices that can be made during a step of the algorithm but do not allow changes of the overall control flow. The steps are run through in the designated order and, the rules of each step have to be executed as long as there are applicable rules. The applicable rules and their matches serve as repair choices. The suggested choices of each step aim at repairing the whole model.

This semi-interactivity guides the user towards a consistent instance and ensures the integrity of the approach: If user interaction is just used to reduce the amount of non-determinism in the repair algorithm, the correctness (and termination) proofs for the algorithm still hold.

The control flow of the algorithm can be stopped at any time, and the resulting intermediate model is an EMF instance model that can be opened and displayed by the EMF editor. If arbitrary model editing steps are allowed (out of the repair process and out of the model editor), it may happen that new inconsistencies are introduced, and the algorithm does not terminate anymore.

3.7.2 Moving Instead of Trimming

During the first part of our algorithm, we resolve inconsistencies w.r.t. upper bounds.

We do this by deletion of supernumerous elements. This is a general solution. In some cases, moving the elements into other containers (sources) without violating their upper bounds would be possible. But this does not always work: For example, the consistency requirements for rules which move cycle-capable containment edges are quite strict [14]. So it may not be possible to generally derive a rule that would be

useful in a concrete situation. And more importantly, because of finite upper bounds it is possible that there is a maximal number of objects of a certain node type which are allowed to exists in EMF-model graphs. Thus, no graph that contains more nodes for one typenthan allowed can be repaired without deleting.

But as long as this is considered, the moving of supernumerous elements into other already existing containers (sources) or newly created ones (if possible) does not change the validity of Theorem 1 and therefore neither that of Theorem 2. However, in Sections A.1 and A.2, we present the schemes of moving rules for non cycle-capable containment and non-containment edges and their meta patterns as well as concrete examples.

3.7.3 Finitely Instantiable Versus Fully Finitely Instantiable Meta-Models

While deleting during the trimming part of the algorithm, we intended not to delete during the second part at the cost of not being able to repair every instance of finitely instantiable type graphs T G: Deletion would have to take place in Step (4) of the algorithm if no target node can be created. In this case, the bounds of all containment edges would be satisfied, but the lower bound of at least one non-containment edge violated. This means that multiplicities of non-containment edges would not only demand or forbid the existence of non-containment edges but additionally impose constraints on the number of certain types of nodes. Here, it may be more advisable to adapt the multiplicities of the meta-model than to loose information by deletion.

Furthermore, there are f.i. meta-models for which only a very small number of consis-tent models exist. Then, repairing instances means the deletion of almost everything and the creation of one of the few consistent models.

For a type graphT G, which is not fully finitely instantiable, the algorithm may break during Step 4. In this case, getting the match of the check rule used in Step 3 aims at identifying for which edge it was not possible to create a target node. This information could be useful, e.g., to refactor the multiplicities of the corresponding type graph so that a given model can be completed, or to maybe delete the source node of that required edge.

An additional alternative is the creation of a further root node. There exist instances of finitely instantiable meta-models, which can be repaired – without deletion during the second part – by creating more than one, but finitely many root nodes.

To summarize, when applying the considered approach to finitely, but not fully finitely instantiable meta-models, the following possibilities exist:

(a) Instance gets repaired.

(b) Algorithm breaks in Step 4 because a needed target node cannot be created. A solution might be achieved by creating finitely many new nodes of root type, or there is no termination, even when creating new nodes of root type.

(c) No termination.

Characterizing these situations by features of the type graph or the instance which is to be repaired is a future work.

3.7.4 Supporting a Set of OCL Constraints

There are some of OCL constraints which can be straightforward supported by our approach. These OCL constraints are semantically equivalent to the lower and upper bound constraints, i.e., they can be represented as graph constraints of form@pP,DC1q or@pP,EC2q— P,C1andC2are graphs such thatP is a sub-graph ofC1 and ofC2. For example, the multiplicity bound r1..2s of a containment edge type

A ^cont[1..2] B and the following OCL constraint:

context Ainv: self.contÑnotEmpty() and self.cont Ñsize() 3

are semantically equivalent to each other and they can be represented as graph con-straints as follows.

@

self:A, D

self:A^:cont :B ^ E

self:A :B

:B :B

:cont :con

t :cont

It means that there is at least one B-node in an A-node, and there are at most two B-nodes in an A-node. The first part represents the lower bound constraint of value 1 and the OCl expressionself.contÑnotEmpty()whereas the second part represents the upper bound constraint of value 2 and the OCL expressionself.contÑ size() 3. Our algorithm can similarly be configured with rules being derived from the graph patterns as follows: From a graph pattern of form @pP,DC₁q, rules of kind required-node-creation can be derived to configure the Step (1) of the algorithm and from a graph pattern of form @pP,EC2q rules of kinds finding-exceeding-node, exceeding-node-deleting and additional-node-creation can be derived to configure the Step (b), the Step (c) and the Step (4) of the algorithm, respectively. Regarding to our example, a required-node-creation rule, which creates a B-node in an existing A -node if and only if it has no B-node, will be derived from the graph pattern

@

self:A, D

self:A^:cont :B

, and an exceeding-node-deleting rule, which deletes a B-node in an existing A-node if and only if it has more than two B-nodes, will be

derived from the graph pattern@

self:A, E

self:A :B

:B :B

:cont :cont :cont

.

However, not all constraints of form@pP,DC1qor@pP,EC2qcan be directly supported.

They need to obey some criteria such that there are no conflicts among them, e.g., if there is a conjunction between a positive and a negative graph constraint of form

@pP,DpC₁q ^ EpC₂qq, C₁ should be a sub-graph of C₂. Figure 3.25 presents the core concept of our future work for supporting a set of OCL constraints.

7

OCL Constraints

translate derive

Rule-Based Algorithm Repair Rules

Graph Constraints

Figure 3.25: EMF Repair supporting a set of OCL constraints

Moreover, the repair algorithm can straightforwardly support negative constraints as done previously. I.e., we derive rules which delete supernumerous elements w.r.t. the negative constraints, and thereafter, we update the rules which create model elements in a way that they do not violate the negative constraints. Here, we can use the tool OCL2AC (see Chapter 5) to update the rules automatically. Furthermore, translating OCL constraints to graph patterns [12, 113] and further to application conditions of rules is promising to achieve an automated interactive model repair approach for meta-models with OCL constraints.