[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[m2m-dev] Possible migration of UMLX to QVT
|
Hi All
Sorry for the long posting; following off-list discussions to resolve
misunderstandings in the 'QVT models component' thread, there seems to
be a lot to discuss. This posting is solely concerned with relocation,
in principle, of various aspects of UMLX functionality. The important but
very tedious details of names can be discussed once what goes where is agreed.
The GMT/UMLX project (along with all other GMT projects) must shortly move
from 'technology' to 'modeling', so at least one relocation of UMLX functionality
is unavoidable. It would be very convenient for me to avoid a further migration
by migrating UMLX to M2M projects.
UMLX is primarily an enhanced graphical syntax for QVTr. Supporting this goal
has resulted in a significant number of important infrastructure contributions. I
wrote many of these up for the EclipseCon/OMG symposium. References are provided
at the end of this posting.
A list of the various parts of the GMT/UMLX project and their dependencies follows.
-------------------
UMLX Model Registry:
depends on EMF
revision to exploit EMF enhancements in progress
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=104005 )
equivalent functionality should eventually become part of EMF
front end GUI might one day be an EMFT project
UMLX Model Registry oAW integration:
depends on UMLX Model Registry
depends on oAW, which is a nuisance given that nothing else does
Declarative QVT models:
depends on EMF
Declarative EQVT models (Ecore only):
depends on MDT-OCL (and EMF)
Declarative EQVT models (Ecore or EMOF):
depends on EMF, MDT-OCL, QVT models
current dependency on UMLX Model Registry looks removable
may be able to use EMF content types instead
Operational QVT models:
depends on Declarative QVT models
Operational EQVT models (Ecore only):
depends on Declarative EQVT models (Ecore only)
Operational EQVT models (Ecore or EMOF):
depends on Declarative EQVT models (Ecore or EMOF)
OCL edit plugins
(the missing genmodel of the MDT-OCL models)
should be part of MDT-OCL yesterday
https://bugs.eclipse.org/bugs/show_bug.cgi?id=196973
QVT Preference GUI
provides a preference page for file extensions, EMOF/Ecore-based
should be enhanced with a project-specific override property page
Abstract parser support
depends on MDT-OCL (and EMF)
weakly depends on QVT Preference GUI
could perhaps migrate to MDT-OCL one day
Abstract unparser support
depends on MDT-OCL (and EMF)
weakly depends on QVT Preference GUI
could perhaps migrate to MDT-OCL one day
Abstract editor support
depends on EMF
weakly depends on QVT Preference GUI
could perhaps migrate to MDT-OCL one day
KM3, OCL, QVTcore, QVTrelation parser
depends on EQVT models, Abstract parser support
depends on UMLX Model Registry to support model name resolution
KM3, OCL, QVTcore, QVTrelation unparser
depends on EQVT models, Abstract unparser support
KM3, OCL, QVTcore, QVTrelation single-page editors
depends on corresponding parser/unparser, EQVT models, Abstract editor support
revision to exploit TCS editor generation merited
Multi-page editor support
depends on EMF
a useful but far from adequately developed enhancement of MultiPageEditorPart
supports text/graphical/tree/XMI views
KM3, OCL, QVTcore, QVTrelation multi-page editors
depends on single page-editors
depends on multi-page edit support
[Above KM3 functionality should be merged with the ATL TCS-based
KM3 support, and the above OCL functionality should migrate to MDT-OCL
once an EMF/GMF compliant MultiPageEditorPart is available from GMF
or Platform.]
[QVTo counterparts of the above have been developed by Open Canarias
but have not yet been offered as a contribution.]
Multi-page KM3, Ecore Tools integration
depends on KM3 bits and Ecore Tools (and GMF)
UMLX models, diagrams, ....
the ultimate very slowly progressing graphical enhanced QVTr editor
depends on EQVT models and Ecore Tools (and GMF)
JUnit Tests
-------------------------------------------------
Migration of parts to EMF(T) or MDT-OCL is obviously impossible before
Ganymede and a bit difficult thereafter.
Migration to a M2M infrastructure component seems to attract little
enthusiasm.
---
Therefore permanent migration of nearly everything to QVT-Declarative seems to
make most sense (to me). Except:
(E)QVTo models migrate to QVT-Operational.
Model Registry temporarily migrates until subsumed by an ?EMFT project.
oAW dependency excluded; oAW integration support offered to oAW.
org.eclipse.ocl...edit support very temporarily migrates until
https://bugs.eclipse.org/bugs/show_bug.cgi?id=196973 is resolved.
OCL and abstract editor support migrates until subsumed by ?MDT-OCL.
KM3 support migrates but is hidden (no published extension points), its
usage is solely to test the abstract editor for non-OCL languages.
-----
This leaves UMLX itself, the enhanced graphical syntax for QVTr and its
multi-page graphical/text/tree/... editing support.
UMLX is pretty well-aligned with the QVT-Declarative goals and so could
well merit migration to QVT-Declarative one day. Sitting at the top of the
above infrastructure, my progress on the graphics is depressingly slow.
The multi-page editor support is a useful but rather superficial adjustment
of some of the MultiPageEditorPart behaviours. Discussion at EclipseCon revealed
that Platform has many of its own ideas for improving MultiPageEditorPart
but seemingly no commitment. Anyone coming along with improvements seems welcome
but will have to take on board all their other issues too. I don't have time
and probably have insufficient knowledge to do this, so I suspect that a migration
of the multi-page editing to Platform is not possible.
--------------
In summary it would be convenient for me to migrate all of UMLX to
QVT-Declarative, with the exception of the (E)QVTo models which could
migrate to QVT-Operational. Some migrations would be temporary.
Regards
Ed Willink
=============================================================
Background reading
-------------------------------------------------
The "Adapting EMOF/EssentialOCL/QVT to Ecore/MDT-OCL/EQVT" submission by E.D.Willink and A.Sánchez-Barbudo at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/EMOFAdapters.pdf
describes how EMOF elements may realised by Ecore Adapters in a flexible manner that supports extension to OCL and QVT.
-------------------------------------------------
The "The EMOF File Extension" submission by
E.D.Willink at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/EMOFFileExtension.pdf
describes how an enhanced ResourceSet that analyzes XML namespaces may be used to eliminate the impractical requirement for a known
and distinct set of file extensions for EMOF models.
-------------------------------------------------
The "Generation of the QVT and EQVT Models" submission by E.D.Willink at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/EQVTModel.pdf
describes a variant Rose Importer that accurately converts the QVT Rose Model to Ecore and EMOF representations and identifies
residual representational issues.
-------------------------------------------------
The "The (UMLX) Model Registry" submission by
E.D.Willink at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/ModelRegistry.pdf
describes a Model Registry to solve the problem of binding a model reference in the form of an informal model name that might appear
in a QVT transformation declaration to a model representation without requiring installation of a plug-in for that model.
-------------------------------------------------
The "Exploiting MDT OCL for QVT" submission by
E.D.Willink, A.Sánchez-Barbudo and C.W.Damus at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/MDTOCLforQVT.pdf
describes the refactoring of MDT-OCL to support re-use of the EssentialOCL grammar for QVT.
-------------------------------------------------
The "Multi-Page QVT Editors" submission by
E.D.Willink at
http://www.eclipse.org/gmt/umlx/doc/EclipseAndOMG08/QVTEditors.pdf
describes a multi-page editor framework that co-ordinates arbitrary EMOF-based or Ecore-based text/tree/graphics views for Abstract
or Concrete Syntax for EMOF, OCL, QVTc, QVTo, QVTr.
