automated planning for resolving model inconsistencies - a scalability study

Automated Planning for Resolving Model Inconsistencies

A Scalability StudyJorge Pinna Puissant

Ragnhild Van Der StraetenTom Mens

October 2010

What kind of model(s) do you consider in your work?

• Meta-Model Independent

• Currently focus in UML

What kind(s) of evolution challenges are addressed

• Inconsistency Management

Model Inconsistency

• In a model-driven development approach, inconsistencies inevitably arise.

• Techniques to detect and resolve model inconsistencies are required.

Inconsistency Management Process

Inconsistency Detection Rules

?

Inconsistency Resolution Strategies

?

ModelDetect Model

Inconsistencies

Select Inconsistency to be Resolved

Choose Resolution Strategy

Apply Resolution Strategies

modify model by selected resolution strategies

(may give rise to new problems)

annotate model with detected

inconsistencies

DETECTION

- Mens et. al.- Blanc et. al.- Easterbrook et. al.- Van Der Straeten et. al.- Egyed et. al.- Engels et. al.

RESOLUTION

- Mens et. al.- Nentwich et. al.- Xiong et. al.- Almeida da Silva et. al.- Egyed et. al.

Artificial intelligence

Deduction, reasoning, problem solving

Knowledge representation and Commonsense knowledge

Automated planning and scheduling

Machine learning

Natural language processing

Robotics

Machine perception, Computer vision, and Speech recognition

Affective computing

Computational creativity

Automated Planning and Scheduling

Desired GoalInitial State

x

yPut Down Stack

Rotate

Set of Actions

Plan



x

yPut Down Stack

Rotate

Set of Actions

Plan

Model with Inconsistencies

Model without Inconsistencies

Model elementary Operations

Classical Planning

• Progression Planning

• Regression Planning

Progression Planning

• Forward state-space search

• Starts with the Initial State

InitialState


InitialState

h


InitialState

h

DesiredGoal

Regression Planning

• Backwards state-space search

• Starts with the Desired Goal

DesiredGoal

Regression Planning

DesiredGoal

InitialState

Example

Class diagram with 4 inconsistency occurrences

Vehicle

Bicycle CarMotorcycle BoatAircraft

Amphibious Vehicle 1..*

Helicopter Airplane

Class diagram with 4 inconsistency occurrences

Vehicle



Helicopter Airplane

• Inherited cyclic composition : 2 occurrences

• Cyclic inheritance: 2 occurrences

Generated resolution plan

1. Delete generalisation Vehicle ➔ Amphibious Vehicle

2. Modify multiplicity of Amphibious Vehicle from 1..* to 0..*

FF : The Fast-Forward Planning System

• Progression Planner

• PDDL language

• Outstanding Performance at the 2nd International Planning Competition

• Top Performer at the 3rd International Planning Competition

• Disjunction and Negation in Goal

FB : Fast Backward Planning

• Regression Planner

• Prolog

• Prototype (custom built)

• Based on regression planner in the “Prolog programming for artificial intelligence” book (Ivan Bratko)

• Recursive best-first search algorithm

• Disjunction and Negation in Goal

The Metamodel

Chapter 3. Conceptual Classification of Inconsistencies 60

ATM

PrintingATMWithDrawATM

WithdrawPrintingATM

ChargeWithdrawPrintingATM TransferWithdrawPrintingATM

1..*

Figure 3.4: Example of an Inherited Cyclic Composition Inconsistency.

3.3.2 Dangling Type Reference

Dangling type reference occurs when a parameter’s or attribute’s type refers to a class thatdoes not exist in the model.

The reasons for this inconsistency to occur are twofold. The type of the attribute or theparameter involved, may have been removed or the type is not yet included in the model.To remove this type of inconsistency from the UML model, the type can be added to theUML model involved.

Involved UML Model Elements:Property, Operation, Parameter, Model and Type.

Definition 40 M suffers from a dangling type reference if and only if one of the

following conditions hold:

1. ∃ att ∈ AttCM : type(att) /∈ (CM ∪PT).

2. ∃ op = (n, c, (p1, . . . , pk), (r1, . . . , rm)) ∈ OpCM : (∃i ∈ {1, . . . k} : pi /∈ (CM ∪ PT)∨ ∃j ∈ {1, . . .m} : rj /∈ (CM ∪PT)).

Example 23 Consider the UML model only consisting of the class diagram in Figure 2.6.

Several occurrences of this type of inconsistency can be found in the model. Due to the fact

that the class Cash is not included in the model, the type of the attribute cash is not known,

also the type of the parameter amount of the dispenseCash operation of the class ATM is

not known to this model.

3.3.3 Connector Specification Missing

Connector specification missing represents a category of inconsistencies. Three kinds ofinconsistencies can be differentiated.

• classless connectable element : there is a connectable element in a sequence diagramwhose base class does not exist in the model.

Fig. 1. C lass D iagram wi t h an inheri t ed cyclic composi t ion inconsist ency, t a kenfrom [20]

between bot h classes. We can solve bot h inconsistencies in an independent wayfor example by breaking t he independent inheri t ance hierarchies.

4 An Approach for Inconsistency Resolution usingAutomated Planning

T he aim of our research is to use au tomated planning to genera te t he plansneeded to resolve such inconsistencies. T his diÞers from t he t radi t ional approachto inconsistency resolu t ion, in which t he developer needs to select a resolu t ionrule from a predeþned hand-wri t ten collect ion of possible rules.

In t he remainder, we explain by means of t he mot ivat ing example how au to-mated planning could be used to create a set of act ions t hat resolve t he incon-sistency. A u tomated planning requires as inpu t an ini t ial st ate, a set of possibleact ions and a desired goal. B ecause planning requires logic condi t ions as in-pu t , t he whole model environment (e.g. model, met a-model, detect ion rules) ist ranslated into a conjunct ion of logic li terals. For inst ance t he met amodel forour simple example, is given below. ( Note t hat each element is represented byan unique id t hrough which i t can be referred. Cardinal is a st rict ly posi t iveinteger including inþni ty.)

(Class ?id - id ?name - String)(Generalisation ?id - id ?label - String ?child_class - class_id

?parent_class - class_id)(Association_End ?id - id ?class - class_id ?role - String

?upper_mult - Cardinal ?lower_mult - Cardinal?composite - Boolean)

(Association ?id - id ?name - String ?ass_end_1 - ae_id?ass_end_2 - ae_id)

T he initial state is a st ate represented as a conjunct ion of li terals, andrepresent t he current world. In our case t he ini t ial st a te will be t he inconsistentmodel. We can use ei t her The Complete Model or The elements of the model thatcompose the inconsistency as ini t ial st ate. T he main advant age of only use t he el-ements of t he inconsistency is t ha t i t makes t he ini t ial st ate signiþcant ly smaller.T his is a big advant age in terms of performance. For inst ance t he elements ofinconsistency_1 is given below.

(Class c1 "ATM")(Class c2 "WithDrawATM")(Class c4 "WithdrawPrintingATM")(Generalisation g1 "Label1" c2 c1)(Generalisation g3 "Label3" c4 c2)(Association_End ae1 c1 "role1" one one yes)(Association_End ae2 c4 "role2" infinity one non)(Association a1 "assocname" ae1 ae2)

T he only problem wi t h t his approach is t hat we can only solve one incon-sistency a t a t ime. A s shown in [4], t here may exist dependencies between in-consistency resolu t ion plans. For example, one act ion can solve more t han oneinconsistency; or if we choose one plan to solve one inconsistency t ha t plan couldprevent t he resolu t ion of anot her inconsistency. For t hese reasons we choose touse t he complete model as ini t ial st ate.

T he set of actions are act ions t ha t could be performed to a st ate to changei t . T he act ions are represented in terms of he precondi t ion t ha t must hold beforet he execut ion and t he eÞect of t he act ion into t he st ate. T his boils down toapplying a k number of act ions t hat we can achieve a goal. In our approacht he set of act ions is composed of t he element ary operat ions (basically, creat ion,modiþcat ion and delet ion) t ha t can be derived from t he met a-model. T heseelement ary opera t ions, combined wi t h t he logic li terals of t he met a-model, allowus to compu te t he list of all possible act ions: create_Class, delete_Class,modify_Name_of_Class, and so on. T his is inspired in .... [R ef B lanc]. A s anexample, t he speciþcat ion of modify_Name_of_Class is given below.

(:action modify_Name_of_Class:parameters (?id - id ?name - String ?new_name - String):precondition (Class ?id ?name):effect (when (not (= ?name ?new_name))

(and (not (Class ?id ?name))(Class ?id ?new_name)))

)

T he desired goal is a par t ially speciþed st ate, represented as a conjunct ionof li terals, and represent t he ob ject ive t hat we want to reach. In t he contex t of in-consistency resolu t ion, we use t he negat ion of t he inconsistency detect ion rule asgoal. We can use the negation of the definition of the inconsistency detection rule,t he type of t he inconsistency or the negation of the instance of the inconsistencydetection rule, t he inconsistency i tself. T he detect ion rule is usually composedby a conjunct ion of li terals, t he negat ion of t hese rules must be a disjunct ion

FF :

class(Id,Name)generalisation(Id,Child_class,Parent_class)! generalisation_label(Id,Label)association_end(Id,Class_id,Role)! association_end_upper(Id,Upper_Mult)! association_end_lower(Id,Lower_Mult)! association_end_composite(Id,Composite)association(Id,Assend1,Assend2)! association_name(Id,Name)

FB :

The Model

(Class c1 Vehicle )(Class c2 Aircraft )(Class c3 Bicycle )(Class c4 Motorcycle )(Class c5 Boat )(Class c6 Car )(Class c7 Helicopter )(Class c8 Airplane )(Class c9 Amphibious_Vehicle )...(Generalisation g5 label5 c6 c1 )...(Generalisation g9 label9 c9 c6 )...(Association_End ae1 c9 role1 star one_l non )(Association_End ae2 c1 role2 one_u one_l yes )(Association a1 ass1 ae1 ae2 )

FF :

The Model

FB : class(c1,vehicle),class(c2,aircraft),class(c3,bicycle),class(c4,motorcycle),class(c5,boat),class(c6,car),class(c7,helicopter),class(c8,airplane),class(c9,amphibious_vehicle),...generalisation(g5,c6,c1),

generalisation_label(g5, label5),...generalisation(g9,c9,c6),

generalisation_label(g9, label9),...association_end(ae1,c9,role1),

association_end_upper(ae1, star),association_end_lower(ae1, one_l),association_end_composite(ae1, non),

association_end(ae2,c1,role2),association_end_upper(ae2, one_u),association_end_lower(ae2, one_l),association_end_composite(ae2, yes),

association(a1,ae1,ae2), association_name(a1, ass1)



x

yPut Down Stack

Rotate

Set of Actions

Plan




Initial State:Model with Inconsistencies1. The complete model.

2. Partial model that contains all those elements that are involved in one or more inconsistency occurrences.

Initial State:Model with Inconsistencies

Vehicle



Helicopter Airplane



x

yPut Down Stack

Rotate

Set of Actions

Plan




Set of Actions:Model elementary Operations

Metamodel elements Possible Actions

Classcreate Classdelete Class

Generalisationcreate Generalisation

modify Generalisation Labeldelete Generalisation

Association End

create Association Endmodify Association End Upper Multiplicitymodify Association End Lower Multiplicitymodify Association End Composition Type

delete Association End

Associationcreate Association

modify Association Namedelete Association

Table 1: Set of actions derived from the metamodel.

The desired goal is a partially specified state, represented as a conjunction

of literals using logic quantification. It specifies the objective that we want to

reach, namely a consistent model. To represent this consistent model we use

either (1) the negation of the inconsistency detection rules; (2) or the negation

of the inconsistency occurrences. An inconsistency detection rule is a conjunc-

tion of literals representing a pattern that, if matched in the model, detects

inconsistency occurrences.

The inherited cyclic composition inconsistency detection rule using the PDDL

syntax is given bellow. Observe that it only specifies an inheritance chain involv-

ing three classes. PDDL syntax does not allow to express transitive closure to

make the rule more generic.

(exists (?a - class_id ?b - class_id ?c - class_id)(and

(exists (?g - g_id ?Label - g_label)(Generalisation ?g ?Label ?c ?a))

(exists (?g - g_id ?Label - g_label)(Generalisation ?g ?Label ?b ?c))

(exists (?ae - ae_id ?role - ae_role?upper - upper_cardinal ?lower - lower_cardinal)

(Association_End ?ae ?a ?role ?upper ?lower yes))(exists (?ae - ae_id ?role - ae_role ?upper - upper_cardinal ?composite - boolean)

(Association_End ?ae ?b ?role ?upper one_l ?composite))))

The advantage of using alternative (1) above is that it can be used to detect

and resolve inconsistency occurrences at the same time. Alternative (2) will only

be able to resolve inconsistency occurrences that have already been identified

previously. On the other hand, as we will see later, alternative (1) suffers from

severe scalability problems.

In both alternatives (1) and (2) we use logic negation to express the fact that

we do not want inconsistencies in the model. Because negation of the conjunction

of literals is used we need a planning approach that allows the use of disjunction

and negative literals in the goal. This is one of the main reasons why we have

selected FF as a planning tool for our experiments.



x

yPut Down Stack

Rotate

Set of Actions

Plan




Desired Goal:Model without Inconsistencies1. The negation of the inconsistency detection

rules.

2. The negation of the inconsistency occurrences.


Inconsistency Detection Rules

?

Inconsistency Resolution Strategies

?

ModelDetect Model

Inconsistencies

Select Inconsistency to be Resolved

Choose Resolution Strategy

Apply Resolution Strategies

modify model by selected resolution strategies

(may give rise to new problems)

annotate model with detected

inconsistencies

The negation of the inconsistency detection rules.

Desired Goal:Model without Inconsistencies1. The negation of the inconsistency detection

rules.

(:goal (not (and (exists ( ?c1 - c_id ?c2 - c_id ?c3 - c_id) (and

(exists (?g - g_id ?Label - g_label) (Generalisation ?g ?Label ?c2 ?c1)) (exists (?g - g_id ?Label - g_label) (Generalisation ?g ?Label ?c3 ?c2)) (exists (?ae - ae_id ?role - ae_role ?upper - upper_cardinal ?lower - lower_cardinal) (Association_End ?ae ?c1 ?role ?upper ?lower yes)) (exists (?ae - ae_id ?role - ae_role ?upper - upper_cardinal ?composite - boolean) (Association_End ?ae ?c3 ?role ?upper one_l ?composite)) )))))

?c1

?c2

?c31..*

Desired Goal:Model without Inconsistencies2. The negation of the inconsistency occurrences.

(:goal (not (and (exists (?g - g_id ?Label - g_label) (Generalisation ?g ?Label c6 c1)) (exists (?g - g_id ?Label - g_label) (Generalisation ?g ?Label c9 c6)) (exists (?ae - ae_id ?role - ae_role ?upper - upper_cardinal ?lower - lower_cardinal) (Association_End ?ae c1 ?role ?upper ?lower yes)) (exists (?ae - ae_id ?role - ae_role ?upper - upper_cardinal ?composite - boolean) (Association_End ?ae c9 ?role ?upper one_l ?composite)) )))

Vehicle

Car


(Class c1 Vehicle )(Class c6 Car )

(Class c9 Amphibious_Vehicle )

Feasibility StudyInitial state Desired Goal:

Negation ofFF Time

(in seconds)FB Time

(in seconds)

complete model inconsistency rules out of memory N/A

partial model inconsistency rules out of memory N/A

complete model inconsistency ocurrences

14.84 0.181

partial model inconsistency ocurrences

0.268 0.051

Scalability Study1. Adding isolated classes.

2. Increasing the inheritance chain.

3. Size of the goal.

!"

#!!!"

$!!!"

%!!!"

&!!!"

'!!!!"

'#!!!"

'$!!!"

'%!!!"

'&!!!"

#!!!!"

!" (" '!" '(" #!"

!"#$%&'(%

)*#+$,%-.%"'-/01$2%3/0''$'%022$2%1-%14$%#-2$/%

)*"

))"

Scalability Study1. Adding isolated classes to complete model.

5 hours

15 seconds

Exponential functionR² = 0.982

!"

#!!!"

$!!!"

%!!!"

&!!!"

'!!!!"

'#!!!"

'$!!!"

'%!!!"

'&!!!"

#!!!!"

!" (" '!" '(" #!"

!"#$%&'(%

)*#+$,%-.%"'-/01$2%3/0''$'%022$2%1-%14$%#-2$/%

)*"

))"


0.19 seconds

Polynomial functiony = 0.001x² + 0.20x + 0.191

R² = 0.999

1.21 seconds


!"#$

#$

#!$

#!!$

#!!!$

#!!!!$

#!!!!!$

!$ %$ #!$ #%$ &!$

!"#$%&'(%

)*#+$,%-.%"'-/01$2%3/0''$'%022$2%1-%14$%#-2$/%

'($

''$

!"

#!"

$!!"

$#!"

%!!"

%#!"

&!!"

&#!"

'!!"

'#!"

#!!"

!" $" %" &" '" #" (" )" *"

!"#$%&'(%

)*#+$,%-.%,$/01$2%3/0''$'%022$2%1-%14$%#-2$/%

+,"

++"

Scalability Study2. Increasing the inheritance chain to the

partial model.10

minutes

0.3 seconds

Exponential functionR² = 0.995

!"

#!"

$!!"

$#!"

%!!"

%#!"

&!!"

&#!"

'!!"

'#!"

#!!"

!" $" %" &" '" #" (" )" *"

!"#$%&'(%

)*#+$,%-.%,$/01$2%3/0''$'%022$2%1-%14$%#-2$/%

+,"

++"


partial model.

0.06 seconds

0.56 seconds

Polynomial functiony = 0.007x² + 0.057

R² = 0.999

!"!#$

!"#$

#$

#!$

#!!$

!$ #$ %$ &$ '$ ($ )$ *$ +$

!"#$%&'(%

)*#+$,%-.%,$/01$2%3/0''$'%022$2%1-%14$%#-2$/%

,-$

,,$


partial model.

Scalability Study3. Size of the Goal

!"

#!"

$!!"

$#!"

%!!"

%#!"

&!!"

&#!"

'!!"

'#!"

#!!"

!" %" '" (" )"

!"#$%&'(%

)*#+$,%-.%,$/01$2%3/0''$'%022$2%1-%14$%#-2$/%

*+"'",-./-0,012-.,20"

*+"&",-./-0,012-.,20"

*+"%",-./-0,012-.,20"

*+"$",-./-0,012-.,20"

**"'",-./-0,012-.,20"

**"&",-./-0,012-.,20"

**"%",-./-0,012-.,20"

**"$",-./-0,012-.,20"

!"!#$

!"#$

#$

#!$

#!!$

!$ %$ &$ '$ ($

)*$&$+,-.,/+/01,-+1/$

)*$2$+,-.,/+/01,-+1/$

)*$%$+,-.,/+/01,-+1/$

)*$#$+,-.,/+/01,-+1/$

))$&$+,-.,/+/01,-+1/$

))$2$+,-.,/+/01,-+1/$

))$%$+,-.,/+/01,-+1/$

))$#$+,-.,/+/01,-+1/$


!"!#$

!"#$

#$

#!$

#!!$

!$ %$ &$ '$ ($

)*$&$+,-.,/+/01,-+1/$

)*$2$+,-.,/+/01,-+1/$

)*$%$+,-.,/+/01,-+1/$

)*$#$+,-.,/+/01,-+1/$

))$&$+,-.,/+/01,-+1/$

))$2$+,-.,/+/01,-+1/$

))$%$+,-.,/+/01,-+1/$

))$#$+,-.,/+/01,-+1/$


FF

!"!#$

!"#$

#$

#!$

#!!$

!$ %$ &$ '$ ($

)*$&$+,-.,/+/01,-+1/$

)*$2$+,-.,/+/01,-+1/$

)*$%$+,-.,/+/01,-+1/$

)*$#$+,-.,/+/01,-+1/$

))$&$+,-.,/+/01,-+1/$

))$2$+,-.,/+/01,-+1/$

))$%$+,-.,/+/01,-+1/$

))$#$+,-.,/+/01,-+1/$


FB

Conclusion & Future Work

• We are going to use FB for future work.

• Because it better fits the problem we are addressing

• FF performs better for other types of problems

• Study and classify inconsistency rules by their “complexity”.

• Integrate into a modeling tool

• Come up with a benchmark

Open question

• Given multiple resolution plans, which one is the most appropriate?

• Are there other techniques that may be better suited for resolving model inconsistencies?

• Partial-order planning, search-based approaches (e.g., local variable neighborhood search)

Automated Planning for Resolving Model Inconsistencies

A Scalability StudyJorge Pinna Puissant

Ragnhild Van Der StraetenTom Mens

October 2010

automated planning for resolving model inconsistencies - a scalability study

Education