Badger: A Regression Planner to Resolve Design Model Inconsistencies

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)

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

The Problem
Two structural inconsistency occurrences :
• Multiplicity composition constraint.
• Operation return constraint.

Car Wheel
4
+ turnLeft():void

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


Idea
Car Wheel
4

+ turnLeft():void
Car Car
Wheel Wheel

The Model

Car
Wheel
-model:string
+ turnLeft():void

Car Car
Wheel Wheel

Resolution Plans

The detected
Inconsistencies
Multiplicity composition constraint
Operation return constraint

Idea
Car Wheel
4

+ turnLeft():void
Car Car
Wheel Wheel

g

The Model

n

n i Car
Wheel

an
-model:string
+ 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

t e Resolution Plans
a
o m
The detected u t
A
Inconsistencies
Multiplicity composition constraint
Operation return constraint

Automated Planning and Scheduling

Initial State Desired Goal

Plan

Put Down y Stack
x

Set of Actions
Rotate


ModelState
Initial with Model without
Desired Goal
inconsistencies inconsistencies
Plan

Put Down y Stack
Elementary model
x

Set of Actions
operations
Rotate


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
signiﬁcantly 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

class diagram models of varying sizes using a set of 13 structural inconsistency
types based on OCL constraints found in the UML metamodel specification.
Our approach for resolving inconsistency occurrences appears to be linear in

Initial State
the size of the model, and scales up to models containing more than 10000
model elements. The execution time also increases as the number of actions
in the resolution plan increases. With respect to the number of inconsistency
occurrences, the approach is quadratic in time. However, controlled user studies
are still needed to adapt the cost function and evaluate the preferred order of

• Is represented using Praxis
the generated resolution plans.
(Blanc et al. 2008)
Acknowledgments. This work has been partially supported by (i) the F.R.S. –
• metamodel independence
FNRS 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 of
Evolution”, an Action de Recherche Concerté financed by the Minist`re de la
e e
Communaut´ fran¸aise - Direction gń´rale de l’Enseignement non obligatoire et
e c e e
elementary model operations
de la Recherche scientifique, Belgium; (iii) the Interuniversity Attraction Poles
Programme – 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)

comes with a suite of Eclipse plugins: a plugin to reason about E
models; a plugin to generate class diagram models of varying s

Initial State
model inconsistency detection engine [2]. As an example, the c
class diagram model of Figure 2 is represented as follows3 :

create(c1, class). Car

- model:string
Wheel

- pressure:ﬂoat
0 .. 2 4
addProperty(c1, name, ‘Car’). - manufactor: string

create(att1, property). + turnLeft():void

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

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

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 functions
logic 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)

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
0 .. 2 4
- pressure:float

I10 is specified below as a negation of this inconsistency occu
+ turnRight():void
+ turnLeft():void
+ getDiameter():float,integer

logic 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 th

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

The use of prefix last in model operation lastAddProperty is
those operations in the model that are not followed by other op
their effects [2]. Using the negation of the inconsistency occurren
goal will only be able to resolve inconsistency occurrences that

Put Down y Stack

Set 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

The logic rules below specify the possible action setPrope

Example
states that the old property must exist before it can be chang
used to verify that the new value is correctly typed and that is

setProperty action
old value. The eff rule expresses the two model operations
of 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)]).

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

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.

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.

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
Plan

• 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).

The generated plans produce a sequence of actions that tr
4.3 Generated Plans model that does not have any of th
Generated
inconsistent model into a
currences specified in the desired goal. Moreover, the genera
The generated plans produce a sequence of actions that tra
resolution plans
do not lead to ill-formed models (that do not conform to t
inconsistent model into a model that does not have any of th
currences specified in the desired goal. given as part of the pr
long as all metamodel constraints are Moreover, the generat
do Two lead to ill-formed models (that do not conform totwo
not complete resolution plans, each containing only th
longinconsistency1occurrences of the motivating example pro
the as all metamodel constraints are given as part of the are
Resolution plan :
Car

-model:string 0..1 4
Wheel

Two complete resolution plans, each containing only two
1. setProperty(pro1,upper,2,1) + turnLeft():void

the inconsistency occurrences of the motivating example are
2. setProperty(par1,direction,‘return’,‘in’)
1. setProperty(pro1,upper,2,1) Car
1. setProperty(par1,direction,‘return’,‘in’)
2. setProperty(pro1,aggregation,‘composite’,‘none’)
-model:string
Wheel

2. delNode(par1,2 parameter)
Resolution plan :
0..2 4

+ turnRight():void + getDiameter():integer
+ turnLeft():void

1. setProperty(pro1,aggregation,‘composite’,‘none’)
2. we unfold the effects of each action from a resolution pl
If delNode(par1, parameter)
quence of elementary Praxis model operations, that can be
If we unfold the effects of each action a consistent one. For t
transform the inconsistent model into from a resolution pla

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 161

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

First Experiment
Timing results for resolving one inconsistency
occurrence of each inconsistency type

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

Second Experiment
0.5

0.4

0.3

0.2

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

Third experiment
Timing 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

Badger: A Regression Planner to Resolve Design Model Inconsistencies

Recomendados

Recomendados

Más contenido relacionado

Más de Tom Mens

Más de Tom Mens (20)

Último

Último (20)

Badger: A Regression Planner to Resolve Design Model Inconsistencies