INSTITUT DE RECHERCHE EN INFORMATIQUE DE NANTES

— Bases de Donnees —

RESEARCH REPORT

No 03.08

09/09/2003

The ATLTransformation-based Model

Management Framework

Jean Bezivin�

, Erwan Breton�, Gregoire Dupe

�,

Patrick Valduriez�

1 Atlas Group, INRIA and IRINUniversity of Nantes,

Nantes, France

2 Soft-MaintGroupe Sodifrance

Nantes, France

IRIN, Universite de Nantes2, rue de la Houssiniere

B.P. 92208 — F-44322 NANTES CEDEX 3

Jean Bezivin , Erwan Breton, Gregoire Dupe, Patrick ValduriezThe ATL Transformation-based Model Management Framework:17 p.

Les rapports de recherche de l’Institut de Recherche en Informatique de Nantes sontdisponibles aux formats PostScript® et PDF® a l’URL :

http://www.sciences.univ-nantes.fr/irin/Vie/RR/

Research reports from the Institut de Recherche en Informatique de Nantes areavailable in PostScript® and PDF® formats at the URL:

http://www.sciences.univ-nantes.fr/irin/Vie/RR/indexGB.html

© September 2003 by Jean Bezivin , Erwan Breton, Gregoire Dupe, Patrick Valduriez

rapport˙interne.tex – The ATL Transformation-based Model Management Framework – 9/9/2003 – 13:49

The ATL Transformation-based ModelManagement Framework

Jean Bezivin , Erwan Breton, Gregoire Dupe, Patrick Valduriez

Jean.Bezivin@irin.univ-nantes.fr, ebreton@sodifrance.fr,Gregoire.Dupe@irin.univ-nantes.fr, Patrick.Valduriez@inria.fr

Abstract

Developers of information systems must typically deal with different models and perform transformations betweenmodels. Model management aims at providing techniques and tools for dealing with models and model transforma-tions in automated ways. In this paper, we present the current design of the ATL (Atlas Transformation Language)transformation-based model management framework. The key design decision is that models and model transfor-mations are treated as first-class citizen. We consider model management in the general context of the MDA. Afterreviewing the successive generations of transformation systems, we define the requirements for the ATL frame-work and we give an initial ATL definition. Finally, we describe three representative ATL transformations for twoimportant levels of transformation complexity.

Categories and Subject Descriptors: D.2.12 [Software]: Software Engineering—Data mapping

General Terms: MDA, model engineering, MOF, model transformation

1. Introduction

A model is a structure that represents a design artifact such as a database schema, an interface definition, an XML type definition, a UML model or a Web document [3]. Developers of information systems must typically deal with different models and perform transformations between models. Examples of transformations are: mapping heterogeneous data source descriptions in a global schema to perform data warehousing; converting XML documents into HTML; or generating EJB or .NET component definitions from a UML model. Most of these transformations today are still programmed using specific languages like SQL, XSLT or even Java or C. For instance, when using mediator systems like Disco [25], most of the development time is incurred in generating object adaptors for heterogeneous data sources. As information systems become more complex and need to support cooperation of heterogeneous applications and components, such manual development of models and transformations is no longer viable.

Model management aims at solving this problem by providing techniques and tools for dealing with models and model transformations in more automated ways. Several research communities such as databases, document management and software engineering have studied it independently for years. Recently, the need for more generic model management has been recognized [15]. The current trend is to consider that models are first class citizens, which seems the only way to deal with the ever-increasing complexity in information systems. It allows separating and combining important aspects such as platform dependent and independent features in a more regular way.

Transformation systems have been used extensively in different areas such as document management, programming languages, databases, etc. [13]. We can roughly distinguish three successive but overlapping periods for transformation systems, which we will analyze in more details later. In the first generation (illustrated below by the awk Unix command), a text file containing a transformation script expresses, in a given style, how a target file may be obtained from a source file. In the second generation (illustrated below by the XSLT vocabulary in the XML document management space), a tree script expresses how to transform an input tree into an output tree (XML documents). We are currently witnessing the rise of a third generation of transformation systems where the input and output are models (i.e. constrained directed labeled graphs) and where the transformations are themselves expressed as similar graph-based models. For example, one may think of a refactoring transformation expressed in UML that produces an improved target UML model from a source UML model.

The fact that first generation transformation systems are still much in use today is sufficient to show that there is no absolute order on the intrinsic values of the three generations. They are complementary rather than concurrent and are still evolving at various rates.

One major goal of third generation transformation systems is to achieve the "transformations as assets" principle. Information system development teams should be organized around a significant and well-structured library of reusable

transformation components. It should be possible to specialize these components and adapt them to the particular working style and specific needs of the development team. For instance, a company could buy a basic reusable transformation library to convert from UML to EJB and then specialize some of the components of the library to adapt them to support its specific methodological rules. Composition is already possible with first and second-generation transformation systems, but specialization is not yet addressed.

Although the basic principles of third generation transformation systems are well understood, much research work is needed to set up experimental systems and make them evolve towards a complete solution. To contribute to this evolution, we are building the ATL (Atlas Transformation Language) transformation-based model management framework in the Atlas group at INRIA/IRIN. One objective is to support reusability through composition and specialization. Although it is still too early to state precisely how this will be achieved, the systematic use of meta-models to define abstract syntax and semantics for models is a good basis. Meta-models that describe domain-specific languages may be made composable and comparable through the use of a common meta-meta-model (a set of constraints on the kind of directed graph we use together with a set of utilities to perform general operations). There are several families of such meta-meta-models [6], one of the most prevalent being the OMG Meta-Object Facility (MOF) [16].

Another important condition for the success of third generation transformation systems like ATL is that a standard transformation language be defined and accepted. Some recent initiatives are making progress into that direction. In [2], an initial proposal was made for a model transformation language. It was then transferred to the Common Warehouse Meta-model (CWM) recommendation of the OMG. It also inspired the new OMG request for proposal called MOF/Query/Views/Transformation (QVT) [17]. At the time of this writing, about half a dozen QVT proposals have been made available. The process of comparing these answers to produce an OMG recommendation is presently going on. It is very likely that the resulting standard will be modular and will allow for both imperative and declarative expressions. As evidenced by the wide adoption of UML, standard languages are important for model management. Thus, ATL will capitalize on the work on QVT as well as on recent work on generic model management platforms such as Rondo [15].

In this paper, we present the current design of the ATL transformation-based model management framework. The key decision is that models and model transformations are treated as first-class citizens. In particular, ATL supports higher-order transformations, which are proving to be very useful for transformation reuse. The main contributions of this paper are as follows:

• We define the problems of model transformation in the general context of the MDA, in particular in relation with the recent QVT request for proposal.

• We propose a classification of transformation systems, roughly divided into three successive generations, which manipulate structures of increasing complexity.

• We define the requirements for the ATL framework from which we derive an initial ATL definition. We also describe a first implementation of the ATL framework based on the Model-In-Action (MIA) transformation engine [23] which roughly satisfies our initial requirements.

• Finally, we propose a classification of transformations in terms of their complexity. Then we describe three representative ATL transformations for two important levels.

This paper is organized as follows. Section 2 defines the problems of model transformation in the MDA. Section 3 gives a classification of transformation systems. Section 4 introduces the ATL framework and gives an initial ATL definition. Section 5 proposes a classification of transformations and describes representative ATL transformations. Section 6 discusses related work. Section 7 concludes.

2. Model Driven Architecture (MDA)

The OMG has specified a complete architecture called MDA with various standard languages of major importance for model management, and thus for ATL. In this section, we discuss model management issues, in particular model transformation, in the context of the MDA.

In the MDA, a specific model captures each aspect of a system, at different stages of development. An advantage of this approach is the ability to deal with business models independently of the platform models (e.g. component models such as COM, J2EE or .NET). Model management in the MDA is intended to be operational and aims at automating operations and processes. MDA capitalizes on standard languages such as UML, the XML Model Interchange (XMI) and MOF.

Studying model management in the context of the MDA has many advantages. By relying on open standards, we can reuse much good work from others. For example we can expect a very interesting quality input when efforts will be invested on revisiting other technological spaces, like databases where solid and validated results have been accumulating for decades. The data transformation field is probably one of the most promising but it may still be enriched by the use of a common transformation language.

Figure 1: Standard OMG layered organization

The OMG has built a meta-data management framework similar to Microsoft Open Information Model (OIM) [2]. This framework is used to support the MDA. It is mainly based on a unique "meta-meta-model", MOF, and a library of meta-models. One of the most popular elements of this library is the UML meta-model. Another one is the Software Process Engineering meta-model (SPEM). This framework is organized as three layers usually referred as M1, M2 and M3. XMI is a standard projection of models (M1) and meta-models (M2) on XML1. XMI is well supported by many companies including IBM (Eclipse) and Sun (NetBeans). XMI is similar to XIF (XML Interchange Format) that was defined in the OIM framework. Among the various meta-models at level M2, we find different categories like processes and products, static and dynamic, functional and non-functional, object and relational, etc.

An additional classification for models has emerged in [24]. It distinguishes between models that are independent of the platform (i.e. PIM for Platform Independent Model) and models that are already bound to a given platform (i.e. PSM for Platform Specific Model). An executable code model (e.g. a Java program) may be considered as a special case of a PSM. The need to have specific platform description models (PDMs) to allow full automation of the binding operation seems a natural consequence of this evolution.

PIMs and PSMs provide a solution for platform independence and smooth migration. This organization of models had the immediate effect to reveal an urgent need for model transformation, not only PIM to PSM, but also many other kinds of PIM to PIM, PSM to PSM and even PSM to PIM transformations. This search for a suitable general model transformation framework is the next important step in the MDA definition. The recent creation of a working group on "legacy transformation" at OMG is a further illustration of this important trend.

1 There are also a standard projection on IDL and another standard projection on Java called JMI (Java User Community JSR #40).

������������ ����������� ���������� �"!$#�������%'&��(%��*)�&�������+����,�-�.�0/� 1���,��2��� 43

Figure 2: Mt: Ma 5 Mb

The main problem of interest here is to express how model Ma is transformed into model Mb. Since the vision is to consider models as first-class citizens, the transformation will be realized by model Mt as described in Figure 2:

Figure 3: Compiling to XMI and XSLT

This could be achieved by serialization of Ma and Mb into XMI and compilation of Mt to XLST as described in Figure 3.

We already studied the process of compilation to XSLT and we have mixed conclusions [20]. Note that compiling a model transformation program to XSLT or XQuery is different from directly applying XSLT or XQuery scripts to models serialized into an XML vocabulary like XMI.

Now we must consider that similarly to Ma and Mb, Mt is also a model and thus is written in the language of its meta-model. This has several consequences. The first one is that when we compile Mt to XSLT, we have access to MMa and MMb at compile time. The second consequence is that the meta-model of Mt is the (hypothetical) language for describing all kinds of transformations. This is further elaborated in Figure 4.

Figure 4: The place of a transformation language

Figure 4 postulates that there exists this common and unique transformation language, QVT. A given transformation operation is thus represented as follows in the basic relation:

6 7�8:9*;<6 6>=@?�6�6�7A?�6�BC?�6>=ED

Figure 5: Basic transformation relation

This means that a new target model Mb based on meta-model MMb is obtained from the source model Ma based on meta-model MMa, by applying a transformation Mt based on the standard transformation language.

From the above basic relation (Figure 5) we may understand how interesting it could be to consider a transformation system as a typing system. Furthermore, taking models as instances and meta-models as types provides a clear interpretation where the notion of abstract meta-model may play a role in defining specification of transformations that could be implemented in a number of different ways.

3. Transformation Frameworks

The achievements of previously built transformation frameworks will be useful in building the ATL transformation framework. In this section, we review the evolution of transformation systems, roughly divided in three generations.

On the other side of the spectrum, we find advanced modern platforms like Rondo [15], organized on the idea of a homogeneous space of high-level operations on models. This opens the road for a radically new way to consider information systems (as data transformation factories) and to conduct software production and maintenance operations on these systems.

A typical example of first generation transformation systems is the Unix environment seen as a data transformation framework (Figure 6). At the basis, we find the possibility to

define components (commands), to assemble them through well-defined interfaces (input and output flow, pipes, return codes, etc.). There is a programming in the large language (e.g. bash) allowing gluing basic components into composite entities. By writing expressions like (a || b) or (a && b) we may state that a transformation applies only if another one has succeeded or failed. More complex composition schemes may be expressed in the shell language. Typical examples of commands are awk, sed and m4.

If we take the awk command for example (Figure 7, Figure 8), it may be seen as a script processor with input and output files2. A script is composed of a set of rules. Each rule has a left-hand side and a right-hand side. The left-hand side is a pattern and the right-hand side is a sequence of instructions. Both sides may refer to record fields. An elementary navigation formalism is used to reference records and fields of the input and output files.

Figure 6: Pipes and filters

F$G.H4I�JLKNMPORQTS@U(V�W@X@ORYPZ�S@U�V\[]_^@`aZEZ_b1cEYC]�KNMPORQTSRMPORQed1f g.V W@X@ORYPZ@d�d4V\[G�JihjKk`RlEb1cm`@nRbjSoMEORQ�]CW@X@ORYPZ�V�^RcCp YPZq`RlPb�cm`anRb�V\[

Figure 7: An awk script

The awk scripting language is sometimes considered to be declarative since the rules may theoretically be executed in any order, exploring the input file records possibly many times and fields and producing the output file records and fields. As illustrated in Figure 7, a specific BEGIN rule will execute before all other regular rules while another special END rule is executed after all regular rules are executed.

There are many other interesting observations that could be made on Unix as a transformation framework. Many of the commands like awk have evolved (gawk) to provide extended facilities like the handling of multiple input or output files.

2 Figure 7 may be considered as a model corresponding to the simplified meta-model of Figure 8.

r<s t u vwu�x\y{z}| r<s u<t |

~k���\�wz y\�{z}��� ��x{z}s �\�

v<��t u�w�\�}� u<z}�

~�x�� s y{� �<�}�}�\z �}x��\s yw�

�{��s �\s �wt v��\t u r<s ���\t v��\t u

�.����

���

�a�

input output

leftHandSide

rigthHandSide

Figure 8: The awk scripting scheme

In the Unix operating system, many commands implement transformation operations and the framework itself (pipes, etc.) encourages programmers to build composite transformations from atomic ones. A variety of different operators, each having a different format for writing transformation operations, allow building complex transformations applied to code or data. Some commands like awk are rule-based declarative systems that transform input to output files while others like m4 follow a completely different functional style. This is an interesting example of what we may call an "initial transformation framework". It is still used and has proven to be helpful. It has obviously many shortcomings such as incompatible scripting languages, no library publicly available of basic awk scripts to reuse, no global framework where to select a generic transformation to apply in a given situation, etc. All these limitations could be formulated as objectives for the future frameworks that we would like to build.

The second generation of transformation systems (XSLT, XQuery, etc.) is currently dealing with tree transformations instead of files of records. A language (XPath) allowing formulating tree navigation expressions is used in the pattern part and the operation part of the transformation rules. Navigating the source tree will produce fragments of the target tree. In the following example we express the search on a document for all references to employees with a salary greater than � 2000 and born before year 1950.

�E�m�����w�w�<�<�w� �C¡¢}£k¤ ¥ ¡ ¦w§��C� ¥ �<¦w§��P�<¦w¨ ©�ª<«\¬�«\­¢ §��C� ¤ ­¢}£k¤ ¥ ¡ � �<� ¥ ®�¯ ¦{§k�C� ¥ �<¦w§ ¤C¤ § ¥ §�¨<¦wª<«\¬<¬�§��C� ¥ � ® §�§ «�¬<­¢ ¬<§k�_� ¤ ­¢ ¬ £k¤�¥ ¡ ¦w§k�_� ¥ �<¦w§�­¢}£k¤ ¥ ¡ ¦w§��C� ¥ �<¦w§��P�<¦w¨ ©�ª<«\§k�C� ¥ � ® §�§ «�­¢}£k¤�¥ ¡ ° ±@¦w§ ¤ ¦wª<«w² ¬ ¤ � ¥ �<� ®R³ ��¦µ´�¶�·k·k·1� ¸<¹1² ¬Nºk° �w¦<© ® § ��� ³P¥ ¦<´N» ¼¾½�·k«¢ §��C�w­¢}£k¤�¥ ¡ ¨<��� ® ¯ �<± ¤ § ¥ §�¨<¦wª<«w² ¬ ¸w���E§�«\¬<­¢}£k¤�¥ ¡ ¨<��� ® ¯ �<± ¤ § ¥ §�¨<¦wª<«w² ¬<±k° � ¤ ¦<¸w� �P§ «�¬<­¢ ¬<§��C�w­¢ ¬ £k¤�¥ ¡ ° ±<­¢ ¬ £k¤�¥ ¡ ¦w§k�_� ¥ �<¦w§�­�E¿ Àw§�� ® �w�w�<�<�w� �C¡¢ §��C� ¤ ­Á ±<�<�@¾§k�C�A° ¸¹��<¨ À<�P§k¸w¦wà «�§��C� ¥ � ® §�§ ¤ ² £ � ¥ «\Ä ¬<¬<§k�C� ¥ � ® §�§ ¤ ¬<§k�_� ¥ � ® § §Å ©�§ �w§RÃà Â�§k�_�w¬ ¤ � ¥ ��� ® ­E¶�·k·k·kÄ�� ¸<¹Aà Â�§k�_�µ¬kºk° �{¦<© ® §��<� ¢ » ¼¾½�·kÄ

Æ�Ç�È�ÉÆ�Ê�Æ�Ë�Ì�Í�Î�Ï�Ð�Ë�Ñ�Ì�Ò�Ó�Ð Í"Ô$Õ�Ì�Î�È�Ö'×�Ð(Ö�È*Ø�×�Ì�Í�Ì�Ù�È�Ñ,È-Í.Ò0Ú�Ë1Ì�Ñ,È�Û�Ð�Ë4Ü

Ä �w§ ¦<Àw�<¸¢ §��C�w­Á ¾§k�C�w¬ ¸w� �P§�ÝÁ ¾§k�C�w¬<±k° � ¤ ¦µ¸µ� �E§�Ý¢ ¬<§k�_�w­Ý¢ ¬<§k�_� ¤ ­Figure 9: Comparing XSLT and XQuery

We see an interesting and typical situation here where two standard notations (XSLT and XQuery) based on the same navigation language (XPath) are used for the same task, by different communities. It is theoretically possible to convert from one to another although this possibility does not seem to be widely used for the time being. This current situation does not promote reusability of transformation programs.

Of course it is possible to use today second-generation transformation techniques for model management. For example, as mentioned before, we may serialize a source model (e.g. a UML model) into a format like XMI or XIF and then simply apply XSLT or XQuery to this input to produce a serialized target model.

Third generation transformation frameworks are based on general graphs, constrained by a common meta-meta-model [14]. The choice of this meta-meta-model is not essential, but the need to select one is important. In the MDA, it is MOF. The ATL language is defined within this scope.

4. The ATL transformation framework

In this section, we discuss the requirements for our ATL transformation framework and define the ATL language. We also introduce the Model-In-Action (MIA) transformation engine [23] which satisfies our initial requirements.

4.1. Requirements

The objectives of the ATL framework are the following:

• ATL will allow us to express specialization and composition of transformations.

• ATL will allow us to express atomic and composite transformations, transformation sequences, pre-conditions and post-conditions, etc.

• ATL will allow for higher-order transformations (HOT), i.e. transformations taking transformations as input or output. Note that this is already partially available in the document management area since an XSLT program may generate another XSLT program. We plan to investigate the real applicability of these higher-level transformations.

• The execution of an ATL program Mt on a model Ma may not only produce the resulting model Mb but also, as a side-effect, a traceability model Mx that will serve to indicate for any target element in Mb from which Ma elements it comes and which rules have been used to generate it. The question

of defining the meta-model MMx from Mt remains an open problem.

• More generally we hope that it will be possible to separate specification from implementation of transformations. We already mentioned previously the possibility of using "abstract meta-models" to this end. Another possibility would be to consider "correspondence meta-models" between a source and a target meta-model. Then "transformation" or "traceability" meta-models could be viewed as specializations of this abstract correspondence meta-model.

• It should be possible to detect specific cases of transformations. Usually the source and target meta-models (MMa and MMb) are different (exogenous transformations) while in some cases they may be the same (endogenous transformations). Many other cases of relations between MMa and MMb exist (specialization, etc) that could be considered in transformations. Another example is the case of invertible transformations, i.e. a transformation Mt-1 may be generated from Mt if Mt is a transformation without loss of information. Other classification schemes will be presented in section 5.1.

• The ATL framework will provide several features like controlled escapes from automatic execution to get user guidance, help to establish the correctness of transformations, etc.

• Most of all, our ultimate goal is to establish significant libraries of reusable ATL transformation components that could be shared among large communities and adapted to the specifics of given working environments. Many tools (transformation browsers, etc.) are needed for this.

Note that in some cases our wish list may be in contradiction with the goals of QVT. To illustrate, we describe two such requirements:

• QVT explicitly asks for in place transformation, i.e. for the possibility for a transformation Mt to modify directly a model Ma. This does not bring significant advantages and has the drawback of making the transformation language more complex.

• QVT asks for one-to-one model transformations only. But many-to-many model transformations may allow much wider possibilities, hopefully without introducing useless complexity. This is an open issue that we are planning to explore.

There are many different kinds of transformations (abstract models to code, refactoring, reverse engineering, etc.). The ATL language is designed to be general and abstract. We plan to use it to compile transformations to many different target languages including XSLT and XQuery.

4.2. ATL definition

The ATL definition should follow the final choice of the QVT specification when it is ready. However, in order to get started now, we adopted the following strategy. There is a transformation engine very close to our initial needs, which could be considered, after some adaptation, as a possible candidate for QVT. This engine, called Model-In-Action (MIA) is commercially available from one of our industrial partners Soft-Maint [23]. It will be briefly described below. The idea is to define the relation between our intended ATL language and the presently available MIA language by a HOT. Only the first time (bootstrapping) the transformation needs to be written in MIA From then on, it may be expressed in ATL.

The advantages of proceeding this way are multiple:

• We can start immediately to experiment with the ATL language. In Section 5.2, we provide the ATL code for a simple transformation (State Pattern) and observe the execution of this transformation program. The concrete syntax used may evolve. An abstract syntax of ATL is provided in Section 5.4.2 in the form of a meta-model. This abstract syntax may also evolve.

• Applying HOT to the evolution of our own language has already been the source of interesting observations. After starting using this iterative strategy, we no more consider it as a palliative but as a normal way of proceeding in the future when we move from one version to another version of ATL.

In [10], the scheme described in Figure 10 has been proposed. This shows the general form of a transformation system, where a transformation is composed of named rules and rules are composed of sub-rules. It is very likely that the Object Constraint Language (OCL), associated with UML, will play a key role in the expression of these transformations. OCL will be used as an assertion as well as a navigation language for models. Thus, OCL will play for QVT a role similar to that of XPath for XSLT and XQuery. The ATL design is consistent with this assumption.

ÞRß�à¾á�âkãkäkß�å�à¾ækç äká

èkékê¾ëRì�ímîPï�ð ñ é¾òóCô¾õ ö÷.ø¾õ ù�úüû�ß�ökâ�âýç äká

þÿ ��� � þ

è��������� ìÿþÿ

Figure 10: General transformation organization

4.3. The MIA engine

The MIA engine, called MIA-Transformation [23], relies on declarative rules. Each rule may declare a context, a query

and an action. The query allows to retrieve model elements, and the action specifies the creation, modification and deletion of model elements. The context declares the elements that will be retrieved by the query and those that will be created by the action. The rules are organized as trees. A child rule inherits from the context of its parent rule. The query and action clauses of the parent rule are performed before those of the child rule.

A coherent set of rules is called a rule set. The execution of a rule set is performed by an inference engine, which allows several passes (this is an option of the rule set). A rule is executed once and only once in a same context. For example, there may be a rule set named Relational2UML that transforms relational schemas into UML models and a rule set named UML2XML that transforms UML models into XML schemas. These two rule sets may be chained within a single scenario that defines the transformation of relational schemas into XML schemas. A scenario is an element that allows defining complex transformations by chaining rule sets. Finally, for more complex operations, "macros" with Java-like syntax may be added and used within the rules.

Ruleset

Selected rule

Rule documentation

Rule context

Rule query

Rule action

Figure 11: MIA rule-building environment

The MIA-Transformation environment provides a graphical editor to specify the rules and a built-in generator of MOF components used to manipulate source and target models. In Figure 11 a typical browser is shown for a transformation from UML to relational database.

5. ATL transformation framework

In this section, we discuss the various levels of transformations and illustrate ATL with representative examples of transformations

5.1. Levels of transformation

������� ��� �������� � !"�$#%�'&)(*!+�-,/.����$��021�!30��54�1����$�)6'�"#7�8�9&;:��<�)#7�"=�!"�?>

There are several ways to classify transformations in a global framework. When dealing with practical transformations, we have been able to observe several levels of complexity in transformations:

@BADCEA�F-G"H"IKJ L MNI�O?PQIRISJUTVISW$PQIRI�OXTYI�IKW@BADCEA�F'Z�H"IKJ L MNI�O?PQIRISJ\[;IRI�O]T_^@BADCEA�F'`�H"IKJ L MNI�O?PQIRISJ\[;IRI�O]a_^@BADCEA�Fcb+H"IKJ L MNI�O?PQIRISJ

⊆⊆⊆⊆I�IRO

∨∨∨∨I�IRO

⊆⊆⊆⊆IRISJ

@BADCEA�F'd�H"IKJ L MNI�O?PQIRI�OXTYI�IKJ'e@BADCEA�FgfhISJ�L MBIRO?PQI�IKJUTYIRI�O@BADCEA�FjiVISJ�L MBIKJ P

Figure 12: Pragmatic classification of MDA transformations

This is a very pragmatic scale for classifying real world transformations in the particular context of the MDA:

• At level 1, we find transformations from a model expressed in a given serialization format (e.g. XMI 1.1) into the same model expressed in another serialization format (e.g. XMI 1.2)

• At level 2, we typically find endogenous transformations, i.e. transformations from one model to another one when the source and target models are strictly identical.

• At level 3 we have exogenous transformations when the source and target meta-models differ only by a small amount. We created this category to deal with transformations based on versioning of meta-models, like the move from UML 1.3 and UML 1.5.

• At level 4, we have again different source and target meta-models, but one of them is strictly "contained" in the other one3.

• At level 5, we find again exogenous transformations, but the source and target meta-models may be viewed as specializations of a common meta-model.

• At level 6, we have general unconstrained exogenous transformations

• At level 7, we have special cases like transformations from a model to a meta-model4 and similar situations.

In the previous scheme, we have not taken into account voluntarily the notion of profile. The UML language may be modified in small amount by defining "dialects" of the base language by so-called profiles mainly composed of

3 The operators used in Figure 12 ( k ,⊆⊆⊆⊆ l etc.) should not be taken with the meaning of strict set operators. Instead they are intended to convey the idea of a certain relation between meta-models. A precise definition of these relations has been undertaken but is beyond the scope of this paper. 4 There are several examples where this kind of promotion from a model to a meta-model may be useful. One popular tool available to do this kind of operation is UML2MOF available in the NetBeans/MDR environment (http://mdr.netbeans.org/uml2mof/)

stereotypes, constraints and tagged values. A profile may be viewed as a specialization of a meta-model for specific purposes. There are a lot of standard profiles being defined like UML for real-time, UML for CORBA, UML for EAI, etc. We consider that this technique is far from stable and has not yet proven its long-term value; this is why we have only considered full-ledged meta-models in the previous classification.

In order to illustrate our work on the initial definition of ATL, we propose three examples of transformations with different properties. The first one (basic example below) is at level 4 of our classification. It is the application on UML models of the well-known state design pattern transforming class and state transition diagrams into class diagrams. The relation between input and output meta-models is thus very narrow.

In the second example, the idea is to transform UML activity diagrams into a specific model able to drive MSProject, Microsoft’ s project management system. Of course a meta-model for MSProject has first to be built since Microsoft does not provide it as standard. This kind of transformation is likely to be performed in other contexts as well, like generating from activity diagrams to an open source software product equivalent to MSProject. So, we have decided to use here the technique of a "pivot" meta-model, i.e. to break the transformation into two composable transformations. For this intermediary pivot we have chosen the OMG standard SPEM (Software Process Engineering Meta-model). This second transformation is at level 6 and allows illustrating some interesting properties of a general transformation framework. The complete operational transformation has been implemented in the MIA environment, including the MSProject interfaces, allowing practically driving this MSProject system with activity diagrams. Needless to say that both source and target meta-models were a priory unrelated and this is a practical experiment in model integration.

The third transformation is also at level 6, but with very different properties. The idea is to apply the principles we are promoting to our own project. Starting from the MIA engine, we first consider that ATL is just another abstract syntax for this transformation engine. Then we plan to progressively decouple ATL from MIA. In order to do so, since ATL and MIA programs are also models, they are based on precise meta-models and it should be possible to express the transformation between them as another ATL program. This is the purpose of this third HOT example that transforms an input ATL transformation model into an output MIA transformation model.

5.2. Basic example

The first example is the controlled application of the state design pattern5.

We consider we have a UML model, where a class C is associated with a state chart diagram. We would like to

5 The State Design pattern is a standard pattern described in the classical GoF book. A description of this may be found at the following URI http://www.dofactory.com/patterns/PatternState.aspx together with illustrative C# code.

transform the class diagram, following the state design pattern, by adding subclasses corresponding to the various possible states of this class. The particular benefits of doing this operation are not our main concern here. Instead we concentrate on the possibility to describe this transformation accurately and to handle a library of such operations.

m�nBo�pqEoErtsvuxw

yBr�sto{z�oE|�s~}���oB����E�t�v���B���

mv�-��E��� o{u�w

yNrs�oBz~o{|s�}N�toB����E���t�E�����<�����v�

�

m�rs��s�o

�

z�oEpqEoErtsvuxw*�r�s��sto{� �?���<� o{uxw���

yNrts�o{z�oE|Es~}���oD��<���������+�����v�E�t �{��5¡

Figure 13: The State design pattern

Just to give an idea of this transformation, let us consider the following very simple example. We have a class Boolean with an element being either in state true or in state false. This is described in Figure 14. The operation not may change the state of a boolean object from true to false or from false to true. Applying the state pattern to this model yields a new situation where there are two sub-classes of Boolean called True and False (Figure 15).

Figure 14: The Boolean class with two states

Figure 15: The result of applying the State pattern

This example may look very naive. However it has been proven to work. In Smalltalk for instance, the class hierarchy is organized this way and there is code to check that class True has only one instance named true (as illustrated in Figure 15). The state design pattern has been most useful in many complex situations (transaction processing systems for example). The challenge here is manifold:

• How to express the transformation operation (creating several classes from an initial class diagram and an associated state diagram)?

• When to apply the transformation in a controlled way? It seems likely that, in a given model, we do not wish to apply this to every class, but only to a selected number of them.

• How to deal with exogenous transformations? Here, it seems that both source and target models have the same meta-model (UML). As a matter of fact we have on the left side a meta-model composed of state-chart diagrams plus class diagrams and on the right side only class diagrams. So it is really a transformation with different meta-models.

Figure 16 presents the transformation using an ATL concrete syntax. ATL programs are composed of OCL expressions (in italic), and ATL operators: forEach (apply the body actions to a set of elements), create … in … (creates a new instance of a defined meta-class and stores the new instance in the defined variable), set … = … (set the property of an element), copy … in … (copy all the elements of Ma in the model Mb).

¢�£�¤x¥�¦~§~¥ ¨© £«ª�¦�¬ ­ ¤ ®{¯D°�¯�±t²© £«ª�¦�¬ £�³x¥´®{¯D°�¯�µ²¶�±�·�­ ±�µ�¬ ¦ ¯�±¹¸v¥�±«¥�¦�¯D±«¢�º�­ ¤�¦ »�¥�±«¥�¦�¯D±«¢�º�­ ¤�¦t²¶�±�·�­ ±�µ�¬ ¦ ¯�±¼¯�£«ª�¦�¬ ½�¬ ¦ © ¦~¤x¥ »�¥�±«¥�¦�¾�¬ ±«»�»�²¶�±�·�­ ±�µ�¬ ¦�¯�±¹¸v¥�±«¥�¦�¿¦~·À¥�¦~§ »�¥�±«¥�¦�²¶�±�·�­ ±�µ�¬ ¦ ¯�µÁ¾�¬ ±«»x» ¤�¦�¾�¬ ±«»�»�²¶�±�·�­ ±�µ�¬ ¦ ¯�µ¹Ã�¦~¤�¦~·x±�¬ ­ Ä�±«¥«­ £�¤ ¤�¦�ÂtÃE¦~¤�¦�²Å¢�£�ÆxÇ È�É�­ ¤ È Ê�ËÌ £�·�½�±«¢�º ÍxÎxÉ�ÎxÏ�È<É�Ð�Ñ�Ò ÓxÏ�­ ¤ Ô�Õ ÖtÕ ×«Ø$Ö�Ù�Ú�Û Ü�×�Ý Ö~Þ Þ ß�Üxà�Õ Ö�Ü�Ù«×�à*á âã Ì £«·ä½�±�¢�º ÍxÎxÉ�ÎxÏ�åEæ É�ÍxÍB­ ¤ à�Õ Ö�Õ ×«Ø/Ö«Ù�Ú�Û Ü�×~Ý Ù«ç�Ü�Õ ×�è{Õã Ì £�·�½�±«¢�º Í�ÎxÉ�ÎxÏ<­ ¤ à�Õ Ö�Õ ×«éÞ Öäà�à�Ý ê�×�Ú~Ö�ëìÛ çxí�Ý Õ ç*î�Ý à�ï«êvë ׫í�Õ ×�èã

¢�·x¦~±�¥�¦ åEæ É«Í�ÍB­ ¤ ÓxÏ~ðåEæ É�ÍxÍäË»�¦�¥ Ü�×�ñ�éÞ Öxàxà�Ý Ü�Ö�ò�×�ó<Ù�ç«Ü�Ù�Ö�Õ á�à�Õ Ö�Õ ×~Ý Ü�Ö«ò{׫ô à�Õ Ö�Õ ×«éÞ ÖxàxàäÝ Ü�Ö�ò�×ÀâxË¢�·x¦~±�¥�¦ õvÏ�ÓxÏ~öxÉ�æ Ò ÷«É�Î~Ò ø~ÓB­ ¤ ÓäÏ�ðEõÏ�ÓxÏ�Ë»�¦«¥ Ó�×�ñvù×~Ü�×�Ý î�Öxí�×~Ü�Õ�óDà�Õ Ö�Õ ×�éÞ Öxàxà�ËÍx¦«¥ Ü�×�ñvù×~Ü�×�Ý Ù�Ú�Û Þ ú�ó<Ü�×�ñ�éÞ ÖxàxàäËûûûFigure 16: ATL simple program

for State Pattern Transformation

• The first action of the transformation is to copy the class diagram of the input model into the output model. This is necessary and possible because the transformation adds elements to the class diagram and does not modify anything else. The following actions are applied to each state of each class present in the source state chart.

• In the first forEach we have another forEach statement dedicated to store the name of the class owning the state that will be treated. The use of this variable is necessary because the stored class will be referred as the super-class of the class that will be created later. The actions of this forEach will be applied to only one element, because the output of the OCL query stateMachine.context is a unique element.

ü�ý�þ�ÿ�ü���ü���������� ���������������������$þ������ ��þ"!���������#'þ �7þ$�%�'&��(���7þ )�� �+*

• The action description part of third forAll, begins by creating a new class corresponding to the current state. The name attribute of the new class is evaluated to the concatenation of the name attribute value of the state and the name attribute value of the class owning the state.

• Finally the generalization relationship between the new class and the class owning the state is created. The properties of the Generalization instance, parent and child, are valuated.

The state pattern has become a classical exercise in model transformation. The only interest here is to show that the ATL program is running for this level 4 transformation.

5.3. Process transformation example

In a more realistic experiment, we deal with two completely disjoint meta-models. On the left-hand side, we use Activity diagrams as defined in UML 1.5. On the right-hand side, we use our own meta-model of the MSProject product. We show how to make automatic transformations between these two independently built meta-models. Figure 17 provides a very simple example of a UML activity diagram:

Figure 17: A sample UML activity diagram

In Figure 18, we give a simplified version of the MSProject meta-model elaborated for this work.

The idea here is to use a pivot model. This is a frequent solution when we anticipate having to do the same kind of work with different source or target meta-models. Instead of building N(N+1)/2 bridges between these N different meta-models, we factor out the work and choose a suitable pivot. Here we have chosen as a pivot meta-model, the SPEM recommendation by OMG. The software development process of IBM and Rational (RUP) has mainly inspired this SPEM standard. A basic kernel of this meta-model is presented in Figure 19.

Figure 18: A meta-model for MSProject

It appears clearly here that the notion of UML Activity may be in direct correspondence with the concept of a Task in MSProject [9]. This corresponds also to the notion of Activity in the SPEM meta-model. Other concepts are more difficult to match like the concepts of Resource in MSProject and of WorkProduct in SPEM. We cannot elaborate on the details of these correspondences here, but the point we wanted to make is the possibility of expressing them by practical and operational bridges expressed in a given transformation language like MIA or ATL. The complete MIA transformation has been used in practical situations.

Figure 19 The kernel of the SPEM meta-model

5.4. Practical higher order transformations

We talk about HOT when we have the situation of a transformation taking as input or producing as output another transformation. In this section we present a practical example of such a transformation. A transformation T that transforms a transformation Tatl written in ATL into a transformation Tmia expressed in MIA is possible because transformations are models. We present below both meta-models, before briefly studying the transformation.

5.4.1. MIA meta-model

The MIA language meta-model used to implement this transformation (see Figure 20) is not the full meta-model. It is just the part that we need to perform an ATL transformation on MIA platform. We will present this transformation language referring to the example of a transformation of a model Ma into a model Mb.

Figure 20: The MIA meta-model

RuleSet: An MIA transformation is a RuleSet that is composed of Rules. Each rule has an Action element and a Query element.

Action: Action elements are composed of ActionItems. Each action item is the equivalent of a code line in the MIA language. This is why the composition relationship between Action and ActionItem is ordered. ActionItem is an abstract class that has four sub-classes: AddTransLink, AssignmentAction, CreateInstance, PropertyOperation.

AddTransLink: This class is able to create a transient link between an element of model Ma and an element of model Mb. Such links are dedicated to help navigate in the models. The use of transient link has no effect on the output model Mb.

AssignmentAction: This describes an assignment where the left part is a variable attribute and the right part is an Expression. In this meta-model, Expression is simply described by a String.

CreateInstance: This class describes the creation of an instance of a meta-class. The new instance is put in the variable defined by the attribute destinationVariable. The toModel attribute specifies in which model the instance has to be created.

PropertyOperation: This is an abstract class specialized by two classes: AddProperty and RemoveProperty. PropertyOperation is able to add/remove properties to an element defined by the toElement attribute. The property type is defined by the propertyName attribute and its value is set with the value attribute.

Query: Query elements are composed of QueryItems. Each item is the equivalent of a code line in the MIA language. This is why the composition relationship between Query and QueryItem is ordered.. QueryItem is an abstract class that has three sub-classes: AllElements, Filter and AssignmentQuery.

AssignmentQuery: This describes an assignment where the left part is the variable attribute and the right part is an Expression. AssignmentAction and AssignmentQuery have been distinguished because they do not have the same constraints on the right part.

AllElements: This class is used to get all the instances of the metaclass defined by the attribute metaItem. The instances are searched in the model specified in the attribute fromModel. The attribute destinationVariable defines the variable where the result of the search has to be stored.

Filter: This class is used to do a selection such as the where clause in SQL. This expression attribute is a boolean expression defining which elements resulting from other query items must be selected.

5.4.2. ATL metamodel

The ATL transformation language is defined by a meta-model (Figure 21) inspired from the OCL 2.0, which may be considered as an assertion and as a navigation language. ATL transformations are stored in QVTUnits. QVTUnits are composed of QVTOperations, which are composed of TransformationDescriptions. A TransformationDescription is an abstract class, which has two sub classes: Action and Context.

Context: The context is used to store the variables and models manipulated by the transformation.

Action: The Action class is the element of the language that will describe the actions needed to perform a transformation.

ü�ý�þ�ÿ�ü���ü���������� ���������������������$þ������ ��þ"!���������#'þ �7þ$�%�'&��(���7þ )�� �+*

The actions have to be executed in a specific order, which is defined in the position attribute. This notion of order is necessary. We cannot for example set an attribute to a class if the class has not been created.

There are three types of Actions: CreateInstance, PropertyOperation, AddTransientLink. Those classes have the same functionality as their MIA equivalent.

Figure 21: The ATL meta-model

The rest of the ATL meta-model is the description of Expression sub-classes. ATL Expression classes are a copy of a part of OCL Expression sub-classes. An important extension has been made: the QueryTransientLinkExp that is a sub-class of CallExp. It is used to navigate through the transient links.

5.4.3. Transformation of ATL to MIA

This transformation can be divided in two parts: one managing the transformation of the classes present in the ATL meta-model shown in Figure 19 and the other one managing the transformation of ATL expressions into MIA. The first one is quite easy to implement, because many elements from both meta-models are identical for the time being. We then have to do a “copy” of the elements. This can be expressed as described in the following pseudo-code.

,�-/.10 Ó~Ò Î32547618~æ Ï:9Ï~Î,�-/.<;>= Ï~ö�É«Î�Ò ø�Ó32541618~æ Ï? Ð�Î~Ò ø�Ó�@�ÎxÏBA�254 ? Ð�Î~Ò ø~Óå�öxÏ�É�ÎxÏC@�ÓäÍ�ÎxÉ�ÓäÐ�Ï>254tå�öxÏ�É«Î�ÏC@�ÓxÍxÎ�É~ÓxÐ�Ï?EDFDF. öxÉ�ÓxÍ~Ò Ï�ÓxÎHGtÒ ÓJIK254 ?EDFDF. öxÉ�ÓxÍHGtÒ ÓCI6�ÏFAEøCL�ÏNM�öxø = Ï~öxÎ�O>25476tÏBA�øJLxÏNM�öxø = Ï~ö�Î�O?EDFD M�öxø = Ï~öxÎ�O>254 ?3DFD M�öxø = Ï~ö�Î�O The previous rules have to manage the creation of the attributes of the classes. The difficulty is that these

attributes have the same names and the same meanings but do not have always the same type. Thus we proceed as presented in the following double entry table.

?E. GBPäÈ>@ ? ÈQ@ ? 9Î�ö~Ò ÓHR SQTBUEVXW/YHZH[:\H\N] ^:_UE`<a:b1cHZN] _Hd e1^KfKgC^:Y�h e1^J[N\i_j^JcE[NW1] \HcUE`<aBVXW/YHZH[:\H\N] ^:_ SQTFUkb1clZN] _Hd

m V<nNb1o UE`<aFVFW/YHZH[N\H\:] ^:_jpSQTBUEVXW/YHZH[:\H\N] ^:_Jq rlfXs tj[m V/nNb1o UE`<aBVXW/YHZH[:\H\N] ^:_Hp

UE`<a:u(vHwx[NgJc UE`<aNu(vHwx[:gCcjq _Hf:yz[ SQTBUEVXW/YHZH[:\H\N] ^:_Jq rlfXs tj[m UE`<aNu(vHwx[:gJcJq _Hf:yz[

The table explains that when we have an ATL attribute, which is a String, the corresponding MIA attribute is also a String, and we simply do a copy. When the ATL attribute is an Expression and the MIA attribute is a String, we use a conversion operator called E2S that converts the ATL Expression into a String compliant with MIA. When the ATL attribute is an Expression and the MIA attribute is an Expression too, we use an E2S conversion operation to set the value attribute of the MIA Expression. When the ATL attribute is an object (Model, Variable, etc.) and the MIA attribute is a String, we set the MIA attribute with the name attribute value of the ATL object. When the ATL attribute is an object and the MIA attribute is an Expression, we set the value attribute of the MIA Expression with the name attribute value of the ATL object.

The second main part of the transformation is the definition of the E2S operator. This operator takes as input an ATL Expression and returns a String compliant to MIA expression syntax. This transformation is a composition of OCL-like IfExp and concatenations of Strings. This part of the transformation is more difficult because it is not mere copying. We have to apply operators (concatenation) to different elements of the input model to obtain one element in the output model.

This transformation of ATL to MIA can be reversed because we do not lose information about the transformation Ta. At the moment however, ATL is not powerful enough to automatically reverse the transformation. It is still necessary to hand-rewrite the transformation. The reversed transformation will be more difficult to write because we would have to parse Strings stored in Expression elements.

6. Related work

Model management has been the subject of intensive research in both the database and software engineering areas, initially with different objectives. In the database community, model management focused on schema management and metadata management issues in data-intensive applications such as database design, data migration or data integration. Schemas are typically represented as graphs with rich semantics in order to relate entities. This representation has been the basis for much work on schema translation and schema integration in distributed multidatabase systems and mediator systems [13]. Recent work has moved on to automatic schema matching with the objective of minimizing the amount of manual post processing [22].

In order to ease the manipulation of transformations, they can be uniformly treated as models [3][4]. This is the design choice we made for ATL. However we go one step further in

generalization by allowing HOTs, transformations taking transformations as input or output. HOTs are proving to be very useful for transformation reuse.

In the software engineering community, model management tends to focus on platform independence, software reuse and model executability issues in the context of distributed applications. The main objective is to raise the level of abstraction and interoperability of software so that business models can be deployed on different component models, such as J2EE and .NET. With its MDA architecture, the OMG is promoting a number of standard languages such as UML, XMI, and MOF/QVT, which are important for model management [7][8]. The ATL design strives to be consistent with the MDA standards; in particular, we will make ATL compatible with the transformation language MOF/QVT when it is ready.

More recently, generic model management has become the subject of much research in order to allow seamless manipulation of different models, as required in complex information systems. Rondo [15] is the first complete prototype of a generic model management system with high-level operators to manipulate models and model transformations. In Rondo, transformations are treated as morphisms that work on syntactic structures.

There is also growing interest in general model transformation systems. First generation transformation frameworks used file scripts to express the conversion of input files to output files. Second generation of transformation frameworks use tree-based scripts (e.g. XSLT) to convert an input tree into an output tree (mainly xml documents). Third generation transformation systems use a graph-based transformation script (a model) to transform an input model into an output model. One of the first illustrations is the OIM transformation system [2], which considers transformations (called mappings) as models. OIM and MTRANS [20], a general framework for model transformations based on XSLT, inspired the initial design of ATL.

UMLAUT [11] is a design transformation framework that provides searching, retrieving and modification functionality, allowing the developer to write transformation code executed on an imported software model. UMLAUT was developed in the Triskell group at IRISA, Rennes, and is now evolving towards MTL, another QVT compliant transformation language. The emphasis in MTL is on an imperative transformation language while in ATL the goal is to progressively move towards more declarative expression. Within the context of the CARROLL research laboratory, we regularly compare our approaches (Thales, Triskell, Artlas) and the first results of this also show the importance of HOTs [5].

Another transformation language called TRL has been defined at France Telecom, in association with a global meta-model repository called Univers@lis. This language is currently being used for several real-life applications like generating from a business component model (OMG EDOC) to a CORBA platform (OMG CCM) [1] or producing VoiceXML code from abstract dialogue specifications.

7. Conclusion

In this paper, we described the current design of the ATL transformation-based model management framework. Our key design decision is that models and model transformations are treated as first-class citizen. In particular, ATL supports higher-order transformations (HOT), which are proving to be very useful for transformation reuse.

The ATL language is designed to be general and abstract. We plan to use it to compile transformations to many different target languages including XSLT and XQuery. The ATL design strives to be consistent with the MDA standards; in particular, we will make ATL compatible with the transformation language MOF/QVT when it is ready. Our first implementation of the ATL framework based on the MIA transformation engine satisfies our initial requirements.

We described three representative ATL transformations for two important levels of transformation complexity. The third transformation (ATL2MIA) shows the practical way we are following on the short term.

One lesson we learned in designing ATL is about the importance of HOT. After using this as a bootstrapping expedient to start the project (without waiting for the QVT definition), we realize now its practical use in many situations. We are finding a lot of examples where HOTs are playing a key role. One of them is for optimizing transformations, which we will study next in the project.

Another concrete example is the following. A company has acquired a set T1 of transformation components to transform say UML 1.5 to EJB 1.1. Then it has adapted T1 into another set of transformation T1' to deal with the local needs. The work to specialize T1 into T1' has been significant. Now a new version of EJB 2.0 becomes available. If the company decides to acquire the T2 library to transform UML 1.5 to EJB 2.0, it will redo all over the adaptation. A more interesting alternative is to get a set of transformation { : T1 |

T2 and to do the adaptation from { to { '. This has most chances to cost less and be more stable. Practical demonstration of this intuition has however still to be presented.

As a suggestion intended to facilitate the merging of the QVT proposals at OMG, we propose to use HOTs to establish correspondences between the different versions of the proposed transformation languages. This may have at the same time a conceptual and a practical benefit. On the theoretical side, the fact that a correspondence may be established between two formalisms is an interesting fact. The notion of a pivot meta-model used in section 5.3 may also be relevant here to understand what could be a "kernel transformation language". On the practical side, it is likely that many organizations may adopt different transformation formalisms and would like to switch from one to another one. If we want the third generation transformation frameworks to perform better on reusability than the previous generations (e.g. awk, sed, m4, xslt, xquery, etc.), this is a mandatory objective.

}�~�����}���}����������� ����������������������������� ���"������������� ���$�%�'���(����� ��� �+�

As future work, we also plan to develop a complete ATL framework based on the sNets reflexive semantic networks, which we developed before [6] and a stand-alone transformation engine. We will also experiment with significant data management applications such as data migration and software engineering applications such as component migration. Ultimately, we wish to release significant libraries of reusable ATL transformation components that could be shared and adapted to the needs of developers of information systems.

References

[1] Belaunde, M., Bézivin, J., Pham, T.H.: Implementing EDOC business components on top of a CCM platform. EDOC'2003, Brisbane, Australia, September 2003.

[2] Bernstein, P. Bergstraesser, T.: Meta-Data Support for Data Transformations Using Microsoft Repository, IEEE Data Eng. Bulletin 22(1), 1999.

[3] Bernstein, P., Levy, A., Pottinger, R.: A Vision for Management of Complex Models, ACM SIGMOD Record 29(4), 2000.

[4] Bernstein, P.: Applying Model Management to Classical Meta Data Problems. CIDR Conference, Asilomar, Ca, 2003.

[5] Bézivin, J., Farcet, N., Jézéquel, J.M., Langlois, B., Pollet, D. : Reflective Model Driven Engineering. Submitted for publication, june 2003.

[6] Bézivin, J., Lemesle, R.: Towards a True Reflective Modeling Scheme. Reflection and Software Engineering, W. Cazzola, R.J. Stroud (eds.), Springer Verlag, LNCS 1826, 2000.

[7] Bézivin, J.,Gerbé, O: Towards a Precise Definition of the OMG/MDA Framework. ASE'01, San Diego, Ca, 2001.

[8] Bézivin, J.: From Object-Composition to Model-Transformation with the MDA. TOOLS-USA’2001, Santa Barbara, Ca, 2001.

[9] Breton, E., Bézivin, J.: Towards an Understanding of Model Executability. Conf. on Formal Ontologies for Information Systems, Ogunquit, Maine, 2001.

[10] Gerber, A., Lawley, M. Raymond, K., Steel, J. Wood, A.: Transformation: The Missing Link of MDA, ICGT 2002.

[11] Ho W-M., Jézéquel J-M., Le Guennec A., Pennaneach F.: UMLAUT: an Extendible UML Transformation Framework, Automated Software Engineering (ASE'99), Florida, 1999.

[12] Kobryn, C.: UML 2001: A Standardization Odyssey. Communications of the ACM, 42(10), 1999.

[13] Kurtev, I., Bézivin, J., Aksit, M. : Technological Spaces: An Initial Appraisal, Int. Federated Conf. (DOA, ODBASE, CoopIS), Industrial track, Irvine, Ca, 2002.

[14] Lemesle, R.: Transformation Rules Based on Meta-modeling, EDOC, San Diego, Ca, 1998.

[15] Melnik, S., Rahm, E, Bernstein, P.A. : Rondo: A Programming Platform for Generic Model Management, ACM SIGMOD Int. Conf., San Diego, Ca, 2003.

[16] OMG/MOF Meta Object Facility (MOF) Specification. OMG Document AD/97-08-14, September 1997, www.omg.org. (MOF 2.0 has been recommended in june 2003, in alignment with UML 2.0).

[17] OMG/RFP/QVT MOF 2.0 Query/Views/Transformations RFP, OMG document ad/2002-04-10, www.omg.org.

[18] OMG/XMI XML Model Interchange (XMI) OMG Document AD/98-10-05, October 1998, www.omg.org.

[19] Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems. Prentice-Hall, 1999

[20] Peltier, M., Bézivin, J., Guillaume, G.: MTRANS: A General Framework, based on XSLT, for Model Transformations, Workshop on Transformations in UML (WTUML), Genova, Italy, 2001.

[21] Pottinger, R.A., Bernstein, P. A.: Merging Models Based on Given Correspondences, University of Washington Proceedings VLDB 2003.

[22] Rahm, E., Bernstein, P. A.: A Survey of Approaches to Automatic Schema Matching, VLDB Journal, 10(4), 2001.

[23] Sodifrance: MIA: Model-In-Action, Commercial Data http://www.sodifrance.com/modelinaction/en/index.php, 2003.

[24] Soley, R. and the OMG staff: Model-Driven Architecture. OMG document Available from www.omg.org, November 2000.

[25] Tomasic, A., Raschid, L., Valduriez, P.: Scaling Access to Heterogeneous Data Sources with DISCO. IEEE Trans. on Knowledge and Data Engineering, 10(5), 1998.

INSTITUT DE RECHERCHE EN INFORMATIQUE DE NANTES

The ATL Transformation-based ModelManagement Framework

Jean Bezivin , Erwan Breton, Gregoire Dupe, Patrick Valduriez

Abstract

Developers of information systems must typically deal with different models and perform transformations betweenmodels. Model management aims at providing techniques and tools for dealing with models and model transforma-tions in automated ways. In this paper, we present the current design of the ATL (Atlas Transformation Language)transformation-based model management framework. The key design decision is that models and model transfor-mations are treated as first-class citizen. We consider model management in the general context of the MDA. Afterreviewing the successive generations of transformation systems, we define the requirements for the ATL frame-work and we give an initial ATL definition. Finally, we describe three representative ATL transformations for twoimportant levels of transformation complexity.

Categories and Subject Descriptors: D.2.12 [Software]: Software Engineering—Data mapping

General Terms: MDA, model engineering, MOF, model transformation

IRIN, Universite de Nantes2, rue de la Houssiniere

B.P. 92208 — F-44322 NANTES CEDEX 3