Transformation Dependency Analysis based on Graph ...informatique.umons.ac.be/ftp_infofs/2006/Mens2006-Bremen.pdf · Tom Mens (tom.mens@umh.ac.be) Institut d’Informatique Université
Post on 19-Mar-2020
3 Views
Preview:
Transcript
Tom Mens (tom.mens@umh.ac.be)Institut d’Informatique
Université de Mons-HainautBelgium
Transformation Dependency Analysisbased on Graph Transformation
and its application to program refactoringand model transformation
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 2
Acknowledgements
This talk reports on joint work with
Gabriele Taentzer and Olga Runge Technische Universität Berlin Developers of the general-purpose graph transformation toolAGG
http://tfs.cs.tu-berlin.de/agg
Günter Kniesel and students Universität Bonn Developer of JTransformer and Condor
http://roots.iai.uni-bonn.de
Ragnhild Van Der Straeten and Maja D’Hondt WORK IN PROGRESS …
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 3
Challenge: Model-driven evolution
ObservationModel-driven software engineering approaches do notadequately address software evolution problemsNeed better support (tools, formalisms) for
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 4
Motivation
Transformation is essential in softwareengineering
At all levels of abstraction Program transformation Model transformation
For all kinds of activities Software refactoring Model inconsistency management Aspect weaving Software merging Model integration Code generation Reverse engineering Software evolution
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 5
Motivation
Transformation dependency analysis is neededfor many of these activities
Given a set of transformations … Are there any sequential dependencies that dictate aparticular order of use? Are there any parallel dependencies that precludetheir joint use? Is it possible to come up with one (or several)‘optimal’ transformation sequence(s)? Is it possible to reorder a given sequence into acanonical form? and so on …
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 6
Motivation
Challenge
How to automate transformation dependencyanalysis?
How to exploit it to provide better tool support forsoftware engineering activities?
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 7
Three experiments with AGG
Specifying refactorings in AGG and analysing their dependencies
Comparing AGG and Condor from the viewpoint of transformation dependencyanalysis
Using AGG for model inconsistencymanagement
detecting and resolving inconsistencies, and analysingtheir dependencies
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 8
About AGG
AGG = Attributed Graph Grammar system Algebraic approach to graph transformationSupports graph grammars (as opposed to programmedgraph rewriting) Annotations are in Java Efficient graph parsing
Parse grammar Critical pair analysis
Easy integration with Java code
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 9
About AGGIntroduction
Experiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 10
About graph transformation
A graph production p: L→R is a structure-preserving partial mapping between (directed,labeled, typed) graphs
Preserves sources and targets of edgesPreserves node and edge typesPreserves node and edge labelsPartial means that nodes or edges may be deleted
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 11
About graph transformation
Exemple: Pull Up Method refactoring
left-hand side L right-hand side R
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 12
About graph transformation
Exemple: Pull Up Method refactoringSome nodes and edges are preserved
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 13
About graph transformation
Exemple: Pull Up Method refactoringSome nodes and edges are deleted
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 14
About graph transformation
Exemple: Pull Up Method refactoringSome nodes and edges are added
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 15
About graph transformation
A graph transformation t: G⇒H is theapplication of a graph production p: L→R that ismatched in the context of a given graph G
t = (p,m) where m: L→G is an injective graph morphism(match)
G
L Rp
m
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 16
About graph transformation
A graph transformation t: G⇒H is theapplication of a graph production p: L→R that ismatched in the context of a given graph G
t = (p,m) where m: L→G is an injective graph morphism(match)
G H
L Rp
m
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 17
About graph transformation
More advanced GT features Negative application conditions (NACs) Set nodes (multi objects) Attributed graphs and GTs Programmed graph transformation Graph grammars
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 18
About graph transformation
A negative application condition nac: L→N of agraph production p: L→R represents a forbiddencontext. In a graph transformation t: G⇒H, nomatch N→G must be found
G H
L Rp
mN
nac
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 19
About graph transformation
Example: Pull Up Method refactoringnode attributes needed
to express name and visibility of methodsto constrain (or modify) visibility of methods
negative application conditions (NAC) neededMethod signature of method to be pulled up should be absentin ancestorsMethod to be pulled up should not be private
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 20
About graph transformation
Example: Pull Up Method refactoring part 1 (P1)left-hand side L right-hand side RNAC
NAC
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 21
About graph transformation
For composite graph productions, we need tocontrol their order of application by means of
sequencingbranchinglooping
For example
supported by Fujaba using story diagram notation
IntroductionExperiment 1Experiment 2
ConclusionsExperiment 3
First Experiment
Specifying and analysing refactorings in AGG
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 24
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Specifying refactorings in AGG
Concrete Scenario: Suggest refactoringopportunities
What are the alternatives of a selected refactoring? Which refactorings need to be applied first in orderto make the selected refactoring applicable? Which other refactorings are still applicable afterapplying the selected refactoring?
Goal: Automate the detection of mutual exclusion relationships between refactorings sequential dependencies between refactorings
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 25
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Specifying refactorings in AGG
Step 1: Express object-oriented metamodel as(attributed) type graph
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 26
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Specifying refactorings in AGG
Step 2: Express refactorings as (typedattributed) graph transformations
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 27
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Step 3: Statically detect critical pairs betweenrefactoring transformations
Potential conflicts between refactorings
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 28
G H1
H2
T1
T2
X
T2
XT1
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Approach: Use critical pair analysis in AGGT1 and T2 form a critical pair if
they can both be applied to the same initial graph G butapplying T1 prohibits application of T2 and/or vice versa
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 29
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Conflict dependency graph
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 30
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Step 4: Fine-tune critical pairs in context ofconcrete input graph
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 31
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Step 4: Fine-tune critical pairs in context ofconcrete input graph
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 32
Refactoring dependency analysisExperiment 1Introduction
Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 33
Refactoring dependency analysisExperiment 1Introduction
Experiment 2
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 34
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3Refactoring dependency analysis
Step 5: Perform sequential dependency analysis
To identify dependencies betweenrefactorings that are applicable
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 35
Refactoring dependency analysis
Sequential dependency graph for refactorings
Experiment 1Introduction
Experiment 2
ConclusionsExperiment 3
Second Experiment
Comparing two tools for performingtransformation dependency analysis:
AGG and Condor
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 40
Comparing AGG and Condor
Goal Compare two tools for transformation dependencyanalysis
AGG tool, based on graph transformation Condor tool, based on logic programming
Compare their advantages and shortcomings based onobjective criteria
Expressiveness Precision Genericity Performance Mechanisms
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 41
First Approach: AGG
Graph Transformation
Tool support: AGG Implements formal notion of critical pair analysis Corresponds to notion of conflict between parallelgraph transformations Also allows detection of sequential dependenciesbetween graph transformations Implemented in Java
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 42
Second Approach: Condor
Conditional Transformation (CT)
Tool support JTransformer
runtime for execution of CTs on Java programs Condor = Conflict Dectector
analyses dependencies between conditional programtranformations conflicts are particular classes of cyclic dependencies not restricted to Java program transformations
implemented in Prolog
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 43
Experimental Setup
refactoring case study too complex canonical simple study
labelled typed graphs can be used to represent any software artefact
8 basic primitive transformations
AddEdge AddNodeDeleteEdge DeleteNodeRenameEdge RenameNodeRetypeEdge RetypeNode
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 44
Specification in AGG
Specify metamodel as type graph
Specify transformations as typed graphtransformations with negative applicationconditions
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 45
Specification in AGG
LHS RHSNAC
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 46
Specification with logic-basedapproach
Metamodel is represented using logic terms
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
Term representationOriginal artefact
graphNode(n1, class)graphNode(n2, field)graphEdge(e1, n1, n2,contains)
package(1, 0, 'demo') class(2, 1, 'C') method(3, 2, 'm' ,void,[4],5) param(4, 3, 's' , 100) block(5, 3, [6]) call(6, 5, null, 3 ) ident(7, 6, 4 )
package demo;class C { void m( String s) { m(s);}}
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 47
Specification with logic-basedapproachct( addEdge(E,N1,N2,T), % head ( graph_node(N1,_), graph_node(N2,_), % condition not(graphEdge(E, N1, N2, _)) ), ( add(graphEdge(E, N1, N2, T)) ) ). % transformation
ct( delEdge(E, N1, N2, T), % head( graphEdge(E, N1, N2, T)), % condition( delete(graphEdge(E, N1, N2, T)))). % transformation
ct( retypeEdge(E, N1, N2, T, Tnew), % head ( graphEdge(E, N1, N2, T) ), % condition ( replace(graphEdge(E, N1, N2, T), % transformation graphEdge(E, N1, N2, Tnew)))).
ct( renameEdge(E, N1, N2, T, Enew), % head ( graphEdge(E, N1, N2, T), % condition not(graphEdge(Enew, _, _, _)) ), ( replace(graphEdge(E, N1, N2, T), % transformation graphEdge(Enew, N1, N2, T)))).
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 52
Analysing conflicts in AGG Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 53
Analysing dependencies in AGG Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 54
addNode delNode
renameNode retypeNode
renameEdge retypeEdge
addEdge delEdge
42
45, 46
60, 61
47
5241
51
4344 55
62
68
53
50
67
70
72 63
6459
54
71
49
66
48
65
57, 5
8
6956
Analysing conflicts in Condor Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 55
addNode delNode
renameNode retypeNode
renameEdge retypeEdge
addEdge delEdge
17
18, 19
1023
20
2425
34
22
29
28
38
39
35
21
14
30
40
27
37
26
36
32, 3
3
1531
9
12, 13
11
16
Analysing dependencies in CondorExperiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 56
Results of comparison
more expressive (full Prolog)less expressive (due toNACs)
expressiveness
0,2 seconds !7m 38s (conflicts)9m 17s (dependencies)
timing results
unificationbacktracking
graph matchinggraph equivalence
mechanismsused
PrologJavaimplementationlanguage
conditional transformationgraph transformationcritical pair analysis
technique usedCondorAGG
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 57
Results of comparison
Both tools generate same results32 dependencies and conflicts
Specifying transformations is more intuitive in AGG (visual notation) less expressive in AGG
restricted expressiveness of NACs no code-level elements
to avoid diagrams cluttered beyond comprehension
Detecting conflicts and dependencies is several orders of magnitude more performant inCondor seconds versus hours
Experiment 2Experiment 1Introduction
ConclusionsExperiment 3
Third experiment
Model inconsistency management in AGG
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 59
Model inconsistency management
GoalSpecify model inconsistencies and their resolutionstrategies as graph transformation rulesUse this to automate the resolution processAnalyse their interdependencies to optimise thisprocess
Experiment 3
Experiment 1Introduction
Conclusions
Experiment 2
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 60
Model inconsistency management
Inconsistency management process
Experiment 3
Experiment 1Introduction
Conclusions
Experiment 2
Conclusions
topics for discussion
further reading
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 62
Topics for discussion(pick your choice)
How to develop an efficient GT engine?scalable to industrial software applicationsa logic-based approach seems to be more efficientfor execution and analysis!What is the source of the performance gap? Graphmatching versus unification / backtracking?
How to compare/combine graph rewriting withother approaches?
tree rewriting, text rewriting, …
Conclusions
Experiment 2Experiment 1Introduction
Experiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 63
Topics for discussion(pick your choice)
How to apply GT in the context of MDE ?How to analyse GT?How to increase their
expressivenessreusabilitygenericitycomposability, …
How to come to a reflective GT engine ?Treat GT’s as first-class entities that can be subjectto transformation themselves
Conclusions
Experiment 2Experiment 1Introduction
Experiment 3
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 64
Conclusions
Experiment 2Experiment 1Introduction
Experiment 3Further reading
Journal articles Analysing refactoring dependencies using graphtransformations
T. Mens, G. Taentzer, O. Runge. To appear in SoSyM journal,2006
A formal approach to model refactoring and modelrefinement
R. Van Der Straeten, T. Mens, V. Jonckers. To appear inSoSyM journal, 2006
Formalising refactorings with graph transformations T. Mens, N. Van Eetvelde, S. Demeyer, D. Janssens. JSME,2005
A survey of software refactoring T. Mens, T. Tourwé. IEEE Trans. Softw. Eng., 2004
© Tom Mens, Invited Talk, University of Bremen, 26 January 2006 65
Conclusions
Experiment 2Experiment 1Introduction
Experiment 3Further reading
Regular articles Transformation dependency analysis: a comparison oftwo approaches
T. Mens, G. Kniesel, O. Runge. Proc. LMO 2006 On the use of graph transformations for modelrefactoring
T. Mens. Post-proceedings of GTTSE summer school, 2006 Towards automating source consistent UMLrefactorings
P. Van Gorp, H. Stenten, T. Mens, S. Demeyer. Proc. UML2003, LNCS 2863
Formalising behaviour preserving programtransformations
T. Mens, S. Demeyer, D. Janssens. Proc. ICGT 2002, LNCS2505
top related