Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-Relations » QVT expressivity
QVT expressivity [message #1064432] Wed, 19 June 2013 09:00 Go to next message
Skander TURKI is currently offline Skander TURKIFriend
Messages: 128
Registered: July 2009
Senior Member
Hi,
I wanted to ask some questions about the expressivity of QVT that seems to me to be a little bit limited compared to other M2M languages (I may be wrong):
1- In defining a domain, in QVT, it seems we can only select one object of one type (c: UML::Class) we cannot for example select all tuples (c1:UMLClass, c2:UMLClass) as a single domain. Of course we can declare two distinct domains for each element, but if we could make a first filtering on the (c1, c2) couples, we could reduce the number of candidate tuples for the rule. If we could write something like:

checkonly domain
source c1:UML::Class,
source c2:UML::Class:
{
...
when{
-- domain-level pre-condition
c1<>c2;
}
};
....
when{
-- relation-level pre-condition
}

2- All the examples from the QVT spec and from the MediniQVT tutorials use meta-models that are designed following a special pattern:
"the contained elements (for example classes) have a reference (myPackage) to the container (package)."
No example is given with a container that has a collection of references (non eOpposite) to its contained elements. How this is delt with in QVT?


Thanks
Re: QVT expressivity [message #1064437 is a reply to message #1064432] Wed, 19 June 2013 09:16 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4185
Registered: July 2009
Senior Member
Hi Skander

IMHO you have hit on an area where the QVTr (and QVTc and QVTo)
specifications are at best vague. I think that an additional 'rooting'
condition needs to be available for specification by the invoking
context, and a much clearer semantics of collection matching is required.

I would tentatively expect that if you apply a transformation defined on
C=>D to a Collection(C) that the result will be a Collection(D).

In UMLX where I tried to support collection matching, you would specify
Collection(C)[2] as the input type so that the transformation would be
applied to all distinct permutations of two Cs.

I currently have student working on realizing a QVTr to qVTc to QVTu to
QVTm to QVTi to OCL to Java chain. I expect that the precision of
Collection matching is something that we get to in about a year's time.

Regards

Ed Willink


On 19/06/2013 11:00, Skander Turki wrote:
> Hi,
> I wanted to ask some questions about the expressivity of QVT that
> seems to me to be a little bit limited compared to other M2M languages
> (I may be wrong):
> 1- In defining a domain, in QVT, it seems we can only select one
> object of one type (c: UML::Class) we cannot for example select all
> tuples (c1:UMLClass, c2:UMLClass) as a single domain. Of course we can
> declare two distinct domains for each element, but if we could make a
> first filtering on the (c1, c2) couples, we could reduce the number of
> candidate tuples for the rule. If we could write something like:
>
> checkonly domain source c1:UML::Class,
> source c2:UML::Class:
> {
> ...
> when{
> -- domain-level pre-condition
> c1<>c2;
> }
> };
> ....
> when{ -- relation-level pre-condition
> }
>
> 2- All the examples from the QVT spec and from the MediniQVT tutorials
> use meta-models that are designed following a special pattern:
> "the contained elements (for example classes) have a reference
> (myPackage) to the container (package)."
> No example is given with a container that has a collection of
> references (non eOpposite) to its contained elements. How this is delt
> with in QVT?
>
>
> Thanks
>
Re: QVT expressivity [message #1064461 is a reply to message #1064437] Wed, 19 June 2013 11:59 Go to previous messageGo to next message
Skander TURKI is currently offline Skander TURKIFriend
Messages: 128
Registered: July 2009
Senior Member
In fact, the QVT-R (chapter 7) in the spec in quite brief. I think it should be developed in a separate spec. I don't understand why these implementation issues are part of the spec (I mean the the compilation chain).
Do you know if another version of the spec is under development?
Re: QVT expressivity [message #1064471 is a reply to message #1064461] Wed, 19 June 2013 12:29 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4185
Registered: July 2009
Senior Member
Hi Skander

If you compare the QVT spec with the OCL spec it is immediately clear
how much is missing. If you study the OCL spec, it doesn't stand for
much close examination. These specifications are really hard to right.

The forthcoming UML 2.5 specification makes a major step forward with
the underlying models being normative and the resulting text (50%
autogenerated) being fairly consistent and only informative.

For OCL I am trying to get closer to 100% auto-generated and to reuse
the autogeneration technology for QVT. But don't expect to see a better
QVT specification for at least a couple of years.

Regards

Ed Willink


On 19/06/2013 13:59, Skander Turki wrote:
> In fact, the QVT-R (chapter 7) in the spec in quite brief. I think it
> should be developed in a separate spec. I don't understand why these
> implementation issues are part of the spec (I mean the the compilation
> chain).
> Do you know if another version of the spec is under development?
Re: QVT expressivity [message #1064499 is a reply to message #1064471] Wed, 19 June 2013 14:01 Go to previous message
Skander TURKI is currently offline Skander TURKIFriend
Messages: 128
Registered: July 2009
Senior Member
Thanks a lot. I know it's easier to criticize.
Previous Topic:[Announce] Eclipse QVTd 0.10.0 (Kepler) RC1 is now available
Next Topic:Current status of QVTd?
Goto Forum:
  


Current Time: Thu Dec 18 20:26:12 GMT 2014

Powered by FUDForum. Page generated in 0.08417 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software