Model Registry

Getting Started

Background Problem

All modeling tools that allow models to be re-used by other models have to solve the problem of model name resolution.

The re-using model references the re-used model.

A simple rather inflexible approach requires the re-user to specify full filenames for each re-used model.

Model Name Accessor

A more flexible approach uses an incomplete name, which we call an accessor, to refer to the referenced model.

This allows modelers to use an informal model name accessor such as UML2 or a URI accessor such as http://www.eclipse.org/uml2/2.0.0/UML to refer to the UML 2.0 meta-model.

It is not necessary to know that, on an Eclipse platform, the meta-model may be found at platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore via the EMF Package Registry.

It is equally unnecessary to know that a different resolution may be used on a non-Eclipse platform.

The EMF Package Registry

The EMF Package Registry is a mapping from URI to generated package typically maintained by using genmodel to create a Java model and plug-in from an Ecore model. This 'heavyweight' approach is very powerful and useful when tools are developed that exploit the model programmatically.

The EMF Package Registry is able to resolve URI accessors for heavyweight models.

The EMF Package Registry cannot resolve model name accessors.

The EMF Package Registry cannot resolve lightweight models, which comprise just an Ecore or equivalent model file, but no associated generated Java model and no corresponding plug-in that can be installed to register them in the EMF Package Registry.

Model Registry

The Model Registry solves this by providing:
  • a Property Page in which the modeler can define the binding between a model name accessor and its physical resource
  • a ModelResolver API with which a modeling tool may resolve the model name into the physical resource
  • an accessor_kind extension point to define alternate kinds of model name accessor
  • The Model Registry provides two kinds of model name accessor as standard

  • an informal model name - java.lang.String
  • a URI - java.net.URI
  • The Model Registry functionality is available to any project, but only after the project has specified that it requires it. This specification is performed by adding the Model Registry Nature to the project.

    The Model Registry is maintained as a model compliant with /org.eclipse.gmt.umlx.registry/model/registry.ecore in .settings/org.eclipse.gmt.umlx.registry.modelregistry for each project with a Model Registry Nature.

    The registry is a simple XML file, so users may choose whichever of the Property Page GUI, the basic EMF generated editor, or a text editor is most convenient for updating model registrations.

    The Model Registry therefore provides the flexible registration of lightweight models that meta-modelers require.

    In contrast the EMF Package Registry provides the powerful registration of heavyweight models that toolsmiths require.

    [Registrations in the EMF Package Registry can be exploited by the Browse Package Registry... button in the Model Registry Property Page.]

    Ecore , EMOF and other model languages

    EMF provides primary support for Ecore models.

    EMF provides secondary support for EMOF models, but often only if those models use a *.emof extension.

    The Model Registry provides an enhanced ResourceSet that uses the namespace of the root element of an XML file to determine the model language. Ecore and EMOF models are therefore supported interchangeably regardless of file extension. The model_content extension point allows further XML model formats to be added.

    The Model Registry also allows a non-XML serialization to be specified when a model is registered. The model_serialization extension point may be used to define an XXX to Ecore transformation, so that models in the XXX textual modeling language can be used directly, in exactly the same way as Ecore or EMOF models.

  • JavaDoc Reference