The typical architecture and the basic data structures of a graph transformation module implementation are presented in Figures 3.6(a) and 3.6(b), respectively, and obtained by the analysis and the general-ization of existing approaches.
At compile-time, a graph transformation moduleis built by using a graph transformation system specification. For each rule in the specification, a corresponding rule executor is prepared, which provides rule application functionality via its apply()method. Each rule executor has a pattern matcher, which provides pattern matching functionality via itsmatch()method for the precondition of the rule, for which the corresponding executor has been generated.
A graph transformation module uses the additional data structure ofMatchings during its oper-ation. A Matchingconsists ofMappings, which can be considered as PatternNode-Object pairs. Note that in the implementation, only nodes of the patterns and their corresponding matched objects are stored explicitly in aMatching, while the mappings of edges are omitted from this data structure as links do not have identities according to our assumptions.
At runtime, rule application is initiated by selecting a rule and invoking the apply()method of its executor. An initial (partial) matching is also passed as input parameter. The behaviour of the apply()method of a rule executor is presented by the sequence diagram of Fig. 3.7.
32 CHAPTER 3. COMPUTING BY GRAPH TRANSFORMATION
interface IPatternMatcher match
RuleExecutor
update apply GraphTransformationModule
patternMatcher 1
(a) The structure of a graph transformation engine module
PatternNode
Mapping Matching
Object 0..1 0..*
value 0..*
mappings 1
0..1 0..*
patternNode
(b) Basic data structures
Figure 3.6: Typical data structures of a graph transformation engine
pm:IPatternMatcher
actor
rule: RuleExecutor
if(matchingFound) 1.2: update 1: apply(Matching m) 1.1: match
Figure 3.7: Sequence diagram for theapply()method
As it can be seen, theapply()method shows a one-to-one correspondance to the theory based definition of rule application. In this sense, activities correspond to the following two phases.
• Pattern matching. The match() method of the pattern matcher is invoked with the initial matching as input parameter. This method completes the matching by adding appropriate map-pings for initially unmatched pattern nodes.
• Updating. If a complete matching has been found in the pattern matching phase, theupdate() method of the rule executor is invoked for handling the tasks of deletion and insertion phases.
As techniques for the implementation of thematch()method are going to be discussed in details in all the upcoming chapters, sample Java codes that implement this method can be found at several locations (e.g., Listings 4.1 and 4.2 in Section 4.2.6). A Java program that describes the manipulation of models has already been presented by Listing 2.2.
3.6. CONCLUSION 33
3.6 Conclusion
In this chapter, by using the object-relational mapping example, the paradigm of graph transformation has been presented as a rule-based specification language for manipulating graph models. In addition, a distributed mutual exclusion algorithm has been introduced to represent another application scenario of graph transformation by providing a way to define the dynamic semantics of a visual language. Then an overview has been given on state-of-the-art graph transformation tools, of which representatives have been selected for our later performance measurements. Finally, a graph transformation module implementation has been discussed by presenting its typical architecture and its basic data structures.
CHAPTER
4
Pattern Matching Strategies
This chapter serves as a framework of existing, graph transformation related concepts, techniques, and heuristics, which is going to be used later for positioning the new results of this thesis. A skeletal, gen-eral purpose graph pattern matching algorithm is presented, into which all the heuristics used by both current and upcoming tools can be plugged. By analyzing this algorithm, complexity considerations of pattern matching are examined both from a theoretical and practical viewpoint. Finally, the widely used concept of search plan driven pattern matching is presented, which can be used for describing heuristics.
4.1 A general purpose graph pattern matching algorithm
As a result of intensive research, several graph pattern matching algorithms have been developed during the last decades. Some publications [25, 32, 46, 56, 89, 90, 92, 117, 131] proposed efficient pattern matching techniques for restricted classes of graphs, while others developed algorithms [29, 81, 140, 141] for graphs without structural restrictions. In the graph transformation community, variants of Ullmann [140] and VF2 [29] algorithms are used most frequently. In Algorithm 4.1, a skeleton is presented to demonstrate the typical structure of all relevant pattern matching algorithms.
The pattern matching algorithm consists of a single recursive procedurematch(k, m) which gets the recursion level kand a matchingm as its inputs. Procedure match(k, m) is initially invoked at recursion level1with a partial matchingm, which is specified outside the pattern matcher by the user, and which contains mappings for a subset of pattern nodes. Since the procedure already tries to find a mapping for the first unmapped pattern node at recursion level1, it should also be checked in the beginning bycheck(0, m)whether the initial partial matchingmrepresents a graph morphism.
If matchingmis complete, then it can be returned as a solution (Lines 1–2). If matchingmis not yet complete (Lines 3–11), then attempts are made to extend the matching. For this reason, a set of mapping candidatesP(k, m)is computed (Line 4), and then each candidate (n, o), which represents the mapping of pattern noden ofLHS (orNAC) to object o, is added to matchingm resulting in a matchingm0 (Line 6). If this new matchingm0 passes all the tests prescribed bycheck(k, m0)(Line 7), the procedurematch()can be invoked recursively in Line 8 with parametersk+ 1and matching m0.
35
36 CHAPTER 4. PATTERN MATCHING STRATEGIES
Algorithm 4.1The skeletal pattern matching algorithmmatch(k, m)
PROCEDURE match(k, m){kis the recursion level, andmis the initial partial matching}
Initially: k= 1andcheck(0, m) =true{The algorithm is initially invoked at recursion level 1, and it checks whether pattern edges that connect pattern nodes contained by the initial partial matchingmcan be mapped to links in the model.}
1: ifmrepresents a total morphism fromLHSto modelM then 2: return m
3: else
4: Compute the set of mapping candidatesP(k, m) 5: for all(n, o)∈P(k, m)do
6: m0:=m∪(n, o){Compute the morphismm0obtained by adding(n, o)tom}
7: ifcheck(k, m0){Verifies whetherm0is a morphism}then 8: return match(k+ 1, m0)
9: end if 10: end for 11: end if
Implementations of the pattern matching algorithm (in different GT tools) typically differ from each other in the technique of computing mapping candidates and checking extended matchings in Lines 4 and 7, respectively. In this sense, the above skeletal algorithm provides auniform descriptionfor all the existing and new pattern matching strategies and heuristics. In order to be able to analyze these algorithm variants, we need an appropriate formalism for describing the search space being traversed by Algorithm 4.1 during pattern matching.
4.1.1 Search space tree
For this reason, asnapshotis constructed from the input parameters (i.e., recursion depth levelkand matchingm), whenever thematch()method is invoked. These snapshots are then organized into a search space tree by also taking into account the method invocation hierarchy of Line 8.
Asearch space tree (SST)is a tree having snapshots as its nodes. The root of the tree is on the0th level of recursion and it corresponds to the initial snapshot that has been prepared, when thematch() method is invoked from outside the pattern matcher (i.e., from the rule executor) with recursion level 1and with the initial partial matching. A snapshot nodes0 consisting of recursion levelk+ 1and a (partial) matchingm0 appears on thekth level of the search space tree as a child of snapshot nodes representing recursion levelkand (partial) matchingm, ifm0 has been obtained frommby executing Line 6 on thekth recursion level at some time during pattern matching. Consequently, if a pattern has lnodes to be matched (l≤ |VLHS|), then the search space tree has at mostl+ 1levels, and only nodes on thelth level may denote complete matchings for the pattern.
Example 9 A sample search space tree is depicted by Fig. 4.1. This tree can be generated by a pattern matching process, which tries to search for matchings forGiveRuleof Fig. 3.5(i) in the instance model of Fig. 3.4(b) by seeking mappings for pattern nodes in theP1,P2,Rorder.
In this case, thematch()method has been invoked with the empty matching as it is shown by the root of the tree. On the second level, such snapshots can be found, which correspond to matchings, in which only pattern nodeP1has been mapped. As it is shown by Fig. 4.1, pattern nodeP1is mapped to processesp1,p2,p3, andp4. Snapshots on the third level represent matchings, in which pattern nodes
P1, and P2are already mapped. For each process assigned to pattern node P1, there is exactly one
4.1. A GENERAL PURPOSE GRAPH PATTERN MATCHING ALGORITHM 37
Figure 4.1: A sample search space tree
following process in the ring that can be a mapping of pattern nodeP2. This is reflected in Fig. 4.1 by the fact that each snapshot on the second level has exactly one child.
4.1.2 Complexity analysis of pattern matching and updating phases
From a theoretical viewpoint, no fast algorithms can be guaranteed to exist for graph pattern matching, as it leads to the subgraph isomorphism problem, for which NP-completeness has been proved [5]. The exponential worst-case complexity of the pattern matching phase can be easily demonstrated by the following example.
Example 10 Let us suppose that (i) the metamodel has a single node and edge type, (ii) the instance model is a directed complete graph, in which each pair of nodes is bidirectionally connected to each other (as in Fig. 4.2(a)), and (iii) theLHSpattern is a path graph (like the one in Fig. 4.2(b)). In such a situation, ifall the matchingsare aimed to be listed, then even this enumeration requires an exponential number of steps, and no analysis and heuristics can help to speed-up the pattern matching process.
n1:Node
(a) An instance model: a complete graph with6objects
n1:Node
(b) AnLHSpattern: a path graph with4nodes
Figure 4.2: Illustrative example for the complexity analysis of pattern matching
If injectivity checking is omitted from the pattern matching process and the evaluation order ofLHS nodes is fixed (e.g., to a left-to-right order in this case), the size of the SST can be estimated as follows.
The leftmost node of theLHScan be mapped to|VM|objects. For each such mapping, the second node of theLHScan be independently fixed to|VM| −1objects, and this argument can be repeated for all the remaining nodes of theLHS. As a consequence, the size of the SST is inO
|VM||VLHS|
, and each leaf of the SST denotes a matching for theLHSpattern in the instance model. The situation is even worse,
38 CHAPTER 4. PATTERN MATCHING STRATEGIES
if nodes of theLHS are allowed to be processed in an arbitrary order, since this gives an additional
|VLHS|!factor for the size of the SST as each matching is enumerated that many times.
Fortunately, in practical model transformation problems of software engineering, search space can be reduced due to several reasons.
• The size of LHS graphs are typically constant except for some rather exotic approaches like shaped hypergraph transformations. This makes the time complexity to be bound by a polyno-mial, in which the exponent is also constant but not necessarily small.
• Instance models from software engineering domains are always sparser than the one in Fig. 4.2(a). In a typical situation, an object is connected via links to a couple of other objects, but not to all objects in the model. As a consequence, if each object stores links to its neighbourhood and navigation is always performed only to the neighbours of a given object, this can reduce the search space significantly by the ratio of neighbouring objects and all objects.
• Metamodels typically contain more than one class and association, which means that only type conformant objects and links have to be enumerated when a matching is being extended. In a typical model repository, neighbours of an object are stored separately according to the type of the connecting link. As a consequence, if navigation is performed only along links of a given type, this can further cut the search space by simply omitting such neighbours that can only be reached via a link of a different type.
• Instance models are typically less regular than the one in Fig. 4.2(a). Irregularities in instance models and LHSpatterns increase the gap between the size of search spaces that are traversed according to differentLHSnode orders. This opens up the way to construct heuristics to reduce the search space by fixing a good (or ideally an optimal)LHSnode evaluation order for pattern matching. Note that finding such an order constitutes a highly critical part in the process of pattern matching.
• A fifth source of state space reduction stems from injectivity checking, which disallows different LHSnodes of the same type to be mapped to the same object in the instance model.
By using the above techniques for typical model transformation problems from the software engi-neering industry, the size of the SST (i.e., the “practical complexity” of graph pattern matching) can be reduced to a scale, which can be overapproximated by a linear or quadratic function of the model size in many applications.
The complexity of the updating phase is linear in the size of the graph transformation rule (i.e., O(|VLHS|+|VRHS|+|ELHS|+|ERHS|)), even if only a rough estimate is used, as at most that many objects and links can be deleted or created.
As a consequence of this short analysis, the rest of this thesis focuses on the performance issues of the pattern matcher as it has significantly larger influence on the overall behaviour and performance of the graph transformation module. This huge gap between the significance of the two phases is also reflected by the detailedness of discussions on pattern maching and updating phases in each of the upcoming chapters.
It is worth emphasizing that the above-mentioned theoretical complexity analysis does not take into account several factors, which might cause significant performance degradation in practice, which obviously affects the measurement results. These factors include the tasks related to querying and updating indexes or to the administration of large number of objects and links, which might influence both the pattern matching and the updating phase.