Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA2/GettingStarted/Creating Transformations"

Line 1: Line 1:
−
== GTASM ==
 
−
 
−
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 <ref name="GTASM">VarrÛ, D., Balogh, A.:The model transformation language of the VIATRA2 framework. Sci. Comput. Program. 68(3) (2007) 214ñ234</ref> , namely, graph transformation (GT) and abstract state machines (ASM) to manipulated graph based models. This combined approach is often called as ''GTASM''.
 
−
 
−
* '''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
 
−
 
−
* '''Graph transformation''' (GT)  <ref name="GT"> Ehrig, H. et al.:Handbook on Graph Grammars and Computing by Graph Transformation. Volume2 : Applications, Languages and Tools. World Scientific (1999)</ref> provides a high-level rule and pattern-based manipulation language for graph models. Graph transformation rules can be specified by using a left-hand side -- LHS (or precondition) pattern determining the applicability of the rule, and a right-hand side -- RHS (postcondition) pattern which declaratively specifies the result model after rule application. Elements that are present only in (the image of) the LHS are deleted, elements that are present only in the RHS are created, and other model elements remain unchanged.
 
−
 
−
* Complex model transformation can be assembled from elementary graph patterns and graph transformation rules using '''abstract state machine''' (ASM)  <ref name="ASM">Bˆrger, E ., Sark, R.: Abstract State Machines. A method for High-Level System Design and Analysis. Springer-Verlag (2003)</ref> in case of the VIATRA2 framework. ASM provides complex model transformations with all the necessary control structures including the sequencing operators, rule invocation, variable declarations and updates, GT rule invocation etc.
 
−
 
−
More information on the semantic integration between graph transformation and abstract state machines can be found in <ref name="DaniPhD">Varro, D.: Automated Model Transformations for the Analysis of IT Systems,îPh.D. thesis, Budapest University of Technology and Economics, Department of Measurement and Information Systems (2004).</ref>.
 
−
 
−
To formulate these constructs VIATRA2 uses its own programming language called VTCL.
 
−
 
 
== The VIATRA2 transformation language ==
 
== The VIATRA2 transformation language ==
−
<!-- VIATRA2 has its own programming language called VTCL.-->
+
VIATRA2 has its own programming language called VTCL. Transformations written in  VTCL are stored in '''.vtcl''' files, and each of them describes a '''machine''' of the GTASM formalism. The definition of the '''control flow''' of the transformation is similar to the mathematical formalism of Abstract State Machines (ASM), and looks just like a conventional programming language (with a syntax somewhat resembling C); this is extended by the declarative features of Graph Transformation (GT).  
−
The VTCL language is a textual syntax to define GTASM program models. Transformations written in  VTCL are stored in '''.vtcl''' files, and each of them describes a '''machine''' of the GTASM formalism. The definition of the '''control flow''' of the transformation is similar to the mathematical formalism of Abstract State Machines (ASM), and looks just like a conventional programming language (with a syntax somewhat resembling C); this is extended by the declarative features of Graph Transformation (GT).  
+
  
 
Why would you want to write transformations in VTCL, instead of implementing them in a well-known programming environment like Java? First, VTCL has convenient access to the VPM model space, which acts as a common ground between heterogeneous modeling formalisms (although VPM also has a Java API). But more importantly, VTCL is a specialized language tailored to transformation specification, having language constructs for efficiently processing models, such as declarative model queries and even declarative manipulation. Should you still find the capabilities of VTCL limiting, there are ways to [[VIATRA2/UseCases/InvokeNativeCode|plug in arbitrary Java code]].  
 
Why would you want to write transformations in VTCL, instead of implementing them in a well-known programming environment like Java? First, VTCL has convenient access to the VPM model space, which acts as a common ground between heterogeneous modeling formalisms (although VPM also has a Java API). But more importantly, VTCL is a specialized language tailored to transformation specification, having language constructs for efficiently processing models, such as declarative model queries and even declarative manipulation. Should you still find the capabilities of VTCL limiting, there are ways to [[VIATRA2/UseCases/InvokeNativeCode|plug in arbitrary Java code]].  
  
−
The [http://www.eclipse.org/gmt/VIATRA2/doc/ official page] hosts the official (slightly outdated) transformation language specification. This section of the wiki, including the following pages, aims to give an informal, introductory overview of the language. The wiki also contains additional reading material including important usage patterns and more advanced topics.
+
The [http://www.eclipse.org/gmt/VIATRA2/doc/ official page] hosts the official (slightly outdated) transformation language specification. This page of the wiki, aims to give a short tutorial of the language. A [[VIATRA2/Activity_Diagrams_to_Petri_Nets|more elaborate tutorial]] is also available. The [[VIATRA2]] wiki also contains additional reading material including important usage patterns and more advanced topics.
  
−
== VTCL basics ==
+
== Language features: GTASM ==
−
The contents of the file form a single GTASM machine, indicated by the <code>machine</code> keyword. The machine declaration is often preceded by <code>namespace</code> header to declare a namespace for the machine; the '''full name''' of the machine (as seen in the ''VIATRA2 Model Spaces'' view) will consist of this namespace, a dot, and the regular name. The other type of header is <code>import</code>, which references a namespace in the VPM metamodel; type names below that namespace can be shortened to their relative qualified names throughout the file.
+
The VTCL language is a textual syntax to define '''GTASM''' program models. GTASM is a combined approach that integrates two popular, intuitive, yet mathematically precise rule-based specification formalisms <ref name="GTASM">VarrÛ, D., Balogh, A.:The model transformation language of the VIATRA2 framework. Sci. Comput. Program. 68(3) (2007) 214ñ234</ref> , namely, graph transformation (GT) and abstract state machines (ASM) to manipulate graph based models.
 +
<!--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. -->
  
−
The procedure/method-like basic execution unit of ASM is the '''ASM rule'''. A rule is defined by code blocks introduced by the <code>rule</code> keyword, followed by the rule name, and then an arbitrary number of input (<code>in</code>), output (<code>out</code>), or in-out (<code>inout</code>) parameters enclosed in parentheses and tailed by an equality sign. A machine can have a '''main rule''', which serves as an entry point; it is executed when the user runs the transformation from the GUI (the dialog box will ask for input parameters). The rest of the ASM rules can be invoked by a <code>call</code> instruction in other rules of the same machine, or a different machine (qualifying the rule name by the full name of the called machine).
+
* '''Graph patterns''' are the key concept in defining model transformations within VIATRA2. A pattern is a declarative query, specified by 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.
−
<!--, or less often from the [[VIATRA2/UseCases/DebuggingAndVisualisation|VIATRA2 console]] or the Java API. -->
+
  
−
Declarative model queries are called '''Graph Patterns'''. They are defined in code blocks indicated by the <code>pattern</code> (or <code>shareable pattern</code>) keyword, the pattern name, and an arbitrary number of (symbolic) parameters enclosed in parentheses (here, there is no distinction between input and output parameters). The pattern body follows, enclosed in curly braces; it describes constraints that the substituted value of the parameters must fulfill. Sometimes, there are multiple disjunctive pattern bodies separated by <code>or</code>. A '''match''' of the pattern is a substitution of each of its parameters (usually to model elements in the model space, less often to other values), such that all constraints are observed in at least one of the disjunctive pattern bodies. Patterns can be incorporated within each other (or a condition expression) using the '''pattern call''' feature (<code>find</code> keyword). Additionally, ASM rules can '''quantify''' the parameter values universally over all matches of a pattern (<code>forall</code> loop), or existentially just to find one match (<code>choose</code> keyword).    
+
* '''Graph transformation''' (GT)  <ref name="GT"> Ehrig, H. et al.:Handbook on Graph Grammars and Computing by Graph Transformation. Volume2 : Applications, Languages and Tools. World Scientific (1999)</ref> provides a high-level rule and pattern-based manipulation language for graph models. Graph transformation rules can be specified by using a left-hand side -- LHS (or precondition) pattern determining the applicability of the rule, and a right-hand side -- RHS (postcondition) pattern which declaratively specifies the result model after rule application. Elements that are present only in (the image of) the LHS are deleted, elements that are present only in the RHS are created, and other model elements remain unchanged. VIATRA2 also allows the definition of imperative actions associated with this formalism.
  
−
Declarative and semi-declarative model manipulations are called Graph Transformation Rules or '''GT rules''' for short. They are defined in code blocks indicated by the <code>gtrule</code> keyword, the GT rule name, an input-output parameter list like the one found at ASM rule declarations, and an equality sign followed by a pair of curly braces enclosing GT rule elements (<code>precondition</code>, <code>postcondition</code>, <code>action</code>). GT rules describe some model manipulation or other effect that is to be executed for matches of a precondition pattern (also known as left-hand-side or '''LHS'''). To define this effect, a GT rule contains either a declarative postcondition (right-hand-side or '''RHS'''), an imperative '''action''' sequence, or both. The precondition is indicated by the keyword <code>precondition</code>, followed either by a pattern call (<code>find</code> keyword) to the precondition pattern, or the inline definition of the precondition pattern. The optional postcondition is defined similarly. The optional imperative action sequence is indicated by the <code>action</code> keyword, followed by a pair of curly braces enclosing a sequence of instructions (similar to <code>seq</code> in ASM rule bodies). A '''rule application''' consists of taking a match of the LHS, replace it with the corresponding image of the RHS graph pattern (if any), and executing the action sequence (if any). The quantification syntax (<code>forall</code>, <code>choose</code>) can be used to apply gtrules on all possible or on one single match of the LHS.  
+
* Complex model transformation can be assembled from elementary graph patterns and graph transformation rules using '''abstract state machine''' (ASM)  <ref name="ASM">Bˆrger, E ., Sark, R.: Abstract State Machines. A method for High-Level System Design and Analysis. Springer-Verlag (2003)</ref> in case of the VIATRA2 framework. ASM provides complex model transformations with all the necessary control structures including the sequencing operators, rule invocation, variable declarations and updates, GT rule invocation etc.  
  
−
As a less common GTASM element, '''ASM functions''' are a global associative (key-value) storage, that contributes to the state of the machine (but not to that of the model, i.e. it is not persisted on saving the model space). Keys are tuples of a chosen number of arguments  ('''arity'''). ASM funtions are defined by the keyword <code>asmfunction</code>, followed by the name of the ASM function, a slash, and the arity. Optionally, the contents can be initialized by an initialization block containing key-value assignments. The contents of the ASM function can be read or written all throughout the machine, as well as from other machines (the ASM function name will have to be qualified with the full name of the defining machine).
+
More information on the semantic integration between graph transformation and abstract state machines can be found in <ref name="DaniPhD">Varro, D.: Automated Model Transformations for the Analysis of IT Systems,îPh.D. thesis, Budapest University of Technology and Economics, Department of Measurement and Information Systems (2004).</ref>.
  
−
'''Variables''' are used throughout the language. Variable names are required to start with capital letters, to be easily distinguishable from model elements, that usually start with a lower case letter. To avoid ambiguities, the name of model elements starting with capital letters sometimes need to be enclosed in single quotation marks, e.g. <code>'Activity'</code>. The variables of the VTCL language are untyped by default; they can hold any kinds of value, including model elements (conforming to any type in the metamodel), strings, integers, etc., even arbitrary Java objects. In addition to the parameters, additional local variables can be used in patterns, GT rules and ASM rules. In ASM rules, they have to be introduced by the <code>let</code> ''variable'' = ''initialValue'', ''variable2'' = ''initialValue2'' <code>in</code> ''block'' construct, or by quantification (over pattern matches or rule applications). Often variables will be initialized with the special value '''undef''' to indicate that they have not yet been assigned.  
+
== Transformation Development ==
 +
In order to learn the VTCL transformation language, it is recommended to start at the [[VIATRA2/GettingStarted/Hello_World_Transformation |Hello World]] example. Afterwards, a more advanced tutorial is available, that walks the reader through the creation of a [[VIATRA2/Activity_Diagrams_to_Petri_Nets|transformation from UML Activities to the domain of Petri Nets]].  
  
−
VTCL uses C-like comments: <code>//</code> causes the VTCL parser to ignore the whole following line, while a pair of <code>/*</code> and <code>*/</code> ignore anything between them. Annotations (e.g. <code lang="java">@incremental</code> or <code  lang="java">@random</code>) are not comments; they are parsed and may provide special options on how certain elements should be interpreted. Many GTASM elements (most importantly, pattern and GT rule definitions) can be preceded by annotations, marked by a <code>@</code> and an annotation name, followed by an optional parentheses-enclosed list of key-value pairs.  
+
More detailed information on the transformation language [[VIATRA2/Transformation_Language | is available on the wiki]].
  
−
== Exercise ==
+
== References ==
−
This exercise relies on the ''Activity Diagrams to Petri Nets'' example transformation included in the [[VIATRA2/Examples|example transformations]] package. Make sure the corresponding VIATRA2 project is in your Eclipse workspace.
+
<references/>
  
−
Open the <code>Activity2PetriNet.vtcl</code> file included in the project. A ''VTCL Text Editor'' will appear, highlighting various elements of the syntax, as well as displaying warning or error indicators. The editor has some useful keystrokes, including <code>Alt+P</code> for parsing + loading the machine (same as dragging & dropping the file from the ''Navigator'' to the entry in the ''VIATRA2 Model Spaces'' view), or <code>Ctrl+S</code> for saving + parsing + loading. 
 
−
 
−
Take a closer look at the vtcl code. Identify the GTASM machine and its entry point. Find the ASM rule, GT rule and graph pattern definitions, and identify their name and parameters. Take a look at the bodies of some of these definitions, and try to identify the variables. Try to find some ASM rule invocations and GT rule applications in the code (<code>call</code> and <code>apply</code> keywords, respectively); hint: hit <code>Ctrl+F</code> while the VTCL file is selected to search in the text. Try to find some graph patterns used as part of a GT rule, either by local declaration or remote reference (<code>find</code> keyword). Try to find some graph patterns used within other graph patterns (<code>find</code> keyword). Try to find some patterns used for pattern matching in ASM rules, iterating over all matches (<code>forall</code>+<code>find</code> structure). Inspect the comments placed in the file, and try to discover which part of the code is responsible for what part of the process.
 
−
 
−
== Developing transformations ==
 
−
GUI, etc. TODO
 
−
 
−
 
−
 
−
 
−
== ASM rule bodies  ==
 
−
<!-- In addition to the rule parameters, local variables can be introduced by the <code>let</code> ''variable'' = ''initialValue'', ''variable2'' = ''initialValue2'' <code>in</code> ''block'' construct, or by quantification. Often variables will be initialized with the special value '''undef''' to indicate that they have not yet been assigned. Variable names are required to start with capital letters, to be easily identified. -->
 
−
<!-- TODO Types, ASMFunc (rule body?). -->
 
 
<!--
 
<!--
−
The most common control flow structure to define the body of a rule or a let/in block is the sequence block, delimited by <code>seq {</code> and <code>}</code>. This sequence block, similarly to the curly braces block in many C-like languages, contains semicolon-separated commands that are executed sequentially. Additional control flow elements include the <code>if (</code>''condition''<code>)</code> ''action'' construct for branching, with an optional <code>else</code> ''otherAction'' part. The loop construct <code>iterate</code> ''action'' repeatedly executes the action as long as it does not '''fail'''. Execution can fail by manually executing the instruction <code>fail</code> (typically to terminate a loop), or by an unsuccessful pattern matching (see later). The <code>try</code> ''action'' construct masks failures , with an optional <code>else</code> ''otherAction'' to execute in case a failure was caught. Finally, <code>skip</code> simply means doing nothing, and the aforementioned <code>call</code> invokes other ASM rules.
+
== GTASM ==
  
−
The most basic commands include <code>update</code> ''variable'' = ''value'', to change variables (or ASM functions), and <code>print</code>/<code>println</code>, to emit textual results / code onto the ''default'' tab of the ''VIATRA2 Textual Output'' view (or [[VIATRA2/UseCases/CodeGeneration|to other tabs or even files]]). The ASM part of VTCL also contains instructions with '''direct model space access''', the most important ones are the following. <code>ref</code> retrieves a model element by its fully qualified name. <code>new</code> and <code>delete</code> adds and removes model elements (as well as <code>supertypeOf</code> and <code>instanceOf</code> relationships!), respectively. <code>rename</code> changes the name of elements; <code>setFrom</code> and <code>setTo</code> manipulate relations, while <code>move</code> and <code>setValue</code> manipulate entities. Throughout these operations, type references can be shortened to a relative qualified name, by importing the namespace of a metamodel by the <code>import</code> header before the machine declaration.
+
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 <ref name="GTASM">VarrÛ, D., Balogh, A.:The model transformation language of the VIATRA2 framework. Sci. Comput. Program. 68(3) (2007) 214ñ234</ref> , namely, graph transformation (GT) and abstract state machines (ASM) to manipulated graph based models. This combined approach is often called as ''GTASM''.
−
-->
+
−
<!-- TODO rule quant -->
+
  
−
See the [[VIATRA2/Examples/VTCL/ASM | ASM]] page for more information.
+
* '''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
  
−
== Patterns ==
+
* '''Graph transformation''' (GT) <ref name="GT"> Ehrig, H. et al.:Handbook on Graph Grammars and Computing by Graph Transformation. Volume2 : Applications, Languages and Tools. World Scientific (1999)</ref> provides a high-level rule and pattern-based manipulation language for graph models. Graph transformation rules can be specified by using a left-hand side -- LHS (or precondition) pattern determining the applicability of the rule, and a right-hand side -- RHS (postcondition) pattern which declaratively specifies the result model after rule application. Elements that are present only in (the image of) the LHS are deleted, elements that are present only in the RHS are created, and other model elements remain unchanged.
−
<!-- TODO -->
+
−
<code>find</code> ''patternName''(''parameters'') clause
+
  
−
See the [[VIATRA2/Examples/VTCL/GraphPattern| Graph Pattern ]] page for more information.
+
* Complex model transformation can be assembled from elementary graph patterns and graph transformation rules using '''abstract state machine''' (ASM)  <ref name="ASM">Bˆrger, E ., Sark, R.: Abstract State Machines. A method for High-Level System Design and Analysis. Springer-Verlag (2003)</ref> in case of the VIATRA2 framework. ASM provides complex model transformations with all the necessary control structures including the sequencing operators, rule invocation, variable declarations and updates, GT rule invocation etc.  
  
−
== GT Rules  ==
+
More information on the semantic integration between graph transformation and abstract state machines can be found in <ref name="DaniPhD">Varro, D.: Automated Model Transformations for the Analysis of IT Systems,îPh.D. thesis, Budapest University of Technology and Economics, Department of Measurement and Information Systems (2004).</ref>.
−
TODO
+
  
−
== Developing transformations ==
+
To formulate these constructs VIATRA2 uses its own programming language called VTCL.
−
GUI, etc. TODO
+
  
−
[[VIATRA2/GettingStarted/Using_Transformations|a previous section]]
+
== The VIATRA2 transformation language ==
 +
The VTCL language is a textual syntax to define GTASM program models. Transformations written in  VTCL are stored in '''.vtcl''' files, and each of them describes a '''machine''' of the GTASM formalism. The definition of the '''control flow''' of the transformation is similar to the mathematical formalism of Abstract State Machines (ASM), and looks just like a conventional programming language (with a syntax somewhat resembling C); this is extended by the declarative features of Graph Transformation (GT).
  
 +
Why would you want to write transformations in VTCL, instead of implementing them in a well-known programming environment like Java? First, VTCL has convenient access to the VPM model space, which acts as a common ground between heterogeneous modeling formalisms (although VPM also has a Java API). But more importantly, VTCL is a specialized language tailored to transformation specification, having language constructs for efficiently processing models, such as declarative model queries and even declarative manipulation. Should you still find the capabilities of VTCL limiting, there are ways to [[VIATRA2/UseCases/InvokeNativeCode|plug in arbitrary Java code]].
  
−
== References ==
+
The [http://www.eclipse.org/gmt/VIATRA2/doc/ official page] hosts the official (slightly outdated) transformation language specification. This section of the wiki, including the following pages, aims to give an informal, introductory overview of the language. The wiki also contains additional reading material including important usage patterns and more advanced topics.
−
<references/>
+
-->

Revision as of 15:53, 16 March 2010

The VIATRA2 transformation language

VIATRA2 has its own programming language called VTCL. Transformations written in VTCL are stored in .vtcl files, and each of them describes a machine of the GTASM formalism. The definition of the control flow of the transformation is similar to the mathematical formalism of Abstract State Machines (ASM), and looks just like a conventional programming language (with a syntax somewhat resembling C); this is extended by the declarative features of Graph Transformation (GT).

Why would you want to write transformations in VTCL, instead of implementing them in a well-known programming environment like Java? First, VTCL has convenient access to the VPM model space, which acts as a common ground between heterogeneous modeling formalisms (although VPM also has a Java API). But more importantly, VTCL is a specialized language tailored to transformation specification, having language constructs for efficiently processing models, such as declarative model queries and even declarative manipulation. Should you still find the capabilities of VTCL limiting, there are ways to plug in arbitrary Java code.

The official page hosts the official (slightly outdated) transformation language specification. This page of the wiki, aims to give a short tutorial of the language. A more elaborate tutorial is also available. The VIATRA2 wiki also contains additional reading material including important usage patterns and more advanced topics.

Language features: GTASM

The VTCL language is a textual syntax to define GTASM program models. GTASM is a combined approach that integrates two popular, intuitive, yet mathematically precise rule-based specification formalisms [1] , namely, graph transformation (GT) and abstract state machines (ASM) to manipulate graph based models.

  • Graph patterns are the key concept in defining model transformations within VIATRA2. A pattern is a declarative query, specified by 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.
  • Graph transformation (GT) [2] provides a high-level rule and pattern-based manipulation language for graph models. Graph transformation rules can be specified by using a left-hand side -- LHS (or precondition) pattern determining the applicability of the rule, and a right-hand side -- RHS (postcondition) pattern which declaratively specifies the result model after rule application. Elements that are present only in (the image of) the LHS are deleted, elements that are present only in the RHS are created, and other model elements remain unchanged. VIATRA2 also allows the definition of imperative actions associated with this formalism.
  • Complex model transformation can be assembled from elementary graph patterns and graph transformation rules using abstract state machine (ASM) [3] in case of the VIATRA2 framework. ASM provides complex model transformations with all the necessary control structures including the sequencing operators, rule invocation, variable declarations and updates, GT rule invocation etc.

More information on the semantic integration between graph transformation and abstract state machines can be found in [4].

Transformation Development

In order to learn the VTCL transformation language, it is recommended to start at the Hello World example. Afterwards, a more advanced tutorial is available, that walks the reader through the creation of a transformation from UML Activities to the domain of Petri Nets.

More detailed information on the transformation language is available on the wiki.

References

  1. ↑ VarrÛ, D., Balogh, A.:The model transformation language of the VIATRA2 framework. Sci. Comput. Program. 68(3) (2007) 214ñ234
  2. ↑ Ehrig, H. et al.:Handbook on Graph Grammars and Computing by Graph Transformation. Volume2 : Applications, Languages and Tools. World Scientific (1999)
  3. ↑ Bˆrger, E ., Sark, R.: Abstract State Machines. A method for High-Level System Design and Analysis. Springer-Verlag (2003)
  4. ↑ Varro, D.: Automated Model Transformations for the Analysis of IT Systems,îPh.D. thesis, Budapest University of Technology and Economics, Department of Measurement and Information Systems (2004).


Retrieved from "https://wiki.eclipse.org/index.php?title=VIATRA2/GettingStarted/Creating_Transformations&oldid=192641"

Back to the top