lintrap : primitive operators for the execution of model transformations with lintra

LinTraP: Primitive Operators for the Execution of

Model Transformationswith LinTra

Loli Burgueño1, Eugene Syriani2, Manuel Wimmer3,Jeff Gray2 and Antonio Vallecillo1

1 Atenea Research Group, University of Malaga2 Software Engineering Research Group, University of Alabama3 Business Informatics Group, Vienna University of Technology

Model-Driven Engineering

Hence the problems being addressed using MDE approaches are increasingly complex:

From “FamiliesToPersons”to DNA Models

From small databases in a PC to Big Data in the Cloud

BigMDE 2014LinTraP: Primitive Operators for the Execution of MTs with LinTra 3

Both because of themodel sizeand the transformation logic

Model-Driven Engineering

The current tools we are using do not even deal with medium-size models that do not fit into the RAM memory of a single machine


MDE tools and mechanisms are lagging behindDo not scale wellDo not support concurrencyDo not support distributionEtc.

They are not up to the current requirements from real industrial practices

Motivation

In practice, we need to

Store and handle models with millions of instancesTransform these models in reasonable amount of timeMake better use of our current IT infrastructure

Networks of distributed computersMulti-core machines


LinTra

LinTra [Burgueno 2013, Burgueno et al. 2013]

Brings concurrency and distribution into the Model Transformations areaAddresses the problem of storing and handling large and very large models (memory allocation, execution times)

7BigMDE 2014LinTraP: Primitive Operators for the Execution of MTs with LinTra

Proposal:Make use of Linda, a mature and widely used Coordination language for concurrent and distributed programmingIt uses the “blackboard” approach, based on “shared” tuple spaces

Every tuple space can be distributed over sets of machines, in a user-transparent way

LindaLinda: coordination language for parallel processes


Blackboard(tuple space)

Tuple(“Bye”, “World”)

read(?, “World”)

write(“Bye”, “World”)

write(25, “dollars”)

Tuple(25, “dollars”)

LinTra: Architecture

Mature Linda implementations availableFor different general purpose languages (GPL)GPL are too low level languages to write MTsWe will place another language (MTL) on top that compiles to GPLs


HMTL(high-level MTL)

LMTL(low-level MTL: Java)

Linda Blackboard

Architecture (coarse-grained)



HMTL(high-level MT)

LMTL(low-level MT: Java)

Linda Blackboard

…

Linda Blackboard

Interface

Adapter Adapter

implements

GigaSpaces Coherence HazelCast

Adapter

No common interface shared by all Linda implementations but we want the technology to be independent of our language

we build an interface to abstract the blackboard accessit deals with the synchronization mechanisms


LMTL: jLinTraOut-place MTsLMTL for MT execution/engineMTs written in Java

Representation of metamodels and models in Java Traceability

Master-SlaveMaster


HMTL(high-level MT)


Linda Blackboard

partitions the input modelorganizes the tasks to be executed by the slaves

Slavesread (a subset of) the input model from the Blackboardtransform the submodel assignedwrite the output model

LinTra: Performance

Ubuntu 12.04 64 bits11.7 Gb of RAM16 cores of 2.67GHz



HMTLExisting MTL compile to LinTraPExisting MTs or MTs written in existing languages can be executed with LinTra


HMTL(high-level MT)


Linda Blackboard

HMTL

…

LinTraP

compiles to

ATL QVT-O ETL

ATL-2-LinTraP QVTO-2-LinTraP ETL-2-LinTraP

LinTraP

LinTraP

LinTraP: collection of minimal, yet sufficient, primitive operators that can be composed to (re-)construct any out-place and unidirectional MTL


These primitive operators encapsulate the LinTra implementation code that makes the parallel and distributed execution possible

Refactor the code to make it reusable for the compilations from HMTL to LMTL

An abstraction of the implementation details of the general-purpose language in which LinTra is implemented

LinTraP

Primitives (continuation of [Syriani et al. 2013])

For MT setupPartitionCreator

For MT executionComposerCreatorFinderTracerCondCheckerDeclarerAssigner


LinTraPPrimitives for the Concurrent Platform

PartitionCreatorModel entities are independent from each otherSize of every partition is requiredPossibility of specifying which elements belong to each partition


myModel

e.g.: PartitionCreator(myModel, ‘’, 3)

p1

p2

p3p4

Syntax:PartitionCreator(input : Model, OE : OclExpression, maxSize : Integer)

LinTraPPrimitives for the Concurrent Platform

PartitionCreatorModel entities are independent from each otherSize of every partition is requiredPossibility of specifying which elements belong to each partitionSyntax:

PartitionCreator(input : Model, OE : OclExpression, maxSize : Integer)

e.g.: PartitionCreator(myModel,‘Figure.allInstances->select(f | f.isSquare )’, 2)


myModel

The purpose of OE is to give the user the possibility to optimize the MT execution.

p3

p1

p2

LinTraPPrimitives for the MTL

TracerThe Tracer provides access to the trace model needed by out-place MT engines for linking the entities in the output model

Given an input entity or set of entities that match the pre-condition of a rule, the traces give access to the entities that were created in the post-condition, and vice versa.


1tr = 2

2 8

circ=8

20

Tracer(Triangle2Circle, 2, circleCreator)

Syntax:Tracer (composer : Composer,

e : [ Entity | Collection(Entity)],creatorName : String ) : Collection(Entity)

LinTraP

Primitives for the MTL

CondCheckerallows the querying of the input model in the Blackboard with an OCL expression that evaluates to a boolean valueSyntax:

CondChecker(expr : OclExpression) : Boolean


Finderallows the retrieval of elements from the Blackboard that satisfy a constraintSyntax:

Finder(expr : OclExpression) : Collection(Entity)

LinTra Transformation Process


Case Study:Activity Diagrams to Petri Nets [Syriani & Ergin 2012]


Composer ActNode { if (CondChecker(e.oclIsTypeOf(ActivityNode))) { Creator(Transition, {[name, e.name], [net, pNet]}, 't1') Creator(Arc, {[transition, Tracer(ActNode, e, 't1')], [place, Tracer(ActNode, e, 'p')], [toPlace, true], [net, pNet]}) Creator(Place, {[name, e.name], [net, pNet], [token, 0]}, 'p') Creator(Arc, {[transition, Tracer(ActNode, e, 't2')], [place,Tracer (ActNode, e, 'p')], [toPlace, false], [net, pNet]}) Creator(Transition, {[name, e.name], [net, pNet]}, 't2') }}



Conclusions and Future Work

Next steps


HMTL(high-level MT)


Linda Blackboard

LinTraPComplete implementation of the primitives

Create compilers

Annotations

New MTLFurther benchmarking

References

[Burgueno 2013] L. Burgueño. Concurrent Model Transformations based on Linda. Doctoral Symposium @ MODELS, pages 9-16, 2013.

[Burgueno et al. 2013] L. Burgueño, J. Troya, M. Wimmer, and A. Vallecillo. On the Concurrent Execution of Model Transformations with Linda. In BigMDE Workshop @STAF, 2013.

[Syriani & Ergin 2012] E. Syriani and H. Ergin. Operational semantics of UML activity diagram: An application in project management. In Proceedings of MoDRE Workshop @ RE, pages 1-8, 2012.

[Syriani et al. 2013] E. Syriani, H. Vangheluwe, and B. LaShomb. T-core: a framework for custom-built model transformation engines. Software & Systems Modeling, pages 1-29, 2013.


LinTraP: Primitive Operators for the Execution of

Model Transformationswith LinTra

Loli Burgueño1, Eugene Syriani2, Manuel Wimmer3,Jeff Gray2 and Antonio Vallecillo1

1 Atenea Research Group, University of Málaga2 Software Engineering Research Group, University of Alabama3 Business Informatics Group, Vienna University of Technology

Thanks!

Metamodels and Models representation

MMs are represented by means of Java classes

Models are composed of class instances (objects)


package classMM;

public class Attribute extends NamedElt {

String id;Boolean multivalued;String typeID; Boolean typeIsComposed = false;String ownerID; Boolean ownerIsComposed = false;

public Attribute (String id, String name, Boolean multiValued, String ownerId, String typeId){ super(name); this.id = id; this.multivalued = multiValued; this.ownerID = ownerId; this.typeID = typeId; }

public String getId() { return id;}

public void setId(String id) { this.id = id;}

public Boolean getMultivalued() { return multivalued;}

public void setMultivalued(Boolean multivalued) { this.multivalued = multivalued;}

RelationshipsTraces

F : Stringn Stringn


Why does every model element need an ID?


DataType

id = “1”

DataType

id = “2”

Attribute

id = “3”

Type

id = “1_Dt2T”

Type

id = “2_Dt2T”Column

id = “3_A2C”

F

F

F


Why to use IDs?Efficiency


Attribute

id = “2”

Column

id = “2_A2C”

F

Class

id =“3”att ={“1”, “2”}

Column

id = “3_C2C.1”

Table

id = “3_C2C.2”

FF

Attribute

id = “1”

Column

id = “1_A2C”

F

Table

id = “3_C2C.2”key= {“3_C2C.1”}

col= {“1_A2C”,“2_A2C”}

FFF

ATL

Model TransformationOut-place transformation

Blackboard split in different areasOne area per each input modelOne area per each output modelOne area reserved to internal transformation purposes


MT Execution config.: Master/Slave+Shared MemoryMaster organizes the work specifying the model portions to be transform at once by a thread and puts them in one specific zone of the tuple spaceEvery slave access to that specific zone takes one piece of work, and transforms the elements the piece of work specifiesNeeded synchonization mechanisms: a semaphore

Model TransformationTransformation execution: Master/Slave+Shared Memory


Master

?

NotifySlaves

Serialization

Model transformation


type.name := datatype.name

Model transformation


WorkExcerpt we = lookForWork(); while (we!=null){

Collection<Objects> in = retrieveElements(we, srcTS); Collection<Objects> out = (new Class2Relational()).transforms(in); trgTS.putAll(out); we = lookForWork(); }

Collection<Object> out = new ...for(Object o : in) { if(o instanceof Class){ ruleClass2Table((Class)o, out); } else if (o instanceof DataType){ ruleDataType2Type((DataType)o, out); } else if...}return out;

Type t = new Type(f(dt.getId()), dt.getName());out.add(t);

type.name := datatype.name

Overview


Input Models

Input Model

Output Models• XMI, data flow…• In a single machine, distributed

Output Model• Blackboard format• In the cloud

Transfo• ATL, QVT,

own language, …

Transfo (java)

Thread N

Thread 1

Thread 2 …

• XMI, data flow, …• In a single

machine, distributed

• Blackboard format

• In the cloud

Input Metamodels• Ecore, KM3, ...

Output Metamodels• Ecore, KM3, ...

conforms to conforms to

Input Metamodels

(Java)

Output Metamodels

(Java)

conforms to conforms to

Linda Blackboard Implementation

HM

TL

LM

TL

Lin

da

LinTraP


Composerallows the grouping of a combination of primitivesSyntax:

Composer <composerName> { <combination of primitives> }


LinTraP


Creatorcreates an entity given its data type and its features (attributes and bindings) and writes it in the BlackboardSyntax

Creator(type : Factory,features : Dictionary<feature : String,

value: [OclDataType | Entity ]>)

Creator(type : Factory,features : Dictionary<feature : String,

value: [OclDataType | Entity ]>,name: String)

e.g.: Creator(Family, {[name, ‘Smith’]}, ‘f1’)


LinTraP


Declarerallows to create a global variable

that can be accessed by its name from any other primitivethat is accessed by all the Slaves involved in the transformation process

Syntax:Declarer(type : [OclDataType | Entity], name : String)


LinTraP


Assignersets the value of a variable defined by a DeclarerSyntax:

Assigner(varName : String, value : [OclDataType | Entity | Creator])

if value : Creatorthe element is stored in the Blackboardthe variable points to itevery time the variable is updated, the corresponding value in the Blackboard is overwritten

if value : [ OclDataType | Entity ]the variable is stored in memory and accessed while the MT is executedit is not a persistent value in the Blackboard


Integration with LinTra

LinTra class diagram metamodel


Integration with LinTra

MT setup

Extract rule schedulingAll rules belonging to the same rule layer can be executed in parallelAll rules in one layer must have terminated before rules in a subsequent layer can begin

Compile MT to LinTraP


Case Study:Activity Diagrams to Petri Nets

Composer Signal { if (CondChecker(e.oclIsTypeOf(SignalNode))) Creator(Transition, {[name, e.name], [net, pNet]}, 't') Creator(Arc, {[transition, Tracer(Signal, e, 't')], [place, Tracer(Signal, e, 'p')], [toPlace, true], [net, pNet]}) Creator(Place, {[name, e.name], [net, pNet]}, 'p')}


Case Study:Activity Diagrams to Petri Nets

Composer MatchSignals { if (CondChecker(e.oclIsTypeOf(SignalNode))) for(a in Finder(‘AcceptSignalNode.allInstances->select(as|

e.activityDiag = as.activityDiag and e.signalId = a.signalId’) Creator (Arc, {[place, Tracer (Signal, e, 'p')], [transition, Tracer (MatchSignals, {e, a}, 't')], [toPlace, false ], [net, pNet]}) Creator (Transition, {[name, e.name+'-'+a.name], [net, pNet]}, 't') Creator (Arc, {[place, Tracer (AcceptSignal, e, 'p')], [transition, Tracer (MatchSignals, {e, a}, 't')], [toPlace, true ], [net, pNet]})}


lintrap : primitive operators for the execution of model transformations with lintra

Documents

execution of mts

execution times

original lintrap

handle models

modeldriven engineeringmde

modeldriven engineeringhence

model transformations

large models memory