ModTransfA Simple Model to Model

Transformation Engine

Cédric Dumoulin

Requirements

Model input: XMI files, ruled by a MOF metamodel XML files, ruled by an XML schema

Easy maintenance of transformation rules To follow metamodel changes

Code generation from model Simple to use Yet available

Proposed Solution

Proposed Solution

A transformation engine takes model(s) and set of rules as input, and produce model(s)

rules

modelmodelmodel model

rules

transformationengine

MM MMbased on based on

instance of instance of

Vocabulary

Model: Graph of related Concepts Concepts defined in metamodel

Metamodel (MM): Graph of classes defining concepts

Transformation Specify how concepts from input MM

are mapped to concepts of output MM

Basic Principle

“Divide and Conquer” Express transformation rule by rule

Rule Specify how one or few input concepts are

transformed to one or few output concepts.

input MM output MMT

r1

r2

r3

r5

r4

Rule A rule is made of:

domains describe input and output concepts can contain complex conditions implicitly define enterGuard, exitGuard, concept creations implicitly define rule parameters

enterGuard to guard the rule execution

actions to populate concept, perform code generation,

do additional computation, … exitGuard

to check the result bind variables

to bind concept and properties to guards and actions

actionslog( 'aMsg' ){language=groovy}(n.startsWith('C')?n=n+'_C':n)

actionslog( 'rule.action' )ownedElement( ownedSrc, ownedDst )

<< rule >>

class<< domain >>

c2 : Class

-name:String=n

-abstract:boolean=abstract

-ownedElement :Collection=ownedDst

<< domain >>

c1 : Class

-name:String=n

-abstract:boolean=abstract

-ownedElement :Collection=ownedSrc

dstUml+

srcUml+

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Rule Example 1 (UML)

Rule Example 1(XML)

Rule Example 2 (UML)Nested Concept

<< domain >>

c1 : Class

-name:String=n

-abstract:boolean=abstract

-ownedElement :Collection=ownedSrc

<< domain >>

c2 : Class

-name:String=n

-abstract:boolean=abstract

-ownedElement :Collection=ownedDst

actionslog( 'rule.action' )ownedElement( ownedSrc, ownedDst )

actionslog( 'aMsg' ){language=groovy}(n.startsWith('C')?n=n+'_C':n)

<< rule >>

class

dstUml+

srcUml+

p1 : Package

-name:String=pName

dependency+0..1

enterGuards{language=groovy}pName = n

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Rule Example 2 (XML)

Transformation

A transformation is made of: involved models declaration rules

topRule called by the engine execute all possible solutions on input domains

rule called by other rules

selectRule set of rules called by other rules the first matching rule is executed

Transformation (UML and XML)

<< transformation >>

uml2uml

-models :String={srcUml, dstUml}

-defaultTargets :String={dstUml}

Created with Poseidon for UML Community Edition. Not for Commercial Use.

How Transformation is Processed

Called with input and output models Specify which models are used as target target models are usually empty models are bind to transformation model names

TopRules are executed input domains are those referring to input models output domains are those referring to output

models

How Rules are Processed

Input bind variables are set Input enter guards are checked

stop if not verified

Output actions are executed Output objects are created and populated

starting from the more nested one (leafs) For a concept, property values are computed first, then the

object is created and populated.

Output post actions are executed Output exit guards are checked

Multiple Call of a Rule

Call of a rule with the same set of parameters Return the same result Only the first call is executed Subsequent calls return the first result multiple properties referencing the same

concept are transformed to references to the same transformed concept

Advanced Features

Extra Properties Definition(ex: stereotypes)

Extra Properties can be defined on model concepts Usage like regular properties Only visible in the transformation

Example definition of the property “stereotypes”

used to check stereotype defined by the model helper

Extra Properties Usage

Code Generation

Associate code templates to rules Templates contain

Replacement places for attributes

Nested rule calls

Use Velocity templates

$c1.packageName

#foreach( $import in $c1.import )import $import;#end

public class ${c1.name} {

// attributes $engine.callRule("attribute“, “src.feature“)

// methods $engine. callRule( “method”, “src.method”)

}

Code Generation: Example

Documentations

Ongoing effort Schema modtransf-v3

XML syntax

XML Rule Syntax:Schema (transformation)

XML Rule Syntax:Schema (domains)

Access To Models

Throw a common API Should be implemented for each Technology:

JMI, XML, EMF, Database, …

Engine

ModelHelper

+createInstance(type:String):Object

+deleteInstance(bean:Object):void

+setProperty(bean:Object,name:String,value:Object):void

+getProperty(bean:Object,name:String):Object

+isInstanceOf(bean:Object,type:String):boolean

+allOfType(type:String):Collection

+isOwner(bean:Object):boolean

+getNativeModel():Object

Model

model+

MetaModelmetamodel+*

modelHelper+

*

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Engine takes graphs of objects as models Model loading is not part of the engine

Can use JMI, JAXB, Castor, DOM, …

From MOF metamodel: Use JMI

From XML schema Use JAXB, Castor

Models Kind

XMImodel

MOFmetamodel

JMI classes

JMI

import/export

generate

XMLmodel

schema

Java classes

JAXB

import/export

generate

Future features

Aspect like property declaration enable declaration of extra properties and methods on

model concepts Structure and classes declaration

To create data needed during transformation dependsOn

Allows specification of rule dependencies Inheritance Key declarations

To lookup created concepts by specified properties …

Questions and Discussion