QVT11 — QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles

Issue : QVT 1.0 Section 7,8,9,10 : Navigating non-navigable opposite roles

UML models drawn with Rose allow an opposite role to be defined for a
uni-directional role. This practice is common but haphazard in UML Infrastructure,
EMOF, OCL and QVT specification diagrams.

However EMOF provides only the (run-time) usage of the model and so any
EMOF (or Ecore) model generator must strip non-navigable opposite roles.

QVT matches models at compile-time and matching has no inherent need to
observe navigation constraints. This is amply demonstrated by the Rel2Core
transformation that makes extensive use of, for instance, the inverse Key to Class
relationship.

----------------------------------

Problem: some QVT transformations require names for non-navigable opposite roles,
but those names cannot be present in layered multi-package EMOF meta-models.

The Rel2Core transformation of Section 10.3 cannot be implemented with QVT 1.0.

----------------------------------

Abandoning EMOF (or Ecore) compliance in favour of perhaps CMOF seems unacceptable.

Changing EMOF (or Ecore) to incorporate opposite roles is not possible because
an EMOF specification cannot be extended to include the opposite role of every
meta-model that will ever exist.

Even if it was, there would be a substantial delay until meta-modelling tools
adopted the change and a problem with poor standardisation and global
non-interference of opposite rolenames.

QVT must therefore support definition of non-navigable role names as part of a
transformation. ModelMorf provided a very practical concrete syntax solution,
whereby the reserved operation opposite(qualified-role-name) could be used as
the missing opposite role-name wherever a forward role-name could be used.

An upward compatible abstract syntax requires an additional is-opposite qualifier
for each referred property.

So for

QVTCore::PropertyAssignment add isOpposite:Boolean[0..1] default false.

QVTTemplate::PropertyTemplateItem add isOpposite:Boolean[0..1] default false.

QVTRelation::Key add oppositeParts:Property[0..*]

with the constraint that parts.size() + oppositeParts.size() > 0

Perhaps QVTOperational::Module needs an additional oppositeConfigProperty and
QVTOperational::ContextualProperty needs an additional isOpposite too.

No Data Available