The required environment, whatever the underlying operating system, for handling EMF models and being able to run the samples provided in this tutorial includes:

Required plugins can be found by using Eclipse installation tool, through the tool bar menu:Help > Find and install > Search for new features to install > Next buttons

At this stage of the tutorial, the designed meta-model should look like the following meta-model:

Figure 2.7. A simple FSM meta-model

Creating a good meta-model is sometime difficult due to limitations of the used tools. For a better experience in using EMF tools and Kermeta, it is advised to respect the following rules:

Additional documentation on EMF can be found at the following links:

More generally, most of EMF documentation can be found onto the Eclipse website.

EMF tools are not the only way to create Ecore meta-models. Any tool that can manipulate Ecore can do the same. Here is a small list of tools that can be used to create your meta-model:

Figure 2.8. Generate Ecore meta-model from Kermeta

The Ecore import/export function and the Omondo editor can be used in order to graphically display the Kermeta classes of a model. It will act as a basic manual roundtrip editor.

This is the most simple way for creating an instance of a meta-model. Creation is accessible by right-clicking onto the root class/model object of the meta-model (in the scope of the FSM example, it is the Fsm class). Because of the containment property, classes are only available for creation through this root class.

Figure 3.1. Create dynamic instance from an Ecore file

Since it allows to customize the generated editor to match meta-model specificities. (see the end of this article: http://www.eclipse.org/articles/Article-Using%20EMF/using-emf.html), this solution should be favoured for meta-models that are relatively stable.

The following code sample load a previously created FSM model:

operation main() : Void is do 
 // Input fsm
 var fsm1 : fsm::Fsm
 // Create the repository, then the resource
 var repository : EMFRepository init EMFRepository.new
 var resource : EMFResource 
 resource ?= repository.createResource("../models/Fsm_dyn_sample1.xmi", "../metamodels/fsm.ecore")
 resource.load

 // Load the fsm (we get the instance) 
 fsm1 ?= resource.instances.one
 // Check that the fsm was correctly loaded
 fsm1.state.each { s | stdio.writeln("-> "+s.name) }
 fsm1.transition.each { t | stdio.writeln( t.source.name+ " -- " +t.target.name ) }
end

At this stage, it should be interesting to be able to modify a previously loaded model using Kermeta before saving it. The procedure is very simple: do your manipulation as if your loaded FSM model is a Kermeta model (which is, in effect, the case!), and then, simply call a save method on the handling resource. For this purpose, the following code can be added at the end of the main operation defined in the above section:

var newstate : fsm::State init fsm::State.new
newstate.name := "s_new"fsm1.state.add(newstate)
// save fsm1 
resource.save()

It is also possible to save the modified model in a new file instead of overwriting the initial one by using the saveWithNewURI() method. To this end, just replace the last line of above code (resource.save()) by the following one:

resource.saveWithNewURI("../models/modified_dyn_sample1.xmi")

Saving a programmatically generated model requires to use a new specific instruction that addq the created Fsm root class to the destination resource. The following code chunk creates a simple EMF model with 2 states (named “foo”, and “bar”), and 2 transitions. Saving it then consists in adding the root class (i.e. the model object) stored in the variable fsm2 into the resource instances.

var another_resource : EMFResource
another_resource ?= repository.createResource(
       "../models/Fsm_scratch_sample.xmi",
       "../metamodels/fsm.ecore")
var fsm2 : fsm::Fsm init fsm::Fsm.new
var s0 : fsm::State init fsm::State.new
var s1 : fsm::State init fsm::State.new
var t01 : fsm::Transition init fsm::Transition.new
var t11 : fsm::Transition init fsm::Transition.new
s0.name := "foo"
s1.name := "bar"
t01.source := s0
t01.target := s1
t11.source := s1
t11.target := s1
fsm2.state.add(s0)
fsm2.state.add(s1)
fsm2.transition.add(t01)
fsm2.transition.add(t11)
// save the from-scratch model!
another_resource.instances.add(fsm2)
another_resource.save()

This program should return the following FSM model (viewed with the reflexive editor):

Figure 4.1. Fsm_scratch_sample view

The following short code sample provides a comprehensive code template (replace the <words>) for model loading. Note here that the term model object is appropriate (better than root class!): loading a model consists in getting the root class, from which, thanks to the containment property (see section 1.2, p.2), all the contained instances can be accessed.

@mainClass "fsm_package::Main"
@mainOperation "main"
package fsm_package;
require kermeta 
require "<relative_path_of_the_metamodel>" // NOTE : same as param of createResource

using kermeta::persistence
using kermeta::standard
class Main
{
 operation main() : Void is do 
      // Variable for your input EMF model
      var <my_model_object> : <type_of_my_model>
      // Create the repository, then the resource
      var <my_rep> : EMFRepository init EMFRepository.new 
      var <my_resource> : EMFResource 
      <my_resource> ?= repository.createResource(
      "<relative_path_of_my_model_to_load>",
      "<relative_path_of_the_metamodel>")
      <my_resource>.load
      // Load the emf model - get the root class 
      <my_model_object> ?= resource.instances.one
     // You can now browse your model through its attributes/references 
      <my_model_object>.<an_attribute_of_it>.each { o | 
         stdio.writeln("-> "+o.toString) } )
     // Save your model in another file
      <my_resource>.saveWithNewUri("<relative_path_of_a_file_where_to_save_model>")
 end
}