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

Difference between revisions of "VIATRA2/Case Studies"

(VIATRA2 Examples)
Line 33: Line 33:
 
[[Image:cwf_vtml.png|frame|Fig.4 The metamodel of the language in the syntax of the VIATRA2 Textualt Metamodeling Language.]]  
 
[[Image:cwf_vtml.png|frame|Fig.4 The metamodel of the language in the syntax of the VIATRA2 Textualt Metamodeling Language.]]  
  
The usual way of creating a metamodel based on an XSD schema:
+
The usual way of creating a metamodel based on an XSD schema: First complex types should be identified by entities in VIATRA2. For the representation of containment relations and cross references between XML tags we have multiple options. Here simple relations are only used. However, for the containment a good idea could be to derive them from a containment supertype. So to represent that a car workflow has cars as containmnet simply a relation is used. In this simple example attributes are similarly handled. The line <tt>relation(application,activity,String)</tt> indicates that an entity the type of whom is activity may have a reference to an application.
First complex types should be identified by entities in VIATRA2.
+
 
 +
Please note the following:
 +
* In the metamodel attributes and containments are not distinguished. If it is needed however, many solutions exist. One possible is that we define two supertypes, one for the containment, the other for the attributes. In order to do that most probably, XML tags and attributes also need supertypes.
 +
* The names of entities are recommended to be identical with the names of the complex types in the Schema. The names of the relations should reflect the names of entities the actual complex type may contain. This makes the build of the importer easier, and more maintainable.
 +
 
 +
 
 +
[[User:Kovmate.gmail.com|Kovmate.gmail.com]] 09:54, 9 June 2008 (EDT)

Revision as of 09:54, 9 June 2008

VIATRA2 Examples

Importer of a Simple XML-based Language

Introduction

There is a third party editor given, which can export into an XML file. We need to represent this model in the VIATRA2 Model Space. Native importers are used to create models in the model space of VIATRA2. This example shows how to build an importer that can instantiate a model in the model space based on a file.

There are two essential components of an importer:

  • A metamodel : The metamodel describes the language, which we want to create an importer for. The metamodel can be regarded as a representation of the language's abstract syntax.
  • An importer plug-in : This is the implementation of the importer. Its basic task is to explore the input file, and instantiate the elements of the metamodel accordingly.


Example: Car workflow importer

The example we would like to use as the pilot example is a workflow description language. A file describes the activities of drivers of cars in a scenario. So we have the participants (the drivers), and the timeline. This workflow however, does not cope with use decisions along the scenario, only a sequential execution of activities is possible extended with concurrency. Hence, it is basically an interval editor. Each interval represents an activity.


Fig.1 The graphical concrete syntax of the language.


Fig. 1 represents a possible graphical concrete syntax of the language.This example has two participants, John Doe and Jane Doe. They are having a chat conversation from 12:00 till 12:09. Meanwhile Jane listens to a song, and John goes on listening the radio.

Fig.2 The XML notation of the workflow.

The XML representation of the example workflow can be seen on Fig. 2. We have one <carworkflow> . The carworkflow describes the activities of the drivers of two <car>s. The <activity>(ie's) attributes also define the additional attributes.

File:Cwf xsd.png
Fig.3 The XSD Schema definition of the language.


Fig. 3 shows the XSD representation of the language. Based on the XSD definition of the language the metamodel can easily be written (See Fig.4).

Fig.4 The metamodel of the language in the syntax of the VIATRA2 Textualt Metamodeling Language.

The usual way of creating a metamodel based on an XSD schema: First complex types should be identified by entities in VIATRA2. For the representation of containment relations and cross references between XML tags we have multiple options. Here simple relations are only used. However, for the containment a good idea could be to derive them from a containment supertype. So to represent that a car workflow has cars as containmnet simply a relation is used. In this simple example attributes are similarly handled. The line relation(application,activity,String) indicates that an entity the type of whom is activity may have a reference to an application.

Please note the following:

  • In the metamodel attributes and containments are not distinguished. If it is needed however, many solutions exist. One possible is that we define two supertypes, one for the containment, the other for the attributes. In order to do that most probably, XML tags and attributes also need supertypes.
  • The names of entities are recommended to be identical with the names of the complex types in the Schema. The names of the relations should reflect the names of entities the actual complex type may contain. This makes the build of the importer easier, and more maintainable.


Kovmate.gmail.com 09:54, 9 June 2008 (EDT)

Back to the top