8.1.8 has
column := self.attribute->new(a) Column(a.name,getSqlType(a.type));
Surely the (a) is a typo?
8.4.6 introduces a <<>> syntax with an example whereby <<id>> provides the UML isID identification. The syntax appears as part of a general <<IDENTIFIER,IDENTIFIER>> syntax so presumably there may be many idenientofioers not just the "id" special case. Surely the IDENTOFOER should at least be a qualified name to identify the package and surely "id" should be qualified to indicate that it is from a UML namespace and should be spelled in accordance with UML spelling?
QVT supports two styles of comment, single/multi-line each of which may precede/follow the commented syntax element. (A leading new-line distinguishes a preceding from a following comment).
The QVT AS inherits a Comment element from MOF with body and annotatedElement properties. This is inadequate to distinguish the two styles or the two positions. Could be fixed by a couple of Boolean properties.
Comments may also be applied to punctuation that has no corresponding model element.
if x then y
else // must have an else
z endif
Perhaps an annotatedText is necessary to allow a comment to refer to punctuation
<comment multiline="false" prefix="false" annotatedText="else" body="must have an else"/>
Might need an annotatedIndex too for the case where the annotatedText occurs multiple times.
Since the annotatedElement is already there, it might be less klunky to anchor the markup with annotatedElement="...z..." precedingText="else", where "...z..." is the appropriate fragment to reference the z element.
In the standard it is stated that all source variables of a relation must be bound, in order for the relation to be applied. This seems the only reasonable approach for relation application. However it has an interesting consequence in the case of *-multiplicity references r, or indeed for any reference r with multiplicity lower bound 0. The source domain in
top relation R
{ checkonly domain src e : E { r = rx : R {}, att = attvalue };
enforce domain trg f : F { rr = rrx : R1 {}, attf = attvalue };
}
will not match to an E instance x which has empty x.r, because rx cannot be bound to any element, and hence the relation R will not be applied to such x - and att will not be copied to attf.
In other cases (non-empty x.r), instances of E are copied to instances of F, and a specifier could expect that R copies x : E with empty x.r to a y : F with empty y.rr, but because of the totality requirement on source bindings, no y is produced for such x.
The QVT specification should alert specifiers to this issue, and that in such cases it would be necessary to split the above relation into two parts, one handling the mandatory features and other parts for each optional feature.
Note that this issue does not arise in languages such as QVT-O and ATL where copying of optional features can be done 'all at once' rather than element-by-element.
The descriptions regarding checkonly and enforce are incomplete and the examples are misleading.
When a domain is selected as a target, there are three execution possibilities.
The illegal state is never described, but is at the heart of a unidirectional transformation for which, as in RelToCore, the source-only domain has no checkonly/enforce and the target-only domain has enforce.
In contrast almost all of the UML2RDBMS examples have the uml domain marked as checkonly, which requires that an execution from RDBMS to check a pre-existing UML is permissible. This requires that the transformation is genuinely bidirectional although by using checkonly rather than enforce the programmer has unhelpfully prohibited the to-UML result from being persisted.
It is doubtful that checkonly has any value at all as a concrete syntax / abstract syntax annotation. Surely a plausible output domain is always enforce; it is the way in which the transformation is invoked that configures whether the enforce creates/replaces/updates/compares/checks... ? Perhaps it is the redundancy of checkonly that has led to the misunderstandings exemplified by the UML2RDBMS example that checkonly marks the input of a unidirectional relation.
Actions required:
In 7.11.3.8, RelationCallExp.argument has a lowerbound of 2 which seems sensible because surely any Relation must have at least an input and an output?
No. A single output non-top Relation is useful to create a singleton output object independent of any input objects. Distinct when invocations can establish singleton ownership in one place and usage in many places.
The lowerbound should therefore be 1.
The QVTr specification does not clarify if top relations can be called from where clauses. It would seem to be a source of potential errors if top relations were both explicitly invoked from where clauses and implicitly invoked by the usual mechanism for top relations. An explicit call R(a,b) of a top relation would normally be redundant because R would be attempted on the source element a in any case through the normal mechanism.
The clause should additionally state "Top level relations cannot be invoked from a where clause". As a consequence, primitive domains are only needed in non-top relations (clause 7.2.4 can state that primitive domains should only appear in non-top relations).
An <objectTemplate> may have an empty list of <propertyTemplate> but the surrounding {} are mandatory. Similarly a <collectionTemplate> may have an empty list of members but the surrounding {} are mandatory.
It is common for patterns to refer to properties / members by type and often name without caring about nested properties / members, but because of the syntax the user must contend with a confusing syntax error until the {} are added.
The user experience and patterns can be somewhat simpler if the {} can be omitted for empty content.
The fourth QVT14-59 comment identifies that Primitive Domain root variables are not useable.
A top primitive domain input is only useful if the specification provides a mechanism to pass configuration to these inputs. It doesn't, so top primitive domains seem useless as is, and perhaps better supported by contextual properties.
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=548536 I thought a non-top primitive domain might be useful, but realized that the primitives were inputs in one direction and outputs in another violating the 7.2.4 restriction to inputs. Now that multiple root variables are permitted it seems that the primitive domain root variables should be moved to the appropriate domain so that they are directional. RelToCore does not use primitive domains. It appears that a genuine use case for a primitive domain with a root variable is lacking.
Suggest: Replace the unfullied potential paramerization of top relations by immutable contextual trasformation properties in similar style to QVTo.
Primitive domains are then reduced to the vague host domain of shared relation variables such as "name : String".
8.1.3.2 says
Each Extent for an in Model Parameter is immutable. It may be shared when the same external model is loaded by multiple in Model Parameters.
8.1.3.4 says
The roots of the forest have no containers, rather they are members of at most one Extent...
Clearly the elements of a common sub-model loaded by/referenced for two distinct Model Parameters are shared, else there could be confusing duplicates. These elements are in multiple extents contradicting the "at most on".
Suggest revise 8.1.3.4 to
The roots of the forest have no containers, rather they are members of typically one Extent... A shared root may be a member of mutiple Extents.
QVT13-26 requested support for collections of input models. This was resolved by generalizing the type of a ModelParameter to allow a Collection. This change was not necessary.
If each input model has a distinct Extent, there need be no prohibition on the passing of multiple Extents to a single TypedModel. By default this will be treated as a multi-rooted model.
In QVTr/QVTc where Extent is currently unused, reification of Extent as a transformable model element solves problems with providing a 'container' for multi-rooted models and allows collections of input/output models per TypedModel to be managed.
In QVTo, Extent can be similarly reified but care is required to separate the similar functionality of Model as the/one-of-the TypedModel instances.
In QVTo the a paremnt mapping may pull its child mappings by e.g.
result.children := self.children->map Child2Child();
QVTr has no counterpart to this. It is needed by those pursuing a procedural style with where clause sequencing. Relations such as RVarSetToMBVarSet in RelToCore demonstrate the need for a multi-invocation.
Since multi-directional usage prohibits the use of a result as in QVTo, suggest that a 1:1 relation invocation may be invoked to perform a N:N mapping by passing a collection where a non-collection was expected to at most one of the root variables of each domain.
QVTr (and QVTc) defines check and enforce modes with a check-before-enforce specified to suppress a redundant enforce. This seems sensible but is only possible for trivial cases. A relation/mapping defines constraints between objects that check mode can validate. But while checking before enforcing none of the intermediate and trace objects exist, so only trivial relations/mappings whose intermediate objects can be inferred can actually be checked. In the general case most of an enforce execution must be performed in order to create the intermediates. In practice, much simpler to specify a full enforce to an internal-output that can then be synchronized with the output-under-test. Successful synchronization determines the check success. If an internal-output is still available as a consequence of an earlier enforce, then a synchronize and check of yet another output-under-test can re-use the enforce. But check cannot be done without a prior enforce. For the trivial cases implementations may synthesize an optimized enforce/synchronize to improve check performance.
Given an enforced pattern such as:
a:A { b = b:B
{ c = c:C }}
there is an ambiguity as to whether the target of a.b is to be enforced remotely and then re-used here (checked) or enforced locally, so it is enforced locally.
This may perhaps be worked around using a Key, but the user must elaborate the pattern to redundantly define all the Key parts.
This may be worked around using a when pattern that relates "b" to its enforcement elsewhere.
Both the workarounds are tedious.
It is possible that there is some smart related to containment relationships that can do better, but more likely it just adds confusion and requires deeper user insight.
Suggest that remotely enforced PropertyTemplateItems can be annotated as checkonly to make the intent explicit.
a:A { checkonly b = b:B
{ c = c:C }}
An overriding relation may need to create nothing when the derived input pattern does not need transformation by the polymorphism. It might be transformed elsewhere explicitly. (Concrete example is OclType in the ATL metamodel which is defined as a derived OclExpression in ATL but not in OCL.)
Create nothing could be achieved by omitting the engforced domain but that violates a consistent overrideing domains WFR.
Create nothing is more sensibly achieved by no output patterns in the enforced domain,
The semantics of Keys wrt to derived types is unspecified and as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=512532 far from obvious.
What are the WFRs for Keys?
Are multiple keys per type allowed?
Is key uniqueness applicable to derived types? or does each key have an implicit, distinct derived key for each derived and miltiply-derived type?
Can a realized access of a Keyed variable return a differenr class that shares the same key?
The soundness of QVTr relies on the fallacy that the Rel2Core transformation fully defines the QVTr semantics in terms of the fully defined QVTc semantics. The QVTc semantics are unfortunately not fully defined and the semantic errors in Rel2Core demonstrate that it can never have been exercised. When Rel2Core is consulted to determine the semantics of collection templates or relation overrides or .... oops. Missing.
I have been trying to prototype a viable QVTr2QVTc as part of the Eclipse QVTd project and solved most of the problems, but...
It is not sensible to transform a hierarchy of non-top overriding relations into QVTc since the need to partition each overriding relation into a pair of unfailing predicate matching and residual execution mappings is unreasonably hard using the very unhelpful ObjectTemplateExp+VariableExp+Variable pattern 'node's. A more sensible graphical PatternNode representation is necessary for readability and sanity.
Suggest that a graphical QVTg representation be introduced so that QVTc and QVTr are defined by more realistic QVTc2QVTg and QVTr2QVTg transformations. Bypassing QVTc should avoid the need for QVTr2QVTc to provide an heroic workaround for every QVTc limitation.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=529130 for more discussion.
Model copy is a potentially well-defined behavior that can have a useful default implicit functionality.
QVTr and QVTc have no copy.
QVTo has a deep copy but since it is a library operation it is not part of the language and so it has no associated traceability. A first class copy is needed. See ICMT 2017: Christopher Gerking, David Schubert and Ingo Budde: Reducing the Verbosity of Imperative Model Refinements by using General-Purpose Language Facilities.
UML supports templated types.
OCL is aligned with UML.
QVT extends OCL.
Therefore QVT supports templated types possibly just through grammar inheritance.
For relations, that have some similarities to operations, a template signature is required in order to allow a user to bind a specific enforced type. In the absence of templates, a relation defined on the template parameter lowerbound can only enforce the lowerbound.
QVTr imposes an unnatural declaration order in the exposition of a RelationCS. Surely the when clause should be early and variable declarations where initializeable?
Suggest relaxing the ordering constraint on declarations in a RelationCS to permit the more readable order
The abstract syntax of QVTr allows a rule to be an override of another rule.
Rule::overrides: Rule [0..1]
The rule that this rule overrides.
The concrete syntax of QVT allows it too:
<relation> ::= ['top'] 'relation' <identifier>
['overrides' <identifier>]
'
'
However, the only semantics I can see for 'overrides' is in clause 7.11.1.4 that says:
"A rule may conditionally override another rule. The overriding rule is executed in place of the overridden rule when the overriding conditions are satisfied. The exact semantics of overriding are subclass specific. "
Questions:
1- What are the overriding conditions? are they implied or specified and if so how?
2- I have not seen any other discussion of overriding in a subclass or Rule so not sure what is meant by "The exact semantics of overriding are subclass specific"?
3- I have not seen any example of using 'overrides' what so ever in the spec, shouldn't there be one?
4 - What is the semantics of overriding? is it related to inheritance in the OO sense ? I think QVTr needs a good "inheritance" model where you can relations can be called polymorphically.
Rule::overrides specifies the Rule that this Rule overrides; no problem.
The remote Rule is overridden by this rule.
But the opposite of Rule::overrides is called overidden.Wrong way round, It should be called overriding. Rule::overriding navigates to the (many) Rules that override (not are overridden by) this Rule.
If a variable has an invalid value and that variable is used by passing it to log(), it should not cause an assertion failure on the use of invalid.
QVT 1.3 removed the artificial restriction on 1 root variable per QVTr domain, but neglected to provide the elaboration for multiple roots per primitive domain. THis is needed to pass 2 parameters to a relation as is required by draft OWL <-> UML transformations.
Suggest allowing a comma-separated list of roots.
Issue 18572 highlighted that QVT 1.1 seemed to require inconsistent fixed-point semantics. The resolution solved the inconsistency by requiring repeated execution to be external to QVT.
However some transformations such as the TTC PetriNet to StateChart require repeated transforming.
If QVTr supported the TypedModel::uses property then an endogeneous transformation whose input TypedModel uses its output TypedModel makes the repeated execution for fixed-point semantics consistent.
Need to update 7.7/add a fixed-point semantics section.
Need to add TypedModel::uses to the QVTr concrete syntax.
It is unclear how multiple mappings may conspire to populate the children property of a parent. Is the final truth of
parent.children := aChild
parent.children = Collection
{aChild}or parent.children->includes(aChild)
Suggest the latter, since the former can easily be programmed explicitly. This avoids the need to re-interpret a clarifying includes predicate as a partial assignment.
8.4.7 defines a "%" mult_op but no accompanying specification.
The disambiguation comment in 8.4.4 suggests a dual semantic, format half-specified, modulo is presumably Integer/UnlimitedNatural::mod
8.4.4 4 defines
The notation “blabla %s\n” % myvar involving the binary '%' operator is a shortand for invoking the pre-defined 'format' operation.
The inconsistent punctuation and lack of the longhand '"blabla %s\n".format(myvar)' makes for a hard read; which % is the shorthand?
This really does not seem very useful. The textual saving is small, it only works for single argument formats, it introduces precedence challenges once the missing precedence is specified.
(Eclipse QVTo does not implement the shorthand.)
Suggest delete the shorthand.
The "The potential ambiguity with the modulo operator is solved thanks to the type of the first argument, which is a string in our case." text implies that either QVTo or OCL provides a modulo operator. OCL <= 2.4 does not. QVTo's grammar defines '% as a mult_op, perhaps just as the format shorthand, there are certainly no defined semantics such as what data types are applicable, how zero is accommodated.
(Eclipse QVTo does not provide any % operator.)
Suggest, delete the confusing sentence.
ODM 1.0 uses a CollectionTemplate extension in which a collection comprehension is used to match Sequence content:
checkonly domain uml assn : Association{general = superassn : Association{
memberEnd = supSeq : Sequence(Property){usuper | true}},
memberEnd = subSeq : Sequence(Property){uprop | true}}
; // steps through both sequences in tandem
It is not clear how to achieve this without a CollectionTemnplate iterator.
The proposal for a co-iterator could avoid the guard and so allow
checkonly domain uml assn : Association{general = superassn : Association{
memberEnd = supSeq : Sequence(Property){usuper,index | true}},
memberEnd = subSeq : Sequence(Property){uprop,index | true}};
If a CollectIonTemplate is for an OrderedCollection e.g. in
elements = oSet:OrderedSet
{m1, m2 ++ rest}the literal could be ordered requiring m1 first, m2 next etc. But this inhibits the useful use case of iteration over the Collection unless we extend to:
elements = oSet:OrderedSet
{mBefore ++ m1, m2 ++ mAfter}Alternatively if 'Ordered' is just ignored, we create a disordered OrderedSet.
The exception raising syntax is a bit of a mess, cherry-picking special syntaxes and thereby inhibiting general functionality such as raising a computed exception. It is therefore not possible to re-raise an exception.
QVTo has stereotypedBy and stereotypedStrictlyBy helpers and a * shortform to assist in the use of stereotypes, but seemingly only for read purposes.
QVTc and QVTr have no overt support for stereotypes.
Document why it isn't necessary.
QVTo's myClass.stereotypedBy(MyStereotype) invocation is actually just the myClass.extension_MyStereotype <> null predicate. QVTc and QVTr can therefore support stereotypes using normal navigation. And as declarative transformation languages a stereotype navigation in the target domain is a stereotype assignment.
QVTo should support stereotype assignment by:
myClass.extension_MyStereotype := ...
Just need an OclElement.allExtensions() helper to support reasoning on the actual steotypes without knowing which ones to 'poll'.
8.4.4. bullet 6 says both available.
Following bullet 8 it says only one or the other available.
An OCL Variable requires its initializer to be statically type conformant to its type.
A QVTc/QVTd (Guard)Variable defers conformance checking till run-time at which point a non-conformance is a predicate failure.
There is therefore a problem with the WFR inherited from OCL.
Suggest:
VariableDeclaration should be the basis for Variable references.
RealizedVariable should be a VariableDeclaration, not a Variable.
GuardVariable should be a new derivation of VariableDeclaration.
NB VariableDeclaration is the common supertype of Variable and Parameter, although VariableDeclaration is seriously underspecified by OCL.
The introduction to 10 concludes
"and finally, the application of this transformation to the familiar object to relational transformation is shown to demonstrate the results"
But the Section ends without this application. The QVTc variant of UML2RDBMS is not this application in a different place since the QVTc exposition does not follow the multi-unidirectional conversion style of RelToCore.
QVT 1.1 introduced an opposite syntax to support inverse navigation. e.g.
in 7.3 "opposite(Class.attribute)".
This is not needed since the OCL implicit opposite role name supports "Class" when there is no ambiguity, and "Class[attribute]" when an ambiguity needs resolution.
The OCL syntax is shorter and reads forwards, unlike the redundant opposite syntax. Suggest deprecation.
8.4.4 at the end has
use-traditional-comparison-sysntax
where surely
use-traditional-comparison-syntax
was intended.
8.4.7 defines a "!->" access_op but there is no accompanying specifucation.
OCL provides two under-specified semantics for the [] indexing operator
qualifiedAssociationName[qualifierList]
ambiguousAssociationName[oppositeAssociationName]
QVTo introduces additional internally and externally ambiguous semantics without any disambiguation specification.
The following shorthands are missing from 8.4.5
anExpression[aTypeExp]
anExpression[anotherExpression]
!
!->
The ImperativeCallExp::isVirtual attribute is defined as follows: "Unless isVirtual is true, this invocation is virtual." This is extremely counter-intuitive and apparently stems from a careless renaming. As a result, virtual call semantics are disabled by default, because the default value 'true' implies that an operation is "statically called". The default should be virtual call semantics, so the description should be turned around.
An entire Module may be declared as blackbox using the isBlackbox attribute. Whereas it is obvious that a blackbox transformation consists of its signature only (name + model parameters) as it doesn't include any operations, what is a blackbox library? If it doesn't include operations as well, it is useless because it has no effective signature.
If the isBlackbox attribute is useful for transformations only, should it be moved from Module to OperationalTransformation?
The RelToCore transformation that 'defines' QVTr semantics has no semantics for Collections, either explicit through use of CollectionTemplateExp or implicit through use of Collection/non-Collection assignment conversion.
8.4.5 2 states "if a collection value is passed there is an implicit comparison with the size of the collection."
This is clearly not the intent: no Collection can ever equal its size.
Presumably the intent is to treat if (aCollection) as a shorthand for if (aCollection->notEmpty()).
Suggest that all shorthands are spelled out explicitly in longhand.
QVT 1.3 8.1.11.1 attempts to identify the hidden information that a trace record must contain. The text is not suitable for a multiple inheritance where there may be one invoked mapping and many executed mappings.
Probably need to trace all executed mappings.
Need to specify how the inherited mappings merge more clearly; probably as a section-wise merge.
The description of UnlinkExp.target specifies an OclExpression but describes a Property.
Is this an error? Is it introducing a new PropertyLiteralExp?
Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.
Two versions numbers are certainly confusing.
But Isn't the "MOF" redundant too?
The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.
Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.
Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.
This affects all of QVTc, QVTr, and QVTo.
For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?
Does QVTo support operation overloading in a similar way to Java?
How are conflicting contextual operations resolved when access semantics are used for import?
How are conflicting contextual operations resolved when extension semantics are used for import?
Is the resolution at run-time different to that at compile-time?
A late resolve() defers an assignment to such a late time that it cannot be used. Multi-pass transformations must therefore either maintain their own Dict of mappings, or use multiple transformations.
Suggest: Allow a "late" keyword to prefix a block, so that late resolution occurs at the end of the block.
Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.
Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.
Suggest 2: Add a getTraceData() to Status and 'this'.
Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.
NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.
Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.
Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.
It offered a simple textual fix which was exploited to resolve the original issue.
It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.
(B) - (Major rework.) Rework the abstract syntax to reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may
contain sub-statements and OCL expressions; OCL expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
(Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)
Major Problem:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
Further Problems:
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
(3) Several OCL equivalence rules break when ImperativeOCL is present.
Detailed problem description:
(1) The current abstract syntax of ImperativeOCL introduces a couple of
unclear situations. This may lead to incompatible QVT implementations.
In the abstract syntax, ImperativeOCL expressions / statements are
inherited from OclExpression. Therefore, conventional OCL
expressions may (and will) contain sub-expressions that are
actually ImperativeOCL expressions.
In conventional OCL, the interpretation of an expression under a
given environment is a value. In ImperativeOCL, the interpretation
of an expression is a value and a new environment
(state,variables). This extended interpretation is not given for
conventional OCL expressions, leading to undefined operational
semantics of those expressions.
Example: Given the following compute expression:
compute(z:Boolean) {
var x : Boolean := true
var y : Boolean := true
if ((x:=false) and (y:=false))
z := y
}
What is the value of this expression: is it true or false (It
depends on whether the 'and' operator is evaluated short-circuit
or strict). The situation is similar for the evaluation of the
other logical connectives, forAll, and exists when these
expressions contain imperative sub-expressions.
(2) Control flow constructs introduced by ImperativeOCL are redundant
compared with existing conventional OCL constructs.
Some of the new language features in ImperativeOCL such as forEach
and the imperative conditional are not really necessary. Their
effect can already be achieved using conventional OCL expressions:
For example:
company.employees->forEach(c)
has the same effect as
company.employees->iterate(c; r:OclAny=Undefined |
c.salary := c.salary * 1.1
)
and
if ( x < 0 )
else
{ x := 1 } endif is the same as
if x < 0 then x := 0 else x := 1 endif
(3) Several OCL equivalence rules break when ImperativeOCL is present.
In conventional OCL, several equivalence rules well known from
logic hold. Allowing OCL expression to contain imperative
sub-expressions breaks these equivalence rules.
Examples:
let x=e1 in e2 equiv. e2
e1 and e2 equiv. e2 and e1
These equivalences do not necessarily hold if e1 or e2 are allowed
to have side-effects.
Proposed solution:
(A) - (The cheap solution.) State textually that conventional OCL
expressions (as described in the OMG OCL spec.) are not
allowed to have side effects unless used as part of a top
level ImperativeOCL expression. Therefore, even in a system
supporting ImperativeOCL, class invariants, and pre- and
postconditions (e.g.) will not be allowed to contain
ImperativeOCL sub-expressions.
State explicitly that the redundant flow control statements
have been introduced (solely) to write concise imperative
programs and that the side-effect free forms of conditional
evaluation ( 'if-then-else-endif' and 'iterate' ) shall not be
used to program side-effects (instead, the ImperativeOCL forms
shall be used).
(B) - (Major rework.) Rework the abstract syntax to reuse OCL
expressions by composition rather than by inheritance.
Imperative expressions ( => rename to 'statements' ) then may
contain sub-statements and OCL expressions; OCL expressions
are reused unchanged from the OCL spec (no imperative
sub-expressions, no side-effects).
These issues have been discussed on the MoDELS 2008 OCL Workshop,
more details can be found at
http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf
The example transformation creates numerous orphan trace classes.
Surely these should be contained by a trace Package?
This could be produced by a top level RelationalTransformationToTracePackage relation. RelationToTraceClass should then not be top level.
Generation of trace is separate from core, so surely there should be a trace direction for the trace output? The core direction should use the trace direction.
The QVTo Standard Library has no model and consequently no namespace.
This encourages a major confusion:
The QVToLib::Model and QVToLib::Transformation types used in the QVTo Standard Library are at a different meta-level to UML::Model and QVTbase::Transformation. We have the uncomfortable situation that a QVToLib::Model is an instance of a QVTbase::TypedModel and a QVToLib::Transformation is an instance of a QVTbase::Transformation.
As a minimum the distinct namespaces should be identified and modeled.
Possibly QVToLib::Model and QVToLib::Transformation should be renamed. Since they have no namespace they are currently unuseable in code; their sole purpose is for specification of implementation behavior.
The author of Issue 9379 misunderstood the poor description of Pattern::bindsTo and consequently removed the
{composes} qualifier..
There was actually nothing wrong with bindsTo that could not have been fixed by clearer wording to the effect that bindsTo was a dustbin container for variables not contained elsewhere.
The above kind of emphasises the benefits of an ownedPlurals naming policy. Therefore suggest that:
a) the AST bloat from the redundant bindsTo be replaced by definition of a suitable derived property that satisfies the intent of all variables.
b) that variables be renamed ownedVariables and used throughout the QVTr to QVTc transformation
The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance.
For a Package: self.nestingPackage.nestedPackages->includes(self)
For a Class:
self.package.ownedTypes->includes(self)
But self cannot have two containers.
The problem is easily resolved by extending only Package and adding those Class features that are actually required.
QVT Relations and working with stereotypes: Is there something like a QVT-R standard library with methods on stereotypes in it? There is none in the specification; compare QVT-R, there are some methods. Are there some else options for accessing stereotypes with QVT-R?
The specification of "late" semantics uses the "conceptually" word; a sure sign of missing semantics. It is followed by a magic null value that stores information for later use and with an unspecified trace interaction.
The interaction of "late" and implicit collect is not handled so in
generalizations := self.eSuperTypes->collect(t | t.late resolve(UML::Generalization))
the direct association of "late" with asssignment is no longer direct; the "late"s must be aggregated. Potentuially this may occur in arbitrary complexd expressions including mapping calls!
An alternate multi-pass interpretation of "late" is given.
This seems like the correct approach; an MtoM transformation from a with-late to multi-pass without-late transformation.
Problem:
ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified.
However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation:
constructor Column::ColumnConstructor (n:String,t: String)
{ name:=n; type:=t; }object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint.
context ObjectExp
inv : argument->size() > 0 implies body.oclIsUndefined()
Discussion:
This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid.
Proposed solution:
In section 8.2.1.24 add the following subsection:
Constraints
If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa):
context ObjectExp
inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and
not body.oclIsUndefined() implies argument->isEmpty()
In section 8.2.1.24 add the following to the the end notation subsection:
Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body:
object result1 : Column (“name”, “String”);
object result2 : Column (“age”, “Integer”);
Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated).
In section 8.4.7:
Replace:
<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
<expression_block>
By:
<object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator>
(<expression_block> | '(' (<declarator_list>)? ')' )
"The starting point is a major flaw in all three QVT languages at present and enabled Perdita Stevens to correctly conclude in http://www.springerlink.com/content/9x368617317l3q87/ that QVTr and QVTc are incompatible. QVT currently provides no way to distinguish whether for instance a check-mode transformation is a query of whether a transformed input pattern can be discovered in the output (e.g. a database lookup), or a validation that the transformed input exactly matches the output (e.g. an already transformed check). Both facilities are useful and so when a QVT transformation is invoked the invoker needs to specify what I call the 'rooting' condition in addition to the direction
8.1.4 states "a mapping operation is always a refinement of an implicit relation" but 8.2.15 defines "refinedRelation: Relation [0..1] The refined relation, if any." Clearly a contradiction.
8.1.4. provides the REL_PackageToSchema example of how an implicit relation might be defined, but no other examples or synthesis rules are supplied.
enforce and checkonly appear in the REL_PackageToSchema example indicating that these define execution mode of a QVTo trnasformation, but there does not appear to be any description of how a transformation might be executed to for instance update an output model. Perhaps the 'output' parameter is 'inout' for create/update but 'out' for create/overwrite.
The numerous problems identified in http://www.omg.org/archives/qvt-rtf/msg00094.html need to be addressed. Apologies too for the long email. This is a very difficult area where precision is important. Provision of
this resolution demonstrates the need for the resolution, but unfortunately the resolution has an
erroneous precision that will make QVTr 1.1 unimplementable whereas QVTr 1.0 is just mildly
ambiguous and conflicting.
Please do not include the resolution in QVT 1.1 without significantrework.
I found the definition of the "checkonly"/"enforce" to isCheckable/isEnforceable helpful, although
different to three of my own intuitive guesses based on attempts to avoid errors in ModelMorf and
Rel2Core examples.
The problems identified below are the result of a local review of the resolution. In the absence of a
coherent Environment semantics it has not been possible to perform a global review. In particular, I
was unable to review the specification for the arguably redundant bindsTo.
[Incidentally, the same resolution approach is needed for QVTc and QVTo].
Disambiguating rules
--------------------
The resolution uses a similar approach to the OCL 2.0 specification, but neglects to provide any
disambiguating rules although many are needed.
Environments
------------
OCL and the resolution employ environments to carry definitions specific to particular CS constructs,
so that a CS reference may be resolved with the aid of an environment or the AST.
In EssentialOCL, all definitions are resolvable with in the immutable AST with the exception of let and
iterator expressions for which a nestedEnvironment() is used to carry the extra variable declaration
with the aid of addElement(). The nestedEnvironment supports name occlusion from outer scopes.
In CompleteOCL, further definitions may be introduced by a definition constraint. The OCL
specification provides no precise insight into how an environment changes to accommodate the
definition. Should the name be added to the AST or to the environment? Is the name available for
forward reference?
Environment::addElement is defined as a query operation thereby inhibiting side effects. Consequently
usage such as
XX.env = YY.env.addElement(Z.name, Z.ast, false)
leaves the environment of YY unchanged and creates an extended environment for XX.
A series of such usages creates a series of progressively elaborated environments that support
backward but not forward referencing. This was not a clear requirement of the QVT 1.0 specification
and it prevents any variable declarations being introduced in an object template tree being resolved
through environments in other object template trees or predicate expressions.
QVT 1.2 RTF Report Page 173 of 190
Object Management Group
RTF/FTF Report
Imposition of no forward referencing seems very undesirable, particularly since the order of domains is
imposed by the model parameter order. Imagine a Java program in which all methods had to be
defined in a no-forward reference order.
As noted above, CompleteOCL neglected to define how AST definitions were added to the AST. QVTr
must solve this problem since QVTr defines a hierarchically scoped AST rather than an annotation of
a pre-existing AST.
I recommend a two stage approach. The inherited attributes section should first compute an
environment from the pushed-down parent environment augmented by pull-ups from child constructs
so that a complete immutable and consequently unambiguous environment is associated with each
construct and then pushed-down to the children. During the pull-up the environment acquires a
mapping from name to future-AST. During the push-down residual future-AST attributes are populated
to give a valid AST.
Reference resolution
--------------------
OCL uses lookup functions to resolve variable references. It is necessary either to overload the lookup
functions so that the the distinct QVTr variable definition sites can be located in the AST, or to use
some form of Environment::addElement where each definition is defined so that resolution in the
environment is possible.
Details
=======
Throughout, many disambiguating rules are needed to define illegal semantics. For instance "any" is
often used to select a syntactically valid value. Corresponding usage in the OCL specification has a
disambiguating rule to clarify what the consequence of not "one" is.
My current best attempt at Disambiguating Rules is attached.
Environment::addElement takes three arguments, the third being a mayBeImplicit argument. This has
been omitted throughout without explanation.
identifierCS
------------
OCL defines SimpleNameCS. A degenerate mapping from identifierCS to SimplenameCS is required.
topLevelCS
----------
The 'imported transformation' environment element is later referenced as 'imported transformations'.
Typo: TransformationListCS for transformationListCS in Synthesized attributes.
importListCS
------------
Semantics of import conflicts must be defined.
unitCS
------
Typo: ast is not a Set.
Surely the import is of packages (enumerations or operations)or at least transformations (QVTo
implementations) rather than necessarily relational-transformations?
transformationCS
----------------
QVT 1.2 RTF Report Page 174 of 190
Object Management Group
RTF/FTF Report
ownedTag is not synthesized.
keyDeclListCS
-------------
Typo: wrong font in synthesized attributes
modelDeclCS
-----------
The [B] grammar:
modelDeclCS ::= modelIdCS ':' '
'
is missing.
keyDeclCS
---------
Synthesized attributes appear to have experienced a copy and paste error while providing distinct part
and oppositePart left hand sides.
keyPropertyCS
-------------
The synthesized attributes poke the parent.
Suggest: it would be clearer for the parent to gather and distribute children similar to the relation/query
allocation by transformationCS.
relationCS
----------
Transformation.extends does not appear to be transitive.
topQualifierCS
--------------
Suggest: a boolean or enumerated value rather than a string.
domainListCS
------------
Typo: missing indentation.
primitiveTypeDomainCS
---------------------
isCheckable, isEnforceable not synthesized.
objectTemplateCS
----------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
collectionTemplateCS
--------------------
Variable needs to be added to relation to provide a container.
Variable needs to be added to relation environment to provide visibility.
Suggest: last two if guards are redundant.
QVT 1.2 RTF Report Page 175 of 190
Object Management Group
RTF/FTF Report
restCS
------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
memberCS
--------
Variable needs to be added to relation to provide a container.
Non-_ named variable needs to be added to relation environment to provide visibility.
whenCS
------
predicateListCS should be optional.
whereCS
-------
predicateListCS should be optional.
ExtOclExpressionCS
------------------
This is not present in the QVTr or OCL grammar.
Presumably it represents the QVTr extension to OCL's OclExpressionCS.
However it is an extension, since at least RelationCallExpCS can be used in an ordinary
OclExpressionCS using "not" or "and".
[A], [B], [C] should therefore follow on from OCL's
[A], [B], [C]..., [I].
RelationCallExpressionCS
------------------------
How is a RelationCallExpressionCS distinguished from an OperationCallExpCS?
In 7.11.3.6 (and 7.8) the ordering of parameters is implied but not explicit. Presumably the first is the output (enforced direction) so:
package QVTBase
context TypedModel
def: allUsedPackage() : Set(EMOF::Package)
= self.dependsOn.allUsedPackage()>asSet()>union(self.usedPackage)
endpackage
package QVTRelation
context RelationImplementation
inv RootNodeIsBoundToRootVariable : self.inDirectionOf.allUsedPackage()>includes(self.impl.ownedParameter>at(1).type._package)
endpackage
This is not satisfied by almost the last line of RelToCore in 10.3:
enforce domain core me:OclExpression{} implementedby CopyOclExpession(re, me);
which seems to have output second.
-----------------------------------------------------
More significantly CopyOclExpession(re, me) is not meaningful as a black box signature, since it is a static function and EMOF has no way to define static functions. Perhaps it is a query, for which the declaration was omitted from the example. If this is the case, it should be made clear that black box operations must be declared internally as queries and bound externally to static operations of the transformation.
This semantic clumsiness could be resolved, if, within a transformation,
relation, domain or query, self is bound to a transformation instance. Queries would then be normal non-static operations of the transformation (class) and the implementedBy operation call would be a normal implicit call via self of a non-static transformation operation or query. (A RelationCallExp would also deviate less from OCL than it currently does.) This would also allow a transformation to extend a Utility class that provided the required black box operations. Since queries and relations are declarative, it is not obvious that there need be any prohibition on the content of an extended Class; if the Class has properties, these cannot mutate during a query or relation match, so the properties are ok; they might even permit useful behavioural tailoring. For instance an 'inherited' Boolean mangledNames property could influence the mapping of names between input and output.
The RelToCore example can then be mended by declaring that:
RelToCore(...) extends utils::CopyUtilities
and externally binding the utils model name to a package that has a CopyUtilities class with suitable a CopyOclExpession operation.
I’m having trouble with the semantics of DELETE on p. 189 of the QVT Specification (v1.1). It reads in part:
FORALL OBJVAR IN MAKESET(<DOMAIN_K_VARIABLE_SET>) (
AND BELONGSTO(OBJVAR, MAKESET(<DOMAIN_K_VARIABLE_SET>))
I guess I don’t understand MAKESET and BELONGSTO. First of all, <DOMAIN_K_VARIABLE_SET> is already a set, so what’s the MAKESET function do? Second, the FORALL iterates OBJVAR over the results of the same MAKESET that BELONGSTO tests. So how can BELONGSTO be false? That is, I would assume BELONGSTO is defined as follows:
BELONGSTO(e, S) º e ÎS
except that under this definition the expression above is always satisfied.
Any and all help appreciated. Thank you very much.
The whole Concrete Syntax section deserves a much more substantial description.
In particular...
The mechanism by which a package name is located is unresolved, perhaps deliberately,
but the omission should be explicit.
What constraints exist on forward referencing of names?
Transformations and mappings could be ordered so that forward references are avoided,
but large modules benefit from an alphabetical ordering of elements, so requiring
a parser friendly order is not user friendly.
