The aim of this workshop is to bring together a number of researchers interested in the
use of graph rewriting for refactoring. In this way we can get to know each other's work,
and discuss differences and commonalities. More broadly we can consider the advantages and
disadvantages of graph rewriting, as compared to other formalisms, for describing various
aspects of refactoring. Also, and perhaps most most importantly, we wish to identify possibilities
for cooperation, within SegraVis (EU) and the project "Formal Foundation for Software Refactoring"
(FWO, Belgium).
Topics of interest: the use of graph transformation and related techniques for the
formalization of refactoring, and for the development of refactoring tools.
This includes also closely related topics, such as the formalization of conditions under
which refactorings are admissible, ways to maintain consistency while refactoring
and detection of "bad smells".
University of Antwerp - Department of Mathematics and Computer Science Middelheimlaan 1, 2020 Antwerpen (Berchem), Belgium
Building G (next to the parking lot)
Room G.017 on the ground floor.
Top-down, left-to-right: Pieter Van Gorp, Matthias Meyer, Gabriele Taentzer,
Ragnhild Van Der Straeten, Dirk Janssens, Andy Schürr, Niels Vaneetvelde, Karsten Hoelscher, Serge Demeyer,
Hendrik Voigt, Paolo Bottoni, Tom Mens,
Bart Du Bois.
The following program is tentative; in a small workshop like this one
we can afford a good amount of flexibility. There will be no formal proceedings,
but we intend to compile the conclusions into a document that may then be published.
April 5
The first day will be devoted to analysing and discussing the current state-of-the art of the topic.
The workshop will start with presentations and discussions of two papers, [1,2],
which will be used as a concrete starting point. In [1] an attempt to model refactorings at the
source code level is presented, and in [2] distributed graph transformations are used to maintain
consistency between the code and the model while refactorings are carried out.
We assume that the participants have read these papers when they arrive. This first part of the meeting
will be followed by short presentations or position statements concerning related topics of a technical
nature, or recent research that is relevant.
10.00 -11.00
presentation of the two basic papers.
11.00 -12.30
discussion and comparison
possible questions to be considered here (suggestions are welcome)
what is precisely the aim of this work? are there important differences?
what have been the main difficulties? do the authors feel that their original
aims were reached?
what can we conclude about the representation of programs?
what can we conclude about the graph rewriting mechanism?
14.00 - 15.30
short (15 min) presentations and position statements concerning the current
work on formalizing refactorings. Evidently we invite all participants to prepare
such presentations concerning any issue they like to discuss here -
our current list includes:
the role of hierarchical graphs and hierarchical graph rewriting
refactoring on models (e.g. in MDA)
refactoring in environments such as FUJABA
identification of code and design smells
16.00 -17.00
In the last session of the day we will try to identify the most important difficulties that
we have encountered in our work so far, and discuss the priority that should be given to
solving them.
April 6
The second day will be used to discuss directions as well as concrete approaches for
future work.
Conclusions of the last session of the previous day will evidently be taken into account.
There will undoubtedly be some unfinished business from the first day, but we would also like to
look at a somewhat broader picture, taking into account current work on program evolution in
a more general sense, and considering more fundamental questions about the pro's and con's of
graph rewriting in this context.
10.00 -11.30
Comparison of graph rewriting and other formal approaches to refactoring.
Are there any fundamental advantages to using graph rewriting here?
What are the limitations? Are there other formalisms that do not have them?
Which particular features, studied in he context of graph rewriting, could be
useful for formalising refactorings? How and why? (e.g. confluency. parallel/sequential
independence, triple graph grammars, critical pairs, etc.)
11.30 - 12.30
What should one really expect from tools for refactoring? At which levels of
abstraction are they relevant (cfr MDA)? How is refactoring related to
program evolution in a general sense? What kind of theoretical methods
or results (if any) are needed to aid in mastering the problems related to
program evolution?
14.00 - 15.00
Conclusion and identification of concrete topics for joint research in the (near) future.
End of workshop. Beginning of writing joint papers
Results
Summary: Graph Transformation for Software Refactoring =
Refactoring perspective
Behaviour preservations
Improve structure
Consistency maintenance, between models and code
Detection of code smells
Relationshp patterns & anti-patterns
Checking of preconditions
Descriptions of transformations
Composition of refactorings
Tools and what kind of tools (refactoring "wizard", customisable
refactorings)
Preserve lay-out
boundary condition: Text transformations (changing names -> also in
comments, files, ...)
what should be inside the model, what can be left out
what constraints do you want to verify, ...
+ what properties need to be preserved & changed
what kind of transformations, what is primitive, what is composed
Requirements/Criteria for any refactoring formalism
define the model (parse tree ?) in a concise way
navigate the parse tree / model
define (generate ?) the transformations
define the properties to be preserved (structure)
Nice to have
intuitive for tool developers
reason about the evolution history
"undo" mechanism / reversability of transformations
[2] P. Bottoni, F. Parisi-Presicce, G. Taenzer, Specifying Integrated Refactoring with Distributed Graph
Transformations, proceedings of AGTIVE 03, 227-272, 2003.
(+32) 3 218 09 04
Dirk.Janssens(a)ua.ac.be
