Model driven development uses more and more complementary models. Indeed, large-scale industrial systems are currently developed by hundreds of developers working on hundreds of models by di erent distributed teams. In such a context, model inconsistency detection is gaining a lot of attention as the overlap between all these models, which are often maintained by di erent persons, are a common source of inconsistencies. This paper proposes a method to detect inconsistencies when models are scattered on di erent editing sites using partial replication. The method provides a way to check the consistency of a single view against the ones that are related to it regarding consistency. It relies on Praxis, an operation based representation of models, to determine what information needs to be collected for consistency checking and the DPraxis protocol to nd where it can be.
Model driven development uses more and more
complementary models. Indeed, large-scale industrial systems are
currently developed by hundreds of developers working on
hundreds of models by di erent distributed teams [
A designer can produce, modify or delete model elements that belong to his view. During the execution of the development process, designers will collaborate. Hence, they will need to access model elements on other sites. Once a designer has accessed model elements from any other view, these model elements can be incorporated to his view as he now relies on it. Also, a designer's view always remains partial for sake of the separation of concerns. Respecting the separation of concern principle inevitably leads to inconsistency between the di erent views. Inconsistencies need to be detected as soon as possible to avoid project failures. In this article, we address the problem of inconsistency detection when the views are distributed. More precisely, we want to tackle with this problem when each designer's site only holds the designer's view. The focus of this work is then to provide a method for detecting single-view inconsistencies, that are all the inconsistencies related to a particular view. In other words, we want to provide a method that only detect inconsistencies that the view's designer can understand and resolve.
We identi ed two problems that need to be tackled regarding single-view inconsistency detection. The rst one is to be able to identify the needed information from other views. This point is handled in section 2. The second lock concerns the problem of nding in which view the interesting information is, which is dealt with in section 3.
If no information is available about what kind of data is relevant to each inconsistency rule, the consistency check of a single view will need to download the entirety of the related views; and possibly the entirety of the views related to the related views, which can quickly end-up in downloading the entire design. The gathering of such a wasteful amount of data can be avoided using lters that can be deduced from the consistency rules' code.
In this section we brie y revisit the three elements from
our previous work [
We propose a formalism to represent models as sequences
of unitary editing operations [
In Praxis, an inconsistency rule is a logic formula over the
sequence of model editing operations (interested readers can
refer to [
The Visibility rule speci es that: An element that has a public visibility can only be in a namespace with a public visibility.
These two rules cover two typical aspects of inconsistency detection. The rule Ownership ( gure 4), speci es that containments should not cycle, which is quite complex to check because containments relationships are spread over the entire design. The rule Visibility ( gure 3) on the contrary, is less complex, and has its locality restricted to each namespace.
V isibility () f9 M e; N 1 lastAddP roperty(M e; visibility; \public00) ^ lastAddRef erence(M e; namespace; N 1) ^ lastAddP roperty(N 1; visibility; V ) ^ not(V = \public00): To illustrate Praxis rules, we present the Praxis version of rule Visibility and Ownership in gure 3 and 4. The Visibility rule has two variables (M e; N 1) that both correspond to identi ers of UML elements. This rule matches any Praxis model construction sequence that results in a model containing an element with a public visibility for which its namespace is not public. The sequence presented in Figure 2 corresponds to an inconsistent model regarding this rule. Launching an inconsistency detection on this sequence would detect the inconsistency Visibility(P1,C1).
The e ect that editing operations may have on inconsistency
rules can be described in a two dimensional boolean matrix
we called impact matrix [
As there is an in nity of possible editing operations (in nity
of possible parameter's values), we group them in
equivalence classes to bound the matrix's size. We de ned four
rules to partition the editing operations for any metamodel.
Two editing operations are equivalent if (1) they create a
model element instance of the same meta-class, (2) they
change a reference for the same meta-reference, (3) they
change values for the same meta-property, (4) they delete
a model element. Thanks to such a partition, the number
of equivalence classes is bound to the number of the
metaclasses, plus the number of the references, plus the number of
properties, plus one (the equivalent class corresponding to
the deletion).The impact matrix is automatically derived
from the metamodel and the inconsistency rules [
Equivalence class CClass CAttribute SPName SPV isibility SROwnedElement SRClass SRAttribute SRNamespace Delete
OwnedElement false false false false true false false false false
Visibility false false false true false false false true false An extract of the impact matrix for the illustrative inconsistency rules we previously introduced is shown in gure 5. The extract shows nine equivalence classes from the metamodel partition, of which only three have an e ect on an inconsistency rule. In this matrix, regarding the Visibility inconsistency rule, the operation classes that may have an impact on this rule are SPV isibility and SRNamesapce. The operations that may have an impact on this rule are those that modify a reference to the namespace of an element, which all belong to the operation class SRNamespace, and those that modify the visibility of an element, which all belong to SPV isibility. Note that the Delete equivalence class has no impact because deletion occurs only for model elements that are not referenced and do not reference other model elements.
Our method for single-view consistency detection uses the
impact matrix that was originally intended for incremental
inconsistency detection [
Having the information about what classes of operations are useful for checking a particular rule is not enough in practice. It does not tackle the problem of gathering data that is actually related to the view for which we want to check the consistency. Indeed, the interesting information is scattered among the views, and not all of the information that belongs to the identi ed operation classes is interesting to the view's designer. In this section we describe how we use group of interest tables from peer-to-peer model editing engines to identify where in the net of views is the information to consider for inconsistency detection.
Partial replications allows each model designer to restrict
his workspace to its strict minimum: his view. The
overlaps between the views are maintained up-to-date thanks to
a complex background update protocol. We de ned such
a protocol, named DPraxis, for distributed model editing
tools [
DPraxis uses the model element as the replication unit. Consequently, views contain replicas for the parts that overlap with at least one other view, and model elements that are proper to the view. The use of the model element as the replication unit allows to ne tune the parts of the model a designer want to import in his view. As DPraxis does not allow dangling links, reference between elements are shared between views only if both the source and the target of a reference are in the site's view. This allows to choose the perimeter of the view by not importing elements pointed by unwanted references.
The DPraxis protocol maintains a table with routing information on each site to propagate changes to the interested sites. Thanks to this table it is possible to know which elements are replicas, and to know, for each replica, on which site it is replicated. This two informations are exploited by the single-view inconsistency detection method to contact other views when checking consistency.
The following method focuses on the use of partial replication. Nevertheless, the method described here for singleview inconsistency detection could be used in centralized architectures as well. We describe in this section how to check one inconsistency rule for one view, plus the elements of other views that are related to the considered view regarding the rule to check.
The intent of single view inconsistency detection is to simulate an inconsistency check where the detection engine can jump from the original view to the related ones. To achieve this goal we propose to begin with the identi cation of what we call Jump Points. A jump point is a replicated model element from which the inconsistency detection engine would want to continue its work in an other view. They correspond to elements for which the local view only has a partial knowledge and where it is necessary to jump to other views to complete this knowledge. Inconsistency rules navigate through the model thanks to references, which can point to other views elements that are not replicated locally. The rst step of single view inconsistency detection is then to nd these local elements that may point to model elements that are not known locally, and may be the source of inconsistencies.
De nition 1. Jump Point: An inconsistency rule's jump point is a model element which is the source (res. the target) of a reference that points to an element outside of the local view and that can be navigated by the inconsistency rule. In Praxis, references are accessed using the logical predicate lastAddReference(source, reference, target). The Impact matrix presented previously can be used to know which references can be crossed by an inconsistency rules. These references correspond to true in the matrix for operation classes of type SRreference. For instance the rule V isibility only navigates through relations of the class SRNamespace. In DPraxis, replicas are maintained up-to-date thanks to interest group tables that can be used to know which elements are replicated, and where.
In practice we determine the jump points following this procedure: 1. Determine the references that can be crossed by the inconsistency rule by looking for true in the Impact Matrix for classes of operations that correspond to references. 2. Determine which elements are replicas using the group of interest table. 3. Confront the two informations to nd all the replicas for which there is a locally crossable reference. These elements will be considered as the only interesting Jump Points.
It is di cult in practice to determine all the possible Jump Points using DPraxis because references in the view can only target elements of the view | if a reference is interesting to one view, then its target has to be imported. Therefore, there can be references of replicas that are not known to the local view. We chose to ignore such jump points because in DPraxis the user decides whether the target (res. source) of a replicated element is interesting or not. It is then reasonable to hide inconsistencies for which the user clearly stated that the reference was not relevant to him/her. We only consider as a jump point elements for which there is at least one reference of the considered type locally. Nevertheless the Jump points we ignore could be capture by looking out in the meta-model if the replica's type can admit crossable references.
The next step of the single-view inconsistency method is to allow inconsistency rules to follow jump points' references to other views. We chose to download data of other views locally for simulating the jumps. This choice allows to use a regular inconsistency detection engine to do the single-view inconsistency detection. Not all the information from the distant view is to be downloaded. First, only information that is interesting to the considered rule matters, which is speci ed in the Impact matrix. Second, only elements that are linked to the jump point need to be downloaded. The gathering of the unitary actions for realizing the singleview inconsistency detection can be done this way: 1. Determine Jump points following the previous procedure. 2. Contact all the sites that have a replica of a jump point for the considered rule. Ask them to send all the unitary operations that are interesting for this rule plus the operations that are necessary to ful ll their preconditions. Wait for the answer. 3. Contacted sites then recursively apply the two previous steps of the procedure as long as new jump points are discovered. Then they send back to the caller all the gathered data.
The implementation of the procedure is detailed in section 4. At the end of this procedure the calling site has gathered all the information that is interesting to the rule from the other views, and that is linked to its jump points. An inconsistency detection on the view plus the gathered data implements a single-view inconsistency detection: It detects the local inconsistencies, plus the inconsistencies that are due to the overlapping parts of the views.
In this section we present an illustrative example of the single-view inconsistency detection.
In gure 6 is shown three sequences corresponding to three di erent views, where each of the views is consistent, but together make a cycle for the ownedElement relationship. The number correspond to a total ordering of the actions that is granted by D-Praxis.
Let us consider a single-view inconsistency detection for View One regarding the Ownership inconsistency rule. The rst step is to determine the jump points: P 1 and P 2 are replicas (they are in the routing table from gure 7). From the Impact Matrix in gure 5 we can deduce that this rule can only cross references from the operation class SROwnedElement. There is a local OwnedElement reference in the view that both concerns P 1 and P 2, thus the jump points for this view and for the rule Ownership are P 1 and P 2.
The simulation of the jump needs to contact View two concerning P 2 and View three concerning P 1. The following requests are sent in order to gather the data without cycling inde nitely: 1 2 3 4 5 6 3 4 7 8 9 10 1 2 7 8 11 12
View One create(P1,package) addProperty(P1,name, 'A') create(P2,package) addProperty(P2, name, 'B') addReference(P1, ownedElement, P2) addReference(P2, namespace, P1) View Two create(P2,package) addProperty(P2, name, 'B') create(P3,package) addProperty(P3,name, 'C') addReference(P2, ownedElement, P3) addReference(P3, namespace, P2) View Three create(P1,package) addProperty(P1,name, 'A') create(P3,package) addProperty(P3,name, 'C') addReference(P3, ownedElement, P1) addReference(P1, namespace, P3) { Recursive Call from View two to View three: P 3 is identi ed as a new jumping point. Requesting all actions in SROwnedElement regarding P 1; P 2; P 3, plus dependencies.
Identi ed operation: 11:addReference(P3, ownedElement, P1) Dependencies: None. P3 and P1 are known to the caller.
Recursive Call: None, no new jump point discovered. { Returned operations: 7:create(P3,package); 9:addReference(P2, ownedElement, P3); 11:addReference(P3, ownedElement, P1).
Request from View one to View three is symmetric to the previous one, it returns the same operations. At the end of the procedure, the view one has gathered: 7 create(P3,package) 9 addReference(P2, ownedElement, P3) 11 addReference(P3, ownedElement, P1) Using both the local and the distant operations, the inconsistency detection engine will detect an inconsistency for the rule Ownership, indeed P 1; P 2; P 3 are in a cycle for the relation OwnedElement. The procedure only gathers the minimal information that matters to the rule, and that has a link to the local data. The designer of view one is now aware of the cycle problem and can contact the designers responsible for the two other implicated views to resolve the problem.
The method described here is based on the fact that inconsistency rules navigate through models using the relations between model elements. This condition does not hold in general, for instance a rule that counts elements of a particular type may not use references for the navigation. Rules that do not use navigation must be checked by gathering all the interesting operations from all the other views.
We implemented the method in our inconsistency detection tool 1 that runs on top of Eclipse. The implementation adds one optimization to the described procedure. We implemented a hashing system to avoid to constantly download the same operations over and over: A hash of the known operations for each operation class is sent prior to the procedure, if the hashes matches, the procedure does not continue.
The naive method to tackle with distributed views
consistency consists in downloading all the views on a central
repository and then perform the inconsistency detection on
the re-united global design [
This paper presents the notion of single-view inconsistency
detection. This method aims at detecting distributed
inconsistencies in a light-weight fashion by only reasoning on
elements that are relevent for both the considered
inconsistency rules and the considered view. The method is based
on the notion of inconsistency rules' jump point which is
computed thanks to two of our previous contributions [