The GROOVE Tool Set

As mentioned in Chapter 1, the Groove project is centered around the veri- fication of object-oriented systems. The Groove Tool Set mainly focuses on the generation of transition systems from graph production systems that specify the behaviour of programs by means of graph transformation rules. In the next paragraphs, we will give a short description of the tools included in the Groove Tool Set, and discuss their main features.

2.3 Tools in the Field

The Groove Tool Set has been written entirely in Java and comprises ap- proximately 400 classes and 150,000 lines of code. Basically, the Groove Tool Set consists of the following tools:

• the Groove Simulator, • the Groove Generator, • the Groove Editor, and • the Groove Imager.

The Groove Simulator provides functionality for constructing state spaces from graph production systems manually (in a single step-wise fashion) or au- tomatically (using different exploration strategies, discussed later on) through a graphical user interface. The Groove Generator is a command-line tool which can be used to generate partial or full graph transition systems without the graphical user-interface. For finite graph production systems the Groove Generator can be configured such as to store the set of all final states of the corresponding graph transition system (if there are any). The main advantage of the Groove Generator above the Simulator is that no time is spent on ex- pensive graph rendering algorithms and no memory is used for constructing the corresponding data structures needed for that. The Groove Editor provides a graphical user interface for specifying graphs to be transformed and graph pro- ductions. Finally, the Groove Imager enables one to generate pictures from graphs or graph productions in various types of formats, among which, JPG, PNG, and EPS.

2.3.1.1 Single Graph Rule Presentation

In contrast to traditional approaches where graph transformation rules are depicted by separate graphs for the left-hand-side (LHS), the right-hand-side (RHS), and NAC s, Groove represents rules in a single graph, using colours to distinguish the different roles graph elements can fulfill. We distinguish between the following roles:

• reader: reader elements are graph elements that are both in the LHS and the RHS. In the rule they are depicted as solid black boxes (nodes) and arrows (edges);

• eraser: eraser elements are graph elements that are in the LHS only. They are depicted as dashed blue (gray, in a black-and-white printout) boxes and arrows;

Chapter 2. Background in Graph Transformation

• creator: greater elements are those nodes and edges that are in the RHS only. In the rule they are visualized as solid fat green (light gray) boxes and arrows;

• embargo: embargo elements represents negative application conditions. They are depicted as dashed fat red (fat gray) boxes and arrows.

Figure 2.17: Single graph representation of the put-rule from Fig. 2.14.

Exploration Strategies. Both the Groove Simulator and the Groove Generator

can be used to generate state spaces automatically using different exploration

strategies. For arbitrary graphs, there can be a set of rule applications, all

leading to different (or isomorphic) graphs. Which rule application to explore depends on the specific explore strategy chosen. In Groove, a variety of strate- gies have been implemented, among which are:

• full: for every reachable graph (starting from the start graph), all rule applications are explored;

• linear: for every graph, a single rule application is selected and explored. This strategy basically results in a linear execution path of the system; • barbed: the resulting state space will look like barbed wire. This means

that for every graph all rule applications are computed and added to the graph transition system as transitions. From the set of successor graphs, only one is selected for further exploration. This strategy can be useful when one is interested in local state properties along a linear path; • edge-bounded: this strategy expects as input an upperbound on the num-

ber of the edges with a specific label that may occur in a graph for it to be further explored. For example, given ‘Cell =50’, this strategy explores all graphs containing less than 50 edges labelled Cell.

2.3 Tools in the Field

Priorities. The application of transformation rules can be further controlled by prioritizing the rules. Each rule can be assigned a single priority. The transformation engine will always first try to apply a rule from the set of rules with highest priority (0 being the lowest priority). Whenever a rule has been applied, new rule applications will again be computed for rules with the highest priority first.

Isomorphism Checking. One advantage of the graph formalism is that symme-

try among states can be recognized through isomorphic graphs. In Groove, a mechanism has been implemented which is based on so called graph certificates for determining whether two graphs are isomorphic [158]. The basic idea is that all graph elements (nodes and edges) are assigned a number, the certificate, that is invariant under isomorphism. The certificate of the entire graph is then composed from the individual element certificates deterministically. Such cer- tificates can then be used as a heuristic for identifying isomorphic graphs in a (previously computed) set of graphs. For state space exploration in Groove this means that whenever a rule application results in a graph G′ isomorphic to a graph G that is already in the state space, G will be used as the target graph and G′ _{does not need to be further explored. This is the reason why,}

in the circular buffer example from Section 2.2.2, the application of a get-rule immediately after the application of a put-rule (and vice versa) results in the same (isomorphic) graph (cf. also Def. 2.13 and Fig. 2.16).

Input/Output. In Groove, both graphs and transformation rules are stored ex- ternally in the GXL format [199], which is an XML-based format designed to be a standard exchange format for graphs. Graph grammars are stored in di- rectories whose names end with “.gps”. Graph grammars can be nested to an arbitrary depth.