Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA2/Frequently Asked Questions

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

General

What is VIATRA2?

VIATRA2 is a model transformation tool integrated into Eclipse. TODO

Is it available for free?

Yes. VIATRA2 is licensed under the Eclipse Public License v1.0.

How do I obtain Viatra2?

See VIATRA2/Installation.

How do I give feedback (bug reports, improvement ideas, experiences, observations)?

There are multiple possibilities:

VTML metamodeling

How to reference relations correctly in VTML?

A frequent mistake when specifying relations in VTML is demonstrated in the following example:

namespace Meta;
entity(Container)
{
  entity(Element);
  relation(list,Element,Element);
  relation(next,list,list); // <-- error: "Source (Meta.Container.list) for relation next undefined."
}

Here, the user wishes to state that the relation "next" can point from a "list" instance to another "list" instance. However, the "list" metamodel element, by definition, is in the namespace of its source (list), whose FQN is also derived using this rule (thus, the FQN of "list" is Meta.Container.Element.list, and the FQN of "next" is Meta.Container.Element.list.next). Therefore, the error message is returned from the VTML parser.

The correct way of referring to relations is always using their "relatively qualified name", relative with respect to the defining context (Container in the example).

namespace Meta;
entity(Container)
{
  entity(Element);
  relation(list,Element,Element);
  relation(next,Element.list,Element.list); // correct
}

How to separate information for the multiple (meta)models in multiple VTML files?

Say we have a metamodel with a relation:

entity(Meta)
{
  entity(A);
  entity(B);
  relation(R,A,B);
}

We want to have another metamodel which "refines" the original one (second VTML file):

import Meta;
entity(Meta_Refined)
{
  entity(C);
  entity(D);
  relation(R2,C,D);
  superTypeOf(A,C); // works because of the import declaration
  superTypeOf(B,D);
}

We export the "refinement" information for the relation in a third VTML file:

import Meta.A;
import Meta_Refined.C;
superTypeOf(R,R2); // <-- problematic

The VTML importer complains that the source for relation R (Meta.A) does not exist, when it clearly exists.

This can be worked around if one imports the parent namespaces, and refers to the relations with their relative qualified names:

import Meta;
import Meta_Refined;
superTypeOf(A.R,C.R2); // correct

What are VPM/VTML relation multiplicities and how can I use them?

In the case of VPM/VTML, relation multiplicites are only markers, which means that the VIATRA modelspace does not enforce their validity but only reports if they do not hold. The reason for this is that (temporarily) inconsistent states must be allowed in order to allow model manipulation (either by the user or by a transformation).

The following relation multiplicities can be defined:

  • one_to_one: 1-1 relaction, every source element can reference at most one target element, and the same in the reverse
  • one_to_many: 1-*, every source element can reference an arbitrary number of target elements, but each target can reference at most one source
  • many_to_one: *-1, every source element can reference at most one target element, but each target can reference an arbitrary number of source elements
  • many_to_many: *-*, every source can reference an arbitrary number of targets and vice-versa

An example:

entity(Meta)
{
	entity(A);
	entity(B);
	relation(R,A,B);
	multiplicity(Meta.A.R,one_to_many);
}
/* a valid model configuration */
entity(Model)
{
	Meta.A(Src);
	Meta.B(Trg0);
	Meta.B(Trg1);
	Meta.A.R(R0,Model.Src,Model.Trg0);
	Meta.A.R(R1,Model.Src,Model.Trg1);
}

Patterns and pattern language

What does the warning "Target end of Relation cannot be resolved locally" mean?

Such a warning means that your pattern definition does not contain a type constraint for the target end of a relation:

pattern dangerous(A,B) =
{
  SomeType(A);
  EdgeType(R,A,B);
}

You get the warning because such patterns are dangerous in the sense that you can get run-time errors if you pass incorrect parameters to this pattern (e.g. a simple string constrant instead of a model element). Therefore, it is strongly recommended to include a type constraint for every variable that appears in the pattern:

pattern dangerous(A,B) =
{
  SomeType(A);
  OtherType(B); // <-- correction
  EdgeType(R,A,B);
}

This is also necessary for the correct operation of the incremental pattern matching engine.

Can patterns (or a single pattern) reference each other recursively?

Yes. However, the recursion should be well-founded. In certain cases, pattern systems that are not well-founded (but have a sensible fixpoint) are also acceptable, but ensuring their correct behaviour is is the responsibility of the pattern engineer.

Can patterns and gtrules be referenced from other VTCL machines?

Yes. The fully qualified name of the pattern/gtrule should be used instead of the short name. The same applies for VTCL rules.

Example:

machine1.vtcl

namespace mydomain.mysubdomain;
machine mymachine {
...
pattern mypattern(X) = {
...
rule myrule(in X) = ...
...

machine2.vtcl

machine myothermachine {
...
pattern composite(A) = {
      find mydomain.mysubdomain.mymachine.mypattern(A);
...
rule somerule(in C) = seq{
      call mydomain.mysubdomain.mymachine.myrule(C);
      forall A in C with find mydomain.mysubdomain.mymachine.mypattern(A) do ...

The pattern matcher seems to discard some occurrences of my patterns. Why?

VTCL has injective pattern matching semantics; in other words, pattern occurrences have to be isomorphic to the pattern graph. The practical implication is that no two pattern variables in the same pattern body can take the same value; such occurrences will be rejected. Patterns should be designed with this important phenomenon in mind.

The only exception is explicit variable assignment (e.g. A=B).

Example:

 pattern fullsiblings(X, Y) = {
      person(X);
      person(Y);
      person(Parent1);
      person(Parent2);
      person.parent(PX1, X, Parent1);
      person.parent(PX2, X, Parent2);
      person.parent(PY1, Y, Parent1);
      person.parent(PY2, Y, Parent2);
 }
As Parent1 and Parent2 are not allowed to coincide due to injectivity, X and Y need two separate common parents. Therefore this pattern does not match half-siblings. Injectivity also keeps X and Y separate, so a single person with two parents does not fit the pattern either.

If you do not need injectivity, you can use shareable patterns, which are non-injective by default (although they do have opt-in injectivity). See the graph pattern examples for more explanation.

VTCL transformations

How do I invoke graph transformation rules in VTCL?

The source excerpt below shows a simple example for invoking a graph transformation rule. Note that unbound variables, which are determined by pattern matching, are marked as out variables in the gtrule definition.

gtrule myGTRule(in A, out B) =
{
  ...
}
 
rule xfromObject(in A) =
seq 
{
  forall B with apply myGTRule(A,B) do skip;
}

Graphical user interface and usage

TODO

How to create transformations and load them into VIATRA2?

How to run a transformation?

How can I edit my model elements in the model space?

What hotkeys can be used in the VTCL editor?

How to export transformations as EMF models?

How to import models into the VIATRA2 model space?

How to export models from the VIATRA2 model space into my native format?

How can I create domain-specific languages in VIATRA2?

How can I customize the VIATRA treeview-based model space editor?

Sensoria CASE Tool

TODO

Miscellaneous

TODO

Back to the top