ATLAS transformation language (ATL)
The ATLAS Transformation Language (ATL) is a transformation language that can be used to describe model transformations. In this context, one also speaks of transformation definitions, by which one understands 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 Language
The background of the development of ATL was a call for proposals of 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 couplings of models are supported. A bidirectionality can be realized by the explicit definition of mutual transformation rules. The tool available for ATL is the integrated development environmentADT (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. ADT includes editors and compilers, an ATL virtual machine and other components, and uses the Eclipse Modeling 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 metamodel and a concrete syntax, besides in the sense of ATL also the transformations are regarded as models. Accordingly, three MOF-compliant metamodels such as the source metamodel, the target metamodel and finally the transformation metamodel are also involved in a transformation.
Transformations in ATL are fundamentally unidirectional in nature, as they operate on read-only source models and generate write-only target models from them. Thus in source models during the transformation only navigating, 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 ATL
The 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 as 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 from the source model the target model is generated and condition 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.
The ATL transformation language recognizes several types of transformation rules:
- Matched Rule is a declarative rule and is called implicitly. It is used to filter certain elements of the source model. The filter conditions are described in the form of OCL expressions(Object Constraint Language). 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.
The following code example shows a Called Rule. It must be called explicitly, and the passing of the model elements as parameters must be taken into account. The type name is from the metamodel MMPerson. These elements are bound to the variable p. The source part of the rule is identified by the keyword "to". The target metamodel is called MMPerson, and names its attributes with name and surname. A convenient Eclipse-based development environment, the ATL Development Tools( ATD), exists for implementing ATL. As the figure shows, the ATD provides the following components:
- ATL Compiler to transform ATL code into bytecode,
- ATL Virtual Machine to execute the bytecode generated by the compiler,
- Model Handler Abstraction Layer to translate the virtual machine commands to the model handlers,
- Model Handler providing the API for manipulating model - in drawing, for example, Eclipse Modeling Framework (EMF) or Metadata Repository( MDR),
- Model Repository for persistent storage of models.
The ADT uses the EMF as the basis for serialization, deserialization, navigation and modification of the models. Furthermore, the ADT implements an addition to the Eclipse debugging framework specially adapted to ATL specifications, which enables debugging of the transformation program. Likewise, when the transformation is aborted due to an error, the navigation of the corresponding source and target model is integrated.