VIATRA2 is a model transformation tool integrated into Eclipse. TODO
Yes. VIATRA2 is licensed under the Eclipse Public License v1.0.
See VIATRA2/Installation.
There are multiple possibilities:
A frequent mistake when specifying relations in VTML is demonstrated in the following example: <source lang="java"> namespace Meta; entity(Container) {
entity(Element); relation(list,Element,Element); relation(next,list,list); // <-- error: "Source (Meta.Container.list) for relation next undefined."
} </source> 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). <source lang="java"> namespace Meta; entity(Container) {
entity(Element); relation(list,Element,Element); relation(next,Element.list,Element.list); // correct
} </source>
Say we have a metamodel with a relation: <source lang="java"> entity(Meta) {
entity(A); entity(B); relation(R,A,B);
} </source>
We want to have another metamodel which "refines" the original one (second VTML file): <source lang="java"> 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);
} </source> We export the "refinement" information for the relation in a third VTML file: <source lang="java"> import Meta.A; import Meta_Refined.C; superTypeOf(R,R2); // <-- problematic </source> 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: <source lang="java"> import Meta; import Meta_Refined; superTypeOf(A.R,C.R2); // correct </source>
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:
An example:
<source lang="java"> 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); } </source>
Such a warning means that your pattern definition does not contain a type constraint for the target end of a relation: <source lang="java"> pattern dangerous(A,B) = {
SomeType(A); EdgeType(R,A,B);
} </source> 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: <source lang="java"> pattern dangerous(A,B) = {
SomeType(A); OtherType(B); // <-- correction EdgeType(R,A,B);
} </source> This is also necessary for the correct operation of the incremental pattern matching engine.
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.
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 <source lang="text"> namespace mydomain.mysubdomain; machine mymachine { ... pattern mypattern(X) = { ... rule myrule(in X) = ... ... </source> machine2.vtcl <source lang="text"> 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 ...
</source>
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: <source lang="text">
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); }
</source>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.
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.
<source lang="java"> gtrule myGTRule(in A, out B) = {
...
}
rule xfromObject(in A) = seq {
forall B with apply myGTRule(A,B) do skip;
} </source>
TODO
TODO
TODO