Talk:QVT
From Wikipedia, the free encyclopedia
Contents |
[edit] QVT
QVT is a well focused subject with good development potential. Method Engineering is a very broad subject with still loose and evolving boundaries. Let us not pollute this precise presentation with a merge in a loosely defined subject.
[edit] What is QVT Compliance?
- I would not say that ATL, etc. is really compliant to QVT in any way. Actually, their strategy is to stay independent of QVT. And by the way, Borland has already a QVT implementation available (although it has not all of the features yet). - May 2006 -
-
- Could the unsigned quotation above bring some proofs of their claims? Is there some papers describing the Borland implementation in detail? Is there some collection of transformations, written in the Borland QVT language? What is the level of compliance between 1 and 12 of the Borland implementation to the QVT standard? Youmee 22:17, 26 May 2006 (UTC)
-
-
- Download a trial - try it yourself - and you will see! I wrote the above cause there are so many unproved statements about ATL in the article (that is actually on QVT!) - this should be fixed first. Borland is seriously heading towards QVT whereas ATL is currently still ahead but without aiming at QVT compatibility, so they are hard to compare. Anyway - learn OCL and you can handle them all. (the unregistered user)
-
-
-
- Actually, as far as I understood, Borland yet implements QVT Operational (would have to take a look at the OMG recommendation to make more serious statements on the compliance level reached). (fbahr. July 03, 2006.)
-
-
-
-
- It seems that, for the time being, ATL is the model transformation language that is the closest to the QVT recommendation. There is a paper by Jouault and Kurtev quoted in the QVT article that discusses these issues at length. You should read it because it is pretty clear. The problem of QVT compliance, with its 12 (twelve) levels of compliance defined by OMG is a very complex one. For the time being, Borland has not proved to be more QVT-compliant than ATL. I doubt anyway that QVT-compliance is a real usability issue since probably the QVT recommendation will have to evolve in the coming years if the OMG wants this proposal to have some practical industial impact. QVT 20:16, 25 May 2006 (UTC)
-
-
-
-
- To avoid any subjective discussions, a definition of ATL scope may be found at: ATL official presentation. Youmee 20:26, 17 June 2006 (UTC)
-
-
-
- I do not understand this discussion. Seems to me that the description found at the previous URL is quite clear. I reproduce it below:
-
-
-
-
- The ATL discussion board concerns ATL, the Atlas Transformation Language, which is being developed at INRIA by the ATLAS group in Nantes and available as open source.
-
-
-
-
-
- ATL is a hybrid language (a mix of declarative and imperative constructions) designed to express model transformations.
-
-
-
-
-
- ATL is described by an abstract syntax (a MOF meta-model), and a textual concrete syntax. A transformation model in ATL is expressed as a set of transformation rules. The recommended style of programming is declarative.
-
-
-
-
-
- OMG has issued a recommendation for model to model transformations. This may be found in the final MOF QVT adopted specification available from: http://www.omg.org/docs/ptc/05-11-01.pdf.
-
-
-
-
-
- ATL is presently a QVT-like language. However it is not, in the present state, 100% compatible with the 12 levels of compliance stated in the previous OMG document.
-
-
-
-
-
- In the future, the evolution of ATL will be more driven by practical usability than by strict QVT-compliance.
-
-
-
-
-
- ATL is part of the general AMMA Platform for which the INRIA ATLAS group in Nantes is currently developing a set of research tools (Model Weaver, Megamodel Manager, etc.).
-
-
-
-
-
- Most of these tools are available as open source in the Eclipse GMT project http://www.eclipse.org/gmt/. In addition to the ATL subproject, you may find there the AMW (Model Weaving) or the AM3 (General Megamodel Management) subprojects.
-
-
-
-
-
- An initial library of ATL transformations may be found at: http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/gmt-home/subprojects/ATL/ATL_examples/index.html
-
-
-
-
-
- Any user is welcome to contribute to this library as open source under the Eclipse Public Library License (EPL 1.0).
-
-
-
-
-
- The documentation on ATL is available from: http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/gmt-home/subprojects/ATL/doc/index.html
-
-
-
-
-
- Feel free to ask more about ATL and the model management tools developed in the mail forum.
-
-
-
-
- I do not see any problem here.
-
-
- This says it all: "In the future, the evolution of ATL will be more driven by practical usability than by strict QVT-compliance." doesn't it? They actually give a damn about QVT - fakes like "QVT-like" are just a delusion. A. Developer 193.22.205.227 12:34, 19 July 2006 (UTC)
-
-
- You have to be aware of ATL's history to better understand its current state and its foreseen future: it evolved while the QVT proposal was in its earliest states of progress (cf. OpenQVT Consortium's TRL submission) ... so I'm sure, *some* compliance level will be formally defined (see QVT/ATL-alignment paper); although it (probably) won't be full complient. (fbahr. July 20, 2006.)
-
-
-
- Is this QVT normative specification really important? More and more people are now realizing that there are plenty of ways to define a model transformation language. There was recently some work on Domain Specific Transformation Languages. Corresponding to different requirements, there are certainly different answers. Probably what we'll see in the coming months and years is a wide spectrum of transformation languages. QVT does not correspond to the exact needs of several communities. Probably QVT will be only one point in a very large solution space. So why bother about QVT? We should instead compare the essentiaal qualities of various transformation languages. To this end it would be nice to have a broad set of benchmark problems, not always the ones proposed in the QVT OMG recommendation that covers only a very small portion of the possibilities of a model transformation language. QVT was surely useful to draw attention to this area. Now the proposal in this state seems rather obsolete, because too restricted to only a particular view of the problem.
-
[edit] again QVT compliance
We need consensus here. How about:
- QVT-like means that the model transformation language allows to write OCL-based programs that may read and write XMI-streams
- QVT-compliant means that some of the compliance criteria apply
- QVT-full-compliant means that all of the compliance criteria do apply
Is that ok to everybody? 12.192.193.2 00:37, 13 June 2006 (UTC)
- Seems a reasonable classification Youmee
- It's essential to differentiate between formal compliance levels as stated in the OMG recommendation and the more taxonomial notion of "compliance". (fbahr. July 03, 2007.)
-
- What is the meaning of: "the more taxonomial notion of compliance" ?
-
-
- Most likely "bad english" ... tried to point out that there are several "official" levels of compliance as well as some more "conceptual aspects" concerned with any notion of compliance (such as: OCL-based, .. etc.) (fbahr. July 20, 2007.)
-
[edit] What about real open-source implementations?
QVT is a well defined OMG specification, but users ave eagerly waiting for usable open source implementations.
Could someone point to existing and accessible mature open source implementations in addition to Tefkat and ATL?
Does somedoby know about the open source status of the TaTa Institute implementation or the Compuware implementation? Will these products come as stand-alone or, like the Borland one, be integrated in other CASE tool products? --12.192.193.2 20:40, 11 June 2006 (UTC)
12.192.193.2 20:36, 11 June 2006 (UTC)
You could check SmartQVT, which implements QVT-operationnal part of QVT. I also sorted a bit the 'Implementations' section of the QVT page, so that we could see quickly what exists out there. Spoivre
I'm a bit confused about the criticism section. Can we really say that QVT is XMI to XMI? Should it be MOF to MOF? Furthermore what about the fuzzy requirements - has this to do something with a model transformations language itself or with MDA? Can there be more requirements than those that you transform from PIM to PSM. Overall I feel that the criticism part should be overworked.