TypedModel Analysis

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 552098 | | Status | NEW | | Importance | P3 normal | | Reported | Oct 15, 2019 04:04 EDT | | Modified | Oct 23, 2019 05:17 EDT | | Depends on | 552252, 552253 | | See also | 549776, 522630 | | Reporter | Ed Willink |

Description

Split off from Bug 549776.

For an arbitrary cascade of relations, the input/output configuration restricts the possible ordering. An actual ordering can be created by solving a cyclic directed grpah in which the nodes are TypedModels (in+out as separate nodes) and the hyperedges are less-than/less-than-or-equal restrictions imposed by a particular selection of relation domains.

For the simple one-in one-out case the graph and solution should be trivial.

For the pathological case a constaint solver might be necessary, but since bad hyperedges get rejected a simpler traversal from consumer to fully satisfued producers may be adequate.

But for now it is sufficient to impose a requirement that the invoker specify a correct ordering of intermediate TypedModels.

The complexity of this analysis can be kicked off into the long grass for a very long time.

[eclipse-qvtd-bot]

By Ed Willink on Oct 18, 2019 10:24

Requiring much more detailed launch configuration is a pain and may be confusing to independent users.

Analoguously to each Relation domain declaring its functionality when selected as an output, each TypedModel could declare its functionality when selected as a target.

Thus for Person2Family.

transformation Persons2FamilyPlans(\ person:PersonsMM,\ family:FamiliesMM,\ plan:FamilyPlansMM ) {

could be elaborated to

transformation Persons2FamilyPlans(\ person:PersonsMM {family,person},\ family:FamiliesMM {family+person,plan,family},\ plan:FamilyPlansMM {} ) {

{family,person}, - 2 stages, family as input then person as output

{family+person,plan,family} - 3 stages, family and person as input, then plan as an intermediate then family as output

{} - 0 stages, an invalid target selection

This eliminates the need for a fancy launch and moves the stage-sequence design to the transformation designer rather than user.

[eclipse-qvtd-bot]

By Ed Willink on Oct 18, 2019 10:29

(In reply to Ed Willink from comment #1)

{family+person,plan,family} - 3 stages, family and person as input, then plan as an intermediate then family as output

This is perhaps the start of a TypedModel level sequencing capability in which a TransformationCallExp might also be used. See Bug 522630.

[eclipse-qvtd-bot]

By Ed Willink on Oct 20, 2019 03:57

The cyclic hazards of same-type mappings are resolved for endogenous transformations by qualifying each type by its TypedModel as a ClassDatum.

We are now struggling with a related cyclic hazard for an update transformation with same type and same TypedModel as input and output. Qualifying each internally as input/intermediate/output in a PositionalClassDatum can solve the problem internally, but surely the real problem is external?

Given a bidirectional update transformation a+b <-> c <-> a+d and a relation a->c how can we deduce whether the relation is a forward or reverse or both contribution? Surely we require the user to specify

aLeft+b <-> c <-> aRight+d

with an aLeft->c or aRight->c contribution?

With distinct in/out TypedModels in QVTs and beyond most of the cyclic hazard problems go away, however it is still possibkle with many intermediates to create a confusing mesh of possibilities, so an ability to configure the TypedModel order is still useful.

But suppose we need a->c to be executed for both aLeft->c and aRight->c how do we avoid having to code a->c twice? See Bug 552252.

[eclipse-qvtd-bot]

By Ed Willink on Oct 20, 2019 04:00

(In reply to Ed Willink from comment #1)

Analoguously to each Relation domain declaring its functionality when selected as an output, each TypedModel could declare its functionality when selected as a target.

Moved to Bug 552253

[eclipse-qvtd-bot]

By Ed Willink on Oct 23, 2019 05:17

(In reply to Ed Willink from comment #3)

Surely we require the user to specify

aLeft+b <-> c <-> aRight+d

with an aLeft->c or aRight->c contribution?

Use "aLeft"/"aRight" rather than "a" avoids confusion wrt ClassDatum TypedModel referencing. But it would be friendlier to allow the user to use just "a". INternal to the code the externally declared "a" TypedModel can be replaced by internally distincrt "a@pre" and "a@post" TypedModels that stay distinct throughout.

We just need to ensure that the early directional QVTr processing can identify whether each "a" is an "a@pre" or "a@post".

Some a@pre is easy since !check+!enforce prohibits a@post.

But given relation r

enforce domain a ...\ enforce domain b ...\ enforce domain c ...

all possibilities are open until we do a global analysis.

But does it make sense? QVTr defines the relations that hold after transformation between input and output models. If an 'updated' model does not have distinct input/output existence we cannot conform that the output state of the model has a correct relationship to the input state. If we auto-identify the "a" model as "a@pre" and "a@post" then the ability to confirm relationships is satisfied. But only kif we know what the realtionship are.

For the triple enforce example above, how do we know whether the relationship applies to the pre/post state of "a"? We don't. Everything applies.

Given a Bug 552253 sequencing such as a+b->a+c we might apply r for both b@pre->a@post+c@post and a@pre+b@pre->c@post which is a bit ugly. Perhaps we rewrite r' as

readonly domain a@pre ...\ readonly domain b@pre ...\ writeonly domain a@post ...\ writeonly domain c@post ...

The duplication of "a" might be able to avoid variable name clashes by recognising that @pre/@post are referring to the 'same' element.

'same' ... Ugh! b@pre->a@post+c@post and a@pre+b@pre->c@post needs no fundamentally new concept.