QVT13 — QVTr: BlackBox operation signature difficulties

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.

7.11.3.6 (and 7.11.1.1) BlackBox operation signature difficulties

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.

Discussion

Binding self to a Transformation instance may conflict with self as the context in a query. Much safer to bind this; just like QVTo.

Using this as the source of an OperationCallExp of a query eliminates an incompatibility with OCL. But there is no need bloat every RelationCallExp with an extra VariableExp for this.

Any enhancement here needs prototyping.