The use of Model Transformations (MT) in software engineering leads to several benefits, such as complexity reduction and portability [3], [4]. However, developing MT is a challenge. As Siikarla et al. state in [12], "An application developer with proper domain knowledge can manually create a target model based on a source model. He can probably even come up with some of the most often used rules of thumb for the transformations. However, defining a complete mapping from all possible source models to target models is remarkably harder." The stateof-the-art for developing MT consists of describing the MT definition informally in natural language [5], based on an "educated guess" [12], and implementing the transformation definition using a transformation language [6], [18]. This informal approach leads to several drawbacks [6], [18], [20], such as inconsistency between specification and implementation [5] and cost increase [8].
Since MT are software [12], they need to be engineered as software [6], using a systematic process of: (i) specifying problems and requirements [5], [6], [7]; (ii) acquiring knowledge about semantic correspondences [19], [20];
(iii) modelling source and target models to outline a transformation [7], [12], [19]; (iv) creating mappings between meta-models [6], [19], [20]; (v) setting up constraints and rules for model mappings [6], [19], [20]; (vi) defining transformation architecture [6]; (vii) implementing the transformation definition using a transformation language [5], [6], [12], [20]; and (vii) validating the transformation definition [5], [6], [12]. Furthermore, analogous to software development, MT can take advantage of further techniques to support its development, such as transformation patterns [7], [18]. As Guerra et al. advocate in [6], developing MT "requires systematic engineering processes, notations, methods and tools". Although there are several tools for implementing MT definitions [20], there is: (i) little work addressing the whole life-cycle of MT [12], [19]; (ii) lack of guidelines for the systematic development of MT, in particular, to support novice MT developers; and (iii) different perspectives regarding the best way to develop MT.
The analysis in this paper aims to contribute to the adoption of Model-Driven Engineering by providing a qualitative analysis of state-of-the-art approaches in developing model-to-model (M2M) transformations, investigating their strengths and weaknesses, and highlighting lessons learned for supporting MT developers starting in this area. Our analysis was prompted by the following research question: Which methods and techniques should a novice MT developer use? Unlike most work in MT, such as that reported in [10], our focus lies in activities of MT life-cycle other than implementation. In particular, we investigate processes, a modelling language, and transformation patterns to support MT development.
Note that this is not the only challenge associated with MDE adoption. However, challenges such as model and meta-model development are outside the scope of our paper. By a literature review, we identify approaches to support MT life-cycle. Then, we qualitatively analyse recent approaches according to three aspects (Section 2): (i) model transformation foundations; (ii) features; and (iii) applicability. Finally, we summarise lessons learned during our experience with analysing and adopting MT in the cloud computing domain (Section 3).
In our investigation of M2M transformation development approaches, we identified no study, either qualitative or quantitative, comparing approaches to MT development in phases other than implementation. Furthermore, taking into consideration approaches we analysed in this paper, apart from the approach presented in [6], no approach was extensively evaluated, providing only worked examples to support a feasibility analysis. Moreover, so far, no approach for MT development has been widely adopted. These three facts make hard to choose a suitable approach when developing MT, fostering the concept of "ad hoc" MT development [6]. It becomes even harder when the MT developer has limited experience in this activity. In order to support novices in the task of selecting an approach for MT development, we provide in this section a qualitative analysis of approaches present in the MT literature. Table 1 summarises our analysis.
As Sjoberg, Dyba & Jorgensen define in [16], "qualitative methods collect material in the form of text, images or sounds drawn from observations, interviews and documentary evidence, and analyze it using methods that do not rely on precise measurement to yield their conclusions." To this end, we used 13 criteria for analysing the approaches covered in our analysis, classifying the approaches into three groups: MT foundations, main features, and applicability of each approach.
The first group consists of foundation concepts of MT, as presented in [3] and [4]. The second group is based on the most relevant features implemented by approaches. Finally, the last group consists of our evaluation of the applicability of these approaches, taking into consideration the perspective of a novice MT developer. The evaluation of these approaches was exclusively based on information presented in their respective papers. As Seaman advocates in [11], by conducting this qualitative analysis we aim at providing rich and informative analysis to support novice MT developers. In addition, we aim at increasing the knowledge on how these approaches can contribute to designing MT.
Investigating model transformation literature, we identified eight research papers presenting approaches supporting M2M transformation development. As in our previous investigation [14] the IEEE digital library provided the most significant set of primary studies for our research, we decided to use this library as our primary source. Our search identified 121 papers, from which we critically analysed both title and abstract, resulting in two papers selected for full reading [7], [8]. In addition, we were supported by an MDE expert, who suggested another paper [6]. Finally, by analysing references and citations of previously selected papers, we found five more relevant papers [5], [12], [18], [19], [20].
Based on an analogy with software development, we classified the identified approaches as:
(i) traditional [6], [12] when they advocate an iterative process of refinements, from requirements to MT implementation and test; (ii) by example [18], [19], [20] when they concentrate on simplifying the transformation development, focusing on model mappings [9]; (iii) emergent [5] when based on emergent software development approaches (e.g., agile), which proposes innovative ways to develop software; and (iv) transformation patterns [7], [8] which enable the identification of recurrent relations in a model transformation, supporting the definition of transformation rules in a reusable way [8].
The first group of criteria consists of: multiple source/ target, exogenous/ endogenous MT, mappings, and rules. It is critical to note that the papers we analysed provided little, or no clear information about the two first criteria. For those cases, we analysed the examples provided throughout the paper as the main reference to infer answers for this question. To simplify the reference to each approach, Table 1 enumerates approaches using numbers from (1) to (8). These numbers will identify their respective approaches from now on. Taking into consideration the support for multiple source/ target, only (2) explicitly stated the support for multiple source and targets by their mapping diagram. All other approaches suggested support for only single source/ target models. For example, (3) made clear the decision taken by a set of stated assumptions. Siikarla, (1), suggested his decision in a figure, used to explain his approach. Analysing the transformation patterns presented, none of them consider multiple source/ targets. For all other approaches, they suggested their decision by examples presented throughout the paper.
Regarding the type of transformation supported, most of approaches support only exogenous transformations. The only exception is (5), which presented only endogenous examples, suggesting that this approach aims at also supporting endogenous transformations. Examples presented by (2) suggested that it supports both types of transformations. Likewise, the patterns flattening and mapping, presented by (8), indicated that it supports both types of transformations.
As mappings and rules are core concepts in MT, both concepts are considered by all analysed approaches. The main difference in this regard lies in how these concepts are implemented by different approaches. For example, whereas (1) set up correspondence examples to map models, and transformation patterns to map meta-model, (6) specified mappings by test cases. Regarding rules, whereas (2) defined it in their low-level design, (3) proposed their automatic generation.
The second group of criteria consists of: language independence, phases covered, focus, artefacts, and tooling support. In the context of this paper, language independence means that the approach is not specific to a particular language for the source and target models/meta-models. Apart from (8), that defines its transformation patterns in the context of QVT, all other approaches are language independent -though the examples presented are based on a particular language, such as (1), that adopted UML. To analyse the phases of MT life cycle covered by approaches, we took into consideration the general process for developing MT, introduced in Section 1. The set of phases we included in this process is the result of an analysis of MT literature. Table 2 summarises the phases covered by each approach, and how each approach covers such phase.
Regarding the focus of each approach, although MT is defined at the metamodel level, most approaches focus on the model rather than the meta-model level. As Wimmer et al. explain in [20], meta-models might not define all language concepts explicitly. Regarding the approaches we analysed, the exception is (7), which focuses on the meta-model, and both (2) and (8), which address both model and meta-model. It is important to note that (8) described their patterns in terms of model, but the definition is made at meta-model level.
Approaches proposed a number of artefacts to support the developer. Table 1 shows the number of artefact types though it is central to note that this information is unclear in some papers, such as those which present (6), (4), and (5). Finally, regarding tool support, (1) and ( 7) do not require a particular tool. In the context of this analysis, requiring tool support means that the approach cannot be wholly applied without a particular tool. For example, (7) does not require a particular tool although it defines several automatic activities. Likewise, although (2) defines a family of languages, its MT development process is language independent. Unlike the other approaches, (2) generates automatically only test and traceability artefacts. In particular, by-example approaches define semi-automatic tasks, that require specific tools. Approach (6) also defined the use of specific tools, such as HUTN, EVL, and an adapted version of JUnit.
To evaluate the applicability of each approach, we considered four criteria: soundness, evaluation, level of technical detail, and the ability of the analysed approach Table 2. MT phases covered by each approach analysed to support another -like design patterns can support software development process. We define the soundness of an approach, using the following scale: (i) minimal -the paper introducing the approach provides very limited information about approach theoretical foundations; (ii) good -the paper justifies the decisions taken and reasons to underpin their decisions, even the information is limited; and (iii) excellent, meaning that the text not only describes decisions and their reasons, but also provides empirical evidence and basis from literature.
Taking into consideration this scale, only (2) was classified as having an excellent soundness whereas (8) was classified as having a good. This result becomes worse when analysed along with the next criterion, evaluation. None of by-example approaches were evaluated in the papers analysed. Apart from (2), which conducted two case studies, other approaches conducted feasibility analyses, taking into consideration worked examples. These two results highlight the need for empirical evidence to support future work in this area. This is particularly important for the industrial adoption of these approaches. However, note that these results do not invalidate the approaches. In fact, as discussed in Section 3, many of these ideas are valid and useful.
Aiming at the application of these approaches, we evaluated the level of technical detail provided in the paper. There are three possible classifications for this criterion: (i) minimal, when the text does not provide enough information to support the application of this approach; (ii) good, when the text provides enough information to support the application of this approach, though detailed information might be missing; and (iii) excellent, when the text not only provide enough information, but also further details about activities, such as examples. In this regard, ( 7) and ( 6) were classed as minimal. Approaches ( 2), (4), and (5) provide excellent information, supported by examples that complement the understanding. However, it is critical to point out that these three approaches rely on tooling support, and the knowledge regarding the tools might be not enough. The other three approaches were classified as good.
Finally, we analysed whether these approaches could support other approach. For example, a traditional software development process might be supported by several approaches, such as design patterns and graphical modelling languages. Apart from transformation patterns and the MT language (approach ( 2)), which by definition could be applied to support other approaches, all other approaches defined their particular, non-extendable, life-cycle. In some cases, such as that of ( 5), the need for tooling support creates additional dependency.
In this section, we summarise lessons learned while transforming a cloud model [13], defined as part of our approach to support cloud portability [15], into a TOSCA definition. Cloud computing is a computing model in which resources, such as computing, are provided as services through the Internet [1]. Topology and Orchestration Specification for Cloud Applications (TOSCA) is a standard specification supported by OASIS to enable cloud portability [2]. This section is based on our attempt to systematically apply the approaches previously presented. Lessons reported in this section complement the analysis in Section 2.
Comparing the generic MT process introduced in Section 1 with the traditional software development (TSD) life-cycle, such as waterfall [17], we can conclude that both processes are similar. A developer needs requirements to define the objectives, artefacts to guide the development, and tests to check for errors. Like the TSD, the code is the main artefact, which represents the MT definition. However, a number of questions arise when starting the requirement definition for a MT. In contrast to TSD, in which one defines several requirements, in MT, inicially, there is one single requirement: transform model A into model B.
In MT, the single requirement proposed must be broken down into several others, specifying that the entity X, in the meta-model A, will become the entity Z, in the meta-model B. To this end, the requirements diagram presented in [6] is a relevant contribution since it enables requirement decomposition and the creation of links between requirements to set up dependencies. However, to define such a mapping, it is necessary to have a clear understanding of semantic correspondences between the meta-models involved. Furthermore, unless these semantic correspondences have been tested before, establishing the requirements would be an error-prone task. For example, when we defined the requirements for our cloud-to-TOSCA MT, we did not know which TOSCA entity a cloud entity will become -though we knew very well both domains.
Thus, we had to analyse semantic correspondences of both meta-models before defining the requirements. In addition, we had to test if these correspondences made sense. In this regard, the test-driven approach proposed in [5] was useful. A test-case is an artefact which outlines these semantic correspondences. Then, by implementing the transformation, this initial assumption is confirmed or refuted. However, from a novice MT developer, the complexity involved in defining requirements for MT is far harder than in TSD. In addition, requirement definition and mapping definition are two close activities. Finally, M2M transformations might involve model-to-text transformations as well, making the process even more complex. Thus, despite the similarity with TSD, in our perspective, MT development requires extra artefacts and activities.
By-example approaches, in particular, advocate the use of models rather than meta-models as the main driver of a MT. Indeed, having two models, one representing a domain A, and another representing a domain B, aids the design of an A-to-B MT. However, creating these models is not trivial. Although it might be an intuitive process when creating a transformation from a UML class diagram to an E-R diagram -a common example used in the literature, other domains require a huge effort. In our case, we found it to be impossible to devise a TOSCA model based on our cloud model without an in-depth preliminary analysis of semantic correspondences. The reason for that is quite simple: a model conforms to a meta-model. Therefore, one cannot create a representation of model A, which conforms to meta-model A, in conformance with meta-model B unless the semantic correspondences between meta-models A and B are known beforehand.
For example, the by-example approaches proposed in [19] and [20], define in their first activities the creation of source and target models, and the mapping of entities between these models. In our case, we already had the cloud model, however, we expected to follow a well-defined MT process in deriving the TOSCA model (target). At that moment, we could infer that a cloud Service is similar to a TOSCA TNodeType, but we did not know correspondences for other entities, such as a cloud Region, and User. Thus, a process advocating the mapping of models to achieve meta-models correspondences was not applicable because without the meta-model correspondences it was impossible to derive the models.
In this regard, we learned that by-example approaches could be useful when meta-model correspondences are already known, and two well-known meta-models are given. Thus, models can be mapped and meta-model correspondences can be automatically generated using these approaches. On the other hand, the creation of two models is quite useful when designing MT as a way to validate meta-model mappings. For example, after identifying that a cloud Resource is equivalent to a TOSCA TNodeType, we created a TOSCA model representing this mapping. Then, we could validate the model in two ways: checking in the general context of TOSCA whether this transformation makes sense, and submitting the generated model to a TOSCA runtime environment. If the environment could process the specification, it meant that the transformation succeeded.
Although not yet addressing all MT development concerns, the analysed approaches provide very useful contributions. Overall, we concluded that, like MT area, the identified approaches are still maturing. As shown by Table 1, most of them were neither extensively evaluated nor sound enough. However, they provide several insights about performing MT, such as correspondence examples [12], requirements diagram [6], and test-cases [5]; -Testing is critical in MT as it is in TSD. It is important to carry out several tests when developing MT. In our experience, we identified problems with different datatypes (e.g., conversion of String to xs:string), names (space between nouns versus no space), and one entity in the source meta-model being mapped to several others in the target meta-model; -Capturing trace links between source and target model elements is a good practice for MT, particularly if a MT becomes complex. In our experience, one single entity in the cloud meta-model became three entities in the TOSCA meta-model, which in turn gave rise to several others. At the end, the set of dependencies created was so complex, that it was hard to validate them. Inspecting the trace model can help considerably in cases like this, as it enables to identify source and target entities.
In our investigation of M2M transformation development, we identified no study, either qualitative or quantitative, comparing approaches for MT development in phases other than implementation. This complicates the selection process of a suitable approach when developing MT, fostering the concept of "ad hoc" MT development. It becomes even harder when the MT developer has limited experience in this activity. To support the selection of an approach for MT development, we provided in this paper a qualitative analysis of eight state-ofthe-art approaches for MT development. This analysis took into consideration 13 criteria, classified in three groups: model transformation foundations, features and applicability. We complemented this analysis presenting the lessons learned from our own experience with developing a MT for cloud domain.
Acknowledgments. This work was funded in part by CNPq -Brazil.