Eclipse Community Forums: GMT (Generative Modeling Technologies) » [Announce] A Proposal and Prototype for an Eclipse Model Registry

Home » Archived » GMT (Generative Modeling Technologies) » [Announce] A Proposal and Prototype for an Eclipse Model Registry

Show: Today's Messages :: Show Polls :: Message Navigator

[Announce] A Proposal and Prototype for an Eclipse Model Registry [message #375959]

Mon, 19 February 2007 21:32

Ed Willink

Messages: 7655
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

Report message to a moderator

Re: [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #378456 is a reply to message #375959]

Mon, 09 July 2007 15:21

Dimitris Kolovos

Messages: 2162
Registered: July 2009
Location: York, UK

Senior Member

Hi Ed,

I think such a component would be really useful and I'm looking forward
to integrating it with Epsilon!

However, I've checked out the org.eclipse.gmt.umlx.registry.* plugins
from the CVS only to realize that I also needed the
org.eclipse.gmt.umlx.cst plugin. Checking this out produced even more
error messages as it requires a number of additional UMLX plugins such
as org.eclipse.gmt.umlx.eqvt and org.eclipse.gmt.umlx.qvt.

Are all those dependencies really required (ie. should the registry
plugin really know about the qvt plugin)? Is it possible to define a
core with minimal dependencies that other projects, such as Epsilon, can
reuse?

Cheers,
Dimitrios

Ed Willink wrote:
> [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
>

Report message to a moderator

Re: [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #378845 is a reply to message #378456]

Sat, 04 August 2007 18:24

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Dimitrios
> Hi Ed,
>
> However, I've checked out the org.eclipse.gmt.umlx.registry.* plugins
> from the CVS only to realize that I also needed the
> org.eclipse.gmt.umlx.cst plugin. Checking this out produced even more
> error messages as it requires a number of additional UMLX plugins such
> as org.eclipse.gmt.umlx.eqvt and org.eclipse.gmt.umlx.qvt.
>
> Are all those dependencies really required (ie. should the registry
> plugin really know about the qvt plugin)? Is it possible to define a
> core with minimal dependencies that other projects, such as Epsilon, can
> reuse?

I've just uploaded the Eclipse 3.3-aligned release.
(see http://www.eclipse.org/gmt/umlx/download/index.html or
http://download.eclipse.org/technology/gmt/umlx/updates/).

The confusing dependencies were caused by the support for KM3 that re-used
a number of parsing tools. I've refactored KM3 support so that it is now a
separate UMLX component, the same as the OCL, QVTcore and QVTrelation editors.
The basic Model Registry should now have simple dependencies.

I have just provided openArchitectureWare integration; it was very easy.
You might care to look at the single short class in org.eclipse.gmt.umlx.registry.oaw
for an example of loading many meta-models. Alternatively my posting at
http://www.openarchitectureware.org/forum/viewtopic.php?show topic=4877
may provide an example of more focussed model resolution.

Regards

Ed Willink

Report message to a moderator

Re: [Announce] A Proposal and Prototype for an Eclipse Model Registry [message #378846 is a reply to message #378845]

Mon, 06 August 2007 09:35

Dimitrios Kolovos

Messages: 1776
Registered: July 2009

Senior Member

Hi Ed,

Thanks a lot for the update! I'll look at the oAW integration info asap.

Cheers,
Dimitrios

Ed Willink wrote:
> Hi Dimitrios
>> Hi Ed,
>>
>> However, I've checked out the org.eclipse.gmt.umlx.registry.* plugins
>> from the CVS only to realize that I also needed the
>> org.eclipse.gmt.umlx.cst plugin. Checking this out produced even more
>> error messages as it requires a number of additional UMLX plugins such
>> as org.eclipse.gmt.umlx.eqvt and org.eclipse.gmt.umlx.qvt.
>>
>> Are all those dependencies really required (ie. should the registry
>> plugin really know about the qvt plugin)? Is it possible to define a
>> core with minimal dependencies that other projects, such as Epsilon,
>> can reuse?
>
> I've just uploaded the Eclipse 3.3-aligned release.
> (see http://www.eclipse.org/gmt/umlx/download/index.html or
> http://download.eclipse.org/technology/gmt/umlx/updates/).
>
> The confusing dependencies were caused by the support for KM3 that re-used
> a number of parsing tools. I've refactored KM3 support so that it is now a
> separate UMLX component, the same as the OCL, QVTcore and QVTrelation
> editors.
> The basic Model Registry should now have simple dependencies.
>
> I have just provided openArchitectureWare integration; it was very easy.
> You might care to look at the single short class in
> org.eclipse.gmt.umlx.registry.oaw
> for an example of loading many meta-models. Alternatively my posting at
> http://www.openarchitectureware.org/forum/viewtopic.php?show topic=4877
> may provide an example of more focussed model resolution.
>
> Regards
>
> Ed Willink
>

Report message to a moderator