Runtime Interoperability of Transformation Engines 1150 1150 Massimo Tisi AtlanMod Nantes, France Massimo.Tisi@inria.fr
Runtime Interoperability of Transformation Engines 1150 1150 Massimo Tisi AtlanMod Nantes, France Massimo.Tisi@inria.fr
An Identity Crisis 1150 1150 Massimo Tisi AtlanMod Nantes, France Massimo.Tisi@inria.fr
ATL GRoundTram
ATL EMF Model EMF Model UnQL Graph Graph
ATL EMF Model EMF Model ATL2UnQL EMF2Graph UnQL Graph Graph
ATL update EMF Model EMF Model ATL2UnQL update EMF2Graph propagation UnQL Graph Graph
ATL EMF Model EMF Model ATL2? EMF2? ? ? ? CSP ASM Maude ...
TGG QVT XSLT … ? ? ? ?2UnQL ?2Graph UnQL Graph Graph
L1 SM1 TM1 f1 l m m' L2 f2 SM2 TM2
In an ideal world... L1 SM1 TM1 f1 m m L2 f2 SM2 TM2
In an ideal world... L1 SM1 TM1 f1 m m L2 f2 SM2 TM2 ...but we are not in an ideal world :(
Realistic Hypothesis 1 m is injective from abstract to concrete no information loss all information from SM1 is encoded in SM2 good bidirectionality properties with m' at least get-put?
Realistic Hypothesis 2 l is not injective Not all the language features are translated Why? 1. not possible -> very different semantics of L1 and L2 2. possible but we don't want to: e.g., we just want to translate the bidirectionalizable part 3. possible but we just don't have time Result: f1 is “semantically different” from f2 TM2 != m(TM1)
Partial translation If we allow any translation l, we could end up with a TM2 completely unrelated with TM1 We are interested in “approximations by defect” of a perfect translation We say that l is a partial translation of a model transformation when it is always guaranteed that: TM2 is part-of m(TM1) (or for graphs: TM2 is a subgraph of m(TM1))
The problem L1 SM1 TM1 f1 l m m' ? ? L2 f2 SM2 TM2 To say more we need to go down to the model-element level
Class models and Relational models type attrs Family: Class family : Attribute Person: Class attrs type attrs members: Attribute name: Attribute firstName: Attribute multivalued = true type type String: Datatype type cols Family: Table family : Column Person: Table cols cols name: Column firstName: Column type type String: Type
rule Class2Table { Class2Relational.atl from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr type attrs ) Family: Class family : Attribute Person: Class } attrs type attrs members: Attribute name: Attribute firstName: Attribute multivalued = true Trace Link type type String: Datatype type cols Family: Table family : Column Person: Table cols cols name: Column firstName: Column type type String: Type
rule Class2Table { Class2Relational.atl from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr type attrs ) Family: Class family : Attribute Person: Class } attrs type attrs members: Attribute name: Attribute firstName: Attribute multivalued = true Trace Link type type String: Datatype type cols Family: Table family : Column Person: Table cols cols name: Column firstName: Column rule Attribute2Column { type type from String: Type s : ClassDiagram!Attribute ( not s.multiValued guard ) to Guards and bindings are OCL t : Relational!Column ( expressions over the source model name <- s.name, type <- s.type bindings ) }
Class2Relational.atl module Class2Relational; create OUT : Relational from IN : ClassDiagram; rule Datatype2Type { from s : ClassDiagram!DataType to t : Relational!Type ( But there is much more: name <- s.name ) } Matching multiple elements rule Class2Table { per rule from s : ClassDiagram!Class Generating multiple to t : Relational!Table ( elements per rule name <- s.name, col <- s.attr OCL functions (helpers) ) } Explicit inter-rule activation rule Attribute2Column { (lazy rules) from s : ClassDiagram!Attribute ( Imperative blocks not s.multiValued ) to t : Relational!Column ( name <- s.name, type <- s.type ) }
Trace links Source Model Destination Model rule1 t A G u I rule2 v B C J t H rule3 E t K
Trace links Source Model Destination Model rule1 t A G u I rule2 v B C J t H rule3 E t K
Trace links Source Model Destination Model rule1 t A G u I rule2 v B C J t H rule3 E t K J?
J: who am I? J
1. Identity by trace links rule1 t A G u I rule2 v B C J t H rule3 E t K J!
But: Not a clear 1-to-1 relationship in ATL2UnQL Even if we modify ATL2UnQL we don't want to modify UnQL to UnCAL ATL EMF Model EMF Model ATL2UnQL EMF2Graph UnQL Graph Graph UnCAL
2. Identity by identifiers Modeling frameworks have a notion of model-element identity E.g., in EMF: Users can set an explicit ID for each model element It is serialized as an XML ID when the model is serialized to XMI/XML Otherwise the system uses an implicit ID the Java object ID while it is in memory an XMI ID when the model is serialized to XMI quite similar to XPath e.g., “/0/@elements.3/@inPattern/@elements.0” Users are encouraged to abstract from IDs
2a. Emulating identifiers rule1 t A G u I rule2 v B C J ID J =“/0/@elements.1” t H rule3 E t K J! /0/@elements.1
But: Implicit identifiers depend on several factors that cannot be easily emulated Non-determinism in the serialization format Changes among EMF versions Structure of the file e.g., element ordering in non-ordered references Non-determinism in the serializer Non-determinism in the transformation language Changes among ATL versions or ATL implementations Because of the partial translation!
2b. “Lifting” Identity ATL EMF Model IDFIER EMF Model ATL EMF Model explicit IDs ATL2UnQL EMF2Graph UnQL Graph Graph
The IDFIER HOT rule Class2Table { from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr ) } rule Class2Table { from s : ClassDiagram!Class to t : Relational!Table ( __xmiID__ <- 'IN'.concat(s.__xmiID__.concat('.Class2Table.t')), name <- s.name, col <- s.attr ) }
rule1 t A G u I rule2 v B C J ID J =“IN.A.rule1.v” t H rule3 E t K J! IN.A.rule1.v
“Lifting” identity The logic for identification is “lifted” from an implicit semantics in the modeling framework to an explicit transformation rule that is composed with the given ATL transformation
Benefits We keep element identity in TM1 and TM2 With no changes to the two transformation engines With no changes to the translator l that is totally agnostic w.r.t the ID format and goes on working if we change it Transparently for a tool that uses SM1/L1/TM1 But not for a tool that uses SM2/L2/TM2 Supporting partial translations
Future work A good formalization Some category theory? Complete analysis of identification methods e.g., adding structural comparison Application to runtime ATL-GRoundTram interaction
Thanks Massimo Tisi - 36/36
Recommend
More recommend
