Kermeta allows you to add behavior to a metamodel and obviously you'll want to load models conformant to this metamodel.
The following section explain one of the simpliest way to do that. This is a very small variation on the code presented in the previous sections.
Actually, this is based on kermeta ability to “require” class definition written in several formats. Currently supported formats are: (version v0.0.16)
kmt files(kermeta textual syntax)
km files(kermeta model in xmi2.0)
ecore files (ecore model in xmi2.0)
emfatic files (textual syntax for ecore developped by IBM
Using the transformations Kermeta2Ecore and Ecore2Kermeta, you can obtain two versions of a metamodel. One in ecore, in 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
![[Tip]](gfx/admonitions/tip.gif) | Tip |
|---|---|
| If you have generated .the ecore from a kmt that defines a behavior, this ecore will also contain the behavior. |
To load or save a model you will continue to use the ecore version so 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 metamodel will be used to specify the behavior, the ecore version will be used by EMF for the persistency aspects.
![[Note]](gfx/admonitions/note.gif) | Note |
|---|---|
| Kermeta2Ecore and Ecore2Kermeta transformations are available in the workbench (right click on an ecore or a kermeta file) |