In the current chapter, I elaborated an adaptive method for executing model-specific search plans in order to improve the performance of graph transformation in its pattern matching phase.
• Costs and optimization mechanisms for model-specific search plans. I defined a cost function for model-specific search plans which estimates the size of the search space that would be traversed during search plan execution. In order to find a low cost search plan according to the special cost function defined for model-specific search plans, I elaborated an optimization technique by customizing traditional greedy algorithms (Sec. 7.3).
• Adaptive graph transformation engine. I elaborated an adaptive graph transformation engine which is able to select the optimal pattern matching strategy at execution time from the set of precompiled strategies by exploiting run-time model statistics (Sections 7.4.1 and 7.5.1).
• EJB3-based prototype engine. I prepared an EJB3-based prototype of the adaptive graph trans-formation engine for the Java 2 Enterprise Edition (J2EE) platform by generating code for pattern matching and cost calculation functionalities of concrete strategies, and by implementing a state-less session bean that selects the optimal strategy at run-time (Sections 7.4.2 and 7.5.2).
• Quantitative evaluation of Java, EJB3 and EJB QL based pattern matching. After fixing a com-mon search plan, I examined and compared the efficiency of Java, EJB3 and EJB QL based pattern matching implementations on a benchmark example (Sec. 7.6).
The above-mentioned results are published in [7, 63, 64, 148, 152, 156]. The results of this chapter have been integrated into the VIATRA2 model transformation framework [142, 143, 144].
Relevance
It is worth noting that the main contributions of the current chapter (i.e., model-specific search plans and the adaptive pattern matching technique) constitute an orthogonal framework of novelties so their relevance can be evaluated independently and also in combination.
Concepts of model-sensitive search plans are directly applicable to further fine-tune the perfor-mance of any compiler-based GT approaches. This statement is confirmed in [51, 132] by the devel-opers of GrGen tool who independently develop the same technique [10, 11] with minor differences in operation cost assignment and search plan cost calculation. A recent paper [12] reported about a new heuristics called Backtracking Lookup by introducing costs for edge lookups, which may further
7.7. CONCLUSIONS 123
accelerate pattern matching in scenarios originating from compiler construction application domain.
GrGen generates search plan driven strategies as C# code, in contrast to our approach, which produces EJB3 compliant Java code. GrGen has no predefined scheduling strategies for cost recalculation. This task can be initiated on request from the GrShell. Each time a search plan cost is recalculated, a cor-responding pattern matching strategy is generated, which can later be dynamically linked into GrGen.
(For comparisons to sophisticated pattern matching strategies of compiled (but non-model-sensitive) graph transformation approaches see Sec. 7.1.)
The combination of adaptive and model-sensitive pattern matching techniques can be used in in-terpreted GT engines as well. If model-specific search graphs are used, then a single low cost search plan can be dynamically prepared at run-time at each rule invocation by using the current adornment and the statistics of the instance model under transformation. In this sense, the pattern matching is always guided by a low cost strategy with respect to the current instance model in contrast to compiled GT engines, which can only select the optimal from the set of precompiled pattern matching strategies.
As a common practical application field of this combined technique, the model transformation frame-work of VIATRA2 should be mentioned as all these contributions are currently being built into its new interpreted graph transformation engine.
The adaptive, model-sensitive pattern matching technique has been recently analyzed quantitatively in [12] by using the benchmarking framework of Chapter 5. In this survey, the authors prove the feasibility of the adaptive approach by demonstrating a strong correlation between search plan costs and pattern matching execution time, which means that the cost model having been presented in Sec. 7.4.1 can be successfully used for estimating the performance of pattern matching.
In the future, adaptivity and model-specific search plans are aimed to be integrated into the generic framework [64] of search plan operations to make its cost assignment dynamic and model dependent by replacing the current static, heuristics-based method. In this sense, this generic framework enables the proper and performance optimal positioning of complex search plan operations (such asNACchecking and the invocation of recursive patterns [152]).
Limitations
It should be emphasized that this chapter presentedpractical heuristicsfor pattern matching. Neither the technique of model-specific search plans, nor the approach of adaptive graph pattern matching can be provenly optimal by their nature due to the following reasons.
First of all, counters of the model repository store aggregated statistical data, which obviously cannot reflect the exact structure of the instance model. Even if all counters share the very same values, the underlying instance models can produce significantly different number of matchings. As a direct consequence, a low cost search plan cannot guarantee a small search space tree during execution.
As counters are used both at compile-time and at run-time for search plan optimization and for cost calculation, respectively, the pattern matching strategy that is executed finally in theExecphase is not necessarily optimal. Refining data structures that store statistics in the model repository can be an obvious way to improve the precision of both techniques, but such an approach can easily become unfeasible due to increased storage or computation efforts caused by the refinement. Note that the success of adaptive graph pattern matching is highly sensitive to the time spent on cost calculation, which is based on the data structures of the repository.
The other problem stems from the special cost function that has been defined for search plans.
The customized greedy algorithms can only provide low cost, but not necessarily optimal search plans.
From a pure mathematical point of view, it is easy to find counterexamples for the optimality of the
124 CHAPTER 7. ADAPTIVE GRAPH TRANSFORMATION
presented algorithms, but these examples are rarely produced by real-life application domains and even in such cases the generated low cost search plans provide good solutions.
Finally, as a general guideline, it can be stated that adaptivity only pays off, if the runtime gain caused by the execution of a low cost strategy exceeds the time spent on cost calculation.
CHAPTER
8
Incremental Graph Transformation
In this chapter, I present the foundations of an incremental graph pattern matching engine for handling rules with negative application conditions, which keeps track of existing matchings in an incremental way to reduce the execution time of graph pattern matching.
8.1 Motivation
Despite the large variety of existing graph transformation tools, the implementation of their graph transformation engine typically follows the same principle. First a matching occurrence of the left-hand side of the graph transformation rule is searched by some sophisticated graph pattern matching algorithm. Then potential negative application conditions are checked that might eliminate the previous occurrence. Finally, the engine performs some local modifications to add or remove graph elements to the matching pattern, and the entire process starts all over again.
As the information on a previous matching is lost when a new transformation step is initiated, the complex and expensive graph pattern matching phase is restarted from scratch each time. This non-incremental behaviour can be a performance bottleneck as demonstrated e.g., by our benchmarking experiments [154] and by practical experience in model-based tool integration [80] based on triple graph grammars [120].
Related work
Incremental updating techniques have been widely used in different fields of computer science. Now a brief overview is given on incremental techniques that could be used for graph transformation.
• Rete networks. [22] proposed an incremental graph pattern matching technique based on the idea of Rete networks [45], which stems from rule-based expert systems. In their approach, a network of nodes is built at compile time from theLHSgraph to support incremental operation.
Each node performs simple tests on the entities (i.e., nodes, edges, partial matchings) arriving to its input(s). If the test succeeds, the node groups entities into compound ones, which are then sent downwards in the network. On the top level of the network, there are nodes with a single input that let such objects and links of a given type to pass that have just been inserted to or
125
126 CHAPTER 8. INCREMENTAL GRAPH TRANSFORMATION
removed from the model. On intermediate levels, network nodes with two inputs appear, each representing a subgraph of theLHS. These nodes try to build matchings for the subgraph from the smaller matchings located at the inputs of the node. On the lowest level, the network has terminal nodes, which do not have outputs. They represent the entireLHS graph. Entities reaching the terminals represent complete matchings for theLHS.
• PROGRES. The PROGRES [122] graph transformation tool supports an incremental tech-nique called attribute updates [66]. At compile-time, an evaluation order ofLHSnodes is fixed by a dependency graph. At run-time, a bit vector is maintained for each object expressing whether it can be bound to the nodes of theLHS. When objects are deleted, some validity bits are set to false according to the dependency graph denoting the termination of possible partial matchings.
In this sense, PROGRES performs immediate invalidation of partial matchings. On the other hand, validation of partial matchings are computed on request (i.e., when a matching for theLHS is requested).
• TefKat. TefKat [82] is a declarative model transformation language together with an execution engine implemented as an Eclipse plugin. The transformation engine performs an SLD resolu-tion based interpretaresolu-tion during which a search space tree is constructed to represent the trace of transformation execution. This tree is maintained incrementally in consecutive steps of transfor-mations as described in [59].
• View updates. In relational databases, materialized views, which explicitly store their content on the disk, can be updated by incremental techniques. Counting and DRed algorithms [57] first calculate the delta (i.e., the modifications) for the view by using the initial contents of the view and base tables and the deltas of base tables. Then the calculated deltas are performed on the view.
These techniques only provide partial solutions for typical model transformation problems as PRO-GRES supports pattern matching in such cases when the rule precondition is a connected graph [98], while the Rete-based approach lacks the support for negative application conditions and inheritance.
Objectives
I propose foundational data structures and algorithms for incremental graph pattern matching where all complete matchings (and also non-extensible partial matchings) of a rule are stored explicitly in a tree according to a given search plan. This tree is updated incrementally triggered by the modifications of the instance model. Negative application conditions are handled uniformly by storing all matchings of the corresponding patterns. Additionally, we keep track if a matching of the negative condition pattern invalidates the matching of the positive pattern. Furthermore, as the main conceptual novelty, we introduce a notification mechanism by maintaining registries for quickly identifying those partial matchings, which are candidates for extension or removal when an object or a link is inserted to or deleted from the model.
Architectural overview
In Figure 8.1, an architectural overview is provided on the envisaged workflow of an incremental pattern matching engine. Note that a main driver of this architecture is to allow easy adaptation to existing GT engines.
8.1. MOTIVATION 127
Tool-specific pattern generator GT rule 1 GT rule n
Pattern 1 Pattern n
Pattern merger and optimizer
Pattern 1*
Pattern k*
Model traversal Metamodel Model
Tool-specific event converter
Modification event
Query/
Result
Search plan and code generator
Incremental pattern matching
engine Preprocessing phase Initialization phase Operation phase
Figure 8.1: Architectural overview of incremental pattern matching
Preprocessing. In a preprocessing phase, patterns are first extracted from graph transformation rules (based upon theLHSandNACof the rules). Since these patterns may be overlapping, this initial set of graph patterns can be optimized by merging them along common parts to be maximized and by extending overlapping areas to original individual patterns. Afterwards, search plans are derived for the optimized pattern set, and template-based code generation is applied to implement the matching tree tailored to the actual GT rules.
Initialization. In the initialization phase, the tree is constructed based upon a given initial model and its metamodel. While this initialization step can be time consuming, this is only performed once, prior to the actual transformations.
Operation.In the operation phase (which is the main focus of the current chapter), the incremental pattern matching engine listens to the notifications sent by the GT engine on model modifications, and keeps track of the changes in the tree. As a consequence, pattern matching queries coming from the GT engine are executed in constant time.
The basic structure of the current chapter is the following.
• Section 8.2 introduces few new concepts to ease the presentation of incremental pattern matching.
• Section 8.3 presents data structures needed for maintaining, efficiently storing, invalidating, and notifying partial matchings, and for accelerating the retrieval of complete matchings.
• Section 8.4 first presents the core algorithm of the incremental pattern matcher, which is invoked whenever the model is changed, then it demonstrates the incremental operation on an example, and finally, details of the main modification event handler methods are reviewed.
• Section 8.5 assesses the computational efficiency of the incremental approach, and compares it to the run-time performance of FUJABA using the object-relational mapping of Section 5.4 as a benchmark example.
• Section 8.6 presents an alternative method for incremental graph transformation by persistently storing partial matchings in tables of an underlying relational database and by executing SQL commands for reconstructing the database content based on the modifications of the instance model.
• Section 8.7 concludes this chapter with summarizing its relevance.
128 CHAPTER 8. INCREMENTAL GRAPH TRANSFORMATION