Grez – User Manual

H.J. Sander Bruggink

Contents

Contents i

1 Introduction 11.1 Introduction to Grez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 Feedback and bug reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.7 How to read this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.8 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 The Graphical User Interface 52.1 Running Grez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 The main window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 The main menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Opening graph transformation systems . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Reading a system from a file . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 Generating random systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 Proving termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.2 Comparing algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.3 Generating traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Specifying algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.1 The algorithm list editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.2 The algorithm editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 Configuring external tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7.1 Configuring SMT solvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7.2 Configuring termination tools . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 Changing user preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.9 Getting help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 The Command-Line Interface 13

i

Contents

3.1 Using Grez from the command-line . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Command-line options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 General options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Action type and system selection . . . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Reporting and proof generation . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.4 Random system generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Specifying algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Specifying Graph Transformation Systems: The Simple Graph Format 174.1 A first tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Defining rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1.2 Defining graph transformation systems . . . . . . . . . . . . . . . . . . . . . 18

4.2 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.2 Object definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.3 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.4 Morphisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.5 Transformation rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.6 Transformation systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.1 Two systems in one file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.2 In-place definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.3 Ad-hoc routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Theoretical Foundations 255.1 Graph transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Satisfiability modulo theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4 Algorithms for proving termination and non-termination . . . . . . . . . . . . . . . . 27

5.4.1 Finding cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4.2 Node counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.4.3 Edge counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4.4 Petri-net approximation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.4.5 Type graph techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4.6 Match bounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A License texts 33A.1 BSD License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.2 Apache License, version 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.3 Creative Commons Attribution 4.0 International Public License . . . . . . . . . . . . 36

Bibliography 41

Index 43

ii

One

Introduction

1.1 Introduction to Grez

Termination, the absence of infinite computations,is a property that is required in many applications,in particular in model transformation, algorithmsand protocol specifications. Many of these appli-cations, such as graphical model transformation(for example, of UML models) and algorithmsthat manipulate data structures on the heap, arenaturally modeled by graph transformation sys-tems. Grez is a software tool that, given a graphtransformation system, automatically tries to finda proof that the graph transformation systemterminates or a proof that it does not. It doesthis by running a number of algorithms concur-rently and reporting the result of the first of themthat successfully finishes. Since the problem isundecidable in general [7], in many cases noneof the algorithms will find a termination or non-termination proof.

Grez provides both a graphical user interfaceand a command-line interface. Configuring Grez,in particular the paths and parameters of theexternal tools called by it, is only possible withthe graphical user interface, but other than thatall Grez functionality can be accessed throughboth interfaces.

Grez is written in Java 8 and uses the standardJava libraries, including Swing and concurrency,JavaCC, ANTLR and Google Guava, as well as

a number of in-house libraries for graph trans-formation and visualization. For some (optional)functionality it needs an external tool, in partic-ular an SMT solver to find solutions for sets ofconstraints and a LATEX distribution to generatePDF reports.

1.2 NamePeople have wondered where the name Grezcomes from. There are two slightly differentthings that people want to know when they askthis question.

Some people who ask this question are curiousabout what “Grez” means. An implicit assump-tion here is that every name must mean something.Amsterdam is a city which grew around a dambuilt in the river Amstel; England is the land ofthe angles, an ancient Germanic tribe; Columbiais named after Christopher Columbus. But thatis not the case here. There is no language I knowof, current or historic, where the letter sequenceG, R, E, Z has any sensible meaning other than“some word which starts with a G, and ends witha Z.”

Other people do not want to know what “Grez”means but what the reason is that the name “Grez”was picked for this particular piece of software.This is an entirely different question, one with ananswer! I took the letters T, E, R and M, which

1

1. Introduction

are the first four letter of the word “termination”,and the applied the well-known ROT-13 cipherto them. The result is “Grez”, which, coinciden-tally, starts with the same two letters as the word“Graph”.

1.3 PeopleThe following people (in alphabetical order) are orwere involved in the development of Grez, eitherby directly implementing the tool or by providingits theoretical foundation:

• H.J. Sander Bruggink (main developer)

• Barbara König

• Dennis Nolte

• Hans Zantema

1.4 System requirementsGrez is written in Java. To use Grez, you needa recent Java virtual machine (Java 8 or newer).Additionally, to export proofs to PDF, you needa LATEX distribution installed, including commonpackages and style files (the command pdflatexmust be in the path).

The performance of some algorithms is greatlyimproved if an external SMT solver is used (SMTmeans satisfiability modulo theories), and somealgorithms even require this. All SMT solverswhich understand the SMT-LIB 2 input formatare supported.1 External SMT solvers can be setup using the GUI, and after that they are alsoavailable for use with the command-line interface.

The standard Grez distribution contains all li-braries that Grez uses; thus, other than Java itself,you don’t have to install additional software torun Grez. To compile from source, however, youneed the following external Java libraries:

1 Some SMT solvers that claim to support the SMT-LIB 2 format, actually do not fully do so.

• ANTLR 4 (www.antlr.org), used for pars-ing the output of SMT solvers;

• Google Guava, version 14 or newer (github.com/google/guava);

1.5 Installation

To install Grez it is only needed to copy the filegrez.jar to a location of your choice.

If you plan on using Grez through the command-line a lot, it is advisable to create a shell scriptin a directory in the path. In Unix-like operatingsystems, such as Mac OS X and Linux, this filecould be named grez and contain:

#/bin/shjava -jar -Dgrez.script=grez

å /path/to/grez.jar "$@"

(the last two lines should be on the same line).In Windows, the file could be named grez.batand look like:

java -jar -Dgrez.script=grezå C:\path\to\grez.jar %*

(the file should consist of a single line). The-Dgrez.script=grez option sets a Java prop-erty which is read by Grez. It has no effectto the working of the program except that thecommand name is displayed correctly in someuser interactions. Creating such a shell scriptallows you to use grez as a command instead ofjava -jar grez.jar.

1.6 Feedback and bug reports

Grez is free software, both as in free speech andas in free beer. This means that you can use thesoftware and inspect and modify its source codewithout cost, but it also means that there is nowarranty, no guarantee and no customer support.

2

www.antlr.orggithub.com/google/guavagithub.com/google/guava

1.8. License

Still, if you have feedback, bug reports andquestions you may send them to the main devel-oper by e-mail:

sanderbruggink@gmail.com

(Please indicate Grez in the subject line.) If timeallows for it, you might even get an answer!

1.7 How to read this manualThis manual is not intended to be read sequen-tially. In particular, the theoretical foundationsof the variant of graph transformation that Grezuses, as well as of the algorithms that it employsto find termination proofs, are covered in Chap-ter 5, so if you want to know the theory behindGrez, you should start there.

Grez offers to main user interfaces, a graphi-cal user interface and a command-line interface,which are covered in Chapters 2 and 3, respec-tively. If you are not interested in the graphicaluser interface you do not need to read Chapter 2,and if you do not want to use the command-lineinterface, you do not need to read Chapter 3.

Chapter 4 presents the file format that Grezuses. Since Grez currently lacks a graphical userinterface for specifying graph transformation sys-tems, you need to read this chapter if you wantto apply it to your own graph transformationsystems.

1.8 LicenseGrez is distributed under the terms of the (threeclause) BSD license (see Appendix A.1). Thetwo main third-party libraries used are ANTLRand Google Guava. The first is, like Grez itself,distributed under the terms of the (three clause)BSD license, while the second is distributed underthe Apache license (see Appendix A.2).

This documentation is distributed underthe Creative Commons 4.0 Attribution licence,CC BY 4.0 (see Appendix A.3).

3

sanderbruggink@gmail.com

Two

The Graphical User Interface

The most common way to interact with Grez isthe graphical user interface, which is presented inthis chapter. The graphical user interface allowsthe user to open graph transformation systems(and generate random ones), run algorithms whichtry to prove termination or non-termination, andinspect termination and non-termination proofsproduced by these algorithms. Additionally thegraphical user interface is used to configure theexternal tools called by Grez.

2.1 Running Grez

To run Grez, a working Java 8 installation mustbe present. If this is the case Grez ’s graphicaluser interface (GUI) is started on the command-line by changing to the directory where the filegrez.jar resides and issuing the command

java -jar grez.jar

Alternatively, in most operating systems one candouble-click the grez.jar file in the file browser.

When starting Grez ’s graphical user interface,one can also specify an input file and use thecommand-line option --system to open a specificgraph transformation system (see § 3.2).

2.2 The main window

The main window of Grez is displayed in Fig-ure 2.1. It consists of the following parts; fromtop to bottom these are:

• In the main menu there are various com-mands for opening and generating graphtransformation systems, configuring externalprograms and changing user preferences.

• In the rule selection box the user can se-lect the rule of the currently opened graphtransformation system which is displayed.

• In the rule display the currently selected ruleis displayed. One can change the layoutof the rule by dragging nodes and (controlpoints of) edges. When multiple nodes andedges are selected, they can be moved simul-taneously by dragging the selection box orrotated by dragging the quarter circle in thetop left corner of the selection box. Currentlyit is not possible to modify the structure ofthe rule.

• In the action panel the user can select the ac-tion she wants to perform (prove, compare ortrace) and give the algorithm or algorithmswhich are to be used in this action. In theright of the action panel is the Execute but-

5

2. The Graphical User Interface

Figure 2.1: Main window of Grez.

ton which executes the currently selectedaction.

• At the bottom is the status bar which dis-plays information about the currently opengraph transformation system, in particularthe number of rules and the edge labels oc-curring in it.

2.3 The main menu

Grez ’s main menu contains the following menusand commands:

• System – Commands for obtaining graphtransformation systems.

– Open GTS – Open a system from a file;see § 2.4.1.

– Generate random GTS – Generatesa random graph transformation sys-tem with user-specified parameters; see§ 2.4.2.

– Exit – Quit Grez

• Options – Command for configuring Grez.

– Termination tools – Configure externaltermination tools used by Grez ; see§ 2.7.2.

– SMT solvers – Configure SMT solversused by Grez ; see § 2.7.1.

– GUI options – Change some preferencesfor the graphical user interface; see§ 2.8.

– Change number of worker threads –Change the number of worker threads

6

2.4. Opening graph transformation systems

that Grez uses when proving or com-paring algorithms (the default is thenumber of separate CPU cores in thecomputer).

• Help – Obtain information about the pro-gram; see § 2.9

– Visit website – Open Grez ’s website ina browser window.

– About – Display copyright, license andversion information of Grez.

2.4 Opening graphtransformation systems

There are two ways to open a graph transfor-mation system: reading a graph transformationsystem from a file or generating a random one.

2.4.1 Reading a system from a file

A graph transformation system can be read from afile in two ways, on the command-line and throughthe graphical user interface.

• On the command line. Specify the file con-taining the GTS on the command-line. Ifthis file contains more than one GTS, thename of the GTS must be specified usingthe --system=name command-line option.See Chapter 3 for more information.

• Through the graphical user interface. SelectOpen GTS from the System menu. A filedialog appears. Select the file containingthe graph transformation system you wantto open. When selecting a file, in the rightof the dialog a list of graph transformationsystems in this file appears. Select the oneyou want to open and click Open.

2.4.2 Generating random systemsGrez provides the option of automatically gener-ating GTSs. To generate a random graph trans-formation system, select the Generate randomGTS menu item from the System menu. A dialogappears in which the parameters of graph trans-formation system generation can be specified.

The parameters can be divided in four parts:general parameters, parameters for the left-handside, parameters for the right-hand side and pa-rameters for the interface of the rule.

General parameters.

• Number of rules – This is a single numberwhich specifies the number of rules in therandomly generated GTS.

• Signature – The labels that can occurin the GTS and their arities. This is acomma-separated list of entries of the formlabel :arity , where label is the stringdisplayed on the edge and arity is the arityof the label, that is the number of nodesedges labeled with this label are incident to.Alternatively, press the Edit button to editthe signature through a dialog.

Left-hand and right-hand side parameters.

• Number of nodes. Distribution for the num-ber of nodes in a graph (see below).

• Density. Distribution for the density of thegraph. The density is a floating point number≥ 0 which determines the number of edgesin the graph depending on the number ofnodes. In particular, if n is the number ofnodes and d the density, the number of edgesin the graph will be d · n2. In typical cases,the density will lie between 0 and 1.

• Connectedness. This parameter control towhich extend the graph is connected. It hasthree possible values:

7

2. The Graphical User Interface

– Arbitrary. All graphs can be gener-ated, regardless of whether they areconnected or not.

– No isolated nodes. Non-connectedgraphs can be generated, but each nodewill always be incident to at least oneedge.

– Connected. Only connected graphs willbe generated.

Interface parameters.

• Number of nodes. Distribution for the num-ber of nodes in the interface (see below).

• Discrete interfaces. When checked, onlyinterfaces without edges will be generated.Otherwise, the interface will be the maximalinterface such that each interface edge ofthe left-hand side has a corresponding edgein the right-hand side.

Specifying distributions. Distributions can begiven through a dialog by clicking the Edit but-ton, or entered manually by giving a string rep-resentation of the distribution. The followingsdistributions are available for all options where adistribution is required:

• Non-random. A single number which is al-ways chosen. The syntax is simply this num-ber, for example 3 or 0.25.

• Uniform. All numbers within a speci-fied range have an equal probability. Thestring representation of such a distributionis uniform(min,max ).

• Normal. Normal distribution with a givenmean and standard deviation. The stringrepresentation of such a distribution isnormal(mean,sd ), where sd is the stan-dard deviation.

2.5 Actions

Grez has three main actions to perform on graphtransformation systems: it can try to automat-ically prove that a given graph transformationsystem terminates or not using a number of al-gorithms (§ 2.5.1), it can compare the result of anumber of algorithms (§ 2.5.2), and it can producea trace for a single algorithm (§ 2.5.3).

2.5.1 Proving termination

To prove termination of a graph transformationsystem, choose the Prove tab from the actionpanel, give the algorithms which are to be usedfor proving termination, and press the Executebutton.

When proving termination, Grez runs a numberof user-selected algorithms concurrently. As soonas one algorithm returns a proof of terminationor non-termination of the graph transformationsystem under consideration, all algorithms arestopped and the found proof is reported to theuser. If an algorithm finds a relative termina-tion proof, all algorithms are stopped and theprocedure is repeated on the smaller graph trans-formation system from this relative terminationproof.

Algorithms are run concurrently, but it is notthe case that all algorithms are started at thesame time: only as many algorithms are run con-currently as CPU cores. The order in which thealgorithms are executed depends on their order inthe list.

There are three possible outcomes of this ac-tion: a proof that the currently opened graphtransformation system terminates, a proof thatthe currently opened graph transformation systemdoes not terminate, or, if none of the algorithmscould find a termination or non-termination proof,no proof at all.

8

2.6. Specifying algorithms

2.5.2 Comparing algorithms

To compare the results of a number of algorithmson the currently opened graph transformationsystem, select the Compare tab from the actionpanel, give a list of algorithm to compare andclick the Execute button.

When comparing algorithms, all algorithmsspecified by the user are run until they finish,either by giving a (relative or non-relative) termi-nation proof, a non-termination proof or reportthat they cannot find a proof. The results ofall algorithms are reported to the user. If somealgorithm return a relative termination proof therelative termination proof will be reported andthe procedure will not be repeated on the smallergraph transformation system.

2.5.3 Generating traces

Some algorithms can generate a trace to makevisible in what order certain operations are triedout. To generate a trace of an algorithm, se-lect the Trace tab of the action panel, enter thealgorithm to generate a trace of, and click theExecute button. The selected algorithm is exe-cuted, the steps of the algorithm are stored, andafter the algorithm finishes its trace and its resultare reported to the user.

Note that generating a trace is not supportedby all algorithms.

2.6 Specifying algorithmsThere are two ways to specify the algorithmswhich are going to be run: the string represen-tation of the algorithm or algorithm list can beedited directly, or it can be edited through a di-alog. If you want to edit the string directly, see§ 3.3 for the syntax. If you want to use the di-alog press the Edit button to the right of thetext box. If the currently selected action is Proveor Compare, the Algorithm list editor appears tospecify the list of algorithms; if the Trace action is

selected, the Algorithm editor appears to specifythe algorithm.

2.6.1 The algorithm list editorThe algorithm list editor displays the list of (repre-sentations of) algorithm on the left and a numberof command buttons on the right. Available com-mand buttons are:

• Add – Opens the Algorithm editor and addsthe algorithm specified there to the algorithmlist.

• Remove – Removes the currently selectedalgorithm from the list.

• Clear – Removes all algorithms from the list.

• Edit – Opens the Algorithm editor to editthe currently selected algorithm.

• Move up – Moves the currently selected al-gorithm one position up in the list.

• Move down – Moves the currently selectedalgorithm one position down in the list.

• Default – Replaces the list by the default listof algorithms.

• Complete – Adds to the algorithm list allalgorithms of the default list, for which thereis not already an algorithm of the same type(but possibly with different parameters) inthe list.

2.6.2 The algorithm editorIn the algorithm editor we can specify the algo-rithm type and for each type we can give a numberof parameters. The following algorithm types areavailable:

• Cycle finder. Tries to prove non-terminationof the selected graph transformation systemby trying to construct a cycle. This algorithmis described in § 5.4.1. The parameters are:

9

2. The Graphical User Interface

– Initial graph size – number of nodes inthe initial graph;

– Length limit – length of the transfor-mation sequences which are generated.

• Node counter. Tries to prove termination byshowing that the number of nodes decreasesin each rule application. This algorithm isdescribed in § 5.4.2.

• Edge counter. Tries to prove terminationby showing that the number of edges witha label from a certain set decreases in eachrule application. This algorithm is describedin § 5.4.3.

• Type graph finder. Tries to prove terminationby the weighted type graph method describedin § 5.4.5. The parameters are:

– Number of nodes in type graph – maxi-mal number of nodes in the type graph;

– Maximum weight – maximal weight(only available if the Use SMT optionis turned off; if on, there is no limit onthe maximum weight);

– Possible semirings – which kind of eval-uation can be used;

– Use SMT – whether to use an externalSMT solver; click the Configure buttonto specify which SMT solver to use.

– Use non-relative termination – whetherto use a relative or non-relative termi-nation. If non-relative termination isused and the SMT solver fails to find aproof, the relative termination is usedafterwards.

• Match bound finder. Tries to prove termi-nation by using the match bound methoddescribed in § 5.4.6. The Length limit pa-rameter specifies after how many iterationsthe algorithm will be aborted, while the other

parameters specify which type graph simpli-fications will be used.

• Petri-net approximator. Tries to prove ter-mination by approximating the graph trans-formation system by a Petri-net. This al-gorithm is described in § 5.4.4. This algo-rithm requires an external SMT solver. Clickthe Configure button to specify which SMTsolver to use.

• External tool. Sends the graph transforma-tion to an external tool, possibly after per-forming some translation.

2.7 Configuring external tools

Two types of external tools can be used with Grez :external SMT solvers and external terminationtools. The external SMT solvers are used by somealgorithms to solve constraints, while externaltermination tools serve as a kind of oracle: Grezinstructs them to prove termination of a graphtransformation system, after translating it to aformat suitable for the tool, and trusts that theresult is correct.

External SMT solvers and termination toolsneed to be configured before Grez can use them.In particular, Grez needs to know where their ex-ecutable files are, what command-line argumentsthe tools require, how and in what format theyexpect their input, and how to interpret theiroutput.

2.7.1 Configuring SMT solvers

To configure the external SMT solvers used byGrez, select the SMT solvers item from the Op-tions menu. A dialog appears with which you canadd, remove and edit the configurations for theexternal SMT solvers. For each SMT solver thefollowing information is required:

10

2.7. Configuring external tools

• Name – The name of the SMT tool. Thisname is used to refer to the tool in userinteractions.

• Executable – Full path of the executable fileof the tool. Click the Browse button to selectthe executable in a file dialog box.

• Command-line arguments – The command-line arguments to be passed to the tool whencalled from Grez. If the command-line argu-ments contain the literal string ‘%FILE%’ or‘$FILE’, this string is replaced by the inputfile name. If it is required to pass an inputfile name to the tool, but none of the twostring is present, then Grez adds the inputfile name to the end of the command-line.

• Input method – Whether the SMT solverexpects its input to be passed through thestandard input stream, or via a temporaryfile on disk.

Grez expects SMT solvers to write their output inSMT-LIB 2 format to the standard output stream.

In principle Grez support any SMT solver whichcan read files in SMT-LIB 2 format and producesresults and models in the same format. SomeSMT solvers which claim to be compatible withSMT-LIB 2, however, are not or not completely.Grez was tested and found to work with CVC4[1] and Z3 [2]. Other solvers might also work; itis up to the user to try out.

2.7.2 Configuring termination tools

To configure external termination tools used byGrez, select the Termination tools item from theOptions menu. A dialog appears with which youcan add, remove and edit the configurations forthe external termination tools. For each termina-tion tool the following information is required:

• Name – The name of the tool. This name isused to refer to the tool in user interactions.

• Executable – Full path of the executable fileof the tool. Click the Browse button to selectthe executable in a file dialog box.

• Command-line arguments – The command-line arguments to be passed to the tool whencalled from Grez. If the command-line argu-ments contain the literal string ‘%FILE%’ or‘$FILE’, this string is replaced by the inputfile name. If it is required to pass an inputfile name to the tool, but none of the twostring is present, then Grez adds the inputfile name to the end of the command-line.

• Input format – The file format in which Grezwill translate the graph transformation sys-tem prior to passing it to the tool. Thepossible values are:

– Simple graph format – Pass the graphtransformation system in simple graphformat to the external tool.

– String rewrite system – Builds a cy-cle rewrite system which is equivalentto the graph transformation system interms of termination, and then calls thetool on that.

• Input method – Whether the terminationtool expects its input to be passed throughthe standard input stream, or via a temporaryfile on disk.

• Terminating regex – If the tool’s outputmatches this regular expression, Grez willinterpret this to mean: the system is termi-nating.

• Non-terminating regex – If the tool’s outputmatches this regular expression, Grez willinterpret this to mean: the system is notterminating.

11

2. The Graphical User Interface

2.8 Changing user preferencesBy choosing GUI options from the Options menuthe user can change the way Grez displays graphsand rules, and specify when the log window isclosed after executing an action.

The following options can be changed by theuser:

• Layouter – Select the layouter which pro-duces the initial layout (that is, determinesthe initial position of the nodes and edges)of the graphs and rules. Possible options are:

– Leveled – Locate nodes with minimumnumber of incoming edges at the top,nodes directly reachable from thosenodes at the level below, etc. In gen-eral produces good results for graphscontaining only binary edges.

– Spring embedder – Use a spring em-bedder to layout graphs and rules. Ingeneral produces satisfiable results.

• Rule style – Select how rules are displayed.Possible options are:

– Separated – The left-hand side andright-hand side are displayed separately,and the correspondence morphism isdisplayed with dashed lines.

– Unified – The left-hand side and right-hand side are displayed in a mergedgraph; colors indicate which nodes andedges are removed and created.

• Close log when finished – During proving,comparing or tracing a log is displayed whichreports to the user what the algorithms arecurrently doing. This option controls whenthis log is automatically closed. Possiblevalues are:

– Never – Never automatically close thelog. The user must click the Close but-ton manually to close the log.

– When successful – The log is automati-cally closed when one of the algorithmsreturned a result, but not when notermination or non-termination proofcould be found.

– Always – The log is always automati-cally closed after all algorithms finished.This causes Grez to finish silently whenno proof can be found.

2.9 Getting helpGrez does not provide an online help system. Itsdocumentation consists of this user manual andthe web site. Under the Help menu you can findtwo menu items: Visit website will open Grez ’swebsite in your standard browser, and About dis-plays version and license information of Grez.

12

Three

The Command-Line Interface

Almost all functionality of Grez can also be ac-cessed from the command line. This is mainlyuseful if you want to start Grez from a shell scriptor another application, for example to performbatch processing. In this chapter we describe thecommand-line interface of Grez.

One thing you cannot do with the command-line interface is configuring external tools, such asother termination provers and SMT solvers. Forthis you need the graphical user interface (see§ 2.7). After an external tool has been configured,it is available through the command-line interface,however.

3.1 Using Grez from thecommand-line

From the directory where the file grez.jar islocated, Grez is started from the command-linewith following command:

java -jar grez.jar --cli

When a suitable shell script is created in the path(see § 1.5), one can also use (in any directory) thefollowing:

grez --cli

In both cases the consist of a numberof command-line options and, optionally, a single

input file. An option starts with -, -- or /, andany other command-line argument is interpretedas an file name. The --cli option makes surethat Grez ’s graphical user interface is not started.The command-line options and input file mayoccur in any order. The available command-lineoptions are listed in the next section.

3.2 Command-line options

Options start with -, -- or /. These threeare equivalent; for example, -help, --help and/help are all recognized as a command-line op-tion and have the same effect. The availablecommand-line options are:

3.2.1 General options

--help, -h – Display usage information (basi-cally the information of this section) andabort.

--version, -v – Display version information andabort.

--cli, -c – Use the command-line interface,that is, do not start the graphical user in-terface.

If none of the above options are present, thegraphical user interface is started.

13

3. The Command-Line Interface

3.2.2 Action type and system selection--action=act – Select the action to perform,

possibilities for act are: prove (try toprove termination or non-termination ofa graph transformation system) compare(compare results of different algorithms)and trace (produce a trace of a supportedalgorithm).

--algos=list – Select the algorithm(s) to try.list is a comma-separated list of algo-rithms (see § 3.3).

--threads=num – Specify the number of workerthreads that Grez uses when executing theProve or Compare actions. The defaultvalue is the number of separate CPU coresin the machine. The Trace action uses asingle thread regardless of the value of thisparameter.

--system=system – If the input file containsmore than one graph transformation system,select the one with the given name.

--random – Generate a random graph transfor-mation system.

--beta – Enable algorithms that are based onunpublished results and/or currently in betastage. These algorithms are disabled bydefault. Note that these algorithms are notdocumented.

3.2.3 Reporting and proof generation--progress=style – Set the progress report

style, possibilities for style are: silent(no progress report), nice (the default),nice-unicode and standard.

--rtype=ext – Set the file type of the gener-ated report (proof/disproof), possibilitiesfor ext are: silent (do not write report),text (text only; default) and pdf (PDF).For the last option a LATEX distribution isrequired.

--rfile=file – Set the file where the generatedreport is written; default is standard outif rtype=text and grez-output.pdf ifrtype=pdf.

--silent – Shorthand for --rftype=silent--progress=silent.

3.2.4 Random system generation

For more information on the meaning of these op-tions, and the syntax for specifying distributions,see § 2.4.2.

--left-size=dist – Set the distribution for thenumber of nodes in the left-hand side.

--right-size=dist – Set the distribution forthe number of nodes in the right-hand side.

--if-size=dist – Set the number of nodes inthe interface.

--left-dens=dist – Set the distribution for thedensity of the left-hand side.

--right-dens=dist – Set the distribution forthe density of the right-hand side.

--dens=dist – Set the distribution for the den-sity of the left-hand side and right-handside at the same time.

--left-conn=conn – Set the connectedness ofthe left-hand side, possibilities are all,connected and noiso.

--right-conn=conn – Set the connectedness ofthe right-hand side, possibilities are all,connected and noiso.

--conn=conn – Set connectedness of the left-hand side and right-hand side at the sametime.

--discrete=bool – Set whether or not the in-terface is discrete (default value: true).

--rules=num – Set the number of rules to gen-erate.

14

3.3. Specifying algorithms

--labels=list – Set the signature of the gen-erated graph transformation system. Thevalue list is a comma-separated list ofentries of the form label :arity .

3.3 Specifying algorithmsThe general syntax for specifying algorithms isthe following:

Algorithm (Parameters )

where Parameters is a comma-separated list ofparam =value pairs. If an algorithm has no pa-rameters the parentheses are optional.

The value can be any string not containinga comma. If the parameter requires an integervalue, value must be an non-negative integer(a sequence of digits), and if the parameter is aboolean parameter, value must be either ‘true’or ‘false’; if the value is to be set to true, ‘=true’can be omitted.

The possible algorithms are list below. Here, anarbitrary string is denoted by s , a (non-negative)integer by n and a boolean value by b .

CycleFinder – Tries to prove non-terminationby constructing a cycle. This algorithm isdescribed in § 5.4.1.

EdgeCounter – Tries to prove termination byshowing that the number of edges with alabel from a certain set decreases in eachrule application. This algorithm is describedin § 5.4.3.

External(tool=s ) – Calls an external termina-tion tool, the name of which is given bythe tool parameter. External tools canonly be configure using the graphical userinterface, see § 2.7.2.

MatchBound(size=n,limit=n,mini=b,in=b,out=b ) – Tries to prove termination byusing the match bound method describedin § 5.4.6. The size parameter specifies

the size of the initial graph, the limitparameter specifies after how manyiterations the algorithm is aborted. Theparameters mini, in and out turn on oroff conservative minimization, incomingfactorization and outgoing factorization,respectively.

NodeCounter – Tries to prove termination byshowing that the number of nodes de-creases in each transformation step. Thisalgorithm is described in § 5.4.2.

PetriNet(tool=s ) – Tries to prove terminationby approximating the graph transformationsystem by a Petri-net. This algorithm isdescribed in § 5.4.4. This algorithm requiresan external SMT solver, the name of whichis specified by the tool parameter.

TypeGraph(smt=b,tool=s,nodes=n,max=n,wt=s, nrt=b ) – Tries to prove termina-tion by the weighted type graph methoddescribed in § 5.4.5. The parameters are:smt – whether or not to use an externalSMT solver; tool – SMT solver to use(only if SMT is used); nodes – maximumnumber of nodes in generated type graph;max – maximum weight of generated typegraph (only if SMT is not used); wt –evaluation type; if it contains ‘T’ tropicalevaluation may be used, if it contains ‘A’arctic evaluation can be used, if it contains‘N’ arithmetic evaluation can be used;nrt – wether or not to use non-relativetermination. This option is only availableif an SMT-solver is used

15

Four

Specifying Graph Transformation Systems:The Simple Graph Format

Currently, Grez does not provide a graphical userinterface for constructing graph transformationsystems. It can generate random graph trans-formation systems, or read existing ones from afile stored on disk. If the user wants to find atermination proof of a custom graph transforma-tion system, he must use an external program tocreate a file which describes the wanted graphtransformation system.

The file format that Grez natively supports,called the simple graph format (SGF), is a text-based format that describes various objects whichplay a role in graph transformation, such as graphs(and hypergraphs), morphisms and rules. Theformat was developed to have a single parser andinput format that can be used in different graphtransformation tools.

Unlike other text-based formats, such as XML-derived formats, which are mainly designed tobe easily parsed by a computer program, SGF isdesigned to be easily written, read and maintainedin source form by a human being – the word simplein the name reflects that it is supposedly simple towrite, not that it describes simple graphs. One ofthe results of the emphasis on easy writing ratherthan easy parsing is that there is sometimes morethan one way to define the same object.

In this chapter we describe the fragment of SGFwhich describes objects that Grez understands,namely graphs, rules, morphisms and graph trans-formation systems.

4.1 A first tourAn SGF file consists of a list of object definitions.Each of the objects defined in an SGF file caneither be nameless or be named by an identifier.If it is named by an identifier, object definitionsoccurring later in the file may refer to the objectby using its name.

The types of object that are mainly importantfor Grez are graph transformation rules (rules forshort) and graph transformation systems, whichare sets of rules. In this section the most commonway to define such objects is presented. For acomplete reference on how these objects can bedefined, the reader is referred to § 4.2.

4.1.1 Defining rules

Rules are defined in the following way:

= rule {

=>

17

4. Specifying Graph Transformation Systems: The Simple Graph Format

};

The ‘ =’ part is optional if you want todefine a rule with a default name. The left-handside and right-hand side are blocks (delimited with‘{’ and ‘}’) defining the nodes and edges of therespective graph (the node and edge definitionsare separated by semicolons). An edge can bedefined in the following ways:

• e:A(n1,...,nk) denotes a (hyper)edgewith name e and label A which is incident tothe nodes n1,. . . ,nk. Giving a name to anedge is optional; if it is absent the edge willnot be in the correspondence morphism ofthe rule.

• n1 --e:A-> n2 denotes a binary edge withsource node n1 and target node n2. Again,the name of the edge is optional. The defi-nition n1 --e:A-> n2 is equivalent to thedefinition e:A(n1,n2).

• n2 n2 --B-> n2 n2 --A-> n3 }=>{ B(n1,n4,n3) }

};

defines a rule which removes pairs of consecutiveA-labelled edges and replaces them by a singlehyperedge labelled B. The node n2 of the left-handside is removed, and the node n4 of the right-handside is created when this rule is applied.

4.1.2 Defining graph transformationsystems

A graph transformation system is defined as fol-lows:

= gts {rules = [

];

};

The list of rules is a comma-separated list or rules.Usually, the list entries are names of rules definedearlier, but it is also possible to define rules in-place using the rule{...} syntax of the previoussection.

Example 4.1.2. A graph transformation systemwhich only contains the rule of Example 4.1.1 isdefined by the following SGF code:

18

4.2. Grammar

MyGTS = gts {rules = [ MyRule ];

};

4.2 GrammarIn this section we specify the grammar of thefragment of SGF which describes graph transfor-mation systems and the objects on which theydepend.

In the grammar fragments we use the follow-ing conventions. Terminal symbols are given intypewriter font and enclosed in double quotes (forexample "graph" and "{"). Non-terminal sym-bol are displayed in a slanted font. We use a kindof extended Backus-Naur form: the right-handsides of the rules are basically regular expressionconsisting of optional parts (?), choice (|) andrepetition (∗).

4.2.1 Tokens

SGF tokens are delimited by whitespace (space,tab, carriage return and line feed) characters. Oth-erwise, whitespace is ignored (this means, in par-ticular, that newlines are ignored and do not carryany meaning).

The following tokens are keywords in SGF:

copyfromgraphgts

ifgraph ?morphismnodenot ?

rulesystem ?totrace ?

The keywords marked with a star are used todescribe objects which are not used in the contextof termination proving; they are mentioned herefor the sake of completeness but can otherwisebe ignored when specifying graph transformationsystems for use with Grez. They are not furthermentioned in this chapter.

An identifier in SGF is any non-empty sequenceof letters (‘a’–‘z’ and ‘A–Z’), digits (‘0’–‘9’) and

the special symbols ‘@’, ‘_’ and ‘.’ which is not akeyword. Identifiers and keywords in SGF are case-sensitive, that is ‘myRule’ is not the same tokenas ‘myrule’ or ‘MYRULE’. Identifiers function bothas names (of defined objects, nodes and edges)and as labels (of edges):

name → identifierlabel → identifier

C/C++-style comments can be used through-out SGF code: on encountering ‘//’ everythinguntil the end of the line is ignored, and addition-ally every symbol between ‘/*‘ and ‘*/’ is ignored.

4.2.2 Object definitions

An SGF file consists of a list of object definitions:

sgf → object∗

Each object definition defines an object of acertain type. For Grez, only graphs (‘graph’),morphisms (‘morphism’), graph transformationrules (‘rule’) and graph transformation systems(‘gts’) are relevant.

Optionally, each defined object is given a nameby preceding the object definition with ‘name =’,where the name is an identifier. By giving anobject a name it is possible to refer to the objectlater.

Each object definition ends with a semicolon.

object → ( name "=" ) ?( graph| morphism| rule| gts| copy ) ";"

To make a copy of a previously defined object,we can use the copy keyword:

copy → "copy" "(" name ")"

19

4. Specifying Graph Transformation Systems: The Simple Graph Format

A declaration of the form copy(name ) makes acopy of the object with the given name. Thisis especially useful if you wish to store the sameobject under two names1.

4.2.3 Graphs

Graphs are defined with the keyword ‘graph’,followed by a description of the nodes and edgesof the graph.

graph → "graph" "{" graph desc "}"

The description of the nodes and edges of thegraph is block delimited with curly braces contain-ing a semicolon-separated list of node and edgedefinitions:

graph desc → node edge( ";" node edge? ) ∗

node edge → node | edge | binedge

Defining nodes. Nodes can be defined by the‘node’ keyword followed by the name of the node.Nodes have no label (see Chapter 5).

node → "node" name

A definition of the form ‘node name ’ makes surethat the graph contains a node with the givenname; if the graph already contains a node withthat name, a second node with the same namewill not be added.

Defining edges. Edges can be defined in twoways: in a functional style, which allows edges ofarbitrary arity to be defined – both binary edgesand hyperedges – and in an “arrow” style, whichonly allows binary edges to be defined but whichis much more convenient in most circumstances.In both cases edges have a label and, optionally, aname, in the grammar called an edge annotation:

1Note, however, that an actual copy is made of theobject; thus the object will be represented in memory twice.

edge annot → (name ":")? label

In the functional style, edges are defined bydefinitions of the form ‘A(n1,. . .,nk)’, where Ais the annotation (label and optionally the name)of the edge and n1, . . . , nk are the names of thenodes incident to the edge.

edge → edge annot"(" inc nodes? ")"

inc nodes → name ( "," name)∗

In the arrow style binary edges are defined byentries of the form ‘src --A -> tgt ’ and ‘tgt y x’ de-fines an A-labeled loop on the node named x. Onthe other hand, each edge can only be definedonce. Defining two edges with the same namewill result in an error, even if they have the samelabel in both cases.

4.2.4 Morphisms

Morphisms are defined by the keyword ‘morphism’as follows:

20

4.2. Grammar

morphism → "morphism"("from" name)?("to" name)?"{" mappings? "}"

mappings → mapping ( ";" mapping )∗mapping → name "=>" name

Every morphism has a domain graph (given af-ter the ‘from’ keyword) and a codomain graph(given after the ‘to’ keyword). In some cases (forexample when defining a rule) the domain andcodomain can be determined from the context; inthese cases explicitly specifying the domain andthe codomain is optional. In all other cases thedomain and codomain must be specified.

The body of a morphism definition consists ofa semicolon-separated list of individual mappingswhich map nodes of the domain graph to nodes ofthe codomain and edges of the domain to edgesof the codomain. When mapping an edge it isnot necessary to explicitly map the incident nodesof that edge also; this is done automatically.

If the specified mapping does not represent a(partial) morphism – in particular this happenswhen a node or an edge of the domain is mappedto two different nodes or edges of the codomain– an error is reported.

4.2.5 Transformation rules

A transformation rule2 consists of a left-hand side,a right-hand side and a correspondence morphismwhich associates a subset of the nodes and edgesof the left-hand side with nodes and edges of theright-hand side. There are two ways in which rulescan be specified: firstly, the three components ofa rule can be given explicitly, and secondly thereis a short-hand form where the correspondencemorphism is automatically constructed from thenames of the nodes and edges of the left-handside and the right-hand side.

2 In addition to these three components, SGF allowsthe definition of negative application conditions. Sincethey are ignored by Grez, they are not described here.

rule → exp rule | short rule

Explicit form. In the explicit form, a rule isdefined by the following grammar:

exp rule → "rule" "{"( "left" "=" graph ref| "right" "=" graph ref| "morphism" "="

morph refgraph ref → graph | namemorph ref → morphism | name

The three components of a rule are explicitly spec-ified, either by referring by name to a previouslydefined graph or morphism, or by defining thecomponents in-place (the graph and morphismnon-terminals are defined in § 4.2.3 and § 4.2.4,respectively). The left-hand side, right-hand sideand morphism can be given in any order, and fromtheir definition until the end of the rule declara-tion scope, left, right and morphism functionas names for the respective objects.

Short-hand form. In the short-hand form, arule is defined by the following grammar:

short rule → "rule" "{""{" graph desc "}""=>""{" graph desc "}"

"}"

The definition of graphs is the same as in § 4.2.3.The correspondence morphism is automaticallygenerated from the graph definitions by mappingeach node and edge of the left-hand side to thenode or edge of the right-hand side with the samename, if it exists.

4.2.6 Transformation systemsA transformation system is a set of rules. Trans-formation systems are defined by the followinggrammar:

21

4. Specifying Graph Transformation Systems: The Simple Graph Format

gts → "gts" "{""rules" "=" "["

rules?"]" ";" "}"

rules → rule ref ("," rule ref )∗rule ref → rule | name

The list of rules is a comma-separated list in whicheach entry is an in-place rule definition (the non-terminal rule is defined in § 4.2.5) or the nameof a previously defined rule.

4.3 Examples

4.3.1 Two systems in one file

It is possible to define two or more graph trans-formation systems in a single SGF file. This canbe useful if the two systems share certain graphsor rules. For example:

A = graph { 1 --A-> 2 };B = graph { 1 --B-> 2 };

AtoB = rule {left = A;right = B;morphism = morphism {

1 => 1;2 => 2;

}}

BtoA = rule {left = B;right = A;morphism = morphism {

1 => 1;2 => 2;

}}

SysAtoB = gts {rules = [ AtoB ];

};

SysBtoA = gts {rules = [ BtoA ];

};

SysAeqB = gts {rules = [ AtoB, BtoA ];

};

If the user tries to open an SGF file which con-tains two graph transformation systems, she mustspecify the name of the system she wants to open,either by using the --system= command-line option or selecting it in the open dialog ofthe graphical user interface.

4.3.2 In-place definition

In almost all cases where you can use the nameof a previously defined object, you can also definethat object in-place. (The exception to this ruleis in the definition of a morphism: after the fromand to keywords you can only use the name of apreviously defined graph.) For example:

MakeTriangle = gts {rules = [

rule {{ T(1,2,3) }=>{ 1 --A-> 2 --A-> 3 --A-> 1 }

}];

}

If you define an object in place, you cannot giveit a name and thus you cannot refer to it later.Defining an object in-place can be advantageousif you need an object only once and do not wantto introduce a new name.

22

4.3. Examples

4.3.3 Ad-hoc routing

The following example is adapted from [5]. Theexample describes a simple ad-hoc routing proto-col in a dynamically changing network. A message(M) traverses a network of servers (S), routers(R) and directed connections (C) between them.The message can only be sent to unvisited (U)nodes. In addition, rules which modify the net-work’s layout are active. The graph transforma-tion system which models the protocol consistsof the following rules:

Send =1 2

CM U

→1 2

CM

Add =1 2

CS S

→1 2

C CS

R US

Connect =1

S U→

1CS U

The numbers below the nodes indicate what nodesare mapped to each other by the correspondencemorphism.

This graph transformation system is repre-sented by the following SGF code:

Send = rule {{ 1 --M-> 1 --C-> 2 --U-> 2 }=>{ 1 --C-> 2 --M-> 2 }

};

Add = rule {{ 1 --S-> 1 --C-> 2 --S-> 2 }=>{ 1 --S-> 1 --C-> n

--C-> 2 --S-> 2;n --R-> n --U-> n; }

};

Connect = rule {{ node 1;

r --S-> r --U-> r; }=>{ 1 --C-> n;

n --S-> n --U-> n; }};

AdHocRouting = gts {rules = [Send,Add,Connect];

};

23

Five

Theoretical Foundations

In this chapter we present some of the theoreticalfoundations of the termination proving techniquesused in Grez. We have choses to keep the texton a high level, referring to the literature for thedetails.

5.1 Graph transformationGrez uses so-called hypergraphs. A hypergraphdiffers from a normal graph in that edges can beincident to any number of nodes. Formally, ahypergraph G consists of a finite set of nodes VG(sometimes also called vertices in the literature)and a finite set of edges EG disjoint from VG.Each edge e ∈ EG has a label labG(e) and asequence of incident nodes attG(e) ⊆ V ∗G. Notethat in this approach nodes do not have labels;they solely serve as a means to connect edges. Inthe following a hypergraph will be simply called agraph.

We will sometimes confuse the graph G withthe set of its components: G = VG ∪EG. In thischapter we will additionally assume – without lossof generality – that, for two graphs G and H, VGand EH are disjoint (in other words, we assumeglobal, disjoint universes of nodes and edges).

The graph labels come from a fixed set Λ, calledthe signature. In Grez, the signature consists ofall identifiers, that is, strings consisting of letters,digits and some special characters (see § 4.2.1)

can function as labels. The subset of labels thatoccur in a graph G is called the signature of G.

If G is a graph, e is an edge of G and v a nodeof G, then we will say that e and v are incidentif v ∈ attG(e). Furthermore, two edges e1 ande2 are adjacent if there exists a node v which isincident to both e1 and e2. Similarly, two nodesv1 and v2 are called adjacent if there exists anedge which is incident to both v1 and v2.

A morphism f from a graph G to a graph His a function which maps nodes of G to nodesof H and edges of G to edges of H, such that,for each edge e ∈ EG, labG(e) = labH(f(e)) andf(attG(e)) = attH(f(e)).1

Grez employs the so-called double pushout ap-proach to graph transformation [6]. However,for performance and convenience reasons, graphtransformation rules are represented similar tosingle pushout rules. A graph transformation ruleconsists of two graphs, a left-hand side L and aright-hand side R, and a partial, injective mor-phism from L to R. The morphism f will becalled the correspondence morphism. Withoutloss of generality it will always be assumed thatthe correspondence morphism f is of the following

1 In this case, f is extended to sequences of nodes asfollows: f(v1 · · · vn) = f(v1) · · · f(vn).

25

5. Theoretical Foundations

form:

f(x) ={x if x ∈ L ∩Rundefined otherwise.

Using this assumption, the equivalent rule in thenormal double pushout style is obtained by takingL ∩R as the interface and the two injections asthe rule span.

A graph transformation step can be algorithmi-cally described as follows. Let a rule ρ = L→ Rwith correspondence morphism f be given. Sup-pose there exists an injective morphism m, thematch, from L into some graph G. The rule canbe applied to m if for every edge e ∈ EG not inthe image of m and node v ∈ attG(e) it holds,that if v is in the image of m, f is defined on thepre-image of v under m. In this case we say thatthe dangling edge condition is satisfied. If therule is applicable, all images of elements in L forwhich f is undefined are removed from G. Thisgives us the “context” graph C. Furthermore theelements of R that do not have a preimage inL are added and connected with the remainingelements, as specified f . This results in the graphH, and we write G ⇒ρ H. The dangling edgecondition ensures that nodes can only be deletedif all incident edges are deleted.

Finally, a graph transformation system is a fi-nite set of graph transformation rules. The rewriterelation induced by the graph transformation sys-tem is the union of the rewrite relations inducedby its rules.

5.2 Termination

There are two kinds of termination: uniform andnon-uniform termination. A graph transforma-tion system is uniformly terminating if it doesnot allow an infinite transformation sequenceG0 ⇒ G1 ⇒ · · · , where G0 is an arbitrary graph.A graph transformation system is non-uniformlyterminating with respect to a set of graphs L if

it does not allow an infinite transformation se-quence G0 ⇒ G1 ⇒ · · · with G0 ∈ L. Grez onlyproves uniform termination (although in futureversions also non-uniform termination might besupported).

A lot of research has been done on techniquesfor proving (uniform) termination of rewrite sys-tems, in particular of term and string rewritesystems. An overview of such techniques can befound in [8, Chap. 6]. In general, termination of aterm or string rewrite system is proven by findinga suitable well-founded ordering > on the termsor strings. In particular, it is convenient if theordering has the following property: if l > r forsome rule ρ = l → r, and s ⇒ρ t, then s > t.Now, if we want to show that a term or stringrewrite system is terminating, it suffices to checkthat l > r for each rule of the system.

In graph transformation the rules do only con-sist of a left-hand side and a right-hand side, butalso of the correspondence morphism. So wedo not want to compare the left-hand side andthe right-hand side in isolation, but also wantto consider the correspondence morphism to getstronger termination arguments. We will call arule ρ decreasing (resp. non-increasing) if it holdsthat G ⇒ρ H implies G > H (resp. G ≥ H),where > is a well-founded ordering on graphswhich depends on the specific technique and ≥is the reflexive closure of >. Now it holds that agraph transformation system is terminating if allits rules are decreasing.

A useful notion is that of relative termination.Let R be a set of graph transformation rules (thatis, R is a graph transformation system). If R canbe partitioned into two setsR> andR= = R\R>such that all rules of R> are decreasing and allrules of R= are non-increasing, then R is termi-nating if and only if R= is terminating. Often,proving that R= is terminating is considerablyeasier than proving that R is terminating. Thus,iterative termination proofs are produced. Manytermination techniques employed by Grez support

26

5.4. Algorithms for proving termination and non-termination

relative termination.

5.3 Satisfiability modulotheories2

Some algorithms used by Grez solve constraints bytranslating them into a satisfiability modulo the-ories (SMT) formula and then calling an externalSMT solver. Here we briefly describe SMT.

The SMT problem is a decision problem forlogical formulas with respect to combinations ofbackground theories expressed in classical first-order logic with equality. Examples of theoriestypically used in computer science are the the-ory of real numbers, the theory of integers, andthe theories of various data structures such aslists, arrays, bit vectors and so on. SMT can bethought of as a form of the constraint satisfactionproblem and thus a certain formalized approachto constraint programming.

Formally speaking, an SMT instance is a for-mula in first-order logic, where some functionand predicate symbols have additional interpre-tations, and SMT is the problem of determiningwhether such a formula is satisfiable. In otherwords, imagine an instance of the Boolean satisfi-ability problem (SAT) in which some of the binaryvariables are replaced by predicates over a suitableset of non-binary variables. A predicate is basi-cally a binary-valued function of non-binary vari-ables. Example predicates include linear inequali-ties (for example 3x+ 2y − z ≥ 4) or equalitiesinvolving uninterpreted terms and function sym-bols (for example f(f(u, v), v) = f(u, v) wheref is some unspecified function of two unspecifiedarguments.) These predicates are classified ac-cording to the theory they belong to. For instance,linear inequalities over real variables are evaluatedusing the rules of the theory of linear real arith-metic, whereas predicates involving uninterpretedterms and function symbols are evaluated using

2This section is adapted from Wikipedia [10].

the rules of the theory of uninterpreted functionswith equality (sometimes referred to as the emptytheory). Other theories include the theories ofarrays and list structures (useful for modeling andverifying software programs), and the theory ofbit vectors (useful in modeling and verifying hard-ware designs). Most SMT solvers support onlyquantifier free fragments of their logics.

Grez employs only the theories of linear integerarithmetic (beta algorithms also non-linear integerarithmetic) and uninterpreted functions, usingquantifier-free logic.

5.4 Algorithms for provingtermination andnon-termination

5.4.1 Finding cycles

Grez implements a simple cycle finder which ex-haustively generates all transition sequences upto a given length which start with an arbitraryinitial graph with a given size. If a cycle existsamong these finitely many transition sequencesthis constitutes a proof of non-termination.

5.4.2 Node counting

The node counting technique is a simple termina-tion technique which supports relative termination.Let #(G) denote the number of nodes of a graphG. This induces a well-founded order on graphby counting the number of nodes.

A rule ρ = L → R is node-decreasing if#(L) > #(R) and it is non-node-increasingif #(L) ≥ #(R). Clearly, when G ⇒ρ H,#(G) > #(H) if ρ is node-decreasing and#(G) ≥ #(H) if ρ is non-node-increasing. Thisleads to the following termination argument:

Theorem 5.4.1. If R and S are graph trans-formation systems such that all rules of R arenode-decreasing and all rules of S are non-node-

27

5. Theoretical Foundations

increasing, then R∪ S is terminating if and onlyif S is.

The node counter algorithm used by Grez usesthis termination argument. It just checks if thecondition applies and returns a termination proofif it does.

5.4.3 Edge counting

The edge counting technique is a simple termina-tion technique which supports relative termination.Let S ⊆ Λ be a set of labels; then, for a graph G,#S(G) denotes the number of edges in G whichare labelled with a label from S.

A rule ρ = L→ R is edge-decreasing with re-spect to S if #S(L) > #S(R) and it is non-edge-increasing with respect to S if #S(L) ≥ #S(R).Clearly, when G ⇒ρ H, #S(G) > #S(H)if ρ is edge-decreasing with respect to S and#S(G) ≥ #S(H) if ρ is non-edge-increasing withrespect to S. This leads to the following termina-tion argument:

Theorem 5.4.2. Let S ⊆ Λ be a set of labels.If R and S are graph transformation systemssuch that all rules of R are edge-decreasing withrespect to S and all rules of S are non-edge-increasing with respect to S, then R ∪ S is ter-minating if and only if S is.

The edge counter algorithm used by Grez usesthis termination argument. It tries all subsets ofthe graph transformation system’s signature andreturns a termination proof if the above conditionholds for one of those subsets.

5.4.4 Petri-net approximation

In [9] a termination technique was presentedwhich over-approximates the transition sequencesof a graph transformation system by a Petri-net.If the Petri-net is terminating, which is the caseif a certain system of linear inequalities does not

have any trivial solutions, then the graph transfor-mation system is terminating as well. In fact, thepaper [9] extends this result to graph transforma-tion systems with negative application conditions(of a certain kind), but since Grez does not sup-port negative application conditions at this point,this extension was not implemented.

The Petri-net that approximates the graphtransformation system has a place for each labelin the signature and a transition for each graphtransformation rule. The pre- and post-conditionsof the Petri-net are as follows: for each edge la-belled with a label A in the left-hand side of arule ρ the place corresponding to A is added asa pre-condition to the transition correspondingto ρ, and, for each edge labelled with a label Bin the right-hand side of a rule ρ the place cor-responding to B is added as a post-condition tothe transition corresponding to ρ. Note that thePetri-net only models the number of edges witha certain label; it does not model the structureof the graph.

Clearly, each transformation sequence of thegraph transformation system induces a firing se-quence of the Petri-net of the same length. Thus,termination of the Petri-net implies terminationof the graph transformation system – but not viceversa.

A non-termination Petri-net is called weaklyrepetitive in the Petri-net literature. To checkwhether a Petri-net is weakly repetitive, the fol-lowing well-known result can be used:

Proposition 5.4.3. Let A be the incidence ma-trix of a Petri-net M . Then M is weakly repetitiveif there exists a vector z, with z > 0 and z 6= 0,such that AT × z ≥ 0.

Grez ’s Petri-net approximation algorithm usesan external SMT solver to check whether theinequality of the above proposition has any so-lutions (since it is a linear inequality, this is adecidable problem).

28

5.4. Algorithms for proving termination and non-termination

5.4.5 Type graph techniques

A type graph for a graph transformation systemR is a graph T , such that for each reachablegraph G there exists a morphism from G to T .(Since Grez only supports uniform termination,effectively this means that for each graph G thereexists a morphism from G to T .) We additionallyrequire that for each rule ρ ∈ R, (where ρ = L→R and ρ has correspondence morphism f) andmorphism m : L → T , there exists a morphismm′ : R→ T such that (m′ ◦ f)(x) = m(x) for allx for which f is defined.

A weighted type graph is a type graph whereeach node and edge has been given a weight ∈ N.

Rules can be evaluated with respect to aweighted type graph in two ways: tropically andarcticly (see below). In each of these cases agraph transformation system is proved to be ter-minating by finding a weighted type graph whichsatisfies the properties required by the chosenevaluation type. Grez ’s type graph algorithm sup-ports two methods for find (tropically, arcticly orarithmetically evaluated) weighted type graphs:the first is a naive implementation which exhaus-tively enumerates all weighted type graphs up toa certain number of nodes and maximum weight;the second encodes the properties as an SMT for-mula and runs an external SMT solver to find aweighted type graph with k nodes satisfying theseproperties (where k is a user-specified parameter).

Tropical evaluation. This termination tech-nique was introduced in [5]. The technique sup-ports relative termination.

Given a weighted type graph T , the weightof a morphism m : G → T , denoted wt(m), isthe sum of all the weights in its image. Then arule ρ = L→ R, with correspondence morphismf , is called tropically decreasing with respectto T if for each morphism mL : L → T thereexists a morphism mR : R → T which agreeson f such that wt(mL) > wt(mR); it is calledtropically non-increasing with respect to T if for

each morphism mL : L → T there exists a mor-phism mR : R→ T which agrees on f such thatwt(mL) ≥ wt(mR).

The following termination argument was provedin [5]:

Theorem 5.4.4. Let T be a weighted type graph.If R and S are graph transformation systems suchthat all rules of R are tropically decreasing withrespect to T and all rules of S are tropicallynon-increasing with respect to T , then R∪ S isterminating if and only if S is.

Arctic evaluation This termination techniquewas introduced in [5]. It is very similar to thetropical evaluation, except that rules are evaluated“from left to right”. As the tropical evaluation,this technique supports relative termination.

Given a weighted type graph T , the weightof a morphism m : G → T is defined in thesame way as with the tropical evaluation. Arule ρ = L → R, with correspondence mor-phism f , is called arcticly decreasing with respectto T if for each morphism mR : R → T thereexists a morphism mL : L → T which agreeson f such that wt(mL) > wt(mR); it is calledarcticly non-increasing with respect to T if foreach morphism mR : R→ T there exists a mor-phism mL : L→ T which agrees on f such thatwt(mL) ≥ wt(mR).

The following termination argument was provedin [5]:

Theorem 5.4.5. Let T be a weighted type graph.If R and S are graph transformation systemssuch that all rules of R are arcticly decreasingwith respect to T and all rules of S are arcticlynon-increasing with respect to T , then R∪ S isterminating if and only if S is.

Arithmetical evaluation. This terminationtechnique was introduced in [4]. The techniquesupports relative termination.

29

5. Theoretical Foundations

Given a weighted type graph T , the weight ofa graph G , denoted wt(G), is the sum of theweights of all morphisms m : G → T , denotedwt(m) which is the product of all the weights in itsimage. Then a rule ρ = L�ϕL− I −ϕR�R, withmorphism f : I → T , is called arithmetically non-increasing with respect to T if for all f it holdsthat

∑mL : L→TmL◦ϕL=f

wt(mL) ≥∑mR : R→TmR◦ϕR=f

wt(mR);

it is called arithmetically decreasing with respectto T if the sum of weights for mL is > than thesum of weights for mR with respect to f ′ : I → Twhere f ′ maps all nodes onto the flower node ofT .

The following termination argument was provedin [4]:

Theorem 5.4.6. Let T be a weighted type graph.If R and S are graph transformation systems suchthat all rules of R are arithmetically decreasingwith respect to T and all rules of S are arith-metically non-increasing with respect to T , thenR∪ S is terminating if and only if S is.

5.4.6 Match bounds

The match bound technique implemented in Grezis a slightly improved version of the techniquepresented in [3]. The idea is to annotate eachedge with a match height, informally the numberof rule applications responsible for creating theedge in question. If the match height of the graphtransformation system is bounded, then the graphtransformation system is terminating.

Formally, annotating a graph transformationsystem is done by constructing a new graph trans-formation systems which uses Λ× N as label set,where Λ is the label set of the original system.When an occurrence of a left-hand side is replacedby a right-hand side, the new edges are annotatedwith a creation height which is equal to the small-est creation height of the left-hand side plus one.Now, the termination argument is as follows: ifthere exists a type graph (with annotated edges)

for the annotated graph transformation system,then the match bound is bounded (because thetype graph is finite by definition) and thus theoriginal graph transformation system is terminat-ing. See [3] for more details and formal definitionsand proofs.

Grez ’s match bound algorithm uses the follow-ing algorithm to try to find a type graph for theannotated graph transformation system:

1. Start with the flower graph, that is the graphwhich consists of a single node v and for eachlabel and edge which is only connected (asmany times as the arity prescribes) to v. Alledges are annotated with the creation height0.

2. Find an occurrence of an annotated left-handside in the current type graph. If such anoccurrence exists, extend the type graph withthe right-hand side. The left-hand side is notremoved from the type graph. Note that theannotations of all edges in the right-hand sideis the minimum annotation of the left-handside plus one.

3. Reduce the type graph by user-specified typegraph reductions (see below).

4. Continue with step 2 as long as the typegraph can be modified this way.

If the algorithm terminates, then a type graph forthe annotated graph transformation system hasbeen found and thus the original graph transfor-mation system is terminating.

Grez implements the following type graph re-ductions:

• Conservative minimization – While the typegraph has an endomorphism (a morphismfrom the type graph to itself) which is notan isomorphism, the type graph is replacedby the image of this endomorphism. Thisreduction is conservative in the followingsense. Let T be a type graph and T ′ its

30

5.4. Algorithms for proving termination and non-termination

minimization. Then there exists a morphismf : G→ T if and only if there exists a mor-phism f ′ : G→ T ′.

• Outgoing edge factorization – If there aretwo edges with the same label, which areconnected to the same node in port 0 (inbinary edges, this is the source port), thenthe nodes connected to port 1 (the targetport) of the two edges are merged. This is anon-conservative reduction. Let T be a typegraph and T ′ its outgoing edge factorization.Then it is the case that the existence of amorphism f : G→ T implies the existence ofa morphism f ′ : G→ T ′, but not the otherway around. For some graph transformationsystems this reduction is necessary for thealgorithm to terminate, while in others itcauses non-termination.

• Incoming edge factorization – The same asoutgoing edge factorization, but now nodesare merged if they are the source nodes oftwo edges with the same label and the sametarget node.

31

Appendix A

License texts

A.1 BSD LicenseRedistribution and use in source and binary forms,with or without modification, are permitted pro-vided that the following conditions are met:

1. Redistributions of source code must retainthe above copyright notice, this list of condi-tions and the following disclaimer.

2. Redistributions in binary form must repro-duce the above copyright notice, this list ofconditions and the following disclaimer inthe documentation and/or other materialsprovided with the distribution.

3. Neither the name of the copyright holder northe names of its contributors may be usedto endorse or promote products derived fromthis software without specific prior writtenpermission.

This software is provided by the copyright holdersand contributors “as is” and any express or impliedwarranties, including, but not limited to, the im-plied warranties of merchantability and fitness fora particular purpose are disclaimed. In no eventshall the copyright holder or contributors be liablefor any direct, indirect, incidental, special, exem-plary, or consequential damages (including, butnot limited to, procurement of substitute goods orservices; loss of use, data, or profits; or business

interruption) however caused and on any theoryof liability, whether in contract, strict liability, ortort (including negligence or otherwise) arising inany way out of the use of this software, even ifadvised of the possibility of such damage.

A.2 Apache License, version 2.0

1. Definitions. “License” shall mean the termsand conditions for use, reproduction, and distri-bution as defined by Sections 1 through 9 of thisdocument.

“Licensor” shall mean the copyright owner orentity authorized by the copyright owner that isgranting the License.

“Legal Entity” shall mean the union of theacting entity and all other entities that control, arecontrolled by, or are under common control withthat entity. For the purposes of this definition,“control” means (i) the power, direct or indirect,to cause the direction or management of suchentity, whether by contract or otherwise, or (ii)ownership of fifty percent (50%) or more of theoutstanding shares, or (iii) beneficial ownershipof such entity.

“You” (or “Your”) shall mean an individual orLegal Entity exercising permissions granted bythis License.

“Source” form shall mean the preferred form for

33

A. License texts

making modifications, including but not limitedto software source code, documentation source,and configuration files.

“Object” form shall mean any form resultingfrom mechanical transformation or translationof a Source form, including but not limited tocompiled object code, generated documentation,and conversions to other media types.

“Work” shall mean the work of authorship,whether in Source or Object form, made availableunder the License, as indicated by a copyrightnotice that is included in or attached to the work.

“Derivative Works” shall mean any work,whether in Source or Object form, that is basedon (or derived from) the Work and for which theeditorial revisions, annotations, elaborations, orother modifications represent, as a whole, an orig-inal work of authorship. For the purpose of thisLicense, Derivative Works shall not include worksthat remain separable from, or merely link (orbind by name) to the interfaces of, the Work andDerivative Works thereof.

“Contribution” shall mean any work of author-ship, including the original version of the Workand any modifications or additions to that Workor Derivative Works thereof, that is intentionallysubmitted to Licensor for inclusion in the Work bythe copyright owner or by an individual or LegalEntity authorized to submit on behalf of the copy-right owner. For the purposes of this definition,“submitted” means any form of electronic, verbal,or written communication sent to the Licensor orits representatives, including but not limited tocommunication on electronic mailing lists, sourcecode control systems, and issue tracking systemsthat are managed by, or on behalf of, the Licen-sor for the purpose of discussing and improvingthe Work, but excluding communication that isconspicuously marked or otherwise designated inwriting by the copyright owner as “Not a Contri-bution.”

“Contributor” shall mean Licensor and any in-dividual or Legal Entity on behalf of whom a

Contribution has been received by Licensor andsubsequently incorporated within the Work.

2. Grant of Copyright License. Subject tothe terms and conditions of this License, eachContributor hereby grants to You a perpetual,worldwide, non-exclusive, no-charge, royalty-free,irrevocable copyright license to reproduce, prepareDerivative Works of, publicly display, publicly per-form, sublicense, and distribute the Work andsuch Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to theterms and conditions of this License, each Contrib-utor hereby grants to You a perpetual, worldwide,non-exclusive, no-charge, royalty-free, irrevocable(except as stated in this section) patent licenseto make, have made, use, offer to sell, sell, im-port, and otherwise transfer the Work, wheresuch license applies only to those patent claimslicensable by such Contributor that are necessarilyinfringed by their Contribution(s) alone or by com-bination of their Contribution(s) with the Workto which such Contribution(s) was submitted. IfYou institute patent litigation against any entity(including a cross-claim or counterclaim in a law-suit) alleging that the Work or a Contributionincorporated within the Work constitutes director contributory patent infringement, then anypatent licenses granted to You under this Licensefor that Work shall terminate as of the date suchlitigation is filed.

4. Redistribution. You may reproduce and dis-tribute copies of the Work or Derivative Worksthereof in any medium, with or without modifi-cations, and in Source or Object form, providedthat You meet the following conditions:

a. You must give any other recipients of the Workor Derivative Works a copy of this License; and

34

A.2. Apache License, version 2.0

b. You must cause any modified files to carryprominent notices stating that You changedthe files; and

c. You must retain, in the Source form of anyDerivative Works that You distribute, all copy-right, patent, trademark, and attribution no-tices from the Source form of the Work, ex-cluding those notices that do not pertain toany part of the Derivative Works; and

d. If the Work includes a “NOTICE” text file aspart of its distribution, then any DerivativeWorks that You distribute must include a read-able copy of the attribution notices containedwithin such NOTICE file, excluding those no-tices that do not pertain to any part of theDerivative Works, in at least one of the fol-lowing places: within a NOTICE text file dis-tributed as part of the Derivative Works; withinthe Source form or documentation, if providedalong with the Derivative Works; or, withina display generated by the Derivative Works,if and wherever such third-party notices nor-mally appear. The contents of the NOTICE fileare for informational purposes only and do notmodify the License. You may add Your own at-tribution notices within Derivative Works thatYou distribute, alongside or as an addendumto the NOTICE text from the Work, providedthat such additional attribution notices cannotbe construed as modifying the License.You may add Your own copyright statement toYour modifications and may provide additionalor different license terms and conditions foruse, reproduction, or distribution of Your mod-ifications, or for any such Derivative Works asa whole, provided Your use, reproduction, anddistribution of the Work otherwise complieswith the conditions stated in this License.

5. Submission of Contributions. Unless Youexplicitly state otherwise, any Contribution in-tentionally submitted for inclusion in the Work

by You to the Licensor shall be under the termsand conditions of this License, without any addi-tional terms or conditions. Notwithstanding theabove, nothing herein shall supersede or modifythe terms of any separate license agreement youmay have executed with Licensor regarding suchContributions.

6. Trademarks. This License does not grantpermission to use the trade names, trademarks,service marks, or product names of the Licensor,except as required for reasonable and custom-ary use in describing the origin of the Work andreproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless requiredby applicable law or agreed to in writing, Licensorprovides the Work (and each Contributor providesits Contributions) on an “as is” basis, withoutwarranties or conditions of any kind, either ex-press or implied, including, without limitation, anywarranties or conditions of title, non-infringement,merchantability, or fitness for a particular pur-pose. You are solely responsible for determiningthe appropriateness of using or redistributing theWork and assume any risks associated with Yourexercise of permissions under this License.

8. Limitation of Liability. In no event andunder no legal theory, whether in tort (includ-ing negligence), contract, or otherwise, unlessrequired by applicable law (such as deliberateand grossly negligent acts) or agreed to in writing,shall any Contributor be liable to You for damages,including any direct, indirect, special, incidental,or consequential damages of any character arisingas a result of this License or out of the use or in-ability to use the Work (including but not limitedto damages for loss of goodwill, work stoppage,computer failure or malfunction, or any and allother commercial damages or losses), even if suchContributor has been advised of the possi