transformation dependency analysis based on graph...

Tom Mens ([email protected])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


Challenge: Model-driven evolution

ObservationModel-driven software engineering approaches do notadequately address software evolution problemsNeed better support (tools, formalisms) for




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




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 …




Motivation

Challenge

How to automate transformation dependencyanalysis?

How to exploit it to provide better tool support forsoftware engineering activities?




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




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




About AGGIntroduction

Experiment 1Experiment 2



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





Exemple: Pull Up Method refactoring

left-hand side L right-hand side R





Exemple: Pull Up Method refactoringSome nodes and edges are preserved





Exemple: Pull Up Method refactoringSome nodes and edges are deleted





Exemple: Pull Up Method refactoringSome nodes and edges are added





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





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





More advanced GT features Negative application conditions (NACs) Set nodes (multi objects) Attributed graphs and GTs Programmed graph transformation Graph grammars





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





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





Example: Pull Up Method refactoring part 1 (P1)left-hand side L right-hand side RNAC

NAC





For composite graph productions, we need tocontrol their order of application by means of

sequencingbranchinglooping

For example

supported by Fujaba using story diagram notation



First Experiment

Specifying and analysing refactorings in AGG


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



Experiment 2


Step 1: Express object-oriented metamodel as(attributed) type graph



Experiment 2


Step 2: Express refactorings as (typedattributed) graph transformations



Experiment 2

ConclusionsExperiment 3Refactoring dependency analysis

Step 3: Statically detect critical pairs betweenrefactoring transformations

Potential conflicts between refactorings


G H1

H2

T1

T2

X

T2

XT1


Experiment 2


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



Experiment 2


Conflict dependency graph



Experiment 2


Step 4: Fine-tune critical pairs in context ofconcrete input graph


Refactoring dependency analysisExperiment 1Introduction

Experiment 2




Experiment 2


Step 5: Perform sequential dependency analysis

To identify dependencies betweenrefactorings that are applicable


Refactoring dependency analysis

Sequential dependency graph for refactorings


Experiment 2


Second Experiment

Comparing two tools for performingtransformation dependency analysis:

AGG and Condor


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



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




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




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




Specification in AGG

Specify metamodel as type graph

Specify transformations as typed graphtransformations with negative applicationconditions




Specification in AGG

LHS RHSNAC




Specification with logic-basedapproach

Metamodel is represented using logic terms



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);}}


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)))).




Analysing conflicts in AGG Experiment 2Experiment 1Introduction



Analysing dependencies in AGG Experiment 2Experiment 1Introduction



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



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



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




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



Third experiment

Model inconsistency management in AGG


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


Conclusions

Experiment 2


Model inconsistency management

Inconsistency management process

Experiment 3


Conclusions

Experiment 2

Conclusions

topics for discussion

further reading


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 3


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 3


Conclusions


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


Conclusions


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

transformation dependency analysis based on graph...

Documents