A number of sample Graph Transformaton Systems demonstrating the various features of GROOVE can be found (and downloaded collectively) at https://github.com/nl-utwente-groove/samples. Here is a list.
-
attributed-graphs. This demonstrates the syntax for attributed graphs and rules. GROOVE has a user syntax and a system syntax for attribute manipulation; though it is unlikely that you will need the latter, the rules are given in both versions.
-
attribute-types. This shows that (attribute and normal) edges with the same name are distinguished by teir target type, and also that attribute edges can be individually deleted and created (like normal edges) but also changed (which amounts to simultaneous deletion+creation, and is closer to the way we usually think of edges).
-
bridge.gps. This is a tour-de-force example of how to use a combination of Groovy and so-called “nodified edges”. (The latter is a special rendering mode for nodes so they look more like edges.) Check the Groovy tab and the type graph to see how this is done.
-
circular-buffe. This is a prototypical rule system, used in many tutorials, showing the basic features of GROOVE: ordinary rules that delete, create and forbid nodes and edges, as well as the effect of unifying isomorphic states. The rule system models a first-in-first-out buffer.
-
colours.gps. This shows the colouring feature of GROOVE: nodes can have a colour determined by their node type, or an individual colour set in the start graph or changed by a rule application. It should be noted that colours are not part of the graph structure, and so two graphs can be isomorphic despite being differently coloured.
-
control.gps. A demonstration of rule control, without parameters, on the basis of a simple, three-rule model in which passengers get on and off trains, and trains move over a track. There are three different control programs that order the passenger transfer slightly differently.
-
copy-graph.gps. This demonstrates three features: nested rules, label variables and conditional creation. One rule,
copyNodes
, copies all nodes, using a specialcopy
-edge to retain the connection between the originals and their copies. Node creation is conditional, usingcnew:
rather thannew:
, to ensure that only nodes that do not already have a copy get one. The rule is quantified non-vacuously so that if there is no node without a copy, the rule does not get applied. A second rule,copyEdges
, also non-vacuously quantified on the outer level, copies over all edges from the original nodes to their copies, using a label variable to cover all possible labels in one go; and it also deleted the specialcopy
-edge introduced bycopyNodes
. -
copy-graph-typed.gps. This is a variation on copy-graph.gps above in which the graphs are typed. The difference is visible in several respects: there are two type graphs, one called
type
which serves to type the copyable graphs themselves, and one calledcopy
which contains the additional structure necessary to make the rule system work; notably,copy
introduces aTop
type of which all others are subtypes, as well as the specialcopy
edge type used to connect the copy of a node with its original. Furthermore, the type labels of the nodes get created during thecopyNodes
rule, whereas thecopyEdges
rule also copies flag, apart from binary edges. Since we need to copy both flags and binary edges, this requires a conjunction of two universally quantified sub-rules; in order for that to work, we need an existential quantifier in between the outer and the inner universals - otherwise, the inner ones would be disjunctively interpreted, meaning that for all nodes, either their outgoing edges or their flags get copied. -
counting.gps. This demonstrates a primitive kind of counting, achieved by local injectivity constraints (in this case, negative ones). A more advanced counting mechanism exists in the form of
count
-edges of universal quantifiers; see