Maintaining consistency between models in development processes is a challenging task. Though in software engineering many case tools exist which allow the editing of models and include code generators for reverse or round trip engineering, the source code is edited with specialized development environments. The same holds for other models, such as requirements speci cations or architectures. The editing tools are often decoupled from each other. Additionally, modi cations of the models are performed simultaneously. In this paper, we introduce strategies to resolve inconsistencies by so-called repair actions. The novelty of the strategies is that they specify di erent concurrent ways of coming to a consistent state, not knowing anything about the modi cations a user had applied. Concrete repair actions are derived at runtime based on the consistency rules and the inconsistent parts of the models only. The maintenance tool can maintain additional models' consistency without developing specialized repair actions. One new strategy proposed in this paper in contrast to other approaches is to heal the violated consistency rule or try a similar one.
Development processes in engineering disciplines tend to be
highly complex. As a result, the product to be developed
needs to be modeled from multiple interdependent
perspectives and on di erent levels of abstraction. The results of
development activities like requirements de nitions, software
architectures, or implementations in software engineering
are stored in models. Di erent models may overlap, so when
they are edited independently, they may impose constraints
on the system to be developed which are not satis able any
more. Models are then said to be inconsistent to each other
[
In literature consistency maintenance of models are also
called inconsistency management [
Usually, valid statements within model overlappings are
formalized by consistency rules [
Many approaches face the problem of inconsistencies by
offering one integrated case tool which performs the tasks of
inconsistency management by direct propagation of changes
to dependent models such as e.g., EclipseUML [
Therefore, consistency maintenance should resolve an
inconsistency by propagation of changes on one model to
depending models incrementally and bidirectionally. Incrementality
means that only local changes are made in a model to handle
one inconsistency so that other changes on the model which
were done in the meantime are not overwritten. Also
inconsistency resolution should be made only on request, meaning
that inconsistencies must be tolerated [
Triple graph grammars (TGG) [
A problem is that triple rules need to be monotone, i.e. they only produce new nodes and edges and are not allowed to delete any. Thus, only inconsistencies caused by addition of new nodes in one of the models can be resolved by transforming them into the dependent model (by applying remaining operations of a triple rule). We would like to call inconsistencies of that kind category 1 inconsistencies. But modi cations on one of the models may a ect nodes which are related to nodes of the other model. It can then happen that the relationship de ned by the triple rule which was applied before is not present any more. We would like to call inconsistencies of that kind category 2 inconsistencies. In this paper, we introduce strategies to resolve category 2 inconsistencies by so-called repair actions. The novelty of the strategies is that they specify di erent concurrent ways of coming to a consistent state, not knowing anything about the modi cations a user had applied. Concrete repair actions are derived at runtime based on the consistency rules and the inconsistent parts of the models only. The maintenance tool can maintain additional models' consistency without developing specialized repair actions. One new strategy proposed in this paper in contrast to other approaches is to heal the violated consistency rule or try a similar one.
This paper is structured as follows: Section 2 presents a scenario where the maintenance tool is applied. Section 3 introduces some basic concepts of the underlying data structures, the modeling of consistency rules, and the de nition of consistency in this setting. In Section 4, the strategies for nding and resolving category 2 inconsistencies are presented. Section 5 describes shortly the implementation of the maintenance tool and the resolving strategies. Related work is discussed in Section 6 and, nally, Section 7 concludes the paper.
While the underlying concepts of the maintenance tools are
fairly general and domain-independent, we focus on software
engineering and introduce a sample scenario where UML
class diagrams and source code are maintained consistent.
For designing the structure of a system, UML class diagrams
are well-suited as they abstract from the implementation
details of the system and they are part of static structure
diagrams in the UML. Heterogeneous tools may be used for
creating UML class diagrams and source code, respectively.
In the following, we assume that the UML class diagrams
are maintained by Eclipse [
Figure 1 illustrates how the tool assists in maintaining consistency when changes are made simultaneously. Three different versions of the sample UML class diagram and the corresponding Visual Studio (VS) object model are shown above and below the dashed line, respectively. The tool maintains a data structure which contains links for connecting the two models. These links are represented by ellipses which are located on the dashed line. Dotted lines are used to indicate the objects participating in a link1. The connections of a link to objects in both models base on template speci cations for corresponding object patterns, e.g. that UML classes correspond to code classes, UML associations correspond to attributes in the code owned by corresponding classes, or UML methods correspond to code methods also both owned by corresponding classes. Furthermore, arrows located on the right indicate the directions of change propagations (structural and attribute changes, respectively). The gure illustrates a re-design process consisting of three steps described in the following.
Initially, the VS object model and the corresponding UML class diagram are consistent to each other, thus, links already exist between the objects (see left version in the gure). They each contain the classes Control and DataAccessObject and the methods getDBItem and getFileItem which are elements of latter class. The association data is represented in the object model as attribute referencing the corresponding class object as type.
Secondly, both models are edited simultaneously (see middle version in the gure). Changes are marked with new or * in the gure for newly added objects or changed objects, respectively. To the VS object model only the helping function helper is added. To the class diagram two further 1Please note that this is a simpli ed notation. Some details of the link data structure introduced later are omitted and also not every link is shown. 2.) state= inconsistent 3.) state= consistent DataAccessObject +getDBItem() +getFileItem()
User changes
Control data Control data 1.) state= consistent
classes DBAccess and FileAccess are added and the methods of their super class are distributed among these classes. Additionally, the method names are generalized to getItem. The models are now inconsistent but the links still exist. We see that inconsistencies caused by newly added objects are category 1 inconsistencies while those caused by changed objects are category 2 inconsistencies.
Finally, the maintenance tool is used to synchronize the parallel work which results in the right versions of the models in the gure. The newly added objects are added to the respective other model. The category 2 inconsistencies within the methods correspondence relation are the non-valid attribute condition, i.e. the method names are not equal, and the owning classes of the UML and code methods do not correspond to each other, respectively. To resolve the inconsistencies the name change in the UML model is propagated to the code model and the shift of the methods to di erent classes in the UML model results in rearrangement of the references between the class and method objects. What we see here is, that the basic template speci cation of corresponding methods are still valid. Please note that there might be compile errors in the source code after the synchronization. The example presented above demonstrates the functionality of the maintenance tool, but it does not show how this is achieved. In the next sections, the underlying conceptual approach is presented. The implementation is introduced in Section 5.
In our approach, we use typed, directed graphs to represent the models between which relationships exist. Graphs consisting of nodes and edges are well suited for representing complex data with manifold relationships in a natural way. Also, inter-model relationships can be expressed easily with nodes and edges referencing related nodes of the graphs. As another advantage we can use the theory of graph transformations to de ne modi cations on the graphs. In the following, the data structures, construction of consistency rules, and the notion of consistency in this setting are presented.
For using TGG in complex scenarios where two dependent
models are edited by di erent tools we create graphs from
these models (via tool wrappers) and denote one as source
and the other as target model. Operations on the models
performed by the respective tools are represented as graph
transformations. The data structure storing links between
inter-dependent models is called integration document which
is also modeled as graph.The framework creates an
integrated graph consisting of the three graphs to simplify
speci cation of the triple rules and their application.
In the following, we want to use UML object diagrams to
represent typed graphs and to model triple rules as well.
The graph schemes, therefore, are modeled as UML class
diagrams. To be able to model integration scenarios, we
provide an extension of the UML meta-model [
To model source and target graphs we use the stereotypes Increment for nodes and Incr2Incr for edges. Source and target graphs have an underlying graph scheme equivalent to the respective models's meta-models. This means the graph schemes of UML class diagrams and source code which we <<Increment>>
Control : Class <<Incr2Incr>> ownedAttribute <<Increment>>
: Property <<Incr2Incr>> association <<Increment>>
data :
Association <<Incr2Incr>> memberEnd <<Increment>>
: Property <<Incr2Incr>> class <<Increment>> DataAcessObj:
Class <<toConSrcIncr>>
<<toConTrgIncr>>
<<toSrcIncr>> <<Link>> <<toTrgIncr>>
: AssocLink
<<Increment>>
data : Property
want to maintain consistent do not di er much from the
meta-model of UML class diagrams speci ed by the OMG
in [
The integration document objects use the stereotype Link to mark the links. Links refer to increments in source or target model via UMLLinks (instances of associations). The increments have to be distinguished according to the graphs they are contained in, either source or target graph. Therefore, stereotypes for UMLLinks from links to increments appear twice, one for increments of the source and one for increments of the target graph. This is indicated by sufxes SrcIncr and TrgIncr of the stereotypes' names. Dependent on whether the increments play the role of a normal or context increment, they are connected to a link via UMLLinks with stereotype toSrcIncr, toTrgIncr, toConSrcIncr, or toConTrgIncr respectively. Increments may play the role of so called context increments for a link when they de ne some kind of existent-dependency for a link, i.e. a link relates increments only if the context increments are connected to these increments within the models.
The integration document also has an underlying graph scheme which models the link types and how they are related to classes of source and target graph schemes. In Figure 2, we see that links of type ClassLink and AssocLink are represented which are used to relate classes or associations in both models. In this example, the association (source) is mapped to a property (target). 3.2
Association2Attribute_Triple_Rule ::
LHS as UML OD <<Increment>>
: Class
The left-hand-side (LHS) of the rule is shown above and speci es that the two classes in each model already exist and are related to each other via links in the integration document. The right-hand-side (RHS) shown below speci es the situation after the rule has been applied meaning that the association in the source graph, the attribute in the target graph, the link in the integration document mapping both onto each other, and the edges embedding these increments in the existing graphs are created. This triple rule also speci es an attribute equation shown in the comment attached to the new link. It states that the increments a and b have the same names. The RHS is the template which declaratively speci es the connection pattern for a consistent link. A rule can also specify restrictions on attributes of the increments, for example the name of a class aClass could be restricted by aClass == 'User'. If the restrictions or equations appear on the LHS they restrict graph pattern matching allowing only those increments to be matched which ful ll these constraints. If they appear on the RHS, the constraints have to be ful lled in any case. When there is no value speci ed within the rule such as in the triple rule shown above, a dialog is prompted to enter a value. As a further example, Figure 4 shows the triple rule which is applied in the scenario for creating the methods getDBItem and getFileItem in source and target graph and the links between them.
Please note: if asynchronous rules are derived from triple rules which have equations, attribute values are transferred into the other model. For example, the forward transformation of the triple rule shown above sets the attribute's name to the association name (b.name := a.name), vice versa for the backward transformation (a.name := b.name).
TGG base on Pair Graph Grammars (PGG) [
Although in practice we do not have a complete TGG we can keep the de nition of consistency of Pratt. We only regard those structures in the models which can be created by one of the triple rules. Other increments are ignored; they also do not make the models inconsistent as there is no triple rule that would de ne corresponding increments in the other model.
Our tool performs the three tasks mentioned in [
The main issues we are dealing with are that we cannot record the changes an external tool performs on a model and also that we cannot assume that a rule modeler speci ed for each operation on a model an equivalent operation on a dependent model. So, instead of parsing the graph and nding out the operations which were performed on a model and to perform equivalent operations on a dependent model, we decided to take only the already available triple rules into account and those parts in the model which make a triple rule inconsistent.
It is so, that a triple rule speci es declaratively in its RHS the correspondences of two patterns in source and target graph. Thus, if the rule is applied, there exist instances of these patterns (subgraphs) in source and target graph and a link exists in the integration document referencing the nodes of these subgraphs. An inconsistency according to a triple rule is, therefore, that the patterns do not match anymore or that attribute conditions are violated. Thus, resolution means to maintain the graphs so that a link referring to nodes in source and target graphs is valid according to an RHS of any triple rule, not necessarily the one which was formerly applied.
It is important to note that a repair action is allowed to change only nodes and edges that were originally created by the applied rule. That does not hold for context increments. Therefore, a repair action never causes new inconsistencies for links referenced as context. But of course, other links having a repaired link in their contexts could be damaged.
For existing links we check if there were modi cations on their referenced increments by doing pattern matching using the RHS of the triple rules applied before. Each link in the integration document has an associated state. When a link has been newly created by applying a rule, its state is initially set to consistent. In the analysis, for each link it is checked whether increments originally referenced by the link are still present in source and target graphs. If the RHS of the triple rule does not match any more due to modi cations of source or target graphs, the state of the link is changed to damaged. For handling the inconsistency all reasons why the link got damaged are collected during analysis. Here, all possibilities for a link to be damaged are listed: Increments deleted Increments of the source or target graph which take part in a link have been deleted, resulting in dangling references of the link. As an example, an attribute of a class could have been deleted.
Attribute values changed Attribute values of source or target increments of a link have been changed so that attribute conditions do not hold any more. This would be the case if the attribute of a class in the source code has been renamed resulting in an inconsistency of the Association2Attribute-rule because the name of the corresponding association in the UML class diagram of that attribute and the attribute's name are no longer equal.
Edges deleted Edges of the source or target graph being involved in a link have been deleted, so that the patterns on both sides are no longer valid. For example, an attribute of a class in the source code has got another type so that the edge typeRef from the attribute to the old type is deleted. Context damaged If a link gets damaged all links referring to it as context get damaged, too. For example, a link L1 mapping an association onto an attribute refers to two links as context links, i.e. those links mapping two classes in each graph onto each other. If one of those links gets damaged, L1 is damaged, too.
We now present what can be done in general if damaged links have been found and list in the following sections graph transformation strategies. We call these strategies repair types because we create concrete instances from these strategies, repair actions, to repair a concrete damaged link with speci c damages. Applied to a damaged link, a repair action brings the link back to a consistent state which means that it resolves the inconsistency.
The most primitive procedure is to delete the link and all the increments on both sides, which are involved in the integration situation. It is obvious that this is suitable only in situations where all increments of a link have been deleted by the user in one of the graphs or where one of the main increments has been deleted. If some increments of a link in one of the graphs are deleted and others still exist, the deletion could have been part of a restructuring activity, thus, deleting all increments is not the reaction the user expected. Still, it is a valid repair strategy, but one which should never be executed without prompting the user before.
The next simple possibility is to only delete the damaged link and to leave the increments on both sides unchanged and to make them available for other transformation rules. Most of the time this also does not lead to the desired behavior of the tool. The modi cations resulting in the damaged link were probably done on purpose. The link, although damaged, may contain valuable information to be used, most importantly, to determine which parts of the graphs may be a ected by the modi cation which damaged the link. For example, in the scenario the Operation2Operation rule from Figure 4 had been applied and the user rerouted the method getDBItem from the class DataAccessObject to another class DBAccess, then the rule did not match anymore. The edge ownedOperation from the class DataAccessObject is missing. But instead of deleting the link and all references the desired repair action is to reroute the ownedOperation reference of the corresponding method in the source code from the class DataAccessObject to the class DBAccess. 4.2.3
Another option is to restore consistency by removing the cause for the inconsistency. For instance, missing increments or edges may be created. This option is desirable only in those cases where the operation causing the damage was carried out accidentally, because it would be undone. For attribute values, the attribute conditions of the triple rule can be used to propagate the change.
This is a trivial solution to handle a damage as for the new situation a rule is de ned (induced) and attached to the link.
As the alternatives to repair inconsistencies presented so far
are not very useful from the practical point of view, more
speci c repair types [
Create increment If an increment is deleted it can be recreated, thus, this (single) damage is removed, resulting in an undo-like operation of the user's changes. Note, this is not a real undo such as in the Undo changes repair type, because attribute values of the recreated increment are not reestablished as before the deletion of the increment.
Create edge If an edge is deleted it can be recreated as above. This also is not a real undo, because an edge which was deleted due to the deletion of an incident increment which is not part of the rule pattern is not recreated by this repair.
Propagate attribute value If an attribute value changed so that the condition of an attribute equation of the applied rule does not hold, this repair type changes attribute values so that the violated attribute equations hold again. For example, in the scenario of Figure 1 the rule which maps two methods onto each other is applied two times. It states that methods a from the source and b from the target graph referred by a link must have the same names, here getDBItem and getFileItem. The user afterwards changed both methods' names in the UML model having the role of method a to getItem, there are two possible actions: (i) b.name := a.name or (ii) a.name := b.name. The rst would correspond to a propagation but the system is not able to determine which value (that of a or b) had changed by the user, so it suggests both alternatives.
Change attribute value according to restriction If an attribute value is changed so that the condition of an attribute restriction is violated, this repair changes the attribute value so that the violated attribute restriction holds again. For example, if the restriction is aClass.name == 'User' and aClass.name di ers from this value, then the action aClass.name := 'User' is proposed. If the restriction is a.card < 10 and a.card is greater than 10, then the action a.card := 10 - 0,1 is proposed, where it must be said that the percentage which is additionally subtracted can be con gured by the user. Note that, for a greater than (>) relation, a percentage is added up.
Include alternative context If increments and edges of the context of a damaged link are missing, this repair type adapts references in the integration document from the damaged link to existing increments and edges in source or target graph (in one step) to make the context valid again for the damaged link. Nevertheless, the repair type is allowed to reassign edges from the non-context increments to the new context so that nally changes in the graphs are made. This repair is applied twice in the scenario of Figure 1 where the method links rst refer to the same context increment DataAccessObject in the source code and after the repair to the alternative context increments DBAccess and FileAccess, respectively.
Conserve the applied rule (not changing): Not doing any changes on the graphs but to heal each single damage is only possible for deleted increments and edges as they can be replaced with already existing increments and edges by adapting the references in the integration document. Violated attribute conditions cannot be reestablished as this would mean to change at least one value in the graphs.
Include alternative increment A deleted increment can be replaced by an alternative increment which exists in the respective graph if it is not used by another link. This increment must ful ll all conditions stated in the triple rule, as for example attribute restrictions or connections to other increments via edges.
Include alternative edge A deleted edge is only a cause for a damage if its two incident increments still exist. If not, then this damage is handled by alternative increment (see above). To nd an alternative edge for the deleted one means that either one of the incident increments or both are replaced with alternatives which exist in the graphs if they are not used by another link. As for the alternative increment repair type (see above) these increments have to ful ll all requirements of the rule.
Include alternative context This repair type is equal to the changing version (see above) not being allowed to do any change on the graphs. Thus, a valid context is included only if it is already connected as required to the non-context part of the link.
The following repair types do not conserve the originally applied rule but substitute it with a similar one. Apply a subset rule (changing): A triple rule is a subset rule of another triple rule if its RHS is a subset of the RHS of the other rule. If an applied rule is inconsistent, one can try to look for a subset rule which is still consistent in the given situation. The applicability of a subset rule is likely as a subset rule has less conditions which may not have been a ected by the modi cations of the user. If there exists such a subset rule which is not damaged, then increments which not appear in the subset rule but by the damaged rule are deleted. The situation after the repair is as if the subset rule had been applied.
Apply another rule from the same rule group (changing): Two rules are in the same rule group if they are ambiguous for a pattern in a graph which means the pattern can be represented in a dependent graph in two ways. If an applied rule is damaged it is likely to look for an alternative rule of the same rule group which is applicable and only do little adaptations to the graph; in case that some preconditions for applicability of the rule are not ful lled, their validity can be enforced with small changes on the graph. For example, required nodes and edges for the application of a di erent rule can be created and nodes and edges of the formerly applied rule which are not used by the alternative rule can be deleted.
Apply another rule from the same rule group (not changing): The same is possible without doing any changes on the graphs.
Apply another rule keeping the main increments: Like alternative rule repair, this repair action searches for another possible rule which can be applied. But instead of taking the whole pattern into account, it just searches for source and target main increments, as a minimal requirement for an alternative rule application if they still exist.
The strategies are implemented in a framework which was
built within the IMPROVE project (1997-2009) [
For concrete models speci c repair actions (i.e. graph transformations) for a damaged link are constructed after the damage check at runtime. The repair actions represent alternatives to make the link consistent again. They can be selected and prioritized so that the framework can be employed for various models and various phases of the development process with di erent requirements on resolution. We focus on the implementation of repair actions here, how they are built and executed.
A repair action is a concrete instance of a repair strategy for a category 2 inconsistency of a damaged link realized as graph transformation with a LHS and a RHS. The LHS and RHS of a repair action are modeled with Pattern objects which can be then interpreted at runtime by methods for pattern search and transformation by a graph transformation engine.
repairActions
«adt»
RepairAction -name -repairType match, search. create, delete, change «adt»
RepairOption repairOptions -name -repairType -matching -conflicts create, delete, change «adt»
Rule -conflicts «adt» GraphPatternHandling::Pattern -nodes -edges When repair actions are constructed it is not known if they really are applicable, i.e. if the search pattern has a match in the graph. If a match is found, then a RepairOption object is created which denotes a really applicable repair action. All options are o ered to the user. For each match of the search pattern found by the graph pattern search engine, the search pattern is enhanced with concrete matching node and edges ids of the graph and is now part of one RepairOption as matching. The repair option only references create, delete, and change patterns of the corresponding repair action. To construct a repair action for conserving the originally applied rule, the patterns are extended step-wise according to the sub strategies. For example, the enhancement to search for an alternative context bases on the patterns which are enhanced with pattern nodes and edges to search for alternative nodes. Repair actions without sub strategies can be constructed independently in one step and retrieve the pattern of the rule which is still intact, the remainder pattern. To demonstrate how repair actions are created we present as examples the implementation of the alternative nodes and context sub strategies. The methods describe how the di erent pattern objects are enhanced to match alternative nodes and an alternative context and replace the missing nodes and damaged context of a link.
Figure 6 shows the method which retrieves as input parameters a list2 of already created repair actions ras, the pattern 2Please note that creation of alternative edge repair is done of the rule rsPattern, and a damage pattern dmgPattern. The damage pattern contains the missing nodes and edges as well as those nodes which violate attribute conditions or restrictions. In this method, all repair actions of ras are extended. Alternative nodes and edges for the missing nodes and their incident edges are searched, i.e. they are added to the search pattern (lines 8 to 14). When the current repair action is applied all edges from the integration document to the alternative nodes are created, i.e. those edges are added to the create pattern (line 17).
Next, the repair actions are enhanced for searching for an alternative context. The method shown in Figure 7 is the changing (c) version and retrieves as input parameters the repair actions ras of the previous step. In this method, each repair action is doubled (line 7). One version (ra) searches for an alternative context group of a missing context node only in the graph of the missing node with pattern search. Nodes of the context are only added to the pattern, if the graph role is equal to the graph role of the missing node (lines 21 and 22). The other version (ra2) searches for an alternative context group in all three graphs with pattern search2. Nodes of the context are all added to this pattern (line 20). The edges of the alternative context are searched in ra only if they belong to the same graph as the missing context (line 27), ra2 searches all edges between the context nodes (line 25). Edges from the context nodes which points to other nodes in the same graph as the missing node are searched in both versions (lines 28 to 30). Those in the other graphs are created (line 32) and edges to the former context are deleted (line 33) but only for ra2. The repair action ra only reassigns edges within the integration document (lines 34 to 36).
To give an example, we present in Figure 8 the repair action ra2 which reassigns the operation getDBItem to the other class DBAccess which plays the role of the alternative context here. The search (LHS) pattern consists of the remaining graph with the current node ids. The nodes DataAccessObj in source and target graph as well as the ClassLink node between them are the context group which has to be replaced as the ownedOperation edge between DataAccessObj and getDBItem in the source graph is missing. The search pattern is extended by an additional context group, only edges between that nodes are added and the ownedOperation edge in the source graph where the edge is missing. The nodes and edges of the gluing graph K (K = LHS \ RHS) of the LHS and the RHS are not changed. The create pattern is the pattern RHSnK and the delete pattern is LHSnK and in this example the edges in the integration document and the target graph.
Generating repair actions at runtime is suitable because they cannot be all modeled beforehand foreseeing all possible changes a user can make. But this approach also implies performance problems when at runtime a set of repair actions is generated, most of them not being applicable as required, e.g., required nodes and edges of the search pattern are not present in the graph.
Therefore, we optimized the process by introducing phases before and that multiple repair actions are generated, i.e. 3e where e is the number of missing edges. 1 List<RepairAction> AlternativeContext_c( List<RepairAction> ras, Pattern rsPattern, Pattern dmgPattern) { 2 List<RepairAction> retRas = ras; 3 foreach (RepairAction ra in ras) { 4 Pattern search = ra.GetSearchPattern(); 5 Pattern create = ra.GetCreatePattern(); 6 Pattern delete = ra.GetDeletePattern(); 7 RepairAction ra2 = new RepairAction(); 8 retRas.Add(ra2); 9 Pattern search2 = new Pattern(search); 10 Pattern create2 = new Pattern(create); 11 Pattern delete2 = new Pattern(delete); 12 ra2.SetSearchPattern(search2); 13 ra2.SetCreatePattern(create2); 14 ra2.SetDeletePattern(delete2); 15 16 foreach (PatternNode patNode in
rsPattern.GetNodes()) 17 if(dmgPattern.ContainsKey(patNode) && rsPattern.IsContext(patNode)) { 18 Pattern ctxtGroup = rsPattern.
GetContextGroup(patNode); 19 foreach (PatternNode ctxtNode in
ctxtGroup) { 20 search2.Add(ctxtNode); 21 if(ctxtNode.graphRole.Equals(patNode .graphRole)) 22 search.Add(ctxtNode); 23 foreach (PatternEdge edge in
rsPattern.GetEdges(ctxtNode)) 24 if (ctxtGroup.ContainsKey(edge.
GetSourceNode() && ctxtGroup.
ContainsKey(edge.
GetTargetNode()) { 25 search2.AddEdge(edge); 26 if (edge.graphRole.Equals(patNode.
graphRole)) 27 search.AddEdge(edge); } 28 else if (edge.graphRole.Equals(
patNode.graphRole)) { 29 search.AddEdge(edge); 30 search2.AddEdge(edge); } 31 else { 32 create2.AddEdge(edge); 33 delete2.AddEdge(edge); 34 if(IntDocEdgeTypes.ContainsKey( edge.type)) 35 create.AddEdge(edge); 36 delete.AddEdge(edge);}}}} 37 return retRas; 38 } <<toConSrcIncr>> <<toConTrgIncr>> <<toSrcIncr>> <<Link>> <<toTrgIncr>> : ClassLink where only repair actions for a set of prede ned repair types are generated and tested. Only if no valid repair action could be found in one phase, repair actions of another set of repair types are tested in the next phase. This proved acceptable runtime behavior. The sets of repair types and the order of their execution can be con gured by the user. Additionally, a set of repair types can be speci ed which should be always tested.
There are many approaches handling inconsistencies with
graph transformations. One is, only delete and attribute
propagations or link deletions are supported as with our
approach, e.g. in [
Since not all kinds of inconsistencies like behavioral
inconsistencies and resolution rules can be expressed easily as graph
transformation rules, there are similar approaches [
A similar dynamic approach is proposed by [
In this paper, novel strategies for resolving inconsistencies between graph-based models taking into account only consistency rules speci ed as triple rules and the damaged subgraphs are presented. The operations which were performed on a model and lead to the inconsistencies are not considered as it is assumed that the models are edited by external tools. Also, resolution is done on request, thus tolerating inconsistencies. A main principle in resolving inconsistencies presented here is to conserve the applied rule or to apply a similar one and do only small adaptations. As discussed, we think that this is a good option in practice. Not presented in this paper, but nevertheless mentionable is that based on the presented strategies multiple alternative repair actions are derived for one damaged link, even multiple repair actions for the strategy to conserve the applied rule or to apply a similar one. Not all are applicable, i.e. required increments are not available, so that only applicable repair actions are suggested to the user. In the end, the user picks the repair action which ts best. This should not be decided by the tool.