The ATLAS Transformation Language (ATL) is a transformation language that can be used to describe model transformations. In this context, it is also referred to as transformation definitions, which is a set of transformation rules that describe how a source model is transformed into a target model. ATL is part of the ATLAS Model Management Architecture (AMMA), whose other projects are ATLAS Model Weaver (AMW), ATLAS Mega-Model Management (AM3), and ATLAS Technical Projectors (ATP). Originally, the ATLAS architecture was developed by the research groups INRIA (Institut National de Recherche en Informatique et en Automatique) at the University of Nantes and LINA (Laboratoire d'Infomatique de Nantes-Atlantique).
The Development of ATLAS TRansformation LanguageThe background of the development of ATL was a call for proposals from the Object Management Group (OMG) with respect to a general programming language for model and code transformation as described in the OMG RFP of the OMG. In addition to the transformation of MOF-compliant models, the specification of ATL also includes transformations whose basis is, for example, databases or XML documents. ATL is also referred to as a hybrid transformation language whose rules are unidirectional in all cases. Furthermore, no coupling of models is supported. Bidirectionality can be realized by explicitly defining mutual transformation rules. The tool available for ATL is the integrated development environment ADT (ATL Development Tools), which is based on an Eclipseplug-in and is also part of the Generative Model Transformer (GMT) project of the Eclipse Foundation. The ADT includes editors and compilers, an ATL Virtual Machine and other components, and uses the Eclipse Modelling Framework (EMF) to process models in terms of serialization, deserialization, navigation and modification.
ATL is counted among the hybrid transformation methods/techniques because its transformation rules can be formulated in both imperative and declarative styles. Primarily, however, the declarative definition of transformation rules is applied, while the definition of imperative language constructs is intended for more complex transformation rules. ATL defines both a meta-model and a concrete syntax. Moreover, in the sense of ATL, the transformations themselves are also considered models. Accordingly, a transformation also involves three MOF-compliant metamodels such as the source metamodel, the target metamodel, and finally the transformation metamodel.
Transformations in ATL are fundamentally unidirectional in nature as they operate on read-only source models and generate write-only target models from them. This means that source models can only be navigated in during the transformation, but no elements can be modified. Similarly, it is not possible to navigate in the target models, but changes can be made. Bidirectional rules can also be specified - in the form of pairs of unidirectional transformation rules for each direction.
Transformation definitions in ATLThe central element of a transformation definition in ATL is the so-called module, which includes a mandatory header, import statements, helper operations and the rules. The header defines the name of the transformation - also called the model name - and specifies its source and target metamodels. The import statement can be used to import ATL libraries or other modules. Helper operations essentially correspond to methods known from other programming languages and used here as helpers within the rules. Helpers are thus called in a specific context on an instance of a metaclass. In addition, global variables and functions can be defined. The rules describe how the target model is created from the source model and require a certain structure:
- InPatterns specify the element of the source metamodel,
- OutPatterns specify the elements of the target metamodel,
- Actions blocks indicate a sequence of instructions that are executed after the Out pattern is created.
- Matched Rule is a declarative rule and is called implicitly. This is used to filter certain elements of the source model. The filter conditions are described in terms ofObject Constraint Language (OCL) expressions. The part of the rule that refers to the target model is then used to generate the corresponding elements of the target model,
- Lazy Rules must be called explicitly,
- Called Rules, like Matched Rules, can generate instances of the target model but must be called explicitly.
- ATL Compiler to transform ATL code into bytecode,
- ATL Virtual Machine to execute the bytecode generated by the compiler,
- Model Handler AbstractionLayer to translate the virtual machine commands to the model handlers,
- Model Handler providing the API for manipulating model - in drawing for example Eclipse Modelling Framework (EMF) or Metadata Repository (MDR),
- Model Repository for persistent storage of models.