Badger: A Regression Planner to Resolve Design Model Inconsistencies

Badger: A Regression Plannerto Resolve Design Model

InconsistenciesJorge Pinna Puissant, Tom Mens and Ragnhild Van Der Straeten

received best foundations paper award from EAPLS (European Association for Programming Languages and Systems)

Published in ECMFA 2012, LNCS 7349, pp. 146-161DOI: 10.1007/978-3-642-31491-9_13

The ProblemAn UML class diagram with 2 inconsistencies

+ getDiameter():float,integer

- pressure:float

Wheel

+ turnRight():void+ turnLeft():void

- model:string- manufactor: string

Car

0 .. 2 4

The ProblemTwo structural inconsistency occurrences :

• Multiplicity composition constraint.

• Operation return constraint.


- pressure:float

Wheel



Car

0 .. 2 4





- pressure:float

Wheel



Car

0 .. 2 4





- pressure:float

Wheel



Car

0 .. 2 4

Example of resolutions


-model:string-manufactor:string

Car

+ getDiameter():integer

- pressure:float

Wheel0..1 4



Car

+ getDiameter():float

- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..2 4



Car


- pressure:float

Wheel0..2 4



Car

+ getDiameter(float):integer

- pressure:float

Wheel

Idea

The Model

The detected Inconsistencies

Resolution Plans

Multiplicity composition constraint Operation return constraint


- pressure:float

Wheel



Car

0 .. 2 4



Car


- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..2 4



Car


- pressure:float

Wheel0..2 4



Car


- pressure:float

Wheel

Idea

The Model

The detected Inconsistencies

Resolution Plans

Multiplicity composition constraint Operation return constraint


- pressure:float

Wheel



Car

0 .. 2 4



Car


- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..2 4



Car


- pressure:float

Wheel0..2 4



Car


- pressure:float

Wheel

Autom

ated P

lanning

Automated Planning and Scheduling

Desired GoalInitial State

x

yPut Down Stack

Rotate

Set of Actions

Plan


Desired GoalInitial State

x

yPut Down Stack

Rotate

Set of Actions

Plan

Model with inconsistencies

Model without inconsistencies

Elementary model operations


Each planning approach consists of :

• A problem domain (possible actions)

• A problem (initial state and desired goal)

• An algorithm

Badger

• A regression planner implemented in Prolog.

• Regression planning searches backwards from the goal to the initial state.

• The use of Prolog provides to the planner the possibility to generate several resolution plans.

Badger

• It works only with relevant actions. Because of this, the search space will be significantly smaller.

• A regression planner’s search space depends mainly on the size of the desired goal.

Initial State

• Is expressed as a conjunction of literals, and represents the current model.

Initial State

Initial State

• Is represented using Praxis (Blanc et al. 2008)

• metamodel independence

• Models and model changes are sequences of elementary model operations

• create, addProperty, addReference, delNode, remProperty, remReference

Initial State

160 J. Pinna Puissant, R. Van Der Straeten, and T. Mens

We have stress-tested our approach on 941 automatically generated UMLclass diagram models of varying sizes using a set of 13 structural inconsistencytypes based on OCL constraints found in the UML metamodel specification.Our approach for resolving inconsistency occurrences appears to be linear inthe size of the model, and scales up to models containing more than 10000model elements. The execution time also increases as the number of actionsin the resolution plan increases. With respect to the number of inconsistencyoccurrences, the approach is quadratic in time. However, controlled user studiesare still needed to adapt the cost function and evaluate the preferred order ofthe generated resolution plans.

Acknowledgments. This work has been partially supported by (i) the F.R.S. –FNRS through FRFC project 2.4515.09 “ResearchCenter on Software Adaptabil-ity”; (ii) research project AUWB-08/12-UMH “Model-Driven SoftwareEvolution”, an Action de Recherche Concertee financed by the Ministere de laCommunaute francaise - Direction generale de l’Enseignement non obligatoire etde la Recherche scientifique, Belgium; (iii) the Interuniversity Attraction PolesProgramme – Belgian State – Belgian Science Policy.

References

1. Almeida da Silva, M.A., Mougenot, A., Blanc, X., Bendraou, R.: Towards Auto-mated Inconsistency Handling in Design Models. In: Pernici, B. (ed.) CAiSE 2010.LNCS, vol. 6051, pp. 348–362. Springer, Heidelberg (2010)

2. Blanc, X., Mougenot, A., Mounier, I., Mens, T.: Detecting model inconsistencythrough operation-based model construction. In: Proc. Int’l Conf. Software Engi-neering, vol. 1, pp. 511–520 (2008)

3. Bratko, I.: Prolog programming for artificial intelligence. Addison-Wesley (2001)4. Demsky, B., Rinard, M.C.: Automatic detection and repair of errors in data struc-

tures. In: Int’l Conf. on Object Oriented Programming, Systems, Languages andApplications, pp. 78–95. ACM (2003)

5. Egyed, A.: Automatically detecting and tracking inconsistencies in software designmodels. IEEE Trans. Software Eng. 37(2), 188–204 (2011)

6. Egyed, A., Letier, E., Finkelstein, A.: Generating and evaluating choices for fixinginconsistencies in UML design models. In: Proc. Int’l Conf. Automated SoftwareEngineering, pp. 99–108. IEEE (2008)

7. Ho!mann, J.: FF: The Fast-Forward Planning System. The AI Magazine (2001)8. Ho!mann, J., Nebel, B.: The FF Planning System: Fast plan generation through

heuristic search. Journal of Artificial Intelligence Research 14, 253–302 (2001)9. Jimenez Celorrio, S.: Planning and Learning under Uncertainty. PhD thesis, Uni-

versidad Carlos III de Madrid (2010)10. Jose, M., Majumdar, R.: Cause clue clauses: error localization using maximum sat-

isfiability. In: Proc. Conf. on Programming Language Design and Implementation,pp. 437–446. ACM (2011)

11. Kuster, J.M., Ryndina, K.: Improving Inconsistency Resolution with Side-E!ectEvaluation and Costs. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.)MODELS 2007. LNCS, vol. 4735, pp. 136–150. Springer, Heidelberg (2007)

Initial State


planner, as the latter depends mainly on the size of the initial state and doesnot exclude irrelevant actions.

We implemented the planner algorithm in Prolog, since Prolog’s built-in back-tracking mechanism allows the planner to easily generate multiple resolutionplans among which the user can choose the most suitable one.

4.1 Problem and Problem Domain

The initial state is expressed as a conjunction of logic literals that represents theinput model. We specify the models using Praxis [2], a language that representsmodels and model changes as sequences of elementary model operations (create,addProperty, addReference, delNode, remProperty, remReference). Praxiscomes with a suite of Eclipse plugins: a plugin to reason about ECore and XMImodels; a plugin to generate class diagram models of varying sizes [15]; and amodel inconsistency detection engine [2]. As an example, the class Car of theclass diagram model of Figure 2 is represented as follows3:

create(c1, class).addProperty(c1, name, ‘Car’).create(att1, property).addProperty(att1, name,‘model’).addReference(att1, type,string).addReference(c1, ownedattribute, att1).create(att2, property).addProperty(att2, name,‘manufactor’).addReference(att2, type,string).addReference(c1, ownedattribute, att2).create(op1, operation).addProperty(op1, name,‘turnRight’).addReference(c1, ownedoperation,op1).create(op2, operation).addProperty(op2, name,‘turnLeft’).addReference(c1, ownedoperation,op2).

This way of representing models o!ers several advantages. The elementary modeloperations are metamodel independent, i.e., they can be used together with anykind of structural metamodel. The second parameter of each model operationrefers to an element of the metamodel (e.g., class, ownedattribute,parameter,ownedoperation).

The desired goal is a partially specified state that represents the objectiveto be reached, namely the absence of model inconsistencies, as a negation ofinconsistency occurrences. An inconsistency occurrence is detected if it matchesthe pattern defined by the inconsistency type. Table 2 presents all logic opera-tors that are allowed to specify the desired goal, inspired by the list of commonconstructs found in inconsistency types [5, 16, 21]. Our approach does the strict

3 In principle, each of the listed model operations should also have a timestamp thatwe have left out for the sake of readability.


- pressure:float

Wheel



Car

0 .. 2 4

Desired Goal

• Is a partially specified state

• Represents the objective to be reached: the absence of inconsistencies

• Uses the negation of inconsistency occurrences

Desired Goal

Desired Goal

Badger: A Regression Planner to Resolve Design Model Inconsistencies 151

minimum to accomplish this goal. For example, if the user wants to solve theinconsistency “the lower multiplicity must be greater than 0”, Badger will pro-poses 1 as solution to avoid an infinite number of possibilities.

Table 2. Logic Operators. Although the operators value comparison, property compar-ison and counting are only shown with the > function, the other comparison functionscan be used as well : <, !, ", =, #=

NameNegative Syntax not(P)literal Semantics ¬P

Example not(lastAddProperty(ae2,iscomposite,‘true’))

ConjunctionSyntax [P, Q]

Semantics P ! QExample [lastAddProperty(c1,name,‘Vehicle’),

lastAddProperty(c2,name,‘Aircraft’)]

DisjunctionSyntax or [P, Q]

Semantics P " QExample or [lastAddProperty(c1,name,‘Vehicle’),

lastAddProperty(c1,name,‘Aircraft’)]Universal Syntax forall(P,Q)

quantification Semantics #x(P (x) $ Q(x))Example forall(lastCreate(X,class), lastAddProperty(X,name,Y))

Existential Syntax exists(P)quantification Semantics %xP (x)

Example exists(lastCreate(X,class))Value Syntax compare(P,>,v)

comparison Semantics #n & N(P (n) ! v & N ! n > v)Example compare(lastAddProperty(ae1,lower mult,X),>,0)

Property Syntax compare(P,>,Q)Comparison Semantics #n,m(P (n) ! Q(m) ! n > m)

Example compare(lastAddProperty(ae1,upper mult,X),>,lastAddProperty(ae1,lower mult,Y))

CountingSyntax count(P,>,v)

Semantics (|{x|P (x)}| > v ! v & N)Example count(lastAddReference(assID,member,X),>,2)

Transitive Syntax nav(From, Kind, To)Navigability Semantics (Kind(From,To) $ nav(From,Kind, To))"

%c(nav(From,Kind, c) ! nav(c,Kind, To) $ nav(From,Kind, To))Example nav(c1,generalization,c9)

As an example, the desired goal to resolve an inconsistency occurrence of typeI10 is specified below as a negation of this inconsistency occurrence, using thelogic operators of Table 2. It disallows the upper bound of the multiplicity onthe aggregate end of a composite aggregation to be greater than 1.

or [not(lastAddProperty(prop1,aggregation,‘composite’)),not(compare(lastAddProperty(prop1,upper,X),>,1))]

The use of prefix last in model operation lastAddProperty is needed to point tothose operations in the model that are not followed by other operations cancelingtheir e!ects [2]. Using the negation of the inconsistency occurrences in the desiredgoal will only be able to resolve inconsistency occurrences that have already beenidentified previously. For this detection, we can rely on the detection approachproposed by [2].

logic operators to specify the desired goal:

Desired Goal

Negation of the Inconsistency Occurrence :


minimum to accomplish this goal. For example, if the user wants to solve theinconsistency “the lower multiplicity must be greater than 0”, Badger will pro-poses 1 as solution to avoid an infinite number of possibilities.

Table 2. Logic Operators. Although the operators value comparison, property compar-ison and counting are only shown with the > function, the other comparison functionscan be used as well : <, !, ", =, #=

NameNegative Syntax not(P)literal Semantics ¬P

Example not(lastAddProperty(ae2,iscomposite,‘true’))

ConjunctionSyntax [P, Q]

Semantics P ! QExample [lastAddProperty(c1,name,‘Vehicle’),

lastAddProperty(c2,name,‘Aircraft’)]

DisjunctionSyntax or [P, Q]

Semantics P " QExample or [lastAddProperty(c1,name,‘Vehicle’),

lastAddProperty(c1,name,‘Aircraft’)]Universal Syntax forall(P,Q)

quantification Semantics #x(P (x) $ Q(x))Example forall(lastCreate(X,class), lastAddProperty(X,name,Y))

Existential Syntax exists(P)quantification Semantics %xP (x)

Example exists(lastCreate(X,class))Value Syntax compare(P,>,v)

comparison Semantics #n & N(P (n) ! v & N ! n > v)Example compare(lastAddProperty(ae1,lower mult,X),>,0)

Property Syntax compare(P,>,Q)Comparison Semantics #n,m(P (n) ! Q(m) ! n > m)

Example compare(lastAddProperty(ae1,upper mult,X),>,lastAddProperty(ae1,lower mult,Y))

CountingSyntax count(P,>,v)

Semantics (|{x|P (x)}| > v ! v & N)Example count(lastAddReference(assID,member,X),>,2)

Transitive Syntax nav(From, Kind, To)Navigability Semantics (Kind(From,To) $ nav(From,Kind, To))"

%c(nav(From,Kind, c) ! nav(c,Kind, To) $ nav(From,Kind, To))Example nav(c1,generalization,c9)

As an example, the desired goal to resolve an inconsistency occurrence of typeI10 is specified below as a negation of this inconsistency occurrence, using thelogic operators of Table 2. It disallows the upper bound of the multiplicity onthe aggregate end of a composite aggregation to be greater than 1.

or [not(lastAddProperty(prop1,aggregation,‘composite’)),not(compare(lastAddProperty(prop1,upper,X),>,1))]

The use of prefix last in model operation lastAddProperty is needed to point tothose operations in the model that are not followed by other operations cancelingtheir e!ects [2]. Using the negation of the inconsistency occurrences in the desiredgoal will only be able to resolve inconsistency occurrences that have already beenidentified previously. For this detection, we can rely on the detection approachproposed by [2].


- pressure:float

Wheel



Car

0 .. 2 4

Set of Actions• A possible action specifies a valid way to go

from one state to another.

• The action is composed of:

• a precondition that must hold in order to execute the action;

• an effect that specifies which model operations will be added to the current state;

• a validity that verifies whether the action respects the metamodel’s constraints

x

yPut Down Stack

Rotate

Set of Actions

ExamplesetProperty action


A possible action specifies a valid way to go from one state to another. Theaction is composed of a precondition (pre) that specifies the conditions that musthold in order for the action to be applicable, and an e!ect (eff) that specifieswhich Praxis model operations will be added to the current state. The validityof an action (can) is verified by using a metamodel that imposes constraintson the model. The metamodel needed to validate the set of actions is specifiedas a set of logic facts in Prolog: fact mme represents the metamodel elements;mme property represents the properties of the specified metamodel element andthe kind of value that is used (e.g., text, boolean, int); mme reference rep-resents the relationships between two metamodel elements, and the name thatthis relationship has. The metamodel used in this paper corresponds to the oneshown in Figure 1.

The logic rules below specify the possible action setProperty. The pre rulestates that the old property must exist before it can be changed. The can rule isused to verify that the new value is correctly typed and that is di!erent from theold value. The eff rule expresses the two model operations changing the valueof a property.

pre(setProperty(Id,MME,Property,OldValue,NewValue),[lastAddProperty(Id,Property,OldValue)]).

can(setProperty(Id,MME,Property,OldValue,NewValue)) :-mme_property(MME,Property,Type),call(Type,NewValue),NewValue \== OldValue.

eff(setProperty(Id,Property,OldValue,NewValue),[remProperty(Id,Property,OldValue),

addProperty(Id,Property,NewValue)]).

4.2 The Algorithm

The algorithm used by Badger is based on the ones explained in [3]. Badgeruses a recursive best-first search (RBFS) to recursively generate a state spaceand search for a solution in that state space. RBFS is a best-first search thatexplores the state space by expanding the most promising node. To do thisthe algorithm needs 3 functions: a successor function, an evaluation functionand a solution function. The successor function generates the child nodes of aparticular node, and is used to generate the state space. It strongly depends onthe problem to be solved. The evaluation function f evaluates the child nodesto find the most promising one. It is defined as the sum of a heuristic function hand a cost function g: f(n) = h(n) + g(n) where h(n) is the minimal estimationof the cost to reach a solution from the node n, and g(n) is the actual cost ofthe path to reach n. The solution function checks if a particular node is one ofthe solutions. These 3 functions are independent of the search algorithm, whichmeans that we can also use other best-first search algorithms (e.g. A*, iterative-deepening A*, memory-bounded A*). We have chosen to use RBFS because it

Planning Algorithm• Uses a recursive best-first search algorithm (RBFS)

to recursively generate a state space and search for a solution in that space.

• RBFS is a best-first search that explores the state space by expanding the most promising node.

• The algorithm needs 3 functions:

• A successor function

• An evaluation function

• A solution function

Algorithm• The successor function generates the child nodes of a

particular node

• The evaluation function f(n) = h(n) + g(n) evaluates each node n to find the most promising one

• the heuristic function h(n) is the minimal cost estimation to reach a solution from the node n.

• the cost function g(n) is the actual cost of the path to reach node n.

• The solution function is used to detect if a particular node is one of the solutions.

Algorithm

• The heuristic function is a known planner heuristic that ignores the preconditions. Every action becomes applicable in every state, and a single literal of the desired goal can be achieved in one step.

• The cost function is the cost that the user defines of applying an action.

• The solution function in Badger is there are no more unsatisfied literals in the desired goal.

Algorithm

• The successor function is at the heart of the planning algorithm. It

• selects a logic operator from the desired goal and generates a literal that satisfies this operator;

• analyses the effect of each action to find one that achieves this literal.

• validates if the selected action can be executed.

• protects the already satisfied literals by checking if the execution of the selected action does not undo a previously satisfied literal;

• regresses goals through actions by:

• adding the precondition of the action (the pre rule) as new literals in the goal;

• removing the accomplished literals from the goal.

The Plan

• Is a sequence of actions that transforms the initial model into a model that satisfies the desired goal.

• Is generated automatically by the planning algorithm.

• Does not lead to ill-formed models (that do not conform their metamodel).

Plan

Generatedresolution plans

Resolution plan 1 :

Resolution plan 2 :


only keeps the current search path and the sibling nodes along this path, makingits space complexity linear in the depth of the search tree.

The heuristic function used by Badger is a known planner heuristic thatignores the preconditions. Every action becomes applicable in every state, anda single literal of the desired goal can be achieved in one step. Remember thatthe desired goal is a conjunction/disjunction of logic literals that represents oneor more negations of inconsistency occurrences. This implies that the heuristiccan be defined as the number of unsatisfied literals in the desired goal. Thecost function used by Badger is the user-specified cost of applying each action.These costs a!ect the order in which the plans are generated. The user can, forexample, give more importance to actions that add and modify model elementsthan to actions that delete model elements.

The solution function used by Badger checks if there are no more unsatisfiedliterals in the desired goal.

The successor function is the most complex one and is at the heart ofthe planning algorithm and proceeds as follows: (i) select a logic operator fromthe desired goal and generate a literal that satisfies this operator; (ii) analysethe e!ect (the eff rule) of each action to find one that achieves this literal;(iii) validate (the can rule) if the selected action can be executed; (iv) protectthe already satisfied literals by checking if the execution of the selected actiondoes not undo a previously satisfied literal; (v) regress goals through actions byadding the preconditions of the action (the pre rule) as new literals in the goaland by removing the satisfied literals from the goal.

4.3 Generated Plans

The generated plans produce a sequence of actions that transform the initial,inconsistent model into a model that does not have any of the inconsistency oc-currences specified in the desired goal. Moreover, the generated resolution plansdo not lead to ill-formed models (that do not conform to their metamodel) aslong as all metamodel constraints are given as part of the problem specification.

Two complete resolution plans, each containing only two actions, that solvethe inconsistency occurrences of the motivating example are given below:

1. setProperty(pro1,upper,2,1)2. setProperty(par1,direction,‘return’,‘in’)

1. setProperty(pro1,aggregation,‘composite’,‘none’)2. delNode(par1, parameter)

If we unfold the e!ects of each action from a resolution plan, we obtain a se-quence of elementary Praxis model operations, that can be applied directly totransform the inconsistent model into a consistent one. For the first plan above,this sequence of operations looks as follows:

1. remProperty(pro1,upper,2)2. addProperty(pro1,upper,1)


only keeps the current search path and the sibling nodes along this path, makingits space complexity linear in the depth of the search tree.

The heuristic function used by Badger is a known planner heuristic thatignores the preconditions. Every action becomes applicable in every state, anda single literal of the desired goal can be achieved in one step. Remember thatthe desired goal is a conjunction/disjunction of logic literals that represents oneor more negations of inconsistency occurrences. This implies that the heuristiccan be defined as the number of unsatisfied literals in the desired goal. Thecost function used by Badger is the user-specified cost of applying each action.These costs a!ect the order in which the plans are generated. The user can, forexample, give more importance to actions that add and modify model elementsthan to actions that delete model elements.

The solution function used by Badger checks if there are no more unsatisfiedliterals in the desired goal.

The successor function is the most complex one and is at the heart ofthe planning algorithm and proceeds as follows: (i) select a logic operator fromthe desired goal and generate a literal that satisfies this operator; (ii) analysethe e!ect (the eff rule) of each action to find one that achieves this literal;(iii) validate (the can rule) if the selected action can be executed; (iv) protectthe already satisfied literals by checking if the execution of the selected actiondoes not undo a previously satisfied literal; (v) regress goals through actions byadding the preconditions of the action (the pre rule) as new literals in the goaland by removing the satisfied literals from the goal.

4.3 Generated Plans

The generated plans produce a sequence of actions that transform the initial,inconsistent model into a model that does not have any of the inconsistency oc-currences specified in the desired goal. Moreover, the generated resolution plansdo not lead to ill-formed models (that do not conform to their metamodel) aslong as all metamodel constraints are given as part of the problem specification.

Two complete resolution plans, each containing only two actions, that solvethe inconsistency occurrences of the motivating example are given below:

1. setProperty(pro1,upper,2,1)2. setProperty(par1,direction,‘return’,‘in’)

1. setProperty(pro1,aggregation,‘composite’,‘none’)2. delNode(par1, parameter)

If we unfold the e!ects of each action from a resolution plan, we obtain a se-quence of elementary Praxis model operations, that can be applied directly totransform the inconsistent model into a consistent one. For the first plan above,this sequence of operations looks as follows:

1. remProperty(pro1,upper,2)2. addProperty(pro1,upper,1)



Car


- pressure:float

Wheel0..1 4



Car


- pressure:float

Wheel0..2 4

Scalability Study

• We use an existing model generator (Mougenot et al. 2009) to analyse the effect of the model size on the plan generation time.

• We created 941 models (ranging from 21 to ~10K model elements)


12. Mani, S., Sinha, V.S., Dhoolia, P., Sinha, S.: Automated support for repairinginput-model faults. In: Int’l Conf. on Automated Software Engineering, pp. 195–204. ACM (2010)

13. Mens, T., Van Der Straeten, R.: Incremental Resolution of Model Inconsistencies.In: Fiadeiro, J.L., Schobbens, P.-Y. (eds.) WADT 2006. LNCS, vol. 4409, pp. 111–126. Springer, Heidelberg (2007), doi:10.1007/978-3-540-71998-4 7

14. Mens, T., Van Der Straeten, R., D’Hondt, M.: Detecting and Resolving ModelInconsistencies Using Transformation Dependency Analysis. In: Wang, J., Whittle,J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 200–214.Springer, Heidelberg (2006)

15. Mougenot, A., Darrasse, A., Blanc, X., Soria, M.: Uniform Random Generationof Huge Metamodel Instances. In: Paige, R.F., Hartman, A., Rensink, A. (eds.)ECMDA-FA 2009. LNCS, vol. 5562, pp. 130–145. Springer, Heidelberg (2009)

16. Nentwich, C., Emmerich, W., Finkelstein, A.: Consistency management with re-pair actions. In: Proc. 25th Int’l Conf. Software Engineering, pp. 455–464. IEEEComputer Society (May 2003)

17. Object Management Group. Unified Modeling Language: Superstructure version2.3. formal/2010-05-05 (May 2010)

18. Pinna Puissant, J., Mens, T., Van Der Straeten, R.: Resolving model inconsisten-cies with automated planning. In: 3rd Workshop on Living with Inconsistencies inSoftware Development. CEUR Workshop Proceeding (September 2010)

19. Russell, S., Norvig, P.: Artificial Intelligence: A Modern Approach, 3rd edn.Prentice-Hall (2010)

20. Spanoudakis, G., Zisman, A.: Inconsistency management in software engineering:Survey and open research issues. In: Handbook of Software Engineering and Knowl-edge Engineering, pp. 329–380. World Scientific (2001)

21. Van Der Straeten, R.: Inconsistency management in model-driven engineering: anapproach using description logics. PhD thesis, Vrije Universiteit Brussel (2005)

22. Van Der Straeten, R., Mens, T., Simmonds, J., Jonckers, V.: Using DescriptionLogic to Maintain Consistency between UML Models. In: Stevens, P., Whittle, J.,Booch, G. (eds.) UML 2003. LNCS, vol. 2863, pp. 326–340. Springer, Heidelberg(2003)

23. Van Der Straeten, R., Mens, T., Van Baelen, S.: Challenges in Model-Driven Soft-ware Engineering. In: Chaudron, M.R.V. (ed.) MODELS 2008. LNCS, vol. 5421,pp. 35–47. Springer, Heidelberg (2009)

24. Van Der Straeten, R., Pinna Puissant, J., Mens, T.: Assessing the Kodkod ModelFinder for Resolving Model Inconsistencies. In: France, R.B., Kuester, J.M., Bor-dbar, B., Paige, R.F. (eds.) ECMFA 2011. LNCS, vol. 6698, pp. 69–84. Springer,Heidelberg (2011)

25. Xiong, Y., Hu, Z., Zhao, H., Song, H., Takeichi, M., Mei, H.: Supporting automaticmodel inconsistency fixing. In: Proc. ESEC/FSE 2009, pp. 315–324. ACM (2009)

First ExperimentTiming results for resolving one inconsistency

occurrence of each inconsistency type

Second ExperimentTiming results for resolving multiple inconsistencies(one of each type) together

Second Experiment

0.1

0.2

0.3

0.4

0.5

12 incons. 9 actions






Third experimentTiming results for resolving multiple inconsistencies

of the same type together.

Conclusions

• We are not aware of any other work having used automated planning for model inconsistency resolution

• Our approach

• does not require the user to specify resolution rules manually or to specify information about the causes of the inconsistency.

• resolves model inconsistencies in a metamodel-independent way.

• increases linearly in time with the size of the model; quadratically with the number of inconsistency occurrences

We also ...

• validated Badger on 5 reverse engineered models

• analysed time to generate multiple resolution plans

• validated metamodel independence by resolving code smells in Java programs

• analysed how changing the cost function allows to give priorities to certain plans

Thanks

Technology

Badger: A Regression Planner to Resolve Design Model Inconsistencies