Kermeta language

Even if it is not very useful in our context, since it doesn't show the really interresting structures of the language, here is the traditional " Hello world " example you can find in every programming book.

package helloworld;

using kermeta::standard             // shorthand for standard types
using kermeta::io::StdIO => stdio   // shorthand to kermeta::io::StdIO

class HelloworldExample
{
    operation sayHello() is
    do
        stdio.writeln("Hello world, ...")
    end
}

KermetaProject "hello"
	groupId = "my.group"
	defaultMainClass = "helloworld::HelloworldExample"
	defaultMainOperation = "sayHello"
	sources = {
		require "${project.baseUri}/src/main/kmt/MainClass.kmt"
	}
	dependencies = {
		//default dependency to kermeta framework (try first in eclipse plugin, then look into maven repository)
		dependency "library.core" ="platform:/plugin/org.kermeta.language.library.core",
		                           "mvn:org.kermeta.language/language.library.core/2.0.4"
	}

Kermeta language includes usual statements like blocks and loops, comments, etc

do
    // a loop for getting a text from an user
    var s : kermeta::standard::String
    from var found : kermeta::standard::Boolean init false
    until found
    loop
        s := stdio.read("Enter a text:\n --> ")
        if s.size > 0 then
            found := true
        else
            stdio.writeln("ERROR - Empty text!")
        end
    end
    stdio.writeln("\n You entered: " + s)
end

All these "classic" imperative features and their syntaxes are described in Chapter 2, Reference . More precisely in

You can get more informations about Kermeta object-oriented features in Chapter 2, Reference . More precisely in

Association is one of the key concepts when using and defining models. It is obviously part of Kermeta.

MOF defines the concept of "Property" which generalizes the notions of attributes, and associations (composite or not) that you can find in UML. Kermeta syntax also distinguishes these two notions as introduced in Section 2.16, “ Class properties ” .

As a reminder, the attribute keyword defines a link with containment (a composite association) whereas the reference keyword just defines an association. As you can see, property declarations are very close to variable declarations introduced in Section 2.6, “ Using Variables ” ). Each reference may be explicitly linked to another reference (it is the opposite concept in MOF terminology – see also section Section 2.16.1, “ Attributes (attribute) , references (reference) ” ).

class Library
{
    attribute books : set Book[0..*]
}

class Book
{
    attribute title : String
    attribute subtitle : String

    reference authors : oset Author[1..*]#works
}


class Author
{
    attribute name : String
    attribute lastName : String
    
    reference works : set Book[0..*]#authors
}

If we represent our Kermeta model in a graphical syntax we obtain the following class diagram ( Figure 1.2, “A concrete example : a library” ).

Figure 1.2. A concrete example : a library

Using Eclipse Modeling Framework (EMF), Kermeta can load and save models done with other EMF tools.

/* Initialize the EMF repository */
var repository : EMFRepository init EMFRepository.new

/* Create an EMF Resource, given model and metamodel URIs as String */
var resource : Resource init repository.createResource(myModelURI, itsMetamodelURI)

/* Load the resource */
resource.load

// get elements from the resource
// in this sample, you know that your root element is always a Library, 
// so you can directly get the first one
var aLibrary : Library
aLibrary ?= resource.one // note the conditional assignment using the ?=, if not a Library you'll get Void

In the same way, you can serialize a model, or load, change and save an existing model.

	Caution
	Your model URI MUST be of the form "platform:/resource/myProject/myModel" or "platform:/plugin/myProject/myModel". Your metamodel URI MUST be of the form "platform:/resource/myProject/myModel" or "platform:/plugin/myProject/myModel" or an URI registered in the EMF registry.

	Caution
	Be aware that you CANNOT load kermeta text files (*.kmt). Only xmi files are allowed to be loaded. Parsing and obtaining a model from a textual syntax is not part of Kermeta. This is the role of other tools (like sintaks). Technically, it is possible to create some Kermeta operation that will hide this step, however, this is not the goal of this manual to explain this procedure.

Actually, navigating in a model is as simple as using objects in an object-oriented program. However, several features have been added in order to ease this activity.

For example, thanks to the lambda expressions, the collections of the language are easily manipulated using lexical closure (select, collect, each, etc). This applies to all the collections of the language, the one you may define directly but also the one which are used when an Attribute or Reference has a multiplicity greater than 1.

Example (based on the library sample of Section 1.4.1, “Associations : toward a first concrete example of a Kermeta model ” ):

var smithBooks : Set<Book> init Set<Book>.new
smithBooks.addAll(
	lib.books.select{aLibraryBook | 
		aLibraryBook.authors.exists{aBookAuthor | aBookAuthor.lastName == "Smith"}})
		

In the example above, lib is an instance of Library. It searchs in the books, select the books where the author last name is "Smith".

In order to improve reuse of existing code between metamodel variants, the language introduces the notion of ModelType. It is based on the notion of conformance between two metamodels. This allows to write behavior that is valid for a given metamodel and that will also work for any conformant metamodel.

TODO write a small illustrative example of a simple printer based on a ModelType : a subset of class diagram of UML

Kermeta has been developed, using MDE principles so it also provides its own metamodel (reflectiveley available). Details of Kermeta metamodel is available in Chapter 3, Kermeta Metamodel

You can get more informations about all Kermeta model-oriented features in the Chapter 2, Reference . More precisely in

One of the key feature of the workbench is the static composition operator require . This operator allows defining these various aspects in separate units and integrating them automatically into the meta-model. The composition is done statically and the composed model is typed-checked to ensure the safe integration of all units. This mechanism makes it easy to reuse existing meta-models or to split meta-models into reusable pieces. It allows to compose the various files and models that will form the final tool.

The workbench will seamlessly convert and merge the various files into the final kermeta program. The classic inputs will be ecore files, kmt files or uml profiles files. The finala assembly will depend on the capabilities of the inputs models. For example, a ecore model has a granularity at the class level (ie. it will just add new classes) whereas Kermeta has a granularity at the feature level and thus can add new features to a class(see next section Section 1.5.2, “ Model element static introduction : Aspect-oriented language ” for more details)

TODO add a sample

	Text not verified for kermeta 2

One of the key features of Kermeta is the static composition operator require allows extending an existing meta-model with new elements such as properties, operations, constraints or classes. This operator allows defining these various aspects in separate units and integrating them automatically into the meta-model. The composition is done statically and the composed model is typed-checked to ensure the safe integration of all units. This mechanism makes it easy to reuse existing meta-models or to split meta-models into reusable pieces. It can be compared to the open class paradigm. Consequently a meta-class that identifies a domain concept can be extended without editing the meta-model directly. Open classes in Kermeta are used to organize cross-cutting concerns separately from the meta-model to which they belong, a key feature of aspect-oriented programming. With this mechanism, Kermeta can support the addition of new meta-class, new subclasses, new methods, new properties, new contracts to existing meta-model. The require mechanism also provides flexibility. For example, several operational semantics could be defined in separate units for a single meta-model and then alternatively composed depending on particular needs. This is the case for instance in the UML meta-model when several semantics variation points are defined.

Thank to this composition operator, Kermeta can remain a kernel platform to safely integrate all the concerns around a meta-model. This feature has proved to be extremly useful in the context of metamodel engineering.

In order to implement and statically type check OCL-like iterators, Kermeta includes some limited functional features by implementing lambda expressions.

This is typically used on Collection which provides operations that uses a function as parameter. For example : each , select , forAll , detect ...

Example 1 : the following code will build a collection of names of the operations that start with "test".

var names : Collection<String>
names := self.getMetaClass.classDefinition.ownedOperation
            .select{ op | op.name.indexOf("test") == 0}
            .collect{ op | op.name }
	    

Example 2 : Providing a time function on Integer

operation times(body : <Integer->Object>) : Void is do
    from var i : Integer init 0
    until i == self
    loop
        body(i)
        i := i + 1
    end
end

this allows to write code like :

var res : Integer
10.times { i | stdio.writeln(i.toString + ": Hello") } // Say 10 times Hello

See sections " Lambda Expressions and functions " and Lambda Expression for detailed informations.

Like in many languages, Kermeta provides two ways to add comments in your models:

Kermeta provides a way to define named and unnamed annotations, that have to be defined just above any model element among Package , ClassDefinition , Property , Operation . Such annotations correspond to MOF tags, and are linked to the elements which immediately follows.

To define a named annotation, you have to use a special symbol "@", whereas an anonymous annotation has to be written between /** and */

Example 1: you can define an annotation to describe the role of a property

@usage "count the number of ..."
reference myCounter : Integer 

Example 2 : you can document your classes and operation using /** ... */

/** * This is a documentation tag for the class "myClass" */
class MyClass {
    /** This is a documentation tag for myOperation */
    operation myOperation() is do
        // Unlinked comment
    end
    @desc "This is a named annotation for thisOperation"
    operation thisOperation() is do
        /* This is an unlinked comment */
    end
}

Kermeta provides a block notion to manage scope of variable. Instruction of the block have to be inserted between do and end keywords. Theses two keywords may be omitted for the conditional and for the loop structures.

A variable could only be accessed in the block where it was defined and in its sub blocks:

do
    var v1 : Integer init 3
    var v2 : Integer init 2
    do
        var v3 : Integer
        v3 := v1 + v2

        var v2 : Integer // error : v2 is already declared in the upper block
    end
    var v4 : Integer init v3 // error : v3 is unknown here
end

Kermeta's conditional statement is composed of at least two elements : a boolean expression and a block that is executed if the boolean is evaluated to true . You can add a third element, with the else keyword, that is executed if the boolean expression is evaluated to false .

Example 1 : if..then..else block

var v1 : Integer init 2
var v2 : String init "blah"

if v1 > 5 then v1 := v1-5

if v1 == 2 then
    v2 := v1
    v1 := v2 + v1
else
    v1 := 0
end

The if statement is an expression (see Chapter 3, Kermeta Metamodel ). As any expression in Kermeta, it can return a value. The return type of the if statement must be a super type of the values "returned" by both then and else blocks (otherwise the type checker will send an error). The values considered as the result of the evaluation (the "returned" values) of the if statement are the last evaluated statement inside then or else block

Example 2 : conditional is an expression

var s : String
    s := if false then "a" else "b" end

Example 3: a more complex conditional

var x : String
    var y : Integer init 5 
    x := if y < 3 then 
         stdio.writeln("hello")
         "a" 
         else 
         "b"
         "c" 
         end // The String "c" will be the value of x

Here is a sample of a typical loop in Kermeta.

var v1 : Integer init 3
var v2 : Integer init 6

from var i : Integer init 0
until i == 10
loop
    i := i + 1
end

	Note
	Unlike Java, there is no exit, break or continue function in Kermeta.

See Section 2.15, “ Collections ” for functions offering iterator-like scanning.

When you need to refer explicitly another entity defined in another file, you have to use the require primitive. It allows loading definitions of an other Kermeta file when file is processed. In the following example, we define a class C which inherits from the A class previously defined.

// file : MyPackage-part1.kmt
package subPackage1;

class A 
{
  // ...
}

// file : MyPackage-part2.kmt
package MyPackage;
require "MyPackage-part1.kmt"

class C inherits subPackage1::A 
{
	// ...
}

	Note
	In most case, the order of the declaration in not important. The only exception is a very rare situation related to aspects (see Section 2.22, “ Weaving Kermeta code ” ).

	Note
	You can create cyclic dependencies of files, the environment will deal with that.

You can require different kind of entity

Obvioulsy, you can require Kermeta textual syntax, ie. *.kmt files

You can require Kermeta models, ie. *.km files .

You can require Ecore models, ie. *.ecore files . These models can then be used as if they were written in Kermeta. In order to add behavior to the classes defined in .ecore files you may : use the weaving to dynamically weave behavior to the ecore, or roundtrip using the button action in the workbench (ecore->kmt->ecore) to statically add the behavior (as EAnnotations) into the ecore file.

Warning

A special attention must be put when requiring resources. It is not allowed to get several versions of the same class that comes from several required files. Kermeta cannot know which version it must use, so you'll get an error. A typical error, is to require both an ecore file and the registered version of it. They represent two distinct resources in memory. A more clever error, is when the two versions are hidden inside an erroneous ecore file which uses several ways to access some metaclass and actually is not consistent. (ex: you find references to both http://www.eclipse.org/emf/2002/Ecore and platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore in the ecore file or one of the dependent files)

In order to use the seamless java import (still prototype in v0.4.2), you can require a jar file . It will automatically convert the java into a Kermeta representation in order to be able to call java code as if it was written in Kermeta. see Section 2.24, “Using existing java code in Kermeta ” for more details.

Kermeta reuse some of the protocols provided by Eclipse.

Relative path.  You can use a path relative to the current file using the normal syntax (./ , ../, etc)

Eclipse workspace relative path.  In Eclipse, you can use a path relative to the user's workspace. In that case the path looks like platform:/resource/ your_project_name / path_to_the_file

Eclipse plugin relative path.  In Eclipse, you can use a path that search in the installed plugins. In that case the path looks like platform:/plugin/ plugin_name / path_to_the_file

Eclipse workspace or plugin relative path.  When deploying Kermeta code, it is sometime interesting to search in both the user's workspace and in the plugins. In that case the path looks like platform:/lookup/ plugin_or_project_name / path_to_the_file

	Note
	This platform:/lookup/ is available in Kermeta only, and only in the require statement. Be careful, using the current version (Kermeta 1.3.1) since a deployed plugin using this protocol may be modified by the user's workspace content!

Registered Ecore.  A variant of requiring an ecore file is to require a registered EPackage . When Eclipse deploys an ecore model plugin, it also registers the EPackage using a unique identifier (nsuri) in order to retreive it quickly. In Kermeta you can also use this nsuri into the require statement. This approach is useful because you can be sure that you require the very same model as Eclipse use to load and save models of that sort. For example, instead of requiring ecore.ecore you may use require "http://www.eclipse.org/emf/2002/Ecore" . This also works for all other registered metamodels (Your own registered metamodel, UML metamodel, etc). Kermeta user interface provides a view that display all registered EPackages and their nsuri.

Kermeta lets you organise your code the way you prefer. There is no predefined organisation of your code, but the language and the workbench proposes various mechanisms and tools to structure it according to your needs and the style you wish for your code. Typically if you use Kermeta internal weaver (see Section 2.22, “ Weaving Kermeta code ” ), manually transform your ecore into Kermeta, eventually weaving the ecore using the merge button available on the worbench.

For example, you can put all your classes into a single file (like in Ecore, every classes is in the .ecore file) or you may create a file for each of them and then use the require to indicates that they must know each other. You can also use an organisation like java, with a file per class and a directory per package.

Kermeta implements a few primitive types. By primitive types, we mean types that are basic to any language, i.e integer, and that have a literal value. See below table.

// Simple datatypes examples
var myVar1 : Integer init 10
var myVar2 : Integer
var myVar4 : String init "a new string value"
var myVar5 : boolean

Kermeta also supports some other primitive types like Float and Character, but they currently don't have a surface syntax for their literals. The way to get them is to use the convertion methods available on String (for both of them) or Integer (for Float).

For example:

var c : Character init "f".elementAt(0)
var r : Real init "4.5".toReal

You can define enumerations using the following syntax. Note that each enumeration literal must end with a ";".

enumeration Size { small; normal; big; huge; } 

You can manipulate enumerated variables and literals with classical operators such as in the following example.

var mySize : Size
if ( mySize == Size.small ) then 
    stdio.writeln("This is small !") 
end

	Note
	Enumeration is a concept of the same level as Class, they must both be defined in a package.

In Kermeta, you can define your own datatype based on existing types without a hard dependency like inheritance.

This is done using the alias syntax.

Ex:

alias MyString : kermeta::standard::String;

In this sample, MyString has all the behavior of kermeta::standard::String but is declared locally. This means that you don't have any dependency to the framework, even to the String in the framework.

Obviously you can reuse existing type names :

alias String : kermeta::standard::String;

This will create a new type String in your package with the behavior of String in the framework.

The definition of an alias is different from the use of "using" statement (as defined in Section 2.14, “ using keyword syntactic sugar ” ), when you write

using kermeta::standard

you simply defined a syntactical shortcut allowing you to access any definition in this package from within this file.

Wheras defining an alias allows you to access this new definition from another package if needed.

	Tip
	It is interesting to redefine your own datatype for all the standard type you use in your metamodel, so when you convert the file into ecore in order to have serialisation, you won't have any dependency to framework.ecore (which is the ecore version of the framework where Kermeta standard type) This allow a lazy coupling of the type definitions.

As introduced in the "Hello world" example (see Section 1.2.1, “ First Program ” ), Kermeta is an object-oriented language. Kermeta provides all MOF concepts like properties, attributes, package. In addition, it provides a body to operations and derived properties.

Classes and abstract classes can be defined in a Java-like way. Class definition must be placed into brackets as it is in the following example.

// an empty simple class
class myFirstClass 
{

}

// a simple abstract class
abstract class MyAbstractClass
{

}

Additionally, for better code robustness, and more user-friendly programming, classes can use the genericity mechanisms (see Section 2.10, “ Genericity ” for more information).

// This is a parametric class
class A<G> {
}

// This is the type variable binding : G is binded with Integer
var a : A<Integer>
a := A<Integer>.new

There are some limitations in regards to Java. For example, you cannot define nested classes in Kermeta. Kermeta offers the same structural concepts than MOF language.

Kermeta provides a way to add operational (action) semantics to your metamodels. For that, you can define operations with their body, as in a classical programming language. You can also specify abstract operations (they have no body). Kermeta requires that every class that contains an abstract operation must be declared as an abstract class.

In the following example, we define some operations, based on a visitor pattern implementation

class Inventory 
{
    operation visitLibrary(l : Library) is
    do
        writeln("Inventory : ");
        l.books.each(b : Book | b.accept(self))
        writeln("----")
    end

    operation visitBook(b : Book) is
    do
        stdio.write("Book : ", b.title, " by ")
        b.authors.each(a : Author | a.accept(self))
    end

    operation visitAuthor(a : Author) is 
    do
        stdio.write(a.name, " ", a.lastName)
    end
}

class Library {
    // ...
    operation accept(visitor : Inventory) is
    do
        visitor.visitLibrary(self)
    end
}

class Book
{
    // ...
    operation accept(visitor : Inventory) is
    do
        visitor.visitBook(self)
    end
}

class Author
{
    // ...
    operation accept(visitor : Inventory) is
    do
        visitor.visitAuthor(self)
    end
}

In this small example we define an Inventory class which can go over the library structure and print books informations. For that, we apply the visitor GoF pattern's on the library structure defining an accept method in every library structures.

2.8.2.1. Result

The special variable result is used to store the value that will be returned by the operation.

operation getName() : String is
    do
        result := self.name
    end

	Note
	This is different of the return in java, since it doesn't end the block. Other instructions can be used after the result assignment.

class A{
    operation main0() is do
        // do something
    end
    operation main1( arg1 : String) is do
        // do something with 1rst argument
    end
    operation main3( arg1 : String, arg2 : String) is do
        // do something with 1st and 2nd arguments
    end
}
// If you ask to launch main0, Kermeta interpereter will create an instance of A and will run main0 on it.

Kermeta doesn't use constructors.

However in some situation, you may need to provide some initialization operation. The best approach is simply to declare an operation which will return self after having done the initialization work.

class A
{
	attribute name : String
	operation initialize(name : String) : A is do
		self.name := name
	end
}        
        

// now you can use it easily in one line
	var aA : A init A.new.initialize("hello")
        

Here are some explanation about some design choice of Kermeta classes.

aspect class ClassFromMyEcore {
	 
	operation init(myParam : String) : ClassFromMyEcore is do
		// assign myParam to some attribute 
		self.name := myParam
		// return self for easier use
		result := self
	end
	// now you can create and initialize this class in one line
	// var foo : ClassFromMyEcore init ClassFromMyEcore.new.init("foo")	
}
          

abstract class Person
{
    attribute name : string
    attribute lastName : string

    reference father : Male#children 
    reference mother : Female#children
}

class Male inherits Person
{
    reference children : oset Person[0..*]#father
    reference wife : Female[0..1]#husband
}

class Female inherits Person
{
    reference children : oset Person[0..*]#mother
    reference husband : Male[0..1]#wife
}

In this example, we define a simple model which represent simples family trees. Here, persons are defined by their name and last name. Each person have a father and mother and respectively might have children. The figure representing this example is Figure 2.1, “A simple family tree model”

Figure 2.1. A simple family tree model

As Kermeta is strongly typed, you cannot assign or pass something of the wrong type.

For example :

class A {
}
class SubA inherits A {
}
class AnotherSubA inherits A {
}

// ...
	var aA    : A init SubA.new
	var aSubA : SubA
	aSubA := aA  // doesn't work because not type safe
        

In this situation you must use one of the following methods : conditional assignment or asType

	aSubA ?= aA  // works
	var aAnotherSubA : AnotherSubA
	aAnotherSubA ?= aA  // works too, but has been assigned Void and not the value 
        	

class B {
}
// ...	
	var aB : B
	aB ?= aA  // doesn't work because not type safe
        	

class C {
	operation needASubA(sa : SubA) : Void	is do
		// do something
	end
}
	// ... typical code using ?= 
	var aC : C init C.new	
	aC.needASubA(aA.asType(SubA))
        	

class Parent
{
     reference children : oset Child[0..*]#parent
}

class Child
{
     reference parent : Parent#children

}

class Male { }

class GrandFather inherits Parent, Male
{
     boolean healthy : Boolean
}

The above example defines a class "GrandFather" that inherits at the same time the class "Parent", and the class "Male". Its graphical representation is shown in below figure.

Figure 2.2. : multiple inheritance

In the following sample, when an operation is declared for the first time (in the parent class Person), it uses the operation keyword. Then, whenever you override it, you will have to use the method keyword.

	Note
	In the sample,Person and adopt are abstract, but this has no influence on the operation-method keywords rule, it would have been the same even if Person was not abstract or if adopt had a behavior in this class.

abstract class Person
{
    attribute name : String
    reference father : Male#children 
    reference mother : Female#children
    operation adopt(child : Person) is abstract}

class Male inherits Person 
{
    reference wife : Female#husband
    reference children : oset Person[0..*]#father    method adopt(child : Person) is    do        children.add(child)
        if not wife.children.contains(child) then            child.father := self            wife.adopt(child)
        end    end}

class Female inherits Person
{
    reference husband : Male#wife
    reference children : oset Person[0..*]#mother    method adopt(child : Person) is    do        children.add(child)
        if not husband.children.contains(child) then            child.mother := self
            husband.adopt(child)
        end    end}

A MOF class can have operations but MOF does not provide any way to describe the behavior of these operations. Furthermore MOF does not provide any semantics neither for operation call nor for operation inheritance and redefinition. This section investigates how, while weaving actions into MOF, MOF semantics can be extended to support behavior definition and extension mechanisms provided by the action language. This implies answering several questions concerning redefinition and dispatch.

2.9.5.1. Operation redefinition

MOF does not specify the notion of overriding an operation because from a structural point of view it does not make any sense. To stick to MOF structure one can argue that redefinition should be forbidden in an executable MOF. This is the simplest solution as it also solves the problem of the dynamic dispatch since a simple static binding policy can be used.

However, operation redefinition is one of the key features of Object-Oriented (OO) languages. The OO paradigm has demonstrated that operation redefinition is a useful and powerful mechanism to define the behavior of objects and allow for variability. This would be very convenient to properly model dynamic semantic variation points existing in e.g. UML state-charts. For this reason we believe that an important feature of an executable MOF is to provide a precise behavior redefinition mechanism. The choice of the operation overriding mechanism must take into account the usual problem of redefinition such as method specialization and conflicting redefinitions related to multiple inheritance.

class A {     operation m1() is do         // Some behavior     end     // operation m2 is abstract     operation m2() is abstract } class B inherits A {         // method m1 inherits operation m1 from A     method m1() is do         // Behavior redefinition     end     method m2() is do // Implementation of the abstract method     end }

Table 2.1. Operation redefinition in Kermeta

	Note
	Notice in that sample that method redefinition uses the method keyword instead of operation.

class A
{
    method m(i : Integer) is do
        // [...]
    end 
    method m(s : String) is do // this is not allowed in Kermeta !!!
        // [...]
    end
}

2.9.5.4. Conflicts related to multiple inheritance

This is also a classical problem that has been solved in several OO languages. There are mainly two kinds of conflicts when a class inherits features from several super-classes:

• Several features with the same name might be inherited from different super classes causing a name clash.

• Several implementations of a single operation could be inherited from different super classes.

There are two kinds of solutions to resolve these conflicts. The first one is to have an implicit resolution mechanism which chooses the method to inherit according to an arbitrary policy. The second one is to include in the language constructions that allow the programmer to explicitly resolve conflicts. In Eiffel, for instance, the programmer can rename features in order to avoid name clashes and can select the method to inherit if several redefinition of an operation are inherited from parent classes.

In the current version of Kermeta, we have chosen to include a minimal selection mechanism that allows the user to explicitly select the inherited method to override if several implementations of an operation are inherited. This mechanism does not allow resolving some name clashes and thus reject some ambiguous programs. For the future version of Kermeta we plan to include a more general mechanism such as traits proposed by Schärli et al. In any case we believe the conflict resolution mechanism should be explicit for the programmer.

class O {     operation m() is abstract } class A inherits O {     method m() is do         // [...]     end } class B inherits O {     method m() is do         // [...]     end } class C inherits A, B { // "from" : an explicit selection of the//implementation to inherit     method m() from A is do         // [...]     end }

Table 2.2. Explicit selection of super operation in Kermeta

In Kermeta classes can have a set of type parameters. These type variables can be used in the implementation of the class as any other type. By default a type variable can take as value any type; but a type variable can also be constrained by a type: in that case, this type variable can only be substituted by a sub-type of this type. The following code demonstrates how to create generic classes.

// A class with a type variable G that can be bound with any type

class Queue<G>
{
     reference elements : oset G[*]

     operation enqueue(e : G) : Void is do 
         elements.add(e)
     end
     
     operation dequeue() : G is do
         result := elements.first
         elements.removeAt(0)
     end
}

// A class with a type variable C that can be bound with any sub-type of Comparable

class SortedQueue<C : Comparable> inherits Queue<C> 
{
     method enqueue(e : C) : Void is do
         var i : Integer
         from i := 0
         until i == elements.size or e > elements.elementAt(i)
         loop
             i := i + 1
         end
         elements.addAt(i, e)
     end
}

Kermeta operations can contain type parameters. Like type variables for classes these type parameters can be constrained by a super type. However, unlike for classes, for which the bindings to these type parameters are explicit, for operations the actual type to bind to the variable is statically inferred for each call according to the type of the actual parameters.

class Utils {
    operation max<T : Comparable>(a : T, b : T) : T is do
        result := if a > b then a else b end
    end
}

	Note
	Notice in that sample that even the "if" is an expression that can return a value that is assigned here to the special variable "result".

Actually, all types can be used as a parameter of a generic class or generic operation. More, the ModelType, is really useful when combined with generics. see Section 2.23, “Model type”

The user will refer to Eclipse documentation for the creation of an EMF model from its ECore meta-model. We suggest to use the Wizard samples to create, at the first hand, an Ecore meta-model, and then, at the second hand, instances of this Ecore meta-model, using the generated EMF reflexive editors.

Once you created the ECore meta-model, please check that you correctly filled the property " Ns URI" of the root package of the Ecore meta-model, otherwise the resource load will fail. This NsURI must equal the real path of your metamodel. (You can modify this property through the Properties View of your meta-model)

In the current version of the EMF resource loader, you have to prepare your EMF Resource following these rules :

@mainClass "root::TestCSLoading"
@mainOperation "main"

package root;

require kermeta
require "cs.ecore"

using kermeta::standard
using kermeta::persistence

class TestCSLoading
{
     operation initialize(uri : String, mm_uri : String) : Set<Object> is do
         /* Initialize the EMF repository */
         var repository     : EMFRepository init EMFRepository.new
         /* Create an EMF Resource */
         var resource : Resource init repository.createResource(uri, mm_uri)
         /* Load the resource */
         resource.load
         /* Get the loaded __root__ instances (a Set<Object>) */
         result := resource  // a resource is a collection of objects contained
     end

operation main() is do 
   var instances : Set<Object> init self.initialize("./test.cs", "./cs.ecore")
   instances.each{ o |
      if (o == void) then stdio.writeln("Void object!") 
      else 
         stdio.writeln("---------------------------------") 
         stdio.writeln("Objet : " + o.getMetaClass.typeDefinition.qualifiedName 
            + " ( " + o.getMetaClass.typeDefinition.ownedAttribute.size.toString+ "attr.)" ) 
      end
      var template : cs::Template // Print instances which type is cs::Template 
      if (cs::Template.isInstance(o)) 
      then 
         template ?= o 
         stdio.writeln(" name : " + template.name) 
         stdio.writeln(" decision : " + template.decision.toString) 
         stdio.writeln(" content : " + template.content) stdio.writeln(" referer : " + template.referer.toString) 
      end
      // Print instances which type is cs::Decision 
      if (cs::Decision.isInstance(o)) 
      then
         decision ?= o 
         stdio.writeln(" name : " + decision.name) 
      end
   }
}

If your resource is dependent of other resources and that EMF succed to load it, the Repository that was used to load your resource will automatically load all these dependent resources.

To save a model, simply add the model elements in a Resource then call the save operation. All model elements contained by these added elements will also be saved in the Resource.

You can split your model in several files by using several resources, but you need to make sure that they all belong to the same Repository. Otherwise, you'll get at best a Dangling exception, or worse create inconsistent files.

Kermeta defines some collection data types handling sets of values. The different available collection types are the result of a combination of the constraints unique and ordered .

Figure 2.4. : The Kermeta collections

Another way to define set of objects would have been to use arrays. In fact, Kermeta does not define explicitly the concept of array, but it provides a multiplicity concept which can be used instead. Multiplicities are a way to define a lower and upper bound on a collection. Syntactically, lower and upper bounds are defined between brackets and are separated by two dots. Bounds can be an integer literal value or a star to specify there's no upper bound.

Example 1 : how to declare collections

using kermeta::standard		// don't need to specify it all the time
	// This is the simpliest and recommanded way of declaring a collection variable
	var myColA : Set<Integer> // this is equivalent to saying set Integer[0..*]
	var myColB : OrderedSet<Integer> // this is equivalent to saying oset Integer[0..*]
		

	// Collection with multiplicities
    var myCol1 : set Integer[4..6] // At least 4 elements and never more than 6
	var myCol3 : seq String[2..*] // At least two strings in the sequence
	var myCol4 : set String[1..*] // An non empty set
	var myCol5 : String[1..*] // If you don't specify any keyword, it is an ordered set
        

There is currently no way to define a collection by extension like you can do in C or Java. You must initialize your collection either by calling new (Kermeta constructor operation) on your collection type, or initialize by copy.

Example 2 : initialize collections

// Example of declaration of variables as Collections. All those syntaxes are valid
var myCol1 : set Integer[0..*]    init kermeta::standard::Set<Integer>.new
// Fill in myCol1
myCol1.add(10)
myCol1.add(50)

var myCol2 : oset String[0..*]    init kermeta::standard::OrderedSet<String>.new
var myCol3 : bag Boolean[0..*]    init kermeta::standard::Bag<Boolean>.new
var myCol4 : seq Integer[0..*]    init kermeta::standard::Sequence<Integer>.new
// if no keyword specified, and multiplicity is set, it is an OrderedSet

var myCol4 : String[0..*] init kermeta::standard::OrderedSet<String>.new

var myCol1a : seq Integer[0..*]    init myCol1
var myCol2a : oset String[0..*]    init myCol2
var myCol3a : kermeta::standard::Bag<Boolean> init myCol3
var myCol3a : kermeta::standard::Sequence<Integer> init myCol4

	Note
	Conclusion : in most cases, you don't need to use this special syntax, you can simply use the generic collection names (Set<Something>, OrderedSet<Something>, etc.) available in Kermeta framework. Moreover, lower and upper bounds aren’t checked yet by Kermeta type checker and interpreter.

The collections in Kermeta implement several functions based on lambda expressions (see Section 2.19, “ Lambda Expressions and functions ” ). These ones are very useful for model navigation.

aCollection.each { e | 
	    /* do something with each element e of this collection */
}

aBoolean := aCollection.forAll { e | /* put here a condition */
	} // return true if the condition is true for all elements in the collection.

aCollection2 := aCollection.select { e | 
	     /* put here a condition that returns true for elements that must be included in the resulting Collection */
	}

aCollection2 := aCollection.reject { e | 
	     /* put here a condition that returns true for elements that must be exclude in the resulting Collection */
	}

 // return a new collection which size is the same as in the original 
			 // collection, and which element type is the type of the result of the expression.
			aCollection2 := aCollection.collect { e | 
			     /* put here an expression, for example e.name */
			}

anObject := aCollection.detect { e | /* a condition */} // returns an element (usually the first) that fulfills the condition.

aBoolean := aCollection.exists { e | /* a condition */} // returns true if at least one element fulfills the condition.

aBoolean := aCollection.exists { e | false true }

aBoolean := aCollection.exists { e |
				stdio.writeln(e.toString)
				/* a condition */
			}
			

aBoolean := aCollection.exists { e | stdio.writeln(e.toString) }/* The value of aBoolean is Void */

We introduce here the 2 first cases, which are relationships between two concrete entities.

class A { attribute x : set X[0..*] } 
class X {}

	Note
	Composition notion also relates to containment notion. So, there are some restriction about valid model. For example, in an association, only one end can be an attribute, otherwise this means that we have an association with a diamond on both end and we cannot say who is the container of the other.

class A { reference x : set X[0..*] } 
class X {}

Attributes, references and properties underlying collections may eventually be specialized. By default, they are represented by an OrderedSet. If you wish to be more precise and for exemple allow to have several items with the same value in your collection, you can use the collection modifiers as defined in Section 2.15, “ Collections ”

For example :

class A {
	attribute x1 : seq String[0..*]  // allows duplicates, ordered
	attribute x2 : set String[0..*]  // doesn't allow duplicates, not ordered        
	attribute x3 : bag String[0..*]  // allows duplicates, not ordered               
	attribute x4 : oset String[0..*] // (default if no modifier) doesn't allow duplicates, ordered        
}        

The opposite [property] of a property defines an association (bidirectional link) between two entities. An opposite is expressed by a sharp #. In the following example, a is the opposite property of the entity of type B, and b is mutually the opposite property of the entity of type A.

	Caution
	A property whose type is a DataType (i.e String, Boolean, Integer) cannot have an opposite!

Example 1 : definition of an attribute, a reference, and an opposite property

This means that a can be accessed from b. Subsequently, if you modify the property b of an instance of A, it will mutually update its opposite property, i.e the property a of the instance of B contained in property b. You can make a test with the following example of code.

Example 2 : navigability of opposite properties

var a1 : A init A.new
a1.name := "a1"
var b1 : B init C.new
a1.b := b1
stdio.writeln("b1 opposite : " + b1.a.name) // This prints "a1"!

The following paragraph shows a set of examples of attributes and references.

Figure 2.5. Attributes and references

Example 3 : a set of attributes and references, with multiplicities and opposites.

TODO : add an example of code using those classes !! See https://gforge.inria.fr/plugins/scmcvs/cvsweb.php/integration_projects/other/org.openembedd.formations/Kermeta/Basics/docs/FR_formation_Kermeta_1er_niveau.odp?cvsroot=openembedd for such examples (p. 21).

package root;

class A1 {
    attribute b : B1[0..*] 
}
class B1 {}
			

class A2 {}
class B2 {
    reference a : A2 
}
			

class A3 {
    reference b : B3#a
}
class B3 {
    reference a : A3#b
}
			

class A4 {
    reference a : A4[0..*]
}

class A5 {
    attribute ab : A5[0..*]#aa
    reference aa : A5#ab
}

class A6 {
    attribute b : B6#a
}
class B6 {
    reference a : A6[1..1]#b
}

class A7 {
    attribute b : B7[0..*]#a
}
class B7 {
    reference a : A7#b 
}

class A8 {
    attribute b : B8[1..1]#a
}
class B8 {
    reference a : A8#b
}

class A9 {}
class B9 {
    reference a : A9[1..1]
}

	Note
	For every case where the upper bound of a property is upper to 1, the type of the property is OrderedSet . The reader will refer to Section 2.15, “ Collections ” (except the bag type) to have the available types for a [m..n](n>1) multiplicity property.

In a class definition, a derived property is a property that is derived or calculated, i.e it contains a body, like operations. Usually, such properties are calculated from other properties available from its owning class definition. In practice, you can define the code that you want inside a derived property.

In other words it does not reference to a concrete entity: it is calculated, through the accessor operations getter and setter.

The special parameter value is used in the setter to get the value passed when calling the setter.

Let's take the following class definitions :

// readonly property : it has no setter
class A 
{
    attribute period : Real
    property readonly frequency : Real // property : keyword for derived property
        getter is do
            result := 1/period
        end
}
// modifiable property :
class B 
{
    attribute period : Real
    property frequency : Real
        getter is do
            result result := 1/period
        end
        setter is do
            period := 1/value
        end
}

// a typical use would be (with aB an instance of class B) 
var freq : Real
fred := aB.frequency // to use the getter
aB.frequency := freq + 1 // to use the setter, the period is also updated in the process 

	Note
	To understand to role of the value keyword, you can imagine that in this sample the setter syntax is a shortcut syntax of : setter( value : Real) is do ... (even if actually this syntax isn't supported).

	Warning
	Since derived properties aims to behave like attributes or references, if the multiplicity is greater than 1, it doesn't make sense to define a setter. This is because it means reassigning the internal collection which is in fact calculated.

Properties are accessed or modified as classical properties. See next subsection for examples.

Example 1 : let's take the example with A6 and B6 :

class A6 {
     attribute b : B6[0..*]#a
}

class B6 {
    reference a : A6#b 
}

var a6 : A6 init A6.new
var b6 : OrderedSet<B6>
// get the b attribute
// Note that as the attribute as a multiplicity >1 it is an OrderedSet 
b6 := a6.b

var a6 : A6 init A6.new
var b6 : B6 init B6.new
// add b6 to the attribute b of A. 
// Note : you don’t have to initialize b! done through A6.new
a6.b.add(b6)

// OrderedSet owns a method that removes an element given its
     // index in the set. For unordered sets, use "remove" method
a6.b.removeAt(0)
// Also valid : a6.b.remove(b6)

var a6 : A6 init A6.new
var b6 : B6 init B6.new
a6.b.add(b6)
// this assertion is true. Moreover, any instance in a6.b will
// have a6 as their opposite since b is a collection
assert(b6.a == a6)

var a6 : A6 init A6.new
var b6 : B6 init B6.new
// add ab6 to the attribute "b"
a6.b.add(b6)

var a6c : A6 init b6.container()
// this assertion is true
assert(a6c.equals(a6))

It is not different with references that have a [m..1] (m=0 or m=1) multiplicity:

Example 2 : the A5 B5 case

class A5 {
    attribute b : B5#a // no multiplicity means [0..1]
}
class B5 {
    reference a : A5[1..1]#b
}

var a5 : A5 init A5.new
var b5 : B5
// get the b attribute
b5 := a5.b

var a5 : A5 init A5.new
var b5 : B5 init B5.new
// set b5 to the attribute b of A.
a5.b := b5

a5.b := void

var a5 : A5 init A5.new
var b5 : B5 init B5.new
a5.b := b5
// this assertion is true.
assert(b5.a == a5)

var a5 : A5 init A5.new
var b5 : B5 init B5.new
// add b5 to the attribute "b"
a5.b := b5

var a5c : A5 init b5.container()
// this assertion is true
assert(a5c.equals(a5))

	Note
	Be careful with attributes or references ref with multiplicity greater than 1, they are automatically initialized with a reflective collection (ie. a collection that is aware of an eventual opposite). So, you cannot assign them using := If you wish to change completely its content with the one of another collection, you must use the clear and addAll operations.

Note

For the same reason, reference refA : OrderedSet<String> is different from reference refB : String[0..*] . If both can be navigated the same way (using add, each or any operation available on Collection), refA needs to be created before use with refA := OrderedSet<String>.new . refA is a reference to a colection whereas refB is a reference to String with a multiplicity greater than 1 (which is internally represented as a ReflectiveCollection<String>)

Attribute and reference have one main behavior difference.

Attribute has a notion of containment that reference hasn't.

This has some implication on the behavior of the assignment because an attribute cannot be owned by more than one object at a time.

There is an exception for attributes which type is a primitive type (String, Integer, Boolean, Real, Char) : since those types inherit from ValueType , they are not concerned by the composition, opposite concepts. In this case, the assignment doesn't impact any value but the assigned one.

Example 1 : Assignment behavior for attribute

class A { attribute c1 : C }
class B { attribute c2 : C }
class C { }
aA.c1 := C.new
aB.c2 := aA.c1     // now aA.c1 == void !!!

Example 2 : Assignment behavior for reference

class A { reference c1 : C }
class B { reference c2 : C }
class C { }

aA.c1 := C.new
aB.c2 := aA.c1     // aB.c2 == aA.c1 and aA.c1 keeps its value !!!

Example 3 : Assignment behavior for attribute which type is String

class A { reference c1 : String }class B { reference c2 : String }aA.c1 := "Robert"aB.c2 := aA.c1 // aB.c2 == aA.c1 == "Robert"

	Note
	The assignment into a variable or a reference is not a problem because it doesn't change the owner of the assigned object.

The equals method behaves the same way as in java. This means that you can overwrite it, if you want to compare the contents of two objects of the same class.

@mainClass "root::Main"
@mainOperation "main"

package root;

require kermeta
using kermeta::standard
using kermeta::kunit
class A {

  reference x : Integer

  method equals(compared : Object) : Boolean is do
    var castedCompared : A
    castedCompared ?= compared
    result := x.equals (castedCompared.x)
  end

}


class Main inherits kermeta::kunit::TestCase{

  operation main() : Void is do

    var a1 : A init A.new
    var a2 : A init A.new
 
    a1.x := 10
    a2.x := 20

    assert( not a1.equals(a2) )	// objects are different with all methods
    assert( not a1 == a2 )
    assert ( a1.oid == a2.oid ) 

    a2.x := 10
 
    assert ( a1.equals(a2) ) 	// objects becomes equals
    assert ( a1 == a2  )		// also with ==
    assert ( a1.oid == a2.oid ) // but they physically are still different

  end

}

In Kermeta language, there is a notion of primitive type. Here is the list of primitive types :

We do not want two Integer objects with the same value to be different. What we want is to use == operator to compare values of primitive types. These classes simply redefine the equals. Then we can write this code :

var i1 : Integer init 10
var i2 : Integer init 10
assert (i1.equals(i2))

var i3 : Integer init 10
var i4 : Integer init 10
assert (i3 == i4)

The method equals exists for the collections. The generic behavior is the following : for two collections a and b, if all elements of a are contained in b and vice-versa, then it returns true, false otherwise. This behavior is little bit different for ordered collection which takes into account the order of elements. Have a look to the following pieces of code :

operation test_try1() : Void is do
   var os : OrderedSet<Integer> init OrderedSet<Integer>.new
   os.add(1) os.add(2) os.add(3) os.add(4) os.add(5) os.add(6)

   var os2 : OrderedSet<Integer> init OrderedSet<Integer>.new
   os2.add(1) os2.add(2) os2.add(3) os2.add(4) os2.add(5) os2.add(6)

   assert (os.equals(os2) )
end

operation test_try2() : Void is do
   var os : OrderedSet<Integer> init OrderedSet<Integer>.new
   os.add(1) os.add(2) os.add(3) os.add(4) os.add(5) os.add(6)

   var os2 : OrderedSet<Integer> init OrderedSet<Integer>.new
   os2.add(1) os2.add(2) os2.add(3) os2.add(4) os2.add(5)

   assert ( not os.equals(os2) )
end

/**
 * An ordered set takes care about the order.
 */
operation test_try3() : Void is do
   var os : OrderedSet<Integer> init OrderedSet<Integer>.new
   os.add(1) os.add(2) os.add(3) os.add(4) os.add(5) os.add(6)

   var os2 : OrderedSet<Integer> init OrderedSet<Integer>.new
   os2.add(4) os2.add(6) os2.add(3) os2.add(1) os2.add(5) os2.add(2)

   assert ( not os.equals(os2) )
end

/**
 * A set does not care about the order.
 */
operation test_try4() : Void is do
   var os : Set<Integer> init Set<Integer>.new
   os.add(1) os.add(2) os.add(3) os.add(4) os.add(5) os.add(6)

   var os2 : Set<Integer> init Set<Integer>.new
   os2.add(4) os2.add(6) os2.add(3) os2.add(1) os2.add(5) os2.add(2)

   assert ( os.equals(os2) )
end

In the following sections, you will find many examples of declarations, definitions, and uses of functions.

The collections in Kermeta implement several functions based on lambda expression. These ones are very useful for model navigation.

Example 1: closure definition for collection iterator-like in Kermeta

aCollection.each { e | 
    /* do something with each element e of this collection */
}

See Section 2.15, “ Collections ” for other existing functions on collections.

Example 2: another useful function that is defined on Integer : the function times

10.times { i | stdio.writeln(i.toString) } // prints 0 to 9 

Notice that you can also write some complex code in the function, using internal variables, etc. In such a case, the last statement evaluation will be the returned result of the lambda expression (provided it is declared to return something)

Example 3 : "complex"" code in a lambda expression

aCollection.each { e | 
    stdio.writeln("I am complex code!"
    stdio.writeln("Element : " + e.toString)
    var i : Integer init 5
    i := i + 132458
}

Example 4 : postponing parameter evaluation in the andThen operation

The operation andThen and orElse of Boolean use the ability of functions to postpone the parameter evaluation. This allows to implement the expected behavior without adding new construct to the language.

        // this kind of code allows to avoid a cast exception on the second test
        if cl.isInstanceOf(NamedElement).andThen{|	cl.asType(NamedElement).name == "foo"} then
        	// do something...
        end

Example 5 : using operation that use a function with several inputs

aCollection.indexedEach { e, eachContext | 
	stdio.write("element "+ eachContext.index.toString + ": " + e.toString)
	if(!eachContext.isLast) then stdio.writeln(",") end 
  }

aCollectionOfNamedElement.forAllCpl{s1,s2| (s1.name==s2.name).implies(s1==s2)}

You can also define your own functions, by declaring an operation, with a parameter as a function using the syntax described in Section 2.19.1, “ Syntax ” .

Example : definition of functions for collections

abstract class Collection<G>
{     
     /** * runs func on each element of the collection */
     operation each(func : <G -> Object>) : Void is do
         from var it : Iterator<G> init iterator
         until it.isOff
         loop
             func(it.next)
         end
      end

     /** * checks that the condition is true on all the element of the collection * returns true if the collection is empty */
     operation forAll(func : <G -> Boolean>) : Boolean is do
         var test : Boolean init true
         from var it : Iterator<G> init iterator
         until it.isOff
         loop
            test := test and func(it.next)
         end
         result := test
     end
}

You can also define lambda expression as variable. This can be useful if you don't want to ( or can't) modify the class.

With one Integer argument and returning an Integer.

var aLambdaExp : <Integer->Integer>
var aLambdaResult : Integer
aLambdaExp :=  { i : Integer | i.plus(4) }
// aLambdaResult equals 7
aLambdaResult := aLambdaExp(3)

var aLambdaExp : <[Integer, Integer]->Integer>
var aLambdaResult : Integer
aLambdaExp :=  { i : Integer, j : Integer | i * j }
// aLambdaResult equals 12
aLambdaResult := aLambdaExp(3, 4)

var init_set : Set<Integer> := Set<Integer>.new
init_set.add(32)
init_set.add(23)
init_set.add(41)

// This sequence equals : [320, 230, 410]
var sequence : Sequence<Integer> := init_set.collect { element | element*10}

The code within the function can be as complex as you want, using internal variables, etc.

var factoExp : <Integer->Integer>
    factoExp :=  { n : Integer | 
        var fact : Integer := 1
        from var x : Integer := 1 
        until x > n 
        loop
            fact := fact * x 
            x:=x+1
        end
        fact // return fact as the result of the function
        //shorter alternative ;-)... if n<=1 then 1 else factoExp(n -1) * n end
    }
    var cnkExp : <[Integer, Integer]->Integer>
    cnkExp :=  { n : Integer, k : Integer |
        factoExp(n) / (factoExp(k) * factoExp(n-k))
    }

When starting to use the lambda expression you can define some useful design patterns. One of them is the ability to propose an each that traverses all the owned element of a given metamodel. For some usage, this can be an interresting alternative to the visitor design pattern.

Let's have the following metamodel:

class NamedElement {
	attribute name : String
}
class A inherits NamedElement {
	attribute ownedAs : A[0..*]
}
class B inherits A {
	attribute ownedBs : B[0..*]
}
class C inherits A {
	attribute ownedBs : B[0..*]
	attribute ownedC : C
}

It would be nice to be able to call a simple lambda on all the elements directly owned by an element. This can be done by adding an operation using the following pattern:

aspect class NamedElement {
	operation eachOwnedElement(func : <NamedElement -> Void>) : Void is do
		// String attributes are value, so they aren't really "owned"  
	end
}
aspect class A inherits NamedElement {
	operation eachOwnedElement(func : <NamedElement -> Void>) : Void is do
		super[NamedElement](func)
		self.ownedAs.each{ e |
			func(e)
		}
	end
}
aspect class B inherits A {
	operation eachOwnedElement(func : <NamedElement -> Void>) : Void is do
		super[A](func) // makes sure to call func on attributes inherited from A
		self.ownedBs.each{ e |
			func(e)
		}
	end
}
aspect class C inherits A {
	operation eachOwnedElement(func : <NamedElement -> Void>) : Void is do
		super[A](func) // makes sure to call func on attributes inherited from A
		self.ownedBs.each{ e |
			func(e)
		}
		if(not ownedC.isVoid) then
			func(ownedC)
		end
	end
}

Then a call like the following will ensure to traverse all the directly owned elements.

var c : C := // initialize it with a complex model :-)
// write the name of all the elements directly  contained by c
c.eachOwnedElement{ aNamedElement | stdio.writeln(aNamedElement.name) }

// collect all the elements directly contained by c
var ownedElements : Sequence<Object> := Sequence<Object>.new
c.eachOwnedElement{ aNamedElement | ownedElements.add(aNamedElement) }
stdio.writeln("ownedElements.size = "+ ownedElements.size.toString)

It is then easy to extend this pattern to traverse the directly and indirectly owned elements.

aspect class NamedElement {
	operation eachAllOwnedElement(func : <NamedElement -> Void>) : Void is do			
		eachOwnedElement{e|
			func(e) 
			e.eachAllOwnedElement{child|func(child)} 
		}
	end
}

This new operation can be called in the same easy way:

// write the name of all the elements directly or indirectly contained by c
c.eachAllOwnedElement{ aNamedElement | stdio.writeln(aNamedElement.name) }

// collect all the elements directly or indirectly contained by c
var allownedElements : Sequence<Object> := Sequence<Object>.new
c.eachAllOwnedElement{ aNamedElement | allownedElements.add(aNamedElement) }

	Tip
	Like any pattern, this task can be automated by using a model transformation. The Ecore MDK offers such transformation that generates this pattern for a given Ecore model.

The merge is driven by the qualified name of the element to merge. Two classes will be merged if they have exactly the same qualified name (packages names + class name)

The merge is allowed only if you add the following keyword:

In this sample, writing:

package pack;
// this is the first aspect of class A
aspect class A {
	attribute decorations : Decoration[0..*]
}
// this aspect also declares a new class, visible only when requiring this aspect
class Decoration{
	attribute val : kermeta::standard::String
}

package pack;
// this is the base class
class A {
	attribute name : kermeta::standard::String
	
	 // operation in this context have access only to the base's features 
	operation getName() : kermeta::standard::String is do
		result := name
	end
}

package pack;

// is this context we have access to all the features of class A : from base, aspect1 and aspect2
aspect class A {
	attribute id : kermeta::standard::Integer
	operation getFullSpecification() : kermeta::standard::String is do
		result := name
		result := "(" + id.toString + ")"
		decorations.each{ decoration | result := result + "<" + decoration.val+ ">" }
	end
}

KermetaProject "aspect_sample"
	groupId = "my.group"
	defaultMainClass = "sample::AspectExample"
	defaultMainOperation = "main"
	sources = {
		require "${project.baseUri}/base.kmt"
		require "${project.baseUri}/aspect1.kmt"
		require "${project.baseUri}/aspect2.kmt"
	}
	dependencies = {
		//default dependency to kermeta framework (try first in eclipse plugin, then look into maven repository)
		dependency "library.core" ="platform:/plugin/org.kermeta.language.library.core",
		                           "mvn:org.kermeta.language/language.library.core/LATEST"
	}

	New in Kermeta 2
	In kermeta 1, the require statements were at the file level, now they apply at the project level. This means that the contibution of an aspect will be visible in all the project. It is still possible to manage the visibility of aspects using project dependencies. It is often useful to separate some set of files into projects.

	Tip
	In the previous example we aspectize a *.kmt, we could choose to aspectize the corresponding *.ecore file. In fact, the both formats are available: *.kmt or *.ecore.

from the point of view of the project, the 3 kmt files are equivalent to write a single kmt file containing :

package pack;
class A {
	attribute name : kermeta::standard::String
	attribute decorations : Decoration[0..*]	
	attribute id : kermeta::standard::Integer
	
	 // operation in this context have access only to the base's features 
	operation getName() : kermeta::standard::String is do
		result := name
	end
	operation getFullSpecification() : kermeta::standard::String is do
		result := name
		result := "(" + id.toString + ")"
		decorations.each{ decoration | result := result + "<" + decoration.val+ ">" }
	end
}
class Decoration{
	attribute val : kermeta::standard::String
}

This sample shows that if the signature are strictly equivalent, then you can redefine the same structural feature (attribute, reference) in several aspect class.

In addition, if an operation can be extended to addpre or post conditions to a given operation.

	New in Kermeta 2
	In kermeta 1, and abstract operation was used to define an operation with no body as a support for operation extensions. In kermeta 2 we suppose that if the developper has defined the operation abstract then his intents is that the operation must be overriden via a sub class. So now, the abstract keyword cannot be used for that. We use the void keyword instead.

Currently, (v1.0.0) the derived properties cannot be redefined in several aspect classes.

aspect class A {
	//the feature is equivalent to the one define in the base class, so this is legal
	attribute name : kermeta::standard::String	
	
	// the operation has the same signature and has no body (ie. void)
	operation getQualifiedName() : kermeta::standard::String 
		post resultNotVoid is not result == Void
		is void
}

package pack;
class A {

	attribute name : kermeta::standard::String
	operation getQualifiedName() : kermeta::standard::String is do
		result := name
	end
}

In ecore, it is possible to define some operation with body. this is acheived either via the generated NOT comment in the generated java file or via a specific annotation in the ecore file (Please refer to EMF documentation and book for details on that). By default, kermeta will reuse these operations and allows to call this code. However, in some situations, you may want to overload this code by your own in kermeta. This can be done as follow:

package pack;
require kermeta
aspect class A {	
	@overloadable "true"
	operation getQualifiedName() : kermeta::standard::String 
		post notVoid is not result == Void
		is abstract
}

package pack;
require kermeta
aspect class A {	
	@overloadable "true"
	operation getQualifiedName() : kermeta::standard::String is do
		raise kermeta::exceptions::NotImplementedException.new
	end
}

class A {
	attribute name : kermeta::standard::String
	operation getQualifiedName() : kermeta::standard::String is do
		result := name
	end
}

In this sample, the first declaration of the operation is adds a post condition to the operation. As it is abstract, it isn't in conflict with the other declarations.

The second declaration, has a body. It implements a kind of default behavior for the operation that will be used if no other body is declared for this operation. this is useful when converting ecore models into Kermeta for example.

The last definition is the one that will be used in this context.

If you define some inheritance in one of your aspects, all the aspects that require this aspect will have access to it. You don't need to redefine it. However, if it helps to clarify the code to write it again, it will behave the same way.

In Kermeta textual syntax, the keyword aspect must be placed before the keyword abstract.

Example :

package pack;
require kermeta
aspect abstract class A {	
	// add something
}

A special case of the use of AOP in Kermeta is having a ClassDefinition A defined in 2 separately modeling units (*.kmt) with the keyword aspect. But the two modeling units does not require another kmt or ecore file containing the base definition of A. Now if there is a new Modeling Unit that requires the two previous one the available definition of A is the composition of the 2 defined aspects.

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

The extern allows you to call a java static method from Kermeta. But, to do that, you will have firstly to create a Java wrapper, that will be able to manipulate correctly the Java objects, and secondly to add this wrapper in your java global classpath.

Then, from this method you can access all your java libraries. One task of the static method will be to convert the basic types like Integer or String.

You'll need to refer to the Javadoc of the interpreter in order to know how to access the internal RuntimeObject of Kermeta.

Example 1 : sample of Kermeta code using extern (io.kmt):

/** * An implementation of a StdIO class in Kermeta using existing Java: standard * input/output */
class StdIO
{
 /** * write the object to standard output */ 
 operation write(object : Object) : Void is do
   result ?= extern fr::irisa::triskell::kermeta::runtime::basetypes::StdIO.write(object)
 end
 
 /** * writeln the object to standard output */ 
 operation writeln(object : Object) : Void is do
   result ?= extern fr::irisa::triskell::kermeta::runtime::basetypes::StdIO.writeln(object)
 end
 
 /** * read an object from standard input */ 
 operation read(prompt : String) : String is do
   result ?= extern fr::irisa::triskell::kermeta::runtime::basetypes::StdIO.read(prompt)
 end

}

Example 2 : sample of Java code ("wrapper") called by the Kermeta extern:

/** Implementation of input and output methods */
   public class StdIO{ 
      // Implementation of method write called as :
      // extern fr::irisa::triskell::kermeta::runtime::basetypes::Io.write(output) 
      public static RuntimeObject write(RuntimeObject output) {
         output.getFactory().getKermetaIOStream().print(output.getData().get("StringValue")); 
      return output.getFactory().getMemory().voidINSTANCE; 
      } 
      // Implementation of method writeln called as : // extern fr::irisa::triskell::kermeta::runtime::basetypes::Io.writeln(output) 
      public static RuntimeObject writeln(RuntimeObject output) {
         write(output); 
         output.getFactory().getKermetaIOStream().print("\n"); 
      return output.getFactory().getMemory().voidINSTANCE; 
      } 
      // Implementation of method writeln called as : // extern fr::irisa::triskell::kermeta::runtime::basetypes::Io.read(output) 
      public static RuntimeObject read(RuntimeObject prompt) {
         java.lang.String input = null; 
         // We also have our own String wrapper 
      if (String.getValue(prompt).length()>0) 
         prompt.getFactory().getKermetaIOStream().print(String.getValue(prompt)); 
      // FIXME : dirty cast.. read returns a String or could return smthg else? 
      input = (java.lang.String)prompt.getFactory().getKermetaIOStream().read( String.getValue(prompt)); 
      RuntimeObject result = String.create(input, prompt.getFactory()); 
      return result; 
   }

	Tip
	This method is used to implement Kermeta framework. You'll find much more code samples of extern call in its sources.

	Warning
	This feature is still a prototype and still have many limitations. The first version is already available but any help is welcome to help us to improve it.

The basic principle, is to simply require your jar file.

 require "yourjar.jar" 

Then Kermeta automatically retreive the class definition it contains to be used from Kermeta code. However, as java and Kermeta have different language constraints, some adaptation are automatically made.

If there is several operations with the same name (as this is legal in Java but not in Kermeta) they are renamed. (Please use the outline to find the new name of the operation you want)

Java contructors are generated as "initialize" operation.

When creating a new java object from Kermeta, a call to new is not enough, you also need to call one of the "initialize" operation in order to correctly create it.

In order to get the standard library direclty from your running java, you can require java_rt_jar but as this library is really big and as you probably don't need all java from Kermeta ;-) then you must use the includeFilter and excludeFilter.

Sample using java.io from java Standard library

 
require kermeta

require java_rt_jar includeFilter ("java::io")   // the filter ensure we don't get all java

using java::io
using kermeta::kunit
class testRequireJava inherits kermeta::kunit::TestCase
{
	operation main() : Void is do
		var tr : TestRunner init TestRunner.new
		tr.run(testRequireJava)
		tr.printTestResult
	end	
	
	operation testmain() : Void is do 
	
		// create and initialize a File with the String
		var f : File init File.new.initialize_String("c:/temp/test.txt")
		var f2 : File
		// create and initialize a FileWriter with the File
		var fwriter : FileWriter init FileWriter.new.initialize_File(f)
		if (f.exists) then 
			stdio.writeln(f.toString + " already exists")
		else
			stdio.writeln(f.createNewFile.toString)
		end
		fwriter.write_String("Hello world") 
		fwriter.close
		stdio.writeln("file written")
		stdio.writeln(fwriter.toString)
	    	    
		stdio.writeln(f.getPath)
		stdio.writeln(f.separator)
		f2 := f
		stdio.writeln(f2.createNewFile.toString)
		stdio.writeln((f2.equals(f)).toString)
		assert( f2.equals(f))
	    
		var fwriter2 : FileWriter
		fwriter2 :=  fwriter
		stdio.writeln((fwriter2.equals(fwriter)).toString)
		assert( fwriter2.equals(fwriter))
	    
		stdio.writeln(f.getPath)
		stdio.writeln(f.toString)
		stdio.writeln("End")
	end
} 
      		

includeFilter and excludeFilter accept a comma separated list of qualified name. includeFilter adds only elements whose qualified name start with one of the list. excludeFilter removes elements whose qualified name start with one of the list. If you use a combinaison of includeFilter and excludeFilter , then the includeFilter is applied before the excludeFilter (that'll remove element from the included one.

Currently known limitations: no support for java5 generics (they are ignored), requiring very big jar like the full java library end up with out of memory error (you need to use the includefilter and excludeFilter), some bugs with some primitives types (double/float)

Figure 3.3. NamedElement class diagram

This figure presents the element in the structure package that have a name. Kermeta relies on in various situation (For example in the typechecking process). The containment hierarchy is also presented since it is used in the identification process.

Class is a bit special, since its name is a derived property.

Figure 3.4. Kermeta type system class diagram (the big picture)

This figure presents the global view of all the metaclasses involved in Kermeta type system.

Basically, you can notice the split between Type and TypeDefinion needed in order to handle generics.

The containment is also represented here.

Please note that there is both Type and TypeDefinition . This is needed because of the support of the generics. For example in

var mycoll : Collection<String>

mycoll is a VariableDecl which point to a Class whose typeDefinition is the ClassDefinition Collection and has a TypeVariableBinding that lead to String.

TODO add an object diagram or a figure to illustrate.

TODO : if time : provide a set of small diagrams that focus of some elements of the type system.

3.2.2.1. ModelType and ModelType adaptation view

Figure 3.5. Kermeta ModelType system class diagram

This figure presents the global view of the main metaclasses involved in Kermeta ModelType.

Figure 3.6. Kermeta ModelType adaptation class diagram

This figure presents the view of the main metaclasses used by the ModelType adaptation.

Kermeta provides basic control structures : block, conditional branch, loop, and exception handling. Here there an excerpt of the Meta-model describing control structures. Each basic control structures derives from the Expression concept.

Figure 3.9. Control structure

Figure 3.12. Kermeta assignment expression

In the following example, thetarget is of type CallExpression and thevalue is of type Expression .

var num : Numeric
var thetarget : Integer
var thevalue : Integer
// assignment : thetarget->target, thevalue->value
thetarget := thevalue
// casting : a is casted into the type of num which is Numeric.
num ?= a

Figure 3.13. Kermeta Literal Expression

var i : Integer
i := 5    // 5 is a IntegerLiteral
var s : String 
s := "I am a string" // "I am a string" is a StringLiteral