Propagating Model Refactorings to Graph Transformation Rules

Sabine Winetzhammer and Bernhard WestfechtelChair of Applied Computer Science 1 - Software Engineering,

University of Bayreuth,Universitatsstraße 30, 95440 Bayreuth, Germany

{sabine.winetzhammer, bernhard.westfechtel}@uni-bayreuth.de

Keywords: Refactoring, Graph Transformation Rules, ModGraph.

Abstract: Model-driven software engineering reduces the effort of developing software by replacing low-level program-ming with the construction of high-level executable models. Refactoring improves the structure of softwareartifacts without changing external behavior. Originally, refactoring was developed for and applied to (object-oriented) programs. In the context of model-driven software engineering, refactoring has to be applied to bothstructural and behavioral models. In this paper, we present tool support for model refactoring in ModGraph,a tool which employs Ecore class diagrams for structural modeling and graph transformation rules for be-havioral modeling. In particular, we focus on the propagation of refactorings of the structural model into thebehavioral model.

1 INTRODUCTION

Model-driven software engineering reduces theeffort of developing software by replacing low-levelprogramming with the construction of high-level exe-cutable models. To this end, both structural and be-havioral models have to be developed. In the con-text of object-oriented modeling, there seems to bea general consensus to employ some variant of classdiagrams for structural modeling, e.g., EMF, MOF,or UML class diagrams. In contrast, there is a widespectrum of languages for behavioral modeling whichare based on different computational paradigms (e.g.,state machines, activity diagrams, or rule-based trans-formation languages). In this paper, we will focus onbehavioral modeling with graph transformation rules:Models are considered as graphs, and transformationsof these graphs are specified declaratively by graphtransformation rules.

Software evolution is a discipline which providesconcepts, methods, and tools for evolving software inresponse to changing requirements, platforms, tech-nologies, etc. In the context of object-oriented soft-ware development, evolution support is provided ina variety of different ways, including e.g. designpatterns and refactorings, both of which facilitatechanges to the software. According to (Fowler, 1999),refactoring denotes the activity of restructuring soft-ware by applying a series of transformations withoutaffecting its externally observable behavior.

The transformations proposed in (Fowler, 1999)were developed for and applied to (object-oriented)programs. In the context of model-driven software en-gineering, refactoring has to be applied to both struc-tural and behavioral models. Previous work on modelrefactoring focused on structural models (Biermannet al., 2006; Mens, 2005; Mens et al., 2007). How-ever, when the structural model is refactored, the re-spective changes have to be propagated into the be-havioral model; otherwise, the behavioral model is nolonger consistent with the structural model.

In this paper, we close the gap identified above,resulting in comprehensive support for model refac-toring. We present tool support for model refactoringin ModGraph1, a tool which employs Ecore class dia-grams for structural modeling and graph transforma-tion rules for behavioral modeling. For the structuralmodel, ModGraph offers a set of refactoring trans-formations along the lines of Fowler’s work (Fowler,1999). The tool support goes beyond previous worksince the refactorings are propagated from the struc-tural model into the behavioral model. Thus, graphtransformation rules are updated in response to thechanges of the underlying Ecore model.

Altogether, our work provides an important con-tribution to model evolution, which is an essential pre-requisite for putting model-driven software engineer-

1http://btn1x4.inf.uni-bayreuth.de/modgraph/homepage

a:EAttribute

C2: EClass

C1: EClass

GT RHSLHS

a:EAttribute

C2: EClass

-- C1: EClass

GT ++

a:EAttribute

C2: EClass

C1: EClass

Figure 1: A graph transformation rule shown as divided view and merged view.

ing to work. The term model evolution is used in a va-riety of different contexts. Frequently, model evolu-tion is concerned with the changes of model instancesin response to changes of the underlying metamodel(Rose et al., 2010) (analogously to schema evolutionin databases (Banerjee et al., 1987)). In contrast, thework presented in this paper has a different focus: Itdeals with the consistent refactoring of a set of in-terdependent models, which requires propagation ofthe changes of the structural model into the behav-ioral model. The migration of model instances is notconsidered here.

The rest of this paper is structured as follows: Sec-tion 2 explains the context in which this work wasperformed. Section 3 provides an overview of our ap-proach to refactoring both structural and behavioralmodels. Section 4 describes the implementation. Sec-tion 5 illustrates this approach by several examples.Section 6 discusses related work. Section 7 concludesthe paper.

2 BACKGROUND

The work reported in this paper was carried out inthe context of the ModGraph project (Winetzhammer,2012). ModGraph is a tool for model-driven soft-ware engineering which is based on the Eclipse Mod-eling Framework (EMF, see (Steinberg et al., 2009)).Structural modeling is performed with Ecore. Thus,a structural model consists of a set of classes owningstructural and behavioral features. Structural featuresare partitioned into attributes, which have (collectionsof) simple values, and references to target classes. Bydefault, references are uni-directional (from instancesof the source class to instances of the target class);however, a pair of uni-directional references may begrouped into a bi-directional reference. Behavioralfeatures are modeled by operations.

The structural model merely describes the signa-ture of operations, but not their behavior. In Mod-Graph, the behavior of an operation may be specifieddeclaratively by a graph transformation rule. Modelinstances are considered as graphs whose nodes andedges correspond to objects and links, respectively.

A graph transformation rule describes an in-placemodel transformation and essentially consists of aleft-hand side and a right-hand side, like the oneshown on the left-hand side of Figure 1 to move anattribute from one class to another. The left-hand sidedescribes the subgraph to be searched (the match forthe rule). Here the classes and the attribute that shouldbe moved are located. The right-hand side speci-fies the subgraph which replaces the left-hand side.In case of Figure 1 the attribute references the otherclass. The left-hand side and the right-hand side maybe merged into a single diagram, as shown in Figure1 on the right-hand side. Elements belonging only toone side need to be marked: only left-hand side ele-ments are colored red and marked --, only right-handside elements are colored green and marked ++.

ModGraph uses the merged view. An example isgiven in Figure 4. In ModGraph single and doubleboxes represent single objects and sets of objects, re-spectively. The current object on which the operationimplemented by the graph transformation rule is in-voked is designated by the inscription this. Arrowsrepresent links, i.e., instances of references. Con-ditions on and modifications of attribute values areshown in the Constraints and Changes compartmentsof the boxes for objects. Nodes designated as optionalare not required for the rule to match. According tothe merged view, insertions and deletions of objectsand links are represented by coloring the respectivegraphical elements in green and red, respectively, aswell as markers ++ and -- are placed inside the boxesfor objects and near to the arrows for links. The mean-ing of the graph transformation rule shown in Figure 4will be described later.

Altogether, the ModGraph tool has to deal withdifferent types of models, as illustrated in Figure 2.The blue boxes represent the models which are cre-ated by the ModGraph user: The structural modelis defined by an Ecore class diagram. The behav-ioral model consists of a set of graph transformationrules specifying the behavior of operations introducedin the structural model. At runtime, graph transfor-mation rules will be applied to model instances bymatching and replacing subgraphs. Internally, a graphtransformation rule is represented as a model, too

Ecore Metamodel

Graph Transformation Metamodel

Instance

EcoreModel

instance of

instance ofGraph Transformation 

Rule

instance of

update

instance of

references

matches / transforms

Figure 2: The problem statement.

(namely an instance of the graph transformation meta-model, which in turn is an instance of the Ecore meta-model).

According to (Fowler, 1999), refactoring denotesthe activity of restructuring software by applying aseries of transformations without affecting its exter-nally observable behavior. Fowler’s book containsa bunch of refactoring transformations, all of whichrefer to the source code. For each refactoring, thefollowing information is supplied: the preconditionunder which the refactoring may be applied, the el-ementary steps of the core refactoring, the impactof changes on dependent model elements, and thepostconditions which hold after the refactoring. Therefactoring transformations vary in their complexityand range from simple ones such as renaming an at-tribute to complex refactorings such as pulling up anattribute from all subclasses to a common superclassand extracting a class from a given class by moving apart of its features to the extracted class.

In this paper, we discuss refactorings of modelsrather than refactoring of source code. More specifi-cally, we focus on models created by ModGraph users(blue boxes in Figure 2). Thus, we consider thefollowing problem: Let us assume that a consistentmodel is given, being composed of a class diagramand a set of graph transformation rules. The graphtransformation rules are typed with the elements ofthe structural model. ModGraph ensures that typingis consistent: The class of an object must be defined inthe class diagram, the attributes occurring in the ob-ject’s compartments must be owned by that class, etc.Now, the ModGraph user would like to apply a refac-toring transformation to the overall model. To thisend, the structural model has to be changed and thechanges must be propagated into the graph transfor-

mation rules such that consistency is re-established.

3 PRELIMINARYCONSIDERATIONS

As the last section described EMF and Mod-Graph graph transformation rules as well as their in-terplay, this one focuses on problems concerning thegraph transformation rules co-occurring within refac-toring the EMF model. Figure 2 shows the meta-relationships between the models (blue, rounded ar-rows), as well as the interplay between EMF andModGraph (black, bold arrows). ModGraph is deeplyrooted in the EMF world, taking a look at the meta-relationships between the models. Each graph trans-formation rule (Figure 2, blue box on the right) is aninstance of the graph transformation meta model (or-ange box on the right) which was built with EMF us-ing the Ecore metamodel (green box on the left). Thismetamodel also serves as metamodel for Ecore classdiagrams (blue box on the left) . Those class diagramsmay be instantiated (black box on the left).

The graph transformation rule interacts with themodel and the instance. The first interaction is causedby the fact that each graph transformation rule imple-ments an operation in the Ecore class diagram. There-fore it references this operation as well as its con-taining class. The second interaction takes place in-side the rule: A ModGraph rule changes instances ofthe Ecore model by matching structures and applyingchanges. The components inside the rule reference el-ements of the structural model, e.g. an object in a rulemust reference an EClass inside the Ecore model, alink has to reference an EReference.

Meta‐Rule / Xcore Operation 

Instance

EcoreModel

Graph Transformation Rule

references

matches / transforms

Transformation (Rule)Perform a refactoring!

Interdependent set of models

refactor refactor

callrefactoring

propagatechanges

Figure 3: Interaction of the refactoring engine with the affected models.

These two dependencies are shown as black, boldarrows named ”references” and ”matches / trans-forms” in Figure 2. A full overview of the dependen-cies between a rule and the structual model is givenin (Buchmann et al., 2012) with an explanation of theModGraph metamodel for graph transformation rules.

Within a static context, this kind of model exe-cution will probably never cause any problems. Butmany models evolve in time: elements are renamed,references are re-targeted and classes are inlined orextracted in order to create or collapse inheritance hi-erarchies or just to improve the model - in short: themodel is refactored. Regarding only Ecore models,applying these refactorings is well understood and im-plemented in several ways, as we will show in Sec-tion 6. The problem is caused by the strong intercon-nection between a rule and the Ecore model. If anyelement is just referencing the refactored model ele-ment, after refactoring, this reference is unset. Hence,the rule is invalid because of inconsistencies betweenthe rule and the model, which will be eliminated byour approach. We propose to propagate refactoringsto rules, with the help of rules, as shown in Figure 3.We use two steps: First we call the modeled refac-toring rules, second we propagate the refactoringsperformed by these rules to the graph transformationrules belonging to the refactored static model by usingmostly meta-rules. That way we provide refactoringon graph transformation rules executed by other graphtransformation rules, we call meta-rules.

Our approach starts with Fowler’s definition ofeach refactoring. As these definitions were introducedfor the refactoring of (object oriented) code, we adaptthe definitions for Ecore model refactorings. Subse-quently we investigate how the changes affect Mod-Graph rules. Here we consider different aspects con-cerning the structure of the rule. Depending on the el-

ement the changes may cause minor or major changesto be performed inside the rule. Table 1 shows some.One may classify the affected rule elements as shownin the first column: the whole rule, nodes (repre-senting single- and multi-valued objects and param-eters), attributes, links (instances of references), andtextual conditions (e.g. pre- and postconditions, at-tribute conditions), as well as fields (e.g. operationcalls). The result of this step is taken to propagatethe changes to the rules. The change may be a simplesetter call on the graph transformation rule or restruc-turing of the rule itself, as Section 5 will show.

The rule as a whole references an operation and itscontaining class. Hence changes performed here needto be propagated. A rule is superseded if the operationis deleted. If the class is deleted, the rule may be as-signed to another class where a similar operation shalltake place now or is also deleted. A node referencesa class. It needs to be updated whenever the classchanges. If for example the class is renamed, the nodeneeds to be retyped. If the class is made abstract, thenode will be deleted if its status is CREATE. For anyother status it will be retyped. Attributes are an essen-tial part of a rule. They may be used to add conditionsto nodes as well as for assignments. Each attribute in arule references an attribute in the Ecore model. There-fore an attribute in a rule needs to follow the attributein the class. Renaming and moving may be executedwithout problems, but retyping is quite interesting: Ifan attribute is retyped in the Ecore model and usedinside a graph transformation rule the user has to as-sign its new value manually. Furthermore attributesmay be moved and links be re-targeted. In both casesthe refactoring tries to locate an instance of the newcontainer / target of the attribute / link and to move /re-target the attribute / link, respectively. If this failsthe attribute / link is deleted. For the textual parts of

Table 1: Effects of model changes on different classes of rule elements.

Affected rule element Change in Ecore model Change modeled in meta-ruleClass

rename adapt references to classdelete adapt references to class, if not successful: delete

Whole rule make abstract adapt references to class

Operationrename adapt references to operationdelete deleteClass

Nodes rename retypedelete delete

make abstract retype or deleteAttribute in Class

rename adapt nameAttributes move try to move, if not successful: delete

retype retype and assign new valuedelete delete

ReferenceLinks rename adapt name

retarget try to retarget, if not successful: deletedelete delete

Textual conditions, any change parse condition and propagate re-paths and fields factoring, if refactored element is found

the rules exists no other way than parsing them to findthe elements referred and to adapt them using namingconventions.

4 IMPLEMENTATION

The refactoring is implemented using Mod-Graph/Xcore2 and Java to implement connectors us-ing extension points. For the static structure, wemainly use two classes in an Xcore model: Refac-toring, to specify the refactorings on the model (asstarted in (Dummel, 2013)), and Propagation, to prop-agate the changes caused by them.

As we want to use the added value of rules only,each refactoring on the model is specified inside agraph transformation rule or an Xcore operation, de-pending on its complexity. We will see in detail inSection 5, that the change of a bi- to a unidirectionalreference is modeled very well with rules, while re-naming an element in the model can be written easilyin a few lines inside an Xcore operation. Please note,that these refactorings are universal. They also workfor Ecore models outside the ModGraph context.

2The approach to use ModGraph and Xcore is describedin (Winetzhammer and Westfechtel, 2013) and (Winet-zhammer and Westfechtel, 2014).

The propagation of changes to ModGraph rulesfollows the same scheme. A complex propagation ismodeled as a rule, using Xcore as control flow lan-guage, if necessary. A simple propagation is modeledas an Xcore operation. In Section 5, examples forpropagations are shown.

As a final step of propagation, all rules changedare validated in order to secure their navigability.Navigability means, that each single- or multi-valuedobject needs to be reachable by navigating links start-ing from the current object or a single- or multi-valued parameter of the operation. If the validationfails the user needs to adjust the rule manually. Thatway, rules which are no more navigable after apply-ing the refactoring will be marked for further manualchanges.

The rest is implemented in Java: We extend apopup-menu in order to be able to call the refactoringin the model and call the refactoring rule implementa-tion (written in ModGraph/Xcore). After successfullyexecuting this one, we call the propagation implemen-tation (written in ModGraph/Xcore), that propagatesthe changes to the rules. The propagation locates therules, parses and fixes them as shown in the next para-graph. The result is a complete model evolution.

We implemented the following refactorings andtheir propagations. A validation of the rules is per-

formed after each refactoring.

Rename element: Renames an ENamedElement.Propagates the new name to the corresponding el-ements in the rules. (See Section 5)

Add parameter: Adds an EParameter to an EOp-eration. Propagate to implemented operation andtextual fields, especially to operation calls, in arule. Both need to be adapted.

Remove parameter: Removes an EParameter froman EOperation. Propagation: Removes the param-eter from the rules, updates textual fields, espe-cially operation calls.

Change value to reference: Updates the contain-ment hierarchy. Propagation: Validate rules in or-der to check exclusiveness.

Change reference to value: Updates the contain-ment hierarchy. No propagation.

Change bi- to unidirectional reference: Removesan EReference. Propagation: Exchanges each linktargeting the deleted reference by a link targetingits former opposite reference. (See Section 5)

Change uni- to bidirectional reference: Adds anEReference and sets its EOpposite. No propaga-tion.

Extract class: Extracts an EClass from a givenEClass and relates them using an EReference.Propagation: If a node references the given class,check if it uses attributes, operations or referencesmoved to the extracted class. If yes, create anew node referencing the extracted class and re-late both using a link which is an instance of theEReference relating the classes. Move the ele-ments referencing the extracted class to the newlycreated node.

Extract subclass: Extracts a subclass from a givenclass. Propagation: If operations, attributes orreferences are moved, retype the nodes referenc-ing the class and using one of the operations, at-tributes or references to be typed over the sub-class.

Extract superclass: Extracts a superclass from agiven class. No propagation, because of inheri-tance.

Inline class: Inlines a class into another class. Prop-agation: Retype all nodes typed over the inlinedclass to the class in which it will be inlined.

Move attribute / operation: Moves the attribute /operation from a source to a target class. Propa-gation: If the rule contains two nodes referencingthe source and target class move the usage of the

attribute / operation. In all other cases delete theusage.

Pull up attribute / operation: Moves the attribute /operation to the super class. No propagation, be-cause of inheritance.

Push down attribute / operation: Moves the at-tribute / operation to the subclasses. Propagation:If there is a node typed over the super class us-ing the pulled down attribute / operation, ask userto which subclass it shall be retyped and performthis.

Replace subclasses with fields: Creates an enu-meration with one literal for each subclass andan attribute typed over the enum in the super-class. Propagation: Replace the nodes typed overthe subclasses by nodes typed over the superclasswith the corresponding literal assigned.

Hide delegate: Removes the direct EReference be-tween two EClasses. Propagation: Delete corre-sponding links in rules.

Remove middleman: Creates a direct EReferencebetween two EClasses. Propagation: Create thecorresponding link, if the rule contains two nodesreferencing the classes.

Replace inheritance with delegation: Replace theexisting generalization with an EReference. Prop-agation: If both classes are referenced by nodesinside a rule create a link referencing the ERefer-ence.

Replace delegation with inheritance: Replace anexisting EReference with a generalization. Prop-agation: Remove the link referencing the ERefer-ence.

5 EXAMPLES

The general idea of propagating model refactor-ings on interdependent models is now concretelyshown considering the refactoring change a bi-directional to a uni-directional reference in detail. Therefactoring to rename an element is sketched by thespecial case of renaming a class.

5.1 Change a Bi- to a Uni-DirectionalReference

The refactoring we consider here in detail is chang-ing a bi- to a uni-directional reference. Starting withFowler’s definition (Fowler, 1999), we provide theimplementation of the model change as well as themeta-rule to propagate the changes.

Figure 4: Rule for changing a bi- to a unidirectional reference in an Ecore class diagram.

Figure 5: Rule propgagating a change of a bi- to a unidirectional reference in an Ecore class diagram to graph transformationrules. The numbers must be replaced by the corresponding OCL conditions shown in Listing 1.

Fowler defines this refactoring as follows: ”Youhave a two-way association but one class no longerneeds features from the other.”(Fowler, 1999) ForEMF this means, that a reference with an oppositeset is deleted. The rule to perform the operation inthe Ecore model is shown in Figure 4. Here a refer-

ence called reference2 (red box, marked with --) isdeleted within all its links (red arrows, marked with--) to classes as well as its opposite relation to theother reference, called formerOpposite.

To propagate this refactoring, we use an Xcoreoperation and two meta-rules. The meta-rule shown

Figure 6: Graph transformation rule before and after in-voking the refactoring change bi- to uni-directional refer-ence on the model. toS and toP are instances of the equallynamed references in the model, which are opposed.

in Figure 5 shows the application of the refactor-ing propagation to links in the Graph Pattern. Themeta-rule for the negative application conditions isstructured analogously and therefore not shown here.These two meta-rules are applied to all rules belong-ing to the refactored model using an Xcore imple-mented operation. First, the operation loads the wholerule, second it calls both meta-rules, third it updatesthe diagram for the rules and finally it saves the mod-ified resource.

In the meta-rule the deleted reference is located.Each link, called delLink in Figure 5, is referencingthe deleted reference and is therefore deleted. A newlink, called link in Figure 5, is created as an instanceof the former opposite of the deleted reference. Thenumbers next to the paths in the rule represent OCLpath expressions, shown in Listing 1. They ensureconsistency for pattern matching. No. 1 and 2 en-sure that the nodes node1 and node2 are referencingthe classes between which the refererences has beendeleted. No. 3 and 4 ensure that a link, referencingthe deleted reference exists in the rule.

The refactoring is applied to a test project. Themodel contains a bidirectional reference modeled astwo EReferences called toS and toP, which are set asEOpposite to each other. The project also contains aset of graph transformation rules. One of the rules isshown in the upper part of Figure 6, where an instanceof a parameter p shall be deleted. This instance is con-nected using a link, an instance of the toP reference, tothe current object. Now let us assume that the user de-cides toP is no more needed in the class diagram andtherefore calls our refactoring rule to change the bi- toa uni-directional reference. toP is removed from thestructural model. Also our propagation mechanismchanges the rules. The result for our example rule isshown on the lower part of Figure 6.

5.2 Rename Element

Renaming an element is a quite common task in pro-gramming and modeling ever since. This is an inter-esting example, as the refactoring for the structuralmodel can be written as a few lines in an Xcore op-eration, but the changes to be propagated to the rulesare not as trivial: As this refactoring may affect allcomponents of an Ecore model, all components ofa rule referencing those may be concerned. Due tothe fact, that elements of a rule reference model el-ements differently, there are a number of renamingpropagations. Starting with the simple part, Listing 2shows the implementation for the refactoring of thestructural model. The renamed element as well asits new name are given as a parameter to the opera-tion. First our implementation checks if the element’scontainer already contains any element with the givennew name. If not, the element is renamed.

The rather complex part is the propagation that isdecomposed into several meta-rules and Xcore opera-tions. For the meta-rules we distinguish between eachelement that is referred in the class diagram. Hence,we need at least one rule or Xcore operation to prop-agate the renaming of a class, an attribute, an opera-tion, or a reference.

As an example we consider the propagation of re-naming a class in the Ecore model. The first step is torename the class in the model itself. This is performedby a call for a setter. In the next step all graph trans-formation rules are searched using the criteria shownin Table 2 in the left column. If one of these ques-tions is answered positively, the rule needs to be ad-justed. Depending on which answers were positives,the changes in the right column are applied to the rulein order to get a consistent set of models. Assumethe answer to the first question is yes. The next ques-tion is also answered positively, if the rule containsa current object. Figure 7 shows the meta-rule forthe propagation. The corresponding class of the ruleis set to the renamed one, the current object this isretyped and possible unbound nodes referring to theclass are also retyped directly. Links as instances ofreferences typed over the renamed class are adaptedin an extra meta-rule, which is called by an operationcall in the current object of the meta-rule shown here.The same holds for the operations resetImplemente-dOperation and handleInnerNodes. The first one cor-rects the implemented operation’s path, the latter han-dles attributes in unbound nodes. Textual elementsare handled separately. Please note that retyping byrenewing the type / corresponding class is necessaryhere, as these are inter-model dependencies which arelost by changing the corresponding object.

Listing 1: OCL path expressions for change bi- to unidirectional reference.1 1 : [ ( s e l f . o c l I s T y p e O f ( GTThisObjec t ) and s e l f . oclAsType ( GTThisObjec t)−>2 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =3 f o r m e r O p p o s i t e . eRe fe renceType . oclAsType ( e c o r e : : EClass ) . name ) )4 or ( s e l f . o c l I s T y p e O f ( GPUnboundNode ) and s e l f . oclAsType ( GPUnboundNode)−>5 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =6 f o r m e r O p p o s i t e . eRe fe r enceType . oclAsType ( e c o r e : : EClass ) . name ) )7 or ( s e l f . o c l I s T y p e O f ( GPBoundNode ) and s e l f . oclAsType ( GPBoundNode)−>8 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =9 f o r m e r O p p o s i t e . eRe fe renceType . oclAsType ( e c o r e : : EClass ) . name ) ) ]

10

11 2 : [ ( s e l f . o c l I s T y p e O f ( GTThisObjec t ) and s e l f . oclAsType ( GTThisObjec t)−>12 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =13 f o r m e r O p p o s i t e . e C o n t a i n e r . oclAsType ( e c o r e : : EClass ) . name ) )14 or ( s e l f . o c l I s T y p e O f ( GPUnboundNode ) and s e l f . oclAsType ( GPUnboundNode)−>15 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =16 f o r m e r O p p o s i t e . e C o n t a i n e r . oclAsType ( e c o r e : : EClass ) . name ) )17 or ( s e l f . o c l I s T y p e O f ( GPBoundNode ) and s e l f . oclAsType ( GPBoundNode)−>18 e x i s t s ( e | e . t y p e . oclAsType ( e c o r e : : EClass ) . name =19 f o r m e r O p p o s i t e . e C o n t a i n e r . oclAsType ( e c o r e : : EClass ) . name ) ) ]20

21 3 : [ s e l f . e l e m e n t s −>s e l e c t ( n | n . o c l I s K i n d O f ( GTNode ) and n . oclAsType ( GTNode ) . ou tgo ingEdges−>22 e x i s t s ( e | e . o c l I s K i n d O f ( GPLink ) and e . oclAsType ( GPLink ) . e x R e f e r e n c e . e I s P r o x y ( ) ) ) ]23

24 4 : [ s e l f . e l emen t s−>s e l e c t ( n | n . o c l I s K i n d O f ( GTNode ) and n . oclAsType ( GTNode ) . incomingEdges−>25 e x i s t s ( e | e . o c l I s K i n d O f ( GPLink ) and e . oclAsType ( GPLink ) . e x R e f e r e n c e . e I s P r o x y ( ) ) ) ]

Listing 2: Xcore implementation of refactoring rename element.1 op void renameENamedElement ( ENamedElement e l e m e n t , S t r i n g newName ) {2 i f ( e l e m e n t . e C o n t a i n e r . e C o n t e n t s . f i l t e r ( e | e . e C l a s s == EClass ) . e x i s t s [ e |3 e . e C l a s s == e l e m e n t . e C l a s s && ( e as EClass ) . name == newName ] ) {4 re turn /∗ and show message ∗ /5 } e l s e {6 e l e m e n t . name = newName7 }8 }

Table 2: Strategy for the rename element refactoring when renaming a class in the structural model.

Does the rule reference this class? Change the reference to the classand retype the current object.

Does the rule contain nodes referencing this class? Retype the node.Do those nodes contain inner nodes Retype them.

referencing contained elements of this class?Does the rule contain links referencing Retype links.

EReferences typed over the class?Does the rule contain textual elements making use of this class? Get the new name and replace the old one.

Figure 7: Rule propagating the renaming of a class in the model to the graph transformation rule.

6 RELATED WORK

Mens (Mens and Tourwe, 2004) provides a com-prehensive survey of software refactoring. Fowler’sbook probably constitutes the most cited reference inthis domain (Fowler, 1999). The refactorings pre-sented in this book all apply to object-oriented pro-grams, i.e., they are applied to source code rather thanmodels. Furthermore, refactorings are described in aninformal way. A formalization which is based on pro-gram graphs and graph transformation rules is pre-sented in (Mens et al., 2005). A major restrictionof this work consists in the fact that only individualrules are considered. In the general case, programmedgraph transformation rules are required for specifyingrefactoring transformations. This is demonstrated e.g.by (Geiger, 2008), in which a refactoring case pre-pared for the GraBaTs 2008 workshop was realizedin Fujaba (Zundorf, 2001). The refactoring case in-cluded three refactorings on program graphs.

Research on model refactoring primarily focuseson the structural model (class diagrams). For exam-ple, in (Biermann et al., 2006) refactoring of Ecoremodels is specified with graph transformation rules inthe AGG environment (Taentzer, 2003). Mens (Mens,2005) demonstrates how refactoring transformations

on UML class diagrams may be specified in differentgraph transformation languages (AGG and Fujaba).In (Mens et al., 2007), critical pair analysis is appliedto AGG rules for refactoring Ecore models in order todetect dependencies between refactoring transforma-tions. Based on this analysis, the user is guided in theapplication of these transformations.

Bottoni (Bottoni et al., 2003) goes beyond theseapproaches by providing integrated refactoring trans-formations: A refactoring transformation is appliednot only to a UML class diagram, but also to thesource code implementing the structural model. Ourwork differs from this approach inasmuch as we con-sider behavioral models rather than source code.

We are aware of only a few approaches dealingwith the propagation of changes from the structuralmodel into the behavioral model. Rosner and Bauer(Roser and Bauer, 2008) propose an approach to up-date model transformations in response to metamodelchanges. The approach requires an ontology mappingbetween metamodel versions and is applied to evolveQVT-R (OMG, 2011) transformations. The evolutionof model transformations constitutes an example of ahigher order transformation (Tisi et al., 2009).

To the best of our knowledge, the only approachdealing with the propagation of changes into graph

transformation rules is presented in (Levendovszkyet al., 2009), which refers to the GReAT languageand environment (Agrawal et al., 2006). However,this approach suffers from several limitations. First, itconsiders only elementary changes to the metamodel,e.g., changing the name of a class. Second, changesare propagated only in a semi-automatic way. Third,the resulting graph transformation rules may containsyntactic and semantic errors.

Altogether, the work presented in this paper isunique inasmuch as it does not only support refactor-ing with, but also refactoring for graph transformationrules. Refactoring on the structural and the behav-ioral model are supported in an integrated way, andchanges are propagated to graph transformation rulessuch that consistency is preserved.

7 CONCLUSION

Model-driven software engineering reduces devel-opment effort by replacing low-level programmingwith the construction of high-level models. To makethese models executable, structural modeling has tobe complemented with behavioral modeling. Duringtheir lifetime, models undergo many changes for a va-riety of different reasons. Thus, it is crucial to sup-port model evolution. Refactoring of models providesan important contribution to model evolution since itaims at restructuring models such that future changesare facilitated.

In this paper, we presented tool support for modelrefactoring in the ModGraph environment. Mod-Graph employs Ecore models for structural modelingand graph transformation rules for behavioral mod-eling. Refactorings are supported in an integratedway: Each refactoring transformation on the struc-tural model is consistently propagated into the be-havioral model. In this way, our work goes con-siderably beyond previous work on model refactor-ing which was confined to the refactoring of thestructural model. Furthermore, while several otherapproaches use graph transformations for refactor-ing (i.e., refactoring with graph transformations), ourwork is unique inasmuch as it addresses refactoringfor graph transformations, as well.

REFERENCES

Agrawal, A., Karsai, G., Neema, S., Shi, F., and Vizhanyo,A. (2006). The design of a language for model trans-formations. Software and System Modeling, 5(3):261–288.

Banerjee, J., Kim, W., Kim, H.-J., and Korth, H. F. (1987).Semantics and implementation of schema evolution inobject-oriented databases. In Proceedings of the 1987ACM SIGMOD International Conference on Manage-ment of Data (SIGMOD 1987), pages 311–322, SanFranciso, CA. ACM Press.

Biermann, E., Ehrig, K., Kohler, C., Kuhns, G., Taentzer,G., and Weiss, E. (2006). EMF model refactoringbased on graph transformation concepts. In Favre, J.-M., Heckel, R., and Mens, T., editors, Proceedings ofthe Third Workshop on Software Evolution ThroughTransformations: Embracing the Change, volume 3of Electronic Communications of the EASST, Natal,Rio Grande del Norte, Brazil. 16 p.

Bottoni, P., Parisi-Presicce, F., and Taentzer, G. (2003).Specifying integrated refactoring with distributedgraph transformations. In (Pfaltz et al., 2003), pages220–235.

Buchmann, T., Westfechtel, B., and Winetzhammer, S.(2012). ModGraph: Graphtransformationen fur EMF.In Sinz, E. J. and Schurr, A., editors, Modellierung2012, volume 201 of Lecture Notes in Informatics,pages 107–122, Bamberg, Germany. GI.

Dummel, N. (2013). Refactoring mit Graphtransforma-tionsregeln. Bachelor thesis, University of Bayreuth,Bayreuth, Germany.

Fowler, M. (1999). Refactoring: Improving the Design ofExisting Code. Addison-Wesley, Boston, MA, USA.

Geiger, L. (2008). Graph transformation-based refactor-ings using Fujaba. In Rensink, A. and van Gorp, P.,editors, 4th International Workshop on Graph-BasedTools: The Contest, Leicester, UK.

Levendovszky, T., Balasubramanian, D., Narayanan, A.,and Karsai, G. (2009). A novel approach to semi-automated evolution of DSML model transformation.In van den Brand, M., Gasevic, D., and Gray, J., edi-tors, Proceedings of the Second International Confer-ence on Software Language Engineering (SLE 2009),volume 5969 of LNCS, pages 23–41, Denver, CO.Springer.

Mens, T. (2005). On the use of graph transformationsfor model refactoring. In Lammel, R., Saraiva, J.,and Visser, J., editors, International Summer Schoolon Generative Techniques in Software Engineering(GTTSE 2005), volume 4143 of LNCS, pages 219–257, Braga, Portugal. Springer.

Mens, T., Eetvelde, N. V., Demeyer, S., and Janssens, D.(2005). Formalizing refactorings with graph transfor-mations. Journal of Software Maintenance and Evo-lution: Research and Practice, 17(4):247–276.

Mens, T., Taentzer, G., and Runge, O. (2007). Analysingrefactoring dependencies using graph transformation.Software and Systems Modeling, 6(3):269–285.

Mens, T. and Tourwe, T. (2004). A survey of software refac-toring. IEEE Transactions on Software Engineering,30(2):126–139.

OMG (2011). Meta Object Facility (MOF) 2.0Query/View/Transformation Specification. ObjectManagement Group, Needham, MA, formal/2011-01-01 edition.

Pfaltz, J. L., Nagl, M., and Bohlen, B., editors (2003).Application of Graph Transformations with IndustrialRelevance: Second International Workshop (AGTIVE2003), volume 3062 of LNCS, Charlottesville, VA,USA. Springer.

Rose, L. M., Herrmannsdoerfer, M., Williams, J. R.,Kolovos, D., Garces, K., Paige, R. F., and Pollack,F. A. (2010). A comparison of model migration tools.In Petriu, D. C., Rouquette, N., and Haugen, Ø., ed-itors, MODELS 2010, Part I, volume 6394 of LNCS,pages 61–75, Oslo, Norway. Springer.

Roser, S. and Bauer, B. (2008). Automatic generation andevolution of model transformations using ontology en-gineering space. In Spaccapietra, S., Pan, J. Z., Thi-ran, P., Halpin, T., Staab, S., Svatek, V., Shvaiko,P., and Roddick, J., editors, Journal of Data Seman-tics XI, volume 5383 of LNCS, pages 32–64. Springer,Heidelberg.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,E. (2009). EMF: Eclipse Modeling Framework.Addison-Wesley, Boston, MA, 2nd edition.

Taentzer, G. (2003). AGG: A graph transformation envi-ronment for modeling and validation of software. In(Pfaltz et al., 2003), pages 446–453.

Tisi, M., Jouault, F., Fraternali, P., Ceri, S., and Bezivin,J. (2009). On the use of higher-order model transfor-mations. In Paige, R. F., Hartman, A., and Rensink,A., editors, ECMDA-FA 2009, volume 5562 of LNCS,pages 18–33, Heidelberg. Springer.

Winetzhammer, S. (2012). ModGraph — generating exe-cutable EMF models. In Krause, C. and Westfechtel,B., editors, Proceedings of the 7th International Work-shop on Graph Based Tools, volume 54 of ElectronicCommunications of the EASST, pages 32–44, Bremen,Germany. EASST.

Winetzhammer, S. and Westfechtel, B. (2013). ModGraphmeets Xcore: Combining rule-based and proceduralbehavioral modeling for EMF. In Tichy, M., Ribeiro,L., Margaria, T., Padberg, J., and Taentzer, G., edi-tors, Proceedings of the 12th International Workshopon Graph Transformation and Visual Modeling Tech-niques (GTVMT 2013), volume 58 of Electronic Com-munications of the EASST, Rome, Italy. EASST.

Winetzhammer, S. and Westfechtel, B. (2014). Compil-ing graph transformation rules into a procedural lan-guage for behavioral modeling. In Pires, L. F., Ham-moudi, S., Filipe, J., and das Neves, R. C., edi-tors, Proceedings of the 2nd International Conferenceon Model-Driven Engineering and Software Devel-opment (MODELSWARD 2014), pages 415–424, Lis-bon, Portugal. SCITEPRESS Science and TechnologyPublications, Portugal.

Zundorf, A. (2001). Rigorous object oriented software de-velopment. Technical report, University of Paderborn,Germany.