Based on the responses of our interviewees and our analysis, we developed a framework to classify influence factors. It allows us to categorize how factors influence properties of MLTs and each other according to our interviewees. Note that we split the property Reuse & Maintainability into two properties for the purpose of reporting. This is done because interviewees chose to consider them separately. Thus reporting on them separately allows for presenting more nuanced results.
The factors themselves are split into six top-level factors namely GPL Capabilities, MTL Capabilities, Tooling, Choice of MTL, Skills and Use Case. The first factor, GPL Capabilities, encompasses sub-factors related to writing model transformations in general purpose languages. MTL Capabilities encompasses sub-factors that originate from transformation specific features of model transformation languages. Tooling contains factors surrounding tool support for MTLs. Choice of MTL details how the choice of language asserts its influence. The factor Skills encompasses sub-factors associated with skills. Lastly, the Use Cases factor contains sub-factors that relate to the involved use case an its influences.
Within the framework we differentiate between two kinds of factors. The first kind are factors, that have a positive or negative impact on properties of MTLs. These include the factors GPL Capabilities, MTL Capabilities and Tooling as well as their sub-factors. The second kind are factors that, depending on their characteristic, moderate how other factors influence properties, e.g. depending on the language, its syntax might have a positive or negative influence on the comprehensibility of written code. We call such factors moderating factors. These include the factors Choice of MTL, Skills and Use Case and their sub-factors.
Table 3 provides an overview over the answers given by our interviewees. The table shows factors on its rows and MTL properties on its columns. A + in a cell denotes, that interviewees mentioned the factor to have a positive effect on their view of the MTL property. A - means interviewees saw a negative influence and +/- describes that there have been mentions of both positive and negative influences. Lastly, a M in a cell denotes, that the factor represents a moderating factor for the MTL property, according to some interviewees. The detailed extent of the influence of each factor is described throughout Sections 5 and 6.
In the following we present all top-level factors and their sub-factors and describe their place within our framework. For each factor we detail its influence on properties of model transformation languages or on other factors, based on the statements made by our interviewees. All statements referred to in this section can be found verbatim in Table 5 in Appendix E.
Using general purpose languages for developing model transformations, as an alternative to using dedicated languages was extensively discussed in our interviews. Interviewees mentioned both advantages and disadvantages that GPLs have compared to MTLs that made them view MTLs more or less favourably.
The disadvantages of GPLs compared to MTLs stem from additional features and abstractions that MTLs bring with them and will be discussed later in Section 5.2. The advantages of GPLs on the other hand can not be placed within the MTL Capability factors. These will instead be presented separately in this section.
According to our interviewees, advantages of GPLs are a relevant factor for all properties of MTLs.
General purpose languages are better suited for writing transformations that require lots of computations. This is because they were streamlined for these kinds of activities and designed for this task, with language features like streams, generics and lambdas. As a result, general purpose languages are far more advanced for such situations compared to model transformation languages, which sacrifice this for more domain expressiveness [Qgpl1].
Much like the language design for GPLs, their tools and ecosystems are mature and designed to integrate well with each other. Moreover, according to several interviewees, their tools are of high quality making developers feel more Productive [Qgpl2].
Lastly, multiple participants noted, that there are much more GPL developers readily available for companies to hire, thus making GPLs more attractive for them. This helps the Maintainability of existing code as such experts are more likely to Comprehend GPL code [Qgpl3]. Whether this aspect also improves the overall Productivity of transformation development in a GPL was disagreed upon, because it might be that developers trained in a MTL could produce similar results with less resources.
It was also mentioned, that much more training resources are available for GPL development, making it easier to start learning and using a new GPL compared to a MTL.
The capabilities that model transformation languages provide that are not present in GPLs, are important factors that influence properties of the languages. This view is shared by our interviewees that raised many different aspects and abstractions present in model transformation languages.
The influence of capabilities specifically introduced in MTLs is diverse and depends on the concrete implementation in a specific language, the skills of the developers using the MTL and the use case in which the MTL is to be applied. We will discuss all the implications raised by our interviewees regarding the transformation specific capabilities of MTLs for the properties attributed to MTLs in detail, in this section.
Domain Focus describes the fact that model transformation languages provide transformation specific constructs, abstractions or workflows. Interviewees remarked the domain focus, provided by MTLs, as influencing Comprehensibility, Ease of Writing, Expressiveness, Maintainability, Productivity and Tool Support. But the effects can differ depending on the specific MTL in question.
There exists a consensus that MTLs can provide better domain specificity than GPLs by introducing domain specific language constructs and abstractions. This increases Expressiveness by lifting the problem onto the same level as the involved models allowing developers to express more while writing less. MTLs allow developers to treat the transformation problem on the same abstraction level as the involved modelling languages [Qdf1]. This also improves the ease of development.
Several interviewees argued, that when moving towards domain specific concepts the Comprehensibility of written code is greatly increased. The reason for this is, that because transformation logic is written in terms of domain elements, unnecessary parts are omitted (compared to GPLs) and one can focus solely on the transformation aspect [Qdf2].
Having domain specific constructs was also raised as facilitating better Maintainability. Co-evolving transformations written in MTLs together with hardware-, technology-, platform- or model changes is said to be easier than in GPLs because “Once you have things like rules and helpers and things like left hand side and right hand side and all these patterns then [it is] easier to create things like meta-rules to take rules from one version to another version [...]” (P23).
Domain focus also enforces a stricter code structure on model transformations. This reduces the amount of variety in which they can be expressed in MTLs. As a result, developing Tool Support for analysing transformation scripts gets easier. Achieving similarly powerful tool support for general purpose languages, and even for internal MTLs, can be a lot harder or even impossible because much less is known solely based on the structure of the code. Analysis of GPL transformations has to deal with the complete array of functionality of general purpose language constructs [Qdf4]. While MTLs can be Turing complete too, they tend to limit this capability to specific sections of the transformation code. They also make more information about the transformation explicit compared to GPLs. This allows for easier analysis of properties of the transformation scripts which reduces the amount of work required to develop analysis tooling.
The influence of domain abstractions on Productivity was heavily discussed in our interviews. Interviewees agreed that, depending on the used language, Productivity gains are likely, due to their domain focus. However, one interviewee explained that precisely because of Productivity concerns companies in the industry might use general purpose languages. The reason for this boils down to the Use Case and project context. Infrastructure for general purpose languages might already be set up and developers do not need to be trained in other languages [Qdf5]. Moreover, different tasks might require different model transformation languages to fully utilise their benefits, which, from an organisational standpoint, does not make sense for a company. So instead one GPL is used for all tasks.
According to our interviewees bidirectional functionality in a model transformation language influences its Comprehensibility, Ease of Writing, Expressiveness and Maintainability and Productivity. Its effects on these properties then depends on the concrete implementation of the functionality in a MTL. It also depends on the Skills of the developers and the concrete Use Case.
Our interviewees mentioned that the problem of bidirectional transformations is inherently difficult and that high level formalisms are required to concisely define all aspects of such transformations. Many believe that because of this solutions using general purpose languages can never be sufficient. Statements in the vein of “in a general purpose programming language you would have to add a bit of clutter, a bit of distraction, from the real heart of the matter” (P42) were made several times. This, combined with having less optimal querying syntax, then shifts focus away from the actual transformation and decreases both the Comprehensibility and Maintainability of the written code.
Maintainability is also hampered because GPL solutions scatter the implementation throughout two or more rules (or methods or files) that have to be adapted in case of changes [Qbx2]. Expressive and high level syntax in MTLs helps alleviate these problems and increases the ease at which developers can write bidirectional model transformations.
Interviewees also commented on the fact that, thanks to bidirectional functionalities, consistency definitions and synchronisations between both sides of the transformation can be achieved easier. This improves the Maintainability of modelling projects as a whole and allows for more Productive workflows. Manual attempts to do so have been stated to be error-prone and labour-intensive.
It was also pointed out that the inherent complexity of bidirectionality leads to several problems that have to be considered. MTLs that offer syntax for defining bidirectional transformations are mentioned to be more complex to use as their unidirectional counterparts. They should thus only be used in cases where bidirectionality is a requirement. Moreover, one interviewee mentioned that developers are not generally used to thinking in bidirectional way [Qbx3].
Lastly, the models involved in bidirectional transformations also play a role regardless of the language used to define the transformation. Often the models are not equally powerful making it hard to actually achieve bidirectionality between them, because of information loss from one side to the other [Qbx4].
Dedicated functionality in MTLs for executing incremental transformations has been discussed as influencing Comprehensibility, Ease of Writing and Expressiveness. Similar to bidirectionality its influence is again heavily dependent on the Use Case in which incremental languages are applied as well as the Skills of the involved developers.
Declarative languages have been mentioned to facilitate incrementality because the execution semantics are already hidden and thus completely up to the execution engine. This increases the Expressiveness of language constructs. It can, however, hamper the Comprehensibility of transformation scripts for developers inexperienced with the language because there is no direct way of knowing in which order transformation steps are executed [Qinc1].
On the other hand interviewees also explained that writing incremental transformations in a GPL is unfeasible. Manual implementations are error-prone because too many kinds of changes have to be considered and chances are high that developers miss some specific kind. Due to the high level of complexity that the problem of incrementality inherently posses interviewees argued that writing such transformations in MTLs is much easier [Qinc2].
The same argumentation also applied for the Comprehensibility of transformations. All the additional code required to introduce incrementality to GPL transformations is argued to clutter the code so much that developers “[will be] in way over their head[s]” (P13).
As with bidirectionality interviewees agreed, that the Use Case needs to be carefully considered when arguing over incremental functionality. Only when ad-hoc incrementality is really needed should developers consider using incremental languages. In cases where transformations are executed in batches, maybe even over night, no actual incrementality is necessary and then “general purpose programming languages are very much contenders for implementing model transformations” (P42). It was also explained that using general purpose languages for simple transformations is common practice in industry as they are “very good in expressing [the required] control flow” (P42) and because none of the aforementioned problems for GPLs have a strong impact in these cases.
The ability of a MTL to define mappings influences that languages Comprehensibility, Ease of Writing, Expressiveness, Maintainability and Reuse of model transformations. Developer Skills, the used Language and concrete Use Case also play an important role in the kind of influence.
Interviewees agreed, that the Expressiveness of transformation languages utilising syntax for mapping is increased due to them hiding low level operations [Qmap1]. However, as remarked by one participant, the semantic complexity of transformations can not be hidden by mappings, only the computational complexity.
According our interviewees mappings form a natural way of how people think about transformations. They impose a strict structure on how transformations need to be defined, making it easy for developers to start of writing transformations. The structure also aids general development, because all elements of a transformation have a predetermined place within a mapping. Being this restrictive has the advantage of directing ones thoughts and focus solely on the elements that should be transformed [Qmap2]. To transform an element, developers only need to write down the element and what it should be mapped to.
The simple structure expressed by mappings also benefits the Comprehensibility of transformations. It allows to easily grasp which elements are involved in a transformation, even by people that are not experienced in the used language. Trying to understand the same transformation in GPLs would be much harder because “[one] would not recognize [the involved elements] in Java code any more” (P32). Instead, they are hidden in between all the other instructions necessary to perform transformations in the language. Interviewees also mentioned that, due to the natural fit of mappings for transformations, it is much easier to find entry points from where to start and understand a transformation and to reconstruct relationships between input and output. This is aided by the fact that the order of mappings within a transformation does not need to conform with its execution sequence and thus enables developers to order them in a comprehensible way [Qmap3].
One interviewee explained that, from their experience, mappings lead to less code being written which makes the transformations both easier to comprehend and to maintain. However, they conceded that the competence of the involved developers is a crucial factor as well. According to them, language features alone do not make code maintainable. Developers need to have language engineering skills and intricate domain knowledge to be able to design well maintainable transformations [Qmap4]. Both are skills that too little developers posses.
Moreover, several interviewees raised the concern, that complex Use Cases can hamper the Comprehensibility of transformations. Understanding which elements are being mapped can be hard to grasp if several auxiliary functions are used for selecting the elements. Here one interviewee suggested that a standardized way of annotating such selections could help alleviate the problem.
It was also mentioned that, while mappings and other MTL features increase the Expressiveness of the language, they might make it harder for developers to start learning the languages. Because a lot of semantics are hidden behind keywords, developers need to first understand the hidden concepts to be able to utilise them correctly [Qmap5].
Other features that highlight how much Expressiveness is gained from mappings have also been mentioned. Mappings hide how relations between input and output are defined. This creates a formal and predictable correspondence between them and thus enables Tracing. Moreover, the correspondence between elements allows languages to provide functionality such as Bidirectionality and Incrementality [Qmap6].
Because many languages that utilise mappings can forgo definitions of explicit control flow, mappings allow transformation engines to do execution optimisations. However, one interviewee explained that they encountered Use Cases where developers want to influence the execution order, forcing them to introduce imperative elements into their code effectively hampering this advantage. It has also been mentioned that in complex cases the code within mappings can get complicated to the point where non experts are unable to comprehend the transformation again. This problem also exists for writing transformations as well. According to one interviewee mappings are great for linear transformations and are thus very dependent on the involved (meta-)models. Also in cases where complex interactions needs to be defined mappings do not present any advantage over GPL syntax and sometimes it can even be easier to define such logic in GPLs [Qmap7].
Lastly, mappings enable more modular code to be written. This in turn facilitates reuse, because reusing and changing code results in local changes instead of several changes throughout different parts of GPL code [Qmap8].
The ability in model transformation languages to automatically create and handle trace information about the transformation has been discussed by our interviewees to influence Comprehensibility, Ease of writing, Expressiveness and Productivity. However, the concrete effect depends on the MTL and the skill of users.
All interviewees talking about automatic tracing agreed that it increases the Expressiveness of the language utilising it. In GPLs this functionality would need to be manually implemented using structures like hash maps. Code to set up traces would then also need to be added to all transformation rules [Qtrc1].
However, interviewees disagreed on how much this actually impacts the overall transformation development. Most interviewees felt like automatic trace handling Eases Writing transformations and even increases Productivity since no manual workarounds need to be implemented. This is because manual implementation requires developers to think about when and in which cases traces need to be created and how to access them correctly. It also enables languages that allow developers to define rules independent from the execution sequence. One interviewee however felt like this was not as effort intensive as commonly claimed and thus automatic trace handling to them is more of a nice to have feature than a requirement for writing transformations effectively. Moreover, for complex Use Cases of tracing such as QvTs late resolve, the Users are required to understand the principle of tracing [Qtrc2]. And according to another interviewee teaching how tracing and trace models work is hard.
Comprehending written transformations can also be aided by automatic trace management. Manual implementations introduce unnecessary clutter into transformation code that needs to be understood to be able to understand a whole transformation. This is especially true if effort has been put into making tracing work efficiently, according to one interviewee. Understanding a transformation is much more straight forward when only the established relationships between the input and output domains need to be considered, without any additional code to setup and use traces [Qtrc3].
Lastly, one interviewee raised the issue that manual trace handling might be necessary to write complex transformations involving multiple source and target models, as current engines are not intended for such Use Cases.
Automatic Model Traversal
According to our interviewees, the automatic traversal of the input model to apply transformations influences Ease of Writing, Expressiveness, Comprehensibility and Productivity. They also explain that depending on the implementation in a concrete MTL the effects can differ. Use Cases are also mentioned to be relevant to the influence of automatic traversal.
Automatic model traversal hides the traversal of the input model and how and when transformations are applied to the input model elements. Because of this many interviewees expressed that this feature in MTLs increases their Expressiveness. The reduced code clutter also helps with Comprehensibility.
It also Eases the Writing of transformations because developers do not need to worry about traversing the input and finding all relevant elements, a task that has been described as complicated by interviewees. This can be of significant help to developers. One interviewee explained, that they ran an experiment with several participants where they observed model traversal to be “one of the biggest problems for test persons” (P49).
Not having to manually define traversal reduces the amount of code that needs to be written and thus increases the overall Productivity of development, according to one interviewee. However, there can also be drawbacks from this practice. Hiding the traversal automatically leads to the context of model elements to be hidden from the developer. In cases where the context contains relevant information this can be detrimental and even mask errors that are hard to track down [Qtrv1].
Lastly, automatic input traversal enables transformation engines to optimize the order of execution in declarative MTLs. And MTLs where no automatic execution ordering can be performed have been described as being “close to plain GPLs” (P52).
Some model transformation languages, such as Henshin, allow developers to define sub-graphs of the model graph, often using a graphical syntax, to be matched and transformed. This pattern-matching functionality influences the Comprehensibility, Expressiveness and Productivity, according to our interviewees. It is, however, strongly dependent on the specific language and Use Case. The feature is only present in a small portion of MTLs and brings with it its own set of restrictions depending on the concrete implementation in the language.
Pattern-matching functionality greatly increases the Expressiveness of MTLs. Similar to the basic model traversal no extra code has to be written to implement this semantic. However, the complexity of the abstracted functionality is even higher, since it is required to perform sub-graph matching to find all the relevant elements in a model. These patterns can also become arbitrarily complex and thus all interviewees talking about pattern-matching agreed that manual implementations are nearly impossible. Nevertheless one interviewee mentioned, that all languages they used that provided pattern-matching functionality (Henshin and TGG) had the drawback of providing no abstractions for resolving traces which takes away from its overall usefulness for certain Use Cases [Qpm1].
Not having to implement complex pattern-matching algorithms manually is also mentioned to increase the Productivity of writing transformations because this task is labour-intensive and error-prone.
Improvements for the Comprehensibility of transformations have also been recognized by some interviewees. They explained that the, often times graphical, syntax of languages with pattern-matching functionality allows to directly see the connection between involved elements. In GPLs this would be hidden behind all the code required to find and collect the elements. As such MTL code is “less polluted” (P52) than GPL code. Moreover, the Comprehensibility is also promoted by the fact that in some languages the graphical syntax shows the involved elements as they would be represented in the abstract syntax of the model.
Dedicated syntax for expressing model navigation has influence on the Comprehensibility and Ease of Writing of model transformations as well as on the Expressiveness of the MTL that utilises it.
Having dedicated syntax for model navigation helps to ease development as it allows transformation engineers to simply express which elements or data they want to query from a model while the engine takes care of everything else. Furthermore, it has been mentioned that this has a positive effect on transformation development because developers do not need to consider the efficiency of the query compared to when defining such queries using nested loops in general purpose languages [Qnav1].
Because languages like OCL abstract from how a model is navigated to compute the results of a query, interviewees attributed a higher Expressiveness to them than GPL solutions and described code written in these languages as more concise. Several interviewees attribute a better Comprehensibility to OCL as a result of this conciseness, arguing that well designed conditions and queries written in OCL are easy to read [Qnav2].
OCL has however also been criticised by an interviewee. According to them, the language is too practically oriented, misses a good theoretical foundation and lacks elegance to properly express ones intent. They explain that because of this, the worth of learning such a language compared to using a more common language is uncertain.
The impact of having to read and write models from and to files, i.e., model management, has been discussed by several interviewees. Automatic model management was discussed in our interviews as influencing the Comprehensibility, Ease of Writing and Expressiveness of model transformations in MTLs.
The argument for all three properties boils down to developers not having to write code for reading input models or writing output models, as well as the automatic creation of output elements and the order thereof. Interviewees agreed that implicit language functionality for these aspects raised the Expressiveness of languages. It reduces clutter when reading a written transformation and thus improving the Comprehensibility. Finally, developers do not have to deal with model management tasks, e.g. using the right format, that are not relevant to the actual transformation which helps with writing transformations [Qman1].
Mechanisms to reuse model transformations mostly influence the Reusability of model transformations in MTLs. Their concrete influence depends on the used Language and how reuse is handled in it. Interviewees also reported on cases where the users Skills with the language was relevant because novices might not be familiar with how the provided facilities can be utilised to achieve reuse.
There exists discourse between the interviewees about reuse mechanisms and their usefulness in model transformation languages. Several interviewees argued that MTLs do not have any reuse mechanisms that go beyond what is already present in general purpose languages. They believe that most, if not all, the reuse mechanisms that exist in MTLs are already present in GPLs and as such MTLs do not provide any reuse advantages [Qrm1]. According to them such reuse mechanisms include things like rule inheritance from languages like ATL or modules and libraries.
Other interviewees on the other hand suggested that while the aforementioned mechanisms stem from general purpose languages, they are still more transformation specific than their GPL counterpart. This is, because the mechanisms work on transformation specific parts in MTLs rather than generic constructs in GPLs [Qrm2, Qrm3]. Because of this focus, interviewees argue that they are more straight forward to use and thus improve Reusability in MTLs.
Interviewees also explained that there exist many languages that do not provide any useful reuse or modularisation mechanisms and that even in those that do it can be hard to achieve Reusability in a useful manner. However, one participant acknowledged that in their case, the reason for this might also relate to the inability of the Users to properly utilize the available mechanisms.
It has also been mentioned that reuse in model transformations is an inherently complex problem to solve. Transferring needs between two transformations which apply on different meta-models is difficult to do. As such, model transformation are often tightly tied to the domain in which they are used which makes reuse hard to achieve and most reuse between domains is currently done via copy & paste. This argument can present a reason why, as criticised by several interviewees, no advanced reuse mechanisms are broadly available.
The desire for advanced mechanisms has been expressed several times. One interviewee would like to see a mechanism that allows to define transformations to adapt to different input and output models to really feel like MTLs provide better reusability than GPLs. Another mentioned, that all reuse mechanisms conferred from object orientation rely on the tree like structure present in class structures while models are often more graph like and cyclic in nature. They believe that mechanisms that address this difference could be useful in MTLs.
Another disadvantage in some MTLs that was raised, is the granularity on which reuse can be defined. In languages like Henshin, for example, reuse is defined on a much coarser level than what is possible in GPLs.
Not having a central catalogue, similar to maven for Java, from which transformations or libraries can be reused, has also been critiqued as hindering reuse in model transformation languages.
The learnability of model transformation languages has been discussed as influencing the Ease of Writing model transformations.
It has been criticised by several interviewees, that the learning curve for MTLs is steep. This is, in part, due to the fact that users not only need to learn the languages themselves, but also accompanying concepts from MDE which are often required to be able to fully utilise model transformation languages. The learning curve makes it difficult for users to get started and therefore hampers the Ease of Writing transformations [Qler1]. This effect could be observed among computer science students at several of the universities of our interviewees. The students were described to having difficulties adapting to the vastly different approach to development compared to more traditional methods. A potential reason for this could be that people come into contact with MDE principles too late, as noted by an interviewee [Qler2].
While Tool Support is a MTL property that was investigated in our study, the tooling provided for MTLs, as well as several functional properties thereof, have been raised many times as factors that influence other properties attributed to model transformation languages as well. Most of the time this influence is negative, as tooling is seen as one of the greatest weak points of model transformation languages by our interviewees.
Many interviewees explained, that the most common languages do in fact have tools. The problem, however, lies in the fact that some helpful tools only exist for one language while others only exist for another language. As a result there is always some tool missing for any specific language. This leads people to feel like Tool Support for MTLs is bad compared to GPLs. Though there was one interviewee that explained that for their Use Cases, all tools required to be productive were present.
In the following, we will present several functional properties and tools that interviewees expressed as influential for Tool Support as well as other properties of MTLs.
Analysis tools are seen as a strong suit of MTLs. Their existence in MTLs is said to impact Productivity, Comprehensibility and perceived Tool Support.
According to the interviewees, some analyses can only be carried out on MTLs, as the abstraction in transformations in GPLs is not high enough and too much information is represented by the program logic and not in analysable constructs. As one interviewee explained, this comes from the fact that for complex analysis, such as validating correctness, languages need to be more structured. Nevertheless, participants mainly mentioned analyses they would like to see, which is an indication that, while the potential for analysis tools for MTLs is high, they do not yet see usable solutions for it, or are unaware of it. This is highlighted by one interviewee that explained that they are missing ways to check properties of model transformations, even though such solutions exist for certain MTLs [Qdb1].
A desired analysis tool mentioned in the interviews is rule dependency analysis and visualisation. They believe that such a tool would provide valuable insights into the structure of written transformations and help to better comprehend them and their intent. “What I would need for QVT-R, for example, in more complex cases, would be a kind of dependency graph.” (P32). Moreover two interviewees expressed the desire for tools to verify that transformations uphold certain properties or preserve certain properties of the involved models.
According to two interviewees, not having a central repository where transformations, written by other developers, can be browsed or downloaded, greatly hinders their view on the Reusability of model transformation languages. This is because it creates a barrier for reuse. For one thing, it is difficult to find model transformations that can be reused. Secondly, mechanisms that would simplify such reuse are then also missing. “I think what is currently missing is a catalogue or a tool like maven for having repositories for transformations so you can possibly find transformations to reuse.” (P14)
Debuggers have been raised as essential tools that help with the Comprehensibility of written model transformations. The existence of a debugger for a given language therefore influences its Tool Support as well as its Comprehensibility.
One interviewee explained that, especially for declarative languages, where the execution deviates greatly from the definition, debugging tools would be a tremendous help in understanding what is going on. In this context, opinions were also expressed that more information is needed for debugging model transformations than for traditional programming and that the tools should therefore be able to do more. Interviewees mentioned the desire to be able to see how matchings arise or why expected matches are not produced as well as the ability to challenge their transformations with assertions to see when and why expressions evaluate to certain values. “Demonstrate to me that this is true, show me the section of the transformation in which this OCL constraint is true or false.” (P28).
Valuable debugging of model transformations is mainly possible in dedicated MTLs, according to one interviewee. They argue that debugging model transformations in GPLs is cumbersome because much of the code does not relate to the actual transformation thus hampering a developers ability to grasp problems in their code.
The ecosystems around a language, as well as existing ecosystems, in which model transformations languages would have to be incorporated into, were remarked as mostly limiting factors for Productivity, Maintainability as well as the perceived amount of Tool Support.
One interviewee explained, that for many companies, adopting a model transformation language for their modelling concerns is out of the question because it would negatively impact their Productivity. The reason for this are existing ecosystems, which are designed for GPL usage. Moreover, it was noted that, to fully utilise the benefits of dedicated languages many companies would need to adopt several languages to properly utilise their benefits. This is seen as hard to implement as “people from industry have a hard time when they are required to use multiple languages” (P49) making it hard for them to maintain code in such ecosystems.
Ecosystems surrounding MTLs have also been criticised in hampering Productivity and perceived Tool Support. Several interviewees mentioned, that developers tend to favour ecosystems where many activities can be done in one place, something they see as lacking in MTL ecosystems. One interviewee even referred to this problem as the reason why they turned away from using model transformation languages completely [Qeco2].
This issue somewhat contrasts a concern raised by a different group of interviewees. They felt that the coupling of much of MDE tooling to Eclipse is a problem that hampers the adoption of MTLs and MDE. This coupling allows many tools to be available within the Eclipse IDE but, according to them, the problem lies in the fact that Eclipse is developed at a faster pace than what tool developers are able to keep up with, leaving much of the Tool Support for MTLs in an outdated state, limiting their exposure and usability [Qeco3].
One essential tool for Tool Support, Ease of Writing and Maintainability of MTLs are language specific editors in IDEs.
Several interviewees mentioned, that languages without basic IDE support are likely to be unusable, because developers are used to all the quality-of-life improvements, with autocompletion and syntax highlighting being the two most important features offered by such tools. Refactoring capabilities in IDEs, like renaming, have also been raised as crucial, especially for easing the Maintainability of transformations.
How well tools can be integrated with each other has been raised as a concern for the Tool Support of MTLs by several interviewees.
Interviewees see a clear advantage for GPLs when talking about interoperability between different MTL tools. They believe, that due to the majority of tools being research projects, little effort is spent into standardizing those in a way that allows for interoperability on the level that is currently provided for GPLs. “But the technologies, to combine them, it is difficult [...]” (P36). One interviewee described their first hand experience with this. They could not get a MTL to process models they generated with a software architecture tool because it produced non standard UML models which could not be used by the MTL. This problem has been echoed by another interviewee who explained that many MTLs do not work with non EMF compatible models.
A few interviewees talked about the availability of information about tools and the general awareness of which tools for MTLs exist. According to them, this strongly influences the perceived lack of Tool Support for model transformation languages in general.
When starting out with model transformations it can be hard to find out which tools one should use or even which tools are available at all. Two interview participants mention experiencing this first hand. They further explain that there exists no central starting point when looking for tools and tools are generally not well communicated to potential users outside of research [Qawa1].
Another interviewee suspected that the same problem also happens the other way around. They believe that some well designed MTL tools are completely unknown outside of the companies that developed them for internal use.
Tool Creation Effort
The amount of effort, that is required to be put into the development of MTL tools, has been raised by many interviewees as a reason why Tool Support for MTLs is seen as lacking.
All interviewees talking about the effort involved in creating tools for MTLs agree that there is a lot of effort involved in developing tools. This is not a problem in and of itself but, when comparing tooling with GPLs interviewees felt like MTLs being at a disadvantage. The disadvantage stems from the community for MTLs being much smaller and thus having less man power to develop tools which limits the amount of tools that can be developed. Several interviewees noted, that the only solution they see for this problem is industrial backing or commercial tool vendors because “I am keenly aware of the cost to being able to develop a good programming language, the cost of maintaining it and the cost of adding debuggers and refactoring engines. It is enormous.” (P1).
When comparing the actual effort for creating transformation specific tools, some interviewees explained that their experience suggests easier tool development for MTLs than for GPLs. They explained that, extracting the transformation specific information necessary for such tools out of GPL code complicates the whole process, whereas dedicated MTLs with their small and focused language core provide much easier access to such information [Qtce2].
The learning curve for someone starting off with MTLs and MTL tools is discussed as a heavy burden to the perceived effectiveness of Tools and even influences Ease of Writing.
Several interviewees criticised the fact that when starting off with a new MTL and its accompanying tools there is little support for users. Many tools lack basic documentation on how to set them up properly and how to use them. As a result users feel lost and find it difficult to start off writing transformations [Qtle1].
Related to the topic of learnability, the usability of tools for model transformation languages is discussed as influencing the quality of Tool Support for the languages as well as the Ease of Writing and Productivity.
To fully utilise the potential of MTLs useable tools are essential. Due to their higher level of abstraction, high quality tools are necessary to properly work with them and Write well rounded transformations [Quse1].
This is currently not the case when looking at the opinions of our interviewees talking about the topic of tool usability. There are tools available for people to start off with developing transformations but they are not well rounded and thus not ready for professional use, according to one interviewee. This is supported by several other interviewees opinions, many tools are faulty, which hinders the workflow and reduces Productivity [Quse2]. It has also been stated that if there were high quality useable tools available, they would be used. The reality for many users is, however, more in line with the experience of one interviewee who stated that they were unable to get many tools (for bidirectional languages) to even work at all.
A reason given for many of the criticised points surrounding MTL tools is their maturity. It is said to be a pivotal factor for everything related to Tool Support.
The maturity of tools for model transformation languages was commented on a lot. Tools need to be refined more in order to raze many of their current faults. The fact that this is not currently done relates back to the effort that is involved with it and the limited personnel available to do so. This is highlighted in an argument made by one of the interviewees who feels, that the community should not be hiding behind the argument of maturity [Qmat1].
Tools or frameworks to support the validation and testing of transformations written in MTLs have been discussed to influence the perceived Tool Support for nearly all MTLs.
Too much of the available tool support focuses solely on the writing phase of transformation development. There is little tool support for testing developed transformations, which has been raised as an area where much progress can, and has to be, made. Especially when comparing the current state of the art with GPLs, MTLs are seen as lacking [Qval1]. Not only are there little to no tools like unit testing frameworks, there is also too few transformation specific support such as tools to specifically verify binding or helper code in ATL.
Choice of MTL
The choice of MTL is an obvious factor that influences how other factors, such as the MTL Capabilities, influence the properties of model transformation languages. However, it should be explicitly mentioned, because it has been brought up countless times by interviewees while not often being considered in literature. Depending on the chosen model transformation language its capabilities and whole makeup changes, which has strong implications on all aspects of model transformation development.
A large number of the interviewees have commented on this. They either directly raised the concern, by prefacing a discussion with a statement such as “[...] it depends on the MTL”, or indirectly raised the concern, when comparing specific languages that do or do not exhibit certain capabilities and properties.
Skills of involved stakeholders is another group of factors that does not have a direct influence on how MTLs are perceived but instead plays a passive role. Many interviewees cited skills as a limiting factor to other influence factors. They argue that insufficient user skills could hinder advantages that MTLs can provide and might even create disadvantages compared to the more well-known and commonly used GPLs.
In this section we present the different types of skills mentioned by our interviewees as being relevant to the discussion of properties of model transformation languages.
The skill of developers in a specific model transformation language was raised by several interviewees as critical in facilitating many of the advantages provided through the languages capabilities. So much so that, according to them, the ability of developers to use and read a language can make or break any and all advantages and disadvantages of MTLs related to Comprehensibility, Ease of Writing, Maintainability and Reuseability.
Basic skills in any language are a prerequisite to being able to use it. They are also necessary to understand written code. There is no difference between GPLs and MTLs. It was however mentioned, that developers are generally more used to the development style in general purpose languages. Thus users need to learn how to solve a problem with the functionality of the model transformation language to be able to successfully develop transformations in a MTL [Qskl1]. This is especially relevant for complex transformations, where users are required to know of abstractions such as tracing or automatic traversal. Following on on this, one interviewee explained, that while learning the language is a requirement, using a new library, e.g. one for developing model transformations, in a GPL also entails learning and as such this must not be regarded as a disadvantage.
For reuse it is also paramount for users to know what elements of a transformation can be reused through language functionality. As a result the Reuseability is again limited by the knowledge of users in the specific language.
Lastly, being able to maintain a transformation written in an MTL also requires users to know the language to be able to understand where changes need to be made [Qskl2].
Apart from mastering a used language, the amount of experience users have with said languages and techniques also play a vital role in bringing out the full potential of said languages. Our interviewees discussed this for Ease of Writing, Maintainability and Productivity.
One interviewee explained that, from their experience, the amount of experience developers have with a language greatly impacts their Productivity when using said language. The problem for MTLs that results from this is the fact that there is little incentive for a person that is trying to build up their CV to spend much time on dedicated languages such as MTLs [Qexp1]. Developers are more inclined to learning and accumulating experience in languages that are commonly used in different companies to improve their chances of landing jobs. As a result people tend to have little to no experience in using MTLs. This in turn results in them having a harder time developing transformations in these languages, and the final product being of lower quality than what they could achieve using a GPL in which they have more experience in.
The problem is further exacerbated in teaching. “Many MDSE courses are just given too late, when people are too acquainted with GPLs, and then its really hard for students to see the point of using models, modelling and MTLs, because it’s comparable with languages and stuff they have already learned and worked with.” (P6).
Similar as the MTL itself and stakeholder Skills, the concrete Use Case in which model transformations are being developed is another factor that does not directly influence how properties of MTLs are being assessed. Instead, interviewees often mention that, depending on the Use Case, other influence factors could either have a positive or negative effect.
Use cases are distinguished along three dimensions. The complexity of involved models based on their structure, the complexity of the transformation based on the semantic gap between source and target, and the size of the transformation based on the use case. Depending on which differentiation is referred to by the interviewees, the considerations look differently.
Involved (Meta-) Models
The involved models and meta-models can have a large impact on the transformation and can hence heavily influence the advantages or disadvantages that MTLs exhibit.
Writing transformations for well behaved models, meaning models that are well structured and documented, can be immensely productive in a MTL while ‘badly’ behaved models bring out problems that require well trained experts to properly solve in a MTL. The UML meta-model was put forth as an example for such a badly behaved meta-model by one interviewee. According to them, transformations involving UML models can be problematic due to templates, which are model elements that are parametrized by other model elements, and eGenericType. The problem with these complex model elements is often worsened by low-quality documentation [Qmod1]. In cases where these badly behaved models are involved, many of the advantages from advanced features of MTLs can not be properly utilised without powerful tooling.
Semantic Gap Between Input and Output
Many interviewees formulate considerations based on the differentiation between ‘simple’ and ‘complex’ transformations in terms of the semantic gap that needs to be overcome. Transformations are considered simple when there is little semantic difference between the source and target models. Common comparisons read like: “transforming boxes into circles” (P32).
For simple transformations, model transformation languages are regarded as taking a lot of work off of the developers through the different language features discussed in Section 5.2. In more complex cases, transformations will get more complex and the developers experience gets more and more relevant, as more advanced language features need to be utilised, which can favour GPLs [Qgap1].
Others argue that the advantages of MTLs only really come into play in more complex cases or when high level features, such as bidirectionality or incrementality, are required. The reasoning for this argument is, that in simple cases the overhead of GPLs is not that prominent. Moreover, for writing complex transformations, dedicated query languages in MTLs are regarded by some to be much better than having to manually define complex conditions and loops in a GPL.
The Size of the transformation based on the Use Case is considered by some interviewees to be a relevant factor as well. In cases with many rules that depend on each other, MTLs are seen as having advantages [Qsiz1]. The size of transformations has been said to be a limiting factor for the use of graphical languages as enormous transformations would make graphical notations confusing. Modularisation mechanisms of languages also become a relevant feature in these cases.