Issue 15416: Derived properties in QVTr (qvt-rtf)
Source:  (Dr. Maged Elaasar, melaasar(at)gmail.com)
Nature: Uncategorized Issue
Severity: 
Summary: If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class {
self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point
}

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class {...}
}
}

}

does this make sense?

Resolution: 
Revised Text: 
Actions taken:
August 13, 2010: received issue
Discussion: 

End of Annotations:=====
ubject: Derived properties in QVTr
To: qvt-rtf@omg.org
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Maged Elaasar <melaasar@ca.ibm.com>
Date: Fri, 13 Aug 2010 11:36:55 -0400
X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at
 08/13/2010 11:36:56


Hi All, I have a question on QVTr:

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class {
self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point
}

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class {...}
}
}

}

does this make sense?


Maged Elaasar, PhD Candidate
Senior Software Engineer, Rational Modeling Tools
IBM Representative@OMG, CAS Research Staff Member
IBM Canada, Ottawa Lab, +1 613 270 4651 



X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOkIZUzUnw4U/2dsb2JhbACfUmdxvi+DCoIwBA
Date: Fri, 13 Aug 2010 17:00:22 +0100
From: Ed Willink <ed@willink.me.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
To: Maged Elaasar <melaasar@ca.ibm.com>
CC: qvt-rtf@omg.org
Subject: Re: Derived properties in QVTr


Hi Maged

[Juergen: this is worth an Issue.]

QVTr already has queries but they are much less user friendly than e.g. MOFM2T's equivelent for which the first parameter is a hidden self, or indeed QVTo.

Perhaps something closer to Complete OCL would do, allowing def'd attributes or operations.

    Regards

        Ed Willink

On 13/08/2010 16:36, Maged Elaasar wrote: 
Hi All, I have a question on QVTr:

If I want to specify a uni-directional transformation using QVTr, is it ok to use "derived" properties in source domains' object templates? I guess since the transform is not meant to be run in the opposite direction, this will not create a problem?

If that is allowed, it would be a good additional feature of QVTr to allow the definition of new derived properties right in the transform, instead of having them only in the source metamodel.

For example

transform A (...) {

property Class::allSuperClass : Class {
self->closure(self.superClass) // closure might not be standard collection op but I used it just to demonstrate the point
}

relation B {
checkonly domain source c:Class {
allSuperClass = super:Class {...}
}
}

}

does this make sense?


Maged Elaasar, PhD Candidate
Senior Software Engineer, Rational Modeling Tools
IBM Representative@OMG, CAS Research Staff Member
IBM Canada, Ottawa Lab, +1 613 270 4651



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3067 - Release Date: 08/12/10 19:34:00