Issue 10938: 9.17 Variable composition (qvt-rtf)
Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity: 
Summary: Issue 9379 made Pattern.bindsTo a non-composition.


This deprives Core of any parent for its non-realized variables.


Suggest: move BottomPattern.realizedVariables to CorePattern.variables.


CorePattern.variables then composes all variables declared for the pattern. A class-type
check of RealizedVariable/Variable derives the 'isRealized' property.

Resolution: It is convenient to keep realized and unrealized variables separate to avoid unnecessary isRealized
tests.
Just add CorePattern.variables to compose the unrealized variables.
Revised Text: In 9.17.1 CorePattern add
variable: Variable [*] {composes} {opposite corePattern:CorePattern[?]}
Unrealized guard pattern variables are the unbound variables of the pattern. Unrealized bottom pattern
variables may be used to factor out common expressions.
In Figure 9.2 add
a CorePattern to Variable composition arc for CorePattern.variable
Update QVTcore models accordingly.
Actions taken:
March 25, 2007: received issue
July 15, 2014: closed issue
Discussion: 

End of Annotations:=====
s is issue # 10938	From: "Ed Willink" <ed@willink.me.uk>

9.17 Variable composition

Issue 9379 made Pattern.bindsTo a non-composition.


This deprives Core of any parent for its non-realized variables.


Suggest: move BottomPattern.realizedVariables to CorePattern.variables.


CorePattern.variables then composes all variables declared for the pattern. A class-type
From: "Ed Willink" <ed@willink.me.uk>
To: <mof-qvt-ftf@omg.org>
Subject: Re: Issue 10938 (was RE: QVTbase, QVTcore and QVTrelation updated diagram review comments)
Date: Sat, 16 Jun 2007 13:52:04 +0100
X-Mailer: Microsoft Outlook, Build 10.0.6822
Thread-Index: AcekP/8cZu8YOp9VS2ipSPHTZvbI3gACChsQAvHlxyA=


Hi Mariano


Migrating Relation::variable to Rule::variable could work but introduces
a semantic change. Variables are currently scoped by domain, so the same
variable name may have a different identity in each domain. The above migration
would prohibit such name re-use (perhaps a good idea anyway).


Sadly, the LetExp workaround doesn't work. Assignments are not OclExpressions
and so cannot be used as a condition expression in a LetExp. Un-realized variables
cannot therefore be used within 'assignments'. The workaround does not work
very well for predicates either, since a multi-term predicate must either
be wrapped in a composing AND to be a single term for the LetExp tree, or
the LetExp tree must be (partially) replicated for each predicate.


Assignment has no super-class at present, so defining an Assignment as a
(Boolean)OclExpression could be sensible and would at least make the
workaround possible.


        Regards


                Ed Willink


> -----Original Message-----
> From: BELAUNDE Mariano RD-MAPS-LAN 
> [mailto:mariano.belaunde@orange-ftgroup.com] 
> Sent: 01 June 2007 13:59
> To: Ed Willink; mof-qvt-ftf@omg.org
> Subject: RE: QVTbase, QVTcore and QVTrelation updated diagram 
> review comments
> (3) Concerning the ownership of variables in QvtCore, to be in line
>   with the approach taken in the relational part, I believe the best
>   solution to the deferred issue 10938 would be  to move the
>   Relation::variable to its superclass
>   Rule::variable so that it becomes usable in the Core part.
>   Anyway, there is an easy turnaround to the problem of ownership
>   of variables you were mentioning: since a Pattern owns Predicates
>   which in turns owns a condition expression, we can use OCL
check of RealizedVariable/Variable derives the 'isRealized' property.