Runtime Interoperability of Transformation Engines 1150 1150 - - PowerPoint PPT Presentation
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
1150 1150
1150 1150
1150 1150
ATL GRoundTram
ATL UnQL EMF Model Graph EMF Model Graph
ATL UnQL EMF Model Graph EMF Model Graph ATL2UnQL EMF2Graph
ATL UnQL EMF Model Graph EMF Model Graph ATL2UnQL EMF2Graph update update propagation
ATL ? EMF Model ? EMF Model ? ATL2? EMF2?
CSP ASM Maude ...
? UnQL ? Graph ? Graph ?2UnQL ?2Graph
TGG QVT XSLT …
L1 L2 SM1 SM2 TM1 TM2 l m m' f1 f2
L1 L2 SM1 SM2 TM1 TM2 m f1 f2 m
L1 L2 SM1 SM2 TM1 TM2 m f1 f2 m
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?
l is not injective
Not all the language features are translated Why?
e.g., we just want to translate the bidirectionalizable part
Result: f1 is “semantically different” from f2
TM2 != m(TM1)
If we allow any translation l, we could end up
We are interested in “approximations by defect”
We say that l is a partial translation of a model
TM2 is part-of m(TM1) (or for graphs: TM2 is a subgraph of m(TM1))
L1 L2 SM1 SM2 TM1 TM2 l m m' f1 f2 ? ?
To say more we need to go down to the model-element level
Family: Class name: Attribute attrs members: Attribute multivalued = true Person: Class String: Datatype firstName: Attribute attrs type type type family : Attribute attrs type Family: Table name: Column cols Person: Table String: Type firstName: Column cols type type family : Column cols type
Family: Class name: Attribute attrs members: Attribute multivalued = true Person: Class String: Datatype firstName: Attribute attrs type type type family : Attribute attrs type Family: Table name: Column cols Person: Table String: Type firstName: Column cols type type family : Column cols type
rule Class2Table { from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr ) }
Trace Link
Family: Class name: Attribute attrs members: Attribute multivalued = true Person: Class String: Datatype firstName: Attribute attrs type type type family : Attribute attrs type Family: Table name: Column cols Person: Table String: Type firstName: Column cols type type family : Column cols type
rule Class2Table { from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr ) }
Trace Link
rule Attribute2Column { from s : ClassDiagram!Attribute ( not s.multiValued ) to t : Relational!Column ( name <- s.name, type <- s.type ) }
guard bindings Guards and bindings are OCL expressions over the source model
module Class2Relational; create OUT : Relational from IN : ClassDiagram; rule Datatype2Type { from s : ClassDiagram!DataType to t : Relational!Type ( name <- s.name ) } rule Attribute2Column { from s : ClassDiagram!Attribute ( not s.multiValued ) to t : Relational!Column ( name <- s.name, type <- s.type ) } rule Class2Table { from s : ClassDiagram!Class to t : Relational!Table ( name <- s.name, col <- s.attr ) }
But there is much more:
Matching multiple elements
Generating multiple
OCL functions (helpers) Explicit inter-rule activation
Imperative blocks
A H I J G E C B K rule1 rule2 rule3 Source Model Destination Model t u v t t
A H I J G E C B K rule1 rule2 rule3 Source Model Destination Model t u v t t
A H I J G E C B K rule1 rule2 rule3 Source Model Destination Model t u v t t
A H I J G E C B K rule1 rule2 rule3 t u v t t
ATL UnQL EMF Model Graph EMF Model Graph ATL2UnQL EMF2Graph UnCAL
But:
Not a clear 1-to-1 relationship in ATL2UnQL Even if we modify ATL2UnQL we don't want to modify UnQL to UnCAL
Modeling frameworks have a notion of
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
A H I J G E C B K rule1 rule2 rule3 t u v t t IDJ=“/0/@elements.1” /0/@elements.1
But:
Implicit identifiers depend on several factors that
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!
ATL UnQL EMF Model Graph EMF Model explicit IDs Graph ATL2UnQL EMF2Graph
ATL EMF Model IDFIER
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 ) }
A H I J G E C B K rule1 rule2 rule3 t u v t t IDJ=“IN.A.rule1.v” IN.A.rule1.v
The logic for identification is “lifted”
from an implicit semantics in the modeling
to an explicit transformation rule that is composed with the given ATL transformation
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
A good formalization
Some category theory?
Complete analysis of identification methods
e.g., adding structural comparison
Application to runtime ATL-GRoundTram
Massimo Tisi - 36/36