Chapter 5. Meta-model with behaviour and persistency

Kermeta makes it possible to add behaviour to a meta-model. Developers may therefore be interested in loading models that conform to such a meta-model. The following section explains one of the simplest way to achieve this goal. This is a very small variation on the code presented in the previous sections.

At current stage, this is based on Kermeta ability to “require” class definition written in several formats. Currently (version v0.0.16) supported formats are:

  1. kmt files (Kermeta textual syntax);

  2. km files (Kermeta model in XMI 2.0);

  3. Ecore files (Ecore model in XMI 2.0);

  4. emfatic files (Ecore textual syntax developed by IBM).

The transformations Kermeta2Ecore and Ecore2Kermeta enables to obtain two versions of a same meta-model, one in Ecore, the other in Kermeta. From a structural point of view, they will be equivalent and compatible in Kermeta.

Then, these two syntaxes are structurally equivalent.

require "fsm.kmt" // if you use this one, you'll have the FSM behavior

is equivalent to

require "fsm.ecore" // if you use this one, you won't be able to use the FSM behavior

If you have generated the Ecore from a kmt that defines a behaviour, this Ecore will also contain the specified behaviour.

Model loading and saving must be achieved using the Ecore version, so that EMF will know how to serialize/deserialize the models.

var my_resource : EMFResource init repository.createResource( "./my_fsm_usermodel.fsm", "./fsm.ecore")

The Kermeta version of the meta-model will be used to specify the behaviour, the Ecore version will be used by EMF for the persistency aspects.

[Note]Note
Kermeta2Ecore and Ecore2Kermeta transformations are available in the workbench by respectively right-clicking onto a Kermeta or an Ecore file).