Download
1 / 10
120 likes | 347 Views
Overview of ATL and ETL. ( Jouault and Kurtev 2006, ‘Transforming Models with ATL’, Proc. MODELS 2005 Workshops , LNCS, vol. 3844, pp. 128-138. Kolovos et al. 2006, ‘The Epsilon Object Language (EOL)’, Proc. ECMDA-FA 2006 , LNCS, vol. 4066, pp. 128-142.
E N D
Overview of ATL and ETL (Jouault and Kurtev2006, ‘Transforming Models with ATL’, Proc. MODELS 2005 Workshops, LNCS, vol. 3844, pp. 128-138. Kolovos et al. 2006, ‘The Epsilon Object Language (EOL)’, Proc. ECMDA-FA 2006, LNCS, vol. 4066, pp. 128-142. Kolovos et al. 2008, ‘The Epsilon Transformation Language’, Proc. ICMT 2008, LNCS, vol. 5063, pp. 46-60.) Presented by Matt Selway
Background of ATL • Hybrid declarative/imperative DSL for writing model-to-model transformations • Started around 2004/5 by the ATLAS Group (later became AtlanMod) INRIA, University of Nantes • Involved in the ModelWare IST European Project • Builds on OCL, was submitted as a candidate for the OMG’s QVT standard • Forms part of the ATLAS Model Management Architecture (AMMA), which supports wider model management such as model merging, comparison, etc.
Background of ETL • Hybrid declarative/imperative DSL for writing model-to-model transformations • Started end of 2005 at Dpt. Comp. Science, University of York; also involved in the ModelWare project • Part of the Epsilon framework, which supports general model management • Task specific language built on EOL; an OCL like language for model navigation and modification • Other Epsilon languages include: EVL, EGL, EWL, ECL, EML, and Flock
Execution Model (Both) • Execute pre-processing (imperative) • Match non-lazy (non-abstract) rules and generate target model elements (declarative) • Execute the rule bodies (in the context of the match and created model elements) (declarative/imperative) • Execute post-processing (imperative)
Syntax Comparison (Rule Structure) ATL Rules ETL Rules (@abstract)? (@lazy)? (@greedy)? (@primary)? rule<name> transform <inVar>:<inType> to (<outVar>:<outType> (, <outVar>:<outType>)* (extends (<ruleName>,)*<ruleName>)? { (guard(:expression)|({statement+}))? statement+ } [abstract]? [[unique]? lazy]? rule <name> [extends <ruleName>]? { from <inVar> : <inType> [in<modelName>]? [( <condition> )]? [using { <var> : <var_type> = <init_exp>; [<var> : <var_type> = <init_exp>;]* }]? to <outVar> : <outType> [in<modelName>]? ( bindings )[, <outVar> : <outType> [in<modelName>]? ( binding )]* [do { statement+ }]? }
Syntax Comparison (Concrete Example) ATL ETL rule Class2Table transform class : OO!Class to table : DB!Table, pkColumn : DB!Column { guard : class.specialises.isUndefined() table.name = class.name; table.columns.add(pkColumn); table.primaryKeys.add(pkColumn); pkColumn.name = class.name + ‘_pk’; pkColumn.type = ‘INT’; } rule SingleValuedAttribute2Column transform attribute : OO!Class to column : DB!Column { guard : notattribute.isMany column.name = attribute.name; column.table ::= attribute.owner; column.type = attribute.type; } rule Class2Table { from class : OO!Class( class.specialises.isUndefined()) to table : DB!Table ( name <- class.name, columns <- Sequence{pkColumn}, primaryKeys <- Sequence{pkColumn} ), pkColumn : DB!Column ( name <- class.name + ‘_pk’, type <- ‘INT’ ) } rule SingleValuedAttribute2Column from attribute : OO!Attribute ( notattribute.isMany) to column : DB!Column ( name <- attribute.name, table <- attribute.owner, type <- attribute.type ) }
Pragmatics • Used both ATL and ETL, overall found ETL easier to use (although I was using ATL quite a while ago, so it may have improved since then) • Couldn’t get ATL superimposition to work (not sure if they have fixed it yet) • Transforming meta-models using ATL is finicky, ETL couldn’t care less; it treats all kinds of models much more uniformly • Using multiple models in ATL was a bit of pain, easier to merge all the (meta-)models into a single one to make life easier • ATL almost forces you to do things declaratively, a number of its imperative features have awkward limitations; therefore, in complex transformations you end up doing weird workarounds • ETL makes it much easier to use imperative constructs, sometimes too easy, but found that complex transformations need them • ETL’s use of ‘=‘ for primitive types and ‘::=‘ for automatic resolution of model types can be a pain, if you use the wrong one you don’t get an error, just an empty result.
