Analysability | Positive | C1 | Declarative MTLs lend themselves to automatic analysis |
P45
| – |
Comprehensibility | Positive | C2 | Based on user feedback, it was identified that visual syntax is beneficial when reading a transformation program |
P43
| Experience |
C3 | Bidirectional transformation languages have an advantage in comprehensibility |
P44
| – |
C4 | Rules written in a declarative MTL are more easily understood in isolation and in combination |
P45
| – |
C5 | An observation made from the empirical data is that context selection and identification are easier for subjects working with MTLs than with GPLs |
P59
| Empirical study |
C6 | There are perceived cognitive gains of graphical representations compared to fully textual representations of transformations shown by for example the appeal of UMLs graphical representation of models |
P63
| – |
C7 | Model transformation languages incorporate high-level abstractions that make them more understandable than GPLs |
P95
| – |
Negative | C8 | Comprehensibility of transformation logic is hampered as current transformation languages provide only a limited view on a transformation problem. For example, graph transformation approaches only reveal parts of the meta-model |
P22
| – |
C9 | Most MTLs lack convenient facilities for understanding the transformation logic |
P22
| – |
C10 | Model transformation languages require specific skills and as a result are hard to understand for many stakeholders |
P27
| – |
C11 | Large and heterogeneous models lead to poorly understandable transformation code due to missing language concepts to master complexity |
P29
| – |
C12 | Graph transformations defined on abstract syntax are hard to read because the user has to be familiar with meta-model that defines the abstract syntax |
P70
| – |
C13 | Purely graph-based transformation languages can become complex and hard to read |
P70
| – |
Conciseness | Positive | C14 | General-purpose languages lack simplicity because of how transformations are defined |
P3
| Examples |
C15 | GPLs do not allow developers to conveniently express model manipulation concepts and the loss of abstraction in GPLs may give rise to accidental complexities |
P52
| Cites P673 |
C16 | Transformations implemented in the pre-study using rule-based MTLs were up to 48% smaller than corresponding Java variants |
P59
| Preliminary study |
C17 | Declarative approaches make language more concise |
P63
| – |
C18 | Graphical notation in MTLs is concise |
P75
| – |
C19 | GPLs do not conveniently express model manipulation concepts and the loss of abstraction can give rise to accidental complexities |
P80
| Cites 673 |
C20 | Model transformation languages incorporate high-level abstractions that make them more concise than GPLs |
P95
| – |
C21 | Model transformation languages are more concise |
P95
| – |
C22 | MDE and model transformation languages such as QVT help to reduce complexity |
P673
| – |
Debugging | Positive | C23 | Debuggers for MTLs are likely better than those for GPLs for debugging transformations since it is questionable whether the call stacks produced by debuggers of GPLs are meaningful for the developer |
P95
| – |
Negative | C24 | Although numerous transformation languages exist, they lack convenient facilities for supporting debugging and understanding of the transformation logic |
P22
| – |
C25 | In ATL, TGGs and QVT-R correspondence is defined on a higher level of abstraction compared to on what execution engines operate Thus debugging is limited on the lower level of the execution engines not on the level of the language definition |
P22
| – |
C26 | In declarative model transformation languages debugging is more difficult than in imperative ones |
P45
| – |
C27 | Model transformation languages lack proper debugging support since implementation cost is high |
P90
| – |
Ease of writing a transformation | Positive | C28 | We found graphical rule definition far more intuitive than syntax-based definition |
P3
| Experience |
C29 | Model transformation languages ease development efforts by offering succinct syntax to query from and map model elements between different modelling domains |
P29
| – |
C30 | Model transformation languages make it easy to work with models |
P50
| – |
C31 | Imperative transformation approaches offer a familiar paradigm, that is, sequence, selection, and iteration |
P63
| – |
C32 | It is our impression that, in general, graph transformations offer significantly better support for the specification and implementation of modelling guidelines and refactorings |
P672
| Experience |
Negative | C33 | Imperative MTLs induce overhead code because many issues have to be accomplished explicitly, e.g. specification of control flow |
P22
| – |
C34 | Traditional transformation languages require specific skills to be able to write transformations |
P27
| – |
C35 | To be able to write transformations, one has to be a transformation expert |
P28
| – |
C36 | Based on user feedback we identified that writing a transformation program with a graphical syntax can be complicated |
P43
| Experience |
C37 | The syntax of declarative MTLs is unfamiliar for many developers |
P45
| – |
C38 | Model transformation languages that define transformations on meta-model level require deep understanding of the meta-model |
P56
| – |
C39 | There is no sufficient (statistically significant) evidence of a general advantage of specialized model transformation languages (ATL, QVT-O) over a modern GPL (Xtend) |
P59
| Empirical study |
C40 | Developers are generally more comfortable with encoding complicated (transformation) algorithms in procedural languages |
P63
| – |
C41 | First of all, some of us are not convinced that the usage of a visual notation has significant advantages compared to a textual notation. A textual notation is more compact, simplifies all kinds of version and configuration management tasks, and does not force its users to spend hours beautifying the layout of huge diagrams |
P672
| – |
Expressiveness | Positive | C42 | Rule-based approaches seem to be less error-prone compared to a manual implementation of pattern matching for each transformation in a general-purpose language |
P2
| – |
C43 | Model transformation languages can hide details like traversing behind simple syntax |
P15
| – |
C44 | Model transformation languages can hide traces behind simple syntax |
P15
| – |
C45 | Model transformation languages can hide rule triggering behind simple syntax |
P15
| – |
C46 | Model transformation languages can hide rule ordering behind simple syntax |
P15
| – |
C47 | Model transformation languages can hide complex transformation algorithms behind a simple syntax |
P15
| – |
C48 | Model transformation languages hide transformation complexity and burden from user |
P27
| Cites P671 |
C49 | Graph transformations generally offer a significantly better support for the specification and implementation of modelling guidelines and refactorings |
P40
| Cites P672 |
C50 | Declarative MTLs allow automatic traceability management |
P45
| Cites P677 |
C51 | Declarative model transformation languages allow for implicit rule ordering lessening the load on developer |
P45
| Cites P677 |
C52 | Declarative MTLs can do implicit target object creation |
P45
| Cites P677 |
C53 | Declarative MTLs allow for implicit source model traversal |
P45
| Cites P677 |
C54 | Model transformation languages syntax is more specific |
P52
| – |
C55 | GPLs do not allow developers to conveniently express model manipulation concepts |
P52
| – |
C56 | We found that copying complex structures is more effective in MTLs |
P59
| Empirical study |
Expressiveness | Positive | C57 | General-purpose languages lack suitable abstractions for specifying transformations |
P63
| – |
C58 | Graph-based MTLs are especially popular due to their high expressive power |
P70
| – |
C59 | Model transformation languages have more specific language constructs |
P80
| – |
C60 | Model transformation languages have a higher level of abstraction which leads to gains in expressiveness over GPLs |
P80
| Cites P675 |
C61 | Model transformation languages are easier to use than GPLs |
P80
| Cites P675 |
C62 | Model transformation languages transformation constructs are more specific |
P94
| – |
C63 | From our perspective, automatic handling/resolution of traces by transformation engine is one of the major features that make existing MTLs better suited for model transformations than GPLs |
P95
| – |
C64 | General-purpose languages lack sufficient transformation concepts |
P95
| – |
C1D | DSLs trade expressiveness in a limited domain for generality |
P675
| Cites P804 |
C65 | GPLs lack suitable abstractions for specifying transformations |
P677
| Cites P63 |
C66 | With a DSL/MTL, a programmer can express their objective in a concise manner using a language that is much higher in expressiveness than that typically offered in a transitional programming language |
P804
| – |
Negative | C67 | Having written several transformation, we have identified that current MTLs are too low a level of abstraction for succinctly expressing transformations between DSLs because they demonstrate several recurring patterns that have to be reimplemented each time |
P10
| Experience |
C68 | Having written several transformation, we have identified that mapping a single element to fragments of multiple elements has to be done programmatically which is counterintuitive and error-prone |
P10
| Experience |
C69 | OCL constraints cannot be transformed in MTLs |
P32
| Empirical Study |
C70 | There is no mechanism for describing and/or storing information about the properties of a transformation |
P33
| – |
Extendability | Negative | C71 | Extending model transformation languages is difficult |
P50
| – |
Just better | Positive | C72 | GGT (graph grammar and graph transformation) are a powerful technique for specifying complex transformations |
P9
| Cites P664-P666 |
C73 | General-purpose programming languages are not suitable for defining model transformations |
P23
| Cites P63 |
C74 | GPLs are not well suited for model migration |
P34
| Examples |
C75 | Dedicated MTLs offer the most potential transformation approach because the languages can be tailored for the purpose |
P63
| – |
C76 | In order to transform models in a GPL, one has to add increasing amounts of machinery, e.g. to keep track of which elements have already been transformed. This leads to the assumption that model transformations cannot be sensibly written in a standard programming language |
P64
| Examples |
C77 | Model transformations present a number of problems which imply that dedicated approaches are required |
P66
| Cites P64 |
C78 | The current consensus is that specialized languages with a mixture of declarative and imperative constructs are most suitable for specifying model transformations |
P86
| – |
C79 | With the help of an example, we have shown that GGT (graph grammar and graph transformation) can be used to transform PIMs into PSMs |
P664
| Examples |
C2D | DSLs open up the application domain to a larger group of developers |
P675
| Cites P803 |
C3D | Domain-specific languages increase the ease of use |
P675
| Cites P803 |
C4D | When using DSLs, less errors are made |
P803
| Empirical Study |
Negative | C80 | General-purpose MTLs are not well suited for model migration since there is additional overhead but dedicated migration languages are |
P34
| Examples |
Learnability | Negative | C81 | The generality of general-purpose MTLs can have the effect of making them less approachable and create a steep learning curve for non-expert users |
P30
| – |
C82 | Users have to learn multiple similar, but not always consistent, languages, which requires considerable time to learn |
P52
| – |
C83 | Model transformation languages have a steep learning curve |
P58
| – |
C84 | One has to learn a completely new language to transform models with MTLs |
P81
| – |
Performance | Positive | C85 | Model transformation languages are more performant |
P95
| Cites P676 |
C86 | GrGen shows a better performance of transformations than Java |
P676
| Samples |
C5D | DSLs have better performance |
P801
| – |
Negative | C87 | Declarative MTLs have performance problems |
P45
| – |
C88 | The performance of model transformation languages is a shortcoming that may make users feel limited |
P52
| – |
C89 | MTLs have worse performance |
P80
| – |
Productivity | Positive | C90 | Model transformation languages being DSLs improve the productivity |
P29
| – |
C91 | Declarative MTLs increase programmer productivity |
P45
| – |
C6D | DSLs increase productivity |
P675
| Cites P801, P803 |
C7D | Using DSLs increases productivity |
P801
| Examples |
C8D | Using DSLs increases productivity |
P803
| Empirical Study |
Negative | C92 | The perceived effectiveness of model transformation languages is bad |
P32
| Empirical Study |
C93 | Productivity of GPL development might be higher since expert users for GPLs are easier to hire |
P59
| – |
Reuse and Maintainability | Positive | C94 | Bidirectional model transformations have an advantage in maintainability |
P44
| – |
C95 | There exists a plethora of reuse mechanisms for MTLs |
P77
| Literature review |
C9D | Domain-specific languages reduce the maintenance costs |
P675
| Cites P800 |
Negative | C96 | Reuse is sparse, transformations are written from scratch every time because meta-models differ slightly |
P4
| Cites P77 |
C97 | Having written several transformation, we have identified that recurring patterns have to be implemented from scratch every time |
P10
| Experience |
C98 | There exists no module concept for model transformation languages that allows programmers to control information hiding and strictly declare model and code dependencies at module interface |
P29
| – |
C99 | Model transformation languages lack sophisticated reuse mechanisms |
P33
| – |
C100 | Unfortunately, the definition of model transformations is normally a type-centric activity, thus making their reuse for other meta-models difficult |
P41
| – |
C101 | Evolving and maintaining MTL requires effort |
P52
| Cites P674 |
C102 | The emphasis of MDE on using DSLs has caused a proliferation of meta-models. In this scenario, developing a transformation for a new meta-model is usually performed manually with no reuse, even if comparable transformations for similar meta-models exist |
P60
| – |
C103 | There are barriers such as insufficient abstraction of reuse mechanisms from meta-models that hamper reuse |
P77
| Literature review |
C104 | There is little support for reusing model transformations in different contexts since they are tightly coupled to the meta-models they are defined upon |
P78
| – |
C105 | Reuse of model transformations is hardly established in practice |
P95
| Cites P77 |
C106 | Developing these new languages to a sufficient degree of maturity is an enormous effort which includes for example construction and optimisation of compilers |
P674
| – |
Semantics and Verification | Positive | C107 | Bidirectional transformation languages have an advantage in verification |
P44
| – |
Negative | C108 | For existing relational model transformation approaches, it is usually not really clear under which constraints particular implementations really conform to the formal semantics |
P21
| – |
C109 | Comprehensive verification support of model transformations is missing |
P22
| – |
C110 | There is a semantic difference between a typical programming language and formalisms that support bidirectionality and change propagation such as TGGs |
P23
| – |
C111 | Most transformation languages have no formal semantics to add detailed specifications on the expected behaviour |
P39
| – |
C112 | The semantics of many model transformation languages is not formally defined |
P58
| – |
Tool Support | Positive | C113 | Internal MTLs can inherit tool support of general-purpose host language |
P23
| – |
C114 | Tool support for external transformation languages is potentially more powerful than for internal MTL or GPL because it can be tailored to the DSL |
P44
| – |
C115 | Declarative MTLs provide opportunities for specialized tool support |
P45
| – |
Negative | C116 | Model transformation languages lack tool support |
P23
| Cites P669,P670 |
C117 | Declarative MTLs lack libraries and tool support |
P45
| – |
C118 | Model transformation languages lack tool support |
P52
| – |
C119 | Supporting tools for MTLs have not the same level of maturity as for GPLs |
P74
| – |
C120 | Model transformation languages have worse tool support |
P80
| Cites P94 |
C121 | Tool support for external MTLs has to be developed which entails extra effort |
P94
| – |
C122 | Tool support for model transformations is not as mature as subjects would like |
P669
| Empirical study |
C123 | Tool support for model transformations is not great |
P670
| Empirical study |
Versatility | Negative | C124 | The syntax of model transformation languages is less versatile |
P52
| – |
C125 | Model transformation languages are less versatile than GPLs |
P80
| – |
C126 | Model transformation languages have less versatile language constructs |
P80
| – |
C127 | Model transformation languages constructs are less versatile |
P94
| – |
C10D | DSLs are less general than general-purpose programming languages |
P675
| – |