Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[qvto-dev] Issue 12518 QVT metamodels (was Re: QVT 1.2 RTF Ballot 3 preview 2)

Hi Nicolas

My intention with the new non-normative metamodels is just to make progress; near perfection is too hard.

- we have models defined using UML so that the unnavigable opposites are now modelled
- we have diagrams drawn from the same UML models
- we have some small fixes

In QVT 1.3, I hope that we can turn the tables and make the UML models normative and autogenerate the specification text.

When converting the Ecore files to UML, I was able to exploit the existence of oppositeRoleName EAnnotations so that I only had to add a few missing names. I fixed a problem in UMLUtil (https://bugs.eclipse.org/bugs/show_bug.cgi?id=427167#c3) so that appropriate multiplicities were applied to the unnavigable oposites. For a few unnavigable containments this changed the diagram to 1 rather than 0..1. I used my discretion to variously make the unnavigable containment navigable and keep the 1 multiplicity, or retain unnavigability but change the multiplicity to 0..1. Since containment is likely to be easily navigable in real models, the additional navigability should cost little. I'm not that keen on containment multiplicity 1, since it prohibits reuse; thus QVTc has to change QVTb to allow nested mappings (Rule). However a 1 containment can be more efficient for pattern matching so where re-use is unlikely it is kept .... Compromise. You can see the detail of changes in the org.eclipse.qvt plugin of the QVTd GIT repository.

I thought about adding the redefines relationships such as Constructor.body, but in part ran out of time, in part didn't want to change too much at once. I see the dual Package/Class inheritance as a much more pressing issue for progress.

I don't really understand your subsets issue. Perhaps you are assuming that QVT is aligned with UML 2.5. Currently QVT defines its own EMOF and EssentialOCL models. These are at least inspired by the much simpler UML InfrastructureLibrary::Core::Basic in which Operation::ownedParameter is not a subset of anything. UML Basic is not supported in UML 2.5, so I expect QVT 1.3 to migrate to the OCL 2.5 Pivot model which will have similar subsets-free execution-friendly characteristics to the obsolete UML Basic.

If you can identify specific negative progress in the Issue 12518 diagrams we can try to fix it.

For new concerns that were also a concern for QVT 1.1, please raise new issues.

Nearly all the changes were in Eclipse QVTo/QVTd already. I raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=426969, https://bugs.eclipse.org/bugs/show_bug.cgi?id=426971, https://bugs.eclipse.org/bugs/show_bug.cgi?id=426983 for some fairly trivial discrepancies. I have not yet investigated whether CatchExp::exceptionVariableName is implemented.

    Regards

        Ed Willink


On 04/02/2014 03:53, Rouquette, Nicolas F (313D) wrote:
Ed,

Thanks for the improved metamodels in 12518!

However, this now exposes some deficiencies of the QVT metamodels!

In QVTBase 1, a Transformation (a kind of Package & Class) has composite
associations to TypedModel, Rule (NamedElements) and Tag.
In QVTBase 2, a Pattern (a kind of Element) has a composite association to

a Predicate (a kind of Element)
In QVTTemplate 1, an ObjectTemplateExp (a kind of LiteralExp) has a
composite association to PropertyTemplateItem (a kind of Element).
Š
In QVTO 3, an ImperativeOPeration (a kind of Operation) has composite
associations to VarParameter (a kind of Parameter & OCL Variable).

Because EMOF well-formedness prevents specifying subsets/redefinitions
(see MOF 2.4.1, section 12.4, constraint [9]),
none of the composite properties defined in QVT metaclasses can be
specified to subset/redefine composite properties of their inherited EMOF
metaclass.

What's the point then of saying that a QVT ImperativeOperation is a kind
of Operation since
neither ImperativeOperation::context : VarParameter[0..1] nor
ImperativeOperation::result : VarParameter[*]
are Operation::ownedParameter : Parameter[*] in the EMOF sense?

It seems to me that it would be preferable to specify the QVT metamodel as

CMOF metamodels (including symmetric association end
subsetting/redefinition as appropriate). EMOF QVT metamodels can be
extracted from CMOF QVT metamodels (just ignore the stuff that's outside
the scope of EMOF)
However, with *only* EMOF QVT metamodels, there's not enough information
to generate an implementation.

At least, in the case of the Eclipse QVTO implementation, we'd be missing
the subsets/redefinitions that allows the Eclipse QVTO code to use the
inherited EMF API (as an implantation of EMOF). Surely, this would be a
step backwards. I hope that for the same of generating an implementation
from the spec, we're not going down the road of adding too many smarts in
the code generators that would, somehow, add the functionality equivalent
to the CMOF subsetting/redefinition constraints had we had a genuine CMOF
QVT metamodel.

- Nicolas.


On 2/3/14 11:01 AM, "Ed Willink" <ed@xxxxxxxxxxxxx> wrote:

Hi

Note that voting for Ballot 1 reballot is still open. Please vote.
Note that voting for Ballot 2 is still open. Please vote.

The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars
since Preview 1).

Preview 30-Jan to 5-Feb
Voting 5-Feb to 19-Feb

Most of the working material may be found at
http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to
Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4
server (1.7 seems fine).

I have managed to provide simple resolutions to two previously deferred
issues.

Issue 12518 is substantially updated to include the redrawn Papyrus
diagrams.

The provisional Ecore and UML models and Papyrus diagrams can be found
in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models
     Regards

         Ed Willink




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7056 - Release Date: 02/03/14






Back to the top