QVT 1.1 RTF Avatar
  1. OMG Issue

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

  • Key: QVT11-14
  • Legacy Issue Number: 11341
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    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


    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..*]

    { composed }
    and possibly relax the lower bound for
    QVTRelation::Key add parts:Property[0..*] { composed }

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

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

  • Reported: QVT 1.0 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — QVT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT