evaluation of kermeta to solve graph based problems

8/9/2019 Evaluation of Kermeta to Solve Graph Based Problems

1/10

Software Tools for Technology Transfer manuscript No.(will be inserted by the editor)

Evaluation of Kermeta for Solving Graph-based Problems

Naouel Moha, Sagar Sen, Cyril Faucher, Olivier Barais, Jean-Marc Jezequel

IRISA / INRIA Rennes Bretagne Atlantique, e-mail: { moha, ssen, cfaucher, barais, jezequel}irisa.fr

Received: date / Revised version: date

Abstract. Kermeta is a meta-language for specifyingthe structure and behavior of graphs of interconnectedobjects called models. In this paper, we show that Ker-meta is suitable for solving graph-based problems. First,Kermeta allows the specification of generic model trans-formations such as refactorings that we apply to differ-ent metamodels including Ecore, Java, and Uml. Sec-ond, we demonstrate the extensibility of Kermeta to theformal language Alloy using an inter-language modeltransformation. Kermeta uses Alloy to generate rec-ommendations for completing partially specified models.

Third, using a common case study we show that the Ker-meta compiler achieves better execution time and mem-ory performance compared to similar graph-based ap-proaches. The three solutions proposed for graph-basedproblems correspond to the first contribution of the pa-per. The second contribution is the comparison of thesesolutions with those proposed by other graph-based tools.The evaluation of Kermeta according to the criteria ofgenericity, extensibility, and performance represents thethird contribution.

Key words: MDE Metamodelling Model Typing

Model Transformation Refactoring Performance Genericity Extensibility Alloy

1 Introduction

Model-Driven Engineering (MDE) is a software develop-ment methodology which focuses on models as first-classentities. Models are graphs of objects interconnected bybidirectional relationships defined in metamodels. MDEaims to improve productivity of developers by maximiz-ing compatibility between systems and platforms andsimplifying the process of design.

Kermeta has been developed as a core language for

an MDE platform. It is an executable metamodellinglanguage implemented on top of the Eclipse Modeling

Framework (EMF) within the Eclipse development en-vironment.

In this paper, we present Kermeta as a suitable lan-guage for solving graph-based problems. We focus onthree case studies proposed in the GraBats08 tool con-test1 that involve specific graph-based problems.

The first case study consists of applying three wellknown refactorings [6] (Encapsulate Field, Move Method,and Pull-up Method) on models of Java programs. In thispaper, we present a generalised approach to model refac-toring that is applicable not only to Java programs but

other metamodels such as Ecore and Uml. We spec-ify the generic refactorings for various metamodels usingthe notion of model typing [28], which is an extension ofobject typing in the model-oriented context.

The second case study (conference scheduling) high-lights the extensibility of Kermeta to external languages,such as the formal language Alloy. We present an inter-language model transformation from Kermeta to Alloyto complete partial models. In the context of the casestudy, we use Alloy to generate different valid sched-ules for an unscheduled conference.

The third case study is an AntWorld simulation de-monstrating Kermeta performance with regard to exe-

cution time and memory usage. The Kermeta to Java /EMF compiler provides a version of the Kermeta simu-lation achieving better performance compared to similarapproaches based on Eclipse and eventually EMF.

Our contributions are threefold: (1) approaches tosolve graph-based problems involving these case studies,(2) experiments to evaluate Kermeta in terms of generic-ity, extensibility, and performance using these case stud-ies, (3) and a comparison of our approaches with thoseproposed by other graph-based tools.

This article is organized as follows. Section 2 intro-duces Kermeta and highlights some of its features in-

1

The GraBats08 tool contest was held during the 4th

Inter-national Workshop on Graph-Based Tools 2008.


2/10

2 Naouel Moha et al.: Evaluation of Kermeta for Solving Graph-based Problems

Fig. 1. Kermeta Graphical Interface

cluding the notion of model typing. Sections 3, 4, and 5develop each of the three criteria that characterise Ker-meta based on the three case studies. Section 6 surveysrelated work. Section 7 concludes and presents futurework.

2 Kermeta

2.1 Description

Kermeta is a language for specifying metamodels, mod-els, and model transformations that are compliant to theMeta Object Facility (MOF) standard [22]. The object-oriented meta-language MOF supports the definition of

metamodels in terms of object-oriented structures (pack-ages, classes, properties, and operations). It also pro-vides model-specific constructions such as containmentsand associations between classes. Kermeta extends theMOF with an imperative action language for specify-ing constraints and operational semantics for metamod-els [20]. Kermeta is built on top of EMF within theEclipse development environment. The action languageof Kermeta provides mechanisms for dynamic binding,reflection, and exception handling. It also includes clas-sical control structures such as blocks, conditionals, andloops. Figure 1 shows the Kermeta graphical interfacewithin Eclipse. It includes three views: a graphical rep-

resentation of the current metamodel, a Kermeta codethat applies transformations on the metamodel, and atree representation of concepts of one of the two firstviews depending on the current view.

In the next paragraphs, we describe two key featuresof the Kermeta language essential for the comprehensionof the paper: its ability of extension and the notion ofmodel typing.

2.2 Extension of Kermeta

The first key feature of Kermeta is its ability to extendan existing metamodel with constraints, new structural

elements (meta-classes, classes, properties, and opera-tions), and functionalities defined with other languages.

This feature offers more flexibility to developers by en-abling them to easily manipulate and reuse existing meta-models. The static composition operator require al-lows defining these various aspects in separate units andintegrating them automatically into the metamodel. Thecomposition is performed statically and the composedmetamodel is type-checked to ensure the safe integra-tion of all units. This mechanism can be compared tothe open class paradigm [5]. Open classes in Kermetaare used to organize cross-cutting concerns separatelyfrom their metamodel, a key feature of aspect-orientedprogramming [12]. Thanks to this composition operator,Kermeta remains a kernel platform and safely integrateall concerns around a metamodel.

Kermeta offers expressions very similar to ObjectConstraint Language (OCL) expressions [24]. In partic-ular, Kermeta includes lexical closures similar to OCL

iterators on collections such as each, collect, select, ordetect. Moreover, Kermeta also allows the direct impor-tation and evaluation of OCL constraints. Pre-conditionsand post-conditions can be defined for operations andinvariants on classes.

Kermeta and its framework remain dedicated to mo-del processing but provide an easy integration with otherlanguages. Kermeta also allows importing Java classes touse services such as file input/output or network commu-nications, which are not available in the Kermeta frame-work. It is also very useful, for instance, to make modelscommunicate with existing Java applications. An otherexample of integration is the extension to Alloy [9] as

presented in Section 4.

2.3 Model Typing

The second key feature of Kermeta is the notion of modeltyping [28]. It consists of a simple extension to object-oriented typing in a model-oriented context. A modeltyping is a strategy for typing models as collections ofinterconnected objects. Model typing permits the detec-tion of type errors early in the design process of modeltransformation. Moreover, it allows more flexible reuse ofmodel transformations across various metamodels, whilepreserving type safety [28]. Type safety is guaranteed by

type conformance, a criterion of substitutability.The notion of model type conformance (or substi-

tutability) has been adapted and extended to modeltypes based on Bruces notion of type groups and typegroup matching [3]. The matching relation, denoted


3/10

Naouel Moha et al.: Evaluation of Kermeta for Solving Graph-based Problems 3

A limitation of the model typing is the name-depen-dent structural conformance. Indeed, only the matchingof variants of model types that have respective objectsinterconnected in the same structural manner and withidentical properties and operations names is possible. Toreduce this limitation, we added two mechanisms to themodel typing: the renaming of properties/operations andthe possibility to match with other objects belonging tothe same inheritance hierarchy. The renaming consists inspecifying a new name for a property or an operation ina specific metamodel to allow the matching. The secondmechanism consists in extending the matching to parentsand children of the current object if this one does notmatch.

The following sections describe the three criteria of Ker-meta using a common pattern. First, we describe the

problem that we propose to solve. Second, we illustrateour approach using a case study. Third, we present someexperiments and results. Finally, we provide a compari-son with other graph-based tools2 followed by a discus-sion.

3 Genericity

In this section, we present generic model transforma-tions in Kermeta based on the notion of model typing.More precisely, we specify generic refactorings for differ-ent metamodels.

3.1 Problem Description

Refactoring has been intensively investigated in the graphand model transformation community over the last fewyears [16]. However, to the best of our knowledge, thereexists no approach to specify metamodel independentgeneric transformations. In current approaches, the spec-ification of refactorings are highly dependent on the meta-model. Our goal is to specify generic model transforma-tions, such as refactorings, that can be reusable on dif-ferent metamodels. For instance, a refactoring such asPull-up Method (i.e., moving methods to the superclass ifthese methods have same signatures on subclasses) could

be generic across any language supporting the object-oriented notion of inheritance (Uml, Ecore, Java).

3.2 Case Study: Refactoring

The refactoring case study of the GraBats08 tool con-test [8] consists of applying three well known refactorings(Encapsulate Field, Move Method, and Pull-up Method) onmodels of Java programs. We generalise this case studyto the problem of specifying generic refactorings for var-ious metamodels. We consider not only models of Javaprograms but also Ecore and Uml models.

2

These tools participate to the tool contest organised for theSTTT Special Section on Graph-based Tool Comparison.

Specification of

Generic Metamodel

GenericMT

1

Specification ofGeneric Refactorings

2

Adaptation with

Target Metamodels

3

TargetMMUML

TargetMMJava

package refactor;

class Refactor

{

operation

encapsulateField(

...

end

}

Refactoring inKermeta

Model UML

Refactored

Model JavaRefactored

Application of

Refactoring

4

Model UMLModel Java

Fig. 2. Approach for the Specification of Generic Refactorings

We illustrate our approach for the Encapsulate Fieldrefactoring. We recall that the Encapsulate Field refac-toring consists of making a public field private and pro-viding accessors [6].

3.3 Approach: Specification of Generic RefactoringsFigure 2 illustrates the four steps of our approach forthe specification of generic refactorings. The first stepconsists in specifying a generic metamodel GenericMT3,which is a super-type of all metamodels. Then, in thesecond step, we specify a refactoring in Kermeta usingGenericMT as the source metamodel. In the third step,the target metamodels such as Uml or Java are adaptedto match with the metamodel GenericMT. The targetmetamodels are then subtypes of GenericMT. In the laststep, the refactoring can then be concretely applied toall models of all target metamodels.

3.3.1 Step 1: Specification of Generic MetamodelOur approach consists first of specifying a lightweightmetamodel that contains the minimum required classesfor specifying refactorings. The generic metamodel, calledGenericMT, given in Figure 3 has been designed to spec-ify refactorings. GenericMT consists of concepts such asclasses, properties, operations, and parameters commonto all metamodels. We use the letter g as a prefix inthe name of each element of the metamodel to denote thefact that they actually play the role of formal generic pa-rameters. The elements contained within the metamodelGenericMT are minimum and sufficient for the specifica-

tion of the three refactorings.

3.3.2 Step 2: Specification of Generic Refactorings

In the second step, we specify refactorings based on thegeneric metamodel. Listing 1 gives a Kermeta code ex-cerpt of the refactoring Encapsulate Field based on themetamodel GenericMT. This code checks (using precon-ditions) if for the specified field a getter accessor doesnot exists or if it exists, it is static. In the body of the op-eration encapsulateField, it creates a getter accessorif it did not exist yet. This code gives an insight into thespecification of refactorings in Kermeta. The interestedreader can refer to the Kermeta syntax in [11].

3 MT refers to Model Type


4/10


5/10


3.4 Experiments and Results

We specify and apply three refactorings suggested inthe GraBats08 tool contest (Encapsulate Field, MoveMethod, and Pull-up Method) on three different meta-

models (Uml, Ecore, and Java Program). The meta-models structurally differ. For example, the Uml meta-model has a hierarchical structure whereas the Java meta-model has a flat structure (i.e., has no containers).

3.5 Comparison with Other Tools

None of the tools that participate to the contest offer thepossibility to specify generic refactorings. However, theyfocus on other criteria. Tools such as Fujaba [7], Pro-gres [32], and VMTS [18] focus on the user interactioncriterion. For example, VMTS provides a source codelike presentation and control flow diagrams for rewriting

rules. In Kermeta, it is also possible to visualize mod-els and metamodels using the Ecore Diagram Editoravailable in the Eclipse Ecore Tools plugin or graph-ical editors generated with GMF (Graphical ModelingFramework) plugin. Jdt2Mdr [19], Progres [32], andFujaba [7] focus on the expressiveness and extensibilitycriteria. Jdt2Mdr transforms Uml models of controlledgraph transformations into executable Java code. Pro-gres provides imperative control structures such as con-ditional branches and iterations. Such control structuresenhance expressiveness in specifying graph transforma-tion rules.

3.6 DiscussionWriting adaptations can be more or less difficult depend-ing on the developers knowledge of the target meta-model. However, after adaptation, the developers canreuse all model transformations written for the genericmetamodel. Conversely, if we write a transformation forthe generic metamodel, we can apply it on all targetmetamodels.

Our approach supports model evolution. Indeed, if ametamodel evolves but still matches with the genericmetamodel, the transformations are still valid for allmodels of the new metamodel.

Our approach contributes to the development of gene-ric tools independent of the metamodelling language. Infuture work, we intend to investigate generic analyses tocompute metrics and detect patterns and anti-patternsor inconsistencies in different metamodels.

4 Extensibility

Model transformations can extend Kermeta to externallanguages and model-oriented tools with functionalitynot readily available in Kermeta. In the following sub-sections, we demonstrate extensibility of Kermeta bypresenting a transformation from metamodels in Ker-

meta to declarative specifications in the formal languageAlloy [9].

Fig. 4. Conference Scheduling Metamodel MMcs


We define a partial model as graph of objects that iseither inconsistent with the structure of its metamodelor does not satisfy some invariants on its metamodel.

The problem we address is the automatic transformationof a partial model into a complete model. The completemodel is a modification of the partial model such that itbecomes consistent with its metamodel and invariants.

We can automate the process of completing a par-tial model using a constraint satisfaction language (CSL)equipped with a solver. We name this process automaticmodel completion. We want to extend Kermeta with thiscapability. The extension transformation must bridgethe gap in expressiveness between Kermeta metamod-els + invariants and the target CSL. This is an issuebecause most CSLs have concise grammars and well-defined declarative semantics as opposed to domain-spe-

cific Kermeta metamodels. Further, we must transformlow-level solutions back from constraint solvers to domain-specific complete models conforming to a Kermeta meta-model.

4.2 Case Study: Conference Scheduling

This case study describes a modelling domain for schedul-ing papers in different sessions of a conference. We struc-ture the concepts of the conference scheduling problemdomain in the metamodel MMcs shown in Figure 4. Themetamodel MMcs consists of a conference with sessions.

Each session contains papers for presentation and a ses-sion chair. Every paper has a presenter. All papers inthe conference must be assigned to time slots while re-specting invariants Ics such as:

1. No simultaneous papers are presented by the sameperson;

2. No presenter is chairing another session at the sametime;

3. Nobody chairs two sessions simultaneously.

A partial model containing objects of classes in MMcsis shown in Figure 5. In the partial model, we do not

assign papers to time slots rendering the invariants Ics

unsatisfied.


6/10


Fig. 5. A Partial Model pcs Without Slot Assignment

Fig. 6. Extensibility Transformation: Kermeta to Alloy for Partial

Model Completion

4.3 Approach: Partial Model Completion

We outline our approach for automatic model comple-tion in Figure 6. Our approach consists of the four fol-lowing steps:

Step 1: The model transformation Kermeta2Alloy:(a) Transforms a source Kermeta metamodel MMs to

anAlloy

model As

. It transforms MMs

classes, theirproperties and implicit constraints (inheritance and prop-erty characteristics such as opposites, composition, unique-ness, and identity) to Alloy signatures and facts. Exam-ple: Listing 5 shows the Alloy signature correspondingto the transformation of the class Paper in MMcs andthe facts generated from implicit constraints in MMcs.

s i g Paper{ p a pe r I D : lone I n t ,

s e s si o n : one S e s s i o n ,p r e s en t e r : one Pe r s o n ,s l o t : one Ti m e S l o t

}

f a c t P a p e r c o n t a i ne r s{ a l l o : P a p er | o in S e s s i o n . p a p e r s }

f a c t S e s s i o n p a p e r s P a p e r s e s s i o n o p p o s it e{ a l l o 1 : S e ss i on , o 2 : P ap er | o2 in o 1 . p a p e r s i m p l i e s o1

in o 2 . s e s s i o n }

Listing 5. Alloy Model for Conference Scheduling

(b) Transforms a source partial model ps to Alloypredicates and appends them to As. Example: The par-tial model in Figure 5 is transformed to the predicateConferenceModel, partially presented in Listing 6. Thepredicate states the number of objects in the partialmodel. Following this, it states values for properties thatwe extract from the partial model. We assign values forall properties available in the partial model includingsessions, papers, presenters, and time slots. What re-

mains unassigned in the predicate are the properties forPaper.slot.

pred Co n f e r e n c e M o d e l{/Number o f o b j e c t s o f e ac h s i g n a t u r e i n P a r t i a l M od el/# Co n f e r e n c e = 1 and # S e s s i o n = 3 and #Paper=9 and#Person=8 and #TimeSlot=6 and/E x i st s s ome o b j e c t o f a s i g n at u r e w i th p r o p e r ti e s o f

v a l ue s i n t he p a r t i a l m od el/some s 1 : S e s s i on , s 2 : S e s s i o n , s 3 : S e s s i o n |

s 1 . s e s s i o n I D = 1 0 and s 2 . s e s s i o n I D = 2 0 and s 3 . s e s s i o n I D=30 and

. . ./ S i m il a r e x p r es s i o ns t ha t d e f i ne o t he r o b j e ct s i n

p a r t i a l m od el /}

Listing 6. Alloy Predicate for pcs

(c) Inserts a run command to solve ps in As. The runcommand states the scopes for the different objects weexpect in the complete model and for integers between27 to 27. It obtains these scopes from the partial model.Example: In the case study we use integers to specifyidentities for sessions, papers, and people. We create theAlloy run command in Listing 7 and insert it into Acs.

The run command solves the predicate ConferenceModel.

run Co n f e r e n c e M o d e l fo r 1 C o n f e re n c e , 6 T i m eS l o t , 9 P a pe r ,3 S es s io n , 8 P er so n , 7 in t

Listing 7. Alloy Run Command to Complete Partial Model

Step 2: We insert Alloy facts for invariants Is tothe metamodel MMs. These invariants are initially spec-ified in OCL. At the moment, we manually transformnatural language or OCL constraints to Alloy facts rep-resenting these invariants. In future, we intend to inte-grate an automatic transformation of a subset of OCL toAlloy facts into Kermeta2Alloy. Example: In the confer-

ence scheduling case study, one of the invariants statesthat a person cannot give simultaneous presentations.We encode both the OCL version and its Alloy fact inListing 8.

/ / No S i m u l a t e no u s P ap er P r e s e n t a t i o n s b y a P e rs o n/ / OCL V e r s i o ncontex t Pe r s o n

in v n o S i m u l t a n e o u s P r e s e n t a t i o n s :s e l f . p r e s e n t s . f o r A l l { p1 , p 2 | p1!=p2 i m p l i e s p 1 . s l o t

! = p2 . s l o t }/ / T r an s f or m ed A l l o y F a ctf a c t n o S i m u l t a n e o u s P r e s e n t a t i o n s{ a l l p : Pe r s o n | a l l p ap er 1 : p . p r e s en t s , p ap er 2 : p . p r e s e n t s

| p a p e r 1 ! = p a p e r 2 i m p l i e s p a p e r1 . s l o t ! = p a p er 2 . s l o t }

Listing 8. OCL Invariant to Alloy Fact

Step 3: We invoke the Alloy API to transform theAlloy source model As to boolean conjunction normalform (CNF). We solve the CNF formula using an off-the-shelf satisfiability (SAT) solver such as ZChaff [14] orMiniSAT [21] to obtain solution(s) (if they exist). Thesesolutions are dumped as Alloy XML files. Example:We present the results of executing the run statement ofListing 7 in Section 4.4.

Step 4: We transform an Alloy XML file represent-ing a solution to a complete model cs using the transfor-mation Alloy2Model. This complete model cs conforms tothe metamodel MMs. Example: In this transformation

low-level relational mappings between atoms is trans-formed to a conference model conforming to MMcs.


7/10


Fig. 7. A Complete Model ccs


We name the Alloy model we obtain for conferencescheduling Acs. We solve Acs to obtain a complete model

ccs with a valid conference schedule. We execute a runcommand to solve the predicate ConferenceModel in Acs.The result of our experiment is an XMI file or a set ofXMI files or complete conference model(s) with validschedule(s). One of the complete models ccs in compre-hensible visual syntax is shown in Figure 7. The red dot-ted arrows from papers to slots illustrate the schedulingsolution.

4.5 Comparison with other Tools

The AGG-EMT [29] tool performs scheduling using triplegraph grammars (TGG). In their approach, a paper isassigned a time slot using TGG rules such that nega-tive application conditions (NACs) are not violated. Thetermination of the transformation process determines ifwe can schedule the conference. The AGG solution isspecific to the scheduling problem while our approach isgeneric and applicable to any Kermeta metamodel trans-formable to Alloy. However, the domain specific TGGrules can make the scheduling process itself more effi-cient than SAT solving.

4.6 Discussion

Our approach is generic and valid for any metamodeland not just for the conference scheduling case study.We present this approach in the context of automaticmodel completion but we have applied this approach ear-lier for model completion in model editors [27], and fortest model generation [26]. There has been other con-tributions to transform high-level languages to Alloysuch as the prototype tool UML2Alloy [1].

Kermeta supports import/export to industry stan-dards for metamodel and metadata specification such asEMF and XSD allowing widespread application of trans-formations written in Kermeta. For instance, the trans-formation to Alloy for any metamodel makes them

amenable to formal analysis, automatic model synthe-sis, and counter-example generation.

5 Performance

In this section, we implement in Kermeta the AntWorldsimulation and evaluate Kermeta performance with re-gard to execution time and memory usage. We also com-

pare and discuss these performance results to those ob-tained with similar approaches based on Eclipse andeventually EMF.


Performance and scalability issues are often seen as achallenge to promote model-driven tools to industry. In-deed, although model-driven applications might offer high-level design abstractions and reduce development timeand efforts, they might also experience scalability prob-lem with respect to performance.

5.2 Case Study: AntWorld

The AntWorld simulation is a case study designed as abenchmark for the comparison of graph-based tools [33].It aims to run tools on a scalable application to eval-uate their performance in terms of execution time andmemory usage.

The case study simulates an ant colony searching forfood around the area of the ant hill located in the centerof a grid. If an ant finds food, it drops pheromones in itsway back home. An ant that brings food into the ant hillleads to the creation of new ants. If an ant searching forfood hits a pheromone, the ant follows the pheromone

path to the food. The simulation is divided in round andevery ant moves during a round.

Figure 8 gives the Ecore metamodel of the AntWorldsimulation. The class Ant represents an ant and containsan attribute mode to determine whether the ant is search-ing for food or moving back to the center. The class Maprepresents the grid of nodes corresponding to the area offood search. A map contains a set of nodes representedby the class GridNode. Among the grid nodes, there aretwo special types of nodes AxisNode and CenterNode.The AxisNode is a node on an axis. The CenterNode cor-responds to the node in the center of the grid. CenterNodeinherits from AxisNode because it is at the intersectionof the two axes. A GridNode is located in a given leveland might be at the border of the map. It also containsa number of food parts and a number of pheromones.

5.3 Approach

Until recently, Kermeta applications were executed onlyin an interpreted mode. To get better performance, wehave developed a Kermeta to Java/EMF compiler thatallows developers to deploy Kermeta applications as Java/ EMF and thus, execute Kermeta applications in a com-piled mode. The Kermeta compiler first transforms a

Kermeta model into anEcore

model and then gener-ates an Eclipse plugin in Java/EMF source code. The


8/10


Fig. 8. AntWorld Metamodel

resulting Java source code may be used both in Eclipseapplication or in Java application (standalone). The Javacompiled version of an Kermeta application typicallyruns faster than in interpreted mode.

5.3.1 Implementation

We implement the AntWorld simulation in Kermeta andin particular, the local search. The transformation rulesof the AntWorld simulation are written as operations,which are sets of expressions that specify the expectedbehavior. The operations are added to the Ecore meta-model of AntWorld by using the aspect-oriented model-ing facilities of Kermeta. Listing 9 describes the opera-tion antEat weaved into the class GridNode. This oper-ation describes the behavior of an ant that arrives at anode containing food. The ant takes a piece of food and

drops 1024 parts of pheromones. This listing shows alsoa reference weaved into the class Map to add a cache ofnodes with pheromones for improving the performanceduring the update of the number of pheromones on anode.

package a n t w o r l d ;

r e q u i r e ke r m e t ar e q u i r e p l a t f o r m : / r e s o u r c e / A n tW o rl d / An tW o rl d . e c o r e

u s i n g a n t w o r l d

a s p e c t c l a s s Map {

r e f e r e n c e g r i d O f Ph e r s : bag GridNode [ 0. . ]

}

a s p e c t c l a s s GridNode {

operation a n t Ea t ( ma p : Map ) i s dos e l f . f o o d : = s e l f . f o o d 1s e l f . p h e r : = s e l f . p h er + 1 0 2 4

/ / T he c u r r en t n od e i s a dd ed t o t h e c a ch e/ / when i t i s i n i t i a l i z e d , i . e . s e l f . p he r == 1 0 24i f s e l f . p h e r == 1 0 2 4 then

m ap . g r i d O f Ph e r s . a d d ( s e l f )end

end

}

Listing 9. Implementation by Aspect of the Reference

gridOfPhers on the Class Map and the Operation antEat on the

Class Ant.


We computed the execution time and memory usage ofthe AntWorld simulation written in Kermeta and exe-

cuted in a compiled mode. These experiments were per-formed on a laptop with an Intel Core 2 CPU T2600,2.16GHz, and 2Go for RAM under Windows XP. Wealso computed these performance tests using the versionof Kermeta on the virtual desktop infrastructure (VDI)submitted for the tool contest to have a fair comparisonwith other VDIs submitted for the tool contest.

The table 1 presents the performance results for ev-ery 25 rounds. It gives the number of grid levels, ants,and nodes with pheromone. It also provides the elapsedtime between every 25 rounds, the cumulative elapsedtime, and the consuming memory. The elapsed time aregiven both on local and the VDI.

The memory usage of the Kermeta runtime contextis constant during the execution and independent of thealgorithm. The memory usage excludes the memory con-sumed for the runtime context (estimated at 5246 kB).

It increases progressively with the number of rounds.

5.5 Comparison with other Tools

We compare the performance results of Kermeta withother tools partipating in the contest. The VMTS tool[17] is the fastest tool among all tools participating tothe tool contest because it seems to be hard coded us-ing C++. VMTS is 53.7 times faster than Kermetaat 500 rounds. We compare Kermeta with other toolsbased on Eclipse or EMF like Viatra2 [31] and EMFTransformation [2]. We execute the simulation using

the VDIs to have a fair comparison. Figure 9 illustratesthe results obtained with Viatra2 and Kermeta. Weobserve that Kermeta is 4.9 times faster than Viatra2at 500 rounds. As regards EMF Transformation, re-sults given during the GraBats08 Workshop showsthat Kermeta is 65 times faster at 100 rounds. In termsof memory usage, Kermeta seems to be the best solutionwith 10,353 kB at 500 rounds compared to VMTS with31,404 kB (that is, a factor of 3) and 90,156 kB for Gr-Gen [4] (a factor of 8.7). Viatra2 consumes 145,000 kBat 350 rounds (results directly provided by Viatra2) incomparison with 4,601 kB in Kermeta (a factor of 31,5).

5.6 Discussion

Viatra2 is not compiled, but interpreted. The use ofa compiled version is very significant in Kermeta andespecially in the case of the AntWorld simulation. Thecompiled version is 50 times faster than the interpretedone.

The measures could have been influenced by externalelements. Indeed, we notice that running programs ornetwork connections can reduce from 10% to 20% thetime executions. Therefore, we compute our performancemeasures by disconnecting all network connections and

closing all programs except Kermeta. However, parasiteprograms may still have influenced the measures.


9/10


10/10


7 Conclusion

In this paper, we have presented Kermeta, an executablemetamodelling language for describing the structure ofmetamodels and their behavior. Kermeta serves as a gen-

eral purpose metamodelling language that helps in solv-ing model- and graph-based problems. We highlightedthe performance, genericity, and extensibility of the Ker-meta language through three cases studies. We showedthat Kermeta allows the specification of generic refactor-ings, the partial model completion, and the efficient ex-ecution of resource consuming algorithms. Future workincludes increasing the repository of refactorings on othermetamodels, automatically transforming a subset of OCLto Alloy, and optimizing the source code generated forimproving the performance.

Acknowledgements. We are grateful to Vincent Mahe and

Didier Vojtisek for their valuable comments on this paperand their contribution on the implementation of the Kermetaworkbench as well as on the solutions of the case studies.

References

1. Kyriakos Anastasakis, Behzad Bordbar, Geri Georg, andIndrakshi Ray. Uml2alloy: A challenging model transfor-mation. In MoDELS, pages 436450, 2007.

2. Enrico Biermann and Claudia Ermel. Antworld simu-lation case study modeled by emf transformation. InProceedings of the 4th International Workshop on Graph-Based Tools (GraBaTs 2008), September 2008.

3. Kim B. Bruce and Joseph Vanderwaart. Semantics-driven language design: Statically type-safe virtual typesin object-oriented languages. Electronic Notes in Theo-retical Computer Science, 20:5075, 1999.

4. Sebastian Buchwald and Moritz Kroll. A grgen.net so-lution of the antworld case for the grabats 2008 contest.In GraBaTs, September 2008.

5. Curtis Clifton, Gary T. Leavens, Craig Chambers, andTodd D. Millstein. Multijava: Modular open classesand symmetric multiple dispatch for java. In Proceed-ings of the 15th International Conference on Object-Oriented Programming, Systems, Languages, and Appli-cations (OOPSLA), pages 130145, 2000.

6. Martin Fowler. Refactoring Improving the Design of

Existing Code. Addison-Wesley, 1

st

edition, June 1999.7. Fujaba. University of paderborn. http://wwwcs.uni-paderborn.de/cs/fujaba/.

8. Berthold Hoffman, Javier Perez, and Tom Mens. A casestudy for program refactoring. In GraBaTs, September2008.

9. Daniel Jackson. Software Abstractions: Logic, Language,and Analysis. The MIT Press, April 2006.

10. Frederic Jouault, Freddy Allilaire, Jean Bezivin, and IvanKurtev. Atl: A model transformation tool. Science ofComputer Programming, 72(1-2):3139, June 2008.

11. Kermeta. http://www.kermeta.org/.12. Gregor Kiczales, John Lamping, Anurag Mendhekar,

Chris Maeda, Cristina Videira Lopes, Jean-Marc Lo-

ingtier, and John Irwin. Aspect-oriented programming.In Proceedings of the 11th European Conference on

Object-Oriented Programming (ECOOP), volume 1241,pages 220242. Springer-Verlag, June 1997.

13. Dimitrios S. Kolovos, Richard F. Paige, and Fiona Po-lack. The epsilon transformation language. In Proceed-ings of the 1st International Conference on Theory and

Practice of Model Transformations (ICMT 2008), vol-ume 5063, pages 4660. Springer, 2008.

14. Y. S. Mahajan and S. Malik Z. Fu. Zchaff2004: An effi-cient sat solver. In Lecture Notes in Computer ScienceSAT 2004 Special Volume LNCS 3542., pages 360375,2004.

15. Tom Mens, Gabi Taentzer, and Olga Runge. AnalysingRefactoring Dependencies using Graph Transformation.Software and Systems Modeling (SoSyM), pages 269285,September 2007.

16. Tom Mens and Tom Tourwe. A survey of software refac-toring. IEEE Transactions on Software Engineering,30(2):126139, February 2004.

17. Tamas Meszaros, Istvan Madari, and Gergely Mezei.

Antworld, vmts. In GraBaTs, September 2008.18. Visual Modeling and Transformation System (VMTS).http://vmts.aut.bme.hu/.

19. Olaf Muliawan, Bart Du Bois, and Dirk Janssens. Refac-toring using jdt2mdr. In GraBaTs, September 2008.

20. Pierre-Alain Muller, Franck Fleurey, and Jean-MarcJezequel. Weaving executability into object-orientedmeta-languages. In MODELS/UML, volume 3713, pages264278, Montego Bay, Jamaica, October 2005. Springer.

21. Niklas Een and Niklas Srensson. Minisat a sat solverwith conflict-clause minimization. In SAT, 2005.

22. OMG. Mof 2.0 core specification. Technical Reportformal/06-01-01, OMG, April 2006. OMG AvailableSpecification.

23. OMG. OMG Home page. http://www.omg.org, 2007.24. OMG. The Object Constraint Language Specification

2.0, OMG Document: ad/03-01-07, 2007.25. OMG. Mof 2.0 query/view/transformation specification.

Specification Version 1.0, Object Management Group,April 2008.

26. Sagar Sen, Benoit Baudry, and Jean-Marie Mottu. Oncombining mullti-formalism knowledge to select testmodels for model transformaion testing. In IEEE Inter-national Conference on Software Testing, Lillehammer,Norway, April 2008.

27. Sagar Sen, Benoit Baudry, and Hans Vangheluwe.Domain-specific model editors with model completion.In In Proceedings of MPM Workshop associated to MoD-ELS07, Nashville, TN, USA, October 2007.

28. Jim Steel and Jean-Marc Jezequel. On model typing.Journal of Software and Systems Modeling (SoSyM),6(4):401414, December 2007.

29. The Attributed Graph Grammar (AGG) System.http://user.cs.tu-berlin.de/ gragra/agg/.

30. Christophe Tombelle and Gilles Vanwormhoudt. Dy-namic and generic manipulation of models: From intro-spection to scripting. In MoDELS, volume 4199, pages395409, 2006.

31. Viatra2. Department of measurement and informa-tion systems, budapest university of technology and eco-nomics. http://www.eclipse.org/gmt/VIATRA2/.

32. Erhard Weinell. Using progres for graph-based programrefactoring. In GraBaTs, September 2008.

33. Albert Zundorf. Antworld. In GraBaTs, September 2008.

evaluation of kermeta to solve graph based problems

Documents