Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMT (Generative Modeling Technologies) » [Announce] A Proposal and Prototype for an Eclipse Model Registry
[Announce] A Proposal and Prototype for an Eclipse Model Registry [message #562616] Mon, 19 February 2007 16:32
Ed Willink is currently offline Ed Willink
Messages: 3844
Registered: July 2009
Senior Member
[Apologies for multiple postings. Please reply to the GMT newsgroup posting.]

Context
-------

A model transformation is declared:

e.g. in QVTrelation

transformation SeqToStm(seqDgm: SeqMM; stm: StmcMM)

the seqDgm model complying with the SeqMM meta-model is transformed to/from the stm model complying with the STmcMM meta-model.

Problem
-------

How are the (models and) meta-models located?

e.g. where is the definition that

SeqMM ==> platform:/resource/QvtrTestFiles/ModelMorfExamples/SeqToStm/ SeqMM.xml

[assuming that there is no entry in the EMF package registry, since SeqMM.xml is a user artefact for which no plugin has been built
and installed as an Ecore model.]

Analysis
--------

The above example happens to be a line from a QVTrelation example from ModelMorf.

I have seen the same problem with ATL, MOFscript and Tefkat, and presume that it exists for all tools that exploit meta-models.

I have seen some rather poor solutions to this problem that are barely adequate for application of transformations and difficult to
generalise across tools.

I am writing a QVTrelation context sensitive editor, and so the editor needs to resolve the meta-models in order to perform
meta-model compliance validation. Use of solutions specific to application of transformations will not suffice. It must be possible
to double click the QVTrelation source to open the editor, and it is not acceptable to modify the source file in order to include
the platform-specific meta-model bindings.

Solution
--------

A user configurable registry of 'model accessor' to 'platform resource' is required, where 'model accessor' can be an informal model
name, such as 'SeqMM' or a URI such as 'http:/my/seq/mm', and platform resource is a simple URI such as
'file:/C:/My/seq/metamodel.xml' or an installed Eclipse resource such as 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore'

The Proposed Eclipse Model Registry (currently available as a prototype from the GMT UMLX Update site
http://download.eclipse.org/technology/gmt/umlx/updates
or CVS at org.eclipse.gmt/umlx/plugins/org.eclipse.gmt.umlx.registry on /cvsroot/technology)
maintains a ModelRegistry model in 'project'/.settings/org.eclipse.gmt.umlx.registry.modelregis try
with per-resource bindings of model accessor to platform resource. Resolution of these bindings is hierarchical, so a binding for a
file, applies only to a file, whereas a binding to a folder applies to all files within the folder and sub-folder, and a binding to
a project applies throughout the project.

Once the Model Registry Nature is added to a project (via the right button menu on a project), resources within the project acquire
Model Registry Property Page (via the Properties selection on the right button menu on the resource). The Model Registry Property
Page provides a GUI for defining the 'model accessor' to 'platform resource' bindings.

The binding also includes a serialisation type, which may be defined to something other than XML to allow non-XML models (e.g. KM3)
to be bound.

Tool support
------------

In order to exploit this registry tools should construct a ModelResourceResolver for the IResource (file) for which resources are to
be resolved, optionally specifying a ResourceSet to be used during resolution.

String metaId = ...; // model for resolution
IResource file = ...; // context for resolution
ResourceSet resourceSet = new ResourceSetImpl(); // or EcoreFamilyResourceSetImpl()
ModelResourceResolver resolver = new ModelResourceResolver(file, resourceSet);
URI uri = resolver.getURI(modelId); // Get platform resource URI or null
Resource resource = resolver.getResource(uri, true); // Same API as ResourceSet.getResource()

EMOF Support
------------

EMF currently allows EMOF models to be used in place of Ecore models, provided the file extension of the EMOF models is distinct and
provided that the EMOFResourceFactoryImpl has been registered for those extensions with the extension to factory map
(resourceSet.getResourceFactoryRegistry().getExtensionToFact oryMap()).

If EcoreFamilyResourceSetImpl is used in place of ResourceSetImpl, the URI of the namespace of the root XML element is examined and
an appropriate content dependent ResourceFactory is used to load the XML file. EMOF and Ecore models can then be used
interchangeably regardless of file extension.

Extension point hooks
---------------------

The model_accessor extension point defines, the kinds of keys for accessing the model registry. By default ModelName and URI keys
are provided. Additional keys may be defined.

The model_content extension point defines the mapping from the URI of the namespace of an XML element to the Resource.Factory that
supports that XML model format. By default Ecore and EMOF are supported. Other XML formats may be defined.

The model_serialisation extension point defines the mapping from non-XML serialisations of a model and the Resource.Factory that
converts that serialisation to/from Ecore. Only the default XML serialisation is supported by default.

Summary
-------

This proposal and prototype is intended to be entirely generic; it has no UMLX-specific functionality.

It is hoped that tools will experiment with it, so that the API can be validated and in due course the prototype migrate to become
part of EMF.

The code was developed using JDK 1.6.0 and Eclipse 3.3M4. It requires at least J2SE1.5, and appears to work on Eclipse 3.2.1. The
Model Registry pages appear to work only for folders and files on Eclipse 3.2.

Comments and Feedback very welcome.

Regards

Ed Willink
Previous Topic:xText Startup Questions
Next Topic:[oaw] metamodel referencing
Goto Forum:
  


Current Time: Fri Apr 18 19:22:32 EDT 2014

Powered by FUDForum. Page generated in 0.01464 seconds