A model type is simply a set of metaclasses. Expressed in Kermeta, this is a collection of Kermeta classes.

package aMetamodel;
// let's define some normal classes 
class C1 {
	attribute name : String
	attribute aC2 : C2#aC1
}
class C2 {
	reference aC1 : C1#aC2
}

// then defining a modeltype is just listing the classes of this modeltype
// here, the model type is composed of two metaclasses, C1 and C2
modeltype MainMT { aMetamodel::C1, aMetamodel::C2}
      	

	Tip
	You can use all classic way to define classes, in kmt, but you can also require an ecore file that will contain your class definition (see require section ???)

Now that you have defined a ModelType, you can use it to declare model variables.

	var aMainMT : MainMT init MainMT.new
      	

But, your model is still empty. As its contents is a (constrained) Set you simply have to fill it with your model element using typechecked operations like add , or using filtered operation like addCompatible and addAllCompatible (with this one you can pass any collection, only compatible objects will be added to the model).

    // create a model element
	var newC1 : aMetamodel::C1 init aMetamodel::C1.new()
	newC1.name := "hello"
	// then add it to the model
	aMainMT.add(newC1)
      	

As a model type is based on "normal" class definitions, loading and saving models mostly relies on the normal way to load resource (see Section 2.12, “ Loading and saving models ” )

A simple approach for loading is to load with the classical approach, then to use the operations addAllCompatible with the content of the resource or resourceToModel with the resource. That will fill the model with compatible objects.

	// load a resource with model elements
	var res : EMFRepository init EMFRepository.new
	var resource : Resource init res.createResource(modelFileName, ecoreMetamodelFileName)
	resource.load()
       	    
	// then add them to the model
	aMainMT.addAllCompatible(resource.contents)
	// alternative
	// aMainMT.resourceToModel(resource)
      	

TODO sample of saving (how to put root objects of the model into a resource)

TODO explain how Modeltype helps to reuse existing code from a metamodel to another

Model types use a notion of conformance that allows to determine if a metamodel is conformant to another. The goal is to be able to write code that will be valid not only for models of a given metamodel, but will be valid for models of conformant metamodels.

In order to be flexible, the conformity between metamodel is based on the properties offered by the metaclasses. It ignores the name of the metaclasses.

As a sample, let's define a mini metamodel and its corresponding model type :

	Note
	We could also define a modeltype directly on top of the previous metamodel (and restrain it to some of its metaclasses), but the sample would have been less general and wouldn't have illustrated the fact that the name of metaclasses are ignored. modeltype MiniMT_2 { aMetamodel::C1 }

	Warning
	The current implementation works only when there is no ambiguity, if there is ambiguity between two metamodels, then they are considered as not conformant. A future version, may eventually introduce a binding mechanism that would allows to remove those ambiguity. (See Jim Steel Phd thesis for more details ???)

TODO

TODO reuse JM slides and the conformity table