The Simple Pattern Matching Strategy

Implementation of pattern matching for MOLA uses the local search plan generation strategy. This is one of the most popular strategies, however typically it requires a sophisticated analysis of pattern or even underlying model to choose the best search plan. A simple algorithm (in the sense of how complex is the implementation) is proposed which is efficient for the typical MOLA patterns used in MDSD-related tasks (it is efficient also for others if appropriate constructs are used). The simple algorithm uses the following principles:

• if the pattern contains a reference class element, then the pattern matching starts from

the reference (if there are more than one, then an arbitrary is chosen).

• otherwise the pattern matching starts from the loop variable in a loophead or from

arbitrary chosen element in a normal rule.

• pattern matching is continued with class elements accessible from already traversed

If rule pattern contains several independent pattern fragments, then these fragments are processed independently by the same principles – such fragments can be treated as separate patterns.

Pattern matching in a regular rule is started from the reference class element, if such class element exists in the pattern. Though MOLA does not require the presence of a reference class element in the pattern, the practical usage of MOLA has shown that most of the regular rules contain it. It is because the usage of imperative control structures causes reuse of the previously matched instances, which are represented by the reference class elements in MOLA. This is one of the main reasons why such simple optimization technique works almost as well as more sophisticated approaches.

Use of reference class elements is natural also in loopheads. It is common to have a loop over, for example, all properties of a given class. This task can be easily described, using a single MOLA loop, where the pattern in the loophead is given using the reference class element and the loop variable. See the loophead of the inner loop in Fig. 26 for the typical case. In this case the pattern matching is started from the reference element (@pack) reducing the search space dramatically. Of course, the path from the reference class element to the loop variable may be longer. The only restriction is that cardinalities of associations along the path (except one directly before the loop variable) should be "1" or "0..1".

For foreach loop statements without a reference in the loophead, pattern matching is started from the loop variable in the loophead. Practical usage of MOLA has shown that typical tasks are naturally programmed using patterns, where cardinalities of association links leading from the loop variable are "1" or "0..1". This causes the execution of the loop to work in a linear time dependant on the number of the instances corresponding to the loop variable. Of course, this does not apply for every example, but if an appropriate metamodelling (UML-like, using composition hierarchy) and imperative algorithms are used, then this condition holds for most cases.

Fig. 26. Transformation example - MOLA procedure building package hierarchy. Note the loophead of the outer loop in Fig. 26. Though cardinalities of association links leading from the loop variable are "0..*", the pattern matching started from loop variable is still efficient. Since class elements other than the loop variable provide the "existence semantics" (find first valid match), in practice this loop works also in linear time because almost all requirements are described using scenarios. In fact, this additional constraint is used to filter out those few cases where requirements are described using different means.

Note that this strategy does not even require the analysis of the cardinalities of metamodel elements at the same time remaining efficient in the practical usage. A similar pattern matching strategy is used also by Fujaba. The bound variable (reference class element in terms of MOLA), is even required by the pattern in Fujaba. However, the benchmark tests [52] have shown that this strategy performs as well as more sophisticated strategies. The same tests also have shown that an appropriate usage of the language constructs (improvement of Fujaba transformation) causes a significant positive impact on the performance. The same holds also for MOLA, however the feature which distinguishes both languages is the loop variable in the MOLA foreach loop. First of all, the transformation becomes more readable for human reader; secondly, it gives slight

advantage in the performance of the pattern matching. It allows iterating through the instances corresponding to the loop variable only, while other patterns elements are checked just for the existence. On the contrary, Fujaba is forced to examine corresponding instances to all pattern elements in the foreach loop.

5.6 Benchmark Results

The simple pattern matching strategy has been implemented in the MOLA Tool for MOLA language. The benchmark tests for this implementation have been carried out. The example described in the Section 4.4 has been reused. The same tests have been repeated for MOLA implementations for MIIREP, JGraLab and EMF repositories.

Table 4. Benchmark results of MOLA implementation for different repositories. Transformation execution time (ms)

Model size (N) MIIREP EMF JGraLab

1750 134 78 277 3500 266 106 388 17500 1349 378 1366 35000 2856 659 2601 87500 6872 1926 6288 175000 15222 3221 11609 350000 27614 7348 23420

The benchmark results are shown in Table 4. Since the transformation which is shown in Fig. 15 has been tested, similar measures are used. The first column depicts the size of model used for tests. The model size (N) is a total number of class instances in a source model. Transformation execution times for MOLA implementation have been shown in the next three columns. The times have been measured in milliseconds rather seconds as it was done in the previous test (see Table 1). It should be noted that the performance has been much better than for previous implementation. For example, the models of size N=3500 have been processed in less than one second in the new implementation, while the old (SQL-based) implementation executes the same transformation in 65 seconds (see Table 1).

The MOLA implementation through Lx language family and simple pattern matching strategy perform in less than 1 second for models of size N≤10000 which is a typical size of model used in MDSD. Since the example used in the benchmark is a typical MDSD transformation (all instances in a model of tree-like structure are processed), benchmark tests show that MOLA implementation is efficient for MDSD- related tasks.

It is interesting to compare also the performance of MOLA on different model repositories. For all repositories the execution times grow almost linearly against the size of a model. The EMF repository has shown the best results. Two other repositories (MIIREP and JGraLab) perform equally strong. MIIREP is better for small models, but JGraLab is better for larger models (the execution times grow slower for JGraLab). However, the difference between results is quite narrow. It should be noted, that all implementations have been tested on large source models (N=350000). They have been processed in less than a half minute. Note that in the example every source model element must be processed and target element created.

It should be noted that the performance of a repository has a great impact on overall performance of transformation technology. For example, the loading and saving EMF-based models are quite inefficient compared to the execution of transformations. For a model of size N=350000 the loading data took ~16 seconds and saving data took more than 10 minutes, while execution of transformation took just ~7 seconds. JGraLab has much better results – loading model took ~1 second and saving model after transformation took ~3 seconds. However, for all repositories the saving time of model increases non-linearly. This problem should be taken into account, but typically MDSD- related transformations are used within some modeling tool and model is saved only when a work with the tool has been ended.