Upcoming SlideShare
×

# Badger: A Regression Planner to Resolve Design Model Inconsistencies

386 views

Published on

Presentation of our ECMFA 2012 paper that was rewarded by the European Association for Programming Languages and Systems (EAPLS) as the best foundations paper award.

0 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

Views
Total views
386
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
4
0
Likes
0
Embeds 0
No embeds

No notes for slide

### Badger: A Regression Planner to Resolve Design Model Inconsistencies

1. 1. Published in ECMFA 2012, LNCS 7349, pp. 146-161 DOI: 10.1007/978-3-642-31491-9_13 Badger: A Regression Planner to Resolve Design Model Inconsistencies Jorge Pinna Puissant, Tom Mens and Ragnhild Van Der Straeten received best foundations paper award from EAPLS(European Association for Programming Languages and Systems)
2. 2. The Problem An UML class diagram with 2 inconsistencies Car Wheel- model:string 0 .. 2 - pressure:ﬂoat 4- manufactor: string+ turnRight():void + getDiameter():ﬂoat,integer+ turnLeft():void
3. 3. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:ﬂoat 4 - manufactor: string + turnRight():void + getDiameter():ﬂoat,integer + turnLeft():void
4. 4. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:ﬂoat 4 - manufactor: string + turnRight():void + getDiameter():ﬂoat,integer + turnLeft():void
5. 5. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:ﬂoat 4 - manufactor: string + turnRight():void + getDiameter():ﬂoat,integer + turnLeft():void
6. 6. Example of resolutions Car Car Wheel Wheel-model:string 0..1 4 -model:string 0..1 4-manufactor:string - pressure:ﬂoat -manufactor:string - pressure:ﬂoat+ turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat+ turnLeft():void + turnLeft():void Car Wheel -model:string -manufactor:string - pressure:ﬂoat + turnRight():void + getDiameter(ﬂoat):integer + turnLeft():void Car Car Wheel Wheel-model:string 0..2 4 -model:string 0..2 4-manufactor:string - pressure:ﬂoat -manufactor:string - pressure:ﬂoat+ turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat+ turnLeft():void + turnLeft():void
7. 7. Idea Car Wheel- model:string 0 .. 2 - pressure:ﬂoat 4- manufactor: string+ turnRight():void + getDiameter():ﬂoat,integer+ turnLeft():void Car Car Wheel Wheel -model:string 0..1 4 -model:string 0..1 4 -manufactor:string - pressure:ﬂoat -manufactor:string - pressure:ﬂoat The Model + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat + turnLeft():void + turnLeft():void Car Wheel -model:string -manufactor:string - pressure:ﬂoat + turnRight():void + getDiameter(ﬂoat):integer + turnLeft():void Car Car Wheel Wheel -model:string 0..2 4 -model:string 0..2 4 -manufactor:string - pressure:ﬂoat -manufactor:string - pressure:ﬂoat + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat + turnLeft():void + turnLeft():void Resolution Plans The detectedInconsistencies Multiplicity composition constraint Operation return constraint
8. 8. Idea Car Wheel- model:string 0 .. 2 - pressure:ﬂoat 4- manufactor: string+ turnRight():void + getDiameter():ﬂoat,integer+ turnLeft():void Car Car Wheel Wheel g -model:string 0..1 4 -model:string 0..1 4 -manufactor:string - pressure:ﬂoat -manufactor:string - pressure:ﬂoat The Model + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat n + turnLeft():void + turnLeft():void n i Car Wheel an -model:string -manufactor:string - pressure:ﬂoat + turnRight():void + getDiameter(ﬂoat):integer + turnLeft():void P l Car -model:string -manufactor:string 0..2 4 Wheel - pressure:ﬂoat Car -model:string -manufactor:string 0..2 4 Wheel - pressure:ﬂoat d + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():ﬂoat + turnLeft():void + turnLeft():void t e Resolution Plans a o m The detected u t AInconsistencies Multiplicity composition constraint Operation return constraint
9. 9. Automated Planning and SchedulingInitial State Desired Goal Plan Put Down y Stack x Set of Actions Rotate
10. 10. Automated Planning and Scheduling ModelState Initial with Model without Desired Goalinconsistencies inconsistencies Plan Put Down y Stack Elementary model x Set of Actions operations Rotate
11. 11. Automated Planning and Scheduling Each planning approach consists of :• A problem domain (possible actions)• A problem (initial state and desired goal)• An algorithm
12. 12. 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.
13. 13. Badger• It works only with relevant actions. Because of this, the search space will be signiﬁcantly smaller.• A regression planner’s search space depends mainly on the size of the desired goal.
14. 14. Initial State• Is expressed as a conjunction of literals, and represents the current model. Initial State Initial State
15. 15. class diagram models of varying sizes using a set of 13 structural inconsistencytypes based on OCL constraints found in the UML metamodel speciﬁcation.Our approach for resolving inconsistency occurrences appears to be linear in Initial Statethe 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 of • Is represented using Praxisthe generated resolution plans. (Blanc et al. 2008)Acknowledgments. This work has been partially supported by (i) the F.R.S. – • metamodel independenceFNRS through FRFC project 2.4515.09 “Research Center on Software Adaptabil-ity”; (ii) research project AUWB-08/12-UMH “Model-Driven Software • Models and model changes are sequences ofEvolution”, an Action de Recherche Concert´e ﬁnanced by the Minist`re de la e eCommunaut´ fran¸aise - Direction g´n´rale de l’Enseignement non obligatoire et e c e e elementary model operationsde la Recherche scientiﬁque, Belgium; (iii) the Interuniversity Attraction PolesProgramme – Belgian State – Belgian Science Policy. • create, addProperty, addReference,References delNode, remProperty, remReference 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 inconsistency through operation-based model construction. In: Proc. Int’l Conf. Software Engi- neering, vol. 1, pp. 511–520 (2008) 3. Bratko, I.: Prolog programming for artiﬁcial intelligence. Addison-Wesley (2001)
17. 17. Desired Goal Desired Goal• Is a partially speciﬁed state• Represents the objective to be reached: the absence of inconsistencies• Uses the negation of inconsistency occurrences
18. 18. poses 1 as solution to avoid an inﬁnite number of possibilities. Desired Goal Table 2. Logic Operators. Although the operators value comparison, property compar- ison and counting are only shown with the > function, the other comparison functionslogic operators to specify the desired goal: can be used as well : <, ≥, ≤, =, = Name Negative Syntax not(P) literal Semantics ¬P Example not(lastAddProperty(ae2,iscomposite,‘true’)) Syntax [P, Q] Conjunction Semantics P ∧Q Example [lastAddProperty(c1,name,‘Vehicle’), lastAddProperty(c2,name,‘Aircraft’)] Syntax or [P, Q] Disjunction Semantics P ∨Q Example or [lastAddProperty(c1,name,‘Vehicle’), lastAddProperty(c1,name,‘Aircraft’)] Universal Syntax forall(P,Q) quantiﬁcation Semantics ∀x(P (x) ⇒ Q(x)) Example forall(lastCreate(X,class), lastAddProperty(X,name,Y)) Existential Syntax exists(P) quantiﬁcation 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)) Syntax count(P,>,v ) Counting Semantics (|{x|P (x)}| > v ∧ v ∈ N) Example count(lastAddReference(assID,member,X),>,2) Transitive Syntax nav(From, Kind, To) Navigability Semantics (Kind(F rom, T o) ⇒ nav(F rom, Kind, T o))∨ ∃c(nav(F rom, Kind, c) ∧ nav(c, Kind, T o) ⇒ nav(F rom, Kind, T o)) Example nav(c1,generalization,c9)
19. 19. Example count(lastAddReference(assID,member,X),>,2) Transitive Syntax nav(From, Kind, To) Navigability Semantics (Kind(F rom, T o) ⇒ nav(F rom, Kind, T o))∨ Desired Goal ∃c(nav(F rom, Kind, c) ∧ nav(c, Kind, T o) ⇒ nav( Example nav(c1,generalization,c9) Car Wheel As an example, the desired goal to resolve an inconsistency o - model:string - manufactor: string 0 .. 2 4 - pressure:ﬂoatI10 is speciﬁed below as a negation of this inconsistency occu + turnRight():void + turnLeft():void + getDiameter():ﬂoat,integerlogic operators of Table 2. It disallows the upper bound of th Negation of the Inconsistency Occurrence :the aggregate end of a composite aggregation to be greater thor [not(lastAddProperty(prop1,aggregation,‘composite’)), not(compare(lastAddProperty(prop1,upper,X),>,1))]The use of preﬁx last in model operation lastAddProperty isthose operations in the model that are not followed by other optheir eﬀects [2]. Using the negation of the inconsistency occurrengoal will only be able to resolve inconsistency occurrences that
20. 20. Put Down y StackSet of Actions x Set of Actions Rotate• A possible action speciﬁes 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 speciﬁes which model operations will be added to the current state; • a validity that veriﬁes whether the action respects the metamodel’s constraints
21. 21. The logic rules below specify the possible action setPrope Examplestates that the old property must exist before it can be changused to verify that the new value is correctly typed and that is setProperty actionold value. The eff rule expresses the two model operationsof 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)]).
22. 22. Planning Algorithm• Uses a recursive best-ﬁrst search algorithm (RBFS) to recursively generate a state space and search for a solution in that space.• RBFS is a best-ﬁrst 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
23. 23. 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 ﬁnd 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.
24. 24. 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 deﬁnes of applying an action.• The solution function in Badger is there are no more unsatisﬁed literals in the desired goal.
25. 25. 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 satisﬁes this operator; • analyses the effect of each action to ﬁnd one that achieves this literal. • validates if the selected action can be executed. • protects the already satisﬁed literals by checking if the execution of the selected action does not undo a previously satisﬁed 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.
26. 26. The PlanPlan • Is a sequence of actions that transforms the initial model into a model that satisﬁes the desired goal. • Is generated automatically by the planning algorithm. • Does not lead to ill-formed models (that do not conform their metamodel).
27. 27. The generated plans produce a sequence of actions that tr4.3 Generated Plans model that does not have any of th Generatedinconsistent model into acurrences speciﬁed in the desired goal. Moreover, the generaThe generated plans produce a sequence of actions that tra resolution plansdo not lead to ill-formed models (that do not conform to tinconsistent model into a model that does not have any of thcurrences speciﬁed in the desired goal. given as part of the prlong as all metamodel constraints are Moreover, the generatdo Two lead to ill-formed models (that do not conform totwo not complete resolution plans, each containing only thlonginconsistency1occurrences of the motivating example prothe as all metamodel constraints are given as part of the are Resolution plan : Car -model:string 0..1 4 Wheel -manufactor:string - pressure:ﬂoat Two complete resolution plans, each containing only two + turnRight():void + getDiameter(ﬂoat):integer1. setProperty(pro1,upper,2,1) + turnLeft():voidthe inconsistency occurrences of the motivating example are2. setProperty(par1,direction,‘return’,‘in’)1. setProperty(pro1,upper,2,1) Car1. setProperty(par1,direction,‘return’,‘in’)2. setProperty(pro1,aggregation,‘composite’,‘none’) -model:string Wheel2. delNode(par1,2 parameter) Resolution plan : 0..2 4 -manufactor:string - pressure:ﬂoat + turnRight():void + getDiameter():integer + turnLeft():void1. setProperty(pro1,aggregation,‘composite’,‘none’)2. we unfold the eﬀects of each action from a resolution plIf delNode(par1, parameter)quence of elementary Praxis model operations, that can beIf we unfold the eﬀects of each action a consistent one. For ttransform the inconsistent model into from a resolution pla
28. 28. Scalability Study • We use an existing model generator (Mougenot et al. 2009) to analyse the effect of the Badger: A Regression Planner to Resolve Design Model Inconsistencies 16112. Mani, S., Sinha,size Dhoolia, P., Sinha, S.: generation time. model V.S., Int’l Conf. on Automated Software Engineering, repairing on the plan Automated support for pp. 195– input-model faults. In: • We created 941 models (ranging from 21 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–14. to ~10K model elements) 126. Springer, Heidelberg (2007), doi:10.1007/978-3-540-71998-4 7 Mens, T., Van Der Straeten, R., D’Hondt, M.: Detecting and Resolving Model Inconsistencies 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 Generation of 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-
29. 29. First ExperimentTiming results for resolving one inconsistency occurrence of each inconsistency type
30. 30. Second ExperimentTiming results for resolving multiple inconsistencies(one of each type) together
31. 31. Second Experiment0.50.40.30.20.1 12 incons. 12 incons. 12 incons. 13 incons. 13 incons. 13 incons. 9 actions 10 actions 11 actions 10 actions 11 actions 12 actions
32. 32. Third experimentTiming results for resolving multiple inconsistencies of the same type together.
33. 33. 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
34. 34. 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
35. 35. Thanks