Detecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis

Transcription

1 Detecting and Resolving Model Inconsistencies Using Transformation Dependency Analysis Tom Mens 1, Ragnhild Van Der Straeten 2, and Maja D Hondt 3 1 Software Engineering Lab, Université de Mons-Hainaut Av. du champ de Mars 6, 7000 Mons, Belgium tom.mens@umh.ac.be 2 Systems and Software Engineering Lab, Vrije Universiteit Brussel Pleinlaan 2, 1050 Brussel, Belgium rvdstrae@vub.ac.be 3 Jacquard INRIA project, Laboratoire d Informatique Fondamentale de Lille Villeneuve dascq Cedex, France dhondt@lifl.fr Abstract. Model inconsistency management is a crucial aspect of model-driven software engineering. It is therefore important to provide automated support for this activity. The problem is, however, that the resolution of inconsistencies may give rise to new inconsistencies. To address this problem, we propose to express inconsistency detection and resolutions as graph transformation rules, and to apply the theory of critical pair analysis to analyse potential dependencies between the detection and resolution of model inconsistencies. As a proof-of-concept, we report on an experiment that we have carried out along these lines using the critical pair analysis algorithm implemented in the state-of-the-art graph transformation tool AGG. The results show that both anticipated and unexpected dependencies between inconsistency detection and resolution rules are found by AGG. We discuss how the integration of the proposed approach into contemporary modelling tools may improve inconsistency management in various ways. 1 Introduction One of the important challenges in current-day model-driven software engineering is the ability to manage model inconsistencies. When designing models in a collaborative and distributed setting, it is very likely that inconsistencies in and between the models will arise because: (i) different models may be developed in parallel by different persons; (ii) the interdependencies between models may be poorly understood; (iii) the requirements may be unclear or ambiguous at an early design stage; (iv) the models may be incomplete because some essential information may still be unknown. In a model evolution context, the ability to deal with inconsistent models becomes even more crucial, as models are continuously subject to changes. Financial support provided through the European Community s Human Potential Programme under contract HPRN-CT , SegraVis. This work was carried out during the tenure of an ERCIM fellowship.

2 2 Mens, Van Der Straeten, D Hondt Nowadays, the UML is the de-facto general-purpose modelling language [1]. Current UML tools, unfortunately, provide poor support for inconsistency management and, if they do, it is usually ad-hoc. We believe that, in the process of managing inconsistencies, support should be provided to detect and resolve inconsistencies at any time the modeller wishes to do so. One way to approach this is to express inconsistency detection and resolutions as transformation rules [2]. In previous work, we explored the use of description logics as an alternative formalism for expressing inconsistency detection and resolutions as transformation rules [3, 4]. However, these transformation rules are typically not independent of one another: applying one rule might inhibit the application of another rule or, the opposite, it might trigger another rule, which suggests that an optimal ordering of rules has to be inferred, if possible. To be able to reason about such parallel and sequential dependencies between rules, we rely on the underlying theory of graph transformation, that allows us to exploit theoretical results about critical pair analyis [5]. As a proof of concept, we carry out an experiment with AGG 4 (version 1.4), a stateof-the-art graph transformation tool that implements a critical pair analysis algorithm [6]. We express model inconsistency detection and resolutions as graph transformation rules in this tool, and show how the transformation dependency analysis allows us to detect opportunities for ordering, refactoring and generally fine-tuning the inconsistency resolution rules. The experiment reported on in this article is carried out in four consecutive steps: (a) Identification. What are the model inconsistencies of interest for the subset of the UML metamodel that will be considered? (b) Specification. How can we formally express the model inconsistencies and their resolutions as graph transformation rules? (c) Dependency analysis. How can we detect parallel conflicts and sequential dependencies between the rules specified in the previous step, using the technique of critical pair analysis? (d) Interpretation of results. What can we learn from this dependency analysis? How can we exploit this information to automate the inconsistency management process? While our intitial results look very promising, it needs to be said that this research is still in the exploratory phase. Fully automated support of our ideas, as well as an empirical validation on industrial case studies, remains to be done. 2 Experimental Setup For illustration purposes, we restrict ourselves to model inconsistencies in UML models consisting of a simplified subset of UML 2.0 class diagrams and protocol state machine diagrams only. It is, however, straightforward to relax this restriction and to apply our approach to other types of UML diagrams as well. For example, we are currently extending our experiment to take sequence diagrams into account. Rather than specifying the model inconsistencies and resolutions in some dedicated modelling tool we decided, for reasons of genericity, to represent UML models in a graph-based format in the general-purpose graph transformation tool AGG. The metamodel for the considered UML subset is expressed as a so-called type graph as shown in 4 See

3 Transformation-based model inconsistency management 3 Fig. 1. Simplified metamodel for UML class diagrams and state machine diagrams, expressed as a type graph with edge multiplicities in AGG. In addition, a node type Conflict is introduced to represent model inconsistencies. Fig. 1. The UML models themselves will be represented as graphs that are constrained by this type graph. These graphs can be generated automatically from the corresponding UML models by exporting them from a modelling tool in XMI format, converting them into GXL format, and importing them into AGG. An experiment along these lines has been carried out by Laurent Scolas as a student project. Note that there need not be any loss of information when generating graphs from UML models, provided that the type graph is sufficiently close to the UML metamodel. Given an explicit description of this metamodel, it would even be possible to generate the corresponding type graph automatically. 2.1 Identification of Model Inconsistencies and Their Resolutions The set of inconsistencies we restrict ourselves to is based on the model elements occurring in the chosen subset of the UML. In [3], a classification of inconsistencies and its motivation has been presented. In the current article, we only take into account structural inconsistencies. For example, the constraint that a concrete class should not contain abstract operations yields a structural inconsistency that can be resolved in various ways. 5 Structural model inconsistencies can be found by detecting the presence or absence of certain patterns in the graph representing the model. In the example above, this would be the presence of a concrete class node, and the presence of abstract operation nodes contained in this class. The specification of behaviour (especially in presence of inheritance) can also introduce behavioural inconsistencies. Because structural patterns do not suffice to express such inconsistencies, we used the formalism of description logics in earlier work [3]. As such, we do not consider this type of inconsistencies in the current article. 5 Alternatively, this inconsistency could be avoided by imposing a graph invariant that prevents this situation, but this would impose to many restrictions on the modeler.

4 4 Mens, Van Der Straeten, D Hondt For each inconsistency we describe a set of resolutions using the following template: NameOfModelInconsistency. Description of model inconsistency. 1. First possible resolution to resolve the model inconsistency 2. Second inconsistency resolution, and so on... The resolutions proposed for each inconsistency boil down to the addition, deletion or modification of relevant model elements. Below we provide a representative, yet incomplete, list of structural model inconsistencies and several alternative ways to resolve them. DanglingTypeReference. An operation has one or more parameters whose types are not specified. It can be resolved in 3 different ways: 1. Remove the parameter whose type is undefined. 2. Assign an existing class as the type of the previously undefined parameter. 3. Assign a new class as the type of the previously undefined parameter. ClasslessInstance. A model contains an instance specification without a corresponding class. Possible resolutions are: 1. Remove the instance specification. 2. Link the instance specification to an existing class. 3. Link the instance specification to a new class. AbstractObject. A model contains an instance specification of an abstract class that does not have any concrete subclasses. (This is an inconsistency since abstract classes cannot be instantiated.) 1. Change the abstract class into a concrete one. 2. Redirect the target of the instance of relation to a new concrete descendant class of the abstract class. 3. Remove the instance specification. AbstractOperation. An abstract operation is defined in a concrete class. (This is an inconsistency since a concrete class is not supposed to have abstract operations.) 1. Change the abstract operation into a concrete one. 2. Remove the abstract operation. 3. Change the concrete class containing the abstract operation into an abstract class. 4. Move up the abstract operation to an existing abstract ancestor class of the concrete class. 5. Move up the abstract operation to a new abstract ancestor class of the concrete class. 6. Move down the abstract operation to an existing abstract descendant class of the concrete class. 7. Move down the abstract operation to a new abstract descendant class of the concrete class. AbstractStateMachine. A state machine expresses the behaviour of an abstract class that does not have any concrete subclasses. 1. Remove the state machine. 2. Connect the state machine to an existing concrete class. 3. Change the abstract class into a concrete one.

5 Transformation-based model inconsistency management 5 DanglingOperationReference. A state machine contains a transition that refers to an operation that does not belong to any class. 1. Add the operation to the class whose behaviour is described by the state machine. 2. Let the transition refer to an existing operation belonging to the class whose behaviour is described by the state machine. 3. Remove the reference from the transition to the operation. 4. Remove the transition. 2.2 Specification of Inconsistency Detection and Resolution Rules in AGG In this section we explain how to specify inconsistency detection and resolutions as graph transformation rules in AGG. To detect occurrences of model inconsistencies, we specify them as graph transformation rules. Their left-hand side contains the graph structure corresponding to a model inconsistency. This structure can be composed of a positive condition (presence of certain combinations of nodes and edges) and a set of negative conditions (absence of certain combinations of nodes and edges). On the right-hand side of the transformation rule a new node of type Conflict is introduced. It always points to one of the nodes that characterise the model inconsistency. To avoid detecting the same occurrence of a model inconsistency more than once, we attach a default negative application condition (NAC) to each rule, specifying that a Conflict node should be absent in the graph structure determining the model inconsistency. Figure 2 gives some examples of model inconsistencies specified as transformation rules. The default NACs are not shown. Fig. 2. Detecting model inconsistency occurrences as graph transformation rules with optional NACs in AGG. If a rule contains more than two panes, the leftmost pane represents a NAC, which should be seen as a forbidden structure. The next pane represents the positive part of the rule s left-hand side. The rightmost pane represents the right-hand side of the rule. For the rule AbstractOperation, no NAC has been specified.

6 6 Mens, Van Der Straeten, D Hondt In the remainder of this article, resolution rules denote the graph transformation rules expressing an inconsistency resolution. To specify such resolution rules, we assume that a model inconsistency occurrence has been detected before. Hence, the graph will already contain at least one Conflict-node indicating an inconsistency that needs to be resolved. After applying the resolution rule, the model inconsistency is no longer present, and the corresponding Conflict-node is removed from the graph structure. Figure 3 shows some examples of inconsistency resolutions specified as graph transformation rules. For the names of the resolution rules, we use the numbering scheme introduced in Sect For example, rule AbstractObject-Res3 corresponds to the third resolution for the AbstractObject model inconsistency. Our resolution rules typically do not require negative application conditions since they always check for the presence of a Conflict node, introduced previously by the corresponding detection rule. Fig. 3. Specification of inconsistency resolutions as graph transformation rules. The left-hand side always contains a Conflict-node, which is removed in the right-hand side.

7 Transformation-based model inconsistency management 7 3 Transformation Dependency Analysis in AGG In this section, we explain how to use static analysis on graph transformation rules to detect mutual exclusions and causal dependencies between the transformation rules introduced before. The analysis is based on the formal notion of independence of graph transformations. It expresses the idea that, in a given situation, two transformations are neither causally dependent nor mutually exclusive. A distinction can be made between the notions of parallel independence (absence of mutual exclusions) and sequential independence (absence of causal dependencies). A formal treatment of these concepts is given in [7]. Based on this notion of independence, a potential parallel or sequential dependency is defined as a pair of transformation rules for which a counter example to parallel or sequential independency can be found. More precisely, two rules are mutually exclusive if application of the first rule prevents application of the second one or vice versa. They are sequentially dependent if application of the second rule requires prior application of the first rule. The goal of critical pair analysis [5] is then to compute all potential mutual exclusions and sequential dependencies for a given set of transformation rules by pairwise comparison. A critical pair formalises the idea of a minimal example of a conflicting situation. To achieve such critical pair analysis, we use the tool AGG, since it is the only available graph transformation tool that implements this technique. Fig. 4. Example of a critical pair illustrating a mutual exclusion between resolution rules AbstractObject-Res1 and AbstractOperation-Res4. Fig. 4 illustrates a critical pair that identifies a mutual exclusion between the resolution rules AbstractObject-Res1 and AbstractOperation-Res4. It is computed by comparing the left-hand sides of both rules, that partially overlap in the coloured class with label 1. This corresponds to a mutually conflicting situation (of type change-useattr-conflict ), since the first resolution rule will make the class concrete, whereas the second resolution rule requires for its application that the class remains abstract.

8 8 Mens, Van Der Straeten, D Hondt Fig. 5. Example of a critical pair illustrating a sequential (causal) dependency of resolution rule AbstractOperation-Res3 on resolution rule AbstractObject-Res1. Figure 5 illustrates a critical pair that identifies a sequential dependency between two resolution rules. The rules AbstractObject-Res1 and AbstractOperation-Res3 are clearly sequentially dependent, if applied to the same class, since the first rule makes an abstract class concrete, whereas the second rule requires the class to be concrete for its application. As such, the application of the first rule enables the application of the second rule. This causal dependency is detected as an overlap (the coloured class with label 1) between the right-hand side of the first rule and the left-hand side of the second rule. 4 Interpretation of Results The main contribution of the proposed technique is that it allows for the static analysis (i.e., independent of any concrete UML model) of mutual exclusions and sequential dependencies between different resolution rules for structural model inconsistencies. This section provides a detailed analysis of the results of the transformation dependency analysis that we performed on the inconsistency detection and resolution rules presented in Sect Mutual Exclusion Analysis When we apply the critical pair analysis algorithm to identify all mutual exclusions between inconsistency detection and resolution rules, we get the following results, which are also summarised in the top part of Table 1: 1. Each inconsistency detection rule is mutually exclusive to itself, in order to avoid the same occurrence of a model inconsistency being detected more than once. 2. No mutual exclusions are found between pairs of distinct detection rules. This corresponds to our intuition, since each rule detects a different kind of model inconsistency. As a result, all detection rules are parallel independent of one another.

9 Transformation-based model inconsistency management 9 Table 1. Classification of mutual exclusions and sequential dependencies. The numbers between parentheses correspond to the explanation that can be found in the numbered lists in the text. The top table summarises the results of the mutual exclusion analysis of Section 4.1, whereas the bottom table summarises the results of the sequential dependency analysis of Section 4.2. mutual exclusion analysis for the same kind of inconsistency between different kinds of inconsistencies detection rule conflicts with detection rule Always (1) Never (2) detection rule conflicts with resolution rule Always (3) Sometimes (4) resolution rule conflicts with resolution rule Always (5) Sometimes (6) sequential dependency analysis for the same kind of inconsistency between different kinds of inconsistencies detection rule depends on detection rule Never (1) Never (2) resolution rule depends on resolution rule Sometimes (3) Sometimes (4) resolution rule depends on detection rule Always (5) Never (6) detection rule depends on resolution rule Sometimes (7) Sometimes (8) 3. By construction, every detection rule is mutually exclusive to each of the resolution rules for a particular kind of inconsistency. This is because, for any particular inconsistency, each of the resolution rules disables the detection rule. 4. Some detection rules are also mutually exclusive to a resolution rule for another kind of model inconsistency, or vice versa. These situations indicate that the different kinds of model inconsistencies and their resolutions are not completely orthogonal. Such information may be exploited to refactor the detection and resolution rules to make them less redundant (see Sect. 6). 5. Alternative resolution rules for the same model inconsistency are always mutually exclusive, because they represent alternative resolutions. One needs to select a single resolution in order to resolve the inconsistency and thus disable the other resolutions. 6. The most interesting result concerns the mutual exclusions between resolution rules for distinct inconsistencies. In Fig. 6, we see many such examples. They imply that the application of a particular resolution for a particular model inconsistency may prohibit the application of a certain resolution for another model inconsistency. An example of such a situation was explained in the previous section, and visualised in Fig. 4. If we have a class that causes an AbstractObject inconsistency and an AbstractOperation inconsistency at the same time, certain pairs of resolutions for both inconsistencies will be mutually exclusive. This is for example the case between AbstractObject-Res1 and AbstractOperation-Res Sequential Dependency Analysis We also used AGG to compute all critical pairs that identify sequential dependencies between the inconsistency detection and resolution rules. This leads to the following results, which are summarised in the bottom part of Table 1:

10 10 Mens, Van Der Straeten, D Hondt Fig. 6. Graph depicting mutual exclusions between resolution rules of distinct model inconsistencies. Except for some layout issues, this graph has been generated automatically by AGG. In order not to clutter the figure, mutual exclusions between different resolution rules of the same model inconsistency have been omitted. 1. By construction, a detection rule never causally depends on itself. 2. In a similar vein, distinct detection rules are not causally dependent because they do not essentially modify the graph structure. The only thing they do is adding a new Conflict-node. 3. Alternative resolution rules for the same model inconsistency are sometimes sequentially dependent. This may be a sign of redundancy between the resolution rules, and it may indicate an opportunity for refactoring the resolutions in order to make them more orthogonal. For example, we noticed a dependency from the second to the third resolution rule of DanglingTypeReference, from the second to the third resolution of ClasslessInstance, from the fourth to the fifth resolution of AbstractOperation, and from the sixth to the seventh resolution of AbstractOperation. These four dependencies all boil down to the same underlying problem. For each resolution rule that adds some link to an existing class, there is a similar resolution rule that first introduces a new class before adding a link to it. Such redundancies can easily be avoided by restructuring the resolution rules. 4. As shown in Fig. 7, there are many sequential dependencies between resolution rules for distinct model inconsistencies. This has two important implications. First, it shows that the resolution of a particular model inconsistency may introduce new and different opportunities for resolving other model inconsistencies. As such, the order of resolution of model inconsistencies may be important. Second, some of the identified sequential dependencies indicate a lack of orthogonality between the various resolutions. This can be seen clearly in the mutual dependency between AbstractObject-Res1 and AbstractStateMachine-Res3, and between Classless- Instance-Res1 and AbstractObject-Res3. In both cases, the resolutions are exactly the same, even though they are used to solve different kinds of model inconsistencies. Again, our analysis helps us to detect such redundancies. 5. Every resolution rule for a given model inconsistency sequentially depends on the detection rule of the same inconsistency, since the detection rule produces a Conflict-node that is required for the application of the resolution rule.

11 Transformation-based model inconsistency management In our current setup, resolution rules for a certain inconsistency never depend on detection rules for another kind of inconsistency, because the Conflict-node contains a description specifying the kind of inconsistency being detected or resolved. 7. Sometimes, the detection of a model inconsistency is triggered by the resolution of another occurrence of the same model inconsistency. This is a degenerate case of the more general situation that is discussed below. 8. In general, the resolution of a model inconsistency may give rise to the introduction of new model inconsistencies. The left part of Fig. 8 shows many such cases of model inconsistencies that are caused by application of a resolution rule. For example, there is a sequential dependency from AbstractObject-Res1 to AbstractOperation. Indeed, by applying the resolution rule AbstractObject-Res1 (see Fig. 3), a previously abstract class will become concrete. If this abstract class happened to have one or more abstract operations (a situation that is completely acceptable), after the resolution all of these operations will lead to an AbstractOperation inconsistency because a concrete class is not allowed to have abstract operations. Fig. 7. Graphs depicting all sequential dependencies between distinct resolution rules. 5 Discussion The ultimate goal of the mutual exclusion analysis and sequential dependency analysis carried out in the previous subsections is to improve the inconsistency resolution process. Mutual exclusion relationships can be used to identify situations where resolution rules for seemingly different model inconsistencies may interfere in unexpected ways. Sequential dependencies allow us to assess the propagation of model inconsistencies during the resolution process. The fact that the resolution of one model inconsistency may introduce other inconsistencies is a clear sign of the fact that inconsistency resolution is a truly iterative

12 12 Mens, Van Der Straeten, D Hondt Fig. 8. The left graph depicts which model inconsistencies sequentially depend on which resolution rules. The right graph shows how these dependencies can give rise to cycles in the conflict resolution process. process, similar in spirit to bug fixing: when fixing one bug, new bugs may appear that need to be fixed as well. One of the challenges is to find out whether the resolution process will ever terminate. Situations that may lead to infinite application of resolution rules can easily be recognised as cycles in the rule dependency graph. As an example of a cycle of length two, we can repeatedly apply resolution rules AbstractObject-Res1 and AbstractOperation-Res3 ad infinitum, without ever reaching a solution. On the right of Fig. 8, another example of a cycle of three resolution rules is presented, that was detected by analysing the dependency graph. In general, the more inconsistencies and resolution rules there are, the more likely it becomes that longer cycles occur, and the more difficult it becomes to detect these cycles. Therefore, automatic detection of such cycles is essential to improve the resolution process. Based on the analysis of all mutual exclusion relationships and causal dependencies between resolution rules, we realised that these rules are not truly orthogonal, and can be refactored in order to remove redundancy. For example, we observed that some resolution rules for certain inconsistencies disable detection rules of other inconsistencies. These resolution rules can be made more orthogonal so that they only affect the inconsistency that they are meant to resolve. Another refactoring possibility becomes apparent by comparing the dependencies detected by different resolution rules of the same inconsistency. In both cases, investigating the overlap graph that is constructed in the critical pair analysis may be used in a semi-automatic way to suggest refactoring opportunities. With respect to tool support, the results of the analysis can be exploited in various ways. If we target semi-automated tool support, we can easily imagine a user interface (integrated into a UML modelling tool) where, for a given UML model, all model inconsistencies are identified in an automated way, and the user is presented a list of resolution actions. Upon selection of such an action, all mutually exclusive actions will

13 Transformation-based model inconsistency management 13 be disabled, and all sequentially dependent actions will become enabled. As such, at any point in time, the user knows exactly which rules can be applied and which not. Currently, different student projects are underway to integrate this kind of support into current-day modelling environments. Once this is achieved, we will perform concrete experiments with the evolution of UML models, which will allow us to refine and extend the incomplete list of model inconsistencies and resolution rules presented in this paper. A more automated kind of support would offer the user a set of different resolution strategies and, upon selection of one of these strategies, a path of resolution rules is computed to resolve all model inconsistencies. Since there can be many such paths, it remains an open question on what would be the most optimal resolution strategy. In order to find an answer to this question, practical case studies are needed in order to determine the typical ways in which model inconsistencies are resolved in practice. 6 Limitations and Future Work A limitation of the current approach that we are well aware of, is the fact that not all kinds of model inconsistencies and resolution rules can be expressed easily as graph transformation rules. For some complex model inconsistencies and resolution rules, programmed graph transformations are required, which allow for expressing sequences, loops and branches of transformation rules. For example, to detect the presence of unreachable states in a state machine, we need to apply a sequence of two rules. The first rule should be applied as long as possible to infer all transitively reachable states, starting from the initial state. The second rule is needed to identify all remaining states, which are by construction those that are unreachable. Behavioural inconsistencies are also difficult to express in a graph-based way. Because of this, in earlier work we have explored the formalism of description logics for this purpose [3, 4]. How this formalism can be combined with the formalism of graph transformation, so that we can still benefit from the technique of critical pair analysis, remains a topic of future work. Another limitation of our current work is that we restricted ourselves to a subset of class diagrams and state machine diagrams only. Our work should be extended to cover the full version of these diagrams, as well as other UML diagrams such as sequence diagrams, component diagrams, activity diagrams, and so on. AGG s current implementation of critical pair analysis suffers from performance problems. It took several hours to compute all results. This is not an immediate concern to us since, for any given set of model inconsistency detection and resolution rules, the computation of mutual exclusion relationships and sequential dependencies needs to be carried out only once, and the results can be stored for future reference. Moreover, a comparison of AGG with another tool, Condor, seems to suggest that performance of the transformation dependency analysis algorithm may be improved without loss of expressiveness [8].

14 14 Mens, Van Der Straeten, D Hondt 7 Related Work In [4, 2], another logic rule-based inconsistency resolution approach similar in spirit to the one presented here was proposed. The main novelty of the current paper, however, is the use of dependency analysis between the different resolution rules. The same remark holds when comparing our work to other attempts to use graph transformation in the context of inconsistency management. In [9], distributed graph transformation is used to deal with inconsistencies in requirements engineering. In [10], graph transformations are used to specify inconsistency detection rules. In [11] repair actions are also specified as graph transformation rules. There are other approaches to inconsistency management that define resolution actions and the way the user can select these actions [12 15]. Again, in contrast to our current work, these approaches do not rely on a formal analysis of the relationships between the various resolution actions. In order to analyse dependencies between transformation rules, we relied on the technique of critical pair analysis of graph transformations. [16] also used this technique to detect conflicting functional requirements in UML models composed of use case diagrams, activity diagrams and collaboration diagrams. In [17], critical pair analysis was used to detect conflicts and dependencies between software refactorings. Other work on critical pair analysis is reported by [18]. 8 Conclusion This article focused on the problem of model inconsistency management, and the ability to provide more disciplined support for iteratively and incrementally detecting and resolving model inconsistencies. For this purpose we explored the use of graph transformation dependency analysis, and critical pair analysis in particular. The main contribution of the proposed approach is that it enables a formal and static analysis of mutual exclusion relationships and causal dependencies between different alternative resolutions for model inconsistencies that can be expressed in a graph-based way. This analysis can be exploited to improve the inconsistency resolution process, for example, by facilitating the choice between mutually incompatible resolution strategies, by detecting possible cycles in the resolution process, by proposing a preferred order in which to apply certain resolution rules, and so on. In the future, we intend to integrate our ideas into a modelling environment in order to provide more disciplined semi-automated tool support for model inconsistency management. References 1. Object Management Group: Unified Modeling Language 2.0 Superstructure Specification. (2005) 2. Van Der Straeten, R., D Hondt, M.: Model refactorings through rule-based inconsistency resolution. In: ACM SAC Track on Model Transformation. (2006) To appear. 3. Van Der Straeten, R., Mens, T., Simmonds, J., Jonckers, V.: Using description logics to maintain consistency between UML models. In: UML The Unified Modeling Language. Volume 2863 of Lecture Notes in Computer Science., Springer-Verlag (2003)

15 Transformation-based model inconsistency management Van Der Straeten, R.: Inconsistency Management in Model-driven Engineering. An Approach using Description Logics. PhD thesis, Department of Computer Science, Vrije Universiteit Brussel, Belgium (2005) 5. Plump, D.: Hypergraph rewriting: Critical pairs and undecidability of confluence. In: Term Graph Rewriting. Wiley (1993) Taentzer, G.: AGG: A graph transformation environment for modeling and validation of software. In: Proc. AGTIVE Volume 3062 of Lecture Notes in Computer Science., Springer-Verlag (2004) Ehrig, H., Prange, U., Taentzer, G.: Fundamental theory for typed attributed graph transformation. In: Proc. Int l Conf. Graph Transformation. Volume 3256 of Lecture Notes in Computer Science., Springer-Verlag (2004) Mens, T., Kniesel, G., Runge, O.: Transformation dependency analysis - a comparison of two approaches. Série L objet - logiciel, base de données, réseaux (2006) 9. Goedicke, M., Meyer, T.,, Taentzer, G.: Viewpoint-oriented software development by distributed graph transformation: Towards a basis for living with inconsistencies. In: Proc. Requirements Engineering 1999, IEEE Computer Society (1999) Ehrig, H., Tsioalikis, A.: Consistency analysis of UML class and sequence diagrams using attributed graph grammars. In: ETAPS 2000 workshop on graph transformation systems. (2000) Hausmann, J.H., Heckel, R., Sauer, S.: Extended model relations with graphical consistency conditions. In: Proc. UML 2002 Workshop on Consistency Problems in UML-Based Software Development. (2002) Easterbrook, S.: Handling conflict between domain descriptions with computer-supported negotiation. Knowledge Acquisition 3 (1991) Nentwich, C., Emmerich, W., Finkelstein, A.: Consistency management with repair actions. In: Proc. 25th Int l Conf. Software Engineering, IEEE Computer Society (2003) Spanoudakis, G., Finkelstein, A.: Reconciling requirements: a method for managing interference, inconsistency and conflict. Ann. Softw. Eng. 3 (1997) Kozlenkov, A., Zisman, A.: Discovering, recording, and handling inconsistencies in software specifications. Int l Journal of Computer and Information Science 5 (2004) 16. Hausmann, J.H., Heckel, R., Taentzer, G.: Detection of conflicting functional requirements in a use case-driven approach. In: Proc. Int l Conf. Software Engineering, ACM Press (2002) 17. Mens, T., Taentzer, G., Runge, O.: Analyzing refactoring dependencies using graph transformation. Software and Systems Modeling (2006) To appear. 18. Bottoni, P., Taentzer, G., Schürr, A.: Efficient parsing of visual languages based on critical pair analysis and contextual layered graph transformation. In: Proc. IEEE Symp. Visual Languages. (2000)