Chapter 3. Kermeta Metamodel

As Kermeta is designed to be used in a model driven environment, its structure is given as a model. This section presents the metamodel of Kermeta which corresponds to the abstract syntax of Kermeta.

This metamodel may be useful for many use cases. For example, you can use it to manipulate your Kermeta code for analysis or even generate some Kermeta code. This may be useful to understand how Kermeta works too.

[Note]Note

All the code samples in this section are for illustration of the given concepts.

The goal of the Kermeta language is to provide an action language for MOF models. The idea is to start from MOF, which provides the structure of the language, and to add an action model. Using the MOF to define the structure of the Kermeta language has an important impact on the language. In fact, as MOF concepts are Object-Oriented concepts, Kermeta includes most of the classical Object-Oriented mechanisms. Yet, MOF only defines structures, and the operational semantic corresponding to MOF concepts has to be defined in Kermeta. For instance MOF does not provide a semantic for behavior inheritance (concepts like method redefinition, abstract method, etc does not have any sense in the MOF).

3.1. Architecture

Kermeta has been designed to be fully compatible with the OMG standard meta-data language EMOF. The metamodel of Kermeta is divided into two packages :

  • structure which corresponds to EMOF

  • behavior which corresponds to the actions. This section gives an overview of these two packages and their relationships.

Thanks to this reuse, Kermeta is fully compatible with EMOF. This is useful in the promotion of Kermeta as a metalanguage.

EMOF extension and Kermeta promotion

Figure 3.1. EMOF extension and Kermeta promotion


The link between structure and behavior is made through the property body of class Operation which allows to define the behavior of an operation using a Kermeta expression.

A more detailed description of the architecture of Kermeta is presented in next sections.

3.2. Structure package

Structure package

Figure 3.2. Structure package


This figure presents the main classes of the structure package. To design this package, we started from EMOF and completed it to build the Kermeta language. The choice of EMOF is motivated by two main reasons : firstly it is standardized by the OMG and secondly is is well-supported by tools such as Eclipse/EMF.

As MOF is not initially designed to be executable, several concepts have to be completed and slightly modified to build an executable language. The first and most important modification is to add the ability to define the behavior of operations. To achieve this we define an action language in the package behavior of Kermeta. The class hierarchy of the package behavior is presented on Figure 3.5, “Behavior package”. In practice, Kermeta expressions have been designed by adding model modification capabilities (like assignment of properties for instance) to OCL expressions.

This represents the static part of the metamodel.

As a reminder, the structure of Kermeta is derived from EMOF from the OMG. During the build process, we merge and connect it with the behavior part.

So all the meaning of those metaclasses are very close to those described in the OMG standard specification.

3.2.1. NamedElement view

NamedElement class diagram

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.

3.2.2. Type system view

Kermeta type system class diagram (the big picture)

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.3. Behavior package

Behavior package

Figure 3.5. Behavior package


3.3.1. Control Structures

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.

Control structure

Figure 3.6. Control structure


3.3.2. Variables

Use of variables

Figure 3.7. Use of variables


3.3.3. Call Expressions

use of exceptions

Figure 3.8. use of exceptions


3.3.3.1. CallSuperOperation

In the following example, the type of super(element) is CallSuperOperation:

class ParentClass {
    operation op(element : Integer) : Integer is do
        result := element + 1
    end

}

class ChildClass {
    method op(element : Integer) : Integer is do
        result := super(element)
    end
}

3.3.3.2. CallVariable

The type of callvar, below, is CallVariable:

var myvar : Integer
var callvar : Integer init 4
// 
myvar := callvar 

A special case, when calling a lambda expression : the type of lf in the assignment of res, is CallVariable.

var lf : <Integer->Integer>
var res : Integerlf := function  { i : Integer | i.plus(1) }
// The type of lf, below, is CallVariable
res := lf(4)
          

3.3.3.3. CallResult

The type of result is CallResult

operation op() : Integer is do
    result := 61
end

3.3.3.4. CallFeature and SelfExpression

  • The type of self is a SelfExpression!

  • The type of attr in the body of the operation myoperation is CallFeature (a callfeature on self), and so is the type of myoperation(4) (a callfeature on a).

class A {
    attribute attr : Integer
    operation myoperation(param : Integer) : Integer is do
        result := self.attr + param
    end
}
class B {
    operation anotheroperation() : Integer is do
        var a : A
        result := a.myoperation(4)
    end
}

3.3.4. Assignment

Kermeta assignment expression

Figure 3.9. 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

3.3.5. Literals

Kermeta Literal Expression

Figure 3.10. 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

3.3.6. Lambda Expression

Kermeta lambda expressions

Figure 3.11. Kermeta lambda expressions


3.4. Viewing Kermeta metamodel

In Kermeta, you can view its metamodel by several ways.

First, the ecore file kermeta_java.ecore is available in the lib folder of Kermeta main plugin.It is used when saving a Kermeta program in XMI ("Compile to XMI" function on *.kmt files). You can then load Kermeta program as a model, typically to transform it.

[Warning]Warning

You should not try to execute operations on Kermeta models you've just dynamically created unless you froze it. This is a feature which has not been completly tested.

Another typical way to access to a Kermeta model and Kermeta metamodel is to use the reflection. All objects inherits from Object that defines the getMetaClass operation. This use is used in one of the samples of Section 2.18, “Dynamic evaluation of Kermeta expressions” (when it selects an operation to be executed).

At last, the parse method on dynamic expression presented in section Dynamic evaluation of Kermeta expressions can give you some way to access a Kermeta model as it parses a Kermeta text and provides the corresponding model.