The Kermeta metamodelling language

The implementation of the transformation that allows the programmer to generate Java code from a given Timed-CaaFWrk -compliant model is given in Kermeta [Tri10a]. Kermeta is an open source object-oriented metamodelling language that was initially created to describe op- erations at the level of the meta-model. Hence, the specification of a meta-model comprises both a structural component defined by the structural relationships between the concepts and a behavioural component defined by the operations enclosed by each concept. The compliance of a model is determined by its adherence to the structural relationships specified by the meta-model, whereas its semantics is determined by the result that is obtained by executing the meta-model operations. Therefore, Kermeta can be seen as a language for specifying the behaviour of a domain-specific language (DSL), which is defined in a metamodelling fashion.

The definition of Kermeta is given in terms of the metamodelling principles. This means that there exists a meta-model that defines its (abstract) syntax. This meta-model is an extended version of the EMOF21 meta-model with concepts that introduce the concepts of control struc- tures, inheritance, operation overriding, as well as convenient constructions derived from the Object Constraint Language (OCL), such as closures, e.g. each, collect, select. A complete list of the extensions can be found in [MFJ05]. It is worth mentioning that the action language defined by the extensions introduced to the EMOF’s is imperative and object-oriented.

The Listing 4.20 shows an example of an operation described in Kermeta. This operation, step, is aimed at checking whether there exists at most one element of type Transition that has as a name the value (named c and of type String -line 1) passed as input parameter. In the case that there exists more than one element with the value passed as the input parameter (line 7), then an exception of type nonDeterminism is raised (line 8). Otherwise, the name of the fired transition (line 11) is returned.

Listing 4.20: Step operation in Kermeta (Taken from [BNT07]).



1 operation s t e p ( c : String ) : String i s do

2 3 var v a l i d T r a n s i t i o n s : Collection<T r a n s i t i o n > 4 5 v a l i d T r a n s i t i o n s := o u t g o i n g T r a n s i t i o n . s e l e c t{ t | t . i n p u t . e q u a l s ( c ) } 6 7 i f v a l i d T r a n s i t i o n s . s i z e > 1 then 8 r a i s e NonDeterminism.new 9 end 10 11 r e s u l t := v a l i d T r a n s i t i o n s . o n e . f i r e 12 13 end  

According to the expected shape a rule in a model transformation should have, and in spite of considering an operation as a rule, it is very difficult to identify the LHS and RHS of a rule, when it is specified in Kermeta. This is because Kermeta was not originally thought to be a transformation language. However, due to the way it is defined and due to its expressiveness

21

168 4. The Timed-CaaFWrk conceptual framework

and features it can be used to such a purpose. However, the main reasons a programmer to chooses Kermeta as the tool to implement the M2T transformation are:

• Its compatibility with the Eclipse Modelling Framework (EMF) [Ecl10, BBM03], which allows the Eclipse Development Environment to be used as a workbench to edit, store, and visualise models; and

• above all, the existence of the Kermeta Emitter Template (KET) [Tri10b] facility, which is specifically meant to ease the development process of an M2T transformation.

This KET facility, which is part of the Kermeta tool set, allows the programmer to specify within a template an overall sketch of the source code to be generated. This template, which is known as a KEt template, is made up of the text that should be written in the output, and tags that are interpreted to generate string values from some computation. There exist three kinds of tags:

• “< % − −” and “− − % >”: to define comments within the template,

• “< % =” and “% >”: to embed Kermeta expressions within the template. The result of the expression is placed within the resulting generated text, and

• “< %” and “% >”: to embed Kermeta statements or blocks within the template. Each block or set of Kermeta statements is known as a scriptlet . There is not any limitation on the number of scriptlets a template may contain. Moreover, a scriplets may reference elements that have been defined in other scriptlets.

The interpretation of the tags take place during the compilation of the template. The compilation of a KET template, performed by the template engine, produces a Kermeta file. It must be noted that the KET template may also be embedded in-line Kermeta statements, which remain once the template is compiled. So far, the compilation of a KET template must be manually performed before launching the M2T transformation. This M2T transformation is made of Kermeta files, only.

The Listing 4.21 shows some parts of the KET template used to generate the Java source code corresponding to a Role element in a Timed-CAA-DRIP -compliant implementation.

Listing 4.21: KET template for a Timed-CAA-DRIP Role class implementation.

 1 <%@ket 2 package=”TimedCAAFWrk” 3 require=”k e r m e t a h t t p : //timedCAAFWrk / 1 . 0 . . / u t i l s / H e l p e r . k m t I n t e r n a l F u n G e n e r a t o r . k m t ” 4 using=”TimedCAAFWrk k e r m e t a : : s t a n d a r d k e r m e t a : : u t i l s ” 5 isAspectClass=” t r u e ” 6 c l a s s =”R o l e ” 7 ismethod=” f a l s e ” 8 operation=” g e n e r a t e ” 9 parameters=”” 10 %> 11 12 <%var i n s t r : Set<I n s t r u c t i o n > i n i t s e l f . i n s t r u c t i o n s ( s e l f . i n s t r s )%> 13 <% i n s t r . s e l e c t{ i | i . i s K i n d O f ( Execute ) } . each { i | %> 14 <%=i . a s T y p e ( E x e c u t e ) . ˜ operation%> 15 <%}%> 16

4.5. Automatic code generation 169 18 . c a a .<%=s e l f . c a a . n a m e %>; 19 20 import j a v a . r m i . R e m o t e E x c e p t i o n ; 21 . . . 22 23 public c l a s s <%=s e l f . n a m e%> e x t e n d s R o l e I m p l { 24 . . . 25

26 public <%=s e l f . n a m e %>(String n , CAA c a a ) t h r o w s RemoteException {

27 s u p e r ( n ) ; 28 setCAA ( c a a ) ; 29 } 30 31 public v o i d body ( ) t h r o w s E x c e p t i o n { 32 . . . 33 } 34 }  

The first part of the template (lines 1-9) corresponds to the mandatory header that every KET template must have. This header contains information regarding the generation of the Kermeta file. This information is provided by eight directives [Cyr10]:

• package: specifies the root package of the Kermeta file, • require: set of requires that the Kermeta file should contain,

• using: declares the external Kermeta files that need to be imported, • class: main class of the Kermeta file,

• isAspectClass: true if the main class is an aspect, • operation: name of the main operation,

• isMethod: true if the main operation is a redefinition of an existing operation, and • parameters: parameters of the generate(...) method. These parameters can be used in

KET tags to gather data from outside the generator.

Directives like package, require, using, class, and parameters are mandatory, whereas isAspect- Class, operation and isMethod are optional.

The remaining part of the example shows how kermeta expressions (lines 14, 17, 18, 23 and 26) and scriptlets (lines 12-13 and 15) are embedded within the template.