* QVTi as a still smaller syntactic subset of QVTm but with imperative semantics suitable for code synthesis.

Using these subset languages, we plan to realize QVTc and QVTr using the following transformation chains

Using these subset languages, we plan to realize QVTc and QVTr using the following transformation chains

Line 76:

Line 74:

* QVTc to QVTu using QVTu

* QVTc to QVTu using QVTu

* QVTr to QVTu using QVTu

* QVTr to QVTu using QVTu

−

−

We hope that a good language-neutral TxVM will arise as a separate project.

We anticipate that the QVTm language will provide a suitably simple declarative language

We anticipate that the QVTm language will provide a suitably simple declarative language

Line 86:

Line 82:

and then transformed for efficient execution by a good TxVM.

and then transformed for efficient execution by a good TxVM.

−

More details on these languages may be found in [[M2M/QVT Declarative Languages]].

+

More details on these languages may be found in [[MMT/QVT Declarative Languages]].

+

+

Recent work on improving the efficiency of the Eclipse OCL evaluator and providing a direct OCL to Java code

+

generator demonstrates that the OCL evaluator can be regarded as the core of a TxVM. The [[M2M/QVTO]] project already exploits

+

this by extending the interpretation capability and adding a debugger. The same interpretation approach should

+

be possible for at least QVTi, QVTm and QVTu, perhaps for QVTc too. Extension of OCL's direct OCL to Java should

+

eliminate the interpretation overheads. Realisation of transformation composition should eventually allow

+

efficient provision of QVTr to QVTc to QVTu to ... and so enable acceptable performance for all languages.

+

+

[https://bugs.eclipse.org/bugs/show_bug.cgi?id=350917 Bug 350917] discusses extending the OCL evaluator with some

+

pattern matching operations to assist in supporting transformations.

==Team==

==Team==

Line 102:

Line 108:

Questions and discussions about the usage of QVT Declarative should take place on the [news://news.eclipse.org/eclipse.modeling.m2m eclipse.modeling.m2m] [http://www.eclipse.org/newsgroups/ Eclipse newsgroup] for the [[M2M|M2M project]] (more details about this newsgroup there), of which QVTd is a component. Please, remember to prefix the subject of your QVT Declarative-related posts with <nowiki>[QVTc]</nowiki>, <nowiki>[QVTr]</nowiki> or <nowiki>[QVTd]</nowiki>.

Questions and discussions about the usage of QVT Declarative should take place on the [news://news.eclipse.org/eclipse.modeling.m2m eclipse.modeling.m2m] [http://www.eclipse.org/newsgroups/ Eclipse newsgroup] for the [[M2M|M2M project]] (more details about this newsgroup there), of which QVTd is a component. Please, remember to prefix the subject of your QVT Declarative-related posts with <nowiki>[QVTc]</nowiki>, <nowiki>[QVTr]</nowiki> or <nowiki>[QVTd]</nowiki>.

−

[[Category:Modeling]] [[Category:M2M]]

+

[[Category:Modeling]] [[Category:MMT]]

Revision as of 05:38, 15 July 2013

Contents

Overview

The QVT Declarative (QVTd) component aims to provide a complete Eclipse based IDE for the Core (QVTc) and Relations (QVTr) Languages defined by the OMG QVT Relations (QVTR) language.
This goal includes all development components necessary for development of QVTc and QVTr programs and APIs to facilitate extension and reuse.

The QVTo component provides corresponding facilities for the Procedural Language.

QVT Declarative currently provides:

Editors for QVTc and QVTr

Parsers for QVTc and QVTr

Meta-models for QVTc and QVTr

(The EMOF-based implementations of the QVT models are the source of the normative models in
ptc/09-11-04 for OMG QVT 1.1.)

This page is a summary of specification related development choices. Its main purpose is to provide a basis for discussion with the community.
Any feed back is welcome.
Please use the M2M newsgroup for the questions and the Bugzilla for issues.

Status and Roadmap

History

Date

Task

July 2008

QVT 1.0 models, parsers and editors migrated from GTM/UMLX project

August 2008

Editors adapted to use IMP

November 2009

Models upgraded and used as basis for OMG QVT 1.1 models

Currently working on

After an unsuccessful attempt to use ATL tooling to define a QVTr compiler, an execution engine
is being planned that will use transformations and support both QVTc and QVTr.

The OMG specification provides an almost monolithic QVTr to QVTc transformation written in QVTr.
This is difficult to understand, and cannot be used until a QVTr execution engine is available.

We therefore plan to transform QVTr to QVTc using QVTc transformations. These will be modularized
by semantic concept to aid understanding and facilitate extension and modification. We similarly plan
to transform QVTc to a TxVM using transformations to a series of intermediate languages.

More specifically, we recognize that any practical use of a transformation is unidirectional
requiring the multi-directional flexibility of QVTr and QVTc to be resolved. We therefore
define

QVTu language as the unidirectional subset of QVTc

QVTm as the smallest declarative subset of QVTu that supports practical transformation programming

QVTi as a still smaller syntactic subset of QVTm but with imperative semantics suitable for code synthesis.

Using these subset languages, we plan to realize QVTc and QVTr using the following transformation chains

QVTi to TxVM using QVTo

QVTm to QVTi using QVTi

QVTu to QVTm using QVTm

QVTc to QVTu using QVTu

QVTr to QVTu using QVTu

We anticipate that the QVTm language will provide a suitably simple declarative language
that will allow for effective application of transformation composition optimizations. These
optimizations will be essential to avoid the costs of naive transformation chains. We hope
that other transformation languages will provide conversion to QVTm so that transformations
developed in a variety of languages can be composed into an efficient composite transformation
and then transformed for efficient execution by a good TxVM.

Recent work on improving the efficiency of the Eclipse OCL evaluator and providing a direct OCL to Java code
generator demonstrates that the OCL evaluator can be regarded as the core of a TxVM. The M2M/QVTO project already exploits
this by extending the interpretation capability and adding a debugger. The same interpretation approach should
be possible for at least QVTi, QVTm and QVTu, perhaps for QVTc too. Extension of OCL's direct OCL to Java should
eliminate the interpretation overheads. Realisation of transformation composition should eventually allow
efficient provision of QVTr to QVTc to QVTu to ... and so enable acceptable performance for all languages.

Installation

Questions and discussions about QVT Declarative usage

Questions and discussions about the usage of QVT Declarative should take place on the eclipse.modeling.m2mEclipse newsgroup for the M2M project (more details about this newsgroup there), of which QVTd is a component. Please, remember to prefix the subject of your QVT Declarative-related posts with [QVTc], [QVTr] or [QVTd].