Hi
Consideration of a declarative transformation cascade forces a new
choice for allInstances:
Regards
Ed Willink
OCL's
allInstances() applies to the one and only immutable model extent.
The meaning of
this in QVT with multiple, some mutable,
extents/domains/typedModels
is unclear.
Suggest that
allInstances applies to all the input and original inout extents
only.
Obtaining
instances from other domains is available through alternate
library
operations such as objectsOfType in QVTo.
Discussion
-
QVTo
allInstances()
could be defined to apply to the initial, prevailing or final
state.
Since a QVTo execution proceeds through a predictable sequence of
states limiting allInstances() to the initial state is unhelpful.
A
limitation to the final state is almost unuseable and may require
a
tool to introduce another form of late processing. Therefore the
prevailing state is most appropriate for a QVTo allInstances().The
returned instances are the mutable instances since any form of
caching would impose an unjustified overhead.
Discussion
-
QVTr/QVTc
allInstances()
could be defined to apply to the initial, prevailing or final
state.
The initial state is easy. The prevailing state does not exist
declaratively. The final state is harder but may be useful for
computing derived output values based on the outputs.
However
consider a cascade of endogeneous transformations A2B, B2C, C2D in
which B2C performs an allInstances(). If we now compose the trio
into
A2B2C2D, the functionality of the allInstances() must not change.
Therefore neither initial nor final state will do, since the
initial
state changes from B to A and the final state from C to D. We must
use a prevailing state, which we can define as the final state of
the
domain in which the invocation of allInstances() occurs. For our
example this is either B or C and does not change as a consequence
of
the cascade.
Revised
Text:
|
Add a new sub-clause
6.5 OCL usage in QVT
Essential OCL is used as the expressions
language for QVT Relations, Core and Operational Mappings.
Additionally, QVT Operational Mappings defines an
extension of Essential OCL, named Imperative OCL, to
provide the side-effect constructs required by this
imperative language
OCL is a side effect free language that supports
evaluation of constraints on the state of the objects in a
model. (Operation pre- and post-conditions and @pre extend
this to two states.) The controlled mechanisms for object
mutation of the QVT languages conflicts with OCL's
expectations of stability. These conflicts are clarified
in this subclause. .
The declarative QVTc and QVTr languages may
cascade mappings in which OCL evaluations access
intermediate objects. These evaluations occur predictably
for either an old or a new state of an object. An old
state is inherently stable. The new state is stabilized by
the declarative computation of values before usage. An
exception however arises for allInstances() for
which the declarative mapping execution order is difficult
for a programmer to predict with certainty. allInstances()
is therefore defined to return the final state of
instances in the domain within which allInstances()
is invoked.
The imperative QVTo language performs object
mutations as it advances from one program state to another
in a predictable order. OCL evaluation may be used within
each state. The functionality of allInstances()
is clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation
allInstances() returns all instances of the classifier
and the classifiers specializing it. May only be used
for classifiers that have a finite number of instances.
This is the case, for example, for user defined classes
because instances need to be created explicitly, and for
enumerations, the standard Boolean type, and other
special types such as OclVoid. This is not the case, for
example, for data types such as collection types or the
standard String, UnlimitedNatural, Integer, and Real
types.
This needs clarification for use in an
imperative QVTo context for which OCL's expectation of an
unchanging context is only valid within sub-expressions of
an ImperativeExpression. Successive calls to allInstances()
may return different sets of mutable instances during the
execution of the transformation.
Instances are returned from the all model
extents for input, inout and output models. Instances of
intermediate objects are not returned unless they have
been added to an extent. Instances from a metamodel are
not returned unless the metamodel is also an input model.
The Model::objectsOfKind() operation may be used
to return selected instances from a particular model
extent.
|
On 07/10/2015 15:26, Adolfo
Sanchez-Barbudo Herrera wrote:
On 07/10/2015 14:48, Ed Willink wrote:
Hi
You make a case for QVTc/r to have a Model::objectsOfKind, so
that a cascade of 'transformations' can use domains to
communicate and interrogate them.
We have two weeks before the ballot 4 preview. Deferring an
understood topic is very undesirable because it just means we
start all over again in one/two years time.
Fair enough. I'm not in the QVT RTF (I can't vote againts this
resolution), so the only thing I can do is identify
inconsistencies/mistakes. My last comments:
- "allInstances() is therefore evaluated before input
models are changed."
input models are not changed. Perhaps, you meant transformed.
I'm not familiar how QVTd deals with in-place transformations, but
the same problem (which appear when initially caching
type-2-instances) we discussed for QVTo also should apply in
QVTr/QVTc.
Conclusion:
- I see no fundamental reason to prohibit or constraint
allInstances() usage in QVT (regardless we are talking on
QVTo/r/c).
- IMO, there is a clear bias from an implemention (which has not
been clarified) perspective, which doesn't justify the
specification change.
- I can consider any change towards this unnecessary direction, as
prejudicial to the specification. Time will say if that was a good
decision or a bad one.
- I'd be in favor of just adding
suggestions/recommendations/well-practices of not using
allInstances in QVTd transformations (justification related to
this, as the one proposed in the resolution, would be required)
Regards,
Adolfo.
Regards
Ed
On 07/10/2015 14:27, Adolfo
Sanchez-Barbudo Herrera wrote:
On 07/10/2015 13:16, Ed Willink wrote:
Hi
We could certainly specify that declaratively allInstances()
is computed after loading but before executing.
Unfortunately, this doesn't support the transformation
scenario I exposed, which requires obtaining the instances on
outputs. Apart from not benefiting from the initial caching,
I'm still struggling to see what's wrong with allInstances on
outputs. Apparently, I kinda convinced you about its utility
in QVTo, I thought my last example would do the same with
QVTd.... getting closer :P.
If all of this is not convincing to any of us, perhaps it
should be deferred as Sergey suggested. I don't expect you
will get better feedback (well, it would be late anyway) from
the RTF during voting period. Perhaps, you could try to move
the specific question to the RTF mailing-list, to see if there
is more luck.
The "specification" of allInstances that I quoted is in
8.3.8. Not in 11.x where you might expect.
>> - "The properties of individual instances may
change as a result of assignments". Not sure what this
>> sentence contributes to allInstances => Remove
it ?
Just trying to highlight that instances may mutate; no
cached copies are referenced.
Editorial comments included in latest draft below:
Found a typo:
"The controlled mechanisms ... conflicts" -> "The
controlled mechanisms .... conflict"
Also revise punctuation in that paragraph.
Regards,
Adolfo.
QVTc/QVTo/QVTr - http://solitaire.omg.org/browse/QVT13-101
Regards
Ed
Add a new sub-clause
6.5 OCL usage in QVT
Essential OCL is used as the expressions language
for QVT Relations, Core and Operational Mappings.
Additionally, QVT Operational Mappings defines an
extension of Essential OCL, named Imperative OCL, to
provide the side-effect constructs required by this
imperative language
OCL is a side effect free language that supports
evaluation of constraints on the state of the
objects in a model. (Operation pre- and
post-conditions and @pre extend this to two states.)
The controlled mechanisms for object mutation of the
QVT languages conflicts with OCL's expectations of
stability. These conflicts are clarified in this
subclause. .
The declarative QVTc and QVTr languages may cascade
mappings in which OCL evaluations access
intermediate objects. These evaluations occur
predictably for either an old or a new state of an
object. An old state is inherently stable. The new
state is stabilized by the declarative computation
of values before usage. An exception however arises
for allInstances() for which the
declarative mapping execution order is difficult for
a programmer to predict with certainty. allInstances()
is therefore evaluated before input models are
changed.
The imperative QVTo language performs object
mutations as it advances from one program state to
another in a predictable order. OCL evaluation may
be used within each state. The functionality of allInstances()
is clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation
allInstances() returns all instances of the
classifier and the classifiers specializing it.
May only be used for classifiers that have a
finite number of instances. This is the case, for
example, for user defined classes because
instances need to be created explicitly, and for
enumerations, the standard Boolean type, and other
special types such as OclVoid. This is not the
case, for example, for data types such as
collection types or the standard String,
UnlimitedNatural, Integer, and Real types.
This needs clarification for use in an imperative
QVTo context for which OCL's expectation of an
unchanging context is only valid within
sub-expressions of an ImperativeExpression.
Successive calls to T::allInstances() may
return different sets of mutable instances during
the execution of the transformation.
Instances are returned from the all model extents
for input, inout and output models. Instances of
intermediate objects are not returned unless they
have been added to an extent. Instances from a
metamodel are not returned unless the metamodel is
also an input model. The Model::objectsOfKind()
operation may be used to return selected instances
from a particular model extent.
On 07/10/2015 12:36, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,
6.5 Clarification is useful, but I don't like
"allInstances() is therefore not available for use by
declarative transformations". In any case, not
recommended. Let me expose another simple example:
1. Imagine I have a transformation a declarative
transformation which from models conforming to XX
metamodel we create models conforming to metamodel YY
2. Then I could create an extending transformation of that
one, with the goal of not only performing the extended
transformation, but it also receives and additional model
parameter conformint to metamodel MM to get some analysis
results.
3. I could have additional rules like the following (take
the following as pseudo-code):
rule measureYs
from XX::RootX
to MM::YMeasurement {
numberOfInstances :=
YY::Y.allInstances()->size()
}
allInstances is useful in this scenario. Why prohibiting
it ? Is there another way to declaratively express this ?
scheduling wise, the rule needs to be executed somewhere
after all rules producing Y have been executed, but I
don't see a problem at all.
*Resuming, allInstances are not normally needed and its
usage might prevent efficient schedules. That said, I
believe it should not be prohibited in QVT, in any case
discouraged/not recommended in declarative languages.*
- I'd set the 6.5 title as "OCL usage in QVT". I'm unsure
if it's better to firstly introduce the relation between
OCL and QVT (i.e. Should the section be 6.1 rather than
6.5). The following introductory paragraph should be
welcomed to the section:
"Essential OCL is reused by the three QVT languages
exposed in this specification. It comprises the
expressions language for QVT Relations, Core and
Operational Mappings. Additionally, QVT Operational
Mappings defines an extension of Essential OCL, named
Imperative OCL, to provide the side-effect constructs
required by this imperative language".
Then the "OCL is a side effect free language .... " should
nicely follow
- NB, I looked for QVTc, QVTr, QVTo acronyms. I just found
one QVTc occurrence (probably from a QVT 1.2. issue
resolution). I'm not against to start to using them, but
we probably need to properly introduce them in the
specification.
8.3.18
- "The OCL definition is: The operation
allInstances() returns all instances of the classifier
and the classifiers specializing it"
I look for that definition in OCL and I didn't find it.
Moreover, I'm unsure what you want to mean with "and the
classifiers specializing it".
- "and other special types such as OclVoid" . We
don't need/should not be vague here. Which one else... I
guess that just OclInvalid, right ? => "and the special
types OclVoid and OclInvalid"
- "The properties of individual instances may change as a
result of assignments". Not sure what this sentence
contributes to allInstances => Remove it ?
Regards,
Adolfo.
On 06/10/2015 17:45, Ed
Willink wrote:
Hi
A change in OCL is not an option, since there will be no
new OCL specifiction for at least a year.
Another try below.
Regards
Ed
Add a new sub-clause
6.5 Interpretation of the OCL specification
OCL is a side effect free language that supports
evaluation of constraints on the state of the
objects in a model. (Operation pre- and
post-conditions and @pre extend this to two
states.) The controlled mechanisms for object
mutation of the QVT languages conflicts with OCL's
expectations of stability. These conflicts are
clarified in this subclause. .
The declarative QVTc and QVTr languages may
cascade mappings in which OCL evaluations access
intermediate objects. These evaluations occur
predictably for either an old or a new state of an
object. An old state is inherently stable. The new
state is stabilized by the declarative computation
of values before usage. An exception however
arises for allInstances() for which the
declarative mapping execution order is difficult
for a programmer to predict with certainty. This
is not surprising since the uncertain order is a
consequence of the search for matches traversing
all relevant instances anyway. allInstances()
is therefore not available for use by declarative
transformations.
The imperative QVTo language performs object
mutations as it advances from one program state to
another in a predictable order. OCL evaluation may
be used within each state. The functionality of allInstances()
is clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation
allInstances() returns all instances of the
classifier and the classifiers specializing it.
May only be used for classifiers that have a
finite number of instances. This is the case,
for example, for user defined classes because
instances need to be created explicitly, and for
enumerations, the standard Boolean type, and
other special types such as OclVoid. This is not
the case, for example, for data types such as
collection types or the standard String,
UnlimitedNatural, Integer, and Real types.
This needs clarification for use in an imperative
QVTo context for which OCL's expectation of an
unchanging context is only valid within
sub-expressions of an ImperativeExpression.
The sets of instances returned by successive calls
to T::allInstances() may grow or shrink
during the execution of the transformation. The
properties of individual instances may change as a
result of assignments.
Instances are returned from the all model extents
for input, inout and output models. Instances of
intermediate objects are not returned unless they
have been added to an extent. Instances from a
metamodel are not returned unless the metamodel is
also an input model. The Model::objectsOfKind()
operation may be used to return selected instances
from a particular model extent.
On 06/10/2015 13:30, Adolfo
Sanchez-Barbudo Herrera wrote:
On 06/10/2015 11:47, Ed Willink wrote:
allInstances() is
underspecified, in particular the extent from the
instances are discovered is unclear
Hi Ed,
I think that this a problem that should be clarified
in OCL, rather than in QVT. I see allInstances working
on a kind of "Environment" or "Scope" (e.g.
ResourceSet in EMF? initial Resource plus all
reachable Resources from it? ). Whatever how "wide"
the scope is something to be considered/clarified for
both OCL and QVT. Ideally, a good clarification in
OCL, might transparently be applied to QVT.
Regards,
Adolfo.
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10768 -
Release Date: 10/06/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No
virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10773 -
Release Date: 10/07/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10773 - Release
Date: 10/07/15
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10774 - Release
Date: 10/07/15
|