An Extensible Platform for the Analysis of Graph ... · for the Analysis of Graph Transformation Systems using Constraint Handling Rules ... 2.4 Eclipse ... 3.4.6.2 Zest

An Extensible Platformfor the Analysis of Graph

Transformation Systems usingConstraint Handling Rules

Mathias WasserthalUniversität UlmFakultät für Ingenieurwissenschaftenund InformatikInstitut für Programmiermethodik undCompilerbauFebruar 2009Diplomarbeit imStudiengang Informatik

Gutachter:Prof. Dr. FrühwirthProf. Dr. von Henke

Betreuer:Frank Raiser

Fassung 10. Februar 2009c© 2009 Mathias Wasserthal

Satz: PDF-LATEX 2ε

Contents

1 Introduction 11.1 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Finding circular lists . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.2 Dining philosophers . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Organization of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Preliminaries 52.1 Constraint Handling Rules (CHR) . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Operational semantics . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Graph Transformation Systems (GTS) . . . . . . . . . . . . . . . . . . . . 92.2.1 Definitions: Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Definitions: Graph transformation system . . . . . . . . . . . . . . 102.2.3 Double pushout as a gluing construction . . . . . . . . . . . . . . . 122.2.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 CHR encoding of GTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1 The platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Plug-ins and extension points . . . . . . . . . . . . . . . . . . . . 21

3 Conception 233.1 Available GTS tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 AGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1.2 Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 Requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 Finding the right tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 Model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.1.1 JGraphT . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.1.2 JGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.1.3 EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.2 Graphical editors . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.2.1 Graphical Editing Framework (GEF) . . . . . . . . . . . 303.4.2.2 Graphical Modeling Framework (GMF) . . . . . . . . . 313.4.2.3 JGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.2.4 yFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.3 Textual editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.3.1 JCHRIDE . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.3.2 XText . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

iii

Contents

3.4.3.3 Textual Editing Framework (TEF) . . . . . . . . . . . . 323.4.4 CHR environments . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4.4.1 Java Constraint Kit (JaCK) . . . . . . . . . . . . . . . . 333.4.4.2 K.U. Leuven JCHR . . . . . . . . . . . . . . . . . . . . 33

3.4.5 Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.5.1 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.5.2 Java Emitter Templates (JET) . . . . . . . . . . . . . . . 34

3.4.6 Graph layout and visualization . . . . . . . . . . . . . . . . . . . . 343.4.6.1 JGraph, yFiles . . . . . . . . . . . . . . . . . . . . . . . 343.4.6.2 Zest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.7 Suitability of the tools . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Realization 374.1 GTS model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.1.2 Editing commands . . . . . . . . . . . . . . . . . . . . . 38

4.1.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.2.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.2.2 Editing commands . . . . . . . . . . . . . . . . . . . . . 43

4.2 The platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1.1 Graphical user interface . . . . . . . . . . . . . . . . . . 454.2.1.2 Extendability . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.2.1 Multi-bar editor . . . . . . . . . . . . . . . . . . . . . . 494.2.2.2 Saving/Loading GTS models . . . . . . . . . . . . . . . 504.2.2.3 Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.2.4 Extension point . . . . . . . . . . . . . . . . . . . . . . 504.2.2.5 Action bar . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 The graphical editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.2.1 Model View Controller (MVC) . . . . . . . . . . . . . . 544.3.2.2 Edit policies . . . . . . . . . . . . . . . . . . . . . . . . 574.3.2.3 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.2.4 Tools and actions in the editors . . . . . . . . . . . . . . 60

4.3.3 Sample computation . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 The textual editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.1.2 Encoding/decoding algorithms . . . . . . . . . . . . . . 674.4.1.3 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.2.1 Grammar and model . . . . . . . . . . . . . . . . . . . . 734.4.2.2 Encoding/decoding algorithms . . . . . . . . . . . . . . 744.4.2.3 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.4.3 Sample computation . . . . . . . . . . . . . . . . . . . . . . . . . 764.5 How to create a tool: The termination analysis tool . . . . . . . . . . . . . 78

4.5.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.5.1.1 Ranking functions . . . . . . . . . . . . . . . . . . . . . 784.5.1.2 Graphical user interface . . . . . . . . . . . . . . . . . . 79

4.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.6 The CHR based analysis tool . . . . . . . . . . . . . . . . . . . . . . . . . 82

iv

Contents

4.6.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.6.1.1 CHR analysis tools extension point . . . . . . . . . . . . 824.6.1.2 Graphical user interface . . . . . . . . . . . . . . . . . . 834.6.1.3 Code generation . . . . . . . . . . . . . . . . . . . . . . 834.6.1.4 Compiler tool . . . . . . . . . . . . . . . . . . . . . . . 85

4.6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.6.2.1 Extension point . . . . . . . . . . . . . . . . . . . . . . 854.6.2.2 Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.6.2.3 Code generation . . . . . . . . . . . . . . . . . . . . . . 864.6.2.4 How to create a CHR tool: Compiler tool . . . . . . . . . 88

4.7 The graphical analysis tool . . . . . . . . . . . . . . . . . . . . . . . . . . 904.7.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.7.1.1 Interactive CHR environment . . . . . . . . . . . . . . . 904.7.1.2 Code generation . . . . . . . . . . . . . . . . . . . . . . 964.7.1.3 Graphical user interface . . . . . . . . . . . . . . . . . . 964.7.1.4 Synchronization of display and handler . . . . . . . . . . 98

4.7.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.7.2.1 Generation of the JCHR handler and its interface . . . . . 984.7.2.2 Loading of the generated files . . . . . . . . . . . . . . . 1004.7.2.3 Using the generated handler . . . . . . . . . . . . . . . . 101

4.7.3 Sample computation . . . . . . . . . . . . . . . . . . . . . . . . . 1044.8 Further analysis tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.8.1 Random host generation tool . . . . . . . . . . . . . . . . . . . . . 1054.8.2 Confluence analysis . . . . . . . . . . . . . . . . . . . . . . . . . 105

5 Conclusion 1095.1 Summary of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Bibliography 111

A Installation guide and CD content 115A.1 CD content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.2 Installation Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

B Introduction to category Theory 117B.1 Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117B.2 Morphisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.3 Pushouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

C Source Code 121C.1 Example commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121C.2 GTS analysis tool extension point . . . . . . . . . . . . . . . . . . . . . . 122C.3 CHR analysis tool extension point . . . . . . . . . . . . . . . . . . . . . . 123C.4 JET Template for JCHR code generation . . . . . . . . . . . . . . . . . . . 124C.5 CHR editor validity and update algorithm . . . . . . . . . . . . . . . . . . 126C.6 Full TEF grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

v

Contents

vi

List of Figures

1.1 Shortening a circular list . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The dining philosophers problem . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Transitions for the refined semantics . . . . . . . . . . . . . . . . . . . . . 82.2 Example for gcd solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Type and typed graph example . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Typed graph transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Typed graph transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Double pushout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Type graph for dining philosophers . . . . . . . . . . . . . . . . . . . . . . 142.8 Typed graph for dining philosophers . . . . . . . . . . . . . . . . . . . . . 152.9 Rules for dining philosophers . . . . . . . . . . . . . . . . . . . . . . . . . 162.10 Two graph notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.11 One graph notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.12 Screen-shot of the eclipse workbench . . . . . . . . . . . . . . . . . . . . 212.13 Components of the eclipse platform . . . . . . . . . . . . . . . . . . . . . 22

3.1 Screen-shot of AGG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Screen-shot of Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Schematics of the MVC pattern . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 UML class diagram for graphs . . . . . . . . . . . . . . . . . . . . . . . . 384.2 UML class diagram for GTS . . . . . . . . . . . . . . . . . . . . . . . . . 394.3 Problematic model states . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Problematic model states . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Problematic model states . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 The multi-bar editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.7 Action bar of the multi-bar editor . . . . . . . . . . . . . . . . . . . . . . . 464.8 Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.9 Flow of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.10 Multi-bar and multi-page editor . . . . . . . . . . . . . . . . . . . . . . . . 494.11 Graphical type graph editor . . . . . . . . . . . . . . . . . . . . . . . . . . 534.12 Graphical host graph editor . . . . . . . . . . . . . . . . . . . . . . . . . . 534.13 Graphical host graph editor . . . . . . . . . . . . . . . . . . . . . . . . . . 544.14 Graphical rule graph editor . . . . . . . . . . . . . . . . . . . . . . . . . . 554.15 Add and remove graph actions . . . . . . . . . . . . . . . . . . . . . . . . 554.16 Graphical editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.17 MVC update mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.18 Flow of information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.19 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 614.20 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 624.21 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 624.22 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 634.23 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 634.24 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 644.25 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 65

vii

List of Figures

4.26 Sample computation (graphical editor) . . . . . . . . . . . . . . . . . . . . 654.27 Host graph encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.28 Rule graph encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.29 Host graph encoding verification algorithm . . . . . . . . . . . . . . . . . 684.30 Rule graph verification algorithm . . . . . . . . . . . . . . . . . . . . . . . 694.31 CHR model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.32 Annotation mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.33 CHR editor actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.34 Sample computation (textual editor) . . . . . . . . . . . . . . . . . . . . . 774.35 Sample computation (textual editor) . . . . . . . . . . . . . . . . . . . . . 774.36 Sample computation (textual editor) . . . . . . . . . . . . . . . . . . . . . 784.37 Termination analysis for dining philosophers . . . . . . . . . . . . . . . . . 794.38 Termination analysis for circular lists example . . . . . . . . . . . . . . . . 804.39 Communication of tools and platform . . . . . . . . . . . . . . . . . . . . 834.40 CHR based tool’s GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.41 CHR compile tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.42 Use case diagram for the graphical simulation tool . . . . . . . . . . . . . . 974.43 Select and order rule graphs . . . . . . . . . . . . . . . . . . . . . . . . . 974.44 Simulation of GTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.45 Interaction of the JCHR handler and the IGTSFacade . . . . . . . . . . . 1024.46 Finding matches and applying rules with the JCHR handler . . . . . . . . . 1034.47 Dialog to adjust code generation . . . . . . . . . . . . . . . . . . . . . . . 1044.48 Host graph in graphical simulation tool . . . . . . . . . . . . . . . . . . . . 1044.49 Rule application in graphical simulation tool . . . . . . . . . . . . . . . . . 1054.50 Highlighted match morphism . . . . . . . . . . . . . . . . . . . . . . . . . 1064.51 Modified host graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.52 Random host generation GUI . . . . . . . . . . . . . . . . . . . . . . . . . 107

viii

List of Tables

4.1 Allowed combinations for rules . . . . . . . . . . . . . . . . . . . . . . . . 414.2 Table of editing commands . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Important methods of AbstractGraphicalEditpart . . . . . . . . . 564.4 Available EditPart classes . . . . . . . . . . . . . . . . . . . . . . . . . 574.5 IGTSFacade methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.6 AbstractGTSFacade abstract methods . . . . . . . . . . . . . . . . . . 99

ix

List of Tables

x

Listings

2.1 plugin.xml example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1 NodeDeleteCommand snippet . . . . . . . . . . . . . . . . . . . . . . . 444.2 ChangeRuleGraphCommand snippet . . . . . . . . . . . . . . . . . . . 454.3 Load extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 Start analysis tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5 getCreateCommand() snippet . . . . . . . . . . . . . . . . . . . . . . 584.6 DeleteGraphAction snippet . . . . . . . . . . . . . . . . . . . . . . . 594.7 Conditional implementation snippet . . . . . . . . . . . . . . . . . . . 604.8 CHR grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.9 plugin.xml snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.10 Termination analysis tool snippet . . . . . . . . . . . . . . . . . . . . . . . 814.11 runAnalysis() snippet . . . . . . . . . . . . . . . . . . . . . . . . . . 814.12 JCHR Fibonacci example . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.13 JET template snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.14 Start a JET transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 874.15 plugin.xml snippet for CHR tools . . . . . . . . . . . . . . . . . . . . 884.16 startAnalysis() snippet . . . . . . . . . . . . . . . . . . . . . . . . 894.17 JET template for activateRule() method . . . . . . . . . . . . . . . . 994.18 Generated activateRule() method . . . . . . . . . . . . . . . . . . . 1004.19 Generated code for new host graphs . . . . . . . . . . . . . . . . . . . . . 1004.20 Add a plug-in as dependency of a project . . . . . . . . . . . . . . . . . . 101C.1 The NodeDeleteCommand class . . . . . . . . . . . . . . . . . . . . . . . 121C.2 Definition for the entries in the plugin.xml . . . . . . . . . . . . . . . . . . 122C.3 Source code of the interface . . . . . . . . . . . . . . . . . . . . . . . . . 122C.4 Definition for the entries in the plugin.xml . . . . . . . . . . . . . . . . . . 124C.5 Source code of the interface . . . . . . . . . . . . . . . . . . . . . . . . . 124C.6 JET template for JCHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124C.7 Rule validity and update algorithm . . . . . . . . . . . . . . . . . . . . . . 127C.8 TEF grammar for CHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

xi

Listings

xii

List of abbreviations

AGG Attributed Graph Grammar, system for creation and analyzing GTS

CHR Constraint Handling Rules, a rule-based declarative language

CCHR CHR implementation in C

CD Compact Disc

DPO Double Pushout, construction in category theory

EMF Eclipse Modeling Framework, create source code from model definitions

GEF Graphical Editing Framework, framework for the creation of graphical editors foreclipse

GMF Graphical Modeling Framework, framework for the model-driven development ofgraphical editors for eclipse.

Groove Graphs for Object Oriented Verification, system for the creation and analyzingGTS

GTS Graph Transformation Systems, rule-based formalism for the modification of graphs

GUI Graphical User Interface

IDE Integrated Development Environment

JaCK Java Constraint Kit, CHR environment for java

JAR Java Archive file, file containing executable java programs

JASE Java Abstract Search Engine, search mechanisms for java

JavaDoc Documentation generated from annotated java source code

JCHR The K.U. Leuven JCHR system, a CHR environment for java

JCHRIDE Eclipse text editor for JCHR

JET Java Emitter Templates, a code generator for java

JGraph Framework for creating graphical editors for graphs in java

JGraphT Library for representing graphs in java

MVC Model View Controller, a paradigm for the realization of GUIs

oAW openArchitectureWare, a framework for model-driven development

PO Pushout, construction in category theory

PDE Plug-in Development Environment for eclipse

PDF Portable Document Format

RCP Rich Client Platform, client software based on eclipse

xiii

Listings

Swing Framework for GUI used in java applications

SWT Standard Widget Toolkit, framework for GUIs used by eclipse

TEF Textual Editing Framework, framework for text to model transformations in eclipse

TMF Textual Modeling Framework, framework for model-driven development of text tomodel transformations in eclipse

UI User interface

UML Unified Modeling Language

XPath Query language for XML files

XSLT Extensible style-sheet language transformations, language for text to text transfor-mations

XText Textual editor and parser for the TMF

yFile Framework for creating editors for graphs in java

xiv

1 Introduction

Graphs are one of the fundamental structures in computer science and can be used to modela large variety of aspects. They represent an easy way of displaying certain structures (e.g.road maps), concepts (e.g. flowcharts), and relations (e.g. UML class diagrams).

Graph Transformation Systems (GTS) ([18]) provide the means to manipulate graphs in arule based manner. GTS use rules which describe a graph before and after the applicationof the rule. These rules can be applied to host graphs in order to modify them. GTS haveapplications not only in theoretical computer science, but also in the fields of visual mod-eling techniques, model transformations, and concurrent distributed systems. Therefore,GTS are often embedded in other projects, but there are only few general purpose develop-ment environments that enable you to create and analyze GTS. Graphs for Object OrientedVerification (Groove) ([33]) and Attributed Graph Grammar (AGG) ([18]), to name two ofthese environments, both have graphical editors for GTS. Furthermore, the tools provideanalysis methods for GTS, e.g. analysis of critical pairs ([18]).

Another rule based formalism are Constraint Handling Rules (CHR) ([20]). A CHR pro-gram is described by rules which modify a constraint store by adding and removing con-straints from it. CHR has a large variety of applications including scheduling, agents, spa-tial or temporal reasoning, and verification. Additionally, CHR programs can be analyzedin various ways, e.g. termination analysis or operational equivalence analysis.

Implementations of CHR exist for various programming languages. Besides that, CHR canbe used to describe, execute, and analyze GTS, as well ([32]). To do that, rules of a GTSare expressed as rules in CHR and graphs can be expressed as lists of constraints.

In the remainder of this chapter, I present the state of the art in GTS tools, CHR implemen-tations, and integrated development environments in section 1.1. Based on this, I motivatemy thesis in section 1.2. In section 1.3, I present two examples that are used throughoutthe thesis.

1.1 State of the art

The tools mentioned above for the creation and analysis of GTS (Groove, AGG) offer animpressive list of features. AGG provides a graphical editor to define graphs and rules.Further editing features are the introduction of graph constraints and negative applicationconditions which restrict the applicability of rules. It provides methods to test the rules forconfluence, i.e. it is checked whether the resulting graphs are isomorphic when rules areapplied in an arbitrary order. Groove also has a graphical editor to create and edit graphs.This editor is, however, based on entering keywords to describe properties of nodes andedges of a graph, but no graphical user interface elements like context menus are provided.Groove also has interesting analysis features. It can, for example, display the exploredstate space when running the GTS. Each intermediate graph, called the state of a graph, towhich the original graph can be transformed is shown as a node. The rules that are neededto reach one state from another are displayed as edges in this graph. However, not thefull state space is displayed but nodes representing isomorphic graphs are merged into onenode. Both tools offer the possibility to apply rules to a given host graph, so that the GTS

1

1 Introduction

can be tested on chosen inputs. An Application Programming Interface (API) to extend thefunctionality of the systems is not available in both tools.

Implementations of CHR exist in many languages, for example Prolog, java, and C ([39]).The earliest implementations of CHR are based on logic programming languages ([24]).The most widely used system is K.U. Leuven CHR which is implemented on top of cer-tain Prolog based languages, e.g. SWI-Prolog ([38]) and Sicstus-Prolog ([36]). There arealso implementations available for the functional language Haskell, e.g. HaskellCHR1 andTaiChi ([5]). Concurrent CHR ([28]) is a CHR implementation that can be run concur-rently and is implemented in Haskell. Implementations for java are the Java ConstraintKit (JaCK) ([2]) and the K.U. Leuven JCHR System (JCHR) ([40]). CCHR ([45]) is animplementation of CHR for the programming language C.

Eclipse2 is an open-source platform for creating Integrated Development Environments(IDE). Eclipse is written in java and has many technologies available that make the de-velopment of IDEs comfortable. For example, it already provides frameworks that allowthe creation of custom graphical and textual editors. Eclipse is based around plug-ins, sothat developers can extend the functionality of eclipse based on already available plug-indefinitions or create new plug-in definitions that can be used by other developers. IDEs canalso be distributed as Rich Client Platforms (RCP), so that only the functionality of the IDEis provided without having to install a whole eclipse system.

1.2 Motivation

As mentioned above, AGG and Groove are not extensible with further analysis or editingmethods. They do not provide all the features that may be needed for the design of a GTS.AGG, for example, offers a confluence analysis for the rules while Groove can explorethe whole space of graphs that can be created with the rules. Both features are great fordesigning GTS, but they are not available in one single tool and none of the tools has adocumented API for extending it with the desired functionality. Furthermore, Frank Raiserdiscovered that GTS can easily be encoded in CHR ([32]), so that GTS can be simulatedwith CHR. Because of that, analysis methods for CHR can also be applied to a GTS. TheCHR notation of rules and graphs yields a simple textual representation of a GTS that canbe used for editing, as well. Additionally, eclipse already provides frameworks to creategraphical and textual editors and allows the creation of custom plug-in definitions that canbe used by other developers to extend the functionality.

For these reasons, I have decided to develop a new platform that is based on eclipse andprovides the possibility to create, edit, and analyze GTS in combination with CHR. Thisplatform must have a graphical editor similar to those in AGG and Groove, but the Graph-ical User Interface (GUI) should offer a better usability. As GTS can be encoded in CHR,the graphs and rules of the GTS should also be displayed in this encoding. As the encodingprovides a textual representation of a GTS, support for editing the GTS via the CHR en-coding must also be provided. Additionally, this new platform should be easily extensibleto support further analysis methods. Therefore, a common API must be available for theplatform to add tools for analysis and editing purposes. To demonstrate the capabilities ofthe platform, selected analysis tools should be provided. The most important ones are atool to simulate a GTS based on CHR and a tool that allows the easy embedding of CHRanalysis methods.

1by Gregory J. Duck, 2004. Download: http://www.cs.mu.oz.au/~gjd/haskellchr/2Available at http://www.eclipse.org/

2

http://www.cs.mu.oz.au/~gjd/haskellchr/

http://www.eclipse.org/

1.3 Examples

Figure 1.1: A circular list consisting of four nodes (a)), after removing one node (b)), withonly two nodes (c)), and only one node (d)).

1.3 Examples

I have chosen two examples to show the features of the developed platform. First, anexample for detecting circular lists from a graph is presented. The second example is thedining philosophers problem.

1.3.1 Finding circular lists

This is an example which finds circular lists in directed graphs. Figure 1.1 a) shows a graphconsisting of four nodes that are connected in a circle. The algorithm to find circular liststries to shorten linked lists of three nodes in a row. Therefore, from each linked list withthree nodes in the graph, the middle node is removed and replaced by an edge connectingthe two remaining nodes (figure 1.1 b)). This is repeated until only two nodes are left(figure 1.1 c)) that are connected to each other. These two nodes are then replaced by onenode with a loop (figure 1.1 d)).

The result of this algorithm is a new graph. If the graph only contains one node with asingle loop, then the original graph was a cyclic list. Else, the graph was no cyclic list. Thisis a useful example for demonstrating the encoding of GTS to CHR (section 2.3.2) and isused as an example throughout the thesis.

1.3.2 Dining philosophers

The dining philosophers problem is an illustrative example for multi-process synchroniza-tion problems which is a common computing problem in concurrency ([8]). The problemis that n philosophers are sitting next to each other on a round table. Every philosopher hasa plate with spaghetti in front of him. There is also one fork between every two of themresulting in n forks on the table. Each philosopher can either think, wait until he can take

3

1 Introduction

Figure 1.2: Illustration of the dining philosophers problem with five philosophers (fromhttp://en.wikipedia.org/wiki/File:Dining_philosophers.png).

the two forks lying next to him, or eat his spaghetti (if he has the two forks). Figure 1.2illustrates this. This problem is an example of multiple processes (the philosophers) whichneed multiple shared resources (the forks).

A problem that can arise is, that each philosopher takes the fork to his left and waits for thefork of the philosopher to his right, so that he can start to eat. But none of them will ever gettwo forks because all are waiting. This is called a deadlock state. Another problem is, thatsome of the philosophers may never get the chance to eat. This is the so called starvationproblem. These are problems that can occur between multiple processes (the philosophers)which are concurrently accessing shared resources (the forks). The porting of this problemto GTS is shown in section 2.2 and its encoding to CHR in section 2.3.

1.4 Organization of the thesis

The main part of this thesis is grouped into four parts:

• Chapter 2 describes the theoretical background of GTS, CHR, and eclipse

• Chapter 3 describes the goals and requirements which are a result of the conceptionphase. Based on this, tools are analyzed which can realize the requirements.

• Chapter 4 describes the design and implementation of the project in order to fulfillthe goals and requirements. Theoretical aspects needed for the realization are alsoexplained here.

• Chapter 5 summarizes the results of the thesis and provides ideas on the furtherdevelopment of the project. Furthermore, possible application areas are shown.

4

http://en.wikipedia.org/wiki/File:Dining_philosophers.png

2 Preliminaries

In this chapter, I give a short introduction to Constraint Handling Rules (CHR), GraphTransformation Systems (GTS), and eclipse. As mentioned in section 1.2, CHR can be usedto simulate GTS. Therefore, I first give a small introduction to CHR. Afterward, I give anintroduction to GTS. GTS are described here with an algebraic approach which is based oncategory theory. The mathematical background for category theory is covered in appendixB. Other approaches to GTS can be found in [41] and [19]. After the introductions to GTSand CHR, I show how to encode GTS to CHR. As the last topic, I present the architectureof the eclipse platform, because it will be used as framework for this project.

2.1 Constraint Handling Rules (CHR)

Constraint Handling Rules (CHR) are a constraint-based language developed by T. Früh-wirth in 1998. The syntax and operational semantics of CHR are described in this section.This introduction is based on [20] which gives a more comprehensive overview of the topicof CHR.

CHR are a rule based language. A CHR program consists of the declaration of constraints(first-order logic predicates) and a set of rules. Constraints are separated into built-in anduser-defined constraints. Built-in constraints are handled by a constraint solver and user-defined constraints are solved by the CHR program itself.

2.1.1 Syntax

Constraints are defined by giving them a unique combination of a name and an arity. Aconstraint c of arity n is defined as c/n (in Prolog-based systems). An n-ary constraint c isdenoted by

c(t1, . . . , tn)

where t1, . . . , tn are terms. These terms can either be ground, i.e. they represent a constantvalue, be a variable, or be an expression of further terms. Identifiers used in ground termsare lower case identifiers and variable names are given by a name which starts with a capitalletter.

The input is a sequence of user-defined and built-in constraints which is called the goal

G = [G1, . . . , Gn]

where G1, . . . , Gn are user-defined or built-in constraints. Rules are of the form:

Rulename @ H ′1, . . . ,H

′i′\H1, . . . ,Hi ⇔ D1, . . . , Dj |B1, . . . , Bk

where Rulename is an optional unique name for the rule. Hkep := [H ′1, . . . ,H

′i′ ], the

kept constraints, and Hrem := [H1, . . . ,Hi], the removed constraints form the head (de-noted by H := Hkep + Hrem) of the rule. D := {D1, . . . , Dj} is called the guard andB := [B1, . . . , Bk] is the body of the rule. The body consists of user-defined and built-in

5

2 Preliminaries

constraints, whereas the head consists only of user-defined and the guard only of built-inconstraints. Rules of these form are called simpagation rules.

If Hkep = [] then the rule is written as

Rulename @ H1, . . . ,Hi ⇔ D1, . . . , Dj |B1, . . . , Bk

and called a simplification rule. If Hrem = [] then the rule is written as

Rulename @ H ′1, . . . ,H

′i′ ⇒ D1, . . . , Dj |B1, . . . , Bk

and called a propagation rule. Hkep and Hrem must not both be empty.

2.1.2 Operational semantics

There exist several definitions of the operational semantics of CHR depending on howdetailed the operations of a CHR program should be modeled. All operational semanticsare based on a state transition system. The states are a combination of user-defined andbuilt-in constraints. The transitions define how rules are applied to modify these states.Furthermore, a Constraint Theory CT is provided for the state transition system whichcan solve the built-in constraints. The starting state is defined by the goal which is alist of constraints. From a given starting state, the rules of the CHR program are appliedcontinuously to the current state (using the defined transitions) until a contradiction of thebuilt-in constraints occurs or no rules can be applied anymore. Rule application means tofind constraints in the current state that match the constraints in a head H of a rule, sothat the guard D of the rule is implied by the built-in constraints of the state under themeaning of the constraint theory CT . Informally, the constraint of a head is a pattern forwhich a constraint of the input is searched. A constraint from a rule’s head can be matchedto a constraint in the current state if their name and arity are equal and if there exists asubstitution of the form [T/c] or [T/T ′] for variables T , T ′ and constant c, for the terms ofthe two constraints. For a more detailed explanation of a match, see [20].

A very detailed operational semantics, called the refined semantics, is used here. It isadopted from [20]. The CHR program itself is modeled as a sequence of rules and the headand body of rules are sequences of constraints. The guard of a rule is a conjunction ofbuilt-in constraints. Constraints in the heads of the rules are associated with numbers (theiroccurrence). The head constraints are numbered starting from 1 in a top-down order (fromthe first to the last rule) and from left to right. However, constraints in Hrem are numberedbefore constraints in Hkep.

A state is a tuple 〈A,S,B, T 〉νn where A, S, B, T , n, and ν have the following meaning:A is the goal stack, a sequence of built-in and user-defined (unnumbered-, numbered-, andactive) constraints. S is the CHR store, a set of numbered constraints. B is the built-instore, a conjunction of built-in constraints. T is the propagation history, a set of tuples(r, I), where r is the name of a rule and I is the sequence of the identifiers of the numberedconstraints that matched the head constraints of r. n is is the next number that can be usedas an identifier for an unprocessed goal constraint. ν is the sequence of the variables of theinitial goal constraints. Usually ν is omitted, because it does not change between states.An initial state is 〈G, ∅, true, ∅〉ν1 , where G are the unnumbered constraints of the goal andν is the sequence of the variables of G.

The constraints in a state can be labeled in three different ways:

unnumbered constraint Constraints that are still unprocessed by the CHR program.They are denoted by their name and attributes. These constraints appear only in thegoal stack.

6

2.1 Constraint Handling Rules (CHR)

numbered constraint User-defined constraints that have been processed and given anidentifier to distinguish between several occurrences of the syntactically same con-straint. These are denoted as c#i, where i is the unique identifier of the constraint.

active constraint User-defined constraints that should only match with occurrence j ofof constraint c in a given CHR program P . They are denoted as c#i : j, where i isagain the unique identifier of the constraint.

The function chr(c#i : j) = chr(c#i) = c is defined to return the corresponding con-straint to an active or numbered constraint. Accordingly, the function id(c#i) = i returnsthe id of a numbered constraint.

A state is failed if B contains contradictions (i.e. CT |= ∃̄B). A state with consistentbuilt-in constraints and empty goal stack (A = []) is called successful. A state is final ifit is failed or if it is successful and no transitions can be applied anymore. Given a finalstate, its answer is chr(S) and B (a failed state has always false as answer, because B isinconsistent).

Figure 2.1 shows the transitions that are used by the refined semantics (for sequences,the Prolog list notation is used). In the refined semantics the constraints from the goalstack are executed from left to right. If the top-most constraint of the goal stack is a user-defined constraint (that may already be numbered), it is made an active constraint (transition(re)activate). Furthermore, if the constraint was not already numbered before it was acti-vated, it is added to the CHR store as a numbered constraint with the new number n fromthe current state as its identifier. If the topmost constraint of the goal stack is a numberedconstraint c#i : j (the occurrence j of constraint c is in rule r), if matching constraints H ′

for the rule r can be found in the CHR store, if the guard is implied by the built-in storeunder the resulting match H ′, and if the propagation history permits it, the rule is appliedand the constraints of its body and the constraints matched to Hkep are added from left toright to the goal stack. The applied rule together with the identifiers of the matched con-straints is then added to the propagation history (transition apply). The propagation historyis used by the transition rule to reject the re-execution of propagation rules by comparingthe constraints’ identifiers of the match H ′ to the sequences of identifiers in the tuples ofthe propagation history.

If no match for the rule’s head can be found with the current occurrence, the next occurrenceis tested (transition default). However, if the active constraint could not be matched to anyrule, then it is removed from the goal stack, but still remains in the CHR store (transitiondrop). If the top-most constraint in the goal stack is a built-in constraint, then it is addedto the built-in store and constraints in the CHR store might be reconsidered (woken) ifthe newly added built-in from the goal stack further constrains variables of the user-definedconstraint. It is then put back on top of the goal stack (transition solve+wake). The functionwakeUp(S,c,B) defines the constraints that need to be reconsidered if a built-in c is addedto the built-in store B.

Described in an informal way, a CHR program tries to apply rules in a top-down mannerto a growing starting sequences of the goal stack. New constraints from the rule body areadded during rule application to the stack. Therefore, the goal stack may grow during ruleapplication just like function call stacks in imperative programming languages.

2.1.3 Example

In this section, I give an example for the syntax and operational semantics described above.The example is a CHR program for the computation of the greatest common divisor that

7

2 Preliminaries

solve+wake〈[c|A], S, B, T 〉n 7→solve+wake 〈wakeUp(S, c, B) + A, S, B′, T 〉n

where c is a built-in constraint and CT |= ∀((c ∧B) ↔ B′).

activate〈[c|A], S, B, T 〉n 7→activate 〈[c#n : 1|A], c#n ∪ S, B, T 〉n+1

where c is a user-defined constraint.

reactivate〈[c#i|A], S, B, T 〉n 7→reactivate 〈[c#i : 1|A], S, B, T 〉n

where c is a user-defined constraint.

apply〈[c#i : j|A], Hkep ∪Hrem ∪ S, B, T 〉n 7→apply 〈C + H + A, Hkep ∪ S, chr(Hrem) =

H ′rem ∧B, T ∪ {(r, id(Hkep) + id(Hrem))}〉n

where the jth occurrence of a user-defined constraint with the same symbol and arity as c is in thehead H ′

kep\H ′rem of a rule with newly created variables of the formH ′

kep\H ′rem ↔ D|B

where CT |= ∃(B) ∧ ∀(B → ∃x̄(chr(Hkep) = H ′kep ∧ chr(Hrem) = H ′

rem ∧D)) and(r, id(Hkep) + id(Hrem)) 6∈ T . H = [c#i : j] if the occurrence for c is in H ′

kep and H = [] if it isin H ′

rem.

drop〈[c#i : j|A], S, B, T 〉n 7→drop 〈A, S, B, T 〉n

if there is no occurrence j for c.

default〈[c#i : j|A], S, B, T 〉n 7→default 〈[c#i : j + 1|A], S, B, T 〉n

if no other transition is possible in the current state.

Figure 2.1: Transitions for the refined semantics.

8

2.2 Graph Transformation Systems (GTS)

〈[gcd(6), gcd(9)], ∅〉17→activate 〈[gcd(6)#1 : 1, gcd(9)], {gcd(6)#1}〉27→default 〈[gcd(6)#1 : 2, gcd(9)], {gcd(6)#1}〉27→default 〈[gcd(6)#1 : 3, gcd(9)], {gcd(6)#1}〉27→default 〈[gcd(6)#1 : 4, gcd(9)], {gcd(6)#1}〉27→drop 〈[gcd(9)], {gcd(6)#1}〉27→activate 〈[gcd(9)#2 : 1], {gcd(6)#1, gcd(9)#2}〉37→default 〈[gcd(9)#2 : 2], {gcd(6)#1, gcd(9)#2}〉37→apply gcd2 〈[K is 9− 6, gcd(K)], {gcd(6)#1}〉37→solve+wake 〈[gcd(3)], {gcd(6)#1}〉37→activate 〈[gcd(3)#3 : 1], {gcd(6)#1, gcd(3)#3}〉47→default 〈[gcd(3)#3 : 2], {gcd(6)#1, gcd(3)#3}〉47→default 〈[gcd(3)#3 : 3], {gcd(6)#1, gcd(3)#3}〉47→apply gcd2 〈[K is 6− 3, gcd(K), gcd(3#3 : 3)], {gcd(3)#3}〉47→solve+wake 〈[gcd(3), gcd(3)#3 : 3], {gcd(3)#3}〉47→activate 〈[gcd(3)#4 : 1, gcd(3)#3 : 3], {gcd(3)#3, gcd(3)#4}〉57→default 〈[gcd(3)#4 : 2, gcd(3)#3 : 3], {gcd(3)#3, gcd(3)#4}〉57→apply gcd2 〈[K is 3− 3, gcd(K), gcd(3)#3 : 3], {gcd(3)#3}〉57→solve+wake 〈[gcd(0), gcd(3)#3 : 3], {gcd(3)#3}〉57→activate 〈[gcd(0)#5 : 1, gcd(3)#3 : 3], {gcd(3)#3, gcd(0)#5}〉67→apply gcd1 〈[gcd(3)#3 : 3], {gcd(3)#3}〉67→default 〈[gcd(3)#3 : 4], {gcd(3)#3}〉67→drop 〈[], {gcd(3)#3}〉6

Figure 2.2: Example computation of the gcd solver according to the refined semantics.

follows the algorithm of Euclid. This is called the gcd example in the remainder of thiswork. There’s only one user-defined constraint

constraint gcd/1.

that has the arity one. There are two rules

gcd1 @ gcd(0)⇔ true.

gcd2 @ gcd(I)\gcd(J)⇔ J ≥ I, I > 0|K is J − I, gcd(K).

For these two rules in the given order, the constraint gcd(0) has occurrence 1, gcd(J) has 2,and gcd(I) has 3. Figure 2.2 gives a sample computation with the goal [gcd(6), gcd(9)]. Inthis example, the built-in constraints and propagation history are not displayed for simpli-fication reasons. The propagation history is not needed, because there are no propagationrules. Furthermore, the variables constrained in the built-in store are directly replaced inthe goal and CHR store. As one can see, the original constraints from the store are addedone after the other to the CHR store. If there are enough numbered constraints in the CHRstore, so that a rule’s head can match, the matching rule that comes first in the list of rulesis applied and new constraints are added to the top of the goal stack.


The concept of Graph Transformation Systems (GTS) dates back to the late 1960s whenit became a generalization of rewriting techniques for trees. The basic idea of GTS isthe rule-based modification of graphs. This section describes the basic definitions to un-

9

2 Preliminaries

Figure 2.3: Type graph with a typed graph. The dotted arrows represent the graph mor-phism from the typed to the type graph.

derstand GTS. The theoretical basis on which GTS are described here is category theorywhich is described in appendix B. The definitions and notations are adopted from [18]. Theexample illustrations represent a GTS which finds circular lists in graphs as described insection 1.3.1.

2.2.1 Definitions: Graphs

A graph is a tuple G = (VG, EG, srcG, tgtG) with the sets of nodes (VG) and edges(EG) and two functions srcG, tgtG : EG → VG which specify the source and targetnodes of the edges in G. The degree of a node is further defined as degG : VG → N,v 7→ |{e ∈ EG|srcG(e) = v}| + |{e ∈ EG|tgtG(e) = v}|. If the graph can be deductedfrom the context, the subscripts are omitted. A graph morphism f = (fV , fE) : G1 →G2 between two graphs G1 and G2 is a tuple of two functions fV : VG1 → VG2 andfE : EG1 → EG2 that preserve the source and target functions. That means fV ◦ srcG1 =srcG2 ◦fE and fV ◦tgtG1 = tgtG2 ◦fE . A type graph TG is a graph with uniquely labelednodes and edges. A typed graph is a tuple GTG = (G, TG, typeTG

G ) consisting of a graphG, a type graph TG, and a graph morphism typeTG

G : G 7→ TG. A typed graph morphismfTG : GTG

1 7→ GTG2 is defined as a graph morphism that fulfills typeTG

G1◦fTG = typeTG

G2.

If the type graph can be deducted from the context, the superscript is omitted and a typedgraph is denoted as G = (VG, EG, srcG, tgtG, typeG).

In figure 2.3 an example of a type graph and a typed graph can be seen. The type graph hasuniquely labeled nodes and edges while the typed graph has no labels. The dotted arrowsrepresent the graph morphism from the typed graph to the type graph. The type graphconsists only of a node with a loop. That means, that the nodes in an according typed graphcan be connected arbitrarily by edges.

2.2.2 Definitions: Graph transformation system

A graph transformation system gts = (P, TG) is a tuple consisting of a set of typed graphproduction rules P and a type graph TG. A typed graph production rule (or just rule ifthe context is clear) is a tuple of the form p = (L l← K

r→ R) where L, K, and R aretyped graphs (called the rule graphs) and l = K → L and r = K → R are injectivetyped graph morphisms (the superscripts for the type graph are omitted, because it resultsfrom the context). Given a typed graph production p = (L l← K

r→ R), a typed graphG (called the host graph), and a typed graph morphism m : L → G (the match), theapplication of p to G via m (G

p,m⇒ H) is called a typed graph transformation. Intuitively,

10


Figure 2.4: Typed graph transformation. The upper row shows the graphs L, K, and R ofthe production rule twoloop. The lower row shows a host graph that is modifiedby the rule.

Figure 2.5: Typed graph transformation of the rule unhook from the circular list example.

when L is matched (via the match morphism m) to a sub-graph of G, then all vertices andnodes in G\m(L\l(K)) are removed from G resulting in an intermediate graph D (calledthe gluing graph). After that, new nodes and edges are added from R\r(K), so that theresulting graph H = D ] (R\r(K)) is the disjoint union of the graph D and the addednodes and edges in R. Figure 2.4 gives an example of a typed graph transformation. Thetop row shows the rule, the bottom row its application to a host graph. The L graph ofthe rule matches to a sub graph, consisting of two nodes connected to each other. One ofthe two nodes is removed together with the edges and a loop is added to the remainingnode. Elements that are removed are displayed in red in the L graph and elements that areadded are green in the R graph. The dotted lines between the upper and lower left graphis the match m. The rule and transformation example shown in figure 2.5 removes themiddle node of a list of three nodes connected in a row. A new edge is inserted between theremaining two nodes. These two rules represent a GTS for finding circular lists in a graphwhich is explained in section 1.3.1.

11

2 Preliminaries

2.2.3 Double pushout as a gluing construction

The informal description of a typed graph transformation given above corresponds to thecategory theoretical principle of two pushouts, a so called double pushout (DPO). A shortintroduction to category theory can be found in appendix B.

A category C = (ObjC ,MorC , ◦, id) is a tuple and its elements have the following mean-ing: ObjC is a class of objects. For each tuple A,B ∈ ObjC there is a set MorC(A,B) ofmorphisms. ◦ is the concatenation of morphisms in MorC withMorC(B,D) ◦MorC(A,B) → MorC(A,D) and idA ∈ MorC(A,A) is the identitymorphism for every A ∈ ObjC . A morphism f ∈ Mor(A,B) can also be written asf : A→ B.

Informally written, a pushout is the gluing of two objects in a category along a commonobject. Given f : A → B and g : A → C ∈ MorC , then a pushout (PO) (D, f ′, g′) isdefined by a pushout object D and morphisms f ′ : C → D, g′ : B → D with f ′◦g = g′◦fsuch that the following universal property is fulfilled: For all objects X ∈ ObjC withmorphisms h : B → X and k : C → X with k ◦ g = h ◦ f there is a unique morphismx : D → X such that x ◦ g′ = h and x ◦ f ′ = k.

In category theory the category GraphsTG consists of typed graphs (over the type graphTG) as its objects, typed graph morphisms as its morphism and the concatenation of mor-phisms as concatenation operator.

The detailed definition of a pushout for the category GraphsTG can be found in appendixB. The pushout

in GraphsTG can be constructed by creating equivalence classes for the nodes and edgesin B and C where two nodes or edges b ∈ B and c ∈ C are equivalent if b = f(a) andc = g(a). The morphisms f ′ and g′ can then be defined as f ′(c) = [c] ∀c ∈ C andg′(b) = [b] ∀b ∈ B (where [c] and [d] denote the according equivalence classes). Thispushout construction fulfills the following properties:

1. If f is injective (or surjective), then f ′ is injective (surjective)

2. The pair (f ′, g′) is jointly surjective (for every element in D there exists a preimagein C or B)

3. If f is injective and x ∈ D has preimages b ∈ B and c ∈ C with g′(b) = f ′(c) = x,then there is a unique preimage a ∈ A with f(a) = b and g(a) = c.

12


4. If f (and hence also f ′) is injective, then D is isomorphic to D′ = C ]B\f(A).

These properties can easily be proved ([18]): The first property can be shown with theproperties of the equivalence relation. The second property is valid due to the constructionof D, which also implies property three. For the last property, one can show that D′ isisomorphic by giving a bijection b : D′ → D. b(x) = [x] is such a bijection.

The possibility of constructing a pushout in the category GraphsTG can be used to checkif a typed graph production rule p = (L l← K

r→ R) can be applied to a host graph G viaa match m : L → G. The rule p is applicable to the typed graph G if there exists a validcontext graph D, so that K together with l : K → L and n : K → D forms a pushout asdescribed above. However, this definition provides no procedure to check whether a rulecan be applied to a host graph. To apply a rule to a host graph, the context graph D must bea proper graph. An improper graph is a graph which contains edges, that are not connectedto a node. These edges are called dangling edges. The gluing condition defines a criterionthat must be fulfilled, so that a rule can be applied. Given the production rule p, the hostgraph G, and a match morphism m : L→ G, the following three sets are defined

1. The gluing points GP are those nodes and edges in L that are not deleted by p, i.e.GP = l(K)

2. The identification points IP are those nodes and edges in L that are identified by m,i.e. IP = {v ∈ VL|∃w ∈ VL, w 6= v : mV (v) = mV (w)} ∪{e ∈ EL|∃f ∈ EL, f 6= e : mE(e) = mE(f)}

3. The dangling points DP are those nodes in L whose images under m are the sourceor target of an edge in G that does not belong to m(L), i.e.DP = {v ∈ VL|∃ e ∈ EG\mE(EL) : srcG(e) = mV (v) or tgtG(e) = mV (v)}

p and m satisfy the gluing condition if DP ∪ IP ⊆ GP , i.e. a rule can only be appliedif all dangling points and all identification points are also gluing points. However, Raiser([32]) provides a simpler definition that covers only injective matches for nodes and edges,i.e. mV (v) 6= mV (w)∀v, w ∈ VL and mE(e) 6= mE(f)∀e, f ∈ EL. The gluing conditioncan then be posted in the simpler form DP ⊆ GP , because there are no identificationpoints. Furthermore, Raiser describes that non-injective matches can be simulated in thefollowing way: Given the rule p = (L l← K

r→ R) and a non-injective match m : L→ Gfor which m(v) = m(w), v 6= w, v, w ∈ VL, a new rule p′ can be introduced, in which thenodes v and w are merged to a new node vw in all three graphs of the rule. Therefore, thenon-injective match m(v) = m(w) is simulated by matching vw to m(vw) where m(vw)is the same node as m(v) (and m(w)) in G. Consequently, new rules can be introducedfor all combinations of possible non-injective matchings simplifying the gluing conditionto the form above.

Lemma 1. (existence of the context graph) For a typed graph production rulep = (L l← K

r→ R), a typed graph G, and a match m : L → G, the context graphD with the PO (1) exists if and only if the gluing condition is satisfied.

13

2 Preliminaries

Figure 2.6: Double pushout for a rule p = (L l← Kr→ R) and a host graph G.

Figure 2.7: Type graph for the GTS representation of the dining philosophers problem.

The proof can be found in [18] on pages 45 to 46

The lemma stated above provides a way of constructing a direct graph transformation ([18]pp. 46–47). Given a production rule p = (L l← K

r→ R), a typed graph G, and a matchm : L → G, the context graph D can be constructed as follows: D = (G\m(L)) ∪m(l(K)) with the morphism k(K) = m(l(K)) and the morphism f is an inclusion. Ina second step, the final pushout graph H can be constructed from K, n : K → D, andr : K → R in the category GraphsTG. Figure 2.6 shows the two pushouts (1) and (2) thatare used for a graph transformation.

Figure 2.4 shows an example for the construction of D and H . To construct D, the graph Gis taken and m(R\l(K)) is removed from it (the elements marked red). To the intermediategraph D, the elements of R\r(K) are added (marked green in the figure) to get the finalgraph H .

2.2.4 Example

Another example for a GTS can be created from the dining philosophers problem describedin section 1.3.2. The type graph shown in figure 2.7 describes the nodes and edges that areneeded. The meaning of the nodes is obvious, the edge between the philosopher and thefork means that this fork lies next to the philosopher. If the loop on the fork is present, thenthe fork is lying on the table, i.e. the loop is removed when a philosopher is eating withthis fork. The loops on a philosopher describe the states he can be in: thinking, eating, orwaiting. The loops on the type graph’s nodes are also intended to be loops in a typed graphin order to describe the state of a node. Therefore, the type graph does not ensure that thetyped graphs are valid instances of the dining philosophers problem. For example, the loopson the type graph’s nodes can also result in edges connecting two different philosophernodes in the typed graph. Figure 2.8 shows a correct instance of the dining philosophersproblem with five philosophers where one philosopher is eating and one is waiting. Onefork is between every two philosophers which is connected to each of them. No two eating

14


Figure 2.8: Typed graph for the dining philosophers problem with five philosophers andone philosopher eating.

philosophers are next to each other. The two onTable loops on the forks are missing wherethe philosopher is eating and each philosopher has exactly one loop.

To describe the change between the different states of the philosophers (eating, thinking,and waiting), three rules have to be introduced. The rules are designed in a way, so that nodeadlocks can occur, i.e. as soon as two forks are available, they are both taken simultane-ously. There are three rules in this GTS that describe the state transition of the philosophersfrom thinking to waiting, from waiting to eating, and from eating back to thinking. Therules are shown in figure 2.9. The first rule thinkToWait removes the think loop from aphilosopher node and adds a wait loop. The second rule waitToEat removes the onTableloops from the forks that are connected to the philosopher, as well as the wait loop fromthe philosopher and adds a new eat loop to him which symbolizes the philosopher takingup the forks and starting to eat. The last rule eatToThink adds the onTable loops to the twoforks connected to the philosopher, removes the eat loop, and adds the think loop to thephilosopher. This means he stops eating, puts back his forks, and starts thinking again.

2.2.5 Notation

There exist several notations for the rules of GTS. The notation with three graphs K, L,and R, used in this section, is good for describing the DPO approach for rule applications.Another approach is to use only two graphs L′ and R′ for a rule and define a partial mor-phism k′ : L′ → R′ that connects the nodes and edges that are connected via the K graphin the three graph notation. Figure 2.10 shows the unhook rule of the circular list GTS.The middle graph K is replaced by a single morphism k′ : L′ → R′. For both, the threeand two graph notation, the coloring of the nodes and edges in the graphs is only a visualhelp to see the nodes and edges that are not an image or preimage of the morphisms l, r,and k′. Another even more compact notation only uses one graph, but in this notation thecoloring is important. The graph K of the three graph notation is displayed in black whilethe nodes and edges in the graphs L and R that are not part of the image of the morphismsl and r are displayed in red and green, respectively. As the rule is presented in one graph,no explicit morphisms are needed anymore. Figure 2.11 also shows the unhook rule, butthis time in the one graph notation. The one graph notation is used for the remainder of

15

2 Preliminaries

Figure 2.9: The rules thinkToWait, waitToEat and eatToThink of the GTS for the diningphilosophers problem.

Figure 2.10: Two graph notation of the rule unhook of the circular list GTS.

Figure 2.11: One graph notation of the rule unhook of the circular list GTS.

16

2.3 CHR encoding of GTS

this thesis, because it provides a simple and compact way of representing GTS rules. Todistinguish the nodes and edges in this graph, the symbols L′, R′, and K are used for red,green, and black nodes and edges of the graph. In the three graph notation L′ is L\l(K),R′ is R\r(K) and K is the K graph.


Section 2.3.1 describes how to encode a GTS to CHR in general. Section 2.3.2 shows theencoding of the GTS for the examples introduced in section 1.3.

2.3.1 Encoding

The encoding of a GTS in CHR is adopted from [32]. To embed a GTS in CHR, an encod-ing must be provided for the typed graph production rules and for typed graphs in general.Production rules can be encoded as CHR rules and graphs in general as a sequence of con-straints that represent the nodes and edges of the graph. As described in section 2.2, a GTSconsists of three types of graphs: A type graph, multiple rules, and multiple host graphs.Let gts = (P, TG) be a GTS with the type graph TG = (VTG, ETG, srcTG, tgtTG) and aset of rules P which contains rules of the form p = (LTG l← KTG r→ RTG) that are typedover TG and let host graphs be of the form G = (VG, EG, srcG, tgtG, typeG) which arealso typed over TG. The elements of the type graph provide the constraint definitions ofthe CHR program: for every node v ∈ VTG a constraint definition v/2 is added, and forevery edge e ∈ ETG a constraint definition e/3 is added to the CHR program.

For the encoding of typed graphs, [typeG(x)] is defined as the name of the type of thenode or edge x in a typed graph. The functions dvar, var : G → VARS, x 7→ Xx mapnodes and edges to variables (VARS is an infinitely large set of variable names), so thatXx is a unique variable name associated with the node or edge x of a typed graph. Withthese mappings, the following encoding from nodes and edges of a typed graph to CHRconstraints is defined:

chrG(host, x) ={ [typeG(x)](var(x), degG(x)) , x ∈ VG

[typeG(x)](del, var(srcG(x)), var(tgtG(x))) , x ∈ EG

chrG(keep, x) ={ [typeG(x)](var(x), dvar(x)) , x ∈ VG

[typeG(x)](dvar(x), var(srcG(x)), var(tgtG(x))) , x ∈ EG

A constraint that encodes a node is called a node constraint, and a constraint that encodesan edge is called an edge constraint. The encoding of a complete graph is the encoding ofall the nodes and edges which are added to a sequence:

chr(host,G) = [chrG(host, x1), . . . , chrG(host, xn)]

andchr(keep, G) = [chrG(keep, x1), . . . , chrG(keep, xn)]

where x1, . . . xn are the nodes and edges of G. The first attribute of a node constraint isthe identifier attribute, the second argument is the degree (for the host encoding) or thedegree variable (for the keep encoding). The edge constraints have three attributes. Thefirst one is the deletion attribute that either contains a variable or a ground term. For hostencodings, it is always a ground term (the constant del is used here). For keep encodings itis a variable. The second and third argument contains the identifiers of the node constraintthey are connected to. These attributes are called source and target attribute. Therefore,

17

2 Preliminaries

their values are called source and target identifiers. If a host graph G is encoded withchr(host,G), the resulting sequence can be used as a list of goal constraints as input for aCHR program. For each rule p = (L l← K

r→ R) of a GTS, a new CHR rule of the form

p @ CL ⇔ CR

withCL = {chr(host, x)|x ∈ L\K} ∪ {chr(keep, x)|x ∈ K}CR = {chr(host, x)|x ∈ R\K} ∪ {chr(keep, e)|e ∈ EK}∪

{chr(keep, v′), var(v′) = var(v),dvar(v′) = dvar(v)− degL(v) + degR(v)|v ∈ VK}

is defined. This means that elements that are removed and added during a rule applicationare encoded as host elements and put into the head and body of the rule, respectively.Edges that are kept (e ∈ EK) in the graph during the transformation are encoded as keepelements and put in the head and body. Each node that is kept (v ∈ VK), is encoded as keepconstraint in the head and in the body. In the body, however, a new node v′ is introduced,together with built-in constraints that set the identifier of the nodes v and v′ equal. A built-in constraint, to set the degree variable v′ to the difference of the degrees of the graphs Rand L is also added.

The rule twoloop (figure 2.4) from the GTS for finding circular lists in a graph is encodedas

twoloop @ node(N0, Deg0), node(N1, 2), edge(del, N0, N1), edge(del, N1, N0)⇔ node(N ′

0, Deg′0), N′0 = N0, Deg′0 = Deg0 + 0− 0, edge(del, N0, N0).

This notation can be simplified to

twoloop @ node(N0, Deg0), node(N1, 2), edge(del, N0, N1), edge(del, N1, N0)⇔ node(N0, Deg0 + 0− 0), edge(del, N0, N0).

by replacing the variables introduced for v′ with the variable and expression from the built-in constraints. This notation is used in the remainder of this thesis.

This encoding ensures that rules can be applied to the goal constraints if and only if theaccording graph production rule can be applied to the according host graph. More de-tailed information about this encoding and proofs for its soundness and completeness canbe found in [32]. With these results, a GTS can be simulated by encoding it to a CHR pro-gram. Rule applications in this CHR program correspond to rule applications in the GTS.Therefore, if the input is a valid encoding of a graph, the constraint store also encodes avalid graph after rule applications.

2.3.2 Examples

The GTS for modeling the dining philosophers problem is described in section 2.2. TheGTS consists of the three rules thinkToWait, waitToEat and eatToThink. The type graphcan be encoded to the constraint definitions

philosopher/2, fork/2, think/3, wait/3, eat/3, onTable/3, liesNextTo/3

18


The rules are encoded (in the simpler notation) as

Pphil = [thinkToWait @ philosopher(P,DegP ), think(del, P, P )⇔ philosopher(P,DegP ), wait(del, P, P ).

waitToEat @ philosopher(P,DegP ), fork(F1, DegF1),fork(F2, DegF2), liesNextTo(Del0, F1, P ),liesNextTo(Del1, F2, P ), onTable(del, F1, F1),onTable(del, F2, F2), wait(del, P, P )⇔ philosopher(P,DegP ),fork(F1, DegF1 − 2), fork(F2, DegF2 − 2),liesNextTo(Del0, F2, P ), liesNextTo(Del1, F1, P ),eat(del, P, P ).

eatToThink @ philosopher(P,DegP ), fork(F1, DegF1),fork(F2, DegF2), liesNextTo(Del0, F2, P ),liesNextTo(Del1, F1, P ), eat(del, P, P )⇔ philosopher(P,DegP ),fork(F1, DegF1 + 2), fork(F2, DegF2 + 2),liesNextTo(Del1, F2, P ), onTable(del, F2, F2),liesNextTo(Del0, F1, P ), onTable(del, F1, F1),think(del, P, P ).]

In this GTS no nodes are added or removed. Because of that, all degree attributes in theheads are variables. The degree attributes of the bodies are expressions. The number thatis added or subtracted from the variable represents the change in the number of edges thatare connected to this node. In the waitToEat rule, for example, which encodes the GTSrule p = (L l← K

r→ R), the node encoded by fork(F1, DegF1) has a degree of threein the L graph and a degree of one in the R graph. Therefore, the constraint in the bodyof the CHR rule is fork(F1, DegF1 − 2), because the degree is decreased by two duringrule application. The deletion variables of the edges that are removed or added are set todel while the edges that are kept receive a unique variable (Del0 and Del1). A host graphconsisting of two philosophers with two forks where one philosopher is eating while thesecond one is waiting can be expressed with the list of constraints:

TwoPhilos := [philosopher(p1, 4), fork(f1, 2), fork(f2, 2), philosopher(p2, 4),liesNextTo(del, f1, p2), liesNextTo(del, f2, p2),liesNextTo(del, f1, p1), liesNextTo(del, f2, p1),eat(del, p2, p2), wait(del, p1, p1)]

The according starting state (compare section 2.1) of a the CHR program Phil = (Pphil)would be

〈TwoPhilos, ∅, true, ∅〉1The rule eatToThink can be applied when all but the last constraint are added to the CHRstore. After that, the graph encoded in the goal stack and CHR store contains again the twophilosopher and fork nodes together with the edges from forks to the philosophers. Theeat(del, p2, p2) constraint is replaced by a think(del, p2, p2) attribute, and two onTableconstraints are added for the fork constraints.

19

2 Preliminaries

The GTS for finding circular lists in graphs introduces the two constraint definitions node/2and edge/3. The two rules are encoded as

unhook @ node(N0, DegN0), node(N1, 2), node(N3, DegN3),edge(del, N0, N1), edge(del, N1, N3)⇔ node(N0, DegN0), node(N3, DegN3), edge(del, N0, N3).

twoloop @ node(N0, DegN0), node(N1, 2), edge(del, N0, N1), edge(del, N1, N0)⇔ node(N0, DegN0), edge(del, N0, N0).

In these rules, nodes are removed. For that reason, the degree attribute of the removednodes is the number of edges that are connected to them (two in both rules). All edges thatappear in the rules are removed or added. Therefore, they are all host encoded and containthe ground term del.

2.4 Eclipse

This section covers a short introduction to the eclipse platform and its architecture. Besidesthat, I describe shortly how to contribute plug-ins and define new extension points. Furtherinformation can be found in [22].

2.4.1 The platform

The Eclipse Platform is designed for hosting integrated development environments (IDEs)and arbitrary tools. It is written in Java. As can be seen in figure 2.13 the eclipse platformis split up into multiple layers.

An important concept of eclipse is its plug-in structure. Except a small core (the RuntimePlatform), every functionality of eclipse is realized via plug-ins. Plug-ins define extensionsand extension points. Basically, extensions are pieces of functionality that are plugged intoextension points. When defining an extension point, at least an identifier must be provided,so that extensions can refer to this extension point. Furthermore, multiple attributes can bedefined. Often a java class name is given that represents the code of the extension to beloaded. In most cases this class is requested to implement a certain interface, so that otherextensions can communicate with this new one. Extensions implement the definition of theextension point, as well as the attributes requested by it.

The Runtime Platform is mainly responsible for finding all plug-ins at start-up and manag-ing them. Plug-ins are usually not loaded when starting the platform, but they are dynam-ically loaded when they are needed. All other elements in figure 2.13 are plug-ins that areloaded on start-up by the Runtime Platform.

The Workspace is the root for the files and folders that can be used with the plug-ins loadedin the platform. It consists of multiple projects which are mapped to folders on the filesystem. Every project in a workspace can have multiple natures defining its properties,e.g. a java project has the JavaCore nature which provides java source folders and au-tomated compilation of the sources. All files and folders in the workspace are so calledresources which are a more fundamental concept than files and folders, because they letyou extend the functionality of the resource elements. One example for this is the so calledmarker mechanism for annotations: Resource elements can be marked with annotations,e.g. compilation errors or warnings which are displayed in a file browser and in editors.Another example is the possibility to add resource listeners that get notified when the re-source changes.

20

2.4 Eclipse

Figure 2.12: Screen-shot of the eclipse workbench.

All the elements described above are completely independent from a graphical user in-terface (GUI). The Workbench is the framework for GUIs in eclipse (which is a plug-initself). The workbench is based on the Standard Widget Toolkit (SWT) for drawing basiccomponents and JFace, a GUI toolkit which is based on SWT and offers a lot of classesfor handling many common GUI programming tasks. SWT comes in many versions thatuse different underlying window systems and defines itself an API which is independentfrom the underlying system. JFace provides components for imaging, font registry, dialogs,preferences, wizards, and progress reporting for long-running operations. The workbenchitself supplies the structures in which tools interact with the user. The eclipse platformGUI paradigm is based around views, editors, and perspectives. While views and editorsare elements visible to the user, the perspective gives information about the constellationof the elements. Editors are tools for editing and displaying files while views are toolsfor viewing objects currently worked with in the workbench. The eclipse platform takescare of integrating, initializing, and destroying editors and views. Further basic featuresof the eclipse platform is the team support and the help which are not further consideredhere. The Screen-shot in figure 2.12 shows the java perspective with an editor and multipleviews.

2.4.2 Plug-ins and extension points

Creating a plug-in in eclipse is done as follows: The user defines two files, plugin.xmland manifest.mf. The plug-in file is an Extensible Markup Language (XML) file, inwhich the user describes all the extensions in his plug-in. For every extension, a uniqueidentifier must be given to identify the given extension, as well as the identifier of the ex-tension point being extended. Furthermore, the attributes described by the extension pointdefinition must be added. The most common attribute is the class attribute which providesthe extension with the information about what class should be loaded when the extensionis activated. This class must also implement the interface given in the description of the ex-tension point. Defining an extension point works in a similar manner. In the plugin.xml

21

2 Preliminaries

Figure 2.13: Overview of the components of the eclipse platform (from http:

//www.eclipse.org/articles/Whitepaper-Platform-3.1/

eclipse-platform-whitepaper.html).

1 2 < e x t e n s i o n3 i d =" example . exampleview "4 p o i n t =" org . e c l i p s e . u i . v iews ">5 <view6 c l a s s =" example . Example "7 i c o n =" i c o n s / sample . g i f "8 i d =" example . ExampleView "9 name=" Example View ">

10 < / view>11 < / e x t e n s i o n >12 < e x t e n s i o n−p o i n t13 i d =" example . e x a m p l e E x t e n s i o n P o i n t "14 name="An exampe e x t e n s i o n "15 schema=" example . example . exsd " / >16 

Listing 2.1: A plugin.xml example.

file, a tag must be inserted that describes the extension point. The schema file is a XML filethat describes the attributes an extension must provide, as well as a textual description of theextension point for documentation. Listing 2.1 shows an example plug-in file for an exten-sion of the org.eclipse.ui.views. The extension tag is used to create a new exten-sion by providing the id attribute and the point attribute which specifies the identifier of theused extension point. The definitions for the extension point org.eclipse.ui.viewsstates that there must be a view tag with several attributes. In the class attribute, a classmust be given that implements the org.eclipse.ui.IViewPart interface (this in-formation is also contained in the extension point definition). The listing also shows anextension point which is defined by an extension-point tag. This tag requires a unique id,so that all extensions to this point can be found, a name that describes the extension point,and a schema file, which describes the extension point. The schema file contains the struc-ture of the XML tags for the extensions (like the view tag described above). Usually, a javainterface is provided together with an extension point, that must be implemented by theextensions. This interface is then used to communicate with the extensions. The schemafile lists which interface must be implemented by the java class that is given in the classattribute.

The manifest.mf file describes the packages that are exported by the plug-in and thedependencies of this plug-in. Besides that, it defines the execution environment and otherinformation needed to properly manage this plug-in.

22

http://www.eclipse.org/articles/Whitepaper-Platform-3.1/eclipse-platform-whitepaper.html



3 Conception

In this chapter, I present already available programs for editing and analyzing GTS in sec-tion 3.1. Furthermore, I analyze the goals mentioned in section 1.2 and refine them furtherin section 3.2. For these goals, I make a requirements analysis in section 3.3. In section 3.4,I present possible tools that can be used for the realization of the project and describe whichtools have been chosen for realization.

3.1 Available GTS tools

In this section, I analyze the tools Attributed Graph Grammar (AGG) ([18]) and Graphsfor Object-Oriented Verification (Groove) ([34]) that have already been mentioned in theintroduction to give a conclusion about the pros and cons of each tool. I analyze the usabil-ity, available analysis features, the possibility to extend the tools, and whether they can beused in other applications. These topics are chosen for analysis, because they are also themain features of the platform developed during this thesis.

3.1.1 AGG

AGG features a user interface divided into four parts. On the left is a list of rules, hostgraphs, and the type graph (the graph pane). On the right is a list of the type nodes andtype edges (type pane). In the middle are three fields. The upper two fields are for drawingrule graphs (rule pane) in a two graph notation (compare section 2.2.5) and the lower oneis for drawing the type or host graph, respectively (host or type pane). Before creating atype graph, one must define the nodes and edges in the list on the right side. See also thescreen-shot in figure 3.1.

When creating edges in host and rule graphs, there is no visual feedback if the connection isvalid, according to the type graph, until the user finishes the connection. If the connectionis invalid, an error message dialog pops up informing about the problem. Furthermore, thenodes must be mapped manually between the rules’s left and right side. The left side canalso be copied over to the right, then the mapping is done automatically. When deletingnodes or edges, a dialog pops up to confirm the deletion.

AGG can apply the given rules automatically to a host graph or by defining the matchesmanually. When selecting matches manually, they can also be auto-completed. There isalso the possibility of undoing transformation steps. Another feature is the non-deterministictransformation mode where rules are applied in a non-deterministic mode. One analysisfeatures of AGG is the critical pair analysis for checking confluence. Confluence is theproperty that rules can be applied in arbitrary order and the final result, when no rule canbe applied anymore, is always the same. The other feature is to test the applicability of arule sequence to a host graph. The advanced features are the creation of attributed GTS thatlet you assign attributes to edges and nodes. Furthermore, it supports graph constraints, tofurther restrict the applicability of rules, as well as positive and negative application condi-tions. There are additional analysis methods for these advanced features, but they are notdiscussed here (see [18] for more information about these topics), because this is beyondthe scope of this work. AGG provides no functionality to add further plug-ins for analyzing

23

3 Conception

Figure 3.1: Screen-shot of AGG.

Figure 3.2: Screen-shot of Groove.

or editing a GTS. But the kernel of AGG (without GUI) can be used in other applications.Therefore, an API for creating GTS is provided, so that rules can be applied to host graphsin arbitrary applications.

3.1.2 Groove

Groove provides a similar appearance to AGG. On the left side is a list of rule graphs withtheir matches on the host graph as sub-elements. There are no type graphs in Groove, nodesand edges can only be labeled with strings. Therefore, there is no consistency check forthe validity of the graph. On the right is a list of labels which can be used for nodes andedges (label list). In the middle is a tabbed pane with four tabs, one for the host graph (thisis called the start graph), one for the rules, one for the exploration of all the graphs that canbe created with the given rules and one for analysis purposes. See also the screen-shot infigure 3.2.

24

3.1 Available GTS tools

The graphs cannot be directly edited in this middle pane, but an editor can be started fromthere. This editor is rather simple, it lets you create nodes and edges and add labels. Thelabels are not imported from the other graphs in the main program and they must be en-tered by hand for each node. Rules are displayed in the one graph notation (comparesection 2.2.5) where light blue dashed lines represent the elements that are removed andbroader green lines symbolize elements that are added during rule application. Elementsthat stay, are kept in black. Groove supports non-injective match morphisms, i.e. it canmatch one element in a rule application multiple times. If this is not intended, the twoelements in the rule have to be marked as unequal, so that they are not matched to thesame element. This is done by adding a connection between them with the label “not:=”which is then displayed as a red edge between the nodes. However, this is not a transitiveoperation. Because of that, if n nodes can be matched non-injectively, O(n2) edges haveto be inserted. For the editing of the rules, the same editor is used as for graphs, so thereare no additional GUI elements for creating it. The properties of an element are, therefore,described by adding special keywords to the label, e.g. elements that are added during ruleapplications have a preceding “new:” in their label. This makes editing rules and graphsvery uncomfortable.

As described above, Groove itself is not an editor but a simulator and the editor for thegraphs is another tool, so the main feature of Groove is the application of the rules to astart graph. On the left pane, all rules with their corresponding matches on the start graphare displayed. By selecting one of the matches, it is displayed in the start graph and thecorresponding rule can be applied. The new matches are directly updated on the left pane.The other feature of Groove is to display the space of all graphs that can be reached byapplying rules to the start graph. This space is itself displayed as a graph where each noderepresents a graph in the transformation and each edge represents the rule that is appliedto transform the graph of the source node to the graph of the target node. By clicking onthe nodes, the corresponding graph is displayed. Groove automatically merges nodes thatcontain isomorphic graphs. The space can either be fully explored or only in a linear way(isomorphic graphs are evaluated only once), which supports a non-deterministic order ofrule application, as well. Groove can try to find final states of a GTS. Therefore, it triesto apply rules in depth- or breadth-first way until no rule is applicable anymore. The finaland the intermediate graphs are also displayed in the explored space tab. The extendedfeatures of Groove are the possibility to add wild-cards and regular expressions to labelswhich are evaluated when applying rules. Furthermore, simple data types can be associatedwith nodes and edges which can be changed during rule application. For more informationabout these advanced features see the Groove documentation ([33]). They are not coveredhere, because that would be beyond the scope of this thesis. There is no documented wayof extending Groove with a better editor or further analysis possibilities. An API for usingGroove without its GUI in external programs is not documented.

3.1.3 Conclusion

Both tools provide a different approach in graphical editing, but both have disadvantages.AGG informs the user very late about editing errors by popping up messages instead ofgiving earlier visual feedback. Groove’s editing mechanism is based on entering keywordsin the nodes’ and edges’ labels without the use of further graphical interfaces. That requiresa constant switching from the keyboard to the mouse. Groove does not even provide supportfor type graphs, it is based only on the matching of labels. That is why no type system isprovided to check the consistency of the start and rule graphs. Both tools provide interestingfeatures, e.g. Groove provides the exploration of all intermediate graphs that can be createdby applying rules, while AGG provides a confluence analysis. However, none of the tools

25

3 Conception

is extensible in order to add other missing features. Only AGG can be integrated in otherprojects to use GTS.

3.2 Goals

Raiser describes in [32] how GTS can be ported to CHR. Given this fact, methods foranalyzing CHR programs can directly be used to analyze GTS, e.g. confluence, termina-tion, and operational equivalence analysis. But these methods cannot be integrated into theexisting tools described above. Furthermore, both tools are stand-alone tools that are notembedded in a common framework. Therefore, there is no common API to extend theirfunctionality.

For that reasons, the subject of this thesis is to create a platform that enables you to createand analyze GTS. Editing should be possible in graphical notation and by using the en-coding in CHR. The textual editor for the CHR encoding should be provided, because itrepresents a simple textual notation for editing a GTS and it helps to understand the resultsof analysis tools that are based on CHR. The platform must not be a stand-alone tool, but itshould be embedded in the eclipse framework to allow easy extensibility. For that reason,no analysis methods are provided by the platform itself, but by further plug-ins. Becauseof that, an API must be made available, so that analysis tools that work directly on the GTSand analysis tools that are based on CHR can be integrated with little work.

To demonstrate the power of the platform, another goal is to create several prototypicalanalysis tools. One analysis method, available in both AGG and Groove, is the applicationof the created rules to a host graph. Therefore, an analysis tool must be offered, that addsthis feature to the platform. This tool is based on CHR, because CHR can be used tosimulate a GTS. Another goal is to create a tool that provides another API, so that CHRanalysis methods (called CHR tool in the remainder) can be added to the platform. Aprototypical CHR tool should be added that creates an executable CHR program from theGTS, because this can be needed by several other CHR tools, e.g. confluence analysis.Furthermore, the executable CHR program can also be embedded into other applications,so that the created GTS can be used there. Exemplary tools, that are independent fromCHR should also be provided. That is why a possibility to analyze the termination of theGTS should be realized. The creation of random host graphs is an example for a tool thatmodifies the GTS. Realizing more of the analysis methods found in AGG or Groove, e.g.graph space exploration of the GTS or confluence analysis, would be out of the scope ofthis thesis and are left for future work.

To summarize, the functional goals are

• Provide editors GTS

– in a graphical way– and in textual way via CHR

• Design of extension possibilities to add arbitrary analysis tools for GTS

– Provide several prototypical analysis tools:∗ Simulation of GTS via CHR∗ Generation of random host graphs∗ Termination analysis for rules

– Provide an analysis tool for embedding CHR based analysis methods

A non-functional goal is to provide a good usability for the editors and tools to allow rapidcreation and analysis of new GTS.

26

3.3 Requirements analysis

3.3 Requirements analysis

In the following, I work out the requirements to achieve the goals described in the previoussection. As described in section 3.2, there are two main goals for this thesis: the develop-ment of editing capabilities for GTS and the design of an extensible analysis platform.

As described in the previous section, there will be graphical, as well as textual editors whichcan be used in parallel. Therefore, an important requirement is the development of a front-end that displays two editors in parallel. As there are multiple editors, loading and savingof a GTS from and to a file must be handled by the platform itself. For the graphical editorsit is very important to prevent the creation of inconsistent graphs and rules. Additionally,they should give early visual feedback of allowed editing steps. As a GTS gts = (P, TG)consists of a set of rules P and a type graph TG, at least two editors are needed. Further-more, a set of host graphs to apply the rules to must be available, therefore, an additionaleditor is needed. For the textual editors, a parsing mechanism is needed, so that it canbe checked whether the CHR source encodes a GTS. Besides that, the textual editor mustprovide specific feedback of errors in the encoding. The encoding described in section 2.3is too complex for editing a GTS, because it also provides some redundant information(the degree, and deletion attribute of constraints) that is only required when running theCHR program and for confluence analysis. As a consequence, a simpler encoding must beprovided to make the editing more comfortable.

To synchronize the editors, a common model of the GTS, the GTS model, must be pro-vided that is used by both editors and the platform. The editors must work synchronouslyand always display the same information to allow comfortable editing. Furthermore, anundo/redo stack is needed, so that changes made to the model can be undone. This stackmust be shared between the editors to prevent inconsistencies of the GTS.

The second main goal is to provide a platform for easy extensibility with analysis toolsfor GTS. As a consequence, a plug-in structure must be developed to share the currentlyedited GTS model with the desired plug-in. Additionally, a simple GUI must be designedfor starting these plug-ins. These plug-ins are called (GTS) analysis tools. For the CHRbased analysis of GTS, an analysis tool called the CHR based analysis tool that createsCHR source code and opens a CHR analysis tool with this generated file must be provided.For the CHR code generation, the possibility to activate and deactivate rules, as well asto change their order is required, because this is important for the execution of CHR pro-grams (section 2.1). Current implementations of CHR for java are all deterministic. Thatis why a non-deterministic mode cannot be provided here. Furthermore, the tool requires apossibility to encode host graphs as input for the CHR analysis tools. When rules or hostgraphs are selected, they should be displayed in the editor, so that the user has direct visualfeedback of the activated rules. In order to add available analysis methods for CHR to theplatform, another plug-in system must be developed to integrate them into the platform.The most basic functionality that is needed is the creation of an executable environment ofthe CHR source, so a CHR analysis tool must be developed that creates this environment.A good example for a CHR analysis tool is a confluence analysis. Therefore, a strategy hasto be developed on how to embed an automatic confluence analysis into the platform. TheCHR analysis tools should also have the possibility to display rules or parts of them in theeditors that correspond to CHR rules. For that reason, the CHR based analysis tools musttransform the request from a CHR tool to a request for the platform in order to display acertain graphs or highlight parts of it.

The analysis tool for rule application to a host graph via CHR must have a graphical frontend to display the graph represented by the CHR store, so a synchronization between theCHR store and the graphical front end must be developed. Layout algorithms are neededfor proper display of the resulting graph. AGG and Groove both provide the possibilityto apply rules step-by-step and manually select the next match for a rule to test the GTS

27

3 Conception

thoroughly. These features should be included in this tool, as well. Therefore, there mustbe a possibility to enable and disable CHR rules and change their order. Additionally, amethod has to be developed, so that the CHR rules can be applied step by step and thematch of the rules can be specified manually. When rules are disabled or enabled, theyshould also be displayed in the editors.

The tool for creating random host graphs must provide a simple interface to enter the num-ber of nodes and edges that should be created. Because of that, an algorithm must beprovided to create a consistent typed graph from this information.

Termination can be analyzed by using a ranking function. Therefore, a method must beprovided to enter the ranking function and analyze the rules with it.

Some of the tools require a communication back to the platform in order to display certaingraphs or at least parts of them. Therefore, a communication infrastructure must be de-veloped, so that the platform can also receive information from the tools to display graphsor highlight parts of it. More of the features that can be found in AGG and Groove arenot provided as additional tools, because the goal of this thesis is the development of anextensible platform and not to implement all the features of AGG and Groove into a singleprogram.

Here is a list of the resulting requirements:

• Platform in general:

– Shared model for GTS, used by editors and tools

– Shared command stack

– Saving/Loading mechanisms for GTS models

• Editors in general:

– Synchronization of view

• Graphical editor:

– Forbid inconsistencies in the GTS

– Early visual feedback about invalid model states

– Multiple embedded editors for host, rule and type graphs

• Textual editor:

– Create model from CHR source

– Algorithm to check for valid encoding of a graph

– Update the GTS model from the CHR source

– Error feedback in the editor

– Simpler encoding for easier editing

• Plug-in system:

– Provide model, command stack, and file for the tool

– Receive information from tools to update the view in the editors

• CHR based analysis tool:

– Plug-in structure for CHR analysis tools

– Select rule order

28

3.4 Finding the right tools

– CHR code generation

– Create executable environment of CHR source

– Confluence analysis tool

– Display graphs selected in CHR tools in the editors.

• Tool for running a GTS based on CHR with graphical front-end:

– Develop a method to execute CHR programs step by step and define matchesmanually

– Create executable environment of CHR program

– Graphical front-end with automatic graph layout

– Synchronization of CHR store and graphical front-end

– Select order of the rules

– Display rules in editors

• Random host graph tool:

– Simple GUI

– Creation of valid models

• Termination analysis tool:

– Manual definition of ranking function

– Display non-terminating rules in editors


In this section, I give an overview of the tools that are available to possibly provide the func-tionality requested above. The selection of the tools is covered at the end in section 3.4.7.

3.4.1 Model creation

The most basic concept of the platform is a common model on which the editors and anal-ysis tools can operate. The model can be designed manually or a library providing graphmodels can be used.

3.4.1.1 JGraphT

JGraphT1 is a graph library which is based on java and supports many different types ofgraphs, e.g. directed and undirected graphs. Furthermore, it implements the listener pattern([23]) to get notified about changes made to the graph. JGraphT is designed to be simpleand highly efficient with large graphs. Additionally, many algorithms from graph theoryare available. JGraphT graphs can be used as models for JGraph which is described whendiscussing about graphical editors in section 3.4.2.3.

1Available at http://www.jgrapht.org/

29

http://www.jgrapht.org/

3 Conception

3.4.1.2 JGraph

JGraph2 is a graphical framework for displaying graphs, but it also provides an own modelfor the representation of graphs that can also be used without the JGraph graphical frame-work. The graph model is meant for extending it for custom application, but a standardgraph model is already provided that works for most applications.

3.4.1.3 EMF

Eclipse features a framework for creating arbitrary models and generate code from it. It iscalled the Eclipse Modeling Framework (EMF) ([15]). EMF creates java interfaces fromthe model definition, as well as implementations of it. It provides structures to keep themodel consistent, i.e. if two classes are connected to each other and a reference is deletedor added in either of the two objects, it also gets deleted or added in the other one. Anotherbenefit of EMF is that it implements the listener pattern ([23]), so that editors and viewerscan be updated automatically upon changes to the model. Aside from references betweenobjects, the concept of containers and containments is provided to create a tree like struc-ture for the objects, i.e. elements can only be contained in one containment at the sametime. EMF also offers the possibility to add custom code to the models.

3.4.2 Graphical editors

For the graphical editors, eclipse itself provides two solutions: The Graphical EditingFramework (GEF) and the Graphical Modeling Framework (GMF). There are third partygraphical editor frameworks that can be used without eclipse: JGraph and yFiles.

3.4.2.1 Graphical Editing Framework (GEF)

GEF ([16]) is a framework for graphical editors in the eclipse platform. It is based onthe model view controller (MVC) paradigm which is further described in [27]. Figure 3.3shows the relation between model, view, and controller objects in the MVC pattern. Themodel represents the data that should be displayed and edited. The view renders the con-tents of the model. The view can query the model itself for changes or add itself as listenerto it, so that it gets notified when the model changes. The controller translates interactionsfrom the user with the view into modifications of the model. In this design, the controlleronly receives information from the view and propagates it to the model. However, in GEFthe controller has a more central part and is named edit-part. It registers itself as listenerto the model and updates the view object when the model is changed. Therefore, the viewand the model are decoupled. Edit-parts can have multiple edit-policies. Requests whichare sent by tools to edit the model, are send from the edit-part to the corresponding edit-policies which itself create commands that modify the model. The tools are provided byGEF and give the user the possibilities of editing the model. Tools for creating, deleting,and moving objects are already provided by GEF, but they can also be extended to providemore specialized functionality. The creation of the views is based on draw2D, a simpletoolkit for creating graphical figures. The technology used for the model is not defined byGEF. The model has to implement the listener pattern. EMF can be used for creating themodel, for example. GEF is widely used in the eclipse community for creating graphicaleditors and good documentation, as well as sample code is available.

2Available at http://www.jgraph.com

30

http://www.jgraph.com


Figure 3.3: Schematics of the MVC pattern (from http://java.sun.com/

blueprints/patterns/MVC-detailed.html).

3.4.2.2 Graphical Modeling Framework (GMF)

GMF ([17]) is based on GEF and EMF. GMF lets you define an EMF model, as wellas views, tools, and a mapping between them in a graphical editor. From this information,code for a graphical editor is generated. Many standard functions often used in GEF editorsare automatically implemented such as zooming and adding comments to elements. Aseparation of the model itself and a model for the graphical representation is available, aswell as the possibility to save them to and load them from a file. To conclude, GMF is atool to rapidly create standard graphical editors.

3.4.2.3 JGraph

JGraph3 is a complete framework for the graphical editing of graphs. The model for editingis already available in JGraph, but it can also be customized. Other models can be used,as well, e.g. the JGraphT model. The JGraph editor components are based on the SwingAPI. There is a free open-source core of JGraph that provides classes for creating owneditors. However, there are also some commercial add-ons for laying out graphs (LayoutPro) and for creating feature rich editors (GraphPad Pro). A complete programmers guideis available together with a few example projects on the project website.

3.4.2.4 yFile

yFile4 is a commercial project. It consists of an extensive library that features algorithmsfor the analysis, visualization, and automatic layout of graphs. The library is written in java

3Available at http://www.jgraph.com4Available at http://www.yworks.com/

31

http://java.sun.com/blueprints/patterns/MVC-detailed.html

http://java.sun.com/blueprints/patterns/MVC-detailed.html

http://www.jgraph.com

http://www.yworks.com/

3 Conception

and uses the Swing API for visualization. It can only be extended in limited ways, becausemost licenses are only byte code licenses, which are not offering access to the source code.

3.4.3 Textual editors

Eclipse itself already provides base classes for textual editors, however, these editors do notoffer parsing mechanisms to retrieve the information that is encoded in the text. An editormade especially for JCHR (a java-based CHR implementation) is currently developed atthe university of Leuven. Two other frameworks are for creating an EMF model from thecontents of a text editor based on a grammar: The Textual Editing Framework (TEF) andthe Textual Modeling Framework (TMF), which are both based on eclipse.

3.4.3.1 JCHRIDE

The JCHRIDE ([1]) is an eclipse text editor with syntax highlighting and rudimentary codecompletion. Furthermore, support for compiling JCHR source code files with the K.U.Leuven JCHR compiler is provided. The compilation, however, works only on MicrosoftWindows systems. The editor does not generate a model of the JCHR source, but onlychecks for syntactic correctness.

3.4.3.2 XText

XText ([13]) is part of the eclipse Textual Modeling Framework (TMF). For XText, a gram-mar and an according EMF model has to be created. Then XText creates a parser, a serial-izer, and a text editor from the model and the grammar. Therefore, models can be createdfrom text or serialized into a string according to the grammar. The editor has many features(syntax highlighting, auto-completion. . . ) and is integrated into eclipse. At the time of im-plementation XText has still been part of the openArchitectureWare (oAW) project ([30]),a framework for model driven development, which is based on eclipse. However, XTexthas been on the move from the oAW project to the eclipse TMF project, but no version hasbeen available for TMF at the time of implementation.

3.4.3.3 Textual Editing Framework (TEF)

A similar tool is the Textual Editing Framework (TEF), which is currently in developmentat the technical university of Berlin ([35]). TEF provides a text editor base class, whichis supplied with a context-free grammar, annotated with classes and properties of classesfrom an EMF model. This grammar is then interpreted by the TEF framework to create aninstance of the EMF model described by the content of the text editor. Furthermore, TEFfeatures error annotation in the editor for syntax errors and reference errors in the generatedmodel instance. Models can also be serialized to strings and displayed in the text editor.The grammar also supports special white space terminals, that are only considered whencreating a string from a model. TEF uses the method of background parsing to continuouslycreate a model in the background. Depending on the type of the TEF editor, a new modelis created on every background parsing step or an existing model is being edited. There isa rudimentary auto-completion function available that can be further extended.

3.4.4 CHR environments

CHR is an extension of a host language, therefore, there exist a lot of implementations forseveral languages. [39] contains an extensive list of available CHR implementations. Most

32


implementations are based on logical programming languages like Prolog, but only few areavailable for imperative languages like java or C. In the following, I present the two mostused implementations for java.

3.4.4.1 Java Constraint Kit (JaCK)

JaCK ([2]) is the earliest CHR implementation for java. It has been started in 2001. JaCKis a combination of several components. JCHR is a CHR dialect that combines Prologbased CHR syntax with java syntax. VisualCHR is a tool for visualizing the executionof JCHR programs. The last component is the Java Abstract Search engine (JASE) inwhich tree-based search strategies can be specified. It provides the possibility to implementsearch algorithms to use backtracking when inconsistent states occur during the executionof JCHR. However, this project is no longer maintained.

3.4.4.2 K.U. Leuven JCHR

The K.U. Leuven JCHR system (not to be confused with the JCHR component of JaCK)is currently in development at the Catholic University of Leuven ([40]). The term JCHR isused in the remainder of this thesis for the K.U. Leuven JCHR system. JCHR is not onlyan implementation of CHR in java, but an integration of the CHR features in java. For anintroduction to the features of JCHR, please refer to the official K.U. Leuven JCHR docu-mentation [43]. Basically, the K.U. Leuven JCHR compiler creates a java 1.5 compatiblesource file from a .jchr file. The resulting class is called handler. The syntax of jchrfiles is a combination of Prolog based CHR and java syntax. JCHR offers the possibility toembed arbitrary java classes and methods into a handler. Therefore, elements of the javalanguage can also be used in JCHR handlers. Furthermore, the generated handlers can beembedded in other java programs. To do that, the handler provides methods to retrieve alist of the constraints in the CHR store and methods to add new constraints to the store.

3.4.5 Code generation

As described in 3.3, there are analysis tools that might rely on CHR source code files. Asa consequence, code generators are needed. I describe Extensible Style-sheet LanguageTransformations (XSLT) and Java Emitter Templates (JET).

3.4.5.1 XSLT

XSLT ([26]) is an XML based transformation language for transforming XML documentsinto other document types like HTML or java source code. The XML source file is notmodified, but a new file is created from the content of the old document. XSLT uses XPath([4]) to query the source XML document for the information needed in the new document.An XSLT file represents the new file with embedded tags that represent the informationfrom the input XML document. Tags are available for iteration and conditional executionbased on the input document. Furthermore, a processor is needed that interprets the XSLTprogram and generates the output document. The two best known processors for java areXalan-J5 which is developed by the Apache foundation and Saxon6 which is based uponSAX the java XML parsing tool.

5Available at http://xml.apache.org/xalan-j6Available at http://www.saxonica.com

33

http://xml.apache.org/xalan-j

http://www.saxonica.com

3 Conception

3.4.5.2 Java Emitter Templates (JET)

JET ([12]) is used to create source files in the EMF project, but this tool can also be usedstandalone. Originally, JET was only used to generate code from structures defined byXML files but has been extended to accept EMF model instances as input. The definitionsfor the generated source is provided via a text file in which the static parts of the source fileare written as they should appear in the generated source and XML tags can be embeddedto insert dynamic information gained from the input XML file or the EMF model. Thesyntax is similar to that of XSLT. There are tags for iteration over multiple elements andconditional insertion of parts of the source file. Further tags can be created as tag librariesby creating an eclipse extension to JET. The input is queried with XPath ([4]). XPath isbasically a method for querying XML files in an easy and intuitive way. XPath expressionscan also be used as input for so called XPath functions. These functions include, for ex-ample, counting the number of elements returned by the query or manipulate lists. FurtherXPath functions can be added by creating an according JET extension which contains theimplementation of the function in java. JET offers the possibility to store calculated valuesin the model during transformation.

3.4.6 Graph layout and visualization

The tool for the execution of GTS based on CHR requires a visual representation of theCHR store as a graph. Therefore, a tool for displaying and laying out a graph is needed.

3.4.6.1 JGraph, yFiles

The tools, mentioned above for the graphical editors that offer layout algorithms can beused as visualization tool-kits. The only interaction that is allowed, is selecting nodes andedges and moving them around. All the other editing features are left away. JGraph andyFiles are the two tools that also provide layout functionality.

3.4.6.2 Zest

For displaying and laying out arbitrary graphs Zest ([14]) can be used. It uses draw2d fromthe GEF project for vizualization. Zest provides a graph object to which nodes and edgescan be added. Zest is based on eclipse and uses the Standard Widget Toolkit (SWT) API.Furthermore, Zest already features several layout algorithms. They can be also be extendedto create custom layout algorithms. The algorithms can also be used independently fromZest. In addition to that, possibilities of selecting nodes and edges and moving nodesaround are provided. Listeners can be added to get notified about selection events occurringat the node and edge widgets.

3.4.7 Suitability of the tools

As mentioned above, it can hardly be decided for each category on its own which toolsshould be used, because some of them rely on each other. First, I exclude some of thetools. Tools with graphical components (i.e. the graphical editors and the visualizationtools) that use the Swing API are difficult to use, because eclipse uses the SWT API forits graphical user interface. Although there are libraries that let you integrate Swing com-ponents into eclipse, this requires much additional work and is error-prone. That is whyJGraph and yFile are not used as editors or visualization tools. This leaves GEF or GMF

34


for the graphical editor and Zest for the visualization and layout toolkit. GMF is basedon GEF and EMF and provides the automatic generation of standard editors. However,the platform contains a textual editor besides the graphical one and these editors interactwith each other. So, if GMF was chosen, the generated code would have to be modifieda lot, so that it could be integrated into the platform and the inter-editor communicationstructure. As GMF editors are generated from model specifications, every change in thespecification would result in a newly created editor and the changes that must be made forthe integration into the platform would have to be redone. GEF, on the other hand, canbe better customized and is not generated from specifications, but implemented manually.Therefore, GEF editors can be used better in combination with other editors. For thesereasons, GEF has been chosen as the framework for graphical editors.

One requirement of the textual editor is that the content must be parsed to retrieve theinformation about the encoded GTS model. JCHRIDE is not used, because it only checksfor syntactical correctness and does not provide further parsing mechanisms. That leavesXText or TEF as possible solutions. Both frameworks have all required features: theycan both create an EMF model instance from the content of a text editor and both canprint a model instance to the text editor. However, XText has been on the move from theoAW to the TMF project at the time of implementation and no version has been available,which is specifically designed for the eclipse TMF framework. Because of that, TEF is theframework that could be embedded better into eclipse and has, therefore, been chosen astextual editor.

The decision for the code generation tool was mainly driven by the eclipse platform. JETis specifically designed for eclipse and seamlessly integrates in the workspace concept byproviding tags for creating files, folders, and new projects. Furthermore, XSLT with Saxonor Xalan-J only takes XML documents as input, while JET also provides the possibility touse instances of EMF models as input. For these reasons, JET is chosen as code generator.

The choice how to provide the model for the GTS is heavily influenced by choosing TEFand GEF as editors and JET as code generator. Although JGraphT provides an elaboratemodel for creating own graph models, many tools based on the eclipse framework use EMFmodels as input. Therefore, I have decided to design a GTS model based on EMF. Anotheradvantage of EMF over JGraphT is, that it directly supports saving and loading of models toand from XML files. In combination with JET, EMF model instances can be used directlyas input for code generation without having to save it to an XML file first.

The K.U. Leuven JCHR system is currently the best supported and fastest ([39]) CHRimplementation for java. JaCK is no longer maintained and does not perform as well as theK.U. Leuven JCHR system. Therefore, the K.U. Leuven JCHR system is used for creatingexecutable environments of CHR programs. Because of that, all generated CHR source isin JCHR syntax.

Further details about the tools and how they are used is provided in chapter 4 as needed.

35

3 Conception

36

4 Realization

In this chapter, I describe the design and implementation of the project. First, I present themodel for GTS in section 4.1. In section 4.2, I show how I have designed the platform itselfincluding the plug-in system for the analysis tools and the elements to display two editorssynchronously. The graphical and textual editors together with synchronization algorithmsare described in sections 4.3 and 4.4. In sections 4.5 to 4.8, I present the realization of theplug-ins. I pay special attention to the tool for CHR based analysis (section 4.6) and thesimulation of a GTS based on CHR (section 4.7). Section 4.5 is a detailed guide that showshow to create custom analysis tools with the example of a tool for termination analysis. Insection 4.8, I present a tool for generating random host graphs and provide a guide howa confluence analysis for CHR could be added as a CHR analysis tool. Each topic willbe divided in showing the design first and then giving details about the implementation.Chosen parts also have an additional section which show a sample computation.

The implementation sections give reference to the eclipse project names, where the sourcecan be found. These project can be found on the CD-ROM to this thesis (see appendix A).

4.1 GTS model

In this section, I explain how the model is designed and present the possibilities for edit-ing it. The model is not directly edited by the tools or by the editors, but commands areprovided to edit the model. These commands are managed by a command stack in order toprovide undo and redo functionality.

4.1.1 Design

In the following, I describe the design of the model and the design of the commands.

4.1.1.1 Model

The model for the GTS (model or GTS model for the remainder of this work) consists ofmultiple graph models. As described in section 2.2, a GTS consists of a set of rules Ptyped over a type graph TG. Furthermore, the possibility to specify a set of host graphsHG typed over TG should be provided. One thing that all the graphs mentioned have incommon is that they consist of nodes and edges that connect the nodes. Each node has a listof edges that have it as source and a separate list for the target edges, whereas each edge hasexactly one source and target node. Furthermore, the edges and nodes belong to exactly onegraph. This description of a graph can be seen in the Unified Modeling Language (UML)class diagram in figure 4.1. The nodes and edges are modeled as a composition, becausenodes and edges can only belong to one graph. Graphs have an identifier, as well.

Figure 4.2 shows the UML class diagram of the complete GTS model. A type graph (Type-Graph) is essentially a graph as described above, only that it has an additional list of itstyped graphs. The nodes and edges of the type graph (TypeNode and TypeEdge) also havea list of their typed nodes and edges (TypedNode and TypedEdge), respectively. The type

37

4 Realization

Figure 4.1: General UML model of a graph in this GTS model.

graph, type nodes, and type edges are inherited from the standard graph model (Graph,Node, and Edge). The type nodes and edges have an additional unique identifier as at-tribute.

Typed graphs (TypedGraph) are the counterparts of the type graphs, so the typed graphsand its nodes and edges contain exactly one reference back to their type graph, type node,or type edge, respectively. In regard to the encoding of GTS to CHR, every node in atyped graph receives an unique id. The graphs in HG (HostGraph) are inherited fromthe typed graph class and have a reference back to the GTS they belong to. A GTS cancontain multiple host graphs, as described in section 2.2. Rule graphs consist of threegraphs that are in relation by two graph morphisms of the form p = (L l← K

r→ R)with the graphs L, K, and Ro and the graph morphisms l and r. I decided not to use thisapproach directly in the model, because nodes and edges in K are additionally stored in Land R and the morphisms have to be provided explicitly which would require additionallogic in the model. As a result, I have designed the rules as a triple of the form p′ =(L′,K,R′) where L′ = L\K and R′ = R\K. A transformation from p′ back to p canbe achieved by defining R = R′ ] K and L = L′ ] K and setting the morphisms l andr to map the nodes from the graph K to the nodes that are added from K to L′ and R′,respectively. With this new way of presenting a rule, the three graphs can be encoded in onetyped graph T = L′ ]K ]R′ (RuleGraph) by giving each node and edge (TransformNodeand TransformEdge) an attribute that describes whether they are in L′, R′, or K. The nodesand edges in L′ correspond to the red elements in the one graph notation described in 2.2,the nodes and edges in R′ to the green elements, and the nodes and edges in K to theblack elements. All these types of graphs are bundled together in one graph transformationsystem class (GTS) by two lists of host and rule graphs and a single type graph over whichthe other graphs are typed. Another approach to model a GTS that is closer to the categorytheoretic basics described in 2.2 would be possible, but in the implementation section Iexplain why I have chosen the approach described above.

4.1.1.2 Editing commands

Commands can be used by the editors to edit a GTS model. There are multiple tasks, whenediting a GTS. First, rule and host graphs can be added and removed and their name canbe changed. For each type of graph, i.e. host, rule, and type graph, nodes and edges canbe removed. The type graph’s edges and nodes can also be renamed. The identifier ofthe nodes in rule and host graphs can also be modified. Finally, the nodes and edges of arule graph p′ = (L′,K,R′) can be moved between the graphs L′, K, and R′. Table 4.2lists the modifications that can be applied to GTS model. However, the GTS model doesnot imply, for example, that type nodes can only be added to a typed graph, and not to ahost graph. Therefore, commands must be provided that ensure that no such invalid modelstates can occur. In the following, I describe the possibilities of returning an invalid model.The according figures illustrate invalid model states.

38

4.1 GTS model

Figure 4.2: UML class diagram of the model of a GTS.

Figure 4.3: Problematic states when editing nodes in a graph (removed elements are red,added elements are green, and modifications are blue).

39

4 Realization

Figure 4.4: Problematic states when editing edges in a graph (removed elements are red,added elements are green, and modifications are blue).

Figure 4.5: Impossible combinations of nodes and edges in the graphs R′,L′, and K of arule. Elements in L′ are red, R′ is green, and K is black. A dashed line means,the element can be in any graph.

40

4.1 GTS model

src/tgt L′ K R′

L′ L′ L′ ∅K L′ L′,K,R′ R′

R′ ∅ R′ R′

Table 4.1: Allowed combinations of edges with source and target nodes for rule graphs.

Node commands When adding nodes in a typed graph with no type node being spec-ified (figure 4.3 a) shows a typed node without its type morphism), the model isinvalid. The identifier of a new node must be unique among the other nodes (fig-ure 4.3 b) shows two nodes with the same identifier). When a node’s identifier ischanged, it must also be ensured that it is unique. The uniqueness of the identifiersis important for the encoding of a GTS in CHR (section 2.2). Removing a node canbe problematic: Edges can be left dangling and if the removed node is a type node,then typed nodes that reference it have no type anymore (figure 4.3 c)).

Edge commands When changing or setting the id of a type edge in a type graph, it mustbe ensured that the identifier is unique (figure 4.4 a)). When adding typed edges intyped graphs, the types of the source and target nodes must match the source andtarget of the type edge (figure 4.4 b) shows typed nodes that are connected by thewrong edge), i.e. the typing morphism described in section 2.2 must be valid. Whencreating a typed edge, a type edge must be provided (figure 4.4 a)). Deleting an edgeonly raises problems when it is a type edge, because typed edges referencing it wouldnot have a type anymore (figure 4.4 b)).

Graph commands Adding and removing graphs does not impose any problems, exceptwhen changing the name of typed graphs, attention must be paid that the new nameis unique for host and rule graphs, respectively.

Commands for nodes and edges in rule graphs The problems stated above foredges and nodes are also valid for rule graphs, but editing rule graphs can lead toadditional invalid model states. When changing the graph to which the nodes andedges belong (L′,R′, or K), it must be ensured that edges cannot arbitrarily connectnodes from the three graphs, e.g. an edge can never connect a node in R′ to a nodein L′. See figure 4.5 for the combinations that are invalid. The valid combinationsof nodes and edges in the graphs are listed in table 4.1. The table shows the graphsin which an edge can be in depending on the fact in which graphs the source andtarget nodes are in. An edge in L′ may only be connected to nodes in L′ and K.Accordingly, an edge in R′ may only be connected to nodes in R′ and K. Edges inK may only be connected to nodes in K.

To prevent the invalid model states described above, commands must be designed in a way,so that they ensure that modifications to a model do not lead to any invalid model state.The problems of checking for unique identifiers when adding or removing nodes, edges, orgraphs can be solved by rejecting the modification if the identifier is not unique. The samesolution holds for adding typed nodes or typed edges when no type node or edge is present.Then the modification is rejected. However, one problem that must be discussed is how tohandle the removal of node and edges. As described above, by removing nodes, edges canbe left dangling. By removing type edges or nodes, there can exist typed edges or nodesthat have no type any more. There are two solutions for this problem: Either forbidding thedeletion of those elements until all other elements that reference it are removed or removingthe referenced elements. I have decided to remove the referenced objects, as well, in orderto make the editing of the model more comfortable.

A similar problem must be discussed for rule graphs. In fact, a rule consists of three graphsL′, K, and R′ which are encoded in one graph in the model. The change of the attribute to

41

4 Realization

which graph a node or edge belongs is called a move between the graphs. When moving arule node in a rule graph, the resulting graph may become invalid according to figure 4.5.There are again two solutions: modifying the connected edges, so that the model is validagain or forbidding the the modification until the according edges are in the correct graph.I have decided to modify the connected edges in order to simplify the editing of the model.However, there are, in fact, three possibilities that can occur when moving a node:

1. After moving the node, the graph is still valid

2. The graph can be made valid, by moving edges

3. The graph cannot be made valid by moving the edges

In the first case, nothing has to be done, because the model is already valid. In the secondcase, the edges that are connected to the moved node can also be moved to other graphs, sothat the model becomes invalid. In the last case, there is an edge that connects a node in R′

to a node in L′. For this combination, no edge can connect these two nodes (table 4.1). Inthis case, there are two possible strategies: forbidding the move to a new graph for the nodeor deleting the edges that would render the model invalid. I have decided again to deletethe edges, because this simplifies the editing of the model.

The last task of editing is the moving of an edge between the three graphs of a rule.However,solving invalid model states by moving connected nodes, too, is problematic, because therecan exist multiple ways of moving the nodes, so that the model becomes valid again. Be-cause of that, the move of an edge is simply forbidden if the resulting model would beinvalid.

4.1.2 Implementation

In this section, I describe how the model and editing commands are implemented. Themodel can be found in the projects org.uniulm.gts.model andorg.uniulm.gts.model.edit. The commands are bundled in the projectorg.uniulm.gts.model.commands.

4.1.2.1 Model

For the implementation, I use the two java technologies EMF and GEF. I decided to use acode generator for creating the source code for the model, because generated code tendsto contain less errors and saves a lot of time. I chose to use EMF, the eclipse based codegeneration tool for modeling. Despite its advantages, code generators often provide onlyfew possibilities to add user generated code which might be necessary to describe logic thatwould otherwise make the model itself very complex. Because of that, the code to keepthe model valid is not put into the model itself, but it is realized by using GEF commands.GEF commands are used, because the graphical editor uses GEF. Therefore, the commandscan be better integrated in the editor.

The UML class diagram in figure 4.2 can be ported directly to EMF by creating an ecore filefrom it which describes all the classes, their attributes, relations, and further the hierarchiccompositional structure of the elements (this is called a containment/container relationshipin EMF). The containment structure is especially important for serializing the model toXML files, which is described in section 4.2.1. The nodes and edges for rule graphs containan attribute to express to which graph of the rule they belong to. This is realized by thejava enumeration RuleGraphType with three states, namely K, R, and L, representingthe belonging of the element to the graphs K, R′, and L′.

42

4.1 GTS model

The EMF generates two projects out of an ecore file: the interfaces and implementationsof the classes (org.uniulm.gts.model) and classes that provide rudimentary editingcapabilities for them (org.uniulm.gts.edit). Other projects like testing environ-ments and editors can also be generated, but they are not considered here. Furthermore, thegenerated implementation provides the listener pattern ([23]) for every class. Automaticconsistency for elements that have a binary relation is also available. When changing therelation in one object, it gets also changed in the other one automatically, e.g. when thesource attribute of an edge is set to null, the edge is automatically removed from the listof edges of the former source node. The reason why the model design is not closer tothe theory described in 2.2 is that EMF is based around classes and their connections toeach other. Morphisms for typed graphs or between the graphs of a rule could be realizedas methods of a class, but the implementation would not be provided automatically. Asa result, the morphisms are expressed as relations and compositions between the classes.In addition to that, the model described above is much more convenient for the editors, asdescribed in section 4.3. Some further adjustments have to be made to the ecore model inregard to the graphical editor: The classes for the nodes, edges, and graphs have a referenceto a view object that saves visual information about the corresponding element, i.e. sizeand position. As described in [3], a model could also be divided into two models where thesecond model only saves the graphical representation. This would provide a separation ofthe display information from the information of the GTS itself which is in general a goodfeature of a model, but there is no advantage specifically for this project. If there were mul-tiple graphical editors, all with a different way of displaying the graphs, it would justifythe separation. Furthermore, the implementation of such a separation would have been tootime-consuming. Because of that, the visual information is saved in the same model.

4.1.2.2 Editing commands

The commands are implemented as GEF commands, so they can easier be integrated intothe graphical editors just as described in [29]. GEF provides a base class Command wheremethods for executing, undoing, and redoing are provided. This class is meant for extend-ing it. Additionally, commands have a canExecute() method that is checked by thecommand stack prior to executing it. This method can be used to check for possible invalidmodel states. In the following, I show how I have solved the problems of editing the model(section 4.1.1) by using commands. A full list of commands for the modification of themodel is listed in table 4.2 (commands for changing the visual presentation of the modelare not listed). From this list, one can see that there is not one command for each elementof the GTS. The commands are more generic and determine the correct object of the modelfrom the given information, e.g. if the graph to which the node or edge is added is a rulegraph, the node or edge is also a rule node or edge, respectively. Each command checks inthe canExecute() command if it can be executed without rendering the model invalid.The execute() method saves values for undoing the command. If further modificationshave to be applied to the model to keep it valid, the corresponding commands are also cre-ated in the execute() method. At the end of this method, the redo() method is called.In the redo() method, the changes are in fact executed. Whereas in the undo() method,the previously saved values are restored and commands executed in the redo() methodare undone

In appendix C.1, two exemplary commands are shown: one for deleting nodes and onefor moving a node or an edge between the graphs R′, L′, and K in a rule. I have cho-sen these two commands, because they present the two more complex situations that canrender a model invalid. Listing 4.1 shows an excerpt of the NodeDeleteCommand. Inthis command, further commands are created in the execute() method (lines 1–19) inorder to delete edges connected to the node. If it is a type node, delete commands forthe typed nodes referencing it are created. These commands are executed in the redo()

43

4 Realization

EdgeCreateCommand Create an edgeEdgeDeleteCommand Delete an edgeEdgeModifyCommand Change the identifier of an edgeNodeCreateCommand Create a nodeNodeDeleteCommand Delete a nodeNodeModifyCommand Change the identifier of a nodeHostGraphCreateCommand Create a new host graphRuleGraphCreateCommand Create a new rule graphGraphDeleteCommand Delete a typed graphChangeGraphNameCommand Change the name of a typed graphChangeRuleGraphCommand Change the belonging of a node or

an edge to another rule graph

Table 4.2: Table of available editing commands.

1 p u b l i c vo id e x e c u t e ( ) {2 removedEdges=new L i n k e d L i s t <EdgeDeleteCommand> ( ) ;3 removedTypedNodes=new L i n k e d L i s t <NodeDeleteCommand> ( ) ;4 i f ( c h i l d i n s t a n c e o f ITypeNode ) {5 f o r ( I A b s t r a c t N o d e n : ( ( ITypeNode ) c h i l d ) . g e t T y p e s ( ) )6 removedTypedNodes . add ( new NodeDeleteCommand ( n ) ) ;7 }8 i f ( c h i l d i n s t a n c e o f INode ) {9 typeNode = ( ( INode ) c h i l d ) . ge tType ( ) ;

10 }11 f o r ( I A b s t r a c t E d g e e : c h i l d . ge tS rcEdg ( ) ) {12 removedEdges . add ( new EdgeDeleteCommand ( e ) ) ;13 }14 f o r ( I A b s t r a c t E d g e e : c h i l d . ge tTg tEdg ( ) ) {15 removedEdges . add ( new EdgeDeleteCommand ( e ) ) ;16 }17 r edo ( ) ;18 }19

20 p u b l i c vo id r edo ( ) {21 f o r ( EdgeDeleteCommand e : removedEdges ) {22 i f ( e . c a n E x e c u t e ( ) ) e . e x e c u t e ( ) ;23 }24 i f ( c h i l d i n s t a n c e o f ITypeNode ) {25 f o r ( NodeDeleteCommand n:removedTypedNodes )26 i f ( n . c a n E x e c u t e ( ) ) n . e x e c u t e ( ) ;27 }28 i f ( c h i l d i n s t a n c e o f INode ) ( ( INode ) c h i l d ) . s e t T y p e ( n u l l ) ;29 c h i l d . s e t G r a p h ( n u l l ) ;30 }31

32 p u b l i c vo id undo ( ) {33 c h i l d . s e t G r a p h ( p a r e n t ) ;34 i f ( c h i l d i n s t a n c e o f INode ) {35 ( ( INode ) c h i l d ) . s e t T y p e ( typeNode ) ;36 }37 i f ( c h i l d i n s t a n c e o f ITypeNode ) {38 f o r ( NodeDeleteCommand n:removedTypedNodes )39 n . undo ( ) ;40 }41 f o r ( EdgeDeleteCommand e : removedEdges ) e . undo ( ) ;42 }

Listing 4.1: Excerpt from the NodeDeleteCommand.

44

4.2 The platform

1 p u b l i c b o o l e a n c a n E x e c u t e ( ) {2 i f ( model i n s t a n c e o f ITrans fo rmEdge ) {3 TransformElementType s r c = ( ( ITransformNode ) ( ( ITrans fo rmEdge ) model ) . g e t S r c ( ) ) . g e t T r a n s

( ) ;4 TransformElementType t g t = ( ( ITransformNode ) ( ( ITrans fo rmEdge ) model ) . g e t T g t ( ) ) . g e t T r a n s

( ) ;5 i f ( newType . e q u a l s ( Trans formElementType .K) &&6 s r c . e q u a l s ( Trans formElementType .K) &&7 t g t . e q u a l s ( Trans formElementType .K) )8 r e t u r n t r u e ;9 e l s e i f ( ! newType . e q u a l s ( Trans formElementType .K) &&

10 ( s r c . e q u a l s ( Trans formElementType .K) | | s r c . e q u a l s ( newType ) ) &&11 t g t . e q u a l s ( Trans formElementType .K) | | t g t . e q u a l s ( newType ) ) )12 r e t u r n t r u e ;13 e l s e r e t u r n f a l s e ;14 }15 i f ( model i n s t a n c e o f ITransformNode ) r e t u r n t r u e ;16 r e t u r n f a l s e ;17 }

Listing 4.2: Excerpt from the ChangeRuleGraphCommand.

method (lines 20–30) by first removing the typed nodes (if the node itself is a type node),then the edges, and at last the node itself. Especially note the undo() method (lines32–42) where all the commands are undone, but in opposite order to keep the modelvalid in intermediate states. Listing 4.2 shows the canExecute() method from theChangeRuleGraphCommand. This command works on both, edges and nodes. Foredges, the canExecute() method checks whether the combination in the new graph isvalid according to table 4.1 (lines 2–14). Nodes may always be moved between the graphs(line 15), because edges connected to them are moved or deleted, as well.

4.2 The platform

The design of the platform itself is very important, because all the tools and the editors areembedded there. The platform consists, on the one hand, of GUI elements for displayingthe editors and for giving a choice for the analysis tools and, on the other hand, of theeclipse extension point where analysis tools can be plugged in.

4.2.1 Design

In this section, I explain the design of the GUI and the extension point, as well as the flowof information between analysis tools and editors.

4.2.1.1 Graphical user interface

The GUI of the platform consists of an editor which is placed in the eclipse workbench anda corresponding action bar. The editor must be able to display two embedded editors at thesame time (the graphical and the textual one). This split editor is called multi-bar editor(in relation to the already existing multi-page editor provided by eclipse). In the multi-bareditor, the editors are arranged vertically below each other, each one having a bar abovecontaining its name. The screen-shot in figure 4.6 shows a multi-bar editor instance with atextual editor expanded and a graphical editor collapsed. Each editor can be collapsed andexpanded by clicking on an arrow in the bar next to its name.

The GTS editor is extended from the multi-bar editor and is used as base editor for theplatform. It handles loading and saving of the GTS model and provides a shared commandstack for the editors and analysis tools.

45

4 Realization

Figure 4.6: The multi-bar editor.

Figure 4.7: The action bar of the multi-bar editor.

The second GUI element is an action bar for the multi-bar editor which can be seen in fig-ure 4.7. This action bar shows actions that are available for the editors which are embeddedin the corresponding multi-bar editor. Furthermore, it contains a combo box that lists allthe available analysis tools. Buttons for undo, redo, and delete operations are inserted atthe left side of the combo-box. The analysis tools can be launched by clicking the entriesof the combo box. The buttons on the right side of the combo-box are managed by the em-bedded editors. These buttons can be updated by the embedded editors. For example, thegraphical editor can display buttons to add new host and rule graphs depending on whichgraph is displayed at the moment.

Other needed GUI elements are file and project creation wizards that guide the user throughthe creation of new GTS. There must be a wizard to create a new GTS project which canhost multiple GTS files. For creating files that contain a GTS, another wizard must becreated. Both wizards are kept very simple and only ask the user to enter the name of theGTS project or select the project where the new GTS file should be added to and providethe name of the file. Both wizards are shown in figure 4.8.

4.2.1.2 Extendability

Before discussing how the platform’s extensibility can be designed, I describe the flowof information in the platform between the tools and the editors, first. Information aboutchanges in the model do not need to be exchanged between tools and editors, becausethe editors and tools can be directly updated from the model itself. Therefore, the onlyinformation that must be send to the analysis tools is the model itself, the file it was loadedfrom, and the command stack, so that the tools can read the model, modify it, or createfurther files depending on the file name of the model.

46

4.2 The platform

Figure 4.8: File (upper) and project (lower) creation wizards.

47

4 Realization

GTSAnalysisTool

GTSAnalysisTool

GTSEditor

GTSEditor

Textual Editor

Textual Editor

Graphical Editor

Graphical Editor

editor starts tool

setModel()

setFile()

setCommandStack()

addChangeListener()

tool requests display update

notifyDisplayUpdate()


Update display


Update display

when updating the view of an editor,the other editor's view is updated, too



Update display


Update display

Figure 4.9: UML sequence diagram of the flow of information between the editors and thetools.

The information that is displayed in the editors and the tools should always be synchro-nized. For that reasons, the information that must be transferred is which graphs, nodes,and edges are currently displayed, so that tools can display graphs and selections of nodesand edges directly in the editors. The sequence diagram in figure 4.9 shows that the GTSeditor is the central point of information transfer. Analysis tools can send information tothe GTS editor about activated graphs and selections. This information is then sent to allthe editors which update their view accordingly. This mechanism can also be used for syn-chronizing the view between the embedded editors by sending a notification with the graphto display from one of the editors to the platform. The platform then updates the view ofboth editors.

An eclipse extension point is used for plugging in analysis tools. As described in sec-tion 2.4, creating an extension point comes in two parts: designing the extension pointdefinition and providing an interface which must be implemented by the extension. Ba-sically, extension points only offer a flow of information to the extension, but a flow ofinformation from the extension is not realized. However, the analysis tools need to sendback notifications, so that graphs can be displayed in the editors. This is described in figure4.9. Therefore, the interface of the extension point must provide methods to set the GTSmodel, the command stack, and the file in the analysis tools. The file is needed, so thatanalysis tools that generate further files can name them reasonably. The command stack isneeded for analysis tools that modify the model. To receive information from the analysis

48

4.2 The platform

Figure 4.10: This screen-shot shows a multi-bar editor with two editors embedded. Theupper editor is a multi-page editor, the lower one is a text editor.

tools, methods for the listener pattern must be added, so that the platform can add itself aslistener to the analysis tool to get notified when a new graph or a part of a graph should bedisplayed. Because of that, a listener interface must be created that can be implemented bythe platform to receive notifications from the analysis tools. The extension point definitioncontains only three attributes: The identifier of the extension, the name that is displayedto the user when the extensions are listed, and the class that is loaded when starting theextension.


This section is split up into several parts: First, I provide some details about the multi-bareditor implementation, then I show how to save and load EMF models from files. Afterthat, I explain the methods of the interface for the extension point. The complete inter-face is also listed in appendix C.2. The next topic is the registration and visibility ofactions in the action bar. Then, there is a short section on how to load extensions anddisplay them in the combo-box of the action bar. At the end, I show how the communi-cation of the plug-ins with the editors is realized. The platform itself can be found in themain project org.uniulm.gts. The extension point definition is found in the projectorg.uniulm.gts.analysistool.

4.2.2.1 Multi-bar editor

The multi-bar editor is implemented in the class MultiBarEditorPart which is simi-lar to a MultiPageEditorPart, but with a MultiBar widget instead of aCTabFolder widget as underlying structure. Figure 4.10 shows an example of a multipage editor and a multi-bar editor where the multi-page editor is embedded in a multi-bareditor. These editors embed further editors on separate pages. Extending the

49

4 Realization

MultiPageEditorPart and overwriting all the methods that access the CTabFolderwidget is, however, problematic, because there are methods that are marked final andcan not be overwritten. As a consequence, the editor has to be reimplemented. Fur-thermore, some concepts from the MultiPageEditorPart cannot be supported. TheMultiPageEditorPart provides several means of modifying the active page whichrefers to the currently displayed page in the CTabFolder widget. However, a multi-bardoes not have an active bar because everything is displayed in parallel. For that reason,these features are not implemented. Additionally, the method for adding new editors hasbeen changed. A float value has to be given when adding a new bar for an editor. This floatvalue gives the relative height of the newly added bar. When resizing the window, collaps-ing or expanding a bar, these additional float values are evaluated to recalculate the heightof the expanded bars. The higher the float value is, the more space the editor gains. Theupper editor in the multi-bar editor in figure 4.10 has a float value that is twice as high as theone of the lower editor. This MultiBarEditorPart is extended by the GTSEditor(which is referred to as GTS editor in the remainder).

4.2.2.2 Saving/Loading GTS models

The GTS editor is the main editor of the platform. It features loading and saving mech-anisms for GTS models. Loading and saving EMF models is done by serializing theminto XML files. This service is directly provided by EMF: An EMF Resource objectis created from an eclipse Path object, then save and load operations can be applied tothe Resource object. An eclipse Path object contains the path to a file or folder. Afterdoing a load on a resource one can retrieve a list of its contents. There is the possibilityof saving multiple contents, i.e. multiple GTS models, but for this application only onemodel is saved. As described in section 4.1.2, the modeling technique of containers andcontainments is used in EMF. Objects can be inside of at most one containment. This givesthe model a tree-like structure which is needed for persistence, because EMF uses XMLto serialize the model and XML has a tree-like structure. If there are elements that arecurrently not in a containment, saving fails. Therefore, special attention must be paid whenmodifying the model (see section 4.1.1), so that all referenced objects are contained in an-other object. The functionality of loading and saving EMF models is bundled in the classModelManager which provides the functionality to load and save models to files and tocreate new models when starting a fresh GTS.

4.2.2.3 Wizards

Other features that have to be implemented are project and file creation wizards for GTS.In section 4.7, I explain why an own project is needed for GTS. However, the projectcreation wizard (bundled in the class NewGTSProjectWizard) creates a new eclipseplug-in project, so that plug-ins can be added as dependencies. The creation is done viaJET which is described in section 4.6. JET is used, because it features an easy way tocreate projects and files in the eclipse workspace. The new file wizard (bundled in the classModelWizard) creates a new GTS model with only the type graph, but without host andrule graphs. This model is then serialized to the file which the user has entered in thewizard. The creation of the initial model is done by the ModelManager class mentionedin the previous section.

4.2.2.4 Extension point

The implementation of the extension point is very close to the design described above. Theinterface’s name is IGTSAnalysisTool. However, an additional method is added to the

50

4.2 The platform

1 p u b l i c v o id computeTools ( L i s t < S t r i n g > names , L i s t < IGTSAnalys i sToo l > t o o l s ) {2 names . c l e a r ( ) ; / / s a ve t h e names3 t o o l s . c l e a r ( ) ; / / s ave t h e t o o l s i n s t a n c e s4 I E x t e n s i o n R e g i s t r y r e g i s t r y = P l a t f o r m . g e t E x t e n s i o n R e g i s t r y ( ) ;5 I E x t e n s i o n P o i n t ep = r e g i s t r y . g e t E x t e n s i o n P o i n t ( " o rg . uniu lm . g t s . a n a l y s i s t o o l " ) ;6 I E x t e n s i o n [ ] e x t s =ep . g e t E x t e n s i o n s ( ) ;7 f o r ( I E x t e n s i o n e x t : e x t s ) {8 f o r ( I C o n f i g u r a t i o n E l e m e n t c : e x t . g e t C o n f i g u r a t i o n E l e m e n t s ( ) ) {9 t r y {

10 O b j e c t t o o l =c . c r e a t e E x e c u t a b l e E x t e n s i o n ( " c l a s s " ) ;11 i f ( t o o l i n s t a n c e o f IGTSAnalys i sToo l ) {12 names . add ( c . g e t A t t r i b u t e ( " name " ) ) ;13 t o o l s . add ( ( IGTSAnalys i sToo l ) t o o l ) ;14 }15 } c a t c h ( E x c e p t i o n e ) { . . . }16 }17 }18 }

Listing 4.3: Load extensions from an extension point.

interface in order to tell the analysis tool that it should start its analysis (runAnalysis()).This method is called after the command-stack, the file, and the model are set for the tool.The complete code for the interfaces and the extension point definition can be found inappendix C.2. A guide for creating an analysis tool can be found in section 4.5.2.

Loading extensions in eclipse is done in multiple steps. Listing 4.3 shows the used codethat is used to load all the analysis tools from the extension point and save them to twolists. First, the extension registry must be fetched (line 4). From there, one gets the desiredextension point by giving its identifier (line 5). The extension point contains a list of its ex-tensions (line 6). Each extension consists of a list of ConfigurationElements whereeach element contains a definition of an extension. The attributes of the extension can bequeried for each ConfigurationElement. From the attribute class an executableclass is loaded and instantiated (line 10). This object is then saved in a list of tools (line13). The name attribute is saved in a list of strings. This list is used for displaying theanalysis tools in a combo box (line 12).

4.2.2.5 Action bar

As described in the design section (4.2.1), the platform has a common action bar for all theeditors. This action bar’s main element is a combo-box that displays all available analysistools. This combo box is implemented in the classPluginSelectToolbarContribution. Elements, except buttons, that are added toan action bar, are called action bar contributions in the eclipse framework or contributionif the context is clear. This combo-box contribution handles the loading of the extensionsas described in the previous section and launches the tools by clicking on their entry. List-ing 4.4 shows how an analysis tool extension is started. When launching an analysis toolextension, the model, the file, and the command stack of the currently active editor are setin the tool. Furthermore, the currently used GTS editor is added as a listener to the tool af-ter removing all old listeners (lines 9–14). Finally, the runAnalysis() method is called(line 15) within a SafeRunnable instance which provides an extra thread that catchesexceptions (lines 2–15). The active model, file, and command stack are always saved inthe combo-box in corresponding variables. Further attention has to be paid when usingmultiple instances of the GTS editor in parallel, because they all share the same action bar.Therefore, each editor has a reference to the combo box in the action bar and every time aneditor receives focus, it sets the model, file, and command stack in the combo box, so thatthe tools receive the content of the currently displayed editor.

51

4 Realization

1 f i n a l IGTSAnalys i sToo l t = t o o l s . g e t ( cb . g e t S e l e c t i o n I n d e x ( )−1) ;2 I S a f e R u n n a b l e run = new I S a f e R u n n a b l e ( ) {3 p u b l i c vo id h a n d l e E x c e p t i o n ( Throwable e x c e p t i o n ) {4 S t r i n g [ ] b u t ={ "Ok" } ;5 MessageDia log md=new MessageDia log ( n u l l , " E r r o r e x e c u t i n g t o o l " , n u l l , "An

u n e x p e c t e d e r r o r o c c u r r e d d u r i n g t o o l e x e c u t i o n " , 0 , but , 0 ) ;6 md . open ( ) ;7 }8 p u b l i c vo id run ( ) t h r ows E x c e p t i o n {9 t . s e tMode l ( model ) ;

10 t . setCommandStack ( commandStack ) ;11 t . s e t F i l e ( f i l e ) ;12 t . r e m o v e A l l L i s t e n e r s ( ) ;13 i f ( e d i t o r != n u l l )14 t . a d d C h a n g e L i s t e n e r ( P l u g i n S e l e c t T o o l b a r C o n t r i b u t i o n . t h i s . e d i t o r ) ;15 t . r u n A n a l y s i s ( ) ;16 }17 } ;

Listing 4.4: Start selected extension from PluginSelectToolbarContribution.

As already mentioned, the editors can register their own actions to the action bar. To realizethat, the action bar has the method registerRetargetActions(List<IAction>)to add actions to it. Not all actions are shown permanently, but only when the displayededitors need them. Because of that, every time when the platform is notified about a displayupdate for the editors, it queries the currently active actions of the editor and sends them tothe action bar, which updates the displayed actions accordingly.

Up to now, only tools can send information about active graphs, nodes, and edges to theplatform, but there is no communication between the tools. However, the interface alreadyprovides methods for setting active graphs, nodes, and edges. This might be especiallyuseful for tools that combine multiple other tools, e.g. analysis environments combiningseveral analysis tools or alternative display modes.

4.3 The graphical editor

This section covers the realization of the graphical editor. The design section explains thegraphical user interface of the editor. The editor is based on GEF and implements theMVC paradigm. This is described in the implementation section together with the toolsand actions that are provided for the editor. A sample computation for the creation of aGTS is shown at the end of this section.

4.3.1 Design

This section covers the design of the graphical editor’s GUI. In a GTS, there are multipletypes of graphs (type graph, host graphs, and rule graphs) which need to be edited by thiseditor. The editor should provide an intuitive method of editing together with visual feed-back about invalid model states (section 4.1.1.2). Editing type graphs is basically editinga normal graph where identifiers for nodes and edges must be supplied. Because of that, astandard editor with tools for creating nodes and edges can be chosen. Figure 4.11 shows astandard GEF editor with a palette on its right containing a selection, a node-, and an edge-creation tool. Typed graph editors are needed for editing rule and host graphs. For typedgraphs, the type graph or at least a list of the types for nodes and edges, must be available.However, displaying the type graph directly to choose the edges and nodes that should becreated next is better, because it shows directly the context of the node or edge type thatshould be created. Using only a list of types (like in Groove or AGG) leads to switchingback to the type graph editor to look up the adjacent edges and nodes of the selected node

52


Figure 4.11: Standard graphical editor for creating type graphs where the identifier of anew edge is queried.

Figure 4.12: Host graph editor together with a type graph, to select the types of nodes andedges.

or edge. Furthermore, when creating new edges in a typed graph, the nodes that cannot beselected as source (or target) should be grayed out, so that the user cannot add edges to thegraph that are incorrect according to the type graph. An editor for creating a host graph(which is in fact a typed graph) could be realized as shown in figure 4.12 with the typegraph displayed above the typed graph editor. The type graph is displayed above the hostgraph editor and can be used to select the type of the node or edge that should be creatednext. A new edge of the type onTable is currently created in the screen-shot. This edge canonly connect nodes of the fork type, therefore, the philosopher nodes are grayed out. Typednodes and typed edges can be created in the type graph by selecting the corresponding typenode or edge in the type graph and then clicking at the appropriate position in the typedgraph editor.

In a GTS, there are in general several host graphs and rules. Because of that, the typed grapheditor must offer a way to select the graph that should be displayed in the editor. Figure4.13 shows a typed graph editor with an embedded list of the available graphs on the rightside. A new graph can be displayed by clicking on the according entry. Furthermore, thename of the graph must be displayed in the graphical representation of the graph.

53

4 Realization

Figure 4.13: Host graph editor together with a list of available graphs on the right side. Thetype graph is collapsed.

Another variant of typed graphs are rule graphs. There are several ways of giving a graphi-cal notation of rule graphs, as described in section 2.2. In the two and three graph notations,the morphisms between the graphs must be provided explicitly. The one graph notation im-plicitly contains these morphisms. I have decided to use the one graph notation, becauseit is a compact and simple notation without the need of manually specifying morphisms.Another benefit of this is that the typed graph editor described above can also be used forediting rule graphs. However, for rule graphs, a context menu has to be added, so that thenodes and edges can be made green, red, or black. Figure 4.14 shows the rule editor withthe context menu for moving an edge between the red, black, and green graph of a rule.

As the editors for host and rule graphs both enable the user to edit several graphs, actionsmust be provided to add and remove host graphs and rules. These actions can be embeddedin the action bar of the platform, as shown in figure 4.15.

As just stated, the graphical editor should consist of three editors (for type, host, and rulegraphs). These editors are grouped together on multiple pages, so that the user can switchbetween them. The actions in the action bar contributor should be updated accordinglywhen the editors are switched. Figure 4.16 shows these pages for the type, rule, and hostgraph editor. The type graph editor is currently displayed.


The implementation is divided into multiple parts. First, I describe how the model viewcontroller (MVC) ([27]) paradigm is implemented in GEF, then I show the implementa-tion of the edit-policies for creating the commands to edit the models. This can all beused by the editors for type, rule, and host graphs in common. The next section de-scribes how the editors themselves are implemented and the last section shows how fur-ther actions for the editors are added. The graphical editors can be found in the projectorg.uniulm.gts.graphicaleditors.

4.3.2.1 Model View Controller (MVC)

In GEF, the controller objects are called Editparts. GEF already provides a base im-plementation in form of an AbstractGraphicalEditpart, which contains severalmethods that can be overwritten to add functionality. Table 4.3 shows the methods that areof interest. There are a few more methods, but I present only the ones used in this project.

For the graph model defined in section 4.1.1, there are basically three EditPart classes,one for edges, one for nodes, and one for graphs. The EditPart instances are created via

54


Figure 4.14: Rule graph editor with context menu for changing the graph of an edge or anode in a rule.

Figure 4.15: Actions for adding and removing host graphs in the action bar of the platform(marked with a red rectangle).

Figure 4.16: Multi page editor containing a rule, host and type graph editor, the type grapheditor is currently the active page.

55

4 Realization

createFigure() create the view objectrefreshVisuals() refresh the view from the modelgetModel() return the model objectgetModelChildren() return all children elements of the modelgetModelSourceConnections() return all edges that are connected as sourcegetModelTargetConnections return all edges that are connected as targetactivate() activate the edit-partdeactivate() deactivate the edit-partcreateEditPolicies() create edit policies for the edit-part

Table 4.3: Important methods, provided by the AbstractGraphcialEditpart, thatshould be implemented by the extending class.

NodeModifyCommand

NodeModifyCommand

Node

Node

NodeEditPart

NodeEditPart

NodeView

NodeView

changeId()

notifyChanged()

refreshVisuals()

setId()

void

void

void

Figure 4.17: UML sequence diagram, showing how the view of a node is updated from themodel.

a factory used by the editor. This factory is implemented in the classGraphEditPartFactory and returns the corresponding EditPart instance for amodel element. EdgeEditPart instances are created for objects which are instancesof the class IAbstractEdge. Accordingly, a NodeEditPart is created for instancesof the IAbstractNode class and a GraphEditPart is created for objects of the classIGraphModel. The edit parts together with their model instances are listed in table 4.4.

All of the edit parts implement the activate() and deactivate() method in whichthey add or remove themselves as listener to their model element. To do that, they must im-plement the EMF Adapter interface, which provides the notifiyChanged()method.This interface is used by the EMF to notify its listeners. In this method, the edit-parts getnotified about changes in the model. The UML sequence diagram in figure 4.17 shows howthe edit parts are updated from the model. This example shows how a Node object is mod-ified by a NodeModifyCommand and how the corresponding NodeEditPart is updated.When the Node is modified, e.g. by changing its id attribute, the notifyChanged()method of the corresponding NodeEditPart instance is called. In this method, the edit-part itself updates the corresponding view element with the method refreshVisuals().The class NodeView implements the graphical representation of a node. Depending onthe type of the edit-part, other refresh methods are called. The GraphEditPart callsthe refreshChildren() method which fetches the model element’s children, i.e. thenodes, by calling the getModelChildren() method. getModelChildren() re-turns a list of all the nodes in the GraphEditPart’s model. The GraphEditPart

56


NodeEditPart Controller for (type-, host- and rule-) nodesEdgeEditPart Controller for (type-, host- and rule-) edgesGraphModelEditPart Controller for (type-, host- and rule-) graphs

Table 4.4: Available EditPart classes.

then checks if any nodes or edges are removed or added and updates the edit-parts for thenodes accordingly.

In the createFigure() method which is also implemented by all edit parts, a draw2dfigure is created. Edges are represented as PolylinePonnection, nodes as NodeView,and graphs as FreeformLayer instances. Only for the nodes, the new classNodeViewPart is extended from the draw2d Rectangle class. Graphs and edgesare displayed using standard classes from draw2d. A new class is created for the nodes,because it contains multiple labels what makes updating this view more complex.

4.3.2.2 Edit policies

Before describing the createEditPolicies()method of the edit-parts (see table 4.3),I want to explain how editing works in GEF. The root of all editing actions is the Toolclass. This class sends (upon user interaction) a Request instance to an EditPart. ThisRequest signals that the model shall be edited. The EditPart sends this Request toits EditPolicy instances which create the corresponding Command instances to ma-nipulate the model. The commands are already described in section 4.1.2. Therefore,the GraphEditPart needs an edit policy for moving around and resizing nodes, aswell as adding them. This is the GraphXYLayoutPolicy. Changing the name of agraph is handled by the ChangeGraphNameEditPolicy that is only added for typedgraphs, i.e. rule and host graphs. NodeEditParts need edit policies for deleting nodes(NodeComponentEditPolicy), adding edges (EdgeCreateEditPolicy) , mov-ing the nodes between the graphs of a rule (TransformTypeEditPolicy, only for rulegraphs), and changing the name of a node (LabelDirectEditPolicy).EdgeEditParts for edges of a type graph have an edit policy for changing the identifier(LabelDirectEditPolicy). For creating edges, another edit-policy must be installed(ConnectionEndpointEditPolicy). Edges in rule graphs have aTransformTypeEditPolicy installed that generates commands for moving the edgebetween the graphs of the rule. Handling bend-points of the edges is done in theEdgeBendpointEditPolicy. Another edit policy is installed for deleting edges(ConnectionEditPolicy). All these edit policies create the commands dependingon the model element contained by the edit part. Creating the command is done in thegetCreateCommand() method. Listing 4.5 shows the getCreateCommand()method from the GraphXYLayoutEditPolicy class for creating a newNodeCreateCommand. In this example, a new command for adding a node to a graphis created. First, it is checked whether the object contained in the request is of the correctclass INode (line 3). If that is not the case, the edit-policy returns null. This meansfor edit-policies in general that they are not responsible for this request. If the request tocreate a node is TypedNodeCreateRequest, i.e. when a typed node should be cre-ated, then the according type node is queried from the request (line 4–7). At the end, anew NodeCreateCommand instance is returned (line 8–11) which is initialized with themodel object for the graph, the size and location of the new node, the type node, and anidentifier for the node which is left blank. The command (section 4.1.2.2) modifies themodel according to the input. If the type is null and the graph model is a type graph thena type node is created. If the type node is not null, then depending on the type of the graph,

57

4 Realization

1 p r o t e c t e d Command getCreateCommand ( C r e a t e R e q u e s t r e q u e s t ) {2 O b j e c t c h i l d C l a s s = r e q u e s t . ge tNewObjec t ( ) ;3 i f ( c h i l d C l a s s i n s t a n c e o f INode ) {4 ITypeNode t y p e = n u l l ;5 i f ( r e q u e s t i n s t a n c e o f TypedNodeCrea teReques t ) {6 t y p e = ( ( TypedNodeCrea teReques t ) r e q u e s t ) . getTypeNode ( ) ;7 }8 r e t u r n new NodeCreateCommand (9 ( IGraphModel ) g e t H o s t ( ) . ge tModel ( ) ,

10 ( R e c t a n g l e ) g e t C o n s t r a i n t F o r ( r e q u e s t ) ,11 type , " " ) ;12 }13 r e t u r n n u l l ;14 }

Listing 4.5: getCreateCommand() from theGraphXYLayoutCreateEditPolicy.

a node for a rule graph or a node for a host graph is created. If the identifier for the node isleft blank, then the command queries the name from the user.

4.3.2.3 Editor

GEF has several base classes for creating editors. I have chosen theGraphicalEditorWithFlyoutPalette, because it already contains a palette whichcan hold tools for creating nodes and edges. This base class has to be extended to cre-ate custom editors. Basically, the two methods initializeGraphicalViewer andconfigureGraphicalViewer have to be implemented for setting the model thatshould be displayed and for configuring the editor. Configurations include setting con-text menus and an edit-part factory. At first, details are given for the type graph editor andthen for the typed graph editors, i.e. the host and rule graph editors.

For the type graph editor, an instance of the GraphEditPartFactory as the edit partfactory is set and a palette with two tools, one for creating nodes and one for creating edges(bundled the class TypeGraphPaletteFactory), is added. The two tools are alreadyprovided by GEF.

Implementing the typed graph editors is more complex, as the type graph is also needed forselecting the type nodes and edges. This is realized by embedding two editors in a multi-bareditor, as shown in figure 4.12. The upper one displays the type graph (GraphViewer).The lower one is the editor for typed graphs itself (TypedGaphEditor). TheGraphViewer is a GEF editor with only a selection tool and no palette, so that no edit-ing can be done there. The typed graph editor has a reference to a GraphViewer andadds itself as selection listener to it. Therefore, every time the user selects a new node oredge in the GraphViewer, a notification is sent to the TypedGraphEditor. Whenit receives notification that a new node or edge was selected, the active tool is changed.If a node is selected in the graph viewer, a TypedNodeCreationTool becomes theactive tool. When an edge is selected, a TypedEdgeCreationTool becomes active.Therefore, the graph viewer is the tool selector for this editor. When no node or edge isselected, a SelectionTool is activated in the TypedGraphEditor. The palette isused, as well, but it displays a list of available typed graphs and provides the possibility toselect them (see figure 4.13). To use the palette as a list of typed graphs, the editor addsitself as PaletteListener to get notified when the active tool is changed. During atool change event, the editor removes the old graph from the display and sets the selectedgraph as the new model. The elements in the palette are in fact selection tool entries withdifferent labels, so that the identifier of the graph is displayed. The typed graph editor alsoadds itself as listener to the GTS model element, so that it gets notified when graphs are

58


1 p u b l i c v o id run ( ) {2 i f ( t g e . ge tC ur r en tG raphM ode l ( ) i n s t a n c e o f IHos tGraphmodel ) {3 ITypedGraphModel g =( ITypedGraphModel ) t g e . ge tCur r en tGraphMode l ( ) ;4 GraphDeleteCommand h o s t =new GraphDeleteCommand ( g ) ;5 cs . e x e c u t e ( h o s t ) ;6 }7 }

Listing 4.6: run() method from the DeleteGraphAction super class.

GTSEditor

GTSEditor

GTSMultiPageEditor

GTSMultiPageEditor

ActivePage

ActivePage

setActiveGraph()

switch tocorrect pageaccording to

the graph

setActiveGraph()

display new graph

void

void

Figure 4.18: Flow of information from the platform to the graphical editor.

added or removed. When a new graph is added, the editor displays this new graph and addsan according entry to the palette. When a graph gets deleted, it displays the next graph inthe list and removes the current one from the palette. Furthermore, the editor needs a refer-ence to the list of typed graphs it edits, the command stack, and the GTS model itself.Theeditor described above can be used as host and rule graph editor.

For each typed graph editor two actions are registered in the action bar to add and deletehost and rule graphs, respectively. Actions provide a method run(), that is called whenclicking on a toolbar entry associated with this action. The actions for adding and removingtyped graphs each have super classes that implement the run()method. Listing 4.6 showsthe run() method of the DeleteGraphAction. The action has references to the typedgraph editor in the variable tge and to the command stack (cs). The method retrieves thecurrent graph model from the editor, creates a GraphDeleteCommand from it, and addsit to the command stack. The editor is then updated due to the changes that are made inthe model. The run() method of the NewGraphAction first asks the user to input aunique identifier and then creates the according command for creating a new graph. Themethods for retrieving the correct command and for retrieving a list of available graphs (tocheck if the entered identifier is unique) must be implemented by the actions for host andrule graphs, respectively.

The three editors described above (for type, host, and rule graphs) are each added on aseparate page in a MultiPageEditorPart to become the final graphical editor forGTS (GTSMultiPageEditor), as can be seen in figure 4.16. All editors, as well asthe MultiBar- and MultiPageEditorParts implement the analysis tool interfacefrom the extension-point, described in section 4.2.2.4, to simplify the flow of informationbetween the type-, rule-, and host graph editors and the platform. Figure 4.18 shows asequence diagram for the flow of information when the platform notifies the editor abouta new graph that should be displayed. The multi page editor may receive notifications

59

4 Realization

1 p u b l i c b o o l e a n e v a l u a t e ( E d i t P a r t e d i t p a r t ) {2 i f ( e d i t p a r t != n u l l ) {3 i f ( TypedEdgeCrea t ionToo l . t h i s . g e t S t a t e ( ) == TypedEdgeCrea t ionToo l . STATE_INITIAL4 && e d i t p a r t i n s t a n c e o f N o d e E d i t P a r t5 && ( ( N o d e E d i t P a r t ) e d i t p a r t ) . ge tModel ( ) i n s t a n c e o f INode6 && typeEdge . g e t S r c ( ) . e q u a l s ( ( ( INode ) ( ( N o d e E d i t P a r t ) e d i t p a r t ) . ge tModel ( ) ) .

ge tType ( ) ) )7 r e t u r n t r u e ;8 e l s e i f ( TypedEdgeCrea t ionToo l . t h i s . g e t S t a t e ( ) == TypedEdgeCrea t ionToo l .

STATE_CONNECTION_STARTED9 && e d i t p a r t i n s t a n c e o f N o d e E d i t P a r t

10 && ( ( N o d e E d i t P a r t ) e d i t p a r t ) . ge tModel ( ) i n s t a n c e o f INode11 && typeEdge . g e t T g t ( ) . e q u a l s ( ( ( INode ) ( ( N o d e E d i t P a r t ) e d i t p a r t ) . ge tModel ( ) ) . ge tType

( ) ) )12 r e t u r n t r u e ;13 }14 r e t u r n f a l s e ;15 }

Listing 4.7: evaluate() method of the Conditional class.

from the platform to display a new graph, so it checks what type of graph it is (type, rule,or host), displays the corresponding page, and signals the editor on this page to displaythe given graph. When certain nodes and edges shall be selected, the multi page editorforwards the list of nodes and edges to the active editor. The active editor then translatesthis list into a Selection for the GEF editor. Selections are a list of objects that aremarked as selected in the editor. When the user selects another graph in one of the typedgraph editors, the editor notifies the multi page editor about a graph change. When the multipage editor gets notified about a graph change, it forwards this information to the platform.When a page change occurs, it also notifies the platform, about the new displayed graph.This is shown in figure 4.9. The platform can then update the other editor, so that the samegraphs are displayed in both editors.

4.3.2.4 Tools and actions in the editors

For the creation of typed nodes and edges, two special tools are needed that contain the typeof the new element. These two tools can be found in the classesTypedNodeCreationTool and TypedEdgeCreationTool. The custom tools forcreating typed edges and nodes are made the active tools when a selection change eventin the graph viewer occurs. Consequently, the first element of the current selection is setas the type for the next created element. The tool sends a TypedNodeRequest (orTypedEdgeRequest) which contains the currently active type node (edge) to the ac-cording controller object. The typed edge creation tool has an additional feature. As theuser should be informed very early about valid (and invalid) editing options, the editor addsitself as state change listener to the tool, so that the editor gets notified when the tool is se-lected when the source has been selected and when the operation is finished. The editorreacts on these events with graying out the nodes to which the edge cannot be connected, i.e.all nodes of the wrong type. This change of colors is done in the model itself. As describedin 4.1.2, each model references an object that saves its visual information. This object isused to store whether a node may be used or not. This is then displayed accordingly bythe editor. The nodes are not only grayed out but also inaccessible for the tool. To realizethis, the getTargetConditional() method from the CreationTool base class isused. It returns a Conditional instance. This class provides the method evaluate()which returns a boolean value. This implementation returns true if the targeted node isvalid and false otherwise. Listing 4.7 shows the implementation of the evaluate() method.This conditional first checks in which state the tool is, i.e. wether the source or target mustbe selected next (lines 3 and 8). Then it checks if the target or source node currently pointedat is of the correct type, according to the source and target of the type edge (lines 4–6 and

60


Figure 4.19: Wizard for creating a new GTS project.

9–11). If the node is valid, then true is returned, false otherwise. With this mechanism,no invalid model states in regard to the type graph can be produced.

For the rule graphs, there must exist a possibility to set the graph of the nodes and edgesto R′, L′, and K depending on whether they are removed, added, or if they stay dur-ing the rule application. Therefore, the actions TransformTypeToKSelectAction,TransformTypeToLSelectAction, and TransformTypeToRSelectActionare added to the context menu of the typed graph editor. The entries in the context menuare only available if the TransformTypeEditPolicy is added to the node or edge,i.e. the entries are only available in the rule graph editor. By opening the context menuof a node or edge and selecting one of the actions, the selected node or edge is moved tograph L′, R′, or K (depending on the selected entry). As a result, the action creates acorresponding command and adds it to the command stack.

4.3.3 Sample computation

In this section, I want to show how the GTS version of the dining philosophers problemcan be created with the graphical editor. First, a new GTS project must be started calledsample (figure 4.19). Then a new GTS file is created by launching the according wizard(figure 4.20). As a first step in creating the GTS for the dining philosophers, the typegraph must be created, by selecting the according tools to create nodes and edges. Theuser is prompted to enter a unique identifier for each edge and node. Figure 4.21 shows thecomplete type graph for the dining philosophers problem.

In the next step, some rules are added. After switching to the rule graph editor page,the button in the bar is clicked to create a new rule (the rule thinkToWait is created), seefigure 4.22. Now the type graph viewer can be used to select the philosopher node andclick on the rule graph editor to add this node to the graph. The new node is called P.Now, two edges, one of type think and one of type wait, must be added as loops to thephilosopher node P. The resulting graph is depicted in figure 4.23. As the think edge is

61

4 Realization

Figure 4.20: Wizard for creating a new GTS file.

Figure 4.21: The type graph for the dinging philosophers problem.

62


Figure 4.22: Create a new rule for the GTS by clicking on the according icon.

Figure 4.23: Node and two edges added to the rule thinkToWait.

63

4 Realization

Figure 4.24: Finished rule thinkToWait, the think edge is removed and the wait edge isadded by this rule.

removed during rule application, it is selected and the context menu is brought up. Whenthe entry “Element is removed” is selected, the edge turns red symbolizing that it is removedduring rule application. The wait edge is modified by selecting the “Element is added”entry from the context menu resulting in the graph shown in figure 4.24. Further rulegraphs can be created in the same manner.

Creating a host graph is done in a similar fashion by switching to host graph page andhitting the button to create a new host graph (figure 4.25). Adding nodes and edges is thesame as for rule graphs. Figure 4.26 shows a graph with four philosophers where one iseating.

4.4 The textual editor

Originally, the textual editor for CHR was planned as a lab course at the institute where thisthesis has been created and should be integrated into the platform. But there were no resultsavailable at the time of implementation, so I have decided to provide an own prototypicalimplementation. Besides creating an editor, an algorithm must be designed to check if theCHR source encodes a valid GTS and apply the according changes to the GTS model. TheCHR source code must of course be dynamically updated when the model is edited in thegraphical editors or with other analysis tools. Another feature that is provided for rapidlycreating rules and host graphs is the “easy editing mode” which offers a simpler encodingof host and rule graphs, which is suitable for editing purposes.

4.4.1 Design

The design of the editor is divided into three parts: The design of the GUI elements of theeditor itself, the design of the algorithms that check if the CHR source encodes a valid GTSand update the GTS model accordingly, and, as the third part, the notation which used todisplay an encoded GTS is described. The notation is shown first.

64


Figure 4.25: Create a new host graph for the GTS by clicking on the according icon.

Figure 4.26: Host graph for the dining philosophers problem with four philosophers.

65

4 Realization

Figure 4.27: Encoding of a host graph.

4.4.1.1 Notation

The textual editor displays the encoding of two graphs at a time, either the type graph ora typed graph together with its type graph. This restriction is set, because the graphicaleditor described in section 4.3 shows at most two graphs of the GTS: The type graph andeventually a host or a rule graph. Three types of graphs can be displayed, so three modesof displaying the graph in the CHR editor are needed. A type graph is encoded as a listof constraint definitions (see section 2.3). The syntax of the CHR code is kept similar tothe one of K.U. Leuven JCHR, because this is the language GTS are exported to for CHRanalysis tools (section 4.6). The type graph of the dining philosophers problem, which isshown in figure 2.7, is encoded as follows:

1 p u b l i c C o n s t r a i n t p h i l o s o p h e r ( L o g i c a l , i n t ) , f o r k ( L o g i c a l , i n t ) ,2 t h i n k ( L o g i c a l , L o g i c a l , L o g i c a l ) , w a i t ( L o g i c a l , L o g i c a l , L o g i c a l ) ,3 e a t ( L o g i c a l , L o g i c a l , L o g i c a l ) , onTab le ( L o g i c a l , L o g i c a l , L o g i c a l ) ,4 l i e s N e x t T o ( L o g i c a l , L o g i c a l , L o g i c a l ) ;

As JCHR is a language with type support, types have to be defined for the constraints. Thetype Logical is a generic type that describes a logical value to which arbitrary values canbe assigned. The type int stands for an integer value. In the example above, every nodeand edge type is encoded as a constraint definition. In section 2.3, host graphs are encodedas lists of goal constraints. However, JCHR does not have a notation for defining goals inits source files. Goals can only be given in a java program that uses the JCHR handler. Thisnotation is not very suitable, because it would require a lot of writing for the user. That iswhy a mixture of JCHR and Prolog based CHR syntax is chosen: The constraint definitionsare given at the beginning, according to the encoding of the type graph, then a line startingwith “:-” followed by a comma-separated list of the encodings of the host graph’s nodesand edges which is terminated by a colon (“.”) is given. Figure 4.27 shows an encodingof a host graph for the example of the dining philosophers problem (section 1.3.2). Theencoding of the according type graph can be found above. For the CHR encoding, everynode needs a unique identifier, so they are labeled platon and aristotle for the philosophernodes and f1 and f2 for the fork nodes. The syntax of the encoding of single constraintsis equivalent to the one described in section 2.3. The encoding of rule graphs works ina similar way: At the beginning, there are the constraint definitions from the rule graphfollowed by the encoding of the rules according to the description in section 2.3. Theencoding of the rule is kept tight to the syntax of JCHR where all rules are enclosed bya rules{...} block and the empty body of a rule is symbolized by the java keywordtrue. Figure 4.28 shows the encoding of the rule waitToEat from the dining philosophersexample (section 1.3.2), as described in section 2.2. Again, the type graph is not displayed.

66


Figure 4.28: Encoding of a rule graph.

Additionally, another encoding for constraints is supported than the one described in sec-tion 2.3. In this encoding, the constraints that represent nodes are unary and they containonly the identifier of the node. The constraints that represent edges are binary constraintsand contain the identifiers of the node constraints for the source and target. For the twotypes of constraints, the degree and the deletion attribute is left away. This can be done forediting, because the degree attribute is only needed for rule application in a CHR programto prevent dangling edges and the deletion attribute is only needed for confluence analysisof CHR programs. The encoding of the host graph from figure 4.27 results in:

1 :−p h i l o s o p h e r ( p l a t o n ) , p h i l o s o p h e r ( a r i s t o t l e ) , f o r k ( f1 ) , f o r k ( f2 ) ,2 l i e s N e x t T o ( f1 , p l a t o n ) , l i e s N e x t T o ( f1 , a r i s t o t l e ) ,3 l i e s N e x t T o ( f2 , p l a t o n ) , l i e s N e x t T o ( f2 , a r i s t o t l e ) ,4 t h i n k ( a r i s t o t l e , a r i s t o t l e ) , e a t ( p l a t o n , p l a t o n ) .

The rule graph from figure 4.28 results in:1 r u l e s {2 p h i l o s o p h e r ( P ) , f o r k ( F1 ) , f o r k ( F2 ) ,3 l i e s N e x t T o ( F2 , P ) , l i e s N e x t T o ( F1 , P ) ,4 onTable ( F1 , F1 ) , onTab le ( F2 , F2 ) , w a i t ( P , P )5 <=>6 p h i l o s o p h e r ( P ) , f o r k ( F1 ) , f o r k ( F2 ) ,7 l i e s N e x t T o ( F2 , P ) , l i e s N e x t T o ( F1 , P ) , e a t ( P , P ) .8 }

4.4.1.2 Encoding/decoding algorithms

In this section, I describe the algorithms for the encoding and decoding of the GTS to andfrom CHR. Encoding is a simple algorithm for all types of graphs, because each graph canbe encoded into a correct CHR program, just as described in section 2.3. However, notevery CHR program encodes a correct GTS. This means, if the CHR source is syntacticallycorrect, the CHR rule or goal can still represent an invalid graph, e.g. the graph couldhave dangling edges. See also section 4.1 for more information about incorrect GTS modelstates. Therefore, an algorithm must be developed to verify CHR rules and goals, whetherthey represent a valid host or rule graph. In the previous section, another, simpler encodingfor constraints is introduced. However, the encoding and decoding algorithms are not de-scribed explicitly for this simpler encoding, because the parts that encode and decode thedegree and deletion attributes of the constraints can be omitted in this case.

The verification of type graphs is uncomplicated: if there are only constraint definitionswith arity two or three and the correct types as described in the previous section, the en-coding represents a valid type graph.

67

4 Realization

1: Input: TypeGraph model, HostGraph model, CHR model2: separate constraints of CHR model in node and edge constraints3: if there exist invalid constraints then4: model is invalid5: end if6: for all edge constraints do7: search node constraints with the same identifier as source and target identifier, called source

and target constraints8: if node constraints could not be found then9: model is invalid

10: end if11: compare names of source and target constraints and the name of the edge constraints to the

identifiers of edge and its source and target node in the type graph12: if constraint names and node identifiers are unequal then13: model is invalid14: end if15: end for16: for all node constraints do17: if identifier of node constraint is duplicate then18: model is invalid19: end if20: count number of edge constraints with the same source or target identifier as the node identifier

21: if degree attribute of node constraint is unequal counted number then22: model is invalid23: end if24: end for

Figure 4.29: Pseudo code for verifying a CHR model encoding a host graph.

The verification of a host graph is a bit more complex. An algorithm for verification isgiven in figure 4.29. For every constraint, one has to check if the constraint name is definedin the constraint definitions and determine if it represents an edge or a node of the GTS.These constraints are called edge constraints and node constraints, respectively. Then, forall edge constraints’ target and source terms, a node constraint containing the syntacticallysame identifier term must be searched. The encoding has dangling edges if an accordingnode constraint cannot be found. If the node constraints are found, their names have to becompared to the identifiers of the source and target type node of the corresponding typeedge in the type graph model of the GTS. The type graph model must be used for this,because the encoding of a type graph in CHR does not provide the information to whichtype nodes the type edges are connected. If constraint names do not match the identifiersof the type nodes, the typing morphism is invalid. The node constraints’ second attribute isthe degree of this node. Because of that, for every node constraint the edge constraints mustbe counted that contain the same source or target attribute as the node constraint’s identifierattribute. If the calculated number is not equal to the number found in the node constraint,the model is invalid. Furthermore, if two node constraints have the same identifier attributethe model is invalid, too, because a node identifier would have been used twice, which isnot allowed.

The procedure for rules is more complex and pseudocode can be found in figure 4.30. Themain problem is that the left and right side of a CHR rule partially encode the same graphof a rule. As a consequence, constraints from the head and the body of the rule have to becompared. In a first step, the constraints have to be separated whether they are only on theleft, only on the right, or on both sides. Six sets are defined, one for every graph of a GTSrule (R′,K, and L′) for node and edge constraints. At first, all constraints from the head ofthe CHR rule are separated into the L′-sets (here is also checked if node constraints with

68


1: Input: type graph model, rule graph model, CHR model2: separate constraints of CHR rule in node and edge constraints of the graphs R′, L′ and K.3: if there exist invalid constraints then4: model is invalid5: end if6: for all edge constraints do7: search node constraints with the same identifier as source and target identifier8: if node constraints could not be found then9: model is invalid

10: end if11: compare names of source and target constraints and the name of the edge constraint to the

identifiers of the nodes and edges in the type graph12: if constraint names and type node identifiers are unequal then13: model is invalid14: end if15: if the edge constraint’s source and target constraint are not in the correct list, according to

table 4.1 then16: model is invalid17: end if18: if edge is in K and deletion term is ground then19: model is invalid20: else if edge is in R′ or L′ and the deletion term is not ground then21: model is invalid22: end if23: end for24: for all node constraints do25: if identifier of node constraint is duplicate then26: model is invalid27: end if28: if node constraint is in L′ (or R′) then29: count number of edge constraints in L′ (or R′) with the same source or target identifier as

the node identifier30: if degree attribute of node constraint is unequal counted number then31: model is invalid32: end if33: else if node constraint is in K then34: count number of edge constraints in L′ and R′ with the same source or target identifier as

the node identifier and calculate their difference.35: calculate the difference of the degree expressions from the head and body constraint36: if the differences are unequal then37: model is invalid38: end if39: end if40: end for

Figure 4.30: Pseudo code for verifying a CHR model encoding a rule graph.

69

4 Realization

the same identifier have already been saved before). Then all constraints from the bodyare processed: For every constraint, the L′-list it is checked whether it already contains thesame constraint. Same in this sense means, for node constraints, that the identifier termand the constraint name must be identical. Furthermore, two node constraints must sharethe same variable in the degree attribute (although the expression can be different on bothsides). For edge constraints, the node and target terms must be the same, as well as the namefor the deletion variable. If the same constraint is found in the L′-list, it is removed fromthere and added to the corresponding K list. If it is not available in the L′ list, it is addedto the R′-list. When the constraints are separated, the validity of the edges is checked. Forthat, the types of target and source nodes of the corresponding type edge (the type graphmodel is used here, because the CHR encoding does not provide the typing information)are compared to the names of the source and target node constraints. Additionally, it mustbe verified that the edges are in the correct list according to their source and target nodeconstraints (see table 4.1 for the allowed combination of edges and nodes). The deletionattributes of the edge constraints have to be checked, as well. For edges in L′ and R′, thedeletion attribute must be ground, i.e. it is a lower case identifier or a number. For edges inK, the deletion attribute must be a variable (i.e. it starts with a capital letter). This variablemust be the same for the two constraints in the head and body of the rule. For the nodeconstraints, the degree variable has to be verified. For node constraints in L′ and R′, thedegree attribute must be an integer representing the number of edge constraints associatedto it (just as for host graphs). The degree attribute for node constraints in K must be verifiedin the following way: counting the number of edge constraints in the L′ list and the numberof edge constraints in the R′ list that contain the same source or target attribute as the nodeconstraint, calculating the difference, and comparing it to the difference of the expressionsin the head and body constraints of the node constraint. If the differences are unequal thenthe encoding is invalid.

Although the algorithms are similar in some parts, they still differ too much to reuse thealgorithm for host graphs in the algorithm for rule graphs. For example, the test whetherthe degree attribute is correct for host graphs cannot be used for rule graphs, because rulegraphs can also contain variables as degree attributes.

If the encoding of a rule or host graph is valid, it has to be compared to the graph model ofthe GTS. Changes that result from the CHR encoding must be applied to the graph model.This algorithm is a little bit different for host and rule graphs, but both use the data gener-ated by the previous algorithm, i.e. the separation of the constraints. As already mentionedabove, encoded type graphs cannot be decoded to a GTS, because they miss the informa-tion how the edges are connected to the nodes. That is why type graphs cannot be editedvia CHR. Because of that, there is no need for an update of the GTS model. The update ofa host graph model works as follows: for each edge constraint, try to find a correspondingedge in the graph model. Sort the edge constraints into two groups: The group of edgeconstraints that cannot be found in the model and the group of edge constraints that arealready available in the graph. The edges in the model that could not be associated to aconstraint are marked for removal. The same is done for node constraints. At first, alledges and nodes that are marked for removal are removed from the graph model. Then, foreach constraint that is in the set of node (edge) constraints and has no representation in themodel, a new node (edge) is added to the model.

The algorithm for updating a rule graph is similar, except that it has to check if the nodesand edges have been moved between the graphs they belong to (L′,R′, or K). In the caseof a move, commands to modify the corresponding edge or node must be created. In thisalgorithm edges and nodes are first removed, then nodes and edges are modified, and atlast, new nodes and edges are added. It is important that elements are first removed, thenmodified, and then added, because otherwise invalid model states can occur.

70


4.4.1.3 Editor

In this section, I want to describe the design of the text editor itself. The editor must givethe possibility to display a given type, host, or rule graph (encoded in CHR) and to allowediting of these graphs. The algorithms in the previous section provide this functionality,they only need a representation of the CHR source as a model that contains rules and goalsconsisting of constraints. For generating a model from text, a parser is needed which readsout the source, checks it for syntactical correctness, and generates a model from it. Aframework for generating models from a textual representation is TEF ([35]). For TEF, agrammar must be created which describes the syntax of the text and associates elements ofthe model to parts of the input text. TEF can then parse the text and return an EMF modelof the textual representation. Furthermore, TEF can create a textual representation from agiven model, what is called pretty printing. In the following, I describe the model used torepresent the CHR rules, goals, and constraints. After that, further features of the editor areexplained.

I do not model all the aspects of CHR, because a full featured CHR editor is not desired.Only the aspects that are needed for representing constraint definitions, rules, and goals forthe encoding of a GTS are regarded. The model is shown in the UML class diagram infigure 4.31. Constraint definitions consist of a name and a list of types for its terms. Con-straints consist of a reference to a constraint definition and a list for the terms where eachterm can be an expression. For the expressions, only addition and subtraction of numbersand literals is modeled, because multiplication is not needed for encoding GTS. Numbersare arbitrary integers while literals are strings. I do not make a distinction of ground andvariable terms in the model, because these properties are checked by the algorithms. Inputsare a list of constraints while rules are modeled as two lists of constraints, one for the headand one for the body of a rule. The corresponding grammar is a context free grammar thatcombines the CHR model with the notation described in the beginning of section 4.4.1.This grammar is further described in the implementation section.

The editor itself must be synchronized with the graphical editor. The model can be usedfor this purpose. The CHR editor observes the model and updates the displayed text whenchanges occur. When the currently displayed graph is changed in the graphical editor, itnotifies the platform about it. The platform then sends this notification to the textual editor.After that, the editor creates a new CHR encoding of the new graph model and displays it.This flow of information is visualized in figure 4.9. A possibility to select another graphin the CHR editor is currently not realized, because the graphical editor can be used forthis. This could be realized in form of a context menu that shows all the available graphs.However, the textual editor would then have to notify the platform about the change of theactive graph, so that the graphical editor can be synchronized accordingly.

The editor must provide information about errors in the CHR source. Syntactical errors areautomatically detected by the parsing functionality of TEF, as well as referencing errorsfrom constraints to constraint definitions. Other encoding errors which are discovered bythe algorithms described above must also be shown as error annotations in the text editor,together with a message that describes the error. The screen-shot in figure 4.32 showshow this annotation mechanism should look like. This example encodes a host graph forthe dining philosophers problem with two philosophers where one is eating and the otheris thinking. The degree attribute of one philosopher contains the wrong number. Thisinformation is also shown in the pop-up.

In section 4.4.1.1, another simpler encoding is introduced, so an action is needed thatswitches between the encodings. Figure 4.33 shows actions of the CHR editor embeddedin the action bar. The second action is for refreshing the encoding from the current graphmodel. This is needed, when too many errors occur while modifying the CHR source andwhen the user wants to start again with the original encoding.

71

4 Realization

Figure 4.31: UML class diagram of the model for the CHR editor.

Figure 4.32: CHR editor error annotation mechanism.

72


Figure 4.33: Actions for refreshing and switching between the encodings in the CHR editor.


In this section, I give implementation details for the CHR model, its corresponding gram-mar, the algorithms for checking validity and updating the model, and the implementationof the editor itself. The editor itself can be found in the projectorg.uniulm.gts.chrtexteditor and the CHR model can be found in the projectorg.uniulm.gts.chrtexteditor.model.

4.4.2.1 Grammar and model

The CHR model is created using the EMF, because TEF supports only EMF models. TheUML class diagram from figure 4.31 can be translated to an ecore model from which sourcecode for the model is produced. See section 4.1.2 for details about EMF and model gener-ation.

The grammar that creates the model from a text is a context free grammar annotated withinformation from the EMF model. Listing 4.8 shows a part of the grammar that creates aCHR model from the syntax described in section 4.4.1.1. The grammar describes the syntaxof the constraints and constraint definitions. Each left side of a rule is a non-terminal. Theycan be followed by an element annotation, that contains a class name from the EMF ecoremodel. This means that this rule describes the content of an instance of the given class.For example, the rule CHR (line 1) is annotated with the class of the same name, therefore,this rule describes a CHR object. The right side may contain annotated non-terminals andterminals. The keywords or non-terminals can be followed by a composite annotation. Theattribute of this annotation is a property of the class which is described by the keyword ornon-terminal. The right side of the rule CHR contains a non-terminal for constraint defini-tions, one for the rule block, and an annotated non-terminal which describes an objects ofthe class Input. For each non-terminal which is annotated with a composite, a rule mustbe provided which describes the content of the annotated property. Non-terminals can alsobe followed by a reference annotation. These annotations have also a property of the de-scribed object as an argument. The rule for such a non non-terminal describes an object

73

4 Realization

1 CHR:element (CHR) −> ( C o n s t r a i n t D e f s ( RuleBlock ) ? ( I n p u t : c o m p o s i t e ( I n p u t s ) ) ? ) ? ;2 RuleBlock −> " r u l e s { " R u l e : c o m p o s i t e ( Rule ) " } " ;3 R u l e : e l e m e n t ( PropRule ) −> ( PropHead ) ? " <=>"4 PropBody " . " ;5 PropHead −> C o n s t r a i n t : c o m p o s i t e ( head )6 ( " , " C o n s t r a i n t : c o m p o s i t e ( head ) ) ∗ ;7 PropBody −> C o n s t r a i n t : c o m p o s i t e ( body )8 ( " , " C o n s t r a i n t : c o m p o s i t e ( body ) ) ∗ ;9 PropBody −> " t r u e " ;

10 C o n s t r a i n t D e f s −> ( " p u b l i c " ) ? " C o n s t r a i n t "11 C o n s t r a i n t D e f : c o m p o s i t e ( c o n s t r a i n t D e f )12 ( " , " C o n s t r a i n t D e f : c o m p o s i t e ( c o n s t r a i n t D e f ) )∗ " ; " ;13 I n p u t : e l e m e n t ( I n p u t ) −> " :−" C o n s t r a i n t s " . "14 C o n s t r a i n t s −> C o n s t r a i n t : c o m p o s i t e ( c o n s t r a i n t s )15 ( " , " C o n s t r a i n t : c o m p o s i t e ( c o n s t r a i n t s ) ) ∗ ;16 C o n s t r a i n t D e f : e l e m e n t ( C o n s t r a i n t D e f ) −>17 IDENTIFIER:composi te ( name ) ( " ( "18 IDENTIFIER:composi te ( v a r i a b l e T y p e s )19 ( " , " IDENTIFIER:composi te ( v a r i a b l e T y p e s ) )∗20 " ) " ) ? ;21 C o n s t r a i n t : e l e m e n t ( C o n s t r a i n t ) −>22 C o n s t r a i n t D e f R e f : r e f e r e n c e ( t y p e ) ( " ( "23 E x p r e s s i o n : c o m p o s i t e ( v a r i a b l e s )24 ( " , " E x p r e s s i o n : c o m p o s i t e ( v a r i a b l e s ) )∗25 " ) " ) ? ;26 C o n s t r a i n t D e f R e f : e l e m e n t ( C o n s t r a i n t D e f ) −>27 IDENTIFIER:composi te ( name ) ;

Listing 4.8: Main part of the grammar for the CHR model and the constraints.

of the corresponding class, but only enough information has to be provided in the text toidentify one of the objects that has already been created of the same type. This object isthen referenced. For example, the rule Constraint (line 21) contains the non-terminalConstraintDefRef (line 22) which has a reference annotation. The rule for this non-terminal describes an instance of the class ConstraintDef (compare line 16 ff.), butonly the name property of the constraint definition is parsed. This object is then comparedto the other ConstraintDef instances in order to find an object that contains the samename property. Terminals are either strings enclosed by quotes or one of several keywordswritten completely in capital letters (e.g. INTEGER or IDENTIFIER) which represent astring or number in the parsed string (lines 17–19). If one of the keywords is followed by acomposite annotation, the described property is in general a string or an integer. This prop-erty is then set to the value found in the input string. The rule ConstraintDef (line 16)has on its right side the keyword IDENTIFIER followed by a composite annotation (line17). For that reason, the next character sequence (consisting of alphanumeric symbols) inthe input string is used as value for the property name (which is of the type string).

The grammar in listing 4.8 shows the structure of the encoding for type, host, and rulegraphs. The type graph is always printed while the rule or the input can also be omit-ted (line 1). The rules for the syntax of the input and the CHR rules correspond to thenotation described in section 4.4.1.1. The grammar shows the syntax of the constraintsand constraint definitions, as well. Constraints can contain expressions as its terms. Thegrammar for terms is not further described here. The complete grammar can be foundin appendix C.6. The grammar in the appendix also contains white space tags, that areonly used for pretty printing, but they are left away here to improve the readability of thegrammar.

4.4.2.2 Encoding/decoding algorithms

This section describes the implementation of the algorithms for encoding a graph of a GTSto the CHR model and for the validation of a CHR model. The implementation of thealgorithm to update the graph that corresponds to a valid CHR model is described, too.

74


The implementation for the model transformation from the GTS to the CHR model worksas follows: The algorithm takes each node and edge from the graph and creates aConstraint object (for typed graphs) or a ConstraintDef object (for the type graph)for it. The attribute lists of the ConstraintDef instances are filled with the accordingnames for the types where the name attribute is the identifier of the node or edge. Thetype attribute of a Constraint instance references the according ConstraintDefinstance. Its attribute list is filled with the values described in section 2.3. Values that rep-resent identifiers, i.e. the first argument for nodes and the second and third argument foredges, are ground terms or variables. The second term of a node constraint is a Numeralinstance containing a number (for host encoded graphs) or a Binary instance (Minus orPlus) which describes an expressions consisting of a Literal and a Numeral. Thesemodel transformation algorithms are provided by the method getCHRModel(...) inthe class GTSTextEditor. This method has the corresponding graph model as attribute.It is overloaded for type, host, and rule graphs.

The implementation of the algorithms for checking the validity of CHR models and updat-ing the corresponding graph model are tied together for technical reasons, because much ofthe information for the model update can be gathered during the validity check. If there areerrors in the CHR encoding, the graph is not updated, but error annotations are displayed inthe editor. The key part of the algorithm is to transform both, the GTS model and the CHRmodel, to a similar form in order to compare them. Consequently, the nodes of the graphand the node constraints of the CHR model are saved in java maps to compare them by theirnode identifier. For edges, a MultiHashMap that allows multiple keys has been created,because an edge is identified by its source node identifier, its target node identifier, and itstype edge’s identifier. Both, the GTS model and the generated CHR model, are saved inthese maps. They are called CHR maps and GTS maps, respectively. These maps are thelists needed by the algorithms described in figures 4.29 and 4.30. Maps were used, becausethey allow a faster access to their elements when the identifier is known. The validity algo-rithm is then applied to the CHR maps. If the model is valid, then GEF commands (see table4.2) are created to update the corresponding graph model. The commands can be createdby comparing the GTS and CHR maps. In case of a rule graph, multiple maps are needed torepresent the three graphs L′, R′, and K of a GTS rule. The algorithms to verify and updaterules can be found in the method updateRuleModel(). The algorithm to verify andupdate host graphs can be found in the method updateHostmodel(). Both methodsreceive the created CHR model as input and are located in the class GTSTextEditor.

The simpler encoding of constraints described in section 4.4.1.1 can also be encoded anddecoded with the given algorithm. The execution of the algorithms is controlled by aboolean variable which skips the parts of the algorithms that are not needed by the sim-pler encoding when set to true. When separating the constraints in the validation algo-rithm, this boolean variable is also queried, because the sorting depends on the terms of theconstraints. The full source code of the method updateRuleModel() can be found inappendix C.5.

4.4.2.3 Editor

The implementation of the CHR editor itself is bundled in the class GTSTextEditorwhich is extended from the TextEditor base class provided by TEF. To synchronizethe editor with the model, the editor registers itself as listener to all elements of the cur-rently displayed graph. This is done as soon as the currently displayed graph model isset by the platform. When the notifyChanged() method is called by the model, themethod printNewCHRModel() is called which transforms the currently active graphmodel to a CHR model (see section 4.4.2.2) and uses the pretty printing function of TEFto display the new encoding. The Editor registers itself as a listener to the TEF parsing

75

4 Realization

mechanism. When a new model is parsed from the contents of the editor, the methoderrorStatusChanged() is called. From this method, the algorithms for validatingthe model are called (section 4.4.2.2). These algorithms also perform the update of thecurrently encoded graph model. However, if the model is invalid, error annotations aredisplayed in the text editor. Error annotations contain a message that describes the error.These annotations are then added to the AnnotationManager of the text editor togetherwith the position of the text part that is responsible for the error. For finding out the positionof the faulty constraints in the text, TEF saves the parsing tree of the last model creation.This tree can be queried with model objects to receive the text parts corresponding to it.From these text parts, the position in the editor can be determined.

Another important point is, that when updating the graph model from the CHR model,notifications from the graph model must be ignored. Otherwise the text would be updatedcontinuously while typing, resulting in a rearrangement of the constraints. Furthermore, thevalidation and update algorithms must be deactivated when the model has just been prettyprinted. The problem that would otherwise occur is, when removing multiple elementsin the graphical editor at once, the model gets pretty printed multiple times in the textualeditor. After each pretty printing, the model is parsed asynchronously in the background,resulting in a new CHR model. As the parsing runs asynchronously, the generated modelmight encode an older version of the graph model. Therefore, the validity and updatealgorithms would produce further commands to change the model which is wrong in thiscase.

The actions are added to the action bar of the platform as described in section 4.2.2.5. TheRefreshCHRAction just calls the method refreshCHR() of the editor it is associatedwith. This method resets the current graph model in the editor to force a refresh of theencoding. The class SwitchCHRModeAction is the action for switching between theencodings. It calls the method switchCHRMode() of the editor. This method switchesthe value of the boolean variable that controls the execution of the encoding and decodingalgorithms described in section 4.4.2.2.


In this section, I describe how to use the textual editor to edit a rule, show how the validitycheck works, and how the graph model is updated. Figure 4.34 shows the rule thinkToWait,created in section 4.3.3, but with the green wait edge missing on the philosopher. Theencoding is displayed in the more complex version with deletion and degree attributes.To add the wait edge, a wait(del,P,P) constraint must be added to the body of thedisplayed rule. This constraint symbolizes a loop on the philosopher node, identified byP. As the constraint is only in the body of the CHR rule, it is automatically in the graphR′ of the GTS rule. Figure 4.35 shows that the encoding is invalid by highlighting thephilosopher constraint in the body of the rule. This is because the validation algorithmfound an error when it checked the degree attribute of the philosopher constraint. In thisexample, the term has the value NC_0-2. That means the degree is smaller by two afterthe rule application. However, because a new edge is added, the degree is unmodified. Forthat reason, the subtraction of 2 must be removed in the degree attribute of the philosopherconstraint. Figure 4.36 shows the final rule with the green wait edge added.

76


Figure 4.34: thinkToWait rule displayed by both editors. The green wait edge is still miss-ing.

Figure 4.35: Invalid encoding, the degree attribute of the philosopher constraint must beupdated, because of the added wait constraint.

77

4 Realization

Figure 4.36: Final rule with the correct encoding.

4.5 How to create a tool: The termination analysistool

In this section, I describe explicitly the steps that are needed to create a GTS analysistool. The creation is shown with the help of an example tool that checks whether a GTSterminates. A GTS terminates when a graph is reached during rule applications to which norules can be applied anymore. Of course, termination is an undecidable problem, becauseof that, the method can only prove termination, but not non-termination. First, I describethe theoretical background of this analysis and how the graphical user interface for this toolcan be designed. Then, I describe in detail how to implement this tool.

4.5.1 Design

The analysis method used here is based on a ranking function. Section 4.5.1.1 provides anexplanation of ranking functions. The GUI for entering the ranking function and displayingthe rules that might not lead to a terminating GTS is described in section 4.5.1.2

4.5.1.1 Ranking functions

Termination of CHR programs can be analyzed with a ranking function ([20]). A rankingfunction fR : Constraints 7→ R+ maps the set of constraints to the set of positive realnumbers, i.e. each constraint is assigned a value called its rank. These functions can bedefined for each type of constraint, e.g. it can be a constant or it may depend on thelength of a list in the constraint. The ranking function can be applied to a conjunction ofconstraints fR(

∧c∈Constraints c) =

∑c∈Constraints fR(c), then the value is the sum of

the ranks of the constraints. By choosing a good ranking function and calculating the rankof the rule’s head and body, one can state if a rule leads to a terminating system. If therank of the head is higher than the rank of the body and this is valid for all rules, the CHRprogram terminates, because the rank of the constraint store strictly decreases and reaches

78

4.5 How to create a tool: The termination analysis tool

Figure 4.37: Termination analysis of the dining philosophers problem, the ranking functionis collapsed.

a minimal value when no rule is applicable anymore. However, if for only one rule the rankof the head is less than or equal to the rank of the body, no statement can be raised whetherthe program is terminating or not.

The encoding of the examples for finding circular lists shown in section 2.3 can be an-alyzed with a ranking function fR(c) = 1 for every constraint c. This function can beused, because edge constraints are never modified, but only removed. The same statementholds for node constraints, although they contain the number of connected edges which ismodified by rules. This number depends on the number of edge constraints. Therefore,the rank of a node constraint can be set to one. The encoding for the circular list exampleis terminating, because each rule removes more node or edge constraints than it adds. Forthe dining philosophers problem’s encoding, no reasonable ranking function can be found,because it is obviously not a terminating system.

This method can be adapted to rule graphs of a GTS: A ranking function is assigned to thenodes and edges. Therefore, the ranking of a graph is the sum of the ranks of its nodes andedges. The ranks of the R and L graph of a GTS rule p = (L l← K

r→ R) are calculated.If the L graph has a higher rank than the R graph and this holds for all rules, then the GTSis terminating.

As seen above, encoded GTS rules can be ranked by a function fR(c) = ac, where ac

is a constant value for each constraint of type c. Applied to a GTS, a constant value isassociated with each type node and each type edge. As a consequence, the rule nodes andrule edges are ranked by their type.


The GUI must show a table to enter the values ac for each type node and edge. Besides that,a list must be displayed that shows the rules that might lead to a non-terminating system.Figure 4.37 shows the analysis of the dining philosophers GTS. In this example, the ranksfor each type node and edge is set to one (the table to enter these values is collapsed in thefigure). The entered values can be arbitrary in this case, because there exists no rankingfunction that can prove termination of this system, because it is non-terminating. The exam-ple shows that the rules thinkToWait and eatToWait might lead to a non-terminating system.When rules are selected from the list of the non-terminating rules, they are displayed in theeditors. Figure 4.38 shows the termination analysis of the circular list example. This sys-

79

4 Realization

Figure 4.38: Termination analysis of the circular list detection GTS.

1 2 < e x t e n s i o n . . . >3 < g t s a n a l y s i s t o o l4 c l a s s =" org . uniu lm . g t s . a n a l y s i s t o o l s . t e r m i n a t i o n . T e r m i n a t i o n A n a l y s i s T o o l "5 name=" T e r m i n a t i o n a n a l y s i s ">6 < / g t s a n a l y s i s t o o l >7 < / e x t e n s i o n >8 . . .9 

Listing 4.9: snippet of the plugin.xml file for the termination analysis tool.

tem terminates according to the ranking function. As a result, no rules are displayed inthe list of rules, but a message is shown that all rules have strictly decreasing rank. Whenselecting the node or edge identifiers in the table, the type graph must be displayed in theeditor with the according node or edge highlighted.


In this section, I demonstrate in detail how an analysis tool is created in general by using thetermination analysis tool as an example. Creating a new analysis tool is usually started bycreating a new eclipse plug-in project. The name of this project isorg.uniulm.gts.analysistools.termination. The first thing is to add anextension declaration to the plugin.xml file in the project. Listing 4.9 shows the contentof this file for this tool. An analysis tool extension is defined by a gtsanalysistooltag that contains the attributes name, which is the human-readable name of the tool, andclass, which gives the location of the class that implements the interfaceIGTSAnalysisTool. This class is loaded when the tool is started. Now, the classTerminationAnalysisTool has to be created. First, I describe the methods thatmust be implemented for the IGTSAnalysisTool interface. The methods for addingand removing listeners are implemented in a standard way by using a list that saves the lis-tener objects. Furthermore, the methods shown in listing 4.10 are implemented to simplify

80

4.5 How to create a tool: The termination analysis tool

1 p u b l i c v o id s e l e c t e d T r a n s f o r m a t i o n ( S t r i n g graph ) {2 f o r ( I G r a p h T r a n s f o r m a t i o n g t : t h i s .m. g e t T r a n s f o r m a t i o n s ( ) )3 i f ( g t . g e t I d ( ) . e q u a l s ( g raph ) ) {4 n o t i f y A l l ( g t ) ;5 b r e a k ;6 }7 }8 p u b l i c v o id s e l e c t e d E d g e ( S t r i n g edge ) {9 GTSElement e l =new GTSElement ( GTSElement .EDGE) ;

10 f o r ( I A b s t r a c t E d g e e:m . ge tTypeGraph ( ) . g e t E d g e s ( ) ) {11 i f ( ( ( ITypeEdge ) e ) . ge t ID ( ) . e q u a l s ( edge ) ) {12 e l . s e t E d g e ( e ) ;13 n o t i f y A l l ( e l ) ;14 b r e a k ;15 }16 }17 }18 p u b l i c v o id s e l e c t e d N o d e ( S t r i n g node ) {19 GTSElement e l =new GTSElement ( GTSElement .NODE) ;20 f o r ( I A b s t r a c t N o d e e:m . ge tTypeGraph ( ) . ge tNodes ( ) ) {21 i f ( ( ( ITypeNode ) e ) . ge t ID ( ) . e q u a l s ( node ) ) {22 e l . se tNode ( e ) ;23 n o t i f y A l l ( e l ) ;24 b r e a k ;25 }26 }27 }

Listing 4.10: Helper methods for notifying listeners.

1 p u b l i c v o id r u n A n a l y s i s ( ) {2 I V i e w P a r t v i ew e r = g e t P a g e ( )3 . g e t A c t i v e P a g e ( )4 . showView ( " org . uniu lm . g t s . a n a l y s i s t o o l s . t e r m i n a t i o n . Termina t ionView " ) ;5 i f ( v i e w e r i n s t a n c e o f Termina t ionView ) {6 c o n t e n t = ( ( Termina t ionView ) v i e w er ) . g e t C o n t e n t ( ) ;7 c o n t e n t . s e t T o o l ( t h i s ) ;8 }9 }

Listing 4.11: Implementation of the runAnalysis() method.

the communication with the listeners. These methods receive the identifier of the node,edge, or rule graph that should be displayed by the editors, search the according objectin the model, and call a notifyAll() method. The notifyAll() method iteratesover the listeners and notifies them. The methods for setting and getting the currently dis-played graph, nodes, or edges are not implemented, because this tool has no use for thesemethods. The methods for setting the file and the command-stack also have no implemen-tation, because they are not needed. The method setModel() saves the given model toa variable and registers itself to it as a listener (the EMF Adapter interface has to be im-plemented for this). If a model has been set before, the tool removes itself as listener fromthe old model. The method runAnalysis() is implemented as shown in listing 4.11.The method opens a view, receives its content, and adds itself to the content by usingthe setTool() method. The content is an instance of TerminationViewContent,which is a class that contains all the GUI elements and provides methods to set rankingfunction entries and the list of rules that might lead to a non terminating system. This classis not described in detail here. The important point is that this GUI class calls the methodsof the tool, shown in listing 4.10, when new elements in its lists are selected. Becauseof that, the type edge, type node, or rule graph is displayed in the editor. The methodupdatedWeights() is called by the content object when the user edits the table of theranking function values. When the updatedWeights() method is called by the contentobject or the notifyChanged()method is called upon a model change, the calculationsaccording to section 4.5.1.1 are computed and the content object is updated accordingly.Additionally, when notifyChanged() is called, the entries of the ranking function ta-

81

4 Realization

ble are updated, because a type node or type edge could have been added, which changesthe ranking function.

To conclude, the main points in creating an analysis tool are:

• Create a new eclipse plug-in project

• Implement the listener methods of the IGTSAnalysis analysis tool in order todisplay nodes, edges, and graphs in the editors.

• Add the tool itself as a listener to the parts of the model that are analyzed to dynam-ically update the analysis.

• The setModel(), setFile(), and setCommandStack() methods shouldonly save values, and not start the analysis itself. This should be done when therunAnalysis() method is called.

• When a GUI is involved, start it in the runAnalysis() method.

4.6 The CHR based analysis tool

One of the main goals (section 3.2) is to develop a platform for the CHR-based analysisof GTS. Therefore, a tool has to be created that allows the simple embedding of analysismethods for CHR. This tool is an intermediate tool which itself defines an extension pointthat offers the possibility to integrate available CHR analysis methods. This tool is calledCHR-based analysis tool or CHR-based tool in the remainder. The tools that are used bythe CHR-based tool are called CHR analysis tools or CHR tools if the context is clear. Onesuch CHR tool is given in the form of a compiler for the CHR source in order to create anexecutable environment. The description of this tool is a tutorial for embedding other CHRanalysis methods and can be found in section 4.6.2.

No tools for analyzing JCHR programs have been available at the time of implementation.For that reason, no further CHR tools are provided. Implementing analysis methods forJCHR would have exceed the scope of this thesis.

4.6.1 Design

This analysis tool basically gives the possibility to launch tools for analyzing CHR pro-grams. Therefore, a simple GUI must be created, as well as another extension point specif-ically designed for CHR analysis tools. To create CHR source code files from the GTSmodel, a method for code generation is required.

4.6.1.1 CHR analysis tools extension point

The extension point and its interface is designed similarly to the extension point for GTSanalysis tool defined in section 4.2.1.2. The plugin.xml contains the same entries: oneto define a class that should be loaded, one for setting the name of the tool and the identifier.The interface is also designed similar. However, for this interface, no command stack isneeded. Furthermore, there is no model of the GTS but a file containing the correspondingCHR program. JCHR is used as CHR implementation. That is why analysis tools must alsobe based on JCHR. JCHR uses .jchr source files for its programs. For more informationon JCHR, see [43]. One problem with the JCHR source code files is, that goals are notincluded in them. Therefore additional methods have to be provided by the interface in

82


CHRTool

CHRTool

CHRBasedTool

CHRBasedTool

Platform

Platform

constraintactivation notification

convert constraintsand rules to nodes,

edges and rule graphs

node/edge/ruleactivation notification

Forward notificationto editors

void

void

Figure 4.39: UML sequence diagram of the communication of CHR tools with the plat-form.

order to add goals that should be analyzed. Just like the interface for the GTS analysistools, this interface has a method for starting the tool itself after setting the file and addingthe goals.

The interface must also contain methods for the listener pattern, so that a bidirectional com-munication is possible between the CHR tools and the CHR-based tool. The bidirectionalcommunication informs the CHR-based tool which rules, goals, or constraints should bedisplayed. Consequently, the CHR-based tool must transform these notifications for CHRrules, goals, or constraints to notifications for rule, host, or type graphs and their nodesand edges, respectively. These new notifications are then sent to the platform. Figure 4.39shows a sequence diagram describing the flow of information between CHR tools and theplatform.


The GUI must display a list to choose which rules should be analyzed and to set their order.There has to be a list to choose the CHR goals, i.e. the encoded host graphs that should beanalyzed. When selecting the elements of these lists, the according graphs are displayed inthe editor. Finally, a drop down menu has to be provided to select the CHR-based analysistool that should be started. The screen-shot in figure 4.40 shows how the GUI should looklike. This screen-shot shows the dining philosophers GTS. On the right, the CHR basedanalysis tool is opened and the host graph with two philosophers is currently selected.Because of that, it is displayed in the editor on the left. Also notice the two text fields onthe top of the tool in which the name of the generated handler and the package used forit can be entered. The contents of these text fields are needed for the code generation asdescribed in section 4.6.1.3. Below the combo box for the selection of the CHR tool is ahyperlink that must be clicked to start the tool that is currently shown in the combo box.

4.6.1.3 Code generation

CHR analysis tools need syntactically correct CHR source code for the analysis, therefore,code generation mechanisms are needed. This generation is done by JET, the java emit-

83

4 Realization

Figure 4.40: The GUI of the CHR based analysis tool together with the editor.

1 package examples . f i b ;2 i m p o r t j a v a . math . B i g I n t e g e r ;3 i m p o r t r u n t i m e . L o g i c a l ;4 i m p o r t u t i l . a r i t h m e t i c s . p r i m i t i v e s . i n t U t i l ;5 p u b l i c h a n d l e r f i b {6 s o l v e r r u n t i m e . E q u a l i t y S o l v e r ;7 p u b l i c c o n s t r a i n t f i b ( i n t N, L o g i c a l M) ;8 r u l e s {9 l o c a l L o g i c a l M1, M2;

10 f i b ( 0 ,M) <=> M = 1 ;11 f i b ( 1 ,M) <=> M = 1 ;12 f i b (N,M) <=>13 f i b ( i n t U t i l . dec (N) , M1) ,14 f i b ( i n t U t i l . sub (N, 2 ) , M2) ,15 M = M1. add (M2) ;16 }17 }18 }

Listing 4.12: JCHR program for calculating the Fibonacci numbers.

ter templates. Details about the code generation are given in the implementation section.The generated code uses the syntax of JCHR. The syntax has some similarities to the javasyntax. Listing 4.12 shows a JCHR program for the calculation of the Fibonacci numbers.At the beginning of a JCHR file, the package name, as well as imports are listed, whichdescribe the packages that are needed. JCHR needs special methods for doing basic nu-merical operations. Therefore, the import of the intUtil class is listed in the exampleabove. The main part of the program is enclosed by a handler statement (lines 5 ff.) thatis similar to a class statement in java. The java class that is generated from this examplewill have the name FibHandler. In the handler, the constraints are defined by givingthe keywords(s) (public/private) constraint, followed by the names of the con-straints together with the types of their attributes. Furthermore, a solver is defined (line6). Solvers are used to solve built-in constraints, i.e. they provide the functionality of aConstraint Theory (section 2.1). In this example, a solver for the BigInteger class iscreated. The next part is enclosed by a rules{...} block (lines 8–16) in which all rulesare listed. The rules have a syntax similar to that described in section 2.1. However, vari-ables that are only in the body of a rule but not in the head must be declared first by givingthe local keyword, followed by the type and the name of the variable. In this example,two variables of the type Logical<BigInteger> are defined (line 9). Logical is a

84


special JCHR type that defines an arbitrary term of the given type (BigInteger in thiscase) which can be compared and set equal to other terms without having a value.

As a result, the code generator must query the rules of the GTS and encode their nodesan edges as constraints of a rule, which is described in section 2.3. In addition to that, allvariables that are in the body, but not in the head of a rule, must be declared at the beginningby using a local statement. Variables are introduced when new nodes are added in a GTSrule, because each added node contains a new unique identifier. The names for the packageand the handler must be provided for code generation. These values are queried in the GUI(see figure 4.40).

4.6.1.4 Compiler tool

One vital part of several analysis methods for CHR is that an executable environment mustbe present to test generated inputs (e.g. confluence analysis ([20])). Therefore, I providea CHR tool that calls the K.U. Leuven JCHR compiler that compiles the JCHR source tojava source which is then compiled to java byte-code by the eclipse platform. This CHRanalysis tool has no graphical user interface. Only when an error occurs, an error dialog isshown that informs the user about the error.


First, I describe the implementation of the extension point for CHR analysis tools, then theintermediate analysis tool and the code generation using JET. At the end, I describe theimplementation of a CHR analysis tool in detail. I use the example of embedding the K.U.Leuven compiler for this purpose. The extension point definition can be found in the projectorg.uniulm.gts.chranalysistool, the CHR based tool inorg.uniulm.gts.analysistools.chrbasedanalysis, the compiler CHR toolin org.uniulm.gts.chranalysistools.chrcompiler, and the JET templatefor generating the source code is located in the projectorg.uniulm.gts.chrexporter.plainchrexporter.

4.6.2.1 Extension point

The extension point definition is similar to the one from the GTS analysis tool. It ba-sically consists of two interfaces, ICHRAnalyzer and ICHRListener, as well as aclass ConstraintNotification. The interface ICHRAnalyzer contains meth-ods for setting the file with the JCHR source (setFile(IFile)) and adding goalsto the CHR analysis tool (addInput(List<ConstraintNotification>)). Agoal is represented as a list of ConstraintNotification instances. This class con-sists of the constraint’s name and a list of strings representing the attributes of the con-straint. Furthermore, methods for adding and removing listeners are provided. The methodrunChrAnalysis() starts the according tool. The ICHRListener interface con-tains methods to notify the listener about activated rules, constraints and constraint defi-nitions. The methods contain either the rule name as string or a list of instances of theConstraintNotification class as its attribute.

4.6.2.2 Tool

The tool itself is realized by two classes, one providing the graphical front-end with meth-ods to set and receive information and the other one providing the functionality of the tool.

85

4 Realization

1 p u b l i c c o n s t r a i n t2 < c : i t e r a t e s e l e c t =" $ g t s / typeGraph / nodes " v a r =" t y p e n o d e " d e l i m i t e r =" , ">3 n_< c : g e t s e l e c t =" t r a n s l a t e ($ t y p e n o d e / @iD, ’ ’ , ’ _ ’ ) " / > ( L o g i c a l I n t , i n t )4 < / c : i t e r a t e >5 < c : i f t e s t =" c o u n t ($ g t s / typeGraph / nodes ) >0 "> , < / c : i f >6 < c : i t e r a t e s e l e c t =" $ g t s / typeGraph / edges " v a r =" t y p e e d g e " d e l i m i t e r =" , ">7 e_< c : g e t s e l e c t =" t r a n s l a t e ($ t y p e e d g e / @iD, ’ ’ , ’ _ ’ ) " / > (8 i n t , L o g i c a l I n t , L o g i c a l I n t )9 < / c : i t e r a t e > ;

Listing 4.13: Snippet of a template for creating the constraint definitions from a type graphmodel.

The tool implements the interface for GTS analysis tools and the listener interface for CHRanalysis tools. First, I describe the interface for the GTS analysis tool. The setModel()method saves the given model as its current model and adds itself as listener to it, so thatthe GUI can be updated when graphs are removed or added. The setFile() method isused to set the name of the JCHR handler in the GUI (because of that, the default name forthe generated file is identical to the file name from which the model was loaded). WhenrunAnalysis() is called, a view is opened. The contents of this view are initializedby filling the lists of rule and host graphs with the corresponding identifiers and register-ing the tool itself as selection listeners to these lists. Furthermore, all CHR analysis toolsextensions are searched, their names are saved in a combo box in the GUI, and a selectionlistener is added to a hyperlink that is used to start the currently selected tool. The selectionlisteners for the lists check the currently selected element of the according list, search thegraph with the same identifier, and notify the listeners of this tool (i.e. the platform) thatthis graph is currently selected. The listener for the hyperlink checks which tool is selected,generates the source (which is described later), and calls the setFile() method of theaccording tool followed by several calls of the addGoal() method for every activatedhost graph in the list of host graphs. When all goals are added, runChrAnalysis() iscalled which starts the functionality of the CHR analysis tool.


The creation of the JCHR source is done with JET. A JET code generator is describedby a template file that contains the static parts of the target document together with XMLtags that describe the dynamic content. Listing 4.13 shows a snippet from the templateto create CHR source from a GTS model. The snippet shows how to generate the list ofconstraint definitions at the beginning of the handler. It contains the <c:iterate ...>tag (lines 2–4) which iterates over a number of objects defined by its select attribute.The objects are selected by using XPath. XPath is a query language designed to select partsof XML documents, but can also be used to query EMF models. For more informationabout XPath, see [4]. Basically, the XPath expression provides a path to reach the desiredobjects in the model. In the first iterate tag stated above, all nodes in the type graph modelare selected by giving the path $gts/typeGraph/nodes, which means that gts isthe root of the model from where the typeGraph attribute is selected. In there, all thenode attributes are chosen (also compare to the definition of the GTS model described insection 4.2). The iterate tag iterates over all nodes. These nodes are represented by the vari-able $typenode. The delimiter attribute of the tag defines the string that separatesthe elements of the iteration from each other. Values can be printed from the model withthe <c:get select=.../> tag. This tag also uses XPath to select a value from themodel. $typenode/@iD, for example, selects the iD attribute of the object typenode.Objects in the model that represent final values, i.e. strings, numbers, and boolean values,are addressed in XPath with an @ sign. The function translate is an XPath function

86


1 p r o p s =new HashMap< S t r i n g , O b j e c t > ( ) ;2 p r o p s . p u t ( " o rg . e c l i p s e . j e t . r e s o u r c e . p r o j e c t . name " , f i l e . g e t P r o j e c t ( ) . g e t F u l l P a t h ( ) .

t o O S S t r i n g ( ) ) ;3 p r o p s . p u t ( " j c h r p a c k a g e " , pkg ) ;4 p r o p s . p u t ( " j c h r h a n d l e r " , hnd l ) ;5 p r o p s . p u t ( " o r d e r " , c o n t e n t . g e t O r d e r ( ) ) ;6 I S t a t u s r e s = JET2Pla t fo rm . runTrans fo rmOnObjec t (7 " org . uniu lm . g t s . c h r e x p o r t e r . p l a i n c h r e x p o r t e r " ,8 model ,9 props ,

10 new N u l l P r o g r e s s M o n i t o r ( ) ) ;

Listing 4.14: Code snippet for starting a JET transformation with additional values from ajava program.

and replaces blanks by underscores in the first attribute. Another tag that is used here, isthe <c:if test=...> tag (line 5) which can be used to conditionally print values tothe target document. The test attribute contains a conditional in which comparison op-erators (<,>,=,<=,>=) can be used together with XPath expressions. The conditionalcount($gts/typeGraph/nodes)>0 uses the XPath function count that returnsthe number of elements in the given XPath expression. There are several XPath expres-sions already available and JET provides the possibility to define new functions by creatingan extension to JET. These functions are implemented as java classes. The example listingfirst prints the node and then the edge constraints, followed by a semi-colon.

The rules are printed by using an iterate tag. However, the iterate tag prints the rules inthe order they appear in the model. Therefore, an XPath function has been designed asa JET extension that receives a list of objects and a list of integers. The list represents apermutation of the elements in the list of objects. This function reorders the list of objectsand returns the new list. The function is called reorder. Certain elements can also be leftaway by removing the according number from the list of integers. At the beginning of therules block in a JCHR file, all variables must be listed that appear in the body but not in thehead of the rules. To realize this, a second XPath function has been created that receivesa list of objects and returns a list of its distinct values, i.e. it removes duplicate entries.This function is called distinct-values. To print all variable names contained in thebodies of rules, all these variables are selected with an XPath expression and handed tothe new defined function. Generating the rules requires to introduce new variable namesfor the deletion and degree attributes of the edge and node constraints. These variablesare named DEL_ or NC_, followed by an increasing number to uniquely identify themwithin a rule. To avoid name clashes between the generated variable names and the variablenames introduced by the model, the names of the identifier variable in node constraints arepreceded by NN_ for variables introduced in the body of a rules or ON_ for variables thatappear in the head of a rule, too.

Furthermore, the template needs the information about the handler and the package name.These values can be given to JET in form of a java map as shown in the code snippet in list-ing 4.14. The snippet shows how a map is filled with values. The variables pkg and hndlcontain the name of the package and the handler. The property order that is put into themap, is the list with integers that represents the permutation of the rules. The GTS model it-self is saved in the variable model and is handed to therunTransformationOnObject() method of the JET platform. This method re-ceives the identifier of the transformation, the EMF model object, the properties, and aninstance of a progress monitor. Each JET transformation is an extension to JET which con-tains the location of the template file. JET also provides tags to create files, folders, andprojects in the eclipse workspace. The complete JET template file can be found in appendixC.4. The source in the appendix is trimmed for readability. That is why the generated codeis not formatted very nice in this form.

87

4 Realization

1 2 < e x t e n s i o n3 p o i n t =" org . uniu lm . g t s . c h r a n a l y s i s t o o l ">4 < c h r a n a l y s i s t o o l5 c l a s s =" org . uniu lm . g t s . c h r a n a l y s i s t o o l s . c h r c o m p i l e r . ChrCompi le r "6 name="KU Leuven JCHR c o m p i l e r ">7 < / c h r a n a l y s i s t o o l >8 < / e x t e n s i o n >9 

Listing 4.15: plugin.xml file for the CHR compiler tool.

4.6.2.4 How to create a CHR tool: Compiler tool

In this section, I show a guide for the creation of a CHR analysis tool by using the exampleof integrating the K.U. Leuven JCHR compiler as a CHR tool. This tool calls the K.U.Leuven JCHR compiler with the generated JCHR file as input and raises an error messagewhen errors occur during execution.

At first, the project org.uniulm.gts.chranalysistools.chrcompiler mustbe created as a plug-in project. In this project, an extension to the CHR analysis toolextension point must be created in the plugin.xml file of the project. Listing 4.15shows the file. The chranalysistool tag defines the name of the tool and the classwhere it is implemented. In a next step, the java class referenced in the extension mustbe created. This class must implement the IChrAnalysisTool interface described insection 4.6.2.1. The interface is not directly implemented by the CHRCompiler class,but it extends the class AbstractCHRAnalysisTool. This class basically implementsthe methods for the listener pattern and provides two methods, notifyRule(...) andnotifyConstraintDef(...), in order to notify the listeners about a rule or a con-straint that should be displayed. The ChrCompiler class must still implement the re-maining methods setFile(...) (file is copied to a variable file), addGoal(...),and startAnalysis(). The method for adding goals can be left unimplemented, be-cause the goals are not needed by the compiler. runChrAnalysis() is the interestingmethod. CHR analysis tools in general start their calculations or display further dialogs,like views or wizards, in this method. In this example, the K.U. Leuven JCHR compiler isstarted. Listing 4.16 shows the source code of the method. This method checks whetherthe source file exists and creates a new Job object for compiling the source code (lines2–5). The tool adds itself as listener to the job and schedules it for execution (lines 17and 18). If the source file does not exist, an error message is displayed. When the jobis finished, it returns a status code to the tool by calling one of the methods from theIJobChangeListener interface (this is not shown in the listing). If an error is re-turned, an error dialog is displayed. For the Job itself, the run() method must be imple-mented. In this method, a Compiler instance is created (line 7). This class also providesa method run() that starts the K.U. Leuven JCHR compiler. The K.U. Leuven JCHRcompiler does not provide a documented method to call it from other java classes. There-fore, the Compiler class creates a new process for launching the K.U. Leuven compiler.The compiler can only be started when the binaries of the java run-time environment arein a folder that is searched by the system. The jar file of the K.U. Leuven JCHR compilermust be in the java class-path, so that it can be found by the run-time environment. Thestandard and error output is returned as a string. These functions are not described anyfurther, because they are only a work-around for a lack of functionality of the JCHR com-piler. The Compiler class returns a status code that signals whether the execution wassuccessful. Additionally, the error output is checked for errors of the JCHR compiler. Thena corresponding status code is returned.

Now the new CHR tool is listed in the combo box of the CHR based analysis tool with thename specified in the plugin.xml (see figure 4.41). When the link under it is clicked,

88


1 p u b l i c v o id r u n C h r A n a l y s i s ( ) {2 b o o l e a n s u c c e s s = t r u e ;3 s t a t u s = S t a t u s . OK_STATUS ;4 i f ( f i l e != n u l l&& f i l e . e x i s t s ( ) ) {5 Job g e n e r a t e C o d e =new Job ( " G e n e r a t e Code " ) {6 p r o t e c t e d I S t a t u s run ( I P r o g r e s s M o n i t o r m o n i t o r ) {7 cmp=new Compile ( f i l e ) ;8 cmp . run ( n u l l ) ;9 i f ( cmp . g e t S t a t u s ( ) != S t a t u s . OK_STATUS)

10 r e t u r n cmp . g e t S t a t u s ( ) ;11 i f ( ! cmp . g e t E r r o r O u t p u t ( ) . e q u a l s ( " " ) )12 r e t u r n new S t a t u s ( S t a t u s . ERROR,13 " org . uniu lm . g t s . c h r a n a l y s i s t o o l s " ,14 " KULeuven JCHR Compi le r p roduced e r r o r s " ) ;15 r e t u r n S t a t u s . OK_STATUS ;16 } } ;17 g e n e r a t e C o d e . a d d J o b C h a n g e L i s t e n e r ( t h i s ) ;18 g e n e r a t e C o d e . s c h e d u l e ( ) ;19 } e l s e {20 s u c c e s s = f a l s e ;21 s t a t u s = new S t a t u s ( S t a t u s . ERROR,22 " org . uniu lm . g t s . a n a l y s i s t o o l s . c h r a n a l y z e r " ,23 " Source f i l e does n o t e x i s t " ) ;24 }25 i f ( ! s u c c e s s ) {26 E r r o r D i a l o g e r r =new E r r o r D i a l o g ( n u l l ,27 " E r r o r c o m p i l i n g f i l e " ,28 " The j c h r f i l e c o u l d n o t be opened " , s t a t u s , 0 ) ;29 e r r . open ( ) ;30 }31 }

Listing 4.16: startAnalysis() method of the ChrCompiler class.

Figure 4.41: CHR compile tool, listed in the combo box of the CHR based tool.

89

4 Realization

the generated code will be compiled to a java source file that can be embedded into otherprojects or used by further analysis tools.

4.7 The graphical analysis tool

When analyzing a GTS, an important requirement is to have the possibility to apply therules to a host graph. The computation of the transformations can be done by CHR (sec-tion 2.3). However, methods must be developed to apply rules step by step and to manuallydefine to which nodes and edges the rule should be applied.

4.7.1 Design

In this section, I develop a method that realizes a step-by-step-application of CHR rulesand describe how to define the next match of a CHR rule manually. Furthermore, I designthe graphical user interface of the tool. To create an executable environment for a GTS,JCHR code has to be generated similar to the method described in the section 4.6.1.3.Additionally, a possibility is required to load and access the generated JCHR handler.

4.7.1.1 Interactive CHR environment

Usually, CHR does not provide the possibility to activate and deactivate rules, apply themstep by step, or manually select to which constraints a rule is applied. In the following, Idescribe approaches to solve each of the three problems.

I found two approaches for the step-by-step-application of rules. The first approach is veryspecific to JCHR handlers: They offer the possibility to register a listener to them, so thatthe handler notifies its listeners before a rule application. To use this feature, the debugmode has to be activated in the compiler. However, the listener only gets notified that arule is going to be applied, but this cannot be canceled. The other approach is to modifythe rules of the original CHR program by adding a new constraint to each rule. Therefore,the rule

r@Hkep\Hrem ⇔ G|B.

is transformed to the rule

r1@Hkep\start, Hrem ⇔ G|B.

The start/0 constraint is a special constraint that is added to the constraint definitionsof the program. This constraint must be added to the CHR goal store if a rule should beapplied. When the start constraint is added, the goal stack of the current state is empty,because all its constraints are already in the CHR store. When the new constraint is added tothe goal stack, it becomes an active constraint and is associated with its occurrences. Whenan occurrence is found, all numbered constraints are searched to find a set of constraints thatmatch to the head of this rule (see section 2.1 for a description of the operational semanticsof CHR). Take, for example, the greatest common divisor program from section 2.1 withthe modified rules

gcd11 @ start, gcd(0)⇔ true.

gcd21 @ gcd(I)\start, gcd(J)⇔ J ≥ I, I > 0|K is J − I, gcd(K).

When adding the constraints gcd(6) and gcd(9), no rules can be applied and the constraintsare moved to the CHR store. The according state is:

〈[], {gcd(6)#1, gcd(9)#2}〉3

90


When a start constraint is added

〈[start], {gcd(6)#1, gcd(9)#2}〉3

it becomes the active constraint resulting in the state:

〈[start#3 : 1], start#3, gcd(6)#1, gcd(9)#2}〉4

When the occurrence matches the start constraint of the second rule

〈[start#3 : 2], {start#3, gcd(6)#1, gcd(9)#2}〉4

a match is found and the rule is applied resulting in the state

〈[gcd(3)], {gcd(6)#1}〉4

No rule of the CHR program is applied and the gcd(3) constraint is moved into the CHRstore, therefore, the final state is

〈[], {gcd(6)#1, gcd(3)#4}〉5

where no transition rule can be applied anymore. Furthermore, a noprocess constraint isadded to the program together with the rule

start⇔ noprocess.

at the very end of the CHR program, so that start constraints are replaced by noprocessconstraints when no rule has been applied. This constraint can be looked up by the userto check whether a rule could be applied or not. However, these constraints have to beremoved from the CHR store when a new start constraint is added, because otherwise, itcannot be determined whether a rule has been applied or not. For this reason, the rule

start\noprocess⇔ true.

is added at the beginning of the program. This rule removes all noprocess constraints thatare currently in the store before attempting to apply any of the other rules when a new startconstraint is added.

The second approach is used, because it is portable to other CHR implementations andthe listener feature of JCHR is still in experimental state and might be removed in furtherversions ([43]).

Activating and deactivating rules is also done by modifying a given CHR program. Eachrule

ri @ Hkep\Hrem ⇔ G|B.

has to be modified in the following form:

r2i @ rule_activate(i),Hkep\Hrem ⇔ G|B.

rule_activate/1 is here a new constraint and i is a unique number which is assigned toeach rule. As a consequence, only when a rule_activate(i) constraint is in the CHR store,the rule can be applied. The greatest common divisor program is used as an example. Therules must be modified in the following form:

gcd12 @ rule_activate(1)\gcd(0)⇔ true.

gcd22 @ rule_activate(2), gcd(I)\gcd(J)⇔ J ≥ I, I > 0|K is J − I, gcd(K).

91

4 Realization

When adding the constraint gcd(9) and gcd(6) no rule of the CHR program can be appliedresulting in the state

〈[], {gcd(6)#1, gcd(9)#2}〉3When a rule_activate(2) constraint is added

〈[rule_activate(2)], {gcd(6)#1, gcd(9)#2}〉3

it becomes the active constraint, resulting in the state:

〈[rule_activate(2)#3 : 1], {rule_activate(2)#3, gcd(6)#1, gcd(9)#2}〉4

When the occurrence matches the rule_activate(2) constraint of the second rule

〈[rule_activate(2)#3 : 2], {rule_activate(2)#3, gcd(6)#1, gcd(9)#2}〉3

a match can be found and the second rule is applied, resulting in the state

〈[gcd(3)], {rule_activate(2)#3, gcd(6)#1}〉3

The rule can be applied two further times, to reach the state

〈[], {rule_activate(2)#3, gcd(3)#5, gcd(0)#6}〉7

in which no transition rule can be applied anymore. In order to apply the first CHR rule toremove the gcd(0) constraint, a rule_activate(1) constraint must be added. To deactivatean activated rule, another rule is added:

rule_activate(N), rule_deactivate(N)⇔ true.

This rule removes pairs of rule_activate(N) and rule_deactivate(N) constraints. Inorder to deactivate a rule, the user has to add a rule_deactivate constraint with the ac-cording rule number to the store. In order to activate a rule a rule_activate constraint withthe according rule number must be added. This is especially useful if the user wants to seethe intermediate state that is reached when only a set of rules is applied. If a final stateis reached the rules can be deactivated and other rules can be activated to reach anotherintermediate state.

There are also two approaches for the manual selection of CHR matches. The first approachis specific to the JCHR K.U. Leuven compiler: Each constraint’s arity is increased by one tohold a boolean value which is true when a constraint can be used for a rule application, andfalse otherwise. The user has to manage these variables and set them true or false, depend-ing on whether the constraint should be used in a match, or not. The rules must be changedaccordingly, so that only selected constraints are used. The problem arising from this is themodified problem ([43]), i.e. how does the JCHR handler know when a constraint’s termis changed and must be revised for rule application. The K.U. Leuven compiler providesa solution in the form of observable variables which notify the JCHR handler when theirvalue changes. Then JCHR reconsiders the constraints of these variables for rule appli-cation. However, this feature is work in progress, has changed in the newer versions ofJCHR, and is not documented very well in the current version. The second approach is tomodify the CHR program itself: different CHR constraints are used to represent selectedand deselected states of constraints. For every constraint type c, two other constraint typesare defined: c_sel and c_desel with the same signature as c. For each constraint c, two newrules of the form

csel @ c_sel(N)\c(N)⇔ true.

92


andcdesel @ c_sel(N), c_desel(N)⇔ c(N).

are introduced where the N symbolizes that all terms of the constraints must be identical.These rules are added at the top of the CHR program. Now, the user can add c_sel con-straints with the attributes of the according c constraint to select a certain constraint. Ac_desel constraint is added to the goal stack in order to revert the constraint to the nor-mal, deselected status. The gcd/1 constraint of the gcd example, therefore, results in theconstraint definitions

gcd/1, gcd_sel/1, gcd_desel/1

the rulesgcdsel@gcd_sel(N)\gcd(N)⇔ true.

andgcddesel@gcd_sel(N), gcd_desel(N)⇔ gcd(N).

To make sure that the rules only work on selected constraints, all constraints in a rule’shead have to be replaced by the corresponding sel version of the constraint. So, every rule

r @ Hkep\Hrem ⇔ G|B

is replaced by a ruler3 @ H ′ ⇔ G|B,Hkep

where for all constraints c ∈ Hkep ∪ Hrem a c_sel constraint in H ′ is added. As youcan see, simpagation rules are replaced by simplification rules, because the constraintsare deselected after rule application. The main problem with this approach is that CHRcannot find matches on its own anymore. Because of that, another modification to the CHRprogram is added. For each rule

r @ Hkep\Hrem ⇔ G|B

a new ruler3find @ find, Hkep,Hrem ⇔ G|H ′

is added which replaces the constraints from an original rule’s head. That is done by thecorresponding selected constraints that are needed by the modified rule r3. find/0 is a newconstraint, which must be added manually. This constraint signals the handler to search fora new match. The rules from the gcd example are modified to

gcd13find @ find, gcd(0)⇔ gcd_sel(0).

gcd13 @ gcd_sel(0)⇔ true.

gcd23find @ find, gcd(I), gcd(J)⇔ J ≥ I, I > 0|gcd_sel(I), gcd_sel(J).

gcd23 @ gcd_sel(I), gcd_sel(J)⇔ J ≥ I, I > 0|K is J − I, gcd(K), gcd(I).

A further rulefind⇔ nofind.

is added to the end of the CHR program and

find\nofind⇔ true.

to its beginning. The first rule gives the user the possibility to see that no match was foundand the second one removes the nofind constraints when a new find constraint is added,so that old nofind constraints cannot be looked up when a new find constraint is added. Ipresent the gcd example and start with a state where the two constraints gcd(9) and gcd(6)

93

4 Realization

are in the CHR store:〈[], {gcd(6)#1, gcd(9)#2}〉3

Now the constraint gcd_sel(6) is added to the goal stack. Therefore, the rule gcdsel istriggered, resulting in the state

〈[], {gcd_sel(6)#3, gcd(9)#2}〉4

No rule can be applied from this state, but when adding another gcd_sel(9) constraint, therule gcdsel is applied again to form the state

〈[gcd_sel(9)#4], {gcd_sel(6)#3}〉5

The gcd_sel(9) constraint in the goal stack is compared to the occurrences of the remainingrules. Finally, the rule gcd23 is applied to form the final state

〈[], {gcd(3)#5, gcd(6)#6}〉7

When a find constraint is added

〈[find], {gcd(3)#5, gcd(6)#6}〉7

a match is found with the occurrence of find in rule gcd23find, which results in the state

〈[gcd_sel(3), gcd_sel(6)], {}〉8

The gcd_sel(3) constraint is moved to the CHR store, because no rule can be applied. Thenthe rule gcd23 can be applied which yields the final state

〈[], {gcd(3)#11, gcd(3)#10}〉12

After adding two more find constraints, the goal store only contains one gcd(3) constraint.

The second approach is chosen with the same arguments mentioned before: It is portableto other CHR implementations and the documentation of the K.U. Leuven system is notvery detailed on this topic and the features required could also be removed or changed infuture versions.

By using the modifications described above, a CHR program can be created that can beexecuted step by step with selected rules and only with the selected constraints. Given aCHR program p = (C,R) consisting of a set of constraint definitions C and a list of rulesR, the new CHR program pinteractive = (C ′, R′) can be created as follows:

C ′ = {find, nofind, start, noprocess, rule_activate(int), rule_deactivate(int)}∪{{c_sel, c_desel, c}|c ∈ C}

R′ = [(find\nofind⇔ true), (start\noprocess⇔ true)]||[(c_sel(N)\c(N)⇔ true), (c_sel(N), c_desel(N)⇔ c)] ∀c ∈ C||[r4

find, r4] ∀r ∈ R

||[(find⇔ nofind), (start⇔ noprocess)]

where r4find is a combination of the rule r3

find and r2 where an additional rule_activate(i)constraint is added to Hkep of r3

find and where i is the number of rule r of the originalprogram p. r4 is a combination of the rules r1, r2, and r3 where an additional startconstraint is added to Hrem of r3, so that the rule is applied only when a start constraintis added by the user. Furthermore, an additional rule_activate(i) is added to Hkep wherei is the number of the rule r of the original program p. The operator || is the concatenation

94


operator for lists. The order of the rules is important, because of the operational semanticsdescribed in section 2.1.

The rules of the CHR program for the gcd example would, therefore, be

find\nofind⇔ true.

start\noprocess⇔ true

gcdsel @ gcd_sel(N)\c(N)⇔ true

gcddesel @ gcd_desel(N), c_sel(N)⇔ c(N).

gcd14find @ rule_activate(1)\find, gcd(0)⇔ gcd_sel(0).

gcd14 @ rule_activate(1)\start, gcd_sel(0)⇔ true.

gcd24find @ rule_activate(2)\find, gcd(I), gcd(J)⇔ J ≥ I, I > 0|gcd_sel(I), gcd_sel(J).

gcd24 @ rule_activate(2)\start, gcd_sel(I), gcd_sel(J)⇔ J ≥ I, I > 0|K is J−I, gcd(K), gcd(I).

find⇔ nofind.

start⇔ noprocess.

For a CHR program of this form, a rule can only be applied if it is activated and a startconstraint is added. Furthermore, the activated rules are only applied to the selected con-straints. These constraints can be manually selected or by adding a find constraint. Whenadding a find constraint, only the rules are used that have been activated by the user.The rules can be activated and deactivated by adding rule_activate and rule_deactivateconstraints.

The following list provides the instructions on how to use a program of the form above:

activation and deactivation of rules Add the according rule_activate(i) orrule_deactivate(i) constraint to the store. Only the activated rules are used forrule application or for automatically selecting constraints.

find constraints that match to the activated rules Add a c_desel constraint for ev-ery c_sel constraint in the CHR store to remove the current selection. Then add afind constraint. The activated rules are then used to find constraints that match toa head. These constraints are then present as selected constraints in the CHR store.The according rule can be applied to them by adding a start constraint. Beforeconstraints can be selected manually, rules have to be activated.

automatic rule application First, add a find and then a start constraint to the CHRstore until a noprocess constraint can be looked up in the CHR store. When onlya fixed number of steps should be executed, find and noprocess constraints areadded alternately to the CHR store the according number of times. This procedurecan also be used to execute one step of the program automatically. Only the activatedrules are used for finding and applying constraints. Therefore, these rules must beactivated prior to adding find and start constraints.

manual step by step rule application To select constraints, the available constraintsmust be visible to the user. New c_sel constraints must be added with the terms fromthe chosen c constraint. For deactivation, c_desel constraints with the same termsas the c_sel constraints are added to the store. To apply one of the activated rulesto the selection, a start constraint must be added. When no rule could be applied,a noprocess constraint is found in the CHR store. The rules have to be activated bythe user prior to adding a start constraint.

95

4 Realization


With the methods described in the previous section, the CHR encoding of a GTS can bemodified in a way that it can be executed step by step and that the nodes and edges can beselected which are matched by the next rule application. The code for realizing this will begenerated in the JCHR syntax, just as described in section 4.6.1.3. But in order to use thegenerated handler, it has to be compiled to a java class (section 4.6.2.4). This class containsmethods that depend on the constraint definitions in the JCHR program. Two methods areprovided for each constraint type: one to receive a list of the constraints in the CHR storeand one to add the constraint to the CHR store. Therefore, loading the generated classdynamically is difficult, because the methods would have to be determined dynamically.A solution to this problem is to generate another java source file which implements a javainterface that provides methods to access node or edge constraints of a JCHR handler moregenerically.

In more detail, this interface must provide methods to return all the information containedin the JCHR program plus the information about host graphs which are not encoded in theJCHR program. For that reason, the interface provides methods to return all rule and hostgraphs’ names, to activate and deactivate rules by giving their name, to restart the CHRprogram with a new host graph (by giving its name), to read all node and edge constraints,to (de)select node and edge constraints, to add start and find constraints, and to checkwhether a rule has been applied or if a match was found. Node and edge constraints needa representation that is independent from the underlying CHR handler, hiding the differ-ent constraints for nodes and edges. Therefore, two wrapper classes for these constrainttypes must be provided. The methods for activating and deactivating constraints receivean instance of one of the wrapper classes and add new constraints to the CHR handler.This generated java class can then be dynamically loaded from the tool to access the JCHRhandler in a generic way.


The graphical user interface consists of two parts: The part where settings are made forgenerating the CHR code and the part where the generated handler is displayed. Figure 4.43shows the first part. The settings that can be made here are similar to the ones describedin section 4.6.1.2. Only the list for selecting host graphs for export is missing, becausethey are all available for selection. When activating and deactivating rules, they shouldbe displayed in the editors. When the CHR handler is created and loaded, the secondpart of the GUI becomes visible which is shown in figure 4.44. A list for activating anddeactivating rules is provided together with a combo box that lists the available host graphs.When rules are (de)activated they should also be displayed in the editors of the platform.The main element is, however, the graphical representation of the current host graph. As therules of the GTS are applied to a host graph by using CHR, automated layout for the graphis needed, because the constraints do not contain information about their position. Thenodes and edges can be selected by double clicking on them, so that rules can be appliedto them. For that reason, the displayed graph must highlight which nodes and edges arecurrently selected. Additionally, hyperlinks are available that enable the user to apply thecurrently activated rules to the currently selected constraints, to select constraints that canbe matched by one of the activated rules, and to apply the rules several times in a row oruntil a final state can be reached. When running the GTS to a final state, another buttonmust be displayed to cancel the calculations in case a non-terminating GTS was designed.Furthermore, a hyperlink is provided to deselect all nodes and edges. The use case diagramin figure 4.42 shows the interaction between the user and the tool.

96


Figure 4.42: UML use case diagram for the interaction between the user and the graphicalsimulation tool.

Figure 4.43: Selection and order of the rules for graphical simulation.

Figure 4.44: Running simulation of a GTS with selected edges and nodes.

97

4 Realization

4.7.1.4 Synchronization of display and handler

To represent the graph in a diagram, it has to be synchronized with the constraint storeof the underlying CHR handler. An algorithm is provided that checks for removal andaddition of constraints. The CHR rules that are generated for the selection and deselectionof constraints in fact remove and add constraints to the store. The graphical representation,however, should not remove and re-add the according nodes, because this would result inlaying out the graph again. The algorithm maintains mappings from node constraints to thedisplayed nodes (node mapping) and from edge constraints to the displayed edges (edgemapping). In fact, the node mapping does not map the constraints to the displayed nodes,but the identifier attribute (that is the first attribute of the constraint, see section 2.3) ismapped to the displayed node. That is done to overcome the problem that two differentconstraint types encode the same node which would otherwise lead to a re-layout of thedisplayed graph when a node becomes (de)selected. When the view of the displayed graphis updated, the node constraints are all stored in a new mapping that also links the firstidentifier attribute of the node constraints to nodes in the diagram. If the node attribute isnot available in the node map, a new node for the diagram is added otherwise the old nodefrom the diagram is taken from the old node mapping. The same procedure is repeated forthe selected nodes. After that, the identifier attributes that are in the old node map, but notin the new node map, are searched and their nodes in the graph display are disposed. Thesame procedure is repeated for edge constraints, as well. The difference is that the mappinggoes directly from the constraints to the displayed edges. Because of that, edges that are(de)selected are removed and added again, but this does not impose any problems. Thiswill not lead to a re-layout, because the position of the edge is determined by the positionsof the source and target node. This synchronization has to be done each time the CHR storeis changed in the handler.


In this section, I give some details about the generation of the JCHR handler and the corre-sponding interface to access it. Then I describe the implementation of the GUI where I payspecial attention to the graphical representation of the constraints as a graph. This tool canbe found in the project org.uniulm.gts.analystools.graphicalsimulation.

4.7.2.1 Generation of the JCHR handler and its interface

The generation of the CHR source is similar to the method described in 4.6, but the alreadydeveloped template is not reused, because the generated code is no regular CHR encoding(section 2.3). The CHR encoding is modified according to the rules in section 4.7.1.1 andthis modified encoding is generated directly from the GTS model without generating theregular encoding first. However, additionally to the CHR source, a java source file has tobe generated which implements the interface IGTSFacade which contains methods togenerically access the JCHR handler. For a list of the provided methods, please see table4.5. The generated code for the java interface does not implement the interface directly,but an abstract base class AbstractGtsFacade. This class implements some methodsof the interface and provides further methods to simplify generated code. Table 4.6 showsthe methods of the abstract base class, that need to be implemented. All these methods areimplemented in a way that they query the CHR store or add a CHR constraint to it. Thecode generation is done by JET, just like for the JCHR file. The activation of rules, forexample, is generated by the template in listing 4.17. This template iterates over the rulesand prints if statements that add rule_activate constraints to the handler. The diningphilosophers problem would, consequently, produce the code shown in listing 4.18. The

98


Read Handler returns. . .List<String> getHosts() list of host identifiersList<String> getRules() list of rule identifiersList<String> getTypeNodes() list of type node identifiersList<String> getTypeEdges() list of type edge identifiersList<GtsChrNode> getNodes() list of nodesList<GtsChrEdge> getEdges() list of edgesList<GtsChrNode> getSelectedNodes() list of selected nodesList<GtsChrEdge> getSelectedEdges() list of selected edgesboolean nothingFound() whether match was foundboolean nothingProcessed() whether rule was appliedModify Handlervoid putStart() apply rulevoid findMatchMorphism() find matchvoid activateRule(String rule) activate rulevoid deactivateRule(String rule) deactivate rulevoid activateAllRules() activate all rulesvoid deactivateAllRules() deactivate all rulesvoid setHost(String host) put new host encoding in goal storevoid select(GtsChrNode n) select nodevoid select(GtsChrEdge e) select edgevoid deselect(GtsChrNode n) deselect nodevoid deselect(GtsChrEdge e) deselect edge

Table 4.5: List of methods provided by the IGTSFacade interface.

Method DescriptionactivateRule(String rule) Activate the rule with the given iddeactivateRule(String rule)a Deactivate the rule with the given iddeselect(GtsChrNode n) Deselect the given node constraintdeselect(GtsChrEdge e) Deselect the given edge constraintselect(GtsChrNode n) Select the given node constraintvoid select(GtsChrEdge e) Select the given edge constraintputStart() Do a transformation stepfindMatchMorphism() Find a match morphismsetHost(String host) Start program with the host of the given idgetNodes(String type) Return all node constraints of the given typegetEdges(String type) Return edge constraints of the given namegetSelectedEdges(String s) Return selected edge constraints of the given namegetSelectedNodes(String s) Return selected nodeconstraints of the given nameboolean nothingFound() Returns if a rule could be appliedboolean nothingProcessed() Returns if a match could be found

Table 4.6: List of methods that need to be implemented by classes implementing the baseclass AbstractGTSFacade.

1 p u b l i c vo id a c t i v a t e R u l e ( S t r i n g r u l e ) {2 < c : s e t V a r i a b l e v a r =" r u l e C n t " s e l e c t =" 0 " / >3 < c : i t e r a t e s e l e c t =" r e o r d e r ($ g t s / t r a n s f o r m a t i o n s / @id , $ o r d e r ) " v a r =" r u l e " d e l i m i t e r ="

e l s e ">4 < c : s e t V a r i a b l e v a r =" r u l e C n t " s e l e c t =" $ r u l e C n t +1 " / >5 i f ( r u l e . e q u a l s ( "< c : g e t s e l e c t =" $ r u l e " / > " ) ) {6 h a n d l e r . t e l l R u l e _ a c t i v a t e ( < c : g e t s e l e c t =" $ r u l e C n t " / > ) ;7 }< / c : i t e r a t e >8 }

Listing 4.17: JET template for generating the activateRule() method.

99

4 Realization

1 p u b l i c vo id a c t i v a t e R u l e ( S t r i n g r u l e ) {2 i f ( r u l e . e q u a l s ( " th inkToWai t " ) ) {3 h a n d l e r . t e l l R u l e _ d e a c t i v a t e ( 1 ) ;4 } e l s e i f ( r u l e . e q u a l s ( " wa i tToEa t " ) ) {5 h a n d l e r . t e l l R u l e _ d e a c t i v a t e ( 2 ) ;6 } e l s e i f ( r u l e . e q u a l s ( " ea tToTh ink " ) ) {7 h a n d l e r . t e l l R u l e _ d e a c t i v a t e ( 3 ) ;8 }9 }

Listing 4.18: Generated code from the template shown in listing 4.17.

1 i f ( h o s t . e q u a l s ( " t w o P h i l o s " ) ) {2 h a n d l e r =new P h i l o s o p h e r H a n d l e r ( ) ;3 HashMap< S t r i n g , L o g i c a l I n t > nodes =new HashMap< S t r i n g , L o g i c a l I n t > ( ) ;4 nodes . p u t ( " P2 " , new L o g i c a l I n t ( ) ) ;5 h a n d l e r . t e l l N _ p h i l o s o p h e r ( nodes . g e t ( " P2 " ) , 3 ) ;6 nodes . p u t ( " F1 " , new L o g i c a l I n t ( ) ) ;7 h a n d l e r . t e l l N _ f o r k ( nodes . g e t ( " F1 " ) , 2 ) ;8 nodes . p u t ( " F2 " , new L o g i c a l I n t ( ) ) ;9 h a n d l e r . t e l l N _ f o r k ( nodes . g e t ( " F2 " ) , 2 ) ;

10 nodes . p u t ( " P1 " , new L o g i c a l I n t ( ) ) ;11 h a n d l e r . t e l l N _ p h i l o s o p h e r ( nodes . g e t ( " P1 " ) , 3 ) ;12 h a n d l e r . t e l l E _ l i e s t N e x t T o ( nodes . g e t ( " F1 " ) , nodes . g e t ( " P2 " ) ) ;13 h a n d l e r . t e l l E _ l i e s t N e x t T o ( nodes . g e t ( " F2 " ) , nodes . g e t ( " P2 " ) ) ;14 h a n d l e r . t e l l E _ e a t ( nodes . g e t ( " P2 " ) , nodes . g e t ( " P2 " ) ) ;15 h a n d l e r . t e l l E _ w a i t ( nodes . g e t ( " P1 " ) , nodes . g e t ( " P1 " ) ) ;16 h a n d l e r . t e l l E _ l i e s t N e x t T o ( nodes . g e t ( " F1 " ) , nodes . g e t ( " P1 " ) ) ;17 h a n d l e r . t e l l E _ l i e s t N e x t T o ( nodes . g e t ( " F2 " ) , nodes . g e t ( " P1 " ) ) ;18 }

Listing 4.19: Generated code to add the constraints of the encoded host graph twoPhilos ofthe dining philosophers example.

other methods for (de)selecting nodes and edges are implemented similarly. The methodsetHost(String) creates a new handler and adds the constraints of the encoding ofthe host graph which is identified by the given string. Listing 4.19 shows the code thatis generated for the twoPhilos host graph of the dining philosophers example. First, newLogicalInt values are created and saved in a map, identified by the node identifier ofthe host. These values are then added to the handler as new fork or philosopher constraintstogether with the number of adjacent edges.

Both files are generated when the user has set the order of the rules and given the name forthe package and the handler in part one of the GUI described in section 4.6.1.2. The JCHRprogram must then be compiled by the K.U. Leuven JCHR compiler, just as described insection 4.6.2.4.

4.7.2.2 Loading of the generated files

The result of the code generation and JCHR compilation are two java classes that are com-piled by the eclipse platform to java byte-code. These classes can be loaded by the javaclass loader. The problem is that the generated implementation of the interface dependson the plug-in created for this GTS analysis tool, because it contains the interface defi-nition. Therefore, the tool must register itself on start-up as a dependency in the projectwhere the generated files are placed in. That is why new GTS projects are eclipse plug-in projects (see section 4.2.1.1), because plug-ins can only be added as dependencies toplug-in projects and not to common java projects. Listing 4.20 shows how a plug-in is pro-grammatically added as a dependency. As described in section 2.4, the dependencies of aproject are saved in the MANIFEST.MF file of the project. Eclipse offers a set of classes toquery and edit elements of the current plug-in project. The BundlePluginModelBase

100


1 / / t h e c u r r e n t p r o j e c t i s saved i n c u r P r o j e c t2 BundlePlug inMode lBase pm=( BundleP lug inMode lBase ) P l u g i n R e g i s t r y . f indMode l ( c u r P r o j e c t ) ;3 I P l u g i n B a s e pb=pm . g e t P l u g i n B a s e ( ) ;4 S t r i n g p l u g i n I d = G r a p h i c a l E x e c u t i o n D i a g n o s t i c T o o l P l u g i n . PLUGIN_ID ;5 P l u g i n I m p o r t p l u g i n = new P l u g i n I m p o r t ( ) ;6 M a n i f e s t E l e m e n t e l e m e n t =7 M a n i f e s t E l e m e n t . p a r s e H e a d e r ( C o n s t a n t s . REQUIRE_BUNDLE, p l u g i n I d ) ;8 p l u g i n . l o a d ( e lement , 1 ) ;9 p l u g i n . se tMode l ( pb . getModel ( ) ) ;

10 / / s e t t h e model e d i t a b l e11 ( ( WorkspaceBundleModel ) ( ( BundleP lug inMode lBase ) pb . getModel ( ) ) .12 getBundleModel ( ) ) . s e t E d i t a b l e ( t r u e ) ;13 / / add t h e p l u g i n as a dependency14 pb . add ( p l u g i n ) ;15 / / s av e t h e made changes16 pm . sa ve ( ) ;

Listing 4.20: Adding a plug-in as dependency of a project.

can be received from the current project to get a IPluginBase instance which managesthe dependencies of a project. A new PluginImport instance can be added to it thatcontains the plug-in id of the graphical analysis tool plug-in (lines 2–9). In order to savethese changes to the MANIFEST.MF file, the model has to be set editable (lines 11,12).When the tool has added itself as dependency to the current project, the interface and theJCHR can be loaded dynamically by the class loader.

4.7.2.3 Using the generated handler

The JCHR handler is not used directly, but via the interface that is also generated. To repre-sent the constraints contained in the handler, Zest is used. Zest is a tool for displaying andlaying out graphs. It is based on draw2d (see section 4.4) for drawing the nodes and edges.Zest provides a Graph widget to which GraphNode and GraphConnection widgetscan be added. Widgets are elements of the GUI provided by the SWT. The elements canthen be laid out automatically. The graph widget is updated every time a constraint is addedto the JCHR handler. Therefore, edge constraints are represented by GraphConnectionwidgets and node constraints are represented as GraphNode widgets. The algorithm de-scribed in section 4.7.1.4 is used to synchronize the contents of the JCHR handler with thegraph widget. To allow the (de)selection of constraints, a MouseListener is added tothe Graph instance. When a double click occurs, the constraint linked to the currentlyselected GraphNode or GraphConnection will be selected in the handler by callingthe select(GtsChrNode) method of the generated interface class. All the communi-cation with the handler is done via the generated implementation of the IGTSFacade, asdescribed in the sequence diagrams in figure 4.45. When the user clicks on a rule in the listof rules or double clicks an edge or node, an according method in the interface is activatedwhich adds a new constraint to the CHR handler.

The option to simulate the GTS until a final state is reached must run in an own thread,because this can be a very long running task which would otherwise block the whole sys-tem. Eclipse provides this functionality in the form of a Job object which has furtherbenefits: It is shown in the eclipse job view and can also be stopped from there. The Jobitself repeatedly calls the methods putStart() and findMatchMorphism() of theinterface (see also section 4.7.1.1) and stops when no rule can be applied anymore (done bycalling the method nothingProcessed()) or when the user requests to stop the job.The tool adds itself as listener to the Job, so that it gets notified when the CHR programhas finished to synchronize the graphical representation with the state of the CHR handler.Figure 4.46 shows how morphisms are found and how rules are applied by using the gen-erated implementation of the interface. Finding a new match morphism is done by addinga find constraint which selects the constraints that can be matched by a rule. But before

101

4 Realization

User

User

GraphDisplay

GraphDisplay

IGTSFacade

IGTSFacade

GTSHandler

GTSHandler

(de)select rule entry

activateRule(ruleName)

get rule number

tellRule_activate(number)

void

void

alt [select]

deactivateRule(ruleName)

get rule number

tellRule_deactivate(number)

void

void

[deselect]

User

User

GraphDisplay

GraphDisplay

IGTSFacade

IGTSFacade

GTSHandler

GTSHandler

Double clicknode or edge

check ifactive

deselect(constraint)

switch to correcttell-method

tellConstraint(new Constraint)

void

void

alt [active]

select(constraint)

switch to correcttell-method

tellConstraint(new Constraint)

void

void

[inactive]

update display

Figure 4.45: UML sequence diagram for the activation or deactivation of rules (upper) andnode or edge constraints (lower).

102


User

User

GraphDisplay

GraphDisplay

IGTSFacade

IGTSFacade

GTSHandler

GTSHandler

find match

getSelectedNodes()

getAct_type();

constraint list

loop [for all active constraint types]

constraint list

deselect(constraint)

telleDeact_type(constraint)

void

void

loop [for each constraint in list]

findMatchMorphism()

tellFind();

void

void

updatedisplay

User

User

GraphDisplay

GraphDisplay

IGTSFacade

IGTSFacade

GTSHandler

GTSHandler

apply rule

putStart()

tellStart();

void

void

updatedisplay

Figure 4.46: UML sequence diagram for finding matches (upper) and applying rules(lower).

103

4 Realization

Figure 4.47: Dialog to adjust code generation.

Figure 4.48: Interface that shows a host graph after the generation of the handler.

adding the find constraint, all selected constraints are deselected first, so that the rule isapplied to the constraints that are selected by the find constraint. Applying a rule is doneby adding a start constraint to the store, so that rules can be applied.


In this section, I want to present the simulation of the dining philosophers example. Fig-ure 4.47 shows the dialog which allows to select the rules and set their order. Furthermore,a package and a handler name can be entered, but the default values are used just as thedefault ordering of the rules. After a click on the Create GTS and execute it hyperlink, amessage will appear at the bottom and the scheduled job will be shown in the bottom rightcorner of the workbench. After the compilation of the JCHR program is finished (this takesabout five to ten seconds) the second part of the GUI will open. Figure 4.48 shows thisGUI with the upper dialog collapsed. The host graph with the two philosophers is selectedshowing the corresponding host graph. When activating constraints in a way that none ofthe selected rules can match it like in figure 4.49 and the apply rule hyperlink is clicked, amessage will be shown which informs the user that no rule could be applied. With a clickon find morphisms and only the rule eating activated, the next match will be highlighted inthe graph as shown in figure 4.50. After clicking on apply rule, the rule is applied, resultingin the graph shown in figure 4.51. Every time when a rule is selected in the list, it is also

104

4.8 Further analysis tools

Figure 4.49: Message that is displayed when no rule can be applied.

displayed in the editor.


In this section, I present another analysis tool and give an idea how a CHR analysis toolcould be realized that checks confluence of GTS.

4.8.1 Random host generation tool

An analysis tool has been developed for the easy generation of random host graphs. Thistool provides a view where the numbers of type nodes and type edges can be entered. Whenall numbers are entered, a graph with the selected amount of nodes of each type is created.The nodes are randomly connected by the selected number of edges. It is taken care of, thatthe edges are connected to nodes of the correct type. Furthermore, if there are no nodes ofthe correct type for a given edge, the edges are not added, of course. This tool implementsthe analysis tool interface, so that the model and the command-stack can be provided.When the tool is started, it launches an eclipse wizard that contains two tables which letyou enter the numbers of the type nodes and type edges. The names of the nodes in thehost graph are increasing numbers. The graph is created using the command stack, butthe nodes and edges are created without the command-stack, so that undoing the creationdirectly removes the graph and not every node or edge separately. Figure 4.52 shows theGUI of the graph generation wizard. The default values are five nodes and edges per type.

4.8.2 Confluence analysis

As already mentioned in section 4.6, there is no tool available for analyzing confluence ofJCHR programs. Confluence means that the order of the rule application a CHR programdoes not influence its final state. Confluence for CHR programs is covered in [20]. Basi-cally, a confluence tester creates an input I from the heads of two rules r1 and r2, applies

105

4 Realization

Figure 4.50: Highlighted match morphism for the activated rules.

r1 to I , resulting in I1 and applies r2 to I , resulting in I2. Then, two runs of the CHRprogram are done, one with input I1 and one with input I2. If the constraint and the built-instores of the two final states are equal1 and this holds for all pairs of rules, then the CHRprogram is confluent.

This test can also be used to test confluence for CHR encoded GTS ([32]). However, whencreating Inputs from heads of the rules, further attention must be paid. The inputs mightnot always be an encoding of a correct graph. Therefore, these inputs do not need to betested.

A CHR tool would need to create an executable version of the CHR program by usingthe CHR tool from section 4.6.2.4 and create inputs according to the description above.These inputs are then used as goals for the generated JCHR handler. The resulting finalstates of the JCHR handler are then compared to decide whether the CHR program isconfluent. Pairs of rules that might lead to a non-confluent system can be listed in the tooland displayed in the editors.

1In fact they do not have to be equal, but they must be variants of each other. This described in [20].

106


Figure 4.51: New host graph after a rule has been applied.

Figure 4.52: GUI of the wizard for creating a random host graph.

107

4 Realization

108

5 Conclusion

In this final chapter, the results of the thesis are summarized and possible future projectsbased on it are presented. Furthermore, some application areas of the developed platformare listed.

5.1 Summary of results

During this thesis, an extensible platform, based on eclipse, for editing and analyzingGraph Transformation Systems (GTS) has been developed. This platform allows the editingof GTS not only with a graphical, but also with a textual editor. The textual representationis based on Constraint Handling Rules (CHR). Raiser describes in [32] how GTS can beencoded in a CHR program. The editing can be done simultaneously by the two editors.The benefit of encoding GTS in CHR is that the rule applications in GTS correspond to ruleapplications in CHR. Therefore, CHR can be used to simulate GTS. Another advantage ofusing the CHR encoding is, that analysis methods that can be applied to CHR can now alsobe applied to GTS, e.g. confluence analysis and operational equivalence analysis.

The platform’s functionality can be extended by further tools. For that reason, an eclipseextension point has been provided that can be used to add analysis and editing features tothe platform. A few prototypical tools are already provided. One tool offers the possibilityto apply the rules of a GTS to a host graph interactively by choosing the nodes and edgesto which a selected rule can be applied. This tool is based on the encoding of GTS in CHRand offers a graphical front-end in order to display the modified graph. A similar featurecan be found in the already available programs for GTS, AGG (section 3.1.1) and Groove(section 3.1.2). The other two exemplary tools are for creating random host graphs andtermination analysis based on a ranking function. More sophisticated tools like the criticalpair analysis that can be found in AGG would not have been in the scope of this thesis andare not provided.

To give the possibility to add analysis methods that are available for K.U. Leuven JCHR(the CHR implementation based on java, used by the platform), another tool has beenprovided. This tool defines another eclipse extension point, so that analysis methods forJCHR can easily be added to the platform. One such CHR tool is provided in form of theK.U. Leuven JCHR compiler to create an executable environment of a GTS encoded inCHR. More sophisticated CHR analysis methods like confluence analysis are not provided,because no implementations have been available and it would have been not in the scopeof this thesis to implement them.

The platform can be used for various purposes. It provides the possibility to create ex-ecutable JCHR handlers based on the GTS, so that they can be used in other projects.Furthermore, the platform can be used in lectures about CHR, GTS, or rule based program-ming languages in general to demonstrate application areas and show how rule applicationis done in CHR and GTS. Rudimentary analysis methods are already provided to make thisplatform an alternative to the already available programs (AGG and Groove) for designingGTS.

To conclude, the platform provides new and interesting features. Two editing possibilitiesfor GTS are available, that can be used in parallel. The platform is not a monolithic block

109

5 Conclusion

of functionality, but it can be extended by further tools to analyze and edit GTS. Due tothe possibilities of encoding a GTS in CHR, analysis methods developed for CHR can beapplied to GTS. These analysis methods can easily be embedded in the platform as furthertools. Guides on how to create those tools are given in section 4.5.2 and section 4.6.2.4.An installation guide for the platform can be found in appendix A.

5.2 Future work

The developed platform is a basis for future work, because new analysis tools for GTS andfor CHR can be added to it. Projects for lab courses could include analysis tools for thecalculation of metrics for the GTS. Other interesting features to raise the versatility of theplatform would be import tools that give the possibility to import GTS created in Groove orAGG. Projects for further master or bachelor thesis could include the realization of (semi-)automatic analysis methods for JCHR that can be integrated into the platform, e.g. thealready described confluence test (section 4.8.2). Another improvement of the platformwould be to add support for attributed GTS ([18]). This additional feature could either beimplemented as a further tool or by modifying the editors themselves to integrate it moretightly into the platform.

110

Bibliography

[1] ABDENNADHER, S., AND FAWZY, S. Jchride: An integrated development environ-ment for jchr. 22nd Workshop on (Constraint) Logic Programming (2008).

[2] ABDENNADHER, S., KRAMER, E., SAFT, M., AND SCHMAUSS, M. Jack: Ajava constraint kit. Electronic Notes in Theoretical Computer Science 64 (Septem-ber 2002), 1–17.

[3] ANISZCZYK, C., AND HUDSON, R. Create an eclipse-based application using thegraphical editing framework. World Wide Web electronic publication, 2007. http://www.ibm.com/developerworks/library/os-eclipse-gef11/.

[4] BOAG, S., BERGLUND, A., CHAMBERLIN, D., SIMÉON, J., KAY, M., ROBIE, J.,AND FERNÁNDEZ, M. F. XML path language (XPath) 2.0. W3C Recommenda-tion xpath20-20070123, W3C, January 2007. http://www.w3.org/TR/2007/REC-xpath20-20070123/.

[5] BOESPFLUG, M. TaiChi:how to check your types with serenity. The Monad.Reader9 (Nov. 2007), 17–31.

[6] BUDINSKY, F., MERKS, E., AND STEINBERG, D. Eclipse Modeling Framework 2.0(2nd Edition). Addison-Wesley Professional, 2006.

[7] CORRADINI, A., EHRIG, H., MONTANARI, U., RIBEIRO, L., AND ROZENBERG,G., Eds. Graph Transformations, Third International Conference, ICGT 2006, Natal,Rio Grande do Norte, Brazil, September 17-23, 2006, Proceedings (2006), vol. 4178of Lecture Notes in Computer Science, Springer.

[8] DIJKSTRA, E. W. Hierarchical ordering of sequential processes. Acta Informatica 1(1971), 115–138.

[9] DJELLOUL, K., DUCK, G. J., AND SULZMANN, M., Eds. CHR ’07: Proc. 4thWorkshop on Constraint Handling Rules (Porto, Portugal, Sept. 2007).

[10] ECLIPSE FOUNDATION, INC. Eclipse modeling framework overview. World WideWeb electronic publication, 2008. http://help.eclipse.org/stable/topic/org.eclipse.emf.doc/references/overview/EMF.html.

[11] ECLIPSE FOUNDATION, INC. Java emitter templates (jet). World Wide Webelectronic publication, 2008. http://www.eclipse.org/modeling/m2t/?project=jet.

[12] ECLIPSE FOUNDATION, INC. Jet developer guide. World Wide Web electronic pub-lication, 2008. http://help.eclipse.org/stable/index.jsp?nav=/27.

[13] ECLIPSE FOUNDATION, INC. Textual modeling framework (tmf): Xtext. World WideWeb electronic publication, 2008. http://www.eclipse.org/modeling/tmf/.

[14] ECLIPSE FOUNDATION, INC. Zest: The eclipse visualization toolkit. World WideWeb electronic publication, 2008. http://www.eclipse.org/gef/zest/.

111

http://www.ibm.com/developerworks/library/os-eclipse-gef11/

http://www.ibm.com/developerworks/library/os-eclipse-gef11/

http://www.w3.org/TR/2007/REC-xpath20-20070123/

http://www.w3.org/TR/2007/REC-xpath20-20070123/

http://help.eclipse.org/stable/topic/org.eclipse.emf.doc/references/overview/EMF.html

http://help.eclipse.org/stable/topic/org.eclipse.emf.doc/references/overview/EMF.html

http://www.eclipse.org/modeling/m2t/?project=jet

http://www.eclipse.org/modeling/m2t/?project=jet

http://help.eclipse.org/stable/index.jsp?nav=/27

http://help.eclipse.org/stable/index.jsp?nav=/27

http://www.eclipse.org/modeling/tmf/

http://www.eclipse.org/modeling/tmf/

http://www.eclipse.org/gef/zest/

Bibliography

[15] ECLIPSE FOUNDATION, INC. Eclipse modeling framework (emf). World Wide Webelectronic publication, 2009. http://www.eclipse.org/modeling/emf/.

[16] ECLIPSE FOUNDATION, INC. Graphical editing framework (gef). World Wide Webelectronic publication, 2009. http://www.eclipse.org/gef/.

[17] ECLIPSE FOUNDATION, INC. Graphical modeling framework (gmf). World WideWeb electronic publication, 2009. http://www.eclipse.org/gmf/.

[18] EHRIG, H., EHRIG, K., PRANGE, U., AND TAENTZER, G. Fundamentals of Al-gebraic Graph Transformation (Monographs in Theoretical Computer Science. AnEATCS Series). Springer, March 2006.

[19] EHRIG, H., HECKEL, R., KORFF, M., LÖWE, M., RIBEIRO, L., WAGNER, A.,AND CORRADINI, A. Algebraic approaches to graph transformation. part ii: singlepushout approach and comparison with double pushout approach. 247–312.

[20] FRÜHWIRTH, T. Constraint Handling Rules. Cambridge University Press, June 2009.to appear.

[21] FRÜHWIRTH, T., AND ABDENNADHER, S. Essentials of Constraint Programming.Springer, 2003.

[22] GAMMA, E., AND BECK, K. Contributing to Eclipse: Principles, Patterns, andPlugins. Addison-Wesley Longman Publishing Co., Inc., Redwood City, CA, USA,2003.

[23] GAMMA, E., HELM, R., JOHNSON, R., AND VLISSIDES, J. Design patterns: ele-ments of reusable object-oriented software. Addison-Wesley Professional, 1995.

[24] HOLZBAUR, C., AND FRÜHWIRTH, T. A Prolog Constraint Handling Rules compilerand runtime system. [25], pp. 369–388.

[25] HOLZBAUR, C., AND FRÜHWIRTH, T., Eds. Special Issue on Constraint HandlingRules, vol. 14(4) of Journal of Applied Artificial Intelligence. Taylor & Francis, Apr.2000.

[26] KAY, M. Xsl transformations (xslt) version 2.0. Tech. Rep. xslt20-20070123,World Wide Web Consortium, 2007. http://www.w3.org/TR/2007/REC-xslt20-20070123/.

[27] KRASNER, G. E., AND POPE, S. T. A cookbook for using the model-view controlleruser interface paradigm in smalltalk-80. J. Object Oriented Program. 1, 3 (1988),26–49.

[28] LAM, E. S. L., AND SULZMANN, M. A concurrent constraint handling rules imple-mentation in haskell with software transactional memory. In DAMP ’07: Proceedingsof the 2007 workshop on Declarative aspects of multicore programming (New York,NY, USA, 2007), ACM Press, pp. 19–24.

[29] MOORE, W., DEAN, D., GERBER, A., WAGENKNECHT, G., AND VANDERHEY-DEN, P. Eclipse Development using the Graphical Editing Framework and the EclipseModeling Framework. IBM redbooks. IBM International Technical Support Organi-zation, Boca Raton, FL, USA, 2004.

[30] OPENARCHITECTUREWARE.ORG. openarchitectureware (oaw) home-page. World Wide Web electronic publication, 2008. http://www.openarchitectureware.org/.

112

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/gef/

http://www.eclipse.org/gmf/

http://www.w3.org/TR/2007/REC-xslt20-20070123/

http://www.w3.org/TR/2007/REC-xslt20-20070123/

http://www.openarchitectureware.org/

http://www.openarchitectureware.org/

Bibliography

[31] RAISER, F. Graph Transformation Systems in CHR. In Logic Programming, 23rdInternational Conference, ICLP 2007 (Porto, Portugal, September 2007), V. Dahl andI. Niemelä, Eds., vol. 4670 of Lecture Notes in Computer Science, Springer, pp. 240–254.

[32] RAISER, F., AND FRÜHWIRTH, T. Strong joinability analysis for graph transforma-tion systems in CHR. In 5th International Workshop on Computing with Terms andGraphs, TERMGRAPH 2009 (2009). accepted.

[33] RENSINK, A. Graphs for object-oriented verification (groove). World Wide Webelectronic publication, 2003. http://groove.cs.utwente.nl/.

[34] RENSINK, A. The GROOVE simulator: A tool for state space generation. In Ap-plications of Graph Transformations with Industrial Relevance (AGTIVE) (2004),J. Pfalz, M. Nagl, and B. Böhlen, Eds., vol. 3062 of Lecture Notes in Computer Sci-ence, Springer, pp. 479–485.

[35] SCHIEDGEN, M. Textual editing framework (tef). World Wide Web elec-tronic publication, 2008. http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html.

[36] SCHRIJVERS, T., AND DEMOEN, B. The K.U.Leuven CHR system: Implementationand application. In First workshop on constraint handling rules: selected contribu-tions (2004), pp. 1–5. Published as technical report: Ulmer Informatik-Berichte Nr.2004-01, http://www/informatik.uni-ulm.de/epin/pw/10481.

[37] SCHRIJVERS, T., AND FRÜHWIRTH, T., Eds. CHR ’05: Proc. 2nd Workshop on Con-straint Handling Rules (Sitges, Spain, 2005), K.U.Leuven, Dept. Comp. Sc., Techni-cal report CW 421.

[38] SCHRIJVERS, T., WIELEMAKER, J., AND DEMOEN, B. Poster: Constraint Han-dling Rules for SWI-Prolog. In Wolf et al. [44]. http://www.informatik.uni-ulm.de/epin/pw/11541.

[39] SNEYERS, J., WEERT, P. V., SCHRIJVERS, T., AND KONINCK, L. D. As time goesby: Constraint Handling Rules – A survey of CHR research between 1998 and 2007.submitted to Journal of Theory and Practice of Logic Programming, 2009.

[40] VAN WEERT, P., SCHRIJVERS, T., AND DEMOEN, B. K.U.Leuven JCHR: a user-friendly, flexible and efficient CHR system for Java. In Schrijvers and Frühwirth [37],pp. 47–62. http://www.cs.kuleuven.be/~petervw/JCHR/.

[41] VELASCO, P. P. P., AND DE LARA, J. Matrix approach to graph transformation:Matching and sequences. In Corradini et al. [7], pp. 122–137.

[42] WEERT, P. V. The k.u.leuven jchr system homepage. World Wide Web electronicpublication, 2008. http://www.cs.kuleuven.be/~petervw/JCHR/.

[43] WEERT, P. V. K.u.leuven jchr user’s manual. World Wide Web electronic publication,2008. Available at [42].

[44] WOLF, A., FRÜHWIRTH, T., AND MEISTER, M., Eds. W(C)LP ’05: Proc. 19thWorkshop on (Constraint) Logic Programming (Universität Ulm, Germany, Feb.2005), vol. 2005-01 of Ulmer Informatik-Berichte. http://www.informatik.uni-ulm.de/epin/pw/11541.

[45] WUILLE, P., SCHRIJVERS, T., AND DEMOEN, B. CCHR: the fastest CHR im-plementation, in C. In Djelloul et al. [9], pp. 123–137. http://www.cs.kuleuven.be/~pieterw/CCHR/.

113

http://groove.cs.utwente.nl/

http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html

http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html

http://www/informatik.uni-ulm.de/epin/pw/10481

http://www.informatik.uni-ulm.de/epin/pw/11541


http://www.cs.kuleuven.be/~petervw/JCHR/

http://www.cs.kuleuven.be/~petervw/JCHR/



http://www.cs.kuleuven.be/~pieterw/CCHR/

http://www.cs.kuleuven.be/~pieterw/CCHR/

Bibliography

114

A Installation guide and CD content

This chapter explains how to install the GTS Editor and its tools in the eclipse platform. Alist of the files and folders on the accompanying Compact Disc (CD) is provided, as well.

A.1 CD content

• src/ – contains the source files of the platform and the plug-ins

• bin/ – contains the binary distribution of the projects that can be installed to eclipse

• lib/ – contains the libraries that are needed to run the K.U. Leuven JCHR compiler

• doc/ – contains the JavaDoc of all the projects

• dist/ – contains a complete eclipse distribution with the platform already inte-grated

• thesis/ – contains this thesis in Portable Document Format (PDF)

A.2 Installation Guide

The installation guide will cover the installation on Linux systems. The installation forMicrosoft Windows based systems is similar, differences are mentioned. Several librariesand plug-ins must be available on the system and in eclipse in order to run the platform.The files that are found in the lib/ folder on the CD must be added to the CLASSPATHsystem variable. Copy all the files to the directory ∼/jchrlib/. Now add the commande x p o r t CLASSPATH=~/ j c h r l i b / a n t l r −2 . 7 . 5 . j a r : \~ / j c h r l i b / a r g s 4 j −2 . 0 . 5 . j a r : \~ / j c h r l i b / KULeuven_JCHR . j a r

to your .bashrc and log in to the system again. The libraries can now be accessedby java. On Microsoft Windows-based systems, the CLASSPATH can be changed in thesystem properties. Now add the KULeuven_JCHR.jar file to the root of the eclipsefolder, so that it is accessible by the eclipse platform.

The dependencies for the GTS platform are GEF, JET, EMF, and TEF. The GEF, EMF,and JET run-time plug-ins can be installed via the update mechanism of eclipse. TEF canbe obtained at [35]. Furthermore, the Plug-in Development Environment (PDE) is neededto create GTS projects. To install the platform with all its tools, copy all Java Archive(JAR) files from the bin/ directory of the CD into the plugins folder of your eclipseinstallation.

When starting eclipse, the new project and file wizards for GTS are available and you canstart creating GTS. Have fun!

For those who do not want to integrate the platform in their eclipse distribution, a distribu-tion for Linux containing all the dependencies can be found in the dist/ folder. Unpackthe file dist.tar to your hard disk and start the eclipse executable. The K.U. Leu-ven JCHR compiler and its dependencies must, of course, still be added to the systemsclasspath.

115

A Installation guide and CD content

116

B Introduction to category Theory

In this appendix, I want to give a short introduction to category theory, because it providesthe theoretical basis for algebraic graph transformation systems. I want to present the basicdefinitions of categories and pushouts and how to construct them. Furthermore, I give someexamples to ease the understanding of category theory when applied to GTS. This appendixis based on [18] which also gives a more detailed explanation of the topic.

B.1 Categories

A category C = (ObjC ,MorC , ◦, id) is a tuple and its elements have the following mean-ing: ObjC is a class of objects. For each tuple A,B ∈MorC there is a set MorC(A,B) ofmorphisms. ◦ is the concatenation of morphisms in MorC . It has the form MorC(B,D)×MorC(A,B) → MorC(A,D). idA ∈ MorC(A,A) is the identity morphism for everyA ∈ ObjC .

For morphisms f ∈ MorC(A,B) the notation f : A → B is used. Furthermore, A iscalled the domain and B the codomain of f . An example of a category would be Sets. Theobjects are sets and functions f : A → B are morphisms. The concatenation (g ◦ f)(x)is given by g(f(x)) and the identity idA : A → A : x 7→ x. The category Graphs canbe constructed component-wise from Sets categories for the nodes and edges of a graph.The morphisms are graph morphisms (see 2.2). The concatenation is the concatenation ofgraph morphisms. The identities are the pairwise identities for nodes and edges.

In addition to that, I want to describe the construction of categories from already existingones. The product category C ×D from two categories C and D is given by

• ObjC×D = ObjC ×ObjD

• MorC×D((A,A′), (B,B′)) = MorC(A,B)×MorD(A′, B)

• for morphisms f : A→ B, g : B → C, and f ′ : A′ → B′, g′ : B′ → C ′ we define(g, g′) ◦ (f, f ′) = (g ◦ f, g′ ◦ f ′)

• id(A,A′) = (idA, idA′)

Another way of creating a category is (co)slicing. A (co)slice category C\X (X\C) of agiven category C consists of the morphisms to (from) a distinguished object X ∈ ObjC

as the Objects. The morphisms in the slice category are morphisms that connect the objectmorphisms. In more detail for slice categories:

• ObjC\X = {f : A→ X|A ∈ ObjC , f ∈MorC(A,X)}

• MorC\X(f : A→ X, g : B → X) = m : A→ B|g ◦m = f

• The concatenation for two morphisms is defined as in the category C

• idf :A→X = idA ∈MorC

Similarly for coslice categories:

117


• ObjX\C = {f : X → A|A ∈ ObjC , f ∈MorC(X, A)}

• MorX\C(f : X → A, g : X → B) = m : A→ B|g ◦m = f

• The concatenation for two morphisms for three objects is defined as in C

• idf :A→X = idA ∈MorC

An example for a slice category is GraphsTG which can be seen as Graphs\TG. Eachtyped graph is presented by its typing morphism and the typed graph morphisms (sec-tion 2.2) are exactly the morphisms in the slice category.

The last category I would like to describe is the dual category Cop. It is given by reversingall morphisms, so MorC(A,B) = MorCop(B,A). For the concatenation, the order ofexecution is reversed in the dual category (because the morphisms are reversed, too). Theidentity morphisms are the same as in C.

B.2 Morphisms

Morphisms in a category C can be of three types: mono-, epi-, and isomorphisms. Amorphism m : B → C is a monomorphism, if for morphisms f, g : A → B ∈ MorC ,it holds that m ◦ f = m ◦ g ⇔ f = g. A morphism e : A → B is an epimorphism,if for morphisms f, g : B → C ∈ MorC , it holds that f ◦ e = g ◦ e ⇔ f = g. Epi-and monomorphisms are dual notions in the respective dual category of each other. Amorphism i : A → B is called an isomorphism if there exists a morphism i−1 : B → Asuch that i−1 ◦ i = idA. Two objects are called isomorphic to each other (A ∼= B), if thereexists an isomorphism between them. If i is an isomorphism, then it is also a mono- and anepimorphism and the inverse morphism of i is unique.

For example in the category Sets the mono- and epimorphisms are the injective and surjec-tive mappings. Therefore, in Graphs and GraphsTG mono- and epimorphisms are thosemorphisms that are injective and surjective, respectively.

B.3 Pushouts

Intuitively, a pushout in category theory is the gluing of two objects along a common object.Here, I want to present the definitions and construction of such pushouts (POs) in specificcategories.

Given f : A → B and g : A → C ∈ MorC , then a pushout (D, f ′, g′) is defined by apushout object D and morphisms f ′ : C → D, g′ : B → D with f ′ ◦ g = g′ ◦ f such thatthe following universal property is fulfilled: For all objects X ∈ ObjC with morphismsh : B → X and k : C → X with k ◦ g = h ◦ f there is a unique morphism x : D → Xsuch that x ◦ g′ = h and x ◦ f ′ = k.

118

B.3 Pushouts

In Sets, the pushout over the moprhisms f : A → B and g : A → C can be constructedas follows: Define the relation f(a) ∼ g(a) for all a ∈ A and let ≡ be the reflexive,symmetric and transitive closure of ∼. [x] = {y ∈ B ] C|x ≡ y} are the equivalenceclasses of the elements in the disjoint union of B and C. Define D = {[x]|x ∈ B ] C}as the set of all equivalence classes of B ] C. Now the pushout can be constructed withf ′(c) = [c] for all c ∈ C and g′(b) = [b] for all b ∈ B. The proof that this is a validpushout can be found in [18]. This pushout construction works analogously for Graphsand GraphsTG for the sets of nodes and edges of the pushout graph. The source andtarget functions of the pushout graph are uniquely determined by the pushout propertiesof the node set. To ease the understanding, I give a short example for the constructionof a pushout in Sets. Given A = {a, b, c, d}, B = {1, 2, 3, 4}, and C = {5, 6, 7, 8}with morphisms f : A → B, f(a) = 1, f(b) = f(c) = 2, f(d) = 3 and g : A →C, g(a) = g(b) = 5, g(c) = 6, g(d) = 7, the relation ∼ yields 1 ∼ 5, 2 ∼ 5, 2 ∼ 6 and3 ∼ 7. Creating the transitive closure leads to 1 ≡ 2 ≡ 5 ≡ 6 and 3 ≡ 7. Therefore,[1] = [2] = [5] = 6 = {1, 2, 5, 6}, [3] = [7] = {3, 7}, [4] = {4} and [8] = {8}. Theresulting pushout object is then D = {[1], [3], [4], [8]}.

119


120

C Source Code

C.1 Example commands

This class implements the command for removing a node from a graph, while keeping themodel consistent.

1 package org . uniu lm . g t s . model . commands ;2 p u b l i c c l a s s NodeDeleteCommand ex tends Command {3 p r i v a t e IGraphModel p a r e n t ;4 p r i v a t e I A b s t r a c t N o d e c h i l d ;5 p r i v a t e L i s t <EdgeDeleteCommand > removedEdges ;6 p r i v a t e L i s t <NodeDeleteCommand > removedTypedNodes ;7 p r i v a t e ITypeNode typeNode ;8

9 p u b l i c NodeDeleteCommand ( I A b s t r a c t N o d e c h i l d ) {10 t h i s . p a r e n t = c h i l d . ge tGraph ( ) ;11 t h i s . c h i l d = c h i l d ;12 s e t L a b e l ( " D e l e t e node " ) ;13 }14 p u b l i c boolean c a n E x e c u t e ( ) {15 re turn p a r e n t != n u l l && c h i l d != n u l l ;16 }17

18 / / f u r t h e r commands are g e n e r a t e d f o r d e l e t i n g a d j a c e n t edges19 p u b l i c vo id e x e c u t e ( ) {20 removedEdges=new L i n k e d L i s t <EdgeDeleteCommand > ( ) ;21 removedTypedNodes=new L i n k e d L i s t <NodeDeleteCommand > ( ) ;22 / / i f t h e d e l e t e d node i s a t y p e node ,23 / / c r e a t e d e l e t e commands f o r a l l t y p e d nodes from i t24 i f ( c h i l d i n s t a n c e o f ITypeNode ) {25 f o r ( I A b s t r a c t N o d e n : ( ( ITypeNode ) c h i l d ) . g e t T y p e s ( ) ) {26 removedTypedNodes . add ( new NodeDeleteCommand ( n ) ) ;27 }28 }29 i f ( c h i l d i n s t a n c e o f INode ) {30 typeNode = ( ( INode ) c h i l d ) . ge tType ( ) ;31 }32 / / c r e a t e d e l e t e commands f o r t h e edges c o n n e c t e d t o t h e node33 f o r ( I A b s t r a c t E d g e e : c h i l d . ge tS rcEdg ( ) ) {34 removedEdges . add ( new EdgeDeleteCommand ( e ) ) ;35

36 }37 f o r ( I A b s t r a c t E d g e e : c h i l d . ge tTg tEdg ( ) ) {38 removedEdges . add ( new EdgeDeleteCommand ( e ) ) ;39 }40 / / e x e c u t e t h e commands41 r edo ( ) ;42 }43

44 p u b l i c vo id r edo ( ) {45 / / f i r s t t h e a d j a c e n t edges are removed46 f o r ( EdgeDeleteCommand e : removedEdges ) {47 i f ( e . c a n E x e c u t e ( ) ) e . e x e c u t e ( ) ;48 }49 / / t h e n t h e t y p e d nodes ( which are now n o t c o n n e c t e d50 / / t o edges anymore )51 i f ( c h i l d i n s t a n c e o f ITypeNode ) {52 f o r ( NodeDeleteCommand n : removedTypedNodes ) {

121

C Source Code

53 i f ( n . c a n E x e c u t e ( ) ) n . e x e c u t e ( ) ;54 }55 }56 / / I f i t i s a t y p e d node , remove i t s c o n n e c t i o n t o57 / / i t s t y p e node58 i f ( c h i l d i n s t a n c e o f INode ) {59 ( ( INode ) c h i l d ) . s e t T y p e ( n u l l ) ;60 }61 / / remove i t from t h e graph62 c h i l d . s e t G r a p h ( n u l l ) ;63 }64

65 p u b l i c vo id undo ( ) {66 / / a l l t h e commands from redo are undone i n r e v e r s e67 / / o r d e r68 c h i l d . s e t G r a p h ( p a r e n t ) ;69 i f ( c h i l d i n s t a n c e o f INode ) {70 ( ( INode ) c h i l d ) . s e t T y p e ( typeNode ) ;71 }72 i f ( c h i l d i n s t a n c e o f ITypeNode ) {73 f o r ( NodeDeleteCommand n : removedTypedNodes ) {74 n . undo ( ) ;75 }76 }77 f o r ( EdgeDeleteCommand e : removedEdges ) {78 e . undo ( ) ;79 }80 }81 }

Listing C.1: The NodeDeleteCommand class

C.2 GTS analysis tool extension point

This appendix contains the definition of the extension point and its interface for GTS anal-ysis tools.

Listing C.2: Definition for the entries in the plugin.xml1 <!ELEMENT e x t e n s i o n ( g t s a n a l y s i s t o o l ) >2 <!ATTLIST e x t e n s i o n3 p o i n t CDATA #REQUIRED4 i d CDATA #IMPLIED5 name CDATA #IMPLIED>6 <!ELEMENT g t s a n a l y s i s t o o l EMPTY>7 <!ATTLIST g t s a n a l y s i s t o o l8 c l a s s CDATA #IMPLIED9 name CDATA #REQUIRED>

10 ∗ c l a s s − The c l a s s t h a t i s l o a d e d when i n v o k i n g11 t h e plug−in , s h o u l d implement IGTSAnalys i sToo l12 ∗ name − t h e name d i s p l a y e d by plug−i n s e l e c t o r s

Listing C.3: Source code of the interface1 package org . uniu lm . g t s . d i a g n o s t i c t o o l s ;2 /∗ ∗3 ∗ T h i s i n t e r f a c e i s used f o r t o o l s t h a t a n a l y z e4 ∗ graph t r a n s f o r m a t i o n s y s t e m s . I t l e t s s e t model ,5 ∗ command s t a c k and f i l e b e i n g worked on , as w e l l6 ∗ as add l i s t e n e r s . Fur thermore t h e r e are methods7 ∗ t h a t l e t s you s e t s e t a c t i v e graphs or graph .8 ∗ e l e m e n t s f o r d i s p l a y p u r p o s e s9 ∗ /

10 p u b l i c i n t e r f a c e IGTSAnalys i sToo l {11 /∗ ∗

122

C.3 CHR analysis tool extension point

12 ∗ s e t s t h e I G r a p h T r a n s f o r m a t i o n S y s t e m model f o r t h i s13 ∗ d i a g n o s t i c t o o l14 ∗ @param model t h e GTS model used15 ∗ /16 p u b l i c vo id se tMode l ( I G r a p h T r a n f o r m a t i o n S y s t e m model ) ;17 /∗ ∗18 ∗ s e t s t h e f i l e which c o n t a i n s t h e model t h a t i s19 ∗ used by t h e e d i t o r20 ∗ @param f i l e t h e f i l e used21 ∗ /22 p u b l i c vo id s e t F i l e ( I F i l e f i l e ) ;23 /∗ ∗24 ∗ add a l i s t e n e r f o r t h i s t o o l25 ∗ @param a t h e l i s t e n e r t o be added26 ∗ /27 p u b l i c vo id a d d C h a n g e L i s t e n e r ( I G T S A n a l y s i s T o o l L i s t e n e r a ) ;28 /∗ ∗29 ∗ removes t h e g i v e n l i s t e n e r from t h i s t o o l30 ∗ @param a t h e l i s t e n e r t o be removed31 ∗ /32 p u b l i c vo id r e m o v e C h a n g e L i s t e n e r ( I G T S A n a l y s i s T o o l L i s t e n e r a ) ;33 /∗ ∗34 ∗ remove a l l l i s t e n e r s35 ∗ /36 p u b l i c vo id r e m o v e A l l L i s t e n e r s ( ) ;37 /∗ ∗38 ∗ s t a r t s t h e t o o l , t h i s method s h o u l d s t a r t v iews ,39 ∗ e d i t o r s and so on . When c a l l i n g a t o o l , make s u r e40 ∗ t o c a l l a l l t h e s e t methods f i r s t41 ∗ /42 p u b l i c vo id r u n A n a l y s i s ( ) ;43 /∗ ∗44 ∗ t h a t s t h e commandstack t h a t s h o u l d be used when45 ∗ m o d i f y i n g t h e model46 ∗ @param cs t h e commandstack t o be used47 ∗ /48 p u b l i c vo id setCommandStack ( CommandStack cs ) ;49 /∗ ∗50 ∗ r e t u r n s t h e c u r r e n t l y s e l e c t e d Graph51 ∗ @return c u r r e n t l y s e l e c t e d graph52 ∗ /53 p u b l i c IGraphModel g e t A c t i v e G r a p h ( ) ;54 /∗ ∗55 ∗ r e t u r n t h e c u r r e n t l y s e l e c t e d e l e m e n t s o f t h e56 ∗ c u r r e n t l y a c t i v e graph i n t h i s t o o l57 ∗ @return c u r r e n t l y s e l e c t e d e l e m e n t s58 ∗ /59 p u b l i c L i s t <GTSElement > g e t A c t i v e S e l e c t i o n ( ) ;60 /∗ ∗61 ∗ S e t t h e s e l e c t e d e l e m e n t s i n t h e g i v e n graph62 ∗ @return c u r r e n t l y s e l e c t e d e l e m e n t s63 ∗ /64 p u b l i c vo id s e t A c t i v e S e l e c t i o n ( IGraphModel m, L i s t <GTSElement > l ) ;65 /∗ ∗66 ∗ a c t i v a t e t h e g i v e n graph i n t h i s t o o l67 ∗ @param m t h e graph t o be shown68 ∗ /69 p u b l i c vo id s e t A c t i v e G r a p h ( IGraphModel m) ;70 }

C.3 CHR analysis tool extension point

This appendix contains the definition of the extension point and its interface for CHR anal-ysis tools.

123

C Source Code

Listing C.4: Definition for the entries in the plugin.xml1 <!ELEMENT e x t e n s i o n ( d i a g n o s t i c t o o l ) >2 <!ATTLIST e x t e n s i o n3 p o i n t CDATA #REQUIRED4 i d CDATA #IMPLIED5 name CDATA #IMPLIED>6 <!ELEMENT c h r a n a l y s i s t o o l EMPTY>7 <!ATTLIST c h r a n a l y s i s t o o l8 c l a s s CDATA #IMPLIED9 name CDATA #REQUIRED>

10 ∗ c l a s s − The c l a s s t h a t i s l o a d e d when i n v o k i n g11 t h e p l u g i n , s h o u l d implement I C h r A n a l y s i s T o o l12 ∗ name − t h e name d i s p l a y e d by p l u g i n s e l e c t o r s

Listing C.5: Source code of the interface1 import j a v a . u t i l . L i s t ;2 import org . e c l i p s e . c o r e . r e s o u r c e s . I F i l e ;3 /∗ ∗4 ∗ I C h r A n a l y z e r l e t s you s t a r t a n a l y s i s o f j c h r f i l e s . I t p r o v i d e s t h e

a d d i t i o n a l c a p a b i l i t y o f add ing i n p u t s t o t h e5 ∗ f i l e f o r a d d i t i o n a l a n a l y s i s . Fur thermore l i s t e n e r s can be added .6 ∗ @author Math ias W a s s e r t h a l7 ∗8 ∗ /9 p u b l i c i n t e r f a c e I C h r A n a l y s i s T o o l {

10 /∗ ∗11 ∗ S e t t h e f i l e which c o n t a i n s t h e j c h r s o u r c e12 ∗ @param f i l e13 ∗ /14 p u b l i c vo id s e t F i l e ( I F i l e f i l e ) ;15 /∗ ∗16 ∗ Command used t o s t a r t t h e a n a l y s i s .17 ∗ /18 p u b l i c vo id r u n C h r A n a l y s i s ( ) ;19 /∗ ∗20 ∗ Add a l i s t e n e r t h a t i s n o t i f i e d abou t s e l e c t e d c o n s t r a i n t s21 ∗ @param l i s t e n e r22 ∗ /23 p u b l i c vo id a d d C h r L i s t e n e r ( I C h r L i s t e n e r l i s t e n e r ) ;24 /∗ ∗25 ∗ Removes t h e g i v e n l i s t e n e r26 ∗ @param l i s t e n e r27 ∗ /28 p u b l i c vo id r e m o v e C h r L i s t e n e r ( I C h r L i s t e n e r l i s t e n e r ) ;29 /∗ ∗30 ∗ method t o add i n p u t t o t h e chr a n a l y s i s . I n p u t i s g i v e n as a l i s t

o f { @link C o n s t r a i n t N o t i f i c a t i o n } s ,31 ∗ c o n t a i n i n g t h e c o n s t r a i n t name , i t s a r i t y and t h e c o n t e n t s o f

t h e v a r i a b l e s .32 ∗ @param l i s t33 ∗ /34 p u b l i c vo id a d d I n p u t ( L i s t < C o n s t r a i n t N o t i f i c a t i o n > l i s t ) ;35 }

C.4 JET Template for JCHR code generation

This appendix lists the JET template for generating JCHR source files from a GTS model.Listing C.6 shows the generation of plain JCHR source. This is used by the CHR basedanalysis tool (section 4.6). This template is trimmed for readability. Therefore, the gener-ated source code is not formattet very nice.

Listing C.6: JET temmplate for JCHR code generation.1 package <c : g e t s e l e c t =" $ j c h r p a c k a g e " / > ;

124

C.4 JET Template for JCHR code generation

2 import r u n t i m e .∗ ;3 import r u n t i m e . p r i m i t i v e .∗ ;4 import u t i l . A r i t h m e t i c s U t i l s ;5 p u b l i c h a n d l e r <c : g e t s e l e c t =" l o w e r c a s e F i r s t ( removeWhi tespace ( $ j c h r h a n d l e r ) ) " / > {6 < f : i n d e n t t e x t =" ">7 p u b l i c c o n s t r a i n t8 <c : i t e r a t e s e l e c t =" $ g t s / typeGraph / nodes " v a r =" t y p e n o d e " d e l i m i t e r =" , ">9 n_<c : g e t s e l e c t =" $ typenode / @iD" / >

10 ( < c : g e t s e l e c t =" $ v a r i a b l e t y p e " / > , i n t )11 </ c : i t e r a t e >12 <c : i f t e s t =" c o u n t ( $ g t s / typeGraph / nodes ) >0 " > , </ c : i f >13 <c : i t e r a t e s e l e c t =" $ g t s / typeGraph / edges " v a r =" t y p e e d g e " d e l i m i t e r =" , ">14 e_ <c : g e t s e l e c t =" $ t y p e e d g e / @iD" / >15 ( i n t , < c : g e t s e l e c t =" $ v a r i a b l e t y p e " / > , < c : g e t s e l e c t =" $ v a r i a b l e t y p e " / > )16 </ c : i t e r a t e >17 <c : i f t e s t =" c o u n t ( $ g t s / typeGraph / nodes ) >0 " > , </ c : i f >18 empty_head ( ) ;19 r u l e s {20 < f : i n d e n t t e x t =" ">21 <c : i f t e s t =" c o u n t ( $ g t s / t r a n s f o r m a t i o n s / nodes [ @trans = ’R ’ ] / @iD) >0 ">22 l o c a l <c : g e t s e l e c t =" $ v a r i a b l e t y p e " / >23 <c : i t e r a t e s e l e c t =" d i s t i n c t−v a l u e s ( $ g t s / t r a n s f o r m a t i o n s / nodes [ @trans = ’R ’ ] / @iD) " v a r

=" i d s " d e l i m i t e r =" , ">24 NN_<c : g e t s e l e c t =" $ i d s " / >25 </ c : i t e r a t e > ;26 </ c : i f >27 <c : i t e r a t e s e l e c t =" r e o r d e r ( $ g t s / t r a n s f o r m a t i o n s , $ o r d e r ) " v a r =" t r a n s ">28 r u l e _ <c : g e t s e l e c t =" t r a n s l a t e ( $ t r a n s / @id , ’ ’ , ’ _ ’ ) " / > @29 <c : i f t e s t =" c o u n t ( $ t r a n s / edges [ @trans = ’L ’ o r @trans = ’K ’ ] | $ t r a n s / nodes [ @trans = ’L ’ o r

@trans = ’K ’ ] ) =0 ">30 empty_head ( )31 </ c : i f >32 <c : i t e r a t e s e l e c t =" $ t r a n s / nodes [ @trans = ’L ’ ] " v a r =" node " d e l i m i t e r =" , ">33 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >34 ( ON_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >35 , <c : g e t s e l e c t =" c o u n t ( $node / s rcEdg [ @trans = ’L ’ ] ) + c o u n t ( $node / t g t E d g [ @trans = ’L ’ ] ) "

/ > )36 </ c : i t e r a t e >37 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’L ’ ] ) >0 and c o u n t ( $ t r a n s / nodes [ @trans = ’K ’ ] ) >0

">38 ,39 </ c : i f >40 <c : i t e r a t e s e l e c t =" $ t r a n s / nodes [ @trans = ’K ’ ] " v a r =" node " d e l i m i t e r =" , ">41 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >42 ( ON_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >43 , NC_<c : g e t s e l e c t =" $node / @iD" / > )44 </ c : i t e r a t e >45 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’K ’ ] | $ t r a n s / nodes [ @trans = ’L ’ ] ) >0 and c o u n t (

$ t r a n s / edges [ @trans = ’L ’ ] ) >0 ">46 ,47 </ c : i f >48 <c : i t e r a t e s e l e c t =" $ t r a n s / edges [ @trans = ’L ’ ] " v a r =" edge " d e l i m i t e r =" , ">49 e_ <c : g e t s e l e c t =" $edge / t y p e / @iD" / >50 ( 0 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / s r c / @iD, ’ ’ , ’ _ ’ ) " / >51 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / t g t / @iD, ’ ’ , ’ _ ’ ) " / > )52 </ c : i t e r a t e >53 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’K ’ ] | $ t r a n s / nodes [ @trans = ’L ’ ] | $ t r a n s / edges [

@trans = ’L ’ ] ) >0 and c o u n t ( $ t r a n s / edges [ @trans = ’K ’ ] ) >0 ">54 ,55 </ c : i f >56 <c : s e t V a r i a b l e v a r =" d e l C n t " s e l e c t =" 0 " / >57 <c : i t e r a t e s e l e c t =" $ t r a n s / edges [ @trans = ’K ’ ] " v a r =" edge " d e l i m i t e r =" , ">58 e_ <c : g e t s e l e c t =" $edge / t y p e / @iD" / >59 ( DEL_<c : g e t s e l e c t =" $ d e l C n t " / >60 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / s r c / @iD, ’ ’ , ’ _ ’ ) " / >61 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / t g t / @iD, ’ ’ , ’ _ ’ ) " / > )62 </ c : i t e r a t e >63 <=>64 <c : i t e r a t e s e l e c t =" $ t r a n s / nodes [ @trans = ’K ’ ] " v a r =" node " d e l i m i t e r =" , ">65 <c : s e t V a r i a b l e v a r =" d i f f "66 s e l e c t ="0−(67 c o u n t ( $node / s rcEdg [ @trans = ’L ’ ] | $node / s rcEdg [ @trans = ’K ’ ] ) +68 c o u n t ( $node / t g t E d g [ @trans = ’L ’ ] | $node / t g t E d g [ @trans = ’K ’ ] ) ) +69 ( c o u n t ( $node / s rcEdg [ @trans = ’R ’ ] | $node / s rcEdg [ @trans = ’K ’ ] ) +70 c o u n t ( $node / t g t E d g [ @trans = ’R ’ ] | $node / t g t E d g [ @trans = ’K ’ ] ) ) " / >71 <c : i f t e s t =" $ d i f f <0 ">72 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >73 ( ON_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >74 , A r i t h m e t i c s U t i l s . sub (NC_<c : g e t s e l e c t =" $node / @iD" / > , < c : g e t s e l e c t ="0−$ d i f f " / > ) )75 </ c : i f >

125

C Source Code

76 <c : i f t e s t =" $ d i f f >0 ">77 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >78 ( ON_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >79 , A r i t h m e t i c s U t i l s . add (NC_<c : g e t s e l e c t =" $node / @iD" / > , < c : g e t s e l e c t =" $ d i f f " / > ) )80 </ c : i f >81 <c : i f t e s t =" $ d i f f =0 ">82 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >83 ( ON_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >84 , NC_<c : g e t s e l e c t =" $node / @iD" / > )85 </ c : i f >86 </ c : i t e r a t e >87 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’K ’ ] ) >0 and c o u n t ( $ t r a n s / nodes [ @trans = ’R ’ ] ) >0

">88 ,89 </ c : i f >90 <c : i t e r a t e s e l e c t =" $ t r a n s / nodes [ @trans = ’R ’ ] " v a r =" node " d e l i m i t e r =" , ">91 n_<c : g e t s e l e c t =" $node / t y p e / @iD" / >92 ( NN_<c : g e t s e l e c t =" t r a n s l a t e ( $node / @iD, ’ ’ , ’ _ ’ ) " / >93 , < c : g e t s e l e c t =" c o u n t ( $node / s rcEdg [ @trans = ’R ’ ] ) + c o u n t ( $node / t g t E d g [ @trans = ’R ’ ] ) "

/ > )94 </ c : i t e r a t e >95 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’R ’ o r @trans = ’K ’ ] ) >0 and c o u n t ( $ t r a n s / edges [

@trans = ’R ’ ] ) >0 ">96 ,97 </ c : i f >98 <c : i t e r a t e s e l e c t =" $ t r a n s / edges [ @trans = ’R ’ ] " v a r =" edge " d e l i m i t e r =" , ">99 e_ <c : g e t s e l e c t =" $edge / t y p e / @iD" / >

100 ( 0 , <c : i f t e s t =" $edge / s r c / @trans = ’R ’ ">NN_</ c : i f >101 <c : i f t e s t =" $edge / s r c / @trans = ’K’ ">ON_</ c : i f >102 <c : g e t s e l e c t =" t r a n s l a t e ( $edge / s r c / @iD, ’ ’ , ’ _ ’ ) " / >103 , <c : i f t e s t =" $edge / t g t / @trans = ’R ’ ">NN_</ c : i f >104 <c : i f t e s t =" $edge / t g t / @trans = ’K’ ">ON_</ c : i f >105 <c : g e t s e l e c t =" t r a n s l a t e ( $edge / t g t / @iD, ’ ’ , ’ _ ’ ) " / > )106 </ c : i t e r a t e >107 <c : i f t e s t =" c o u n t ( $ t r a n s / nodes [ @trans = ’K ’ ] | $ t r a n s / nodes [ @trans = ’R ’ ] | $ t r a n s / edges [

@trans = ’R ’ ] ) >0 and c o u n t ( $ t r a n s / edges [ @trans = ’K ’ ] ) >0 ">108 ,109 </ c : i f >110 <c : s e t V a r i a b l e v a r =" d e l C n t " s e l e c t =" 0 " / >111 <c : i t e r a t e s e l e c t =" $ t r a n s / edges [ @trans = ’K ’ ] " v a r =" edge " d e l i m i t e r =" , ">112 e_ <c : g e t s e l e c t =" $edge / t y p e / @iD" / >113 ( DEL_<c : g e t s e l e c t =" $ d e l C n t " / >114 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / s r c / @iD, ’ ’ , ’ _ ’ ) " / >115 , ON_<c : g e t s e l e c t =" t r a n s l a t e ( $edge / t g t / @iD, ’ ’ , ’ _ ’ ) " / > )116 </ c : i t e r a t e >117 <c : i f t e s t =" c o u n t ( $ t r a n s / edges [ @trans = ’R ’ o r @trans = ’K ’ ] |118 $ t r a n s / nodes [ @trans = ’R ’ o r @trans = ’K ’ ] ) >0119 and c o u n t ( $ t r a n s / edges [ @trans = ’L ’ o r @trans = ’K ’ ] |120 $ t r a n s / nodes [ @trans = ’L ’ o r @trans = ’K ’ ] ) =0 ">121 ,122 </ c : i f >123 <c : i f t e s t =" c o u n t ( $ t r a n s / edges [ @trans = ’L ’ o r @trans = ’K ’ ] |124 $ t r a n s / nodes [ @trans = ’L ’ o r @trans = ’K ’ ] ) =0 ">125 empty_head ( )126 </ c : i f >127 <c : i f t e s t =" c o u n t ( $ t r a n s / edges [ @trans = ’L ’ o r @trans = ’K ’ ] |128 $ t r a n s / nodes [ @trans = ’L ’ o r @trans = ’K ’ ] ) >0129 and c o u n t ( $ t r a n s / edges [ @trans = ’R ’ o r @trans = ’K ’ ] |130 $ t r a n s / nodes [ @trans = ’R ’ o r @trans = ’K ’ ] ) =0 ">131 t rue132 </ c : i f >133 .134 </ c : i t e r a t e >135 </ f : i n d e n t >136 }137 </ f : i n d e n t >138 }

C.5 CHR editor validity and update algorithm

This Appendix lists the algorithm for updating a rule graph from a given CHR model. Thefirst part checks the validity of the encoding, the second part updates the rule graph model.

126


Listing C.7: Algorithm for checking the validity of rules and applying the correspondingupdates to the rule graph.

1 p r o t e c t e d boolean u p d a t e T r a n s f o r m a t i o n M o d e l (CHR c h r ) {2 n o t i f y = f a l s e ;3 / / f i r s t t h e t y p e graph and r u l e graph model are p u t i n t o hash maps4 / / hashmaps f o r t y p e n o d e s and t y p e e d g e s5 HashMap< S t r i n g , I A b s t r a c t N o d e > t y p e n o d e s =6 new HashMap< S t r i n g , I A b s t r a c t N o d e > ( ) ;7 HashMap< S t r i n g , I A b s t r a c t E d g e > t y p e e d g e s =8 new HashMap< S t r i n g , I A b s t r a c t E d g e > ( ) ;9 ITypeGraphModel t g = ( ( ITypedGraphModel ) model ) . ge tTypeGraph ( ) ;

10 f o r ( I A b s t r a c t E d g e e : t g . g e t E d g e s ( ) )11 i f ( e i n s t a n c e o f ITypeEdge )12 t y p e e d g e s . p u t ( ( ( ITypeEdge ) e ) . ge t ID ( ) , e ) ;13 f o r ( I A b s t r a c t N o d e n : t g . ge tNodes ( ) )14 i f ( n i n s t a n c e o f ITypeNode )15 t y p e n o d e s . p u t ( ( ( ITypeNode ) n ) . ge t ID ( ) , n ) ;16

17 I G r a p h T r a n s f o r m a t i o n g t = ( I G r a p h T r a n s f o r m a t i o n ) model ;18 / / hashmaps f o r nodes and egges o f t h e model19 / / nodes20 HashMap< S t r i n g , ITransformNode > nodesL = new HashMap< S t r i n g , ITransformNode > ( ) ;21 HashMap< S t r i n g , ITransformNode > nodesK = new HashMap< S t r i n g , ITransformNode > ( ) ;22 HashMap< S t r i n g , ITransformNode > nodesR = new HashMap< S t r i n g , ITransformNode > ( ) ;23 HashMap< S t r i n g , ITypeNode > nodeTypes = new HashMap< S t r i n g , ITypeNode > ( ) ;24 HashMap< S t r i n g , TransformElementType > nodeTrans = new HashMap< S t r i n g ,

TransformElementType > ( ) ;25 HashMap< S t r i n g , I n t e g e r > nodeDegreeExpr =new HashMap< S t r i n g , I n t e g e r > ( ) ;26 f o r ( I A b s t r a c t N o d e t n : g t . ge tNodes ( ) ) {27 i f ( t n i n s t a n c e o f ITransformNode )28 sw i t ch ( ( ( ITransformNode ) t n ) . g e t T r a n s ( ) . g e t V a l u e ( ) ) {29 case TransformElementType .K_VALUE: nodesK . p u t ( t n . ge t ID ( ) , ( ITransformNode ) t n ) ; break

;30 case TransformElementType . L_VALUE: nodesL . p u t ( t n . ge t ID ( ) , ( ITransformNode ) t n ) ; break

;31 case TransformElementType . R_VALUE: nodesR . p u t ( t n . ge t ID ( ) , ( ITransformNode ) t n ) ; break

;32 }33 nodeTypes . p u t ( ( ( ITransformNode ) t n ) . ge t ID ( ) , ( ( ITransformNode ) t n ) . ge tType ( ) ) ;34 nodeTrans . p u t ( ( ( ITransformNode ) t n ) . ge t ID ( ) , ( ( ITransformNode ) t n ) . g e t T r a n s ( ) ) ;35 }36 / / edges37 MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t < ITransformEdge >>

edgesL = new MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t <ITransformEdge > >() ;

38 MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t < ITransformEdge >>edgesK = new MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t <ITransformEdge > >() ;

39 MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t < ITransformEdge >>edgesR = new MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t <ITransformEdge > >() ;

40

41 HashMap< ITransformEdge , ITypeEdge > edgeTypes = new HashMap< ITransformEdge , ITypeEdge> ( ) ;

42 HashMap< ITransformEdge , S t r i n g > edgeSrc = new HashMap< ITransformEdge , S t r i n g > ( ) ;43 HashMap< ITransformEdge , S t r i n g > edgeTgt = new HashMap< ITransformEdge , S t r i n g > ( ) ;44 HashMap< ITransformEdge , TransformElementType > edgeTrans = new HashMap< ITransformEdge ,

TransformElementType > ( ) ;45

46 f o r ( I A b s t r a c t E d g e e : g t . g e t E d g e s ( ) ) {47 i f ( e i n s t a n c e o f ITrans fo rmEdge ) {48 ITransformNode s r c =( ITransformNode ) e . g e t S r c ( ) , t g t =( ITransformNode ) e . g e t T g t ( ) ;49 ITypeEdge t y p e = ( ( ITrans fo rmEdge ) e ) . ge tType ( ) ;50 sw i t ch ( ( ( ITrans fo rmEdge ) e ) . g e t T r a n s ( ) . g e t V a l u e ( ) ) {51 case TransformElementType .K_VALUE:52 i f ( ! edgesK . c o n t a i n s K e y ( s r c , t g t , t y p e ) )53 edgesK . p u t ( s r c , t g t , type , new L i n k e d L i s t < ITransformEdge > ( ) ) ;54 edgesK . g e t ( s r c , t g t , t y p e ) . add ( ( ITrans fo rmEdge ) e ) ;55 break ;56 case TransformElementType . L_VALUE:57 i f ( ! edgesL . c o n t a i n s K e y ( s r c , t g t , t y p e ) )58 edgesL . p u t ( s r c , t g t , type , new L i n k e d L i s t < ITransformEdge > ( ) ) ;59 edgesL . g e t ( s r c , t g t , t y p e ) . add ( ( ITrans fo rmEdge ) e ) ;60 break ;61 case TransformElementType . R_VALUE:62 i f ( ! edgesR . c o n t a i n s K e y ( s r c , t g t , t y p e ) )63 edgesR . p u t ( s r c , t g t , type , new L i n k e d L i s t < ITransformEdge > ( ) ) ;64 edgesR . g e t ( s r c , t g t , t y p e ) . add ( ( ITrans fo rmEdge ) e ) ;

127

C Source Code

65 break ;66 }67 edgeSrc . p u t ( ( ITrans fo rmEdge ) e , e . g e t S r c ( ) . ge t ID ( ) ) ;68 edgeTgt . p u t ( ( ITrans fo rmEdge ) e , e . g e t T g t ( ) . ge t ID ( ) ) ;69 edgeTypes . p u t ( ( ITrans fo rmEdge ) e , ( ( ITrans fo rmEdge ) e ) . ge tType ( ) ) ;70 }71 }72

73 i f ( c h r . g e t R u l e ( ) . s i z e ( ) ! = 1 ) re turn f a l s e ;74 / / CHR program i s encoded i n hashmaps75 HashMap< C o n s t r a i n t , S t r i n g > e r r o r s =new HashMap< C o n s t r a i n t , S t r i n g > ( ) ;76

77 / / save a l l c o n s t r a i n t s i n a s e t78 Set < C o n s t r a i n t > c o n s t r a i n t S e t = new HashSet < C o n s t r a i n t > ( ) ;79 f o r ( C o n s t r a i n t c : ( ( PropRule ) c h r . g e t R u l e ( ) . g e t ( 0 ) ) . ge tHead ( ) ) c o n s t r a i n t S e t . add ( c ) ;80 f o r ( C o n s t r a i n t c : ( ( PropRule ) c h r . g e t R u l e ( ) . g e t ( 0 ) ) . getBody ( ) ) c o n s t r a i n t S e t . add ( c ) ;81 HashMap< S t r i n g , C o n s t r a i n t > n o d e C o n s t r a i n t s L = new HashMap< S t r i n g , C o n s t r a i n t > ( ) ;82 HashMap< S t r i n g , C o n s t r a i n t > n o d e C o n s t r a i n t s K = new HashMap< S t r i n g , C o n s t r a i n t > ( ) ;83 HashMap< S t r i n g , C o n s t r a i n t > n o d e C o n s t r a i n t s R = new HashMap< S t r i n g , C o n s t r a i n t > ( ) ;84 HashMap< S t r i n g , I n t e g e r > nodeEdgeCount=new HashMap< S t r i n g , I n t e g e r > ( ) ;85

86 / / Mult iHashMaps f o r t h e edge c o n s t r a i n t s87 MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t >> e d g e C o n s t r a i n t s L = new

MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t > >() ;88 MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t >> e d g e C o n s t r a i n t s K = new

MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t > >() ;89 MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t >> e d g e C o n s t r a i n t s R = new

MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t > >() ;90 Set < S t r i n g > edgeDelVars =new HashSet < S t r i n g > ( ) ;91 / / p u t t h e c o n s t r a i n t s i n t o t h e groups L , R and K92 / / p r o c e s s h e a d c o n s t r a i n t s f i r s t93 f o r ( C o n s t r a i n t c : ( ( PropRule ) c h r . g e t R u l e ( ) . g e t ( 0 ) ) . ge tHead ( ) ) {94 / / f i l t e r e r r o r s i n c o n s t r a i n t s ( e . g . m u l t i p l e i d e n t i f i e r s )95 / / node c o n s t r a i n t s96 i f ( ( s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==197 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l98 | | ! s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==299 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l )

100 && c . ge tType ( ) != n u l l101 && t y p e n o d e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) ) ) {102 S t r i n g i d = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;103 i f ( ! n o d e C o n s t r a i n t s L . c o n t a i n s K e y ( i d ) ) {104 n o d e C o n s t r a i n t s L . p u t ( id , c ) ;105 i f ( ! nodeEdgeCount . c o n t a i n s K e y ( i d ) )106 nodeEdgeCount . p u t ( id , 0 ) ;107 c o n s t r a i n t S e t . remove ( c ) ;108 } e l s e {109 e r r o r s . p u t ( c , " d u p l i c a t e node i d e n t i f i e r " ) ;110 c o n t i n u e ;111 }112 / / edge c o n s t r a i n t s113 } e l s e i f ( s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==2114 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l115 && c . g e t V a r i a b l e s ( ) . g e t ( 1 ) i n s t a n c e o f L i t e r a l116 && c . ge tType ( ) != n u l l117 && t y p e e d g e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) )118 | | ! s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==3119 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l120 && c . g e t V a r i a b l e s ( ) . g e t ( 1 ) i n s t a n c e o f L i t e r a l121 && c . g e t V a r i a b l e s ( ) . g e t ( 2 ) i n s t a n c e o f L i t e r a l && c . ge tType ( ) != n u l l122 && t y p e e d g e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) ) ) {123 S t r i n g s r c , t g t ;124 i n t s h i f t = s i m p l e ? 0 : 1 ; / / d i f f e r e n t p o s i t i o n s when i n s i m p l e mode125 s r c = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t (0+ s h i f t ) ) . g e t V a l u e ( ) ;126 t g t = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t (1+ s h i f t ) ) . g e t V a l u e ( ) ;127 S t r i n g t y p e =c . ge tType ( ) . getName ( ) ;128 i f ( ! s i m p l e && C h a r a c t e r . i sUppe rCase ( ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) .

c ha rA t ( 0 ) ) ) {129 i f ( ! e d g e C o n s t r a i n t s L . c o n t a i n s K e y ( s r c , t g t , t y p e ) )130 e d g e C o n s t r a i n t s L . p u t ( s r c , t g t , type , new L i n k e d L i s t < C o n s t r a i n t > ( ) ) ;131 e d g e C o n s t r a i n t s L . g e t ( s r c , t g t , t y p e ) . add ( c ) ;132 } e l s e {133 i f ( ! e d g e C o n s t r a i n t s L . c o n t a i n s K e y ( s r c , t g t , t y p e ) )134 e d g e C o n s t r a i n t s L . p u t ( s r c , t g t , type , new L i n k e d L i s t < C o n s t r a i n t > ( ) ) ;135 e d g e C o n s t r a i n t s L . g e t ( s r c , t g t , t y p e ) . add ( c ) ;136 }137 i f ( nodeEdgeCount . c o n t a i n s K e y ( s r c ) ) nodeEdgeCount . p u t ( s r c , nodeEdgeCount . g e t ( s r c )

−1) ;138 e l s e nodeEdgeCount . p u t ( s r c , −1) ;

128


139 i f ( nodeEdgeCount . c o n t a i n s K e y ( t g t ) ) nodeEdgeCount . p u t ( t g t , nodeEdgeCount . g e t ( t g t )−1) ;

140 e l s e nodeEdgeCount . p u t ( t g t , −1) ;141 c o n s t r a i n t S e t . remove ( c ) ;142 } e l s e {143 e r r o r s . p u t ( c , " I n v a l i d C o n s t r a i n t " ) ;144 c o n t in u e ;145 }146 }147

148 / / p r o c e s s body c o n s t r a i n t s149 f o r ( C o n s t r a i n t c : ( ( PropRule ) c h r . g e t R u l e ( ) . g e t ( 0 ) ) . getBody ( ) ) {150 / / f i l t e r e r r o r s ( wrong v a r i a b l e names f o r a t t r i b u t e s , d u p l i c a t e e n t r i e s , o c c u r e n c e

o f v a r i a b l e s t h a t s h o u l d n o t be t h e r e ,151 / / m u l t i p l e d e l e t i o n v a r i a b l e s )152 / / node c o n s t r a i n t s153 i f ( s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==1154 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l155 && c . ge tType ( ) != n u l l156 && t y p e n o d e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) )157 | | ! s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==2158 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f L i t e r a l159 && c . ge tType ( ) != n u l l && t y p e n o d e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) ) ) {160 S t r i n g i d = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;161 i f ( n o d e C o n s t r a i n t s L . c o n t a i n s K e y ( i d ) ) {162 i f ( ! s i m p l e ) {163 L i s t < L i t e r a l > lL=new L i n k e d L i s t < L i t e r a l > ( ) , lR=new L i n k e d L i s t < L i t e r a l > ( ) ;164 g e t L i t e r a l ( n o d e C o n s t r a i n t s L . g e t ( i d ) . g e t V a r i a b l e s ( ) . g e t ( 1 ) , lL ) ;165 g e t L i t e r a l ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) , lR ) ;166 i f ( lR . s i z e ( ) !=1 | | lL . s i z e ( ) !=1 | | ! lR . g e t ( 0 ) . g e t V a l u e ( ) . e q u a l s ( lL . g e t ( 0 ) .

g e t V a l u e ( ) ) ) {167 e r r o r s . p u t ( c , " C o n s t r a i n t s i n head and body must s h a r e t h e same V a r i a b l e i n t h e

second a t t r i b u t e " ) ;168 c o n t in u e ;169 }170 nodeDegreeExpr . p u t ( id , e v a l E x p r e s s i o n ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) ) ) ;171 }172 n o d e C o n s t r a i n t s K . p u t ( id , n o d e C o n s t r a i n t s L . remove ( i d ) ) ;173 c o n s t r a i n t S e t . remove ( c ) ;174 } e l s e {175 i f ( n o d e C o n s t r a i n t s R . c o n t a i n s K e y ( i d ) ) {176 e r r o r s . p u t ( c , " D u p l i c a t e node e n t r y i n body " ) ;177 c o n t in u e ;178 }179 i f ( ! s i m p l e ) {180 L i s t < L i t e r a l > l i t =new L i n k e d L i s t < L i t e r a l > ( ) ;181 g e t L i t e r a l ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) , l i t ) ;182 i f ( l i t . s i z e ( ) ! = 0 ) {183 e r r o r s . p u t ( c , " Second a t t r i b u t e must n o t c o n t a i n v a r i a b l e s " ) ;184 c o n t in u e ;185 }186 }187 n o d e C o n s t r a i n t s R . p u t ( id , c ) ;188 i f ( ! nodeEdgeCount . c o n t a i n s K e y ( i d ) )189 nodeEdgeCount . p u t ( id , 0 ) ;190 c o n s t r a i n t S e t . remove ( c ) ;191 }192 }193 / / edge c o n s t r a i n t s194 e l s e i f ( s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==2 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f

L i t e r a l195 && c . g e t V a r i a b l e s ( ) . g e t ( 1 ) i n s t a n c e o f L i t e r a l && c . ge tType ( ) != n u l l196 && t y p e e d g e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) )197 | | ! s i m p l e && c . g e t V a r i a b l e s ( ) . s i z e ( ) ==3 && c . g e t V a r i a b l e s ( ) . g e t ( 0 ) i n s t a n c e o f

L i t e r a l198 && c . g e t V a r i a b l e s ( ) . g e t ( 1 ) i n s t a n c e o f L i t e r a l && c . g e t V a r i a b l e s ( ) . g e t ( 2 )

i n s t a n c e o f L i t e r a l && c . ge tType ( ) != n u l l199 && t y p e e d g e s . c o n t a i n s K e y ( c . ge tType ( ) . getName ( ) ) ) {200 i n t s h i f t = s i m p l e ? 0 : 1 ;201 S t r i n g s r c = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t (0+ s h i f t ) ) . g e t V a l u e ( ) ;202 S t r i n g t g t = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t (1+ s h i f t ) ) . g e t V a l u e ( ) ;203 S t r i n g t y p e =c . ge tType ( ) . getName ( ) ;204

205 i f ( e d g e C o n s t r a i n t s L . c o n t a i n s K e y ( s r c , t g t , t y p e ) && e d g e C o n s t r a i n t s L . g e t ( s r c , t g t , t y p e) . s i z e ( ) >0) {

206

207 i n t edg =0;208 i f ( ! s i m p l e ) {209

210 S t r i n g d e l = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;

129

C Source Code

211 i f ( edgeDelVars . c o n t a i n s ( d e l ) ) {212 e r r o r s . p u t ( c , " D e l e t e v a r i a b l e was used a l r e a d y " ) ;213 c o n t in u e ;214 }215 i f ( d e l . l e n g t h ( ) ==0 | | C h a r a c t e r . i sLowerCase ( d e l . ch a rA t ( 0 ) ) ) {216 e r r o r s . p u t ( c , " F i r s t a t t r i b u t e must n o t be a ground te rm " ) ;217 c o n t in u e ;218 }219 edg=−1;220 i n t c n t =−1;221 f o r ( C o n s t r a i n t ch : e d g e C o n s t r a i n t s L . g e t ( s r c , t g t , t y p e ) ) {222 c n t ++;223 i f ( ( ( L i t e r a l ) ch . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) . e q u a l s ( d e l ) ) {224 edg= c n t ;225 }226 }227 i f ( edg==−1){228 e r r o r s . p u t ( c , " There i s no edge c o n s t r a i n t i n t h e head wi th t h e same d e l

v a r i a b l e " ) ;229 c o n t in u e ;230 }231 edgeDelVars . add ( d e l ) ;232 }233 i f ( ! e d g e C o n s t r a i n t s K . c o n t a i n s K e y ( s r c , t g t , t y p e ) ) {234 e d g e C o n s t r a i n t s K . p u t ( s r c , t g t , type , new L i n k e d L i s t < C o n s t r a i n t > ( ) ) ;235 }236 e d g e C o n s t r a i n t s K . g e t ( s r c , t g t , t y p e ) . add ( e d g e C o n s t r a i n t s L . g e t ( s r c , t g t , t y p e ) . remove (

edg ) ) ;237 i f ( nodeEdgeCount . c o n t a i n s K e y ( s r c ) ) nodeEdgeCount . p u t ( s r c , nodeEdgeCount . g e t ( s r c )

+1) ;238 e l s e nodeEdgeCount . p u t ( s r c , 1 ) ;239 i f ( nodeEdgeCount . c o n t a i n s K e y ( t g t ) ) nodeEdgeCount . p u t ( t g t , nodeEdgeCount . g e t ( t g t )

+1) ;240 e l s e nodeEdgeCount . p u t ( t g t , 1 ) ;241 c o n s t r a i n t S e t . remove ( c ) ;242 } e l s e {243 i f ( ! e d g e C o n s t r a i n t s R . c o n t a i n s K e y ( s r c , t g t , t y p e ) )244 e d g e C o n s t r a i n t s R . p u t ( s r c , t g t , type , new L i n k e d L i s t < C o n s t r a i n t > ( ) ) ;245 e d g e C o n s t r a i n t s R . g e t ( s r c , t g t , t y p e ) . add ( c ) ;246 i f ( nodeEdgeCount . c o n t a i n s K e y ( s r c ) ) nodeEdgeCount . p u t ( s r c , nodeEdgeCount . g e t ( s r c )

+1) ;247 e l s e nodeEdgeCount . p u t ( s r c , +1) ;248 i f ( nodeEdgeCount . c o n t a i n s K e y ( t g t ) ) nodeEdgeCount . p u t ( t g t , nodeEdgeCount . g e t ( t g t )

+1) ;249 e l s e nodeEdgeCount . p u t ( t g t , +1) ;250 c o n s t r a i n t S e t . remove ( c ) ;251 }252 } e l s e {253 e r r o r s . p u t ( c , " I n v a l i d C o n s t r a i n t " ) ;254 c o n t in u e ;255 }256 }257

258 / / i n complex mode edge c o n s t r a i n t s must n o t c o n t a i n v a r i a b l e s i f t h e y are i n L \ K orR \ K

259 i f ( ! s i m p l e && c o n s t r a i n t S e t . s i z e ( ) ==0)260 f o r ( C o n s t r a i n t c : n o d e C o n s t r a i n t s L . v a l u e s ( ) ) {261 L i s t < L i t e r a l > l i t =new L i n k e d L i s t < L i t e r a l > ( ) ;262 g e t L i t e r a l ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) , l i t ) ;263 i f ( l i t . s i z e ( ) ! = 0 ) {264 e r r o r s . p u t ( c , " Second a t t r i b u t e must n o t c o n t a i n v a r i a b l e " ) ;265 c o n s t r a i n t S e t . add ( c ) ;266 c o n t in u e ;267 }268 }269

270 / / check i f edges are c o n n e c t e d t o t h e c o r r e c t nodes ( a c c o r d i n g t o t h e i r t y p e edge ) ,and t h e c o r r e c t group ( L , K or R )

271 f o r ( i n t i =0 ; i <3 ; i ++) {272 i f ( c o n s t r a i n t S e t . s i z e ( ) >0) break ;273 HashMap< S t r i n g , HashMap< S t r i n g , HashMap< S t r i n g , L i s t < C o n s t r a i n t >>>> map= n u l l ;274 sw i t ch ( i ) {275 case 0 : map= e d g e C o n s t r a i n t s L . getMap ( ) ; break ;276 case 1 : map= e d g e C o n s t r a i n t s K . getMap ( ) ; break ;277 case 2 : map= e d g e C o n s t r a i n t s R . getMap ( ) ; break ;278 }279

280 f o r ( S t r i n g s r c : map . ke yS e t ( ) )281 f o r ( S t r i n g t g t : map . g e t ( s r c ) . ke yS e t ( ) )282 f o r ( S t r i n g t y p e : map . g e t ( s r c ) . g e t ( t g t ) . ke yS e t ( ) )

130


283 f o r ( C o n s t r a i n t c : map . g e t ( s r c ) . g e t ( t g t ) . g e t ( t y p e ) ) {284 / / check t o which group i t b e l o n g s ( L , R , K)285 C o n s t r a i n t s r c c = nul l , t g t c = n u l l ;286 i f ( i ==0 && n o d e C o n s t r a i n t s L . c o n t a i n s K e y ( s r c ) )287 s r c c = n o d e C o n s t r a i n t s L . g e t ( s r c ) ;288 i f ( n o d e C o n s t r a i n t s K . c o n t a i n s K e y ( s r c ) )289 s r c c = n o d e C o n s t r a i n t s K . g e t ( s r c ) ;290 i f ( i ==2 && n o d e C o n s t r a i n t s R . c o n t a i n s K e y ( s r c ) )291 s r c c = n o d e C o n s t r a i n t s R . g e t ( s r c ) ;292 i f ( i ==0 && n o d e C o n s t r a i n t s L . c o n t a i n s K e y ( t g t ) )293 t g t c = n o d e C o n s t r a i n t s L . g e t ( t g t ) ;294 i f ( n o d e C o n s t r a i n t s K . c o n t a i n s K e y ( t g t ) )295 t g t c = n o d e C o n s t r a i n t s K . g e t ( t g t ) ;296 i f ( i ==2 && n o d e C o n s t r a i n t s R . c o n t a i n s K e y ( t g t ) )297 t g t c = n o d e C o n s t r a i n t s R . g e t ( t g t ) ;298 i f ( s r c c == n u l l ) {299 e r r o r s . p u t ( c , " c o u l d n o t f i n d a v a l i d s o u r c e node c o n s t r a i n t " ) ;300 c o n s t r a i n t S e t . add ( c ) ;301 c o n t in u e ;302 }303 i f ( t g t c == n u l l ) {304 e r r o r s . p u t ( c , " c o u l d n o t f i n d a v a l i d t a r g e t node c o n s t r a i n t " ) ;305 c o n s t r a i n t S e t . add ( c ) ;306 c o n t in u e ;307 }308 ITypeEdge t e = ( ITypeEdge ) t y p e e d g e s . g e t ( c . ge tType ( ) . getName ( ) ) ;309 ITypeNode t n s r c = ( ITypeNode ) t y p e n o d e s . g e t ( s r c c . ge tType ( ) . getName ( ) ) ;310 ITypeNode t n t g t = ( ITypeNode ) t y p e n o d e s . g e t ( t g t c . ge tType ( ) . getName ( ) ) ;311 i f ( t n s r c != t e . g e t S r c ( ) ) {312 e r r o r s . p u t ( c , " Type o f s o u r c e node i n c o r r e c t " ) ;313 c o n s t r a i n t S e t . add ( c ) ;314 c o n t in u e ;315 }316 i f ( t n t g t != t e . g e t T g t ( ) ) {317 e r r o r s . p u t ( c , " Type of t a r g e t node i n c o r r e c t " ) ;318 c o n s t r a i n t S e t . add ( c ) ;319 c o n t in u e ;320 }321

322 }323 }324 / / complex mode : check i f t h e d e l and c o u n t a t t r i b u t e i s c o r r e c t l y s e t ground or

v a r i a b l e325 i f ( ! s i m p l e && c o n s t r a i n t S e t . s i z e ( ) ==0) {326 / / check h o s t nodes ( he re t h e a t t r i b u t e must be ground )327 f o r ( i n t i =0 ; i <2 ; i ++) {328 / / check edges ( d e l )329 MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t >> map= n u l l ;330 sw i t ch ( i ) {331 case 0 : map= e d g e C o n s t r a i n t s L ; break ;332 case 1 : map= e d g e C o n s t r a i n t s R ; break ;333 }334 f o r ( L i s t < C o n s t r a i n t > l : map . v a l u e s ( ) )335 f o r ( C o n s t r a i n t c : l ) {336 S t r i n g d e l = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;337 i f ( d e l . l e n g t h ( ) ==0 | | C h a r a c t e r . i sUppe rCase ( d e l . ch a rA t ( 0 ) ) ) {338 e r r o r s . p u t ( c , " D e l e t i o n argument must be ground " ) ;339 c o n s t r a i n t S e t . add ( c ) ;340 c o n t in u e ;341 }342

343 }344

345 / / check nodes ( c o u n t )346 HashMap< S t r i n g , C o n s t r a i n t > nmap= n u l l ;347 sw i t ch ( i ) {348 case 0 : nmap= n o d e C o n s t r a i n t s L ; break ;349 case 1 : nmap= n o d e C o n s t r a i n t s R ; break ;350 }351 f o r ( C o n s t r a i n t c : nmap . v a l u e s ( ) ) {352 i f ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) i n s t a n c e o f Numeral ) {353 i n t c n t = ( ( Numeral ) c . g e t V a r i a b l e s ( ) . g e t ( 1 ) ) . g e t V a l u e ( ) ;354 S t r i n g i d = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;355

356 i f ( ! nodeEdgeCount . c o n t a i n s K e y ( i d ) | | Math . abs ( nodeEdgeCount . g e t ( i d ) ) != c n t ) {357 e r r o r s . p u t ( c , " second a t t r i b u t e must be a number and r e p r e s e n t t h e number o f

edges on t h i s node " ) ;358 c o n s t r a i n t S e t . add ( c ) ;359 c o n t in u e ;360 }

131

C Source Code

361 }362 }363 }364 / / check t h e edge c o n s t r a i n t s t h a t are k e p t ( i n group K) , he re t h e d e l a t t r i b u t e

must be v a r i a b l e365 f o r ( L i s t < C o n s t r a i n t > l : e d g e C o n s t r a i n t s K . v a l u e s ( ) ) {366 f o r ( C o n s t r a i n t c : l ) {367 S t r i n g d e l = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;368 i f ( d e l . l e n g t h ( ) ==0 | | C h a r a c t e r . i sLowerCase ( d e l . ch a rA t ( 0 ) ) ) {369 e r r o r s . p u t ( c , " D e l e t i o n argument must be a v a r i a b l e " ) ;370 c o n s t r a i n t S e t . add ( c ) ;371 c o n t in u e ;372 }373 }374 }375 / / check t h e node c o n s t r a i n t s t h a t are k e p t ( i n group K) , he re t h e c o u n t a t t r i b u t e

must c o n t a i n a v a r i a b l e376 f o r ( C o n s t r a i n t c : n o d e C o n s t r a i n t s K . v a l u e s ( ) ) {377

378 i n t c n t = nodeDegreeExpr . g e t ( ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) )−e v a l E x p r e s s i o n ( c . g e t V a r i a b l e s ( ) . g e t ( 1 ) ) ;

379 S t r i n g i d = ( ( L i t e r a l ) c . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ;380 i n t c n t 2 =0; / / =1000;381 i f ( nodeEdgeCount . c o n t a i n s K e y ( i d ) ) c n t 2 =nodeEdgeCount . g e t ( i d ) ;382 i f ( ! nodeEdgeCount . c o n t a i n s K e y ( i d ) | | c n t 2 != c n t ) {383 e r r o r s . p u t ( c , " second a t t r i b u t e must be a E x p r e s s i o n wi th one V a r i a b l e and

r e p r e s e n t t h e d i f f e r e n t number o f edges " ) ;384 c o n s t r a i n t S e t . add ( c ) ;385 c o n t i n u e ;386

387 }388 }389

390

391

392 }393

394 / / remove a l l o l d a n n o t a t i o n s395 I A n n o t a t i o n M o d e l am= t h i s . g e t S o u r c e V i e w e r ( ) . g e t A n n o t a t i o n M o d e l ( ) ;396 f o r ( A n n o t a t i o n a : a l T r a n s ) {397 am . removeAnno ta t i on ( a ) ;398

399 }400

401 / / i f t h e r e are s t i l l u n p r o c e s s e d C o n s t r a i n t s p r i n t e r r o r a n n o t a t i o n s402 i f ( c o n s t r a i n t S e t . s i z e ( ) >0) {403 a l T r a n s =new L i n k e d L i s t < Anno ta t i on > ( ) ;404 I M o d e l C r e a t i n g C o n t e x t mcc= t h i s . g e t L a s t M o d e l C r e a t i n g C o n t e x t ( ) ;405

406 f o r ( C o n s t r a i n t c : c o n s t r a i n t S e t ) {407 P o s i t i o n p=mcc . g e t T r e e N o d e F o r O b j e c t ( c ) . g e t P o s i t i o n ( ) ;408 A n n o t a t i o n a ;409 i f ( e r r o r s . c o n t a i n s K e y ( c ) )410 a=new E r r o r A n n o t a t i o n ( e r r o r s . g e t ( c ) +" [ "+mcc . g e t T r e e N o d e F o r O b j e c t ( c ) . ge tNodeText

( ) +" ] " ) ;411 e l s e412 a=new E r r o r A n n o t a t i o n ( " E r r o r i n C o n s t r a i n t "+mcc . g e t T r e e N o d e F o r O b j e c t ( c ) .

ge tNodeText ( ) ) ;413 am . a d d A n n o t a t i o n ( ( o rg . e c l i p s e . j f a c e . t e x t . s o u r c e . A n n o t a t i o n ) a , p ) ;414 a l T r a n s . add ( a ) ;415 }416

417 re turn f a l s e ;418 }419

420

421 / / modi fy , add or d e l e t e nodes and edges422

423 / / new and m o d i f i e d nodes424 HashMap< S t r i n g , ITransformNode > newNodes = new HashMap< S t r i n g , ITransformNode > ( ) ;425

426 L i s t < ITransformNode > nodeModify = new L i n k e d L i s t < ITransformNode > ( ) ;427 L i s t < ITransformNode > nodeAdd=new L i n k e d L i s t < ITransformNode > ( ) ;428 L i s t < ITransformNode > n o d e D e l e t e =new L i n k e d L i s t < ITransformNode > ( ) ;429 L i s t < ITransformEdge > edgeModify = new L i n k e d L i s t < ITransformEdge > ( ) ;430 L i s t < ITransformEdge > edgeAdd=new L i n k e d L i s t < ITransformEdge > ( ) ;431 L i s t < ITransformEdge > e d g e D e l e t e =new L i n k e d L i s t < ITransformEdge > ( ) ;432 / / a d j u s t t h e group o f t h e nodes433 f o r ( Trans formElementType i : Trans formElementType . v a l u e s ( ) ) {434 HashMap< S t r i n g , C o n s t r a i n t > cons = n u l l ;

132


435 sw i t ch ( i . g e t V a l u e ( ) ) {436 case TransformElementType .K_VALUE: { cons = n o d e C o n s t r a i n t s K ; break ; }437 case TransformElementType . L_VALUE: { cons = n o d e C o n s t r a i n t s L ; break ; }438 case TransformElementType . R_VALUE: { cons = n o d e C o n s t r a i n t s R ; break ; }439 }440 f o r ( S t r i n g i d : cons . ke yS e t ( ) ) {441 i f ( nodesR . c o n t a i n s K e y ( i d ) ) {442 i f ( ! i . e q u a l s ( Trans formElementType . R) ) {443 nodeModify . add ( nodesR . g e t ( i d ) ) ;444 }445

446 nodeTrans . p u t ( id , i ) ;447 newNodes . p u t ( id , nodesR . g e t ( i d ) ) ;448 nodesR . remove ( i d ) ;449 } e l s e450 i f ( nodesK . c o n t a i n s K e y ( i d ) ) {451 i f ( ! i . e q u a l s ( Trans formElementType .K) )452 nodeModify . add ( nodesK . g e t ( i d ) ) ;453 newNodes . p u t ( id , nodesK . g e t ( i d ) ) ;454 nodeTrans . p u t ( id , i ) ;455 nodesK . remove ( i d ) ;456 } e l s e457 i f ( nodesL . c o n t a i n s K e y ( i d ) ) {458 i f ( ! i . e q u a l s ( Trans formElementType . L ) )459 nodeModify . add ( nodesL . g e t ( i d ) ) ;460 newNodes . p u t ( id , nodesL . g e t ( i d ) ) ;461 nodeTrans . p u t ( id , i ) ;462 nodesL . remove ( i d ) ;463 } e l s e {464 / / new nodes465 ITransformNode nn=new ITrans fo rmNodeImpl ( ) ;466 nn . s e t I D ( ( ( L i t e r a l ) cons . g e t ( i d ) . g e t V a r i a b l e s ( ) . g e t ( 0 ) ) . g e t V a l u e ( ) ) ;467 newNodes . p u t ( nn . ge t ID ( ) , nn ) ;468 nodeAdd . add ( nn ) ;469 nodeTypes . p u t ( nn . ge t ID ( ) , ( ITypeNode ) t y p e n o d e s . g e t ( cons . g e t ( i d ) . ge tType ( ) . getName

( ) ) ) ;470 nodeTrans . p u t ( nn . ge t ID ( ) , i ) ;471 }472 }473 }474 / / removed nodes475 n o d e D e l e t e . ad dA l l ( nodesR . v a l u e s ( ) ) ;476 n o d e D e l e t e . ad dA l l ( nodesL . v a l u e s ( ) ) ;477 n o d e D e l e t e . ad dA l l ( nodesK . v a l u e s ( ) ) ;478

479 / / new and m o d i f i e d edges480 / / a d j u s t group o f edge481 f o r ( Trans formElementType i : Trans formElementType . v a l u e s ( ) ) {482 MultiHashMap3 < S t r i n g , S t r i n g , S t r i n g , L i s t < C o n s t r a i n t >> cons = n u l l ;483 sw i t ch ( i . g e t V a l u e ( ) ) {484 case TransformElementType .K_VALUE: { cons = e d g e C o n s t r a i n t s K ; break ; }485 case TransformElementType . L_VALUE: { cons = e d g e C o n s t r a i n t s L ; break ; }486 case TransformElementType . R_VALUE: { cons = e d g e C o n s t r a i n t s R ; break ; }487 }488 HashMap< S t r i n g , HashMap< S t r i n g , HashMap< S t r i n g , L i s t < C o n s t r a i n t >>>> map= cons . getMap ( ) ;489 f o r ( S t r i n g s r c : map . ke yS e t ( ) ) {490 f o r ( S t r i n g t g t : map . g e t ( s r c ) . ke yS e t ( ) )491 f o r ( S t r i n g t y p e : map . g e t ( s r c ) . g e t ( t g t ) . ke yS e t ( ) )492 f o r ( C o n s t r a i n t c : map . g e t ( s r c ) . g e t ( t g t ) . g e t ( t y p e ) ) {493 ITransformNode n s r c =newNodes . g e t ( s r c ) , n t g t =newNodes . g e t ( t g t ) ;494 ITypeEdge e t y p e =( ITypeEdge ) t y p e e d g e s . g e t ( t y p e ) ;495 i f ( edgesR . c o n t a i n s K e y ( ns rc , n t g t , e t y p e ) &&496 ! edgesR . g e t ( n s r c , n t g t , e t y p e ) . i sEmpty ( ) ) {497 ITrans fo rmEdge foundEdge=edgesR . g e t ( n s r c , n t g t , e t y p e ) . remove ( 0 ) ;498 i f ( ! i . e q u a l s ( Trans formElementType . R) ) {499 edgeModify . add ( foundEdge ) ;500 }501 edgeTrans . p u t ( foundEdge , i ) ;502

503 } e l s e i f ( edgesK . c o n t a i n s K e y ( ns rc , n t g t , e t y p e ) &&504 ! edgesK . g e t ( n s r c , n t g t , e t y p e ) . i sEmpty ( ) ) {505 ITrans fo rmEdge foundEdge=edgesK . g e t ( n s r c , n t g t , e t y p e ) . remove ( 0 ) ;506 i f ( ! i . e q u a l s ( Trans formElementType .K) ) {507 edgeModify . add ( foundEdge ) ;508 }509 edgeTrans . p u t ( foundEdge , i ) ;510

511 } e l s e512 i f ( edgesL . c o n t a i n s K e y ( ns rc , n t g t , e t y p e ) &&513 ! edgesL . g e t ( n s r c , n t g t , e t y p e ) . i sEmpty ( ) ) {

133

C Source Code

514 ITrans fo rmEdge foundEdge=edgesL . g e t ( n s r c , n t g t , e t y p e ) . remove ( 0 ) ;515 i f ( ! i . e q u a l s ( Trans formElementType . L ) ) {516 edgeModify . add ( foundEdge ) ;517 }518 edgeTrans . p u t ( foundEdge , i ) ;519

520 } e l s e {521 / / new edges522 ITrans fo rmEdge ne=new IT rans fo rmEdgeImpl ( ) ;523 edgeAdd . add ( ne ) ;524 edgeTypes . p u t ( ne , ( ITypeEdge ) t y p e e d g e s . g e t ( c . ge tType ( ) . getName ( ) ) ) ;525 edgeSrc . p u t ( ne , s r c ) ;526 edgeTgt . p u t ( ne , t g t ) ;527 edgeTrans . p u t ( ne , i ) ;528 }529

530 }531

532 }533 }534 / / removed edges535 f o r ( Trans formElementType i : TransformElementType . v a l u e s ( ) ) {536 MultiHashMap3 <ITransformNode , ITransformNode , ITypeEdge , L i n k e d L i s t < ITransformEdge >>

cons = n u l l ;537 sw i t ch ( i . g e t V a l u e ( ) ) {538 case TransformElementType .K_VALUE: { cons =edgesK ; break ; }539 case TransformElementType . L_VALUE: { cons =edgesL ; break ; }540 case TransformElementType . R_VALUE: { cons =edgesR ; break ; }541 }542 HashMap<ITransformNode , HashMap<ITransformNode , HashMap<ITypeEdge , L i n k e d L i s t <

ITransformEdge >>>> map= cons . getMap ( ) ;543 f o r ( ITransformNode s r c : map . ke yS e t ( ) )544 f o r ( ITransformNode t g t : map . g e t ( s r c ) . ke yS e t ( ) )545 f o r ( ITypeEdge t y p e : map . g e t ( s r c ) . g e t ( t g t ) . ke ySe t ( ) )546 e d g e D e l e t e . ad dA l l ( map . g e t ( s r c ) . g e t ( t g t ) . g e t ( t y p e ) ) ;547 }548

549 / / e x e c u t e t h e changes : i n t h i s o r d e r : d e l e t e edges , d e l e t e nodes , m od i f y nodes ,mo d i f y edges , add nodes , add edges

550 f o r ( ITrans fo rmEdge e : e d g e D e l e t e ) {551 EdgeDeleteCommand cmd=new EdgeDeleteCommand ( e ) ;552 commandStack . e x e c u t e ( cmd ) ;553 }554 f o r ( ITransformNode n : n o d e D e l e t e ) {555 NodeDeleteCommand cmd=new NodeDeleteCommand ( n ) ;556 commandStack . e x e c u t e ( cmd ) ;557 }558 f o r ( ITrans fo rmEdge e : edgeModify ) {559 TransformTypeChangeCommand cmd=new TransformTypeChangeCommand ( ) ;560 cmd . se tMode l ( e ) ;561 cmd . setNewType ( edgeTrans . g e t ( e ) ) ;562 commandStack . e x e c u t e ( cmd ) ;563 }564 f o r ( ITransformNode n : nodeModify ) {565 TransformTypeChangeCommand cmd=new TransformTypeChangeCommand ( ) ;566 cmd . se tMode l ( n ) ;567 cmd . setNewType ( nodeTrans . g e t ( n . ge t ID ( ) ) ) ;568 commandStack . e x e c u t e ( cmd ) ;569 }570 f o r ( ITransformNode n : nodeAdd ) {571 NodeCreateCommand cmd=new NodeCreateCommand ( gt , new R e c t a n g l e (0 ,0 ,−1 ,−1) , nodeTypes .

g e t ( n . ge t ID ( ) ) , n . ge t ID ( ) ) ;572 commandStack . e x e c u t e ( cmd ) ;573 cmd . g e t C r e a t e d N o d e ( ) . e A d a p t e r s ( ) . add ( t h i s ) ;574 newNodes . p u t ( n . ge t ID ( ) , ( ITransformNode ) cmd . g e t C r e a t e d N o d e ( ) ) ;575 TransformTypeChangeCommand cmd2= new TransformTypeChangeCommand ( ) ;576 cmd2 . se tMode l ( cmd . g e t C r e a t e d N o d e ( ) ) ;577 cmd2 . setNewType ( nodeTrans . g e t ( n . ge t ID ( ) ) ) ;578 commandStack . e x e c u t e ( cmd2 ) ;579 }580 f o r ( ITrans fo rmEdge e : edgeAdd ) {581 EdgeCreateCommand cmd=new EdgeCreateCommand ( newNodes . g e t ( edgeSrc . g e t ( e ) ) , edgeTypes .

g e t ( e ) ) ;582 cmd . s e t T a r g e t ( newNodes . g e t ( edgeTgt . g e t ( e ) ) ) ;583 commandStack . e x e c u t e ( cmd ) ;584 cmd . g e t C r e a t e d E d g e ( ) . e A d a p t e r s ( ) . add ( t h i s ) ;585 TransformTypeChangeCommand cmd2= new TransformTypeChangeCommand ( ) ;586 cmd2 . se tMode l ( cmd . g e t C r e a t e d E d g e ( ) ) ;587

588 cmd2 . setNewType ( edgeTrans . g e t ( e ) ) ;

134

C.6 Full TEF grammar

589 commandStack . e x e c u t e ( cmd2 ) ;590

591 }592

593 re turn true ;594 }

C.6 Full TEF grammar

This appendix lists the full TEF grammar used for CHR programs.

Listing C.8: TEF grammar for CHR.1 s y n t a x (CHR) " r e s o u r c e s / c h r t y p e g r a p h . e c o r e " {2 CHR: e l e m e n t (CHR) −> ( C o n s t r a i n t D e f s ( RuleBlock ) ?3 ( I n p u t : c o m p o s i t e ( I n p u t s ) ) ? ) ? ;4 RuleBlock −> " r u l e s { " ws ( s t a t e m e n t )5 ws ( i n d e n t ) Rule : c o m p o s i t e ( Rule ) ws ( s t a t e m e n t )6 / / ( ws ( i n d e n t ) Rule : c o m p o s i t e ( Rule ) )∗7 " } " ;8 Rule : e l e m e n t ( PropRule ) −> ( PropHead ) ? ws ( s t a t e m e n t )9 " <=>" ws ( s t a t e m e n t ) PropBody " . " ;

10 PropHead −> C o n s t r a i n t : c o m p o s i t e ( head )11 ( " , " ws ( s p a c e ) C o n s t r a i n t : c o m p o s i t e ( head ) ) ∗ ;12 PropBody −> C o n s t r a i n t : c o m p o s i t e ( body )13 ( " , " ws ( s p a c e ) C o n s t r a i n t : c o m p o s i t e ( body ) ) ∗ ;14 PropBody −> " t r u e " ;15 C o n s t r a i n t D e f s −> ( " p u b l i c " ws ( s p a c e ) ) ? " C o n s t r a i n t "16 ws ( s p a c e ) C o n s t r a i n t D e f : c o m p o s i t e ( c o n s t r a i n t D e f )17 ( " , " ws ( s p a c e ) C o n s t r a i n t D e f : c o m p o s i t e ( c o n s t r a i n t D e f ) )∗18 " ; " ws ( s t a t e m e n t ) ;19 I n p u t : e l e m e n t ( I n p u t ) −> ":−" C o n s t r a i n t s " . " ws ( s t a t e m e n t ) ;20 C o n s t r a i n t D e f : e l e m e n t ( C o n s t r a i n t D e f ) −>21 IDENTIFIER : c o m p o s i t e ( name ) ( " ( "22 IDENTIFIER : c o m p o s i t e ( v a r i a b l e T y p e s ) ( " , "23 IDENTIFIER : c o m p o s i t e ( v a r i a b l e T y p e s ) )∗" ) " ) ? ;24 C o n s t r a i n t s −> C o n s t r a i n t : c o m p o s i t e ( c o n s t r a i n t s )25 ( " , " ws ( s p a c e ) C o n s t r a i n t : c o m p o s i t e ( c o n s t r a i n t s ) ) ∗ ;26 C o n s t r a i n t : e l e m e n t ( C o n s t r a i n t ) −>27 C o n s t r a i n t D e f R e f : r e f e r e n c e ( t y p e ) ( " ( "28 E x p r e s s i o n : c o m p o s i t e ( v a r i a b l e s ) ( " , "29 E x p r e s s i o n : c o m p o s i t e ( v a r i a b l e s ) )∗" ) " ) ? ;30 C o n s t r a i n t D e f R e f : e l e m e n t ( C o n s t r a i n t D e f ) −>31 IDENTIFIER : c o m p o s i t e ( name ) ;32 E x p r e s s i o n −> L i t e r a l ;33 E x p r e s s i o n −> Numeral ;34 E x p r e s s i o n −> Minus ;35 E x p r e s s i o n −> P l u s ;36 L i t e r a l : e l e m e n t ( L i t e r a l ) −> IDENTIFIER : c o m p o s i t e ( v a l u e ) ;37 Numeral : e l e m e n t ( Numeral ) −> INTEGER : c o m p o s i t e ( v a l u e ) ;38 Minus : e l e m e n t ( Minus ) −> E x p r e s s i o n : c o m p o s i t e ( l h s )39 "−" E x p r e s s i o n : c o m p o s i t e ( r h s ) ;40 P l u s : e l e m e n t ( P l u s ) −> E x p r e s s i o n : c o m p o s i t e ( l h s )41 "+" E x p r e s s i o n : c o m p o s i t e ( r h s ) ;42 }

135

Name: Mathias Wasserthal Matrikelnummer: 541501

Erklärung

Ich erkläre, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebenenQuellen und Hilfsmittel verwendet habe.

Ulm, den . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Mathias Wasserthal

Documents

An Extensible Platform for the Analysis of Graph ... · for the Analysis of Graph Transformation Systems using Constraint Handling Rules ... 2.4 Eclipse ... 3.4.6.2 Zest