| Is Ecore fit for EMOF meta-modeling? [message #573366] |
Tue, 06 June 2006 19:04 |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
I have recently encountered some nasty problems when trying to use Ecore as
the underlying technology for QVT and consequently EMOF-based modeling.
The problem is that QVT is based on EMOF and so defined in EMOF and so
at some meta-meta-... level the model must be EMOF.
Ecore is effective as a generator of executable Java models, for which
at some meta-meta-... level the model is Ecore.
Now if QVT is modeled using EMF, it is possible to register QVT as an
Ecore package and to have a consistent model that uses EMOF. However a QVT
transformation applied to a QVT model must be able to access the QVT meta-model,
and that meta-model is Ecore not EMOF, so unless EMF provides an ability to
access (rather than just serialise) a registered Ecore model as EMOF, it is not possible
to traverse the meta-levels of QVT without crossing from EMOF to Ecore and
getting type violations. https://bugs.eclipse.org/bugs/show_bug.cgi?id=145239
We seem to have 2 choices, either every EMOF derived model must acquire a
an E counterpart. We already have (E)OCL, but we will need EQVT etc, etc, etc.
Or we recognise that EMOF-based modeling should be EMOF-based.
The latter means that resolution of the QVT URI must be able to resolve to
qvt.emof.
A closely related problem that I have observed with OMELET, Tefkat, ATL and
MOFScript, is how to convert a meta-model-name into a model-model-content.
The EMF Package registry provides a partial solution, using a URI as a
meta-model-name, but it only works for meta-models
that have been successfuly converted to Java code. This is not possible for
unmodified EMOF models, since nsURI and instanceClassName nulls cause NPEs in
genmodel, and anyway, why is it necessary to generate Java code when none is wanted?
It seems that the EMF Package registry should have two forms of registration:
URI => implementing Java class, genModel file name
URI => emofModel file name
so that the latter can be consistently used for EMOF-based meta-modelling, and the former
for Java-based executables. The emofModel could be auto-generated by genModel for Java-based
models.
We just need an ability to register emofModels in plugin.xml. To avoid the
inconvenience of starting up nested Eclipse sessions, we need a registered package
browser that supports maintenance and loading of perhaps a .metamodels file per
project.
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.02715 seconds
] 
Search
Help
Register
Login
Home
