VIATRA2/Components

Outdated page

This page contains obsolete information about the VPM based VIATRA2 and preserved for archive purposes only.
The currently maintained wiki is available at http://wiki.eclipse.org/VIATRA

TODO model space, interpreter, etc.

Model space

Models and metamodels are all stored uniformly in the so-called VPM model space, which provides a very flexible and general way for capturing languages and models on different meta-levels and from various domains (or technological spaces).

Special features of the VPM model space (not supported by EMF) allows to

• enumerate all instances of a metamodel element (in addition to access the class from an instance model element)
• navigate references (relations) in both directions
• assign multiple types for a model element (multi-domain editing)
• reliable and simultaneous manipulation of metamodels and models (to enable generic / higher-order transformations)

This model space can be populated by various importer plugins including support for

• UML2
• BPEL and other business process modeling notations
• various domain-specific models (using XML or EMF-based model representations)

Transformation Language

Since precise model-based systems development is the primary application area of VIATRA2, it necessitates that (i) the model transformations are specified in a mathematically precise way, and (ii) these transformations are automated so that the target mathematical models can be derived fully automatically. For this purpose, VIATRA2 have chosen to integrate two popular, intuitive, yet mathematically precise rule-based specification formalisms, namely, graph transformation (GT) and abstract state machines (ASM) to manipulated graph based models.

• (Graph) Patterns are the basic concept in defining model transformations within VIATRA2. A pattern is a collection of model elements arranged into a certain structure fulfilling additional constraints (as defined by attribute conditions or other patterns). Patterns can be matched on certain model instances
• Elementary model manipulation is specified by graph transformation rules. Like OCL, graph transformation rules describe pre- and postconditions to the transformations, but graph transformation rules are guaranteed to be executable, which is a main conceptual difference. Upon successful matching of the precondition pattern, the graph transformation rules changes the underlying model elements according to the postcondition pattern.
• Graph transformation rules are assembled into complex model transformations by abstract state machine rules, which provide a set of commonly used imperative control structures with precise semantics.

Advanced features of the VIATRA2 transformation language (called VTCL) are

• Pattern composition (for pre and postcondition patterns)
• Recursive (graph) patterns
• Negative patterns with arbitrary depth of negation

Pattern matcher

Role

The pattern matcher is the component responsible for finding the occurrences of the defined VTCL patterns. The pattern matcher is invoked whenever the interpreter executes a forall or choose construct having a with find somepattern(...) or with apply somegtrule(...) clause. The first invokation of a certain pattern might last longer due to pattern analysis, search plan generation, and other preparatory tasks.

Alternatives

VIATRA2 R3 ships with two alternative pattern matcher engine.

The local-search based default pattern matcher searches the model space each time a pattern query is requested. Pattern matching may consume a significant amount of time on each query, but no other maintenance costs arise.

The incremental pattern matcher has a radically different approach: the occurrence set of patterns is constructed on their first usage, preserved in-memory and maintained from that time on. After each model manipulation step, the necessary local changes to these stored occurrence sets are calculated and the updates are performed. The great advantage of the incremental pattern matcher is that pattern queries can be fulfilled virtually instantly, as the result set is already available. The disadvantages are that model manipulation costs are somewhat increased due to the maintenance of occurrence sets, and the stored results sets may consume a significant amount of memory. It is recommended to use the incremental pattern matcher engine with a high amount of memory allocated to the Java VM.

Our measurements and experiments show that choosing the incremental pattern matcher may improve performance by several orders of magnitude in some cases. If large models are used with frequent pattern matching queries and relatively minor model changes, consider using the incremental pattern matcher.

Important note: the incremental pattern matcher currently does not inline (flatten) patterns, and therefore does not support locally unresolvable pattern variables. An example of an unsupported pattern would look like this:

pattern incompletePattern(A,B) = 
{ 
  Type(A); 
  // no declaration of B
  check(value(A) == value(B)); 
}

Selecting the pattern matcher engine

@incremental
pattern myIncrementalPattern(X,Y) = 
{
   /* ... */
}
 
@localsearch
pattern myLocalSearchPattern(A,B) = 
{
   /* ... */
}

With annotations, you can select on a per-pattern basis which pattern will be matched incrementally and which with local search. It is your responsibility that if patterns call each other, you have to make sure that each pattern along the call chain is used with the same annotation. To avoid annotating each pattern, the same annotations can be applied on a per-machine basis to provide machine-level defaults. Per-pattern annotations can be used to locally override the machine default.

You can also use these annotation on a per-gtRule basis to select which pattern matcher to use for matching the LHS side of a gtRule. Machine level annotation also sets the default matcher for the GT matcher.

@incremental
pattern myIncrementallyMatchedGTRule(X,Y) = 
{
   /* ... */
}
 
@localsearch
pattern myLocallyMatchedGtRule(A,B) = 
{
   /* ... */
}

Initial experience shows that combining the two pattern matcher can easily result in a low memory consumption but fast matching strategy.