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 | |
---|---|
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).
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.
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.
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.
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.
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.
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.
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 }
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)
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 }
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
var i : Integer i := 5 // 5 is a IntegerLiteral var s : String s := "I am a string" // "I am a string" is a StringLiteral
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 | |
---|---|
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.