[specification] Make sense of blackboxes / implementedby

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 462151 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 14, 2015 18:08 EDT | | Modified | Mar 18, 2015 16:44 EDT | | Reporter | Ed Willink |

Description

QVTr nominally supports blackboxes via, as exemplified by the ModelMorf, DNF_bbox.qvtr

relation CopyOfExpr\
{\
    domain expr1 e1:Expr {};

    enforce domain expr2 e2:Expr {} implementedby CopyExpr(e1, e2);\
}

In ModelMorf, this means that there is a DNF_bbox_ext.java hosting a CopyExpr with an additional ModelMorf-specific workspace parameter.

In the QVTr AS, CopyExpr is referenced by an Operation totally discarding the e1/e2 parameters except in that they may have contributed to a signature lookup.

When this maps to QVTc, for which RelToCore constructs an OperationCallExp witgh no source, arguments or types, the operation is magically able to do Creation/Deletion.

The most obvious requirement might be to invoke a Java operation so wouldn't

implementedby 'my.pkge.CopyExpr';

be more sensible. QVTr knows about the outside of the '' string. Inside is implementation-specific.

Or differently sensible while remaining modelled.

enforce domain expr2 e2:Expr {} implementedby e1.CopyExpr();

I don't see the need for deletion. Surely deletion occurs by garbage collection of orphan objects?

But is either useful? a deep copy of e1's descendants is straightforward, but how are e1's references correct to e2 equivalent? Perhaps this is why ModelMorf passes a workspace.

[eclipse-qvtd-bot]

By Ed Willink on Mar 14, 2015 18:33

Or just imposing the solution:

enforce domain expr2 e2:Expr {} implementedby CopyExpr;

means that the generated transformation will be an abstract class with an abstract method

E2 CopyExpr(E1);

for which the user must provide a derived concrete implementation, and within which the transformation API can be exploited.

The above is straightforward for CGed implementation. For interpreted execution we will need to work a bit harder, perhaps using reflection to ensure that it appears the same to the user.

[eclipse-qvtd-bot]

By Ed Willink on Mar 14, 2015 18:49

QVTr syntax changed to simple name following implementedby keyword. This enables us to potentially support something sensible and after a trivial edit to DNF_bbox.qvtr, we can have no errors in the QVTr workspace.

[eclipse-qvtd-bot]

By Ed Willink on Mar 15, 2015 13:42

Simple name definition implementedby pushed to master for M6.

TODO:

• define the API for user provision of the BB
• ?? validate that the compatible BB exists
• support CGed execution of BB
• support interpreted execution of BB