A metamodel for the specification and verification of model refactoring actions

Refactoring has become a valuable activity during the software development lifecycle, because it can be induced by different causes, like new requirements or quality improvement. In code-based development contexts this activity has been widely studied, whereas in model-driven ones, where models are first-class development entities, there are many issues yet to be tackled. In this paper we present a metamodel that supports the specification of pre- and post- conditions of model refactoring actions, and the automated derivation and verification of such conditions in specific modeling languages. Our work is aimed at helping users to implement refactoring actions in the adopted modelling language by providing an environment for guaranteeing the feasibility of refactoring actions. Our primary focus is on the definition of applicable sequences of refactoring actions, rather than on the user-driven step-by-step application of refactoring actions. As an example, we illustrate the applicability of our metamodel for UML models refactoring.


INTRODUCTION
Refactoring is acquiring ever more relevance during software lifecycle due to fast and frequent software changes that require exibility * This work has been partially funded by the ECSEL project MegaMart2 (grant agreement No 737494).
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro t or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior speci c permission and/or a fee. Request permissions from permissions@acm.org. For exaemple, Opdyke had introduced in his Ph.D. thesis the feasibility of a sequence of refactoring actions by considering and introducing pre-and post-condition aspects [20]. Lately, Fowler et al. had provided a dictionary of refactoring actions aimed at driving users selection [10]. By leveraging on Opdyke's approach, Ò Cinnèide et al. have introduced a framework for automatically verifying the feasibility of a sequence of refactoring actions [17]. In the latter, they have formalised whether a sequence is feasible or not by reducing and validating its pre-and post-condition.
In our recent work [2,3], we have targeted the need of implementing refactoring actions in model-based approaches. In this context, we have experimented a lack of support especially to the de nition of sequences of actions that can be batch-applied, for example in the context of evolutionary algorithms, without user interactions. In order to start targeting this lack, in this paper we present a metamodel, that we have developed by leveraging on Opdyke and Ò Cinnèide concepts, for supporting refactoring activities, with a special focus on pre-and post-condition speci cation and veri cation.
We have conceived our metamodel with the aim of being applied to multiple modelling languages. Thus, we have introduced di erent anchor points for applying the metamodel to their modelling languages. Furthermore, we have developed a set of external helpers aimed to execute common operations, for example, the reduction of the sequence pre-condition or the validation of the post-condition. Moreover, we have decided to use OCL as constraint language because it is quite commonly adopted in MDE ecosystems.
We have applied our metamodel to UML and AEmilia [7]. For both languages, we have implemented di erent refactoring actions to build feasible sequences of refactoring actions. Due to space limitations, we report here only the UML implementation.
The remaining of this paper is structured as follows: Section 2 introduces the related work; in Section 3 we describe our metamodel, while in Section 4 we illustrate its application to UML; conclusion and future work are reported in Section 5.

RELATED WORK
Software refactoring is a well-known activity very likely born with programming. The x-it-later approach, where xing problems (especially non-functional ones) is demanded after a prototypal version of the code has been produced, implies refactoring as a rst-class activity, interleaved with other phases of the software lifecycle. Although code refactoring is an extensively explored topic in literature [1,16,21,24], the wide adoption of MDE techniques in software design and development, which has led models to be rst-class artefacts, paved the way to model refactoring, which nowadays represents a challenging research area [4,10,12,23].
Recently, several approaches have tried to improve code refactoring within IDEs (eg, Eclipse, IntelliJ Idea). Kim et al. have proposed a series of papers [13,14] targeting Java code refactoring through the implementation of some design patterns de ned in [11]. Our approach di ers in that, rst, it supports model-based refactoring in a language-independent way and, second, it leaves to the user the de nition of refactoring actions.
In the model-based context, di erent approaches have been published, which share the characteristic of being user-driven. EMF Refactor [5] provides a suite of well-known refactoring actions by exploiting a statical analysis of the target model and by considering design quality metrics. Operation Recorder [8] allows to derive model refactoring, based on model di erences, by applying a pattern matching algorithm on source and refactored models. With respect to these approaches, we natively enable the speci cation of sequences of refactoring actions.
Our approach borrows some concepts from code refactoring approaches [17,20], by providing support to specify and verify preand postconditions of model refactoring actions and to automatically derive and verify pre-and postconditions for sequences of refactoring actions.
Fowler et al. have introduced in [10] a cornerstone for code refactoring. They have presented a dictionary of refactoring actions, which helps developers in selecting the most valuable actions that solve their issues.
Ouni et al. have presented an approach for xing code smells by suggesting design patterns [21]. They have used a multi-objective function to drive the search within the solution space. By exploiting the QMOOD (Quality Model for Object-Oriented Design) [6] model, they are able to calculate the e ectiveness of each refactoring action on the quality of the source code. Moreover, for each refactoring operation they have used a pre-condition style as Opdyke had introduced in [20]. Basically, our approach takes into account the last aspect, by trying to formalise the Opdyke's concepts in a modeldriven refactoring environment.
The main di erences between code-based and model-based refactoring come form the di erent nature of the refactoring targeted artefacts.
The main issue in model-based refactoring is to maintain the conformance among views. For example, a refactoring action might directly change a view (e.g. static view), but it might indirectly involve other views (e.g. the behavioral one). Mansoor et al. have presented an example that intends to address this issue [15], as they have proposed a solution for maintaining intra-view conformance. In this direction, our approach provides a solution in which we can verify the feasibility of the sequence by evaluating the postcondition of a refactoring sequence.

METAMODEL FOR MODEL REFACTORING
In this section, we describe the core of our work by: (i) introducing the metamodel for model refactoring (Section 3.1), and (ii) describing the metamodel facilities that we provide for enabling users to "plug" refactoring actions into a language-dependent context, thus inducing pre-and post-conditions support within the target modelling language (Section 3.2).
Several model-based refactoring approaches exist in literature, but none of them is based on a general metamodel that supports refactoring feasibility in multiple modeling languages. In fact, our metamodel has to be intended as an instrument that allows to generate a set of facilities (data-structures and algorithms) that ease the veri cation of refactoring applicability, as described in the remaining of this section.

Metamodel Description
Our metamodel has been de ned within the Eclipse Modelling Framework [22], hence it basically consists of an (annotated) ecore le accompained by a .genmodel le that allows to generate all the required facilities. Figure 1 depicts the metamodel big picture.
The Refactoring metaclass (bottom-left of Fig. 1) represents the root, although we would not generate any model out of this metamodel, as intended in a "pure" MDE context. In fact, keyapplications of our framework fall within contexts where a large number of refactoring action sequences have to be automatically generated, applied and veri ed, as for example in multi-objective optimization contexts [2].
A Refactoring may contain: • A sequence of refactoring Actions, namely actions; • A Precondition and a Postcondition, both representing the general concept of Condition, which basically contains a logical formula in rst-order logics, namely FOLSpecification (see the conditionFormula reference). Refactoring Preand Post-Conditions are derived from Preand Post-Conditions of the Actions composing the Refactoring.
The concepts of pre and post-condition are borrowed from theoretical code-based aspects initially presented by Opdyke [20], and successively improved by Ó Cinnéide et al. [17]. In the latter, the feasibility of a sequence of refactoring actions (i.e. a Refactoring) is guaranteed if and only if the conditions of each action do not break the applicability of the remaining actions in the sequence. In practical terms, the precondition of the rst action has to be veri ed, then its postcondition does not have to break the precondition of the second action in the sequence, and so on, for each action in the sequence.
For example, let us de ne the following refactoring actions in a UML context: (1) moveComp(c : Component, T : Set(Node)), which re-deploys a Component, namely c, to a given set of target Nodes, namely T.
Their pre-and post-conditions, namely pre 1 , post 1 , pre 2 and post 2 , would be as follows: the set of all the Components and Nodes in the UML model, respectively. Hence, pre 1 checks the existence of the moved Component and each selected target Nodes.
where C and N are the set of all the Components and Nodes in the UML model, respectively, whereas D is the set of deployment Nodes of c, after the application of moveComp. Hence, post 1 is similar to pre 1 , but it additionally checks that the moved Component is actually deployed to the selected target Nodes.
where C is the set of all the Components in the UML model. Hence, pre 2 checks the existence of Component to be deleted.
where C is the set of all the Components in the UML model, after the application of moveComp. Hence, post 2 checks the non-existence of the deleted Component.
Given the refactoring actions above and their pre-and postconditions, the sequence mo eComp(c1,T 1) → deleteComp(c1) would be feasible, because post 1 (applied to the instances c1 and T1) does not break pre 2 (applied to c1), i.e. c1 still exists after having been moved and it can be thus deleted. Conversely, the sequence deleteComp(c1) → mo eComp(c1,T 1) would not be feasible, because post 1 (applied to c1) breaks pre 2 (applied to c1 and T1), i.e. c1 does not exist anymore after having been deleted, hence it cannot be moved.
Providing a language-independent automated support for a priori verifying the feasibility of refactoring action sequences, through the mechanism exempli ed above, lls an important lack in the context of model-based refactoring, which is often conceived as a user-driven activity, i.e. semi-automated. In fact, such an automated support paves the way to approaches that automatically generate (and possibly suggest) design alternatives resulting from the application of di erent refactoring action sequences, e.g. search-based approaches based on multi-objective optimization such as [2,15,21].
An Action exposes four public methods, which must be implemented to exploit the framework for a speci c modelling language ( 2 ): i) execute, ii) setParameters, iii) createPreCondition and iv) cre-atePostCondition. The latter two methods allow to de ne the preand post-conditions that must be validated before (i.e. pre-) and after (i.e. post-) the action is executed, by invoking the method execute. However, in order to create a Condition for an Action, its Parameters have to be set by overriding the setParameters method. Parameters are used to "resolve" model elements involved in Conditions, through the resolvingExpr strings that are assumed to be conform to the OCL grammar (i.e. they must express OCL queries), as described later in this section. There are two types of Parameter: SingleValued and MultipleValued. The former type is used to resolve a single model element, whereas the latter is used for resolving a set of model elements. Parameters may properly recur within a FOLSpecification as operands of the Operators that compose the speci cation. In fact, a FOLSpecification contains a root, namely rootOperator, which represents the rst Operator that, in turn, may contain other Operators, and so on. As a result, a FOLSpecification is expressed in a functional-like notation by using the available kinds of Operators. Currently, LogicalOperators have been de ned, as: Exists, ForAll, Not, And, Or. However, the metamodel de nition is open to the introduction of other operators, if needed, such as operational ones.
Note that, di erent representations of FOLSpecification would have been possible, e.g. as a set of atomic expressions which are rstly declared and then composed by means of operators. However, for sake of simplicity, we have opted for the one presented here.
Equation (1) describes a minimal example of FOLSpecification, where the existence of a speci c model element, resolved through the getCompToMoveSVP SingleValuedParameter, has to be veried within the set of all the UML Components, which is retrieved via the getAllCompsMVP MultipleValuedParameter. Practically, the FOLSpecification will be composed by only one ExistsOperator with getCompToMoveSVP as element and getAllCompsMVP as collection.

Main Facilities for Language-Speci c Contexts
As mentioned before, our metamodel is an instrument that allows to generate a set of refactoring support facilities. In this section, we describe what a user is expected to do in order to exploit such refactoring facilities with the aim of "plugging" the metamodel into a speci c modelling notation (e.g. UML [19]). We remark that Action represents a key anchor point, because a user must implement her refactoring actions, by overriding the four declared Action methods, in order to apply the metamodel to a speci c modeling language. As from Fig. 2, the metamodel provides an ad-hoc class, namely Manager, that exposes all the facilities needed for such purpose.

Manager Facilities.
Manager provides many methods, spanning from objects initialization and creation (e.g. of FOLSpecifications, Single and MultipleValuedParameters, Pre and Post-Conditions, Operators) to conditions comparison, processing and evaluation. Fig. 2 depicts a minimal but signi cant subset of such methods, which are described in the following to clarify the fundamental role played by Manager: • calculatePreCondition is in charge of deriving the PreCondition of the Refactoring, passed as input to the method, by exploiting an ad-hoc version of the approach by Ó Cinnéide et al. [17] that we have implemented for our purposes. • calculatePostCondition is in charge of deriving the PostCondition of the Refactoring, passed as input to the method, analogously to calculatePreCondition. • evaluateFolSpeci cation veri es a FOLSpecification against a contextual model element passed as input parameter, which has to be retrieved and properly cast, based on the target modelling language. Moreover, Manager has three fundamental references to di erent kinds of managers, aimed at tailoring to a speci c modelling language, namely: MetamodelManager, OclManager and OclString-Manager. To this aim, a user has to extend and implement her own version of the latter managers, as described in the following.

MetamodelManager.
MetamodelManager handles ordinary activities on a target modelling language. Two methods need to be overridden by a user extension of this class, i.e. init and packageRegistering. The former has to initialise all paths of the artefacts needed for dealing with models conforming to the target metamodel. For example, the path of the source model onto which a Refactoring has to be applied, and thus pre-and post-conditions have to be derived and veri ed, as well as additional resources and resource sets ( 3 ) have to be de ned in the init method. The packageRegistering method, instead, is responsible for the registration of all the necessary packages into the EMF registry, and it has to be properly called by init to enable the creation of required resources.

OclManager.
OclManager is in charge of performing OCL queries and handling their results, within the context of the target modeling language. Notice that OCL query results return Objects, HashSets of Objects, or Java Generics (not shown in Fig. 2), which need to be properly cast before being returned to the caller. For this reason, the user is required to extend OclManager with her own manager, by providing tailored implementations of its predeclared methods.

OclStringManager.
As mentioned before, parameters are used to resolve model elements involved within conditions. Although this appears as a restricting assumption, it simpli es the management of such strings. As alternative, in fact, OCLExpressions ( 4 ) rather than strings should be used, thus resulting in a higher complexity. However, in both cases, the user is required to know OCL, hence we have opted for introducing such assumption in favour of simplicity. 3  That said, OCLStringManager itself does not provide any method, hence the user has to implement all the necessary OCL queries within a tailored extension of it. Each method has to return a prede ned query, and all queries will be available to use by setParameters methods of the de ned refactoring actions. When the FOLSpecification of a Condition for an Action has to be evaluated against a model, all the needed Parameters are set by construction, thus each OCL query can be evaluated to properly resolve the model elements involved in the condition.
Finally, we remark that the basic idea behind such mechanism for resolving model elements, grounded on a single class that provides all the needed strings, is borrowed from the Android string resources system, which can be queried in order to obtain text strings with optional text styling and formatting for the labels of an application ( 5 ).

APPLYING THE METAMODEL TO AN EXAMPLE MODELING LANGUAGE : UML
In this section, we illustrate the application of our metamodel to a speci c modeling language. We have recently applied refactoring action sequences automatically, in two di erent model-based contexts, that are: i) an Epsilon-based approach, where di erent kinds of refactoring sessions on UML-MARTE models [18], aimed at detecting and removing performance antipattern occurrences, can be executed by exploiting the di erent execution semantics of Epsilon languages [2]; ii) a multi-objective optimization approach, where alternative sequences of refactoring actions on AEmilia architectural speci cations [7,9] are automatically obtained as the near-Pareto front of a tness function that considers design aspects (i.e., number of changes) and performance ones (i.e. number of performance antipattern occurrences and a performance quality indicator) [3]. For this reason, in this section we opt for providing a thorough usage example of our metamodel facilities within one of these contexts, i.e UML-MARTE, rather than showing the e ects of refactoring actions on modeling examples. However, readers interested to this aspect can refer to the works mentioned above.

UmlAction
Let us consider a refactoring Action, namely UmlMoveComponent, which takes as input a UML Component, namely compToMove, and a list of Nodes, namely targets, and deploys the former to the latter. As mentioned before, the Java implementation of the action has to be introduced within the execute method. While implementing an action, a user has to de ne attributes representing its Parameters that will be subsequently set within the setParameters method. Listing 1 shows an excerpt of an implementation of the setParameters method conceived for the UmlMo-veComponent refactoring action. In particular, it shows how to set the following Parameters: • compToMoveSVP, whose resolvingExp retrieves the Component to move (line 2). The resolvingExpr is set through the get-CompQuery method. getCompQuery ( compToMove ) ) ) ; 3 setAllCompsMVP ( Manager . getInstance () . createMultipleValuedParameter ( UmlOclStringManager . getInstance () . getAllCompsQuery () ) ) ; 4 setTargetNodesMVP (... getNodesQuery ( nodes ) ) ) ; 5 setAllNodesMVP (... getAllNodesQuery () ) ) ; 6 ... 7 } • allCompsMVP, whose resolvingExpr retrieves all the Components within the system model (line 3). The resolvingExpr is set through the getAllCompsQuery method. • targetNodesMVP, whose resolvingExpr retrieves all the Nodes to which compToMove has to be moved (line 4). The resolving-Expr is set through the getNodesQuery method. • allNodesMVP, whose resolvingExpr retrieves all the Nodes within the system model (line 5). The resolvingExpr is set through the getAllNodesQuery method. The resolvingExprs above must be provided by a properly tailored OclStringManager, namely UmlOclStringManager (lines 4-15 and 16-18 of Listing 6).
Once action parameters have been set, they can be retrieved through the proper getters, e.g. getTargetNodesMVP() and getAllN-odesMVP(), in order to de ne action pre-and post-conditions. Hence, using such a notation, the PreCondition of UmlMoveComponent should verify the following rst-order logics formula: This pre-condition checks the existence of: (1) the Component to move (i.e. getCompToMoveSVP()) within the set of all the Components (i.e. getAllCompsMVP()); (2) each target deployment Node for the Component to move (i.e. getTargetNodesMVP()) within the set of all the Nodes (i.e. getAllNodesMVP()).

UmlMetamodelManager
As said in Sec. 3.2.2, a MetamodelManager has to handle the ordinary activities on a target modelling language. Two methods have to be overridden by a potential UmlMetamodelManager, namely init and packageRegistering. An example of the former is reported in Listing 4 (lines 1-7), where the model URI is set (line 2), all the needed packages are registered (line 3), the UmlOclManager is initialized (line 4) and, nally, resources are properly set (line 5) and the model is stored in ad-hoc variable (line 6). Note that the code not shown here, i.e. packageRegistering() method, works on UML models pro led with MARTE that are out of the scope of this paper.

UmlOclManager
As said in Sec. 3.2.3, an OclManager has to handle OCL queries execution and their results. Methods of OclManager have to be implemented by a potential UmlOclManager. For sake of paper readability, we do not report here a complete example, however a minimal excerpt for an evaluateOCL method is reported in Listing 5, where an OCL object and an OCLHelper ( 6 ) are instantiated (lines 6 From org.eclipse.ocl.helper. ... 8 Query < EClassifier , EClass , EObject > q = ocl . createQuery ( helper . createQuery ( query ) ) ; 9 return q . evaluate ( contextualElement ) ; 10 } 2-3), the query context is set by properly checking the type of the contextual element (lines 4-7) and, furthermore, an OCL Query to evaluate is properly obtained (line 8). The latter is nally evaluated and the result of such evaluation is returned (lines 9-10). Note that, the code not shown here (line 7), performs further checks of the contextual element type (e.g., Component, Node) in order to properly set the helper context.

UmlOclStringManager
As said in Sec. 3.2.4, OCLStringManager itself does not provide any method, hence the user has to implement all the necessary OCL queries, for example within a UmlOclStringManager. Each method has to return a prede ned query, and all queries will be available to the setParameters method of the UmlMoveComponent refactoring action. Listing 6 reports sample code for some methods of a UmlOclStringManager, in particular: • getCompQuery (lines 1-3), which retrieves the Component to move, passed as input, if the PaRunTInstance stereotype (from PAM package of MARTE pro le) is applied. • getAllCompsQuery (lines 4-6), which retrieves all the Components with the PaRunTInstance stereotype applied. • getNodesQuery (lines 7-17), which retrieves all the Nodes with the GaExecHost stereotype (from GQAM package of MARTE pro le) applied, among the ones passed as input. • getAllNodesQuery (lines [18][19][20], which retrieves all the Nodes with the GaExecHost stereotype applied.
A critical point is that the user is in charge of writing her preand post-condition as OCL statements, thus she needs to acquire con dence with OCL that, however, is one of the most widely adopted languages in the MDE environment.
As mentioned in Sec. 4, we have recently introduced automation in the application of refactoring action sequences in two modelbased contexts, i.e. UML and AEmilia. Here, we have illustrated the application of our metamodel to the UML case.
Our primary objective in the near future is to extend this metamodel to enable the speci cation of performance antipatterns detection rules and their veri cation against a model. To this aim, we shall need to include relational operators for comparing numerical values retrieved through the resolving expressions of singleand multiple-valued parameters. Relational operators would allow our metamodel to potentially provide a complete support to the speci cation and veri cation of rst-order logics formulae, independently from the fact that they represent pre-and post-conditions or performance antipatterns detection rules.