Propagating Model Refactorings to Graph Transformation Rules
Sabine Winetzhammer and Bernhard Westfechtel
Chair of Applied Computer Science 1 - Software Engineering,
University of Bayreuth, Universit
¨
atsstraße 30, 95440 Bayreuth, Germany
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 software
artifacts 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 both
structural 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 the
behavioral model.
1 INTRODUCTION
Model-driven software engineering reduces the effort
of developing software by replacing low-level pro-
gramming 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 be
a general consensus to employ some variant of class
diagrams for structural modeling, e.g., EMF, MOF,
or UML class diagrams. In contrast, there is a wide
spectrum of languages for behavioral modeling which
are based on different computational paradigms (e.g.,
state machines, activity diagrams, or rule-based trans-
formation languages). In this paper, we will focus on
behavioral modeling with graph transformation rules:
Models are considered as graphs, and transformations
of these graphs are specified declaratively by graph
transformation rules.
Software evolution is a discipline which provides
concepts, methods, and tools for evolving software in
response to changing requirements, platforms, tech-
nologies, etc. In the context of object-oriented soft-
ware development, evolution support is provided in
a variety of different ways, including e.g. design
patterns and refactorings, both of which facilitate
changes to the software. According to (Fowler, 1999),
refactoring denotes the activity of restructuring soft-
ware by applying a series of transformations without
affecting 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 model
refactoring focused on structural models (Biermann
et 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 no
longer 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 refactoring
in ModGraph
1
, a tool which employs Ecore class dia-
grams for structural modeling and graph transforma-
tion rules for behavioral modeling. For the structural
model, ModGraph offers a set of refactoring trans-
formations along the lines of Fowler’s work (Fowler,
1999). The tool support goes beyond previous work
since the refactorings are propagated from the struc-
tural model into the behavioral model. Thus, graph
transformation rules are updated in response to the
changes 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-
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 instances
1
http://btn1x4.inf.uni-bayreuth.de/modgraph/homepage
17
Winetzhammer S. and Westfechtel B..
Propagating Model Refactorings to Graph Transformation Rules.
DOI: 10.5220/0005098900170028
In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 17-28
ISBN: 978-989-758-037-6
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
a:EAttribute
C2: EClass
C1: EClass
GT
RHS
LHS
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.
in response to changes of the underlying metamodel
(Rose et al., 2010) (analogously to schema evolution
in databases (Banerjee et al., 1987)). In contrast, the
work presented in this paper has a different focus: It
deals with the consistent refactoring of a set of in-
terdependent models, which requires propagation of
the changes of the structural model into the behav-
ioral model. The migration of model instances is not
considered here.
The rest of this paper is structured as follows: Sec-
tion 2 explains the context in which this work was
performed. Section 3 provides an overview of our ap-
proach to refactoring both structural and behavioral
models. Section 4 describes the implementation. Sec-
tion 5 illustrates this approach by several examples.
Section 6 discusses related work. Section 7 concludes
the paper.
2 BACKGROUND
The work reported in this paper was carried out in
the 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 owning
structural and behavioral features. Structural features
are partitioned into attributes, which have (collections
of) simple values, and references to target classes. By
default, references are uni-directional (from instances
of the source class to instances of the target class);
however, a pair of uni-directional references may be
grouped into a bi-directional reference. Behavioral
features 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 specified
declaratively by a graph transformation rule. Model
instances are considered as graphs whose nodes and
edges correspond to objects and links, respectively.
A graph transformation rule describes an in-place
model transformation and essentially consists of a
left-hand side and a right-hand side, like the one
shown on the left-hand side of Figure 1 to move an
attribute from one class to another. The left-hand side
describes the subgraph to be searched (the match for
the rule). Here the classes and the attribute that should
be 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 other
class. The left-hand side and the right-hand side may
be merged into a single diagram, as shown in Figure
1 on the right-hand side. Elements belonging only to
one side need to be marked: only left-hand side ele-
ments are colored red and marked --, only right-hand
side elements are colored green and marked ++.
ModGraph uses the merged view. An example is
given in Figure 4. In ModGraph single and double
boxes represent single objects and sets of objects, re-
spectively. The current object on which the operation
implemented by the graph transformation rule is in-
voked is designated by the inscription this. Arrows
represent links, i.e., instances of references. Con-
ditions on and modifications of attribute values are
shown in the Constraints and Changes compartments
of the boxes for objects. Nodes designated as optional
are not required for the rule to match. According to
the merged view, insertions and deletions of objects
and links are represented by coloring the respective
graphical elements in green and red, respectively, as
well as markers ++ and -- are placed inside the boxes
for objects and near to the arrows for links. The mean-
ing of the graph transformation rule shown in Figure 4
will be described later.
Altogether, the ModGraph tool has to deal with
different types of models, as illustrated in Figure 2.
The blue boxes represent the models which are cre-
ated by the ModGraph user: The structural model
is defined by an Ecore class diagram. The behav-
ioral model consists of a set of graph transformation
rules specifying the behavior of operations introduced
in the structural model. At runtime, graph transfor-
mation rules will be applied to model instances by
matching and replacing subgraphs. Internally, a graph
transformation rule is represented as a model, too
(namely an instance of the graph transformation meta-
model, which in turn is an instance of the Ecore meta-
model).
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
18
Ecore
Metamodel
GraphTransformation
Metamodel
Instance
Ecore
Model
instanceof
instanceof
GraphTransformation
Rule
instanceof
update
instanceof
references
matches/transforms
Figure 2: The problem statement.
According to (Fowler, 1999), refactoring denotes
the activity of restructuring software by applying a
series of transformations without affecting its exter-
nally observable behavior. Fowler’s book contains
a bunch of refactoring transformations, all of which
refer to the source code. For each refactoring, the
following information is supplied: the precondition
under which the refactoring may be applied, the el-
ementary steps of the core refactoring, the impact
of changes on dependent model elements, and the
postconditions which hold after the refactoring. The
refactoring transformations vary in their complexity
and range from simple ones such as renaming an at-
tribute to complex refactorings such as pulling up an
attribute from all subclasses to a common superclass
and extracting a class from a given class by moving a
part of its features to the extracted class.
In this paper, we discuss refactorings of models
rather than refactoring of source code. More specifi-
cally, we focus on models created by ModGraph users
(blue boxes in Figure 2). Thus, we consider the
following problem: Let us assume that a consistent
model is given, being composed of a class diagram
and a set of graph transformation rules. The graph
transformation rules are typed with the elements of
the structural model. ModGraph ensures that typing
is consistent: The class of an object must be defined in
the 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 this
end, the structural model has to be changed and the
changes must be propagated into the graph transfor-
mation rules such that consistency is re-established.
3 PRELIMINARY
CONSIDERATIONS
As the last section described EMF and ModGraph
graph transformation rules as well as their inter-
play, this one focuses on problems concerning the
graph 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 and
ModGraph (black, bold arrows). ModGraph is deeply
rooted 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 an
instance 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). This
metamodel also serves as metamodel for Ecore class
diagrams (blue box on the left) . Those class diagrams
may be instantiated (black box on the left).
The graph transformation rule interacts with the
model and the instance. The first interaction is caused
by 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 of
the Ecore model by matching structures and applying
changes. The components inside the rule reference el-
ements of the structural model, e.g. an object in a rule
must reference an EClass inside the Ecore model, a
link has to reference an EReference.
These two dependencies are shown as black, bold
arrows named ”references” and ”matches / trans-
forms” in Figure 2. A full overview of the dependen-
PropagatingModelRefactoringstoGraphTransformationRules
19
MetaRule /
Xcore Operation
Instance
Ecore
Model
GraphTransformation
Rule
references
matches/transforms
Transformation(Rule)
Perform a
refactoring!
Interdependent
set of models
refactor refactor
call
refactoring
propagate
changes
Figure 3: Interaction of the refactoring engine with the affected models.
cies between a rule and the structual model is given
in (Buchmann et al., 2012) with an explanation of the
ModGraph metamodel for graph transformation rules.
Within a static context, this kind of model exe-
cution will probably never cause any problems. But
many models evolve in time: elements are renamed,
references are re-targeted and classes are inlined or
extracted in order to create or collapse inheritance hi-
erarchies or just to improve the model - in short: the
model 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 any
element is just referencing the refactored model ele-
ment, after refactoring, this reference is unset. Hence,
the rule is invalid because of inconsistencies between
the rule and the model, which will be eliminated by
our approach. We propose to propagate refactorings
to 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 refactorings
performed by these rules to the graph transformation
rules belonging to the refactored static model by using
mostly meta-rules. That way we provide refactoring
on graph transformation rules executed by other graph
transformation rules, we call meta-rules.
Our approach starts with Fowler’s definition of
each refactoring. As these definitions were introduced
for the refactoring of (object oriented) code, we adapt
the 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 changes
to be performed inside the rule. Table 1 shows some.
One may classify the affected rule elements as shown
in the first column: the whole rule, nodes (repre-
senting single- and multi-valued objects and param-
eters), attributes, links (instances of references), and
textual conditions (e.g. pre- and postconditions, at-
tribute conditions), as well as fields (e.g. operation
calls). The result of this step is taken to propagate
the changes to the rules. The change may be a simple
setter 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 its
containing class. Hence changes performed here need
to be propagated. A rule is superseded if the operation
is deleted. If the class is deleted, the rule may be as-
signed to another class where a similar operation shall
take place now or is also deleted. A node references
a class. It needs to be updated whenever the class
changes. If for example the class is renamed, the node
needs to be retyped. If the class is made abstract, the
node will be deleted if its status is CREATE. For any
other status it will be retyped. Attributes are an essen-
tial part of a rule. They may be used to add conditions
to nodes as well as for assignments. Each attribute in a
rule references an attribute in the Ecore model. There-
fore an attribute in a rule needs to follow the attribute
in the class. Renaming and moving may be executed
without problems, but retyping is quite interesting: If
an attribute is retyped in the Ecore model and used
inside a graph transformation rule the user has to as-
sign its new value manually. Furthermore attributes
may be moved and links be re-targeted. In both cases
the refactoring tries to locate an instance of the new
container / target of the attribute / link and to move /
re-target the attribute / link, respectively. If this fails
the attribute / link is deleted. For the textual parts of
the rules exists no other way than parsing them to find
the elements referred and to adapt them using naming
conventions.
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
20
Table 1: Effects of model changes on different classes of rule elements.
Affected rule element Change in Ecore model Change modeled in meta-rule
Class
rename adapt references to class
delete adapt references to class, if not successful: delete
Whole rule make abstract adapt references to class
Operation
rename adapt references to operation
delete delete
Class
Nodes rename retype
delete delete
make abstract retype or delete
Attribute in Class
rename adapt name
Attributes move try to move, if not successful: delete
retype retype and assign new value
delete delete
Reference
Links rename adapt name
retarget try to retarget, if not successful: delete
delete delete
Textual conditions, any change parse condition and propagate re-
paths and fields factoring, if refactored element is found
4 IMPLEMENTATION
The refactoring is implemented using ModGraph/X-
core
2
and Java to implement connectors using exten-
sion points. For the static structure, we mainly use
two classes in an Xcore model: Refactoring, to specify
the refactorings on the model (as started in (D
¨
ummel,
2013)), and Propagation, to propagate the changes
caused by them.
As we want to use the added value of rules only,
each refactoring on the model is specified inside a
graph transformation rule or an Xcore operation, de-
pending on its complexity. We will see in detail in
Section 5, that the change of a bi- to a unidirectional
reference is modeled very well with rules, while re-
naming an element in the model can be written easily
in a few lines inside an Xcore operation. Please note,
that these refactorings are universal. They also work
for Ecore models outside the ModGraph context.
The propagation of changes to ModGraph rules
follows the same scheme. A complex propagation is
modeled as a rule, using Xcore as control flow lan-
guage, if necessary. A simple propagation is modeled
2
The approach to use ModGraph and Xcore is described
in (Winetzhammer and Westfechtel, 2013) and (Winet-
zhammer and Westfechtel, 2014).
as an Xcore operation. In Section 5, examples for
propagations are shown.
As a final step of propagation, all rules changed
are validated in order to secure their navigability.
Navigability means, that each single- or multi-valued
object 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 validation
fails the user needs to adjust the rule manually. That
way, rules which are no more navigable after apply-
ing the refactoring will be marked for further manual
changes.
The rest is implemented in Java: We extend a
popup-menu in order to be able to call the refactoring
in the model and call the refactoring rule implementa-
tion (written in ModGraph/Xcore). After successfully
executing this one, we call the propagation implemen-
tation (written in ModGraph/Xcore), that propagates
the changes to the rules. The propagation locates the
rules, parses and fixes them as shown in the next para-
graph. The result is a complete model evolution.
We implemented the following refactorings and
their 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-
PropagatingModelRefactoringstoGraphTransformationRules
21
ements in the rules. (See Section 5)
Add Parameter: Adds an EParameter to an EOp-
eration. Propagate to implemented operation and
textual fields, especially to operation calls, in a
rule. Both need to be adapted.
Remove Parameter: Removes an EParameter from
an 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: Re-
moves an EReference. Propagation: Exchanges
each link targeting the deleted reference by a link
targeting its former opposite reference. (See Sec-
tion 5)
Change Uni- to Bidirectional Reference: Adds an
EReference and sets its EOpposite. No propaga-
tion.
Extract Class: Extracts an EClass from a given
EClass and relates them using an EReference.
Propagation: If a node references the given class,
check if it uses attributes, operations or references
moved to the extracted class. If yes, create a
new node referencing the extracted class and re-
late both using a link which is an instance of the
EReference relating the classes. Move the ele-
ments referencing the extracted class to the newly
created node.
Extract Subclass: Extracts a subclass from a given
class. Propagation: If operations, attributes or
references 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 a
given class. No propagation, because of inheri-
tance.
Inline Class: Inlines a class into another class.
Propagation: Retype all nodes typed over the in-
lined class 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 referencing
the source and target class move the usage of the
attribute / operation. In all other cases delete the
usage.
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 user
to which subclass it shall be retyped and perform
this.
Replace Subclasses with Fields: Creates an enu-
meration with one literal for each subclass and
an attribute typed over the enum in the super-
class. Propagation: Replace the nodes typed over
the subclasses by nodes typed over the superclass
with 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 EReference
between two EClasses. Propagation: Create the
corresponding link, if the rule contains two nodes
referencing the classes.
Replace Inheritance with Delegation: Replace the
existing generalization with an EReference. Prop-
agation: If both classes are referenced by nodes
inside a rule create a link referencing the ERefer-
ence.
Replace Delegation with Inheritance: Replace an
existing EReference with a generalization. Prop-
agation: Remove the link referencing the ERefer-
ence.
5 EXAMPLES
The general idea of propagating model refactorings
on interdependent models is now concretely shown
considering the refactoring change a bi-directional to
a uni-directional reference in detail. The refactoring
to rename an element is sketched by the special case
of renaming a class.
5.1 Change a Bi- to a Uni-directional
Reference
The refactoring we consider here in detail is chang-
ing a bi- to a uni-directional reference. Starting with
Fowler’s definition (Fowler, 1999), we provide the
implementation of the model change as well as the
meta-rule to propagate the changes.
Fowler defines this refactoring as follows: ”You
have a two-way association but one class no longer
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
22
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 transformation
rules. The numbers must be replaced by the corresponding OCL conditions shown in Listing 1.
needs features from the other.”(Fowler, 1999) For
EMF this means, that a reference with an opposite
set is deleted. The rule to perform the operation in
the Ecore model is shown in Figure 4. Here a refer-
ence called reference2 (red box, marked with --) is
deleted within all its links (red arrows, marked with
--) to classes as well as its opposite relation to the
other reference, called formerOpposite.
To propagate this refactoring, we use an Xcore
operation and two meta-rules. The meta-rule shown
in Figure 5 shows the application of the refactor-
ing propagation to links in the Graph Pattern. The
PropagatingModelRefactoringstoGraphTransformationRules
23
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 equally
named references in the model, which are opposed.
meta-rule for the negative application conditions is
structured 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 whole
rule, second it calls both meta-rules, third it updates
the 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 referencing
the deleted reference and is therefore deleted. A new
link, called link in Figure 5, is created as an instance
of the former opposite of the deleted reference. The
numbers next to the paths in the rule represent OCL
path expressions, shown in Listing 1. They ensure
consistency for pattern matching. No. 1 and 2 en-
sure that the nodes node1 and node2 are referencing
the classes between which the refererences has been
deleted. No. 3 and 4 ensure that a link, referencing
the deleted reference exists in the rule.
The refactoring is applied to a test project. The
model contains a bidirectional reference modeled as
two EReferences called toS and toP, which are set as
EOpposite to each other. The project also contains a
set of graph transformation rules. One of the rules is
shown in the upper part of Figure 6, where an instance
of a parameter p shall be deleted. This instance is con-
nected using a link, an instance of the toP reference, to
the current object. Now let us assume that the user de-
cides toP is no more needed in the class diagram and
therefore calls our refactoring rule to change the bi- to
a uni-directional reference. toP is removed from the
structural model. Also our propagation mechanism
changes the rules. The result for our example rule is
shown 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 structural
model can be written as a few lines in an Xcore op-
eration, but the changes to be propagated to the rules
are not as trivial: As this refactoring may affect all
components of an Ecore model, all components of
a rule referencing those may be concerned. Due to
the fact, that elements of a rule reference model el-
ements differently, there are a number of renaming
propagations. Starting with the simple part, Listing 2
shows the implementation for the refactoring of the
structural model. The renamed element as well as
its new name are given as a parameter to the opera-
tion. First our implementation checks if the element’s
container already contains any element with the given
new name. If not, the element is renamed.
The rather complex part is the propagation that is
decomposed into several meta-rules and Xcore opera-
tions. For the meta-rules we distinguish between each
element 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 to
rename the class in the model itself. This is performed
by a call for a setter. In the next step all graph trans-
formation rules are searched using the criteria shown
in 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 rule
in order to get a consistent set of models. Assume
the answer to the first question is yes. The next ques-
tion is also answered positively, if the rule contains
a current object. Figure 7 shows the meta-rule for
the propagation. The corresponding class of the rule
is set to the renamed one, the current object this is
retyped and possible unbound nodes referring to the
class are also retyped directly. Links as instances of
references typed over the renamed class are adapted
in an extra meta-rule, which is called by an operation
call 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 elements
are handled separately. Please note that retyping by
renewing the type / corresponding class is necessary
here, as these are inter-model dependencies which are
lost by changing the corresponding object.
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
24
Listing 1: OCL path expressions for change bi- to unidirectional reference.
1 1 : [ ( s e l f . o c l IsT y p e O f ( GT T h is O bje c t ) and s e l f . o c l A sType ( GTTh i sOb j ec t)>
2 e x i s t s ( e | e . t y p e . oc l A s T y p e ( e c o r e : : E C l a s s ) . name =
3 f o r m e r O p p o s i t e . e R e f e re n c e T y p e . o clAsType ( e c o r e : : E C l a s s ) . name ) )
4 o r ( s e l f . o c l I s T y p e O f ( GPUnboundNode ) and s e l f . oclAsTy p e ( GPUnboundNode)>
5 e x i s t s ( e | e . t y p e . oc l A s T y p e ( e c o r e : : E C l a s s ) . name =
6 f o r m e r O p p o s i t e . e R e f e r e n c e T y p e . o clAsType ( e c o r e : : E C l a s s ) . name ) )
7 o r ( s e l f . o c l I s T y p e O f ( GPBoundNode ) and s e l f . oclAsT y p e ( GPBoundNode)>
8 e x i s t s ( e | e . t y p e . oc l A s T y p e ( e c o r e : : E C l a s s ) . name =
9 f o r m e r O p p o s i t e . e R e f e re n c e T y p e . o clAsType ( e c o r e : : E C l a s s ) . name ) ) ]
10
11 2 : [ ( s e l f . o c l I s T y p e O f ( GT T h is O bje c t ) and s e l f . o c l A sType ( GTTh i sO b j ec t)>
12 e x i s t s ( e | e . t y p e . ocl A s T y p e ( e c o r e : : E C l a s s ) . 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 . oclAsTy p e ( e c o r e : : ECl a s s ) . name ) )
14 o r ( s e l f . o c l I s T y p e O f ( GPUnboundNode ) and s e l f . o c l A s T ype ( GPUnboundNode)>
15 e x i s t s ( e | e . t y p e . ocl A s T y p e ( e c o r e : : E C l a s s ) . 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 . oclAsTy p e ( e c o r e : : ECl a s s ) . name ) )
17 o r ( s e l f . o c l I s T y p e O f ( GPBoundNode ) and s e l f . o c l A s T ype ( GPBoundNode)>
18 e x i s t s ( e | e . t y p e . ocl A s T y p e ( e c o r e : : E C l a s s ) . 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 . oclAsTy p e ( e c o r e : : ECl a s s ) . 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 . oc l A s T y p e ( GTNode ) . o u tg oi n g E d g e s >
22 e x i s t s ( e | e . o c l I s K i n d O f ( GPLink ) and e . o c l A sType ( 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 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 ) an d n . oclAs T y p e ( GTNode ) . in c o ming E d ges>
25 e x i s t s ( e | e . o c l I s K i n d O f ( GPLink ) and e . o c l A sType ( 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 vo i d 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 == E Cl as s ) . 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 E C l a s s ) . name == newName ] ) {
4 re t u r n / and show message /
5 } e l s e {
6 e l e m e n t . name = newName
7 }
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 class
and 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.
6 RELATED WORK
Mens (Mens and Tourw
´
e, 2004) provides a compre-
hensive survey of software refactoring. Fowler’s book
probably constitutes the most cited reference in this
domain (Fowler, 1999). The refactorings presented in
this book all apply to object-oriented programs, i.e.,
they are applied to source code rather than models.
Furthermore, refactorings are described in an infor-
mal way. A formalization which is based on program
graphs and graph transformation rules is presented
in (Mens et al., 2005). A major restriction of this
work consists in the fact that only individual rules are
considered. In the general case, programmed graph
transformation rules are required for specifying refac-
toring transformations. This is demonstrated e.g. by
(Geiger, 2008), in which a refactoring case prepared
for the GraBaTs 2008 workshop was realized in Fu-
jaba (Z
¨
undorf, 2001). The refactoring case included
three refactorings on program graphs.
PropagatingModelRefactoringstoGraphTransformationRules
25
Figure 7: Rule propagating the renaming of a class in the model to the graph transformation rule.
Research on model refactoring primarily focuses
on the structural model (class diagrams). For exam-
ple, in (Biermann et al., 2006) refactoring of Ecore
models is specified with graph transformation rules in
the AGG environment (Taentzer, 2003). Mens (Mens,
2005) demonstrates how refactoring transformations
on UML class diagrams may be specified in different
graph transformation languages (AGG and Fujaba).
In (Mens et al., 2007), critical pair analysis is applied
to AGG rules for refactoring Ecore models in order to
detect dependencies between refactoring transforma-
tions. Based on this analysis, the user is guided in the
application of these transformations.
Bottoni (Bottoni et al., 2003) goes beyond these
approaches by providing integrated refactoring trans-
formations: A refactoring transformation is applied
not only to a UML class diagram, but also to the
source code implementing the structural model. Our
work differs from this approach inasmuch as we con-
sider behavioral models rather than source code.
We are aware of only a few approaches dealing
with the propagation of changes from the structural
model into the behavioral model. Rosner and Bauer
(Roser and Bauer, 2008) propose an approach to up-
date model transformations in response to metamodel
changes. The approach requires an ontology mapping
between metamodel versions and is applied to evolve
QVT-R (OMG, 2011) transformations. The evolution
of model transformations constitutes an example of a
higher order transformation (Tisi et al., 2009).
To the best of our knowledge, the only approach
dealing with the propagation of changes into graph
transformation rules is presented in (Levendovszky
et al., 2009), which refers to the GReAT language
and environment (Agrawal et al., 2006). However,
this approach suffers from several limitations. First, it
considers only elementary changes to the metamodel,
e.g., changing the name of a class. Second, changes
are propagated only in a semi-automatic way. Third,
the resulting graph transformation rules may contain
syntactic and semantic errors.
Altogether, the work presented in this paper is
unique inasmuch as it does not only support refactor-
ing with, but also refactoring for graph transformation
rules. Refactoring on the structural and the behav-
ioral model are supported in an integrated way, and
changes are propagated to graph transformation rules
such that consistency is preserved.
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
26
7 CONCLUSION
Model-driven software engineering reduces develop-
ment effort by replacing low-level programming with
the construction of high-level models. To make
these models executable, structural modeling has to
be complemented with behavioral modeling. During
their lifetime, models undergo many changes for a va-
riety of different reasons. Thus, it is crucial to sup-
port model evolution. Refactoring of models provides
an important contribution to model evolution since it
aims at restructuring models such that future changes
are facilitated.
In this paper, we presented tool support for model
refactoring in the ModGraph environment. Mod-
Graph employs Ecore models for structural modeling
and graph transformation rules for behavioral mod-
eling. Refactorings are supported in an integrated
way: 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 the
structural model. Furthermore, while several other
approaches use graph transformations for refactor-
ing (i.e., refactoring with graph transformations), our
work is unique inasmuch as it addresses refactoring
for 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 in
object-oriented databases. In Proceedings of the 1987
ACM SIGMOD International Conference on Manage-
ment of Data (SIGMOD 1987), pages 311–322, San
Franciso, CA. ACM Press.
Biermann, E., Ehrig, K., K
¨
ohler, C., Kuhns, G., Taentzer,
G., and Weiss, E. (2006). EMF model refactoring
based on graph transformation concepts. In Favre, J.-
M., Heckel, R., and Mens, T., editors, Proceedings of
the Third Workshop on Software Evolution Through
Transformations: Embracing the Change, volume 3
of 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 distributed
graph transformations. In (Pfaltz et al., 2003), pages
220–235.
Buchmann, T., Westfechtel, B., and Winetzhammer, S.
(2012). ModGraph: Graphtransformationen f
¨
ur EMF.
In Sinz, E. J. and Sch
¨
urr, A., editors, Modellierung
2012, volume 201 of Lecture Notes in Informatics,
pages 107–122, Bamberg, Germany. GI.
D
¨
ummel, N. (2013). Refactoring mit Graphtransforma-
tionsregeln. Bachelor thesis, University of Bayreuth,
Bayreuth, Germany.
Fowler, M. (1999). Refactoring: Improving the Design of
Existing 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-Based
Tools: 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 transformations
for model refactoring. In L
¨
ammel, R., Saraiva, J.,
and Visser, J., editors, International Summer School
on 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). Analysing
refactoring dependencies using graph transformation.
Software and Systems Modeling, 6(3):269–285.
Mens, T. and Tourw
´
e, T. (2004). A survey of software refac-
toring. IEEE Transactions on Software Engineering,
30(2):126–139.
OMG (2011). Meta Object Facility (MOF) 2.0
Query/View/Transformation Specification. Object
Management Group, Needham, MA, formal/2011-01-
01 edition.
Pfaltz, J. L., Nagl, M., and B
¨
ohlen, B., editors (2003).
Application of Graph Transformations with Industrial
Relevance: Second International Workshop (AGTIVE
2003), volume 3062 of LNCS, Charlottesville, VA,
USA. Springer.
Rose, L. M., Herrmannsdoerfer, M., Williams, J. R.,
Kolovos, D., Garc
´
es, 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 and
evolution 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.
PropagatingModelRefactoringstoGraphTransformationRules
27
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 B
´
ezivin,
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 Electronic
Communications of the EASST, pages 32–44, Bremen,
Germany. EASST.
Winetzhammer, S. and Westfechtel, B. (2013). ModGraph
meets Xcore: Combining rule-based and procedural
behavioral modeling for EMF. In Tichy, M., Ribeiro,
L., Margaria, T., Padberg, J., and Taentzer, G., edi-
tors, Proceedings of the 12th International Workshop
on 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 Conference
on Model-Driven Engineering and Software Devel-
opment (MODELSWARD 2014), pages 415–424, Lis-
bon, Portugal. SCITEPRESS Science and Technology
Publications, Portugal.
Z
¨
undorf, A. (2001). Rigorous object oriented software de-
velopment. Technical report, University of Paderborn,
Germany.
ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends
28