Your SlideShare is downloading. ×
Badger: A Regression Planner to Resolve Design Model Inconsistencies
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Badger: A Regression Planner to Resolve Design Model Inconsistencies

222
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.

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.

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
222
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. The Problem An UML class diagram with 2 inconsistencies Car Wheel- model:string 0 .. 2 - pressure:float 4- manufactor: string+ turnRight():void + getDiameter():float,integer+ turnLeft():void
  • 3. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:float 4 - manufactor: string + turnRight():void + getDiameter():float,integer + turnLeft():void
  • 4. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:float 4 - manufactor: string + turnRight():void + getDiameter():float,integer + turnLeft():void
  • 5. The Problem Two structural inconsistency occurrences :• Multiplicity composition constraint.• Operation return constraint. Car Wheel - model:string 0 .. 2 - pressure:float 4 - manufactor: string + turnRight():void + getDiameter():float,integer + turnLeft():void
  • 6. Example of resolutions Car Car Wheel Wheel-model:string 0..1 4 -model:string 0..1 4-manufactor:string - pressure:float -manufactor:string - pressure:float+ turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float+ turnLeft():void + turnLeft():void Car Wheel -model:string -manufactor:string - pressure:float + turnRight():void + getDiameter(float):integer + turnLeft():void Car Car Wheel Wheel-model:string 0..2 4 -model:string 0..2 4-manufactor:string - pressure:float -manufactor:string - pressure:float+ turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float+ turnLeft():void + turnLeft():void
  • 7. Idea Car Wheel- model:string 0 .. 2 - pressure:float 4- manufactor: string+ turnRight():void + getDiameter():float,integer+ turnLeft():void Car Car Wheel Wheel -model:string 0..1 4 -model:string 0..1 4 -manufactor:string - pressure:float -manufactor:string - pressure:float The Model + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float + turnLeft():void + turnLeft():void Car Wheel -model:string -manufactor:string - pressure:float + turnRight():void + getDiameter(float):integer + turnLeft():void Car Car Wheel Wheel -model:string 0..2 4 -model:string 0..2 4 -manufactor:string - pressure:float -manufactor:string - pressure:float + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float + turnLeft():void + turnLeft():void Resolution Plans The detectedInconsistencies Multiplicity composition constraint Operation return constraint
  • 8. Idea Car Wheel- model:string 0 .. 2 - pressure:float 4- manufactor: string+ turnRight():void + getDiameter():float,integer+ turnLeft():void Car Car Wheel Wheel g -model:string 0..1 4 -model:string 0..1 4 -manufactor:string - pressure:float -manufactor:string - pressure:float The Model + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float n + turnLeft():void + turnLeft():void n i Car Wheel an -model:string -manufactor:string - pressure:float + turnRight():void + getDiameter(float):integer + turnLeft():void P l Car -model:string -manufactor:string 0..2 4 Wheel - pressure:float Car -model:string -manufactor:string 0..2 4 Wheel - pressure:float d + turnRight():void + getDiameter():integer + turnRight():void + getDiameter():float + turnLeft():void + turnLeft():void t e Resolution Plans a o m The detected u t AInconsistencies Multiplicity composition constraint Operation return constraint
  • 9. Automated Planning and SchedulingInitial State Desired Goal Plan Put Down y Stack x Set of Actions Rotate
  • 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. Automated Planning and Scheduling Each planning approach consists of :• A problem domain (possible actions)• A problem (initial state and desired goal)• An algorithm
  • 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. 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.
  • 14. Initial State• Is expressed as a conjunction of literals, and represents the current model. Initial State Initial State
  • 15. class 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 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 financed 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 scientifique, 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 artificial intelligence. Addison-Wesley (2001)
  • 16. comes with a suite of Eclipse plugins: a plugin to reason about Emodels; a plugin to generate class diagram models of varying s Initial Statemodel inconsistency detection engine [2]. As an example, the cclass diagram model of Figure 2 is represented as follows3 :create(c1, class). Car - model:string Wheel - pressure:float 0 .. 2 4addProperty(c1, name, ‘Car’). - manufactor: string + turnRight():void + getDiameter():float,integercreate(att1, property). + turnLeft():voidaddProperty(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).
  • 17. Desired Goal Desired Goal• Is a partially specified state• Represents the objective to be reached: the absence of inconsistencies• Uses the negation of inconsistency occurrences
  • 18. poses 1 as solution to avoid an infinite 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) 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)) 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. 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:floatI10 is specified below as a negation of this inconsistency occu + turnRight():void + turnLeft():void + getDiameter():float,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 prefix last in model operation lastAddProperty isthose operations in the model that are not followed by other optheir effects [2]. Using the negation of the inconsistency occurrengoal will only be able to resolve inconsistency occurrences that
  • 20. Put Down y StackSet of Actions x Set of Actions Rotate• 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
  • 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. 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
  • 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 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.
  • 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 defines of applying an action.• The solution function in Badger is there are no more unsatisfied literals in the desired goal.
  • 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 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.
  • 26. The PlanPlan • 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).
  • 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 specified 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 specified 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:float Two complete resolution plans, each containing only two + turnRight():void + getDiameter(float):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:float + turnRight():void + getDiameter():integer + turnLeft():void1. setProperty(pro1,aggregation,‘composite’,‘none’)2. we unfold the effects of each action from a resolution plIf delNode(par1, parameter)quence of elementary Praxis model operations, that can beIf we unfold the effects of each action a consistent one. For ttransform the inconsistent model into from a resolution pla
  • 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. First ExperimentTiming results for resolving one inconsistency occurrence of each inconsistency type
  • 30. Second ExperimentTiming results for resolving multiple inconsistencies(one of each type) together
  • 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. Third experimentTiming results for resolving multiple inconsistencies of the same type together.
  • 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. 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. Thanks

×