Issue 15416: Derived properties in QVTr (qvt-rtf)
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
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
July 15, 2014: closed issue
Discussion: 
Use of derived properties while checking should pose no problem. The existing text on values is
sound.
Use of derived properties while enforcing is highly suspect. Derived properties are often readonly. If
changeable then the derived interrelationships are an issue for the metamodel not for QVTr.
When QVTr acquires well-formedness rules, an enforeable readonly property could be diagnosed.
QVTr supports queries that can be used to emulate custom derived properties.
Disposition: Closed, No Change
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