Advantages and Disadvantages of (Dedicated) Model Transformation Languages A Qualitative Interview Study

1 Introduction

• Prior literature claims many advantages and disadvantages for MTLs, but only a few studies investigate how far those claims hold.The claims concern properties including comprehensibility, expressiveness, productivity, tool support, and reuse and maintainability.Source: §1 · p. 2
• Many published claims omit their context and reasoning, leaving unclear why and when an MTL advantage or disadvantage applies.This lack of context also makes proper evaluation difficult.Source: §1 · p. 2
• Semi-structured interviews with 56 researchers and practitioners elicited views and reasons about literature-based MTL claims across six selected properties.The researchers qualitatively analyzed responses for factors affecting individual claims and MTL properties more broadly.Source: §1 · p. 2
• The paper contributes a factor categorization, explanations of how factors affect MTL properties, suggestions for empirical investigation, and proposals for language improvement.The investigated properties are comprehensibility, ease of writing, practical expressiveness, productivity, reuse and maintainability, and tool support.Source: §1 · pp. 2–3
• The study identifies many factors that influence MTL properties, plus moderating factors that change the context in which those influences apply.The authors say these findings can guide focused studies and decisions about where MTLs need improvement.Source: §1 · p. 3

2.1 Model-driven engineering

• Model-driven development uses models to describe problem domains and develop solutions; meta-models define model structure, with MOF supporting modelling frameworks.The background presents models as central development artefacts and frames transformations as part of this approach.Source: §2.1 · p. 3

2.2 Domain-specific languages

• Domain-specific languages tailor notation and constructs to a domain, aiming to let developers work with domain concepts and ease development.They are presented as potential alternatives to general-purpose tools for domain-specific problems.Source: §2.2 · p. 3

2.3 Model transformation languages

• MTLs are domain-specific languages for transformations, with explicit constructs for tasks such as model matching and features such as directionality and rule organization.The paper introduces only features relevant to its study; Table 1 provides an overview.Source: §2.3 · p. 4, Table 1 · p. 4

2.3.1 External and Internal transformation languages

• Internal MTLs are embedded in a host language, whereas external MTLs are independent and have their own compiler or virtual machine.Examples include FunnyQT embedded in Clojure and ATL as an external language.Source: §2.3.1 · p. 4

2.3.2 Transformation Rules

• MTL transformation rules are dedicated mapping constructs, unlike GPL functions or methods, whose transformation role may require inspecting their contents.ATL rules map Member elements to Male or Female elements.Source: §2.3.2 · pp. 4–5

2.3.3 Rule Application Control: Location Determination

• Location determination ranges from automatic traversal matching individual elements to pattern matching that finds subgraphs for rule application.Henshin uses graph patterns to match connected model elements, while ATL applies rules to individual matching elements.Source: §2.3.3 · p. 5

2.3.4 Directionality

• Transformations may be unidirectional or multidirectional; QVT-R relates elements across domains, while ATL defines input-to-output execution in one direction.Some languages support execution in both directions from one definition; others require rules for each direction.Source: §2.3.4 · pp. 5–6

2.3.5 Incrementality

• Incrementality updates existing models after source changes without rerunning the whole transformation, requiring monitoring and rule-to-model information.Changes can trigger corresponding rules, with additional management potentially needed to maintain model validity and consistency.Source: §2.3.5 · p. 6

3.1.1 Identifying the appropriateness of semi-structured interviews

• Semi-structured expert interviews elicited participants’ opinions and reasoning, and transcripts were analysed using Kuckartz’s qualitative content analysis framework.The researchers chose interviews to support open-ended follow-up questions, and selected Kuckartz (2014) for its detailed analysis procedures.Source: §3.1.1 · p. 7, §3 · p. 7

3.1.2 Retrieving previous knowledge

• A prior structured literature review categorized 127 claims into 15 MTL properties, which formed the basis for the interview study.The review’s categories included comprehensibility, expressiveness, productivity, reuse and maintainability, and tool support.Source: §3.1.2 · p. 8

3.1.3 Interview guide

• The guide presented literature-derived claims for agreement ratings and open-ended reasons; non-specific claims broadened discussion beyond the claims’ narrow framing.Six properties were selected to keep interviews within a manageable length, and pilot testing led to adding non-specific claims and replacing yes/no agreement questions with a Likert scale.Source: §3.1.3 · pp. 8–11

3.1.4 Selecting & contacting participants

• The study contacted 645 potential participants and received 55 acceptances, an 8.53% response rate; it conducted 54 interviews with 55 interviewees and collected one written response.Including the written response in the response-rate calculation yielded 8.68%.Source: §3 · p. 7, §3.1.4 · p. 11, §3.2 · p. 11

3.2 Interview Conduction and Transcription

• Interviews lasted 20–80 minutes and produced just over 32 hours of audio and about 162,100 transcript words; question sets were distributed across participant backgrounds.At least one participant from each demographic group answered each question set, though a uniform distribution was not possible.Source: §3.2 · pp. 11–12

3.3.1 Initial Text Work

• Two authors initially coded transcript segments where interviewees reasoned about influences on properties, using concise codes that preferably reflected participants’ wording.The coding and analysis followed Kuckartz’s seven-step process with MAXQDA support.Source: §3.3.1 · p. 12, §3.3 · p. 12

3.3.2 Developing thematic main codes

• The researchers defined three thematic code families: properties discussed, factors influencing them, and assessments of those factors’ effects.Property sub-codes were deductively based on the six properties selected from the earlier literature review.Source: §3.3.2 · p. 12

3.3.3 Coding of all the material with main codes

• One author coded all transcripts by property, refining factor and factor-assessment codes later and prioritizing speed while limiting subsequent analysis to overlapping relevant codes.This departed from Kuckartz’s specifications by coding property sub-codes directly and including initially unimportant segments, which the later overlap-based analysis excluded.Source: §3.3.3 · pp. 12–13
• The initial coding assigned statements an essence-summarising code and an explicit property sub-code such as Expressiveness, supporting systematic categorisation.Source: §3.3.3 · p. 13

3.3.4 Compilation of all text passages coded with the same main code

• MAXQDA was used to compile passages sharing a main code, providing the basis for inductively developing its sub-codes.The authors describe this compilation step as technical, requiring selection of the main code under consideration in the tool.Source: §3.3.4 · p. 13

3.3.5 Inductive development of sub-codes

• Sub-codes were developed inductively from initial codes, with thematic codes identifying named factors and evaluative codes capturing how participants believed factors affected properties.Three authors developed codes from 18 interviews through discussion, analysed the remaining transcripts, and reached consensus on the complete code system.Source: §3.3.5 · p. 13

3.3.6 Coding of all the material with complete code system

• The main author recoded all transcripts using the final code system, while co-authors checked samples for consistent coding and relevant statements.Review findings were discussed pairwise and incorporated into a final coding approved by all authors; example codes included Expressiveness, Traceability, and MTL advantage.Source: §3.3.6 · pp. 13–14

3.3.7 Simple and complex analysis and visualisation

• The analysis examined factors for each property individually, then used theoretical coding to develop a model of influences across properties and their potential interactions.For each property, the authors used MAXQDA to find segments coded with both a factor and that property, then analysed commonalities and contradictions; cross-property analysis compared factor assessments.Source: §3.3.7 · p. 14

3.3.8 Privacy and Ethical concerns

• Participants received information about data collection, data handling, and their rights before interviews, and consented to recording, transcription, and analysis.Recordings were encrypted and deleted after transcription, transcripts were processed to remove identifying details, and no sensitive information beyond voices and names was collected.Source: §3.3.8 · p. 14

4.1 Background

• Research-background participants formed the largest group, although only 3 had used transformations solely in industry and 25 had industry contact through projects or work.The authors note that the sample lacked industry practitioners, but many interviewees could still offer an industry view.Source: §4.1 · p. 15, Figure 6 · p. 15

4.2 Experience

• 50 interviewees had at least 5 years of model-transformation experience, including 24 with over 10 years.One participant had used model transformations only briefly during a master's thesis.Source: §4.2 · p. 15

4.3 Used languages for transformation development

• 52 participants had used dedicated MTLs, compared with 27 who had used GPLs and 5 who had used internal MTLs for transformations.Participants could report more than one language; ATL was the most-used dedicated MTL (37 participants), followed by Henshin (17).Source: §4.3 · pp. 15–16
• Among GPLs, Java was most used (14 participants), followed by Xtend (12); Java Emitter Templates was reported by 4.The study's figures summarize dedicated MTL and GPL usage separately.Source: §4.3 · p. 16, Figure 8 · p. 16, Figure 9 · p. 16
• Only four internal MTLs were mentioned, and none was used by more than two interviewees.The authors describe internal MTLs as lacking prominence among participants' reported languages.Source: §4.3 · p. 16

5.1 GPL Capabilities

• GPLs were viewed as better for computation-heavy transformations, while mature tools and ecosystems can improve productivity and hiring availability can support maintainability; productivity effects of hiring were disputed.Interviewees also cited more plentiful GPL training resources as making it easier to learn a new language.Source: §5.1 · p. 17

5.2.1 Domain Focus

• MTL domain-specific constructs can raise expressiveness and ease development by matching the abstraction level of the models, while simplifying code and enabling stronger analysis tooling.Effects vary by MTL; existing GPL infrastructure and skills may nevertheless make one GPL more practical across an organization’s use cases.Source: §5.2.1 · pp. 17–19, §5.2 · p. 17

5.2.2 Bidirectionality

• Bidirectional MTL features can ease writing and improve consistency, but their complexity, developer skills, use case, and unequal model capabilities can limit their benefits.High-level syntax can avoid scattered GPL implementations, while bidirectional features should be used only when required; information loss between models can prevent true bidirectionality.Source: §5.2.2 · p. 19

5.2.3 Incrementality

• Incremental MTLs can make complex transformations easier to express and write than error-prone manual GPL implementations, although hidden execution order may hinder comprehension.Their use should depend on need: batch or simple transformations may not require incrementality, and GPLs can remain suitable in those cases.Source: §5.2.3 · pp. 19–20

5.2.4 Mappings

• Mappings can improve expressiveness, ease writing, comprehension, and reuse by structuring transformations around corresponding elements, but complex use cases, hidden semantics, and limited developer expertise can undermine these benefits.Mappings can support tracing, bidirectionality, incrementality, and execution optimization; imperative control-flow needs or complex interactions may reduce their advantage over GPLs.Source: §5.2.4 · pp. 20–21

5.2.5 Traceability

• Automatic trace handling can increase expressiveness and ease writing and comprehension by avoiding manual trace code, though its productivity value is disputed and complex or multi-model cases may still require manual handling.Some developers must understand tracing principles, and interviewees noted that teaching trace models can be difficult.Source: §5.2.5 · p. 21

5.2.6 Automatic Model Traversal

• Automatic model traversal can reduce code clutter and the effort of finding relevant elements, but hiding element context may mask errors that are difficult to diagnose.Its effects depend on the MTL implementation and use case.Source: §5.2.6 · pp. 21–22
• Automatic input traversal lets engines optimize execution order in declarative MTLs; without automatic ordering, some MTLs are described as close to plain GPLs.Source: §5.2.6 · p. 22

5.2.7 Pattern-Matching

• Pattern matching can increase expressiveness, productivity and comprehensibility by avoiding manual algorithms and making model-element connections visible, but its benefits depend on language and use case.Patterns can become arbitrarily complex, making manual implementations nearly impossible; Henshin and TGG were also criticized for lacking trace-resolution abstractions in some use cases.Source: §5.2.7 · p. 22

5.2.8 Model Navigation

• Dedicated navigation syntax abstracts model queries, easing development and often improving expressiveness and comprehensibility, though one interviewee questioned OCL’s elegance, theoretical basis and value to learn.The query engine handles navigation and efficiency concerns that developers would otherwise face with nested loops.Source: §5.2.8 · p. 22

5.2.9 Model Management

• Automatic model management improves expressiveness, comprehensibility and ease of writing by handling model input/output, output-element creation and ordering, and file-format concerns.Source: §5.2.9 · p. 22

5.2.10 Reuse Mechanism

• Interviewees disagreed on reuse benefits: some saw no advantage over GPLs, while others said transformation-specific mechanisms are more direct; availability, granularity, catalogues and user skills also constrain reuse.Some languages lack useful mechanisms, reuse can be coarse-grained, and interviewees cited the absence of a central catalogue as a hindrance.Source: §5.2.10 · p. 23
• Reuse remains difficult because transformations are tied to their domains and meta-models, so cross-domain reuse often relies on copy-and-paste and interviewees called for more advanced mechanisms.Potential improvements mentioned include adapting transformations to different input and output models and addressing models’ graph-like, cyclic structure.Source: §5.2.10 · p. 23

5.2.11 Learnability

• A steep learning curve, including the need to learn MDE concepts, makes it harder to start writing transformations; interviewees also reported student difficulties adapting to this development approach.Source: §5.2.11 · p. 23

5.3 Tooling

• Tooling is viewed as a major MTL weakness because helpful tools are fragmented across languages, although one interviewee had everything needed for their use case.The reported gaps concern tool coverage rather than a total absence of tools.Source: §5.3 · pp. 23–24

5.3.1 Analysis Tooling

• MTL structure can support analyses difficult in GPLs, but interviewees often wanted usable analysis tools, including dependency visualization and transformation-property checks.Interviewees described a potential advantage, while some were unaware of existing solutions for certain MTLs.Source: §5.3.1 · p. 24

5.3.2 Code Repositories

• The absence of a central repository makes transformation libraries harder to find and reuse, and leaves reuse mechanisms missing.Interviewees compared the desired resource to maven-central or npm.Source: §5.3.2 · p. 24

5.3.3 Debugging Tooling

• Debuggers aid comprehensibility, especially for declarative transformations where execution may diverge from the definition and developers need to inspect matching and expression behavior.Interviewees also wanted assertions and more transformation-specific debugging information.Source: §5.3.3 · p. 24

5.3.4 Ecosystem

• Ecosystem concerns include outdated Eclipse-coupled tools, weak interoperability with other tools and models, and difficulty finding available tooling.Some interviewees favored integrated ecosystems, while others reported that platform changes left tools outdated.Source: §5.3.4 · p. 25, §5.3.6 · p. 25, §5.3.7 · p. 25

5.3.5 IDE Tooling

• IDE support, onboarding, usability, and testing remain important gaps: basic editing aids are expected, while faulty tools and limited testing support hinder development.Interviewees described poor documentation for getting started and a shortage of unit-testing and transformation-specific validation tools.Source: §5.3.5 · p. 25, §5.3.9 · p. 26, §5.3.10 · p. 26

5.3.8 Tool Creation Effort

• MTL tool development is effort-intensive for a small community, though focused language cores can make transformation-specific tools easier to build than tools for GPL code.Interviewees linked limited staffing to the amount of tooling available and to unresolved tool faults.Source: §5.3.8 · p. 25, §5.3.11 · p. 26

5.5 Skills

• Stakeholder skills and use-case complexity affect whether MTL advantages are realized; simpler transformations may favor MTL features, while complex cases make experience and advanced capabilities more consequential.Interviewees also described advantages for MTLs in complex cases requiring features such as bidirectionality or incrementality, and for large transformations with interdependent rules.Source: §5.5 · p. 26, §5.5.2 · p. 27, §5.6 · p. 27

6 Cross-Factor Findings

• The structure model maps factors to MTL properties and shows which factors moderate each influence.It treats identified factors as explanatory variables and MTL properties as outcomes.Source: §6 · p. 28
• MTL advantages from domain-specific capabilities depend on the use case, chosen language, and user skills; tooling can support those advantages, but availability and quality remain major problems.General-purpose language versatility may overshadow MTL benefits in some contexts.Source: §6 · p. 28

6.1 The Effects of MTL Capabilities

• Domain-specific capabilities can avoid manual implementation, reduce code clutter, foreground input-output mappings, and address transformation-specific problems such as synchronization.These capabilities were regarded as opportunities for better support in developing transformations.Source: §6.1 · p. 29
• MTL-specific problem-solving styles can be unfamiliar to programmers trained in imperative languages, while domain-specificity can make transformations hard to reuse across use cases.The paper links these difficulties to limited exposure to logical and functional programming concepts.Source: §6.1 · p. 29
• Tooling can facilitate properties beyond tool support, and interviewees regarded available-tool quality as affecting all aspects of an MTL.The paper notes usability, maturity, and interoperability problems in prior empirical studies of MDE tools.Source: §6.2 · p. 29
• Good MTL tools are scarce, language-specific, and poorly integrated, often splitting development across workflows; their development is constrained by effort and a small community.The paper also notes a lack of large commercial vendors able to fund commercially viable tools.Source: §6.2 · p. 29

6.3 The Importance of Moderating Factors

• Use case, skills, and MTL choice shape whether language features support properties such as comprehensibility and productivity, or instead impose unnecessary effort.The paper says these organizational considerations arise before transformation development and are often not discussed explicitly.Source: §6.3 · p. 31

7.1.1 Evaluation of MTL Capabilities and Properties

• Experts considered MTL capabilities largely beneficial outside edge cases, but empirical data substantiating these views is still missing.The authors call for studies to back up expert opinions and investigate the limits interviewees described.Source: §7.1.1 · pp. 31–32
• Experiments can analyze existing transformations, while case studies can track technology effects in complex real-world settings over time.The authors note that experiments with large examples and expert participants are difficult to arrange.Source: §7.1.1 · pp. 31–32
• Evaluation studies should account for relevant factors and contexts, including semantic gaps and transformation complexity, to clarify when MTL features help or hinder.The authors recommend evaluating individual factors or related groups, including through comparisons where a factor is present or absent.Source: §7.1.1 · p. 32
• The interview study cannot quantify factor importance or influence strength, which the authors say is needed to prioritize assessment and improvement.They propose a survey and universal structure modelling to estimate influence and moderation weights.Source: §7.1.1 · p. 32

7.1.2 Improving MTL Capabilities

• The authors recommend advancing reusable transformation mechanisms and improving MDSE education and MTL learning resources to address reuse and learnability concerns.Suggested reuse mechanisms include templates that adapt to differing inputs and outputs; learning improvements include better documentation and tutorials.Source: §7.1.2 · p. 33
• The authors call for stronger industry cooperation and more representative, production-ready MTLs, with prototypical innovations evaluated before adoption into flagship languages.They also suggest considering a refreshed QVT effort and greater focus on bidirectional, incremental, and declarative transformations.Source: §7.1.2 · p. 34
• To lower legacy-integration barriers, the authors propose integration guidance, use-case-specific language recommendations, and accessible GPL bindings for gradual adoption.They suggest identifying system components suited to transformations and avoiding the overhead of introducing a new language and intermediate models where bindings suffice.Source: §7.1.2 · p. 34

7.2 Steps Towards Solving the Tooling Problem

• MTL tooling should provide integrated editors, debuggers, and analysis tools, while usability studies target adoption barriers and transformation-specific debugging gaps.The authors also advise assessing tool requirements early when designing internal MTLs embedded in GPLs.Source: §7.2 · pp. 34–35

8.1 Internal Validity

• Context-dependent meanings could lead to misinterpretation during coding, and the authors say this threat could not be fully mitigated.A single author handled each transcription and analysis step; transcripts were rechecked, and random analysis samples were reviewed by other authors to reduce errors and confirmation bias.Source: §8.1 · pp. 35–36

8.2 External Validity

• Convenience sampling leaves representativeness difficult to assess because the makeup of the target population is unknown.Starting participant selection from research publications also biased the sample toward research, limiting applicability to industrial cases, although half had some industry contact.Source: §8.2 · p. 36
• The study's results do not apply to model-to-text languages because the participant search and analysis focused on model-to-model transformations.Search terms missed model-to-text terms, and the authors chose not to distinguish the two transformation approaches during analysis.Source: §8.2 · p. 36
• Participation bias may have reduced the negative factors reported, although the authors judge its effects weak based on the critiques elicited.They cannot rule out that people with positive views were more likely to participate.Source: §8.2 · p. 36

8.3 Construct Validity

• Wording in the interview claims could have introduced unconscious bias, and the authors cannot exclude that some relevant factors were never raised.They used broad claims, positive and negative statements, and open-ended questions, but acknowledge these measures may not have been sufficient.Source: §8.3 · p. 36

8.4 Conclusion Validity

• Research-oriented participants may have viewed MTLs more positively, so too few negative influences may have been identified.The authors nevertheless conclude that the results remain meaningful because interviewees also discussed the topic critically.Source: §8.4 · pp. 36–37

9 Related Work

• An earlier literature review found 137 claims across 15 MTL properties in 58 publications, with little empirical verification and insufficient context for evaluation.The review searched over 4,000 publications.Source: §9.1 · p. 37
• A survey and discussion attributed MTLs' declining popularity to technical, tooling, and social issues, as well as GPLs adopting MTL ideas.The authors say their own interviews support these results with more detailed background knowledge.Source: §9.1 · p. 37
• A controlled comparison of ATL, QVT-O, and Xtend found no clear MTL advantage across three development tasks, under narrow conditions.The tasks involved comprehension, modification, and developing a transformation from scratch.Source: §9.1 · p. 37
• A comparison of 10 ATL transformations with Java versions found newer Java features reduced cyclomatic complexity and lines of code, while ATL's relative hiding of complexity stayed constant.The Java versions were Java SE5 and Java SE14.Source: §9.1 · p. 37

9.2 Empirical studies on model transformations

• MDE studies also report organizational and social influences, including limited expertise and integration with existing infrastructure.The authors note that these factors overlap with their findings on MTLs.Source: §9.3 · pp. 38–39
• Other empirical studies identify tooling, integration, and performance as relevant beyond the properties directly examined in this study.Findings include tooling as a major MDE factor, challenges integrating MTLs into existing infrastructure, and performance problems reported by over half of surveyed developers.Source: §9.2 · p. 38, §9.3 · p. 39

10 Conclusion

• Interviews with 56 research and industry participants yielded a structure of direct and moderating factors affecting seven MTL properties.Direct factors include language capabilities such as automatic trace handling; contextual factors include developer skills.Source: §10 · p. 39
• The authors recommend more empirical studies to substantiate claimed properties and improvements to transformation-specific reuse, legacy integration, outreach, and tool usability.They say their results provide detailed data for these actions.Source: §10 · p. 39

A Interview Questions

• The interview guide presented literature-based claims and asked participants to rate agreement and explain their reasoning.Claims covered ease of writing and comprehensibility, including abstraction, succinct syntax, and required skills.Source: Ease of Writing · p. 39, Comprehensibility · p. 39

Tool Support

• Tool-support prompts covered MTL productivity, GPL hiring advantages, DSL-tailored tooling, and perceived support gaps.These are interview claims, not study findings.Source: Tool Support · p. 40, Productivity · p. 40

Reuseability & Maintainability

• Reuse and maintainability prompts included expressiveness, hidden transformation burden, recurring patterns, bidirectionality, and reuse mechanisms.These are interview claims, not study findings.Source: Reuseability & Maintainability · p. 40, Expressiveness · p. 40

B Mail Templates

• The recruitment template framed the study around the SLR's finding that many MTL claims lacked substantiation and may depend on omitted implicit knowledge.It invited authors of publications included in that review to discuss their experiences and views.Source: Mail Template · p. 41

C Demographics

• Table 4 presents interviewee demographic data organized by participant ID, background, experience in years, and transformation-language types used.The supplied continuation shows entries for participants P42 through P56.Source: Table 4 · p. 42, C Demographics · p. 43
• The supplied rows include participants from research, industry, and research-and-industry projects.The entries also include varied reported experience levels and language combinations.Source: C Demographics · p. 43
• The language-type entries distinguish dedicated MTLs, internal MTLs, and GPLs in the listed participants' experience.The table caption identifies the material as an overview of interviewee demographic data.Source: Table 4 · p. 42, C Demographics · p. 43

• The interviews concern claims about model transformation languages at the Institute for Software Engineering and Programming.Source: General information, declaration of… · p. 44

• The study examines claims about the advantages and disadvantages of model transformation languages and the evidence for them.Source: Languages of Ulm University · p. 44
• The work package surveys researchers and practitioners about claims concerning model transformation languages.It is part of Stefan Götz’s doctoral thesis.Source: Languages of Ulm University · p. 44
• Its goal is to understand the reasoning people use when believing claims about model transformation languages.Source: Languages of Ulm University · p. 44

• Participants select an interview date through a poll and are contacted about a week beforehand to arrange it.Source: §1 · p. 44
• Interviews take place through an Ulm University-hosted conferencing tool or Skype, according to participant preference.Source: §1 · p. 44
• Interviewers ask about participants’ experience, then present literature claims and solicit agreement judgments and reasons.Source: §1 · p. 44
• With consent, interviews are audio-recorded, transcribed, and the recordings deleted once transcription is complete.Source: §1 · p. 44
• Participants must have some experience with model transformation languages.Source: §1 · p. 44

• Identifiable raw data are shared only among the three named Ulm University project partners for transcription and analysis.Source: §3 · p. 45
• The team removes identifying details and deletes the audio recordings as soon as possible, no later than 30 October 2020.The project states that individuals cannot be deduced from the anonymized interviews.Source: §3 · p. 45
• Anonymized processed and unprocessed answers are made publicly available, where they can be accessed and used by anyone and cannot be completely deleted.Source: §3 · p. 45

Contact person

• Stefan Götz is listed at Ulm University's Institute of Software Engineering and Programming Languages as the contact person.The section invites readers to contact him with questions, concerns, or doubts.Source: Contact person · p. 45

Declaration of consent

• Participants consent to the interview and related data processing; a separate option permits publication of anonymized answers, and consent may be revoked without disadvantage.The form also notes that revocation does not affect the legality of processing already carried out under consent.Source: Declaration of consent · p. 46

E Quotations

• A transformation rule communicates source-to-target domain mapping, and interviewees argue MTL reuse should target modeling beyond general object-oriented mechanisms.The quoted rule description frames its purpose as mapping source-domain objects to target-domain objects.Source: E Quotations · p. 48
• Reuse is supported through ATL superimposition and helper libraries and VIATRA pattern inclusion, whereas GPL trace information may need manual maintenance.The quotations distinguish MTL reuse mechanisms from the reported GPL burden of reimplementing trace maintenance.Source: E Quotations · p. 48
• Participants cite steep learning demands, limited modeling experience, and late MDSE instruction as obstacles to understanding and using MTLs.One respondent says many Java developers lack modeling experience, while another describes MDSE courses arriving after students are accustomed to GPLs.Source: E Quotations · pp. 48–49
• Participants describe Eclipse coupling as limiting applicability, alongside difficulties integrating transformation technologies into broader tool ecosystems.These are participant-reported concerns about applicability and technical integration.Source: E Quotations · p. 48
• Interviewees value advanced, domain-specific MTL tool support, but also report poor usability and missing testing support in ATL.One participant contrasts ATL's lack of testing support with Java's JUnit and other testing tools.Source: E Quotations · p. 49
• One participant reports lacking initial go-to documentation for MTLs, while another attributes their prolonged limitations partly to low industry uptake and manpower.These are interviewee explanations, not independently established causes.Source: E Quotations · p. 49

Declarations

• The authors declare no competing interests relevant to the article's content.Source: Declarations · p. 50