Resolving model inconsistencies using automated ...

Softw Syst Model DOI 10.1007/s10270-013-0317-9

SPECIAL SECTION PAPER

Resolving model inconsistencies using automated regression planning Jorge Pinna Puissant · Ragnhild Van Der Straeten · Tom Mens

Received: 25 October 2012 / Revised: 9 January 2013 / Accepted: 16 January 2013 © Springer-Verlag Berlin Heidelberg 2013

Abstract One of the main challenges in model-driven software engineering is to automate the resolution of design model inconsistencies. We propose to use the artificial intelligence technique of automated planning for the purpose of resolving such inconsistencies through the generation of one or more resolution plans. We implemented Badger, a regression planner in Prolog that generates such plans. We assess its scalability on the resolution of different types of structural inconsistencies in UML models using both generated models and reverse-engineered models of varying sizes, the largest ones containing more than 10,000 model elements. We illustrate the metamodel-independence of our approach by applying it to the resolution of code smells in a Java program. We discuss how the user can adapt the order in which resolution plans are presented by modifying the cost function of the planner algorithm. Keywords Automated planning · Inconsistency resolution · Software modeling

Communicated by Dr. Antonio Vallecillo and Dr. Juha-Pekka Tolvanen. J. Pinna Puissant (B) · T. Mens Service de Génie Logiciel, Institut COMPLEXYS, Université de Mons, Place du Parc 20, 7000 Mons, Belgium e-mail: [email protected] T. Mens e-mail: [email protected] R. Van Der Straeten Software Languages Lab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium e-mail: [email protected]

1 Introduction One of the main challenges in model-driven software engineering (MDE) is to deal with evolving models, and to provide automated mechanisms to support this evolution [1]. A particular point of attention is to manage inconsistencies in software models [2]. Such model inconsistencies are inevitable [3], because a software system’s description is composed of a wide diversity of models, some of which are developed and maintained in parallel. Many domain-independent and domain-specific modeling languages exist. As a consequence, there are many different kinds of, often interrelated, models that can suffer from many types of inconsistencies. In this article, we mainly focus on design models expressed in the Unified Modeling Language (UML), because it is the de facto general-purpose modeling language [4]. Its visual notation consists of a set of different diagram types, such as class diagrams, sequence diagrams and statecharts, each expressing certain aspects of a software system. These diagrams are interrelated, and inconsistencies in and between them can arise easily. Our research does not focus on the activity of model inconsistency detection that has become well-established. Instead, we address the resolution of model inconsistencies. In particular, we focus on a semi-automatic way to resolve a selection of previously identified model inconsistencies through the generation of so-called resolution plans. To do this, we use the technique of automated planning [5] originating from the field of artificial intelligence [6]. This technique allows the generation of possible resolution plans through an automated planner without the need of manually writing resolution rules. In this article, we present and validate a regression planner that we implemented in Prolog, a well-known and widely used logic programming language [7,8].

123

J. Pinna Puissant et al.

This article is a substantially revised and extended version of our ECMFA 2012 paper [9] based on the PhD thesis of the first author [10]. The afore-mentioned paper has been enhanced with a more thorough validation, an illustration of the metamodel independence of the approach by applying it to the resolution of Java code smells, and a discussion of how the order of generated resolution plans can be changed by adapting the cost function. The article is structured as follows. Section 2 introduces the problem of model inconsistency resolution and presents a motivating example. Section 3 introduces automated planning. Section 4 explains the automated planner that we implemented for resolving model inconsistencies. Section 5 assesses the scalability of the approach, by showing how it is able to generate resolution plans for generated UML models of varying sizes, as well as for models reverse engineered from Java code. Section 6 discusses how the planning algorithm can be adapted to change the order of the generated resolution plans. Section 7 illustrates that the planner is independent from a particular metamodel, by illustrating that it can be applied in a different context, namely the resolution of code smells in Java programs. Section 8 presents the threats to validity and Sect. 9 discusses the future work. Section 10 presents related work and Sect. 11 concludes this article.

2 Motivating example Consider as a motivating example, the simple UML class diagram is shown in Fig. 1. The diagram contains two structural inconsistencies, corresponding to constraints imposed by the UML metamodel that are not respected by the class diagram model. The first one breaches the so-called “multiplicity composition constraint”, because the composite association (represented by a black diamond) between classes Car and Wheel has an upper multiplicity greater than 1 (namely 2) at the composite end, which is in contradiction with the fact that a part in the composition cannot be shared between multiple components. The second inconsistency breaches the “operation return constraint” because the operation getDiameter():float,integer of class Wheel has two return parameters instead of a single one. Each inconsistency can be resolved in several ways. For example, we can resolve the first inconsistency either by changing the upper multiplicity from 2 to 1, or by replac-

Car -manufactor:string

Wheel 0..2

4

+ startEngine():void

Fig. 1 Class diagram with 2 inconsistencies

123

ing the composite association by a regular association. The second inconsistency can be resolved either by removing one of both return parameters, or by changing one of the return parameters into an input parameter. For now, this example serves to illustrate some examples of structural model inconsistencies. In Sect. 4, we come back to this example by proposing automated plans to resolve these inconsistencies. This requires us, however, to first introduce the notion of automated planning.

3 Automated planning Our aim is to tackle the problem of inconsistency resolution by generating possible resolutions without the need of manually writing resolution rules or writing any procedures that generate possible resolutions. The approach needs to enable the resolution of multiple inconsistencies at once and to perform the resolution in a reasonable time. In addition, the approach needs to be generic, i.e., it needs to be easy to apply it to different modeling languages. In this article, we propose to use automated planning for this purpose. Automated planning aims to generate plans, i.e., sequences of actions that lead from an initial state to a state meeting a specific predefined goal. As schematized in Fig. 2, each planning approach consists of a representation language to describe the problem domain and the specific problem; an algorithm describing the mechanism to solve the problem; and a sequence of generated plans produced as output of the algorithm. The problem domain (e.g., model inconsistency resolution) is expressed as a set of possible actions (e.g., to change a model). A possible action specifies a valid way to go from one state to another. The action is composed of a precondition that specifies the conditions that must hold in order for the action to be applicable, and an effect that specifies the changes to be made to the current state. The problem that needs to be solved in the problem domain (e.g., an inconsistent model such as the one in Fig. 1) is expressed by an initial state and a desired goal. The initial state represents the current state of the world (the inconsistent model). The desired goal is a partially specified state that describes the world that we would like to obtain (a consistent model). A generated plan is a sequence of actions, generated automatically by the planning algorithm, to transform the initial state into a state that satisfies the desired goal. Many algorithms exist to solve planning problems [5]. A first approach consists in translating the problem and its domain into a satisfiability problem, and using a model checker or SAT solver to find a solution [11]. A second way consists in using a state space search algorithm. The state space can be traversed through progression planning

Resolving model inconsistencies

The algorithm Search Algorithm (RBFS)

Evaluation function f(n) = h(n) + g(n)

Cost function g(n)

Successor function

Solution function

Initial state

Desired goal

Heuristic function h(n)

Set of possible actions (The problem domain)

Fig. 2 The representation language and planning algorithm

or regression planning. Progression planning performs a forward search that starts in the initial state and tries to find a sequence of actions that reaches a goal state. Regression planning starts from the goal state and searches backwards to find a sequence of actions that reaches the initial state.

The performance of Badger depends mainly on the size of the desired goal as the algorithm works only with relevant actions. A relevant action is an action that contributes to the achievement of the goal. The search space of a regression planner will be significantly smaller than the one of a progression planner, as the latter depends mainly on the size of the initial state and does not exclude irrelevant actions.

4 Badger: a regression planner In earlier work [12], we assessed the use of an existing progression planner called FF (Fast-Forward Planning System) [13,14]. It is considered by Russell and Norvig [6] as the most successful state-space searcher, and was awarded for outstanding performance at the AIPS 2000 planning competition and top performer at the AIPS 2002 planning competition. FF uses an expressive logic representation language (called PDDL). It was the only readily available planner we found at that time that properly dealt with negation. Unfortunately, when we used this planner in the specific context of model inconsistency resolution, it suffered from various scalability problems and lack of expressiveness, making the approach unusable for our purposes. Therefore, in this article, we present our implementation and validation of a regression planner that we have baptized Badger. The name comes from the honey badger, an animal that is able to run backwards, just like a regression planner searches backwards from the goal state. The main components of Badger are schematically depicted in Fig. 2 and will be discussed in the following subsections.

4.1 The metamodel In our current implementation of Badger, we specified the metamodel manually as a set of logic facts in Prolog. It would be possible to automate this process, e.g., by converting the metamodel specification from some other format (e.g., XMI or Ecore), but this is left as future work. A simple metamodel for class diagrams is shown in Fig. 3. The logic representation of this metamodel is given below. Rule mme represents the metamodel elements. Rule mme_property represents the properties of the specified metamodel element, the kind of value that is used (e.g., text, boolean, int), the default value and if the property is optional or not. Rule mme_refs represents the relationships between two metamodel elements, the name of this relationship, the multiplicities and if it is a composite relationship. Rule mme_enum represents the possible values of an enumeration type. Here is an extract of the logic rules representing part of the metamodel of Fig. 3:

123

J. Pinna Puissant et al. packagedelement Operation AggregationKind

VisibilityKind public private protected package

none shared composite

* Package

0..1

name:Text visibility:VisibilityKind

0..1

name:Text

*

ParameterDirectionKind in inout out return

1

* ownedattribute name:Text Class 2..* visibility:VisibilityKind 0..1 0..1 * upper:Number name:Text navigableownedend lower:Number type visibility:VisibilityKind 0..1 0..1 * isreadonly:Boolean * aggregation:AggregationKind iscomposite:Boolean ownedend

name:Text visibility:VisibilityKind direction:ParameterDirectionKind

*ownedoperation

packagedelement

Property Association

name:Text 1 visibility:VisibilityKind

0..1

packagedelement

*

Parameter ownedparameter

generalization

1..*

*

Generalization

general

1

*

Fig. 3 Simplified fragment of the UML metamodel for class diagrams

mme(class). mme_property(class,name,text,‘a class’,false). mm_refs(class,0,*,ownedattribute,property,0,1,true). mm_refs(class,0,*,ownedoperation,operation,0,1,true). mme(property). mme_property(property,name,text,‘src’,false). mme_property(property,lower,int,0,true). mme_property(property,upper,int,0,true). mme_property(property,aggregation, aggregationKind,‘none’,true). mm_refs(property,0,1 type,class,0,*,false). mm_enum(aggregationKind, [’none’,’shared’,’composite’]). mme(operation). mme_property(operation,name,text,‘an operation’,false). mme(parameter). mme_property(parameter,name,text,‘a parameter’,false). mme_property(parameter,direction, parameterDirectionKind,‘in’,false). mm_refs(parameter,0,1,type,class,0,*,false). mm_enum(parameterDirectionKind, [’in’,’inout’,’out’,’return’]). mme(association). mm_refs(association,2,*,ownedend,property,0,1,true).

As we will see in the next section, additional constraints on the metamodel can be specified in the logic rules that encode the actions of the planner. 4.2 The problem description The initial state of a planning problem is expressed as a conjunction of logic literals that represents the input model. We specify the models using Praxis [15]. It comes with a suite of Eclipse plugins to reason about ECore and XMI models; to generate class diagram models of varying sizes [16]; and to detect model inconsistencies [17,18]. The key idea of the Praxis language is that it represents models and model changes as sequences of six types of elementary operations: create, delete, addProperty, remProperty, addReference and remReference.

123

An example of how to represent the initial state with Praxis is shown below using the class diagram of Fig. 1. First, class Car and its owned properties, attributes and operations are created by author Tom during revision 0. Next, class Wheel and its constituents are created by author Jorge in revision 1. Finally, the association between both classes is added by author Tom in revision 2. create(c1, class, 0,‘Tom’). addProperty(c1, name, ‘Car’, 0,‘Tom’). create(att1, property, 0,‘Tom’). addProperty(att1, name,‘manufactor’, 0,‘Tom’). addReference(att1, type,string, 0,‘Tom’). addReference(c1, ownedattribute, att1, 0,‘Tom’). create(op1, operation, 0,‘Tom’). addProperty(op1, name,‘startEngine’, 0,‘Tom’). addReference(c1, ownedoperation,op1, 0,‘Tom’). create(c2,class, 1,‘Jorge’). addProperty(c2, name,‘Wheel’, 1,‘Jorge’). create(att2, property, 1,‘Jorge’). addProperty(att2, name,‘pressure’, 1,‘Jorge’). addReference(att2, type,float, 1,‘Jorge’). addReference(c2, ownedattribute,att2, 1,‘Jorge’). create(op2, operation, 1,‘Jorge’). addProperty(op1, name,‘getDiameter’, 1,‘Jorge’). create(par1, parameter, 1,‘Jorge’). addProperty(par1, name,‘a’, 1,‘Jorge’). addProperty(par1, direction,‘return’, 1,‘Jorge’). addReference(par1, type,float, 1,‘Jorge’). addReferemce(op2, ownedparameter,par1, 1,‘Jorge’). create(par2, parameter, 1,‘Jorge’). addProperty(par2, name,‘b’, 1,‘Jorge’). addProperty(par2, direction,‘return’, 1,‘Jorge’). addReference(par2, type,integer, 1,‘Jorge’). addReferemce(op2, ownedparameter,par2, 1,‘Jorge’). addReference(c2, ownedoperation,op2, 1,‘Jorge’). create(pro1, property, 2,‘Tom’). addProperty(pro1, name,‘src’, 2,‘Tom’). addProperty(pro1, lower,0, 2,‘Tom’). addProperty(pro1, upper,2, 2,‘Tom’). addProperty(pro1, aggregation,‘composite’, 2,‘Tom’). addReference(pro1, type,c1, 2,‘Tom’). create(pro2, property, 2,‘Tom’). addProperty(pro2, name,‘dst’, 2,‘Tom’). addProperty(pro2, lower,4, 2,‘Tom’). addProperty(pro2, upper,4, 2,‘Tom’). addProperty(pro2, aggregation,‘none’, 2,‘Tom’). addReference(pro2, type,c2, 2,‘Tom’).

Resolving model inconsistencies Table 1 Logic operators–atoms Praxis primitives

Syntax

Example

lastCreate(id,mme) lastAddProperty(id,property,value) lastAddReference(id1,reference,id2) The semantics of the Praxis primitives is given by the Praxis language. For example, lastCreate(id,mme) is true if there is a create(id,mme,r,a) in the sequence of elementary operations that is not deleted later in the sequence lastAddProperty(c1,name,‘Car’)

Syntax

forall(P(x1 , ..., xk , y1 , ..., yp ), Q(y1 , ..., yp , z1 , ..., zm )) where P and Q are Praxis primitives

Semantics

∀x1 ...∀xk ∀y1 ...∀y p (P(x1 , ..., xk , y1 , ..., y p ) ⇒ ∃z 1 ...∃z m Q(y1 , ..., y p , z 1 , ..., z m ))

Semantics

Universal quantification

Existential quantification

Value comparison

Example

forall(lastCreate(Y,class), lastAddProperty(Y,name,Z))

Syntax

exists(P(x1 , ..., xk )) where P is a Praxis primitive

Semantics

∃x1 ∃x2 ...∃xk (P(x1 , ..., xk ))

Example

exists(lastCreate(X,class))

Syntax

compare(P(x), >, v) where P is a Praxis primitive of kind lastAddProperty, x is a variable that represents the third parameter of P, and v ∈ N Let n be the unique value such that the model satisfies P(n). The truth value of compare(P(x), >, v) is the truth value of n > v compare(lastAddProperty(pro1,upper,X),>,1)

Semantics Example Property comparison

Example

compare(P(x), >, Q(y)) where P and Q are Praxis primitives of kind lastAddProperty, x and y are variables that represent the third parameter of P and Q Let n and m be the unique values such that the model satisfies P(n) and Q(m). The truth value of compare(P(x), >, Q(y)) is the truth value of n > m compare(lastAddProperty(pro1,upper,X), >, lastAddProperty(pro1,lower,Y))

Syntax

count(P(x), >, v) where P is a Praxis primitive, x is a variable, and v ∈ N

Semantics

|{a | M | P(a)}| > v where M is the model

Syntax

Semantics

Counting

Transitive Navigability

Example

count(lastAddReference(agg, ownedEnd, X), >, 1)

Syntax Semantics

nav(From, Kind, To) where Fr om and T o are model elements and K ind is a binary relation between model elements nav(From, Kind, To) is true iff (Fr om, T o) is in the transitive closure of K ind

Example

nav(c1,generalization,c9)

Although the operators for value comparison, property comparison and counting are only shown with the > function, other comparison functions can be used as well : ,1)) ]

The prefix last used in operation lastAddProperty in the example above refers to those model operations that are not followed by other operations cancelling their effects [17]. Using the negation of the inconsistencies in the desired goal ensures to resolve only those inconsistencies that have been detected previously. For this detection, we rely on the detection approach proposed by [17]. Note that our approach does the strict minimum to accomplish the desired goal. For example, if the user wants to solve an inconsistency of type “the lower bound multiplicity must be greater than 0”, Badger will propose 1 as solution to avoid

123

J. Pinna Puissant et al. Table 2 Logic operators–Boolean combinations Negative literal

Conjunction

Disjunction

Syntax

not(L) where L is an Atom

Semantics

not L

Example

not(lastAddProperty(prop1,aggregation,‘composite’)),

Syntax

[L1 , L2 , . . . , Lk ] where L 1 , L 2 , . . . , L k are Atoms or Boolean Combinations

Semantics

L 1 ∧ L 2 ∧ …∧ L k

Example

[lastAddProperty(c1,name,‘Car’), lastAddProperty(c2,name,‘Wheel’)]

Syntax

or[L1 , L2 , . . . , Lk ] where L 1 , L 2 , . . . , L k are Atoms or Boolean Combinations

Semantics

L 1 ∨ L 2 ∨ …∨ L k

Example

or [lastAddProperty(c1,name,‘Car’), lastAddProperty(c1,name,‘Wheel’)]

an infinite number of possibilities. In the case of multiple inconsistencies, Badger will still do the strict minimum. For example, suppose that we have an inconsistency type requiring that the upper multiplicity must be strictly greater than 0 and a second inconsistency type requiring that the upper multiplicity must be greater than the lower multiplicity. If, initially, the lower multiplicity of some association end is 3 and the upper multiplicity is 0, Badger will propose to change the upper multiplicity to 4, since this is the minimal solution satisfying both requirements. A possible action specifies a valid way to go from one state to another. The action is composed of a precondition (pre) that specifies the conditions that must hold in order for the action to be applicable, and an effect (eff) that specifies which elementary operations will be added to the current state. The validity of an action (can) is verified by checking the constraints imposed by the metamodel on the model. The logic rules below specify the possible action setProperty. The pre rule states that the old property must exist before it can be changed. The can rule is used to verify that the new value is correctly typed and that it is different from the old value.1 The eff rule specifies the effect as a sequence of two elementary operations (remProperty and addProperty) to change the value of a property. It takes as a parameter the latest revision R on which the resolution plan is supposed to be applied. pre(setProperty(Id,MME,Property,OldVal,NewVal), [lastAddProperty(Id,Property,OldVal)]). can(setProperty(Id,MME,Property,OldVal,NewVal)) :mme_property(MME,Property,Type), call(Type,NewVal), NewVal \== OldVal. eff(setProperty(Id,Property,OldVal,NewVal),R, [remProperty(Id,Property,OldVal,R,‘Badger’), addProperty(Id,Property,NewVal,R,‘Badger’)]).

Planner actions

elementary model operations

createObj

create

createProperty

addProperty

setProperty deleteProperty

remProperty

createReference

addReference

moveReferenceSrc moveReferenceDst

remReference

deleteReference deleteObj

delete

Fig. 4 List of planner actions and their unfolding into elementary model operations

tions used in the effect of the action. Figure 4 lists all the actions that we have defined, together with the elementary model operations to which they unfold. 4.3 The generated plans Any automated planner should generate plans that contain a sequence of actions that transform the initial, inconsistent model into a model that does not have any of the inconsistencies specified in the desired goal. Moreover, the generated resolution plans should not lead to ill-formed models (that do not conform to their metamodel) as long as all metamodel constraints are given as part of the problem specification. Two complete resolution plans, each containing only two actions, that both solve the inconsistencies of the motivating example of Sect. 2 are given below:

We would like to stress here that an action used by the planner should not be confused with the elementary opera-

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

1 The call predicate used as part of the can rule is a well-known Prolog meta-predicate [7].

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

123

Resolving model inconsistencies

If we unfold the effects of each action from a resolution plan, we obtain a sequence of elementary operations that can be applied directly to transform the inconsistent model into a consistent one. Let us assume that the last model revision was number 1, and that the planner corresponds to an author named ‘badger’. Under these assumptions, the sequence of elementary operations that resolves the inconsistencies as specified by the first plan will be: remProperty(pro1,upper,2, 3,‘badger’) addProperty(pro1,upper,1, 3,‘badger’) remProperty(par1,direction,‘return’, 3,‘badger’) addProperty(par1,direction,‘in’, 3,‘badger’)

Unfolding the second resolution plan into a sequence of model operations would yield: remProperty(pro1,aggregation,‘composite’, 3,‘badger’) addProperty(pro1,aggregration,‘none’, 3,‘badger’) delete(par1,parameter, 3,‘badger’)

4.4 The algorithm We implemented the planner algorithm in Prolog, since Prolog’s built-in backtracking mechanism allows the planner to easily generate multiple resolution plans among which the user can choose the most suitable one. In this section, we will describe the different components of our algorithm, schematised in Fig. 2. The planner algorithm used by Badger is based on the recursive best-first search (RBFS) implementation of [8] to recursively generate a state space and search for a solution in that state space. RBFS is a best-first search that is essentially an improvement of the well-known A* algorithm (which is known to be complete) to explore the state space by expanding the most promising node. The algorithm relies on three functions: a solution function, a successor function and an evaluation function. These three functions are independent of the search algorithm, implying that we can also use other best-first search algorithms (e.g., A*, iterative-deepening A*, memory-bounded A*). We have chosen for RBFS because it only keeps the current search path and the sibling nodes along this path, making its space complexity linear in the depth of the search tree [22]. The solution function used by Badger checks if a particular node is one of the solutions by verifying if there are no more unsatisfied literals in the desired goal. The successor function is the most complex one and is at the heart of the planning algorithm. It generates the child nodes of a particular node, and is used to generate the state space. The function proceeds as follows: (1) select a logic operator from the desired goal and generate a literal that satisfies this operator; (2) analyse the effect (the eff rule) of each action to find one that achieves this literal; (3) validate (the can rule) if the selected action can be executed; (4) protect the already satisfied literals, i.e., check if the execution

of the selected action does not undo a previously satisfied literal; (5) regress goals through actions, i.e., add the preconditions of the action (the pre rule) as new literals in the goal and remove the satisfied literals from the goal. The evaluation function f evaluates the child nodes to find the most promising one. It is defined as the sum of a cost function g and a heuristic function h : f (n) = g(n) + h(n). The cost function g(n) is the actual cost of the path to reach n. In Badger, the user can attach a different cost for applying each action. By default, all actions have the same cost, but the user can, for example, give more importance to actions that add and modify model elements than to actions that delete model elements. As will be shown in Sect. 6, these user-specified costs affect the order in which the plans are generated. The heuristic function h(n) is the minimal estimation of the cost to reach a solution from the node n. It can be obtained by defining a relaxed problem that is easier to solve. Among the typical heuristics known from automated planning, the one we implemented in Badger is a heuristic that ignores the preconditions. As a result, every action becomes applicable in every state, and a single literal of the desired goal can be achieved in one step. Remember that the desired goal is a Boolean combination of logic literals that represents one or more negations of inconsistencies. This implies that the heuristic can be defined as the number of unsatisfied literals in the desired goal. The experiments that we will report upon in Sect. 5 reveal that this heuristic function provides good results. It would have been possible to define and explore new planner heuristics for Badger, but developing and evaluating such heuristics takes a lot of effort and trial and error and is, therefore, out of the scope of this article. Nevertheless, likely candidate heuristics that we would recommend as alternatives of the current one would be based on the common relaxations in automated planning (e.g., ignore the delete effect, subgoal independence) [11]. 4.5 Temporary elements The number of actions proposed by a resolution plan to resolve an inconsistency involving the modification of a reference in the desired goal depends on the size of the initial state (i.e., it depends on the number of model elements). This negatively affects the performance of the algorithm and the number of generated resolution plans. To avoid generating many resolution plans that each refer to a concrete model element (e.g., one of the many classes in a class diagram), we introduced the notion of temporary elements as an abstraction of such a set of concrete model elements. A temporary element is represented as a tuple (+other,X,Y) where X is the model element type (e.g. class) and Y is the set of model elements of this type that cannot be used as part of the

123

J. Pinna Puissant et al. Table 3 List of selected structural model inconsistency types Id

Model element

Description of the inconsistency type (see [4])

I1

Association

Only binary associations can be aggregations (p. 39)

I2

Element

Elements that must be owned must have an owner (p. 65)

I3

NamedElement

If a NamedElement is not owned by a Namespace, it does not have a visibility (p. 101)

I4

MultiplicityElement

A multiplicity must define at least one valid cardinality that is greater than zero (p. 97)

I5

MultiplicityElement

The lower bound must be a non-negative integer literal (p. 97)

I6

MultiplicityElement

The upper bound must be greater than or equal to the lower bound (p. 97)

I7

Classifier

The general classifiers are the classifiers referenced by the generalization relationships (p. 54)

I8

Classifier

I9

Classifier

Generalization hierarchies must be directed and acyclic. A classifier can not be both a transitively general and transitively specific classifier of the same classifier (p. 54) A classifier may only specialize classifiers of a valid type (p. 54)

I10

Property

A multiplicity on an aggregate end of a composite aggregation must not have an upper bound greater than 1 (p. 127)

I11

Property

Only a navigable property can be marked as readOnly (p. 128)

I12

Property

The value of isComposite is true only if aggregation is composite (p. 128)

I13

Operation

An operation can have at most one return parameter (p. 107)

proposed resolution. Once the resolution plan is generated, the user must replace the temporary element by a concrete element that does not belong to Y to avoid re-introducing the same inconsistency. As an illustration of this, consider the example of an undesired cycle in a class specialization hierarchy: class A specializes class B and conversely. To resolve this inconsistency, the planner will generate plans that redirect one of the two specialisations constituting the cycle to another class. For example, a plan will be proposed to redirect the specialisation from class A to some other class different from class B through the use of (+other,class,[B]). This “other class” notation serves as a placeholder for any of the existing classes in the model, or even an entirely new class to be added by the user. 5 Scalability study In this section, we perform a scalability study of Badger for resolving structural model inconsistencies. We start by presenting the experimental setup. 5.1 Experimental setup All experiments reported in this article were carried on a Power Mac with 2.80GHz Intel Xeon Quad-Core processor and 4Gb of RAM. We used the 32-bit version of SWI-Prolog 6.0.2, running on the Ubuntu 11.04 operating system. All timing results obtained were averaged over ten different runs to account for performance variations. (Instead of using the average time, we could have chosen to use the minimal time instead, since the noise generated by external factors will always be positive.)

123

Table 3 lists 13 structural model inconsistency types we will consider in our scalability experiments. These inconsistency types are based on the UML 2.3 metamodel (of which Fig. 3 can be considered to be a simplified version) and its well-formedness constraints expressed in OCL. Each entry in Table 3 consists of an id followed by the metamodel element on which the constraint is specified in the UML specification. Next, a short description of the inconsistency type is given, followed by the page number of the UML Superstructure document [4], where the inconsistency type can be found. For convenience, the selected inconsistency types in Table 3 were taken from or inspired by [4,17,20,23,24]. This list is, therefore, by no means complete. Other inconsistency types could be added and might affect the outcome of the experiments. In a first scalability experiment (cf. Sect. 5.2) we make use of a model generator due to the unavailability of a sufficiently large sample of realistic UML models. We choose to use an existing model generator that was mathematically grounded and validated in [16]. The model generator implements three probabilistic generators to produce valid models: a value generator for the model element’s properties (i.e., names, literal values, visibility kinds, direction kinds), a generator for generalizations, and a generator for references. The latter two probabilistically choose valid targets in the generated elements. We modified the probabilities used by the afore-mentioned generators to be able to generate inconsistent models containing the different types of inconsistencies listed in Table 3. For example, we customised the generators to authorise lower bound multiplicities smaller than 0 (I5 ), to authorise lower bound multiplicities bigger than the upper bound multiplicities (I6 ) and to authorise non-binary association to be aggregations

Resolving model inconsistencies

(I1 ). The resulting generated models typically contain many different inconsistencies belonging to different inconsistency types, but the number will vary from one model to another. We used the generated inconsistent models to study the impact of model size on Badger’s performance. Conforming to the metamodel of Fig. 3 we generated 941 models with sizes ranging from 21 to 10,849 model elements (obtained using the Praxis primitive lastCreate). The generated models also contain references (from 21 to 11,504) and properties (from 40 to 22,903), obtained using the Praxis primitives lastAddProperty and lastAddReference, respectively. Depending on their size, the generated models contained between 18 and 10,176 different inconsistencies. Except for the smallest models, all models contained many inconsistencies of each inconsistency type of Table 3. An exception to this was inconsistency type I8 for which there were only between 0 and 3 inconsistencies in each model. In a second scalability experiment (cf. Sect. 5.3), we use UML models obtained by reverse engineering five Java open source software systems (Chipchat, UMLet, CleanSheets and ThinWire). These five models have been used previously to evaluate a different model inconsistency approach [25]. The reverse engineering was done through Together 2006 Release 2 for Eclipse, an integrated modeling environment with support for reverse engineering of source code.2 This resulted in UML class diagrams and sequence diagrams, with model sizes ranging between 2,113 and 8,571 elements. In all scalability experiments, we analyze the growth of execution time by fitting statistical regression models to the obtained timing results. We used five different types of parametric regression models: a linear model, a logarithmic model, a quadratic polynomial, a power model and an exponential model. To adjust for the different number of parameters (the quadratic polynomial uses three parameters whereas the others use only two), the goodness of fit of each type of model is verified using the adjusted coefficient of determination3 R¯ 2 . Its value is always between 0 and 1, and a value close to 1 corresponds to a good fit. We manually confirmed the fit of each model through a visual analysis. In all tables displaying R¯ 2 values (e.g., Table 4), we use the following notation to facilitate identification of the best regression models. Regression models with the highest R¯ 2 value are marked with (*). Values higher than 0.90 are indicated in italics, and values higher than 0.95 are indicated in boldface. 2

techpubs.borland.com/together/tec2006/en/readme.html. 2 R¯ 2 is defined as 1 − (1 − R 2 ) n−n−1 p−1 , where R is the coefficient of determination, n is the sample size and p the number of parameters in the regression model.

3

Table 4 R¯ 2 values of five different parametric regression models used to fit the timing results of Fig. 5 Linear

Log.

Quadr. polyn.

Power

Exp.

I1

0.994

0.763

0.999 (*)

0.921

0.964

I2

0.992

0.744

0.997 (*)

0.921

0.953

I3

0.994

0.721

0.999 (*)

0.911

0.948

I4

0.996

0.760

0.998 (*)

0.933

0.963

I5

0.990

0.736

0.998 (*)

0.917

0.961

I6

0.989

0.740

0.998 (*)

0.909

0.970

I7

0.991

0.740

0.997 (*)

0.906

0.964

I8

0.984

0.701

0.993 (*)

0.874

0.963

I9

0.991

0.740

0.997 (*)

0.906

0.964

I10

0.992

0.755

0.999 (*)

0.925

0.961

I11

0.994

0.745

0.999 (*)

0.933

0.942

I12

0.992

0.738

0.999 (*)

0.890

0.976

I13

0.994

0.740

0.999 (*)

0.915

0.953

5.2 Assessing scalability with generated models In this section, we present three different experiments executed on the set of models obtained using the model generator. The generator provided as output models represented as sequences of elementary model operations, as explained in Sect. 4.2. In a first experiment, we applied Badger 13 times on each generated model, to resolve a single inconsistency of each type (see Table 3). In a next experiment, 13 inconsistencies (i.e., one of each type) were resolved together, for each of the generated models. In a last experiment, we applied Badger on a very large model to resolve an increasing number of multiple inconsistencies of the same type. For the first experiment, we ran Badger on all generated models and computed the timing results for generating a single resolution plan. We analysed the relation between the number of model elements and the time (in milliseconds) needed to resolve only one inconsistency of a particular type. To compare the timing results for different inconsistency types, we repeated the experiment for each of the 13 inconsistency types of Table 3. The results are visualised in Fig. 5. We observe that the time needed to resolve inconsistencies of a particular inconsistency type mainly depends on the size of the model. We also observe a different time for different types of inconsistencies. This is related, amongst others, to the number of logic literals in the desired goal. For example, I13 requires 4 literals and takes on average 4.2 times longer than I5 that only uses 1 literal. Table 4 shows the obtained R¯ 2 values. An analysis of this table allows us to conclude that there is a linear relationship between the size of the model and the execution time.

123

J. Pinna Puissant et al. 50 I1 I3 I5 I7 I9 I11 I13

45 40 35 30

I2 I4 I6 I8 I10 I12

25 20 15 10 5 0 0

2000

4000

6000

8000

10000

Fig. 5 Comparison of execution time (y axis, in milliseconds) per model size (x axis, in number of model elements) for resolving a single inconsistency in 941 different models. Different colours and symbols represent different inconsistency types

Indeed, from the R¯ 2 values, we can observe that the linear and quadratic polynomial models are the best in all cases. For all quadratic models, the coefficient of x 2 was always close to 0, so it is very close to linear. A visual interpretation confirms that the linear models are a very good match. For the second experiment, we studied how the generation of resolution plans with Badger scales up when resolving multiple inconsistencies of different types together. For each considered model, we resolved together one inconsistency of each of the 13 inconsistency types. Because not all models have an inconsistency of type I8 , during our analysis we distinguished between models containing 12 inconsistencies (excluding I8 ) and models containing 13 inconsistencies. Figure 6 (top part) presents the results of this experiment. A visual interpretation shows that the resolution time only increases slightly as the model size increases. Unfortunately, none of the regression models is a good fit ( R¯ 2 < 0.25). The execution time depends on a number of factors. As expected, the execution time is lower for 12 inconsistencies (mean = 170.91, median = 167.59) than for 13 inconsistencies (mean = 215.22, median = 211.48). Another factor that determines the execution time is the number of actions in the resolution plan. Resolving 12 inconsistencies requires between 8 and 11 actions (median = 10), while for 13 inconsistencies between 9 and 12 actions and needed (median = 11). In addition, the resolution time increases as the number of actions increases, as shown in the box plots of Fig. 6 (bottom part). For the third experiment, we studied how the generation of a resolution plan scales up if Badger resolves multiple inconsistencies of the same type together. To test this, we generated a very large model containing more than 10,000 elements and a large number of inconsistencies of each type. We excluded inconsistency type I8 , because the model generator did not create enough inconsistencies of this type. For each of the remaining 12 inconsistency types, we computed

123

Fig. 6 Top Time comparison (y axis, in milliseconds) per model size (x axis, in number of model elements) for resolving multiple inconsistencies of different types in 941 different models. Bottom boxplots showing effect of number of actions on execution time

Fig. 7 Execution time (y axis, in seconds) per number of inconsistencies of the same type (x axis) for resolving multiple inconsistencies in a very large model. Different colours and symbols represents different inconsistency types

the time required to resolve an increasing number of inconsistencies (ranging from a single one to 70). Figure 7 visualizes the results and Table 5 shows the obtained R¯ 2 values. We visually observe a rapid increase of the execution time as the number of inconsistencies of the same type that need to be resolved increases. By observing the R¯ 2 values, we can conclude that there is a quadratic polynomial growth in execution time. Indeed, while the R¯ 2 values

Resolving model inconsistencies Table 5 R¯ 2 values of five different parametric regression models used to fit the timing results of Fig. 7 Linear

Log.

Quadr. polyn.

Power

Exp.

I1

0.809

0.449

0.991 (*)

0.930

0.943

I2

0.799

0.439

0.989 (*)

0.916

0.957

I3

0.782

0.422

0.986 (*)

0.915

0.955

I4

0.789

0.429

0.987 (*)

0.889

0.972

I5

0.789

0.429

0.987 (*)

0.889

0.972

I6

0.779

0.419

0.986 (*)

0.926

0.947

I7

0.779

0.420

0.985 (*)

0.941

0.936

I9

0.780

0.420

0.985 (*)

0.942

0.934

I10

0.786

0.426

0.987 (*)

0.926

0.949

I11

0.792

0.432

0.988 (*)

0.922

0.953

I12

0.782

0.422

0.986 (*)

0.915

0.955

I13

0.801

0.445

0.981 (*)

0.907

0.952

Fig. 8 Execution time (y axis, in milliseconds) per number of generated plans (x axis) for 13 inconsistencies (one inconsistency per type) in the reverse engineered models. Different colours and symbols represent different models Table 7 R¯ 2 values of five different parametric regression models used to fit the timing results of Fig. 8

Table 6 Models obtained by reverse engineering Java code

Linear

Log.

Quadr. polyn.

Power

Exp.

m1

0.943

0.608

1.000 (*)

0.745

0.995

m2

0.942

0.607

1.000 (*)

0.700

0.985

184

m3

0.941

0.605

1.000 (*)

0.701

0.986

6,345

186

m4

0.941

0.605

1.000 (*)

0.695

0.984

1.4b

7,392

254

m5

0.941

0.605

1.000 (*)

0.681

0.979

1.2

8,571

231

Id

Java system

Version

Model elements

Classes

m1

Chipchat

1.0β2

2,113

14

m2

UMLet

9β

4,897

m3

SweetRules

2.0

m4

CleanSheets

m5

ThinWire

are very high for the quadratic polynomial, power and exponential regression models, the quadratic models have the best fit (with R¯ 2 > 0.98 in all cases). The different growth rates observed in Fig. 7 reflect the complexity of the inconsistency type to be resolved. For example, the inconsistency types whose resolution only requires the change of property values (e.g., I5 and I6 ) take less time than those that need changes to references between model elements (e.g., I9 and I7 ), because of the additional multiplicity constraints required for the latter. 5.3 Assessing scalability with reverse-engineered models In addition to assessing the scalability using generated models, in this section, we assess the scalability on UML models obtained by reverse engineering Java code from five open source software systems, summarized in Table 6. The reverse engineering resulted in a series of class diagrams and sequence diagrams. The metamodel used by these reverse engineered models is a subset of the UML metamodel. This metamodel is significantly bigger than the one used in the previous section (Fig. 3), and has been specified manually in Badger in the same way as the one presented in Sect. 4.1. We analyzed empirically how the generation of multiple resolution plans with Badger scales up when resolving

multiple inconsistencies of different types together. We first manually added one inconsistency of each of the 13 inconsistency types to each of the reverse engineered models. We then resolved together one inconsistency of each of the 13 inconsistency types, and we generated gradually from a single resolution plan to 100 resolution plans. Figure 8 presents the results of this experiment. Visually, we notice that the execution time rapidly increases as the number of generated plans increases. This is confirmed by the analysis of the fitted types of parametric regression models that reveals at least a quadratic growth. In Table 7, showing the obtained R¯ 2 values for each type of regression model, we observe that the quadratic regression model has the best fit (with R¯ 2 > 0.999 in all cases), closely followed by the exponential regression models ( R¯ 2 > 0.97 in all cases).

6 Changing the order of generated resolution plans To assess whether Badger generates meaningful resolution plans, we manually verified all generated resolution plans for 5 very small class diagram models (containing between 2 and 9 classes each). The number of generated plans varied between 3 and 10. The plans corresponded to what we expected, though we did not always agree with the order in

123

J. Pinna Puissant et al.

erated and presented by increasing order of actions, to resolve this inconsistency. These plans are presented below, using an informal notation, since the logic representation introduced in Sect. 4.3 would require too much space:

Wheel

concrete syntax

p1 :: Parameter

type

Float :: Class

direction = return

ownedparameter

getDiameter :: Operation

ownedoperation

Wheel :: Class

ownedparameter

p2 :: Parameter

type

Integer :: Class

direction = return

abstract syntax Fig. 9 Concrete and abstract syntax of a class with an inconsistency of type I13 (cf. Table 3)

which these plans were generated. By modifying the cost function g(n), presented in Sect. 4.4 as part of the evaluation function of our planner algorithm, we can easily change the order in which resolution plans are generated by Badger, taking into account the user’s preferences. In all previous experiments, we always generated the shortest plans first: because we used the same cost for each action, the generated plans were ordered in terms of the number of actions they contain. When different plans have the same number of actions, the order in which they are generated depends on how the set of possible actions and the model elements are indexed by Prolog. In this section, we will explore different orders, by changing the priority of the following parameters used by the cost function: (a) the kind of action; (b) the metamodel element; (c) the model element on which an action is performed; (d) the author that performed the action; and (e) the revision in which it has been performed. (a) Setting priorities on the kind of action Let us start by illustrating the effect of assigning a higher priority (i.e., lower cost) to certain kinds of actions on the order in which Badger generates plans. We use a simple class with an inconsistency of type: “an operation can have at most one return parameter” (I13 of Table 3). Figure 9 shows the concrete and abstract syntax of class Wheel. The inconsistency arises because operation getDiameter() has two return parameters (one float and one integer). Badger proposes ten plans, gen-

123

1. move reference ownedparameter between operation getDiameter and parameter p1 to make the parameter belong to a different operation; 2. move reference ownedparameter between operation getDiameter and parameter p2 to make the parameter belong to a different operation; 3. set property direction of parameter p1 from return to in; 4. set property direction of parameter p1 from return to inout; 5. set property direction of parameter p1 from return to out; 6. set property direction of parameter p2 from return to in; 7. set property direction of parameter p2 from return to inout; 8. set property direction of parameter p2 from return to out; 9. delete parameter p1 and delete also its references: reference ownedparameter between parameter p1 and operation getDiameter, and reference type between parameter p1 and class Float; 10. delete parameter p2 and delete also its references: reference ownedparameter between parameter p2 and operation getDiameter, and reference type between parameter p2 and class Integer. If the user changes the priorities of certain kinds of actions, this will affect the order in which these ten plans are generated. Table 8 shows the order for each considered scenario. In scenario (1), the user sets a higher priority (i.e., lower cost) to the plans containing delete actions (deleteProperty, deleteReference and deleteObj). As a result, plans 9 and 10 will be generated before all others, because these plans delete one of the parameters: p1 and p2, respectively. In scenario (2), the user sets a higher priority to the plans with delete actions and lower priority to the plans with actions that move the references (moveReferenceSrc and moveReferenceDst). This moves the plans using actions that modify references to the end while plans with delete actions are moved to the front. As a result, Badger will generate plans 9 and 10 (that contain delete actions) first, and plans 1 and 2 (that move references) last. In scenario (3), the user sets higher priority to plans with delete actions and wishes to exclude plans with actions that move references (by giving these actions an infinite cost ∞). Infinite costs are represented in Prolog by the cost function returning fail, prohibiting the generation of plans that use these actions.

Resolving model inconsistencies Table 8 Effect of action priorities on the order in which resolution plans are generated for resolving the inconsistency of type I13 in Fig. 9 Chosen cost function

Resolution order

(0) Shortest plans first (default settings)

1; 2; 3; 4; 5; 6; 7; 8; 9; 10

(1) Higher priority to plans with delete actions

9; 10; 1; 2; 3; 4; 5; 6; 7; 8

(2) Higher priority to plans with delete actions and lower priority to plans with actions that modify references

9; 10; 3; 4; 5; 6; 7; 8; 1; 2

(3) Higher priority to plans with delete actions and never generate plans with actions that modify references

9; 10; 3; 4; 5; 6; 7; 8

Those plans whose priority has changed w.r.t. the default scenario (0) are put in italics

Using this new cost function, Badger generates only eight plans, starting with plans 9 and 10, and leaving out plans 1 and 2 that involve moving references. (b) Metamodel priority To illustrate the effect of assigning priorities to different parts of the metamodel, we use a simple model composed of a class diagram and a sequence diagram. This model has an inconsistency of type: “each message in a sequence diagram needs to have a corresponding operation that needs to be owned by the message receiver’s class”. Figure 10 shows the concrete syntax of the model and the abstract syntax of the inconsistent part of the model, i.e., the message play that is used in the sequence diagram but not defined by an operation in the class Streamer. By default, Badger generates the following eight plans, by increasing number of actions, to resolve the inconsistency: 1. move reference sentTo between message play and lifeline st: Streamer so that the message is sent to a different lifeline; 2. set property name of message play from play to stream; 3. set property name of operation stream from stream to play; 4. set property name of message play from play to wait; 5. set property name of operation wait from wait to play; 6. set property name of message play from play to connect; 7. set property name of operation connect from connect to play; 8. delete message play and also delete its references: reference sentBy between lifeline d: Display and message play, and reference sentTo between message play and lifeline st:Streamer. If the user sets higher or lower priorities to certain kinds of metamodel elements, this will affect the order in which these eight plans are generated. Table 9 shows the order for each considered scenario. In scenario (1), the user sets higher priority to the sequence diagram by assigning a smaller cost to actions that create, modify or delete a model element belonging to the sequence diagram. As a result, the five plans gener-

ated first (plans 1, 2, 4, 6 and 8) now involve the manipulation of an element belonging to the sequence diagram, while the three plans generated last (plans 3, 5 and 7) involve the manipulation of an element belonging to the class diagram. In scenario (2), the user sets higher priority to the class diagram in a similar way. The three first generated plans are now the ones involving manipulation of class diagram elements (plans 3, 5 and 7). In scenario (3), the user excludes plans containing manipulations of class diagram elements, by assigning an infinite cost to the corresponding actions. As a result, Badger only generates the 5 plans that manipulate sequence diagram elements. (c) Model priority To illustrate the effect of assigning priorities to particular model elements, we use again the model of Fig. 10. We illustrate three different scenarios that are summarised in Table 10. In scenario (1), the user sets a lower priority to those actions that modify or delete the message play or its relationships: sentBy and sentTo. As a result, the first generated plans are those that do not modify the message play or its relationships (plans 3, 5 and 7). In scenario (2), the user excludes plans that manipulate the play message or its relationships sentBy and sentTo, by assigning an infinite cost to the corresponding actions. As a result, only plans 3, 5 and 7 are generated. In scenario (3), the user sets a higher priority to actions that modify or delete the operations wait and connect. The first generated plans are now plan 5 that modifies the name wait into play and plan 7 that modifies the name of connect into play. Observe that, if different resolution plans contain the same type of action but applied to a different model element, the order in which these plans are generated may be changed by adapting the cost function. This can be seen, for example, with plans 2 and 3 that both modify property name on a different model element. Resolution order (0) of Table 10 generates plan 2 before plan 3, while resolution order (1) generates plan 3 before 2. (d) Author priority To illustrate the effect of prioritising certain authors on the order of generated plans, we use a simple class diagram with an inconsistency of type I8 (cf. Table 3). Figure 11 shows the abstract syntax of this model. The inconsistency arises because of an inheritance cycle between the classes Vehicle,

123

J. Pinna Puissant et al. Display

Streamer

User 1

*

u: User

1 + select():void + stop():void + play():void + draw():void

1 + stream():void + wait():void + connect():void

d: Display

st: Streamer

1 : select 2 : connect 3 : play 4 : draw

concrete syntax

ownedoperation d: Display :: Lifeline

stream :: Operation

sentBy play :: Message

instanceOf

Streamer :: Class

ownedoperation

wait :: Operation

order = 2

sentTo

st: Streamer :: Lifeline

ownedoperation

connect :: Operation

abstract syntax Fig. 10 Concrete and abstract syntax of a small class diagram and sequence diagram with an inconsistency of type “each message in a sequence diagram needs to have a corresponding operation that needs to be owned by the message receiver’s class” Table 9 Effect of metamodel priorities on order in which resolution plans are generated for resolving the inconsistencies in Fig. 10

Chosen cost function (0) Shortest plans first (default settings)

1; 2; 3; 4; 5; 6; 7; 8

(1) Higher priority to plans with actions that modify the sequence diagram

1; 2; 4; 6; 8; 3; 5; 7

(2) Higher priority to plans that modify the class diagram

3; 5; 7; 1; 2; 4; 6; 8

(3) Never generate plans that modify the class diagram

1; 2; 4; 6; 8

Aircraft and Airplane. Three authors participated in the creation of this class diagram: Tom, Jorge and Mathieu. The modifications performed by these different

123

Resolution order

authors in different revisions are expressed in the abstract syntax using the constraints {author = …} and {revision = …}. The inconsistency was introduced by

Resolving model inconsistencies Table 10 Effect of model priorities on order in which resolution plans are generated for resolving the inconsistencies in Fig. 10 Chosen cost function

Resolution order

(0) Shortest plans first (default settings)

1; 2; 3; 4; 5; 6; 7; 8

(1) Highest priority to plans that do not modify or delete the message play and its relationships

3; 5; 7; 1; 2; 4; 6; 8

(2) Never generate plans that modify or delete the message play and its relationships

3; 5 ; 7

(3) Highest priority to plans that modify the operations wait and connect

5; 7; 1; 2; 3; 4; 6; 8

{author = Tom} {revision = 3} Vehicle :: Class {author = Tom} {revision = 3} superClass

{author = Tom} {revision = 1} Aircraft :: Class

{author = Jorge} {revision = 4} superClass

{author = Tom} {revision = 1} superClass

{author = Tom} {revision = 1} Airplane :: Class

{author = Mathieu} {revision = 2} superClass {author = Mathieu} {revision = 2} Helicopter :: Class

Fig. 11 Abstract syntax of a small class diagram with an inconsistency of type I8 (cf. Table 3)

a combination of modifications by different persons (Tom and Jorge) in different revisions (1, 3 and 4). Badger proposes the following three plans, generated and presented by increasing order of actions, to resolve the inconsistency: 1. delete reference superClass (created by Tom in revision 3) between classes Vehicle and Aircraft; 2. delete reference superClass (created by Jorge in revision 4) between classes Airplane and Vehicle; 3. delete reference superClass (created by Tom in revision 1) between classes Aircraft and Airplane;

Jorge. In scenario (2), the user only generates plans involving a manipulation of model elements created by Jorge, by setting an infinite cost (∞) to the actions performed by other authors. This leads to only plan 2 being generated. In scenario (3), the user sets higher priority to actions carried out by Mathieu. This has no effect on the default generation order, since none of the plans contained actions in which Mathieu was involved. Finally, in scenario (4), the user only wants plans that involve actions carried out by Mathieu, by assigning an infinite cost to the actions involving other authors. This results in no plans being generated, for the same reason as in scenario (3). (e) Revision priority To illustrate the effect of revision priority on the order of generated plans, we use the same example as the one used in Fig. 11. Table 12 shows the order in which the plans are generated according to the following scenarios. In scenario (1), the user sets higher priority (i.e., lower cost) to more recent revisions, by defining the cost function as a monotonically decreasing function in terms of the revision number. This leads to plan 2 being generated first, as it corresponds to a change made in revision 4. In scenario (2), the user sets higher priority (lower cost) to earlier revisions. This leads to plan 3 corresponding to revision 1 being generated first, followed by plan 1 corresponding to revision 2 and finally plan 2 corresponding to revision 4. Combining Priorities Obviously, all of the above ways of setting priorities to modify the cost function may be comTable 12 Effect of revision priorities on generation order of plans for resolving the inconsistencies in Fig. 11

We illustrate the effect of assigning author priorities through four scenarios. Table 11 shows the order in which the plans are generated depending on the given scenario. In scenario (1), the user sets higher priority to actions that are carried out by Jorge. As a result, plan 2 is generated first, as it is the only one manipulating a reference introduced by Table 11 Effect of author priorities on generation order of plans for resolving the inconsistencies in Fig. 11

Chosen cost function

Resolution order

(0) Shortest plans first (default settings)

1; 2; 3

(1) Higher priority to later revisions

2; 1; 3

(2) Higher priority to earlier revisions

3; 1; 2

Chosen cost function

Resolution order

(0) Shortest plans first (default settings)

1; 2; 3

(1) Higher priority to actions by Jorge

2; 1; 3

(2) Allowing only plans containing exclusively actions carried out by Jorge

2

(3) Higher priority to actions by Mathieu

1; 2; 3

(4) Allowing only plans containing exclusively actions by Mathieu

No plans generated

123

J. Pinna Puissant et al. implements

*

1 VisibilityKind

Interface

*

name:Text visibility:VisibilityKind

public private protected package

type

0..1

deprecated:Boolean

1

methods parameters

*

type

0..1

implements

*

* Override SuppressWarnings Nonnull CheckForNull Deprecated SwingThread DottedClassName CheckReturnValue AnalysisFeature Type. Nullable SlashedClassName SpecialKind DischargesObligation Before Test After NonNull

*

*

*

Field

annotationKind

Class

name:Text visibility:VisibilityKind

*

1 name:Text

*

static:Boolean deprecated:Boolean annotation:annotationKind

1

visibility:VisibilityKind abstract:Boolean deprecated:Boolean

*

type

*

0..1

*

0..1

*

methods

0..1

type

* * *

calls parameters exceptions

catches

* * * * *

*

*

method name:Text constructor:Boolean visibility:VisibilityKind

*

static:Boolean abstract:Boolean deprecated:Boolean annotation:annotationKind

0..1

*

*

overrides

*

extends

accesses

Fig. 12 Metamodel of the structure of Java used by Praxis

bined together without any restriction. For example, we could combine the author and revision information from Fig. 11 to set higher priority to the most recent revisions carried out by author Tom. This will lead to the following order of plans: 1 (changes by Tom in revision 3); 3 (changes by Tom in revision 1); 2 (no changes by Tom). For more examples on how to combine different types of priorities in the cost function, we refer the interested reader to [10].

7 Metamodel independence In this section, we show the metamodel independence of Badger by proposing plans to resolve code smells in a Java program (as opposed to structural inconsistencies in UML models as was the case in all previous examples). Kent Beck4 defines a code smell as a “hint that something has gone wrong somewhere in your code”. A more practical definition is that a code smell is a pattern that, if detected in the code source, can reveal design problems. A code smell warns about poor quality source code and design problems that make the system harder to understand, maintain and evolve [26,27]. For the experiment, we analyzed the open source Java program FindBugs5 , release 2.0. We used the Praxis plugin to convert the program structure of FindBugs into elementary 4

See http://c2.com/cgi/wiki?CodeSmell.

5

findbugs.sourceforge.nets.

123

model operations, corresponding to the metamodel given in Fig. 12. This metamodel has been represented manually in Badger in the same way as described in Sect. 4.1. Note that, because Praxis only exported the Java program structure (and not the full program code) into model operations, we only show how to resolve code smells that affect the structure of the program. We applied the Praxis detection plugin to detect the presence of 32 different types of code smells in total. Table 13 reports only those types for which at least one code smell was detected in the analyzed Java program. The table also shows the time that Badger took to resolve one code smell per type, and the time to resolve all code smells per type. Observe that, for the types C S2 , C S3 and C S4 , the time taken by Badger to resolve one code smell is the same as the time to resolve all of them because only one smell of these types was detected. Also observe that Badger ran out of memory when trying to resolve all code smells of type C S8 and C S9 , due to the high number of code smells detected for these two types: 803 and 2,219, respectively. This was due to the fact that in our experiments, we used a 32-bit version of SWI-Prolog 6.0.2, limiting the memory size to 128Mb. From the list of detected code smells, we chose to illustrate the resolution plans generated by Badger for a single code smell of three different types: C S3 , C S6 and C S9 . All classes involved in these three code smells belong to the package edu.umd.cs.findbugs The first code smell of type C S3 : “Abstract method overrides a concrete implementation” corresponds to abstract

Resolving model inconsistencies Table 13 Number of code smells detected in the Java program FindBugs and timing results (expressed in seconds) Id

Description

# Detected smells

Time to resolve one code smell

Time to resolve all code smells

C S1

TestCase defines setUp that doesn’t call super.setUp()

C S2

Method uses Properties.put instead of Properties.setProperty

C S3

Abstract method overrides a concrete implementation

1

0.2915

0.2915

C S4

Class relies on internal API classes

1

0.1961

0.1961

C S5

Method creates local variable-based synchronized collection

27

0.1958

0.6375

C S6

Class defines field that masks a superclass field

34

0.2834

5.4055

C S7

2

0.2843

0.2875

C S8

Method doesn’t override method in superclass due to wrong package for parameter Constructor makes call to non-final method

803

0.2624

Out of memory

C S9

Unwritten field

2,219

0.3269

Out of memory

method sawOpcode belonging to class bcel.Opcode StackDetector that overrides the concrete method sawOpcode belonging to class visitclass. DismantleBytecode. The extends chain between both classes is composed of three classes: class bcel.OpcodeStackDetector extends class BytecodeScanningDetector, which extends class visitclass. DismantleBytecode. Badger proposes eight resolution plans to resolve this code smell. They are presented informally below:

1. change the name of method sawOpcode of class OpcodeStackDetector; 2. delete the extends reference between bcel.OpcodeStackDetector and BytecodeScanning Detector; 3. delete the extends reference between Bytecode ScanningDetector and visitclass.Dismantle Bytecode; 4. change the name of method sawOpcode of class DismantleBytecode; 5. change method sawOpcode in class Dismantle Bytecode from concrete to abstract ; 6. change method sawOpcode in class OpcodeStack Detector from abstract to concrete; 7. delete method sawOpcode of class OpcodeStack Detector. This plan also contains 50 more actions (not shown here) to delete all the references from and to this method. No reference should be left if one of the objects that are part of the reference is deleted. 8. delete method sawOpcode of class Dismantle Bytecode. This plan also contains 55 more actions (not shown here) to delete all the references from and to this method. No reference should be left if one of the objects that are part of the reference is deleted.

13

0.2831

0.7604

1

0.1830

0.1830

The second code smell that we resolved is of type C S6 : “Class defines field that masks a superclass field”. This code smell corresponds to the field serialVersionUID from class gui2.FilterMatcher and the field serialVersionUID from class Stacked FilterMatcher. The latter one extends the class gui2.FilterMatcher. Badger proposes five resolutions plans to resolve this smell: 1. change the name of field serialVersionUID of class StackedFilterMatcher; 2. delete the extends reference between both classes; 3. change the name of field serialVersionUID of class FilterMatcher; 4. delete field serialVersionUID of class Stacked FilterMatcher and delete the reference between the class and the field; 5. delete field serialVersionUID of class Filter Matcher and delete the reference between the class and the field. The third code smell to be resolved is of type C S9 : “Unwritten field”. This code smell arises from field FINDBUGS_JAR in class anttask.AbstractFind BugsTask that has not been written by any method. Badger proposes 2 resolutions plans to resolve this smell: 1. add a reference field_writer from any method to field FINDBUGS_JAR; 2. delete the field and delete the reference fields from the class to the field. While this experiment has illustrated that Badger is indeed metamodel independent, it should be noticed that the resolution plans proposed by Badger do not necessarily preserve program behavior. Ideally, refactorings (i.e.,

123

J. Pinna Puissant et al.

behavior-preserving program transformations) should be proposed as a way to resolve code smells. Pérez [27] proposed a planner algorithm to compute, from refactoring strategies, the refactoring plans needed to automatically correct code smells. 8 Threats to validity Our approach has only been stress-tested on a Java system and on UML models consisting of class diagrams, sequence diagrams and use case diagrams. However, the fact that we rely on a metamodel independent representation (using sequences of elementary model operations) makes it straightforward to apply it to other types of models as well. We restricted our approach to structural inconsistency types only. We considered a limited set of such inconsistency types, but we have taken into account a variety of logic operators and elementary model operations. It remains an open question whether and how the approach can be generalised to non-structural inconsistencies (e.g., behavioural inconsistencies). Only inconsistencies that can be expressed using the logic operators presented in Tables 1 and 2 can be used in our approach. Adding new logic operators can have an impact on the timing results and on the performance of the planner algorithm. Based on the experiments carried out so far, we believe that the set of logic operators we have used provides a good trade-off between performance and expressiveness. We have used a third-party model generator [16] during our experiments. This may cause a bias as the generated models may not be representative for “real” models. This bias is limited since the model generator we used relies on the Boltzmann random sampling method that generates, in a scalable way, uniform samplings of any given size. We also carried out experiments using reengineered models, but it remains an open question whether the approach can scale up to real industrial models. Our approach does not take into account some metamodel features such as specialization, derived model elements and stereotypes. Accommodating these would require some changes to the planner algorithm, and may have an effect on its performance. 9 Discussion and future work To make the approach useful in practice, the resolution preferred by the user should be among the first generated resolution plans. The order in which resolution plans are generated can be changed by modifying the cost function of the planner algorithm, as shown in Sect. 6. In addition, entire resolution plans can be omitted by attaching an infinite weight to certain actions. Determining the most suitable parameters for

123

the cost function in practice would require a controlled user study to assess the quality of the resolution plans as perceived by the user. This is left for future work. Other requirements to make the approach practically viable are its integration into a modeling environment, and the availability of an intuitive visual interface allowing the user to easily adapt the cost function to her needs without requiring any programming experience or knowledge of the underlying planning algorithm. This was, however, outside the scope of the current article. It could be interesting to use automated planning for model refactoring, a technique that aims to transform models while preserving their behavior. Automated planning has been used by Pérez [27] to generate refactoring strategies in source code (Java programs). Pérez’ approach could be used in model refactoring, but the planner domain knowledge, refactoring rules and refactoring strategies, need to be added manually. The other way around, Badger could be adapted to be used in model refactoring, but a way to describe and preserve model behaviour must be added. In this article, we used classical planning, one of the automated planning variants, for the purpose of automatically resolving model inconsistencies. We would like to study the use of planning under uncertainty [28,29], another variant of automated planning. Planning under uncertainty aims to resolve problems in a nondeterministic and partially observable world, in which the planner has incomplete knowledge of the current state. Such a planner could be beneficial to resolve inconsistencies in distributed models, which are continuously edited by developers working asynchronously on their local copy, and committing their work from time to time to the rest of the developers [30]. To achieve this, the planner that resolves inconsistencies locally must exploit the possibility to share information (e.g., resolution plans, model elements) with the other planners installed somewhere else. Even though automated planning met our expectations, we intend to study other artificial intelligence techniques for the purpose of resolving modeling inconsistencies in an automated way. Logic-based approaches have been used for different but related purposes in inconsistency resolution. Marcelloni and Aksit [31,32] used fuzzy logic to cope with methodological inconsistencies in design models. It remains to be seen whether this approach can be generalised to resolve any kind of model inconsistency. Castro et al. [33] used logic abduction to detect and resolve inconsistencies in source code. We have started to carry out some promising experiments to apply this approach to resolve inconsistencies in design models, but a full-fledged experimental study is necessary to assess whether the approach actually scales up and works in practice. Harman [34] advocates the use of search-based approaches in software engineering. This includes a wide variety of

Resolving model inconsistencies

different techniques and approaches such as metaheuristics, local search algorithms, automated learning, genetic algorithms [6]. We believe that these techniques could be applied to the problem of model inconsistency resolution, because it satisfies at least three important properties that motivate the need for search-based software engineering: the presence of a large search space, the need for algorithms with a low computational complexity, and the absence of known optimal solutions. How these search-based approaches would compare to our proposed automated planning approach to model inconsistency resolution remains an open question. To assess the adequacy of all these different approaches to inconsistency resolution, there is an urgent need to define a benchmark enabling their comparison. Such a benchmark should contain at least a set of shared case studies on which to evaluate each approach; as well as a set of clearly identified comparison criteria. Defining such benchmarks is challenging because the existing model inconsistency resolution approaches found in research literature are quite diverse. They are implemented in different programming languages and on different operating systems, use different input formats, modeling languages and metamodels for the models, and different input and output formats for inconsistencies and resolutions. The benchmark should also impose a fixed set of inconsistency rules, which is quite difficult if the modeling languages or the metamodels are different. Analysing the resolution quality of the different approaches would require a controlled user study. Indeed, in presence of a wide variety of different resolution approaches, the only meaningful notion of quality would be the quality as perceived by the user.

10 Related work Several approaches have been proposed to resolve model inconsistencies. In our previous work [35], we specified resolution rules manually, which is an error-prone process. Automatic generation of inconsistency resolution actions aims to resolve this problem. Nentwich et al. [21] achieve this by generating resolution actions automatically from the inconsistency types. The execution of these actions, however, only resolves one inconsistency at a time. As recognised by the authors, this causes problems when inconsistencies and their resolutions are interdependent. In [35], we proposed a formal approach based on graph transformation to analyse these interdependencies. Xiong et al. [24] define a language to specify inconsistency rules and the possibilities to resolve the inconsistencies. This requires inconsistency rules to be annotated with resolution information. Almeida da Silva et al. [36] propose an approach to generate resolution plans for inconsistent models, by extending inconsistency detection rules with informa-

tion about the causes of the inconsistency, and using manually written functions that generate resolution actions. In both approaches, inconsistency detection rules are polluted with resolution information. Instead of explicitly defining or generating resolution rules, a set of models satisfying a set of consistency rules can be generated and presented to the user. Egyed et al. [23] define such an approach for resolving inconsistencies in UML models. Given an inconsistency and using choice generation functions, their approach generates possible resolution choices, i.e., possible consistent models. The choice generation functions depend on the modeling language, i.e., they take into account the syntax of the modeling language, but they only consider the impact of one consistency rule at a time. Furthermore, these choice generation functions need to be implemented manually. In [25], we used Kodkod, a SAT-based constraint solver using relational logic, for automatically generating consistent models. While the approach guarantees correctness and completeness (within the considered lower and upper bounds of the relations defined in the problem), a major limitation is its poor performance and lack of scalability. In Sect. 6, we illustrated how the cost function can be tweaked to change the order in which resolution plans are generated and presented to the user. In a similar vein, Küster and Ryndina [37] introduced the concept of sideeffect expressions to determine whether or not a resolution introduces a new inconsistency. They attach a cost to each inconsistency type to compare alternative resolutions for the same inconsistencies. A few other authors use automatic planning to solve different kinds of software engineering problems. For example, Pérez [27] applied automated planning to correct design smells in Java. The author uses JSHOP2 [38] and HTN planning to compute the refactoring strategies needed to automatically correct the design smells. Sirin et al. [39,40] use the SHOP2 planner to address the problem of automated composition of web services. Automated planning is also used by Memon et al. [41] to automatically generate test cases for graphical user interfaces (GUIs). They use the Interference Progression Planner (IPP) [42] to generate plans representing the testing sequences of GUI interactions. 11 Conclusion In this article, we used automated planning, a logic-based approach originating from artificial intelligence, for the purpose of automatically generating model inconsistency resolutions. We are not aware of any other work having used this technique for this purpose. We implemented a new regression planner, called Badger, in Prolog. Badger requires as input a model and a set of inconsistencies. In contrast to other inconsistency resolution

123

J. Pinna Puissant et al.

approaches, the planner does not require the user to specify resolution rules manually or to specify information about the causes of the inconsistency. To specify inconsistency resolution plans in a metamodel-independent way, and to be able to reuse an existing model generator, we relied on the Praxis language [17]. We validated Badger on 941 automatically generated UML class diagram models of various sizes (from 21 to 10,849 model elements), as well as on UML models obtained by reverse engineering five Java programs (from 2,113 to 8,571 model elements). We used a set of 13 structural inconsistency types based on OCL constraints found in the UML metamodel specification. We validated our approach through several stress-tests and discussed the limitations of our approach. Our empirical experiments suggested a strong linear relationship between the model size and the execution time, a quadratic relationship between the number of inconsistencies and the execution time and a quadratic relationship between the number of generated plans and the execution time. We also observed an increase of the execution time as the number of actions in the resolution plans increases. Our approach scales up to models containing more than 10,000 model elements. The metamodel independence was validated by applying Badger to the problem of resolving code smells in Java programs. However, controlled user studies are still needed to evaluate the preferred order of the generated resolution plans. Acknowledgments This work has been partially supported by the F.R.S.–FNRS through FRFC project 2.4515.09 “Research Center on Software Adaptability”; and by research project AUWB-08/12-UMH “Model-Driven Software Evolution”, an Action de Recherche Concertée financed by the Ministère de la Communauté française - Direction générale de l’Enseignement non obligatoire et de la Recherche scientifique, Belgium.

References 1. Van Der Straeten, R., Mens T., Van Baelen, S.: Challenges in modeldriven software engineering. In: Models in Software Engineering. Lecture Notes in Computer Science, vol. 5421, pp. 35–47. Springer, Berlin (2009) 2. George, S., Zisman, A.: Inconsistency management in software engineering: Survey and open research issues. In: Handbook of Software Engineering and Knowledge Engineering, pp. 329–380. World Scientific, Singapore (2001) 3. Balzer, R.: Tolerating inconsistency. In: Proceedings of the 13th International Conference on Software Engineering, ICSE ’91, pp. 158–165 IEEE Computer Society Press, Los Alamitos (1991) 4. Object Management Group: Unified Modeling Language: Superstructure version 2.3. formal/2010-05-05 May (2010) 5. Ghallab, M., Nau, D., Traverso, P.: Automated Planning: Theory and Practice. Morgan Kaufmann, Burlington (2004) 6. Russell, S., Norvig, P. : Artificial Intelligence: A Modern Approach, 3rd edn. Prentice Hall, Upper Saddle River (2010)

123

7. Sterling, L.S., Shapiro, E.Y.: The Art of Prolog: Advanced Programming Techniques, 2nd edn. MIT Press, Cambridge (1994) 8. Bratko, I.: Prolog Programming for Artificial Intelligence. Addison-Wesley, Boston (2001) 9. Pinna Puissant, J., Van Der Straeten, R., Mens, T.: Badger: a regression planner to resolve design model inconsistencies. In: Vallecillo, A., Tolvanen, J.-P., Kindler, E., Störrle, H., Kolovos, D.S. (eds.) ECMFA. Lecture Notes in Computer Science, vol. 7349, pp. 146– 161. Springer, Berlin (2012) 10. Pinna Puissant, J.: Resolving Inconsistencies in Model-Driven Engineering using Automated Planning. PhD thesis, Université de Mons (2012) 11. Jiménez Celorrio, S.: Planning and Learning under Uncertainty. PhD thesis, Universidad Carlos III de Madrid (2010) 12. Pinna Puissant, J., Mens, T., Van Der Straeten, R.: Resolving model inconsistencies with automated planning. In: 3rd workshop on Living with Inconsistencies in Software Development, CEUR Workshop Proceeding (2010) 13. Hoffmann, J.: FF: the fast-forward planning system. AI Mag. 22(3):57–72 (2001) 14. Hoffmann, J., Nebel, B.: The FF planning system: fast plan generation through heuristic search. J. Artif. Intell. Res. 14, 253–302 (2001) 15. Blanc, X., Falleri, J.-R.: Internet software evolution with vpraxis. ERCIM News 2012(88) (2012) 16. Mougenot, A., Darrasse, A., Blanc, X., Soria, M.: Uniform random generation of huge metamodel instances. In: European Conference on Model Driven Architecture—Foundations and Applications, pp. 130–145. Springer, Berlin (2009) 17. Xavier, B., Mougenot, A., Mounier, I., Mens, T.: Detecting model inconsistency through operation-based model construction. In: Proceedings of the International Conference on Software Engineering, vol. 1, pp. 511–520 (2008) 18. Le Noir, J. Delande, O., Exertier, D., Aurélio, M., da Silva, A., Blanc, X.: Operation based model representation: experiences on inconsistency detection. In: France, R.B., Malte Küster, J., Bordbar, B., Paige, R.F. (eds) ECMFA. Lecture Notes in Computer Science, vol. 6698, pp. 85–96. Springer, Berlin (2011) 19. Egyed, A.: Automatically detecting and tracking inconsistencies in software design models. IEEE Trans. Softw. Eng. 37(2), 188–204 (2011) 20. Van Der Straeten, R.: Inconsistency management in model-driven engineering: an approach using description logics. PhD thesis, Vrije Universiteit Brussel (2005) 21. Nentwich, C., Emmerich, W., Finkelstein, A.: Consistency management with repair actions. In: Proceedings of the 25th International Conference on Software Engineering, pp. 455–464. IEEE Computer Society, New York (2003) 22. Korf, R.E.: Linear-space best-first search: summary of results. In: Proceedings of the Tenth National Conference on Artificial Intelligence, AAAI’92, pp. 533–538. AAAI Press, California (1992) 23. Egyed, A., Letier, E., Finkelstein, A.: Generating and evaluating choices for fixing inconsistencies in UML design models. In: Proceedings of International Conference on Automated Software Engineering, pp. 99–108. IEEE, New York (2008) 24. Xiong, Y., Hu, Z., Zhao, H., Song, H., Takeichi, M., Mei, H.: Supporting automatic model inconsistency fixing. In: Proceedings of ESEC/FSE 2009, pp. 315–324. ACM, New York (2009) 25. Van Der Straeten, R., Pinna Puissant, J., Mens, T.: Assessing the Kodkod model finder for resolving model inconsistencies. In: European Conference on Modelling Foundations and Applications. Lecture Notes in Computer Science, vol. 6698, pp. 69–84. Springer, Berlin (2011) 26. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley, Boston (1999)

Resolving model inconsistencies 27. Pérez, J.: Refactoring Planning for Design Smell Correction in Object-Oriented Software. PhD thesis, ETSII, University of Valladolid (2011) 28. Vere, S.A.: Planning in time: windows and durations for activities and goals. IEEE Trans. Pattern Anal. Mach. Intell. 5, 246–267 (1983) 29. Dean, T., Basye, K., Chekaluk, R., Hyun, S., Lejter, M., Randazza, M.: Coping with uncertainty in a control system for navigation and exploration. In: Proceedings of the 8th National Conference on Artificial Intelligence (AAAI), vol. 2, pp. 1010–1015. MIT Press, Boston (1990) 30. Mougenot, A., Blanc, X., Gervais, M.-P.: D-praxis: a peer-to-peer collaborative model editing framework. In: Proceedings of the 9th IFIP WG 6.1 International Conference on Distributed Applications and Interoperable Systems, DAIS ’09, pp. 16–29. Springer, Berlin (2009) 31. Marcelloni, F., Aksit, M.: Leaving inconsistency using fuzzy logic. Inf. Softw. Technol. 43(12), 725–741 (2001) 32. Marcelloni, F., Aksit, M.: Fuzzy logic-based object-oriented methods to reduce quantization error and contextual bias problems in software development. Fuzzy Sets Syst. 145(1), 57–80 (2004) 33. Castro, S., Brichau, J., Mens, K.: Diagnosis and semi-automatic correction of detected design inconsistencies in source code. In: Proceedings of Internationall Workshop on Smalltalk Technologies, pp. 8–17. ACM, New York (2009) 34. Harman, M.: Search based software engineering. In Computational Science—ICCS 2006. Lecture Notes in Computer Science, vol. 3994, pp. 740–747. Springer, Berlin (2006) 35. Mens, T., Van Der Straeten, R., D’Hondt, M.: Detecting and resolving model inconsistencies using transformation dependency analysis. In: Proceedings of International Conference on Model Driven Engineering Languages and Systems. Lecture Notes in Computer Science, vol. 4199. pp. 200–214. Springer, Berlin (2006) 36. da Silva, M.A.A., Mougenot, A., Blanc, X., Bendraou, R.: Towards automated inconsistency handling in design models. In: Proceedings International Conference on Advanced Information Systems Engineering. Lecture Notes in Computer Science. Springer, Berlin (2010) 37. Küster, J.M., Ryndina, K.: Improving inconsistency resolution with side-effect evaluation and costs. In: Proceedings of International Conference on Model Driven Engineering Languages and Systems. Lecture Notes in Computer Science, vol. 4735, pp. 136–150. Springer, Berlin (2007) 38. Nau, D., Au, T.-C., Ilghami, O., Kuter, U., Murdock, J.W. Wu, D., Yaman, F.: Shop2: an HTN planning system. J. Artif. Intell. Res. 20:379–404 (2003) 39. Sirin, E., Parsia, B., Wu, D., Hendler, J.A., Nau, D.S.: HTN planning for web service composition using SHOP2. Web Semant. Sci. Serv. Agents World Wide Web 1(4), 377–396 (2004) 40. Wu, D., Sirin, E., Hendler, J.A., Nau, D.S., Parsia, B.: Automatic web services composition using SHOP2. In: WWW (Posters) (2003) 41. Memon, A.M., Pollack, M.E., Soffa, M.L.: Hierarchical GUI test case generation using automated planning. IEEE Trans. Softw. Eng. 27(2), 144–155 (2001) 42. Koehler, J., Nebel, B., Hoffmann, J., Dimopoulos, Y.: Extending planning graphs to an adl subset. In: Steel, S., Alami, R. (eds.) Recent Advances in AI Planning. Lecture Notes in Computer Science, vol. 1348, pp. 273–285. Springer, Berlin (1997)

Author Biographies Jorge Pinna Puissant obtained his Ph.D. in 2012 at the Software Engineering Lab of University of Mons, Belgium. His thesis promotor was Tom Mens, and the topic of the Ph.D. was essentially what is presented in the current SoSyM article. Jorge no longer works in academia today.

Ragnhild Van Der Straeten is a post-doctoral researcher at the Software Languages Lab, Department of Computer Science, Faculty of Sciences, Vrije Universiteit Brussel, Belgium. Her research interests are in model-driven software engineering, in workflow modelling and in domain engineering. More specifically, she has published many peer-reviewed international articles on the topic of inconsistency management in modeldriven software engineering. She has been a reviewer for several international workshops, conferences and journals. She teaches courses on software engineering. She is a member of the ACM.

Tom Mens is full professor directing the Software Engineering Lab at the Department of Computer Science, Faculty of Sciences, University of Mons, Belgium. His research interests are in software evolution, modeldriven software engineering, empirical analysis and humancomputer interaction. He is involved in several research projects and published numerous articles in these domains in international scientific conferences and journals, including several ones in SoSyM. He co-edited the Springer book Software Evolution with Serge Demeyer in 2008 and was program co-chair of CSMR 2011, CSMR 2012 and ICSM 2013. He chairs the ERCIM Working Group on Software Evolution, and is a member of IEEE, the IEEE Computer Society and the European Association of Software Science and Technology (EASST).

123