Home » Archived » M2M (model-to-model transformation) » [OVTR] General question about QVT Spec
| [OVTR] General question about QVT Spec [message #75697] |
Tue, 04 March 2008 12:29  |
Eclipse User |
|
|
|
Originally posted by: david.hittel.de
Hi,
I am trying to get into QVT for my thesis. I am evaluating current
implementations of QVT.
I am wondering about a part in the specification it says "...the declarative
part, as it forms the framework for the ... the imperative part."
From my understanding the declarative part is a two level architecture where
the Relation and Core language have the same abilities, but the level of
abstraction of the Core language is way higher, so it's more verbose but
more simple.
And it says that the Relation language has the ability to convert Relations
Model into Core Models. Is this just helpful to create a software
implementation of QVT or can this be also useful in a software project where
i am using QVT as a model to model transformation, if yes, why?
The only Relative language implementation is MediniQVT right now that I
know.
Please correct me if I understand anything wrong
The imperative part has the Operational Mapping Language and the Black Box.
From my understanding Black Box is just an extension to the declarative
framework to execute external MOF Operations.
The Operational Mappings are a way of imperative QVT transformation and can
be used to extend the declarative transformation if it's not possible to the
write a pure declarative transformation, this explanation would fit into my
quote from above.
"...the declarative part, as it forms the framework for the ... the
imperative part."
But from my understanding that the transformation can be written entirely
written in the operational language as stated in 6.2.1 of the Spec, didn´t
fit into the quote from above, because there is no declarative framework
needed if everything is written an operational language.
Could you help me to understand the basic concept correct, are my thoughts
totally bullshit?
Thanks a lot
David Hittel
|
|
|
| Re: [QVTR] General question about QVT Spec [message #75785 is a reply to message #75697] |
Wed, 05 March 2008 10:25  |
| Eclipse User |
|
|
|
Originally posted by: quentin.glineur.obeo.fr
This is a multi-part message in MIME format.
--------------060007050807030708060805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi David,
answers follow up...
David Hittel a
|
|
|
| Re: [QVTR] General question about QVT Spec [message #75861 is a reply to message #75785] |
Wed, 05 March 2008 12:38 |
| Eclipse User |
|
|
|
Originally posted by: david.hittel.de
Hi Quentin,
thanks for your comments. I working my way through the specification :-).
The goal of my thesis is to evaluate current QVT implementations based on
OMG´s spec.
Right now i choose the following
QVT-O
Borland Together
SmartQVT
EclipseM2M
QVT-R
MediniQVT
I think that are so far the best implementations of QVT that are working and
useable for a real software project.
What do you think about it, do you think this selection is making sense,
what do you would improve?
The hard think about it is the evaluation of these software implementations
is, that the specification is just beta and far away
of being complete, so every program has kind of its own way to interpreted
the specification. So want to you think
is the best way to create a evaluation criteria catalog for this software
test?
Other Problem is the support of the Borland Together, nobody from this
company is really interested in want I am trying to do.
I didn´t even got a trail version that is longer than 30 days, not even if
it's a academic purpose.
All other project teams helped a lot, what do you think i should do? Is
someone from Borland working on the M2M project that could
help me out? Or should I kick this implementation, because all other
solution are open source and Borland Together isn't and therefore
this solution has way better requirements.
Greetings to France.
Thanks
David
"Quentin Glineur" <quentin.glineur@obeo.fr> schrieb im Newsbeitrag
news:fqlse4$hg1$1@build.eclipse.org...
> Hi David,
>
> answers follow up...
>
> David Hittel a écrit :
>> Hi,
>>
>> I am trying to get into QVT for my thesis. I am evaluating current
>> implementations of QVT.
>>
>> I am wondering about a part in the specification it says "...the
>> declarative part, as it forms the framework for the ... the imperative
>> part."
>>
>> From my understanding the declarative part is a two level architecture
>> where the Relation and Core language have the same abilities, but the
>> level of abstraction of the Core language is way higher, so it's more
>> verbose but more simple.
>
> In fact, the Relations language is more abstract. Among the different
> reasons, let's say this is because:
> - it does not have to deal with trace model (there are implicit)
> - it uses high level description elements such as equality artefacts
> (PropertyTemplateItem) whose semantics can change according to the
> execution (both equality checking or assignment)
> - the conciseness of the language whose equivalent in Core language has
> to be detailed...
>
>> And it says that the Relation language has the ability to convert
>> Relations Model into Core Models. Is this just helpful to create a
>> software implementation of QVT or can this be also useful in a software
>> project where i am using QVT as a model to model transformation, if yes,
>> why?
>
> Indeed, this is helpful for the implementation. To fulfil its goal
> (especially of incrementality and traceability), a QVT Relations
> transformation can be implemented by a QVT Core transformation. Running
> on the top of such an engine, it then reuse all the QVT Core facilities.
>
> But this is also a proof of operationnability of the language: it is
> powerfull enough to express itself in a less abstract language.
> An analogy is done in the specification, considering the Core expression
> as byte code and the Relations expression as source code. This
> conversion is then like a compilation. This is a bootstrap description.
>
>> The only Relative language implementation is MediniQVT right now that I
>> know.
>
> We are implementing an Eclipse solution: browse the CVS. The QVTR
> compiler is smart enough to produce a correct ASM file (ATL VM byte
> code) for the transformation umlToRdbms. We are producing examples,
> Wiki, tests, and so on...
>
>> Please correct me if I understand anything wrong
>>
>> The imperative part has the Operational Mapping Language and the Black
>> Box.
>> From my understanding Black Box is just an extension to the declarative
>> framework to execute external MOF Operations.
>
> Yes, it is a way to call "on the self" operations to fulfil the creation
> goal. The block boxes are use for the implementation of the enforcement
> of the direction domain semantics.
>
>> The Operational Mappings are a way of imperative QVT transformation and
>> can be used to extend the declarative transformation if it's not
>> possible to the write a pure declarative transformation, this
>> explanation would fit into my quote from above.
>>
>> "...the declarative part, as it forms the framework for the ... the
>> imperative part."
>>
>> But from my understanding that the transformation can be written
>> entirely written in the operational language as stated in 6.2.1 of the
>> Spec, didn´t fit into the quote from above, because there is no
>> declarative framework needed if everything is written an operational
>> language.
>>
>> Could you help me to understand the basic concept correct, are my
>> thoughts totally bullshit?
>
> I do not see any "bullshit" in your speech. In my opinion, the described
> architecture is a try to make several languages as part of a unique
> framework. But you may have noticed that no example of interoperability
> is given in the specification...
> The declarative part and the imperative one are definitively
> independent. We have not reach the homogeneity phase yet!
>
>> Thanks a lot
>>
>> David Hittel
>>
>
> Quentin GLINEUR
>
>
|
|
|
| Re: [QVTR] General question about QVT Spec [message #75943 is a reply to message #75861] |
Wed, 05 March 2008 14:09 |
| Eclipse User |
|
|
|
Originally posted by: quentin.glineur.obeo.fr
This is a multi-part message in MIME format.
--------------040409060804070209040009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi David,
First: Eclipse M2M QVT-O is supported by Borland. I do not think it has
much difference with Together (but I may be wrong)....
Now about the comparisons, I don't this there much sense to compare
product implementing different languages together (because the languages
being independent, the provided solutions are not on the same level).
Please note that the ptc/07-07-07 is a "Final Adopted Specification" so
not beta any more. However, the specification do not provide a mean to
consider authoritative points. Therefore the only criteria I see to
judge a product are:
- the openness of the project to compare implementation with the
specification
- the activity of the project (with community feedback...)
- the architecture of the project
- the user functionalities
But all of these depends on the context of the comparison (the good tool
for the right project).
David Hittel a
|
|
|
| Re: [QVTR] General question about QVT Spec [message #76027 is a reply to message #75861] |
Thu, 06 March 2008 10:54 |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi David,
Together uses Operational QVT from M2M Eclipse project but has some
commercial add-ons like
debugger, codecompletion.
If you could work without these, I recommend you to take M2M QVTO, as it
gets new features
that are not part of the Together release.
I work for Borland and I'm for sure interested in your activities and
willing to
help you in that.
Regards,
/Radek
On Wed, 05 Mar 2008 13:38:00 +0100, David Hittel <david@hittel.de> wrote:
> Hi Quentin,
>
> thanks for your comments. I working my way through the specification :-).
>
> The goal of my thesis is to evaluate current QVT implementations based
> on OMG´s spec.
>
> Right now i choose the following
>
> QVT-O
>
> Borland Together
> SmartQVT
> EclipseM2M
>
> QVT-R
>
> MediniQVT
>
> I think that are so far the best implementations of QVT that are working
> and useable for a real software project.
> What do you think about it, do you think this selection is making sense,
> what do you would improve?
>
> The hard think about it is the evaluation of these software
> implementations is, that the specification is just beta and far away
> of being complete, so every program has kind of its own way to
> interpreted the specification. So want to you think
> is the best way to create a evaluation criteria catalog for this
> software test?
>
> Other Problem is the support of the Borland Together, nobody from this
> company is really interested in want I am trying to do.
> I didn´t even got a trail version that is longer than 30 days, not even
> if it's a academic purpose.
>
> All other project teams helped a lot, what do you think i should do? Is
> someone from Borland working on the M2M project that could
> help me out? Or should I kick this implementation, because all other
> solution are open source and Borland Together isn't and therefore
> this solution has way better requirements.
>
> Greetings to France.
>
> Thanks
>
> David
>
>
>
> "Quentin Glineur" <quentin.glineur@obeo.fr> schrieb im Newsbeitrag
> news:fqlse4$hg1$1@build.eclipse.org...
>> Hi David,
>>
>> answers follow up...
>>
>> David Hittel a écrit :
>>> Hi,
>>>
>>> I am trying to get into QVT for my thesis. I am evaluating current
>>> implementations of QVT.
>>>
>>> I am wondering about a part in the specification it says "...the
>>> declarative part, as it forms the framework for the ... the imperative
>>> part."
>>>
>>> From my understanding the declarative part is a two level architecture
>>> where the Relation and Core language have the same abilities, but the
>>> level of abstraction of the Core language is way higher, so it's more
>>> verbose but more simple.
>>
>> In fact, the Relations language is more abstract. Among the different
>> reasons, let's say this is because:
>> - it does not have to deal with trace model (there are implicit)
>> - it uses high level description elements such as equality artefacts
>> (PropertyTemplateItem) whose semantics can change according to the
>> execution (both equality checking or assignment)
>> - the conciseness of the language whose equivalent in Core language has
>> to be detailed...
>>
>>> And it says that the Relation language has the ability to convert
>>> Relations Model into Core Models. Is this just helpful to create a
>>> software implementation of QVT or can this be also useful in a software
>>> project where i am using QVT as a model to model transformation, if
>>> yes,
>>> why?
>>
>> Indeed, this is helpful for the implementation. To fulfil its goal
>> (especially of incrementality and traceability), a QVT Relations
>> transformation can be implemented by a QVT Core transformation. Running
>> on the top of such an engine, it then reuse all the QVT Core facilities.
>>
>> But this is also a proof of operationnability of the language: it is
>> powerfull enough to express itself in a less abstract language.
>> An analogy is done in the specification, considering the Core expression
>> as byte code and the Relations expression as source code. This
>> conversion is then like a compilation. This is a bootstrap description.
>>
>>> The only Relative language implementation is MediniQVT right now that I
>>> know.
>>
>> We are implementing an Eclipse solution: browse the CVS. The QVTR
>> compiler is smart enough to produce a correct ASM file (ATL VM byte
>> code) for the transformation umlToRdbms. We are producing examples,
>> Wiki, tests, and so on...
>>
>>> Please correct me if I understand anything wrong
>>>
>>> The imperative part has the Operational Mapping Language and the Black
>>> Box.
>>> From my understanding Black Box is just an extension to the
>>> declarative
>>> framework to execute external MOF Operations.
>>
>> Yes, it is a way to call "on the self" operations to fulfil the creation
>> goal. The block boxes are use for the implementation of the enforcement
>> of the direction domain semantics.
>>
>>> The Operational Mappings are a way of imperative QVT transformation and
>>> can be used to extend the declarative transformation if it's not
>>> possible to the write a pure declarative transformation, this
>>> explanation would fit into my quote from above.
>>>
>>> "...the declarative part, as it forms the framework for the ... the
>>> imperative part."
>>>
>>> But from my understanding that the transformation can be written
>>> entirely written in the operational language as stated in 6.2.1 of the
>>> Spec, didn´t fit into the quote from above, because there is no
>>> declarative framework needed if everything is written an operational
>>> language.
>>>
>>> Could you help me to understand the basic concept correct, are my
>>> thoughts totally bullshit?
>>
>> I do not see any "bullshit" in your speech. In my opinion, the described
>> architecture is a try to make several languages as part of a unique
>> framework. But you may have noticed that no example of interoperability
>> is given in the specification...
>> The declarative part and the imperative one are definitively
>> independent. We have not reach the homogeneity phase yet!
>>
>>> Thanks a lot
>>>
>>> David Hittel
>>>
>>
>> Quentin GLINEUR
>>
>>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
| Re: [QVTR] General question about QVT Spec [message #76238 is a reply to message #76207] |
Wed, 12 March 2008 08:59 |
| Eclipse User |
|
|
|
Originally posted by: david.hittel.de
Hi Ed,
that why i didn´t put ModelMorf in consideration, because i tought
this project is dead.
I am almost finished with explaining QVT-R, but nobody from you unterstands
german i guess :-). Otherwise someone could go trough my paper and correct
technical errors.
Best regards
David Hittel
"Ed Willink" <ed@willink.me.uk> schrieb im Newsbeitrag
news:fr6h0s$lko$1@build.eclipse.org...
> Hi David
>
>> QVT-R
>>
>> MediniQVT
>
> There is also ModelMorf, for which Sreedhar Reddy is a major influence.
> Sreedhar is also perhaps the greatest influence on the QVTR specification
> chapters.
>
> Unfortunately the ModelMorf web-site has not updated since its Pre-Beta3,
> that did not have full support for sets.
>
> ---
>
> Within the Eclipse fold, the GMT/UMLX component provides accurate
> QVT models and validating editors for QVTR and QVTcore.
>
> ---
>
> The evolution of the QVTr to QVTcore transformation in the QVT spec
> can be attributed to the usage within ModelMorf and validation within
> UMLX.
>
> Regards
>
> Ed Willink
>
|
|
|
| Re: [QVTR] General question about QVT Spec [message #76255 is a reply to message #75943] |
Wed, 12 March 2008 09:37 |
| Eclipse User |
|
|
|
Originally posted by: david.hittel.de
Hi Quentin,
thanks for the hint with Borland I am in touch now with Radek Dvorak.
Thats a problem that i was worried about. Do you think it would be useful
to compare the Languages additional to the software test, and pointing out
the advantages and disadvantages.
If you like more declarative or imperative Languages is sometimes just a
matter of
personal taste. So i had to work out the real differences.
I think as an QVT user the two main languages would be Qvt-r and qvt-o that
i should compare. I could
maybe find out the diffrences, but it would be sometimes hard for me to
judge what is good or bad , because
right now i just far away from the knowlegde you guys here.
Best regards
David
"Quentin Glineur" <quentin.glineur@obeo.fr> schrieb im Newsbeitrag
news:fqm9iq$1q0$1@build.eclipse.org...
> Hi David,
>
> First: Eclipse M2M QVT-O is supported by Borland. I do not think it has
> much difference with Together (but I may be wrong)....
>
> Now about the comparisons, I don't this there much sense to compare
> product implementing different languages together (because the languages
> being independent, the provided solutions are not on the same level).
>
> Please note that the ptc/07-07-07 is a "Final Adopted Specification" so
> not beta any more. However, the specification do not provide a mean to
> consider authoritative points. Therefore the only criteria I see to
> judge a product are:
> - the openness of the project to compare implementation with the
> specification
> - the activity of the project (with community feedback...)
> - the architecture of the project
> - the user functionalities
> But all of these depends on the context of the comparison (the good tool
> for the right project).
>
>
> David Hittel a écrit :
>> Hi Quentin,
>>
>> thanks for your comments. I working my way through the specification :-).
>>
>> The goal of my thesis is to evaluate current QVT implementations based
>> on OMG´s spec.
>>
>> Right now i choose the following
>>
>> QVT-O
>>
>> Borland Together
>> SmartQVT
>> EclipseM2M
>>
>> QVT-R
>>
>> MediniQVT
>>
>> I think that are so far the best implementations of QVT that are working
>> and useable for a real software project.
>> What do you think about it, do you think this selection is making sense,
>> what do you would improve?
>>
>> The hard think about it is the evaluation of these software
>> implementations is, that the specification is just beta and far away
>> of being complete, so every program has kind of its own way to
>> interpreted the specification. So want to you think
>> is the best way to create a evaluation criteria catalog for this
>> software test?
>>
>> Other Problem is the support of the Borland Together, nobody from this
>> company is really interested in want I am trying to do.
>> I didn´t even got a trail version that is longer than 30 days, not even
>> if it's a academic purpose.
>>
>> All other project teams helped a lot, what do you think i should do? Is
>> someone from Borland working on the M2M project that could
>> help me out? Or should I kick this implementation, because all other
>> solution are open source and Borland Together isn't and therefore
>> this solution has way better requirements.
>>
>> Greetings to France.
>>
>> Thanks
>>
>> David
>>
>>
>>
>> "Quentin Glineur" <quentin.glineur@obeo.fr> schrieb im Newsbeitrag
>> news:fqlse4$hg1$1@build.eclipse.org...
>>> Hi David,
>>>
>>> answers follow up...
>>>
>>> David Hittel a écrit :
>>>> Hi,
>>>>
>>>> I am trying to get into QVT for my thesis. I am evaluating current
>>>> implementations of QVT.
>>>>
>>>> I am wondering about a part in the specification it says "...the
>>>> declarative part, as it forms the framework for the ... the imperative
>>>> part."
>>>>
>>>> From my understanding the declarative part is a two level architecture
>>>> where the Relation and Core language have the same abilities, but the
>>>> level of abstraction of the Core language is way higher, so it's more
>>>> verbose but more simple.
>>>
>>> In fact, the Relations language is more abstract. Among the different
>>> reasons, let's say this is because:
>>> - it does not have to deal with trace model (there are implicit)
>>> - it uses high level description elements such as equality artefacts
>>> (PropertyTemplateItem) whose semantics can change according to the
>>> execution (both equality checking or assignment)
>>> - the conciseness of the language whose equivalent in Core language has
>>> to be detailed...
>>>
>>>> And it says that the Relation language has the ability to convert
>>>> Relations Model into Core Models. Is this just helpful to create a
>>>> software implementation of QVT or can this be also useful in a software
>>>> project where i am using QVT as a model to model transformation, if
>>>> yes,
>>>> why?
>>>
>>> Indeed, this is helpful for the implementation. To fulfil its goal
>>> (especially of incrementality and traceability), a QVT Relations
>>> transformation can be implemented by a QVT Core transformation. Running
>>> on the top of such an engine, it then reuse all the QVT Core facilities.
>>>
>>> But this is also a proof of operationnability of the language: it is
>>> powerfull enough to express itself in a less abstract language.
>>> An analogy is done in the specification, considering the Core expression
>>> as byte code and the Relations expression as source code. This
>>> conversion is then like a compilation. This is a bootstrap description.
>>>
>>>> The only Relative language implementation is MediniQVT right now that I
>>>> know.
>>>
>>> We are implementing an Eclipse solution: browse the CVS. The QVTR
>>> compiler is smart enough to produce a correct ASM file (ATL VM byte
>>> code) for the transformation umlToRdbms. We are producing examples,
>>> Wiki, tests, and so on...
>>>
>>>> Please correct me if I understand anything wrong
>>>>
>>>> The imperative part has the Operational Mapping Language and the
>>>> Black Box.
>>>> From my understanding Black Box is just an extension to the
>>>> declarative
>>>> framework to execute external MOF Operations.
>>>
>>> Yes, it is a way to call "on the self" operations to fulfil the creation
>>> goal. The block boxes are use for the implementation of the enforcement
>>> of the direction domain semantics.
>>>
>>>> The Operational Mappings are a way of imperative QVT transformation and
>>>> can be used to extend the declarative transformation if it's not
>>>> possible to the write a pure declarative transformation, this
>>>> explanation would fit into my quote from above.
>>>>
>>>> "...the declarative part, as it forms the framework for the ... the
>>>> imperative part."
>>>>
>>>> But from my understanding that the transformation can be written
>>>> entirely written in the operational language as stated in 6.2.1 of the
>>>> Spec, didn´t fit into the quote from above, because there is no
>>>> declarative framework needed if everything is written an operational
>>>> language.
>>>>
>>>> Could you help me to understand the basic concept correct, are my
>>>> thoughts totally bullshit?
>>>
>>> I do not see any "bullshit" in your speech. In my opinion, the described
>>> architecture is a try to make several languages as part of a unique
>>> framework. But you may have noticed that no example of interoperability
>>> is given in the specification...
>>> The declarative part and the imperative one are definitively
>>> independent. We have not reach the homogeneity phase yet!
>>>
>>>> Thanks a lot
>>>>
>>>> David Hittel
>>>>
>>>
>>> Quentin GLINEUR
>>>
>>>
>>
>
>
|
|
|
| Re: [QVTR] General question about QVT Spec [message #76718 is a reply to message #76255] |
Thu, 13 March 2008 16:10 |
| Eclipse User |
|
|
|
Originally posted by: quentin.glineur.obeo.fr
This is a multi-part message in MIME format.
--------------080105050203060007060707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi David,
Indeed, the choice of a technology must be though in terms of a response
to a particular need in a particular context.
QVTR and QVTOM has, for me, different use cases. For example, QVTOM is
mainly for quick model construction with an imperative approach
(suitable for "regular" programmers) whereas QVTR offers the way to tie
semantically two models (with declarative approach i.e. more easily
maintainable (for me!)).
The rest is chapel fight! ;)
Quentin
David Hittel a
|
|
|
Goto Forum:
Current Time: Thu Apr 18 20:38:09 GMT 2024
Powered by FUDForum. Page generated in 0.01685 seconds |
] 
Search
Help
Register
Login
Home
