[
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