Using Internal Domain-Specific Languages to Inherit Tool Support
Total Page:16
File Type:pdf, Size:1020Kb
Journal of Software & Systems Modelling manuscript No. (will be inserted by the editor) Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations Georg Hinkel · Thomas Goldschmidt · Erik Burger · Ralf Reussner Received: March 14, 2016 / Revision: January 5, 2017/ Accepted: not yet Abstract Model-driven engineering (MDE) has pro- .NET platform. The results confirm the value of inher- ven to be a useful approach to cope with todays ever ited modularity and tool support while conciseness and growing complexity in the development of software sys- understandability are still competitive. tems; nevertheless, it is not widely applied in industry. Keywords Model-driven Engineering · Model Trans- As suggested by multiple studies, tool support is a ma- formation · Domain-Specific Language · Tool Support · jor factor for this lack of adoption. Especially the devel- Extensibility opment of model transformations lacks good tool sup- port. Additionally, modularization techniques are in- evitable for the development of larger model transfor- 1 Introduction mations to keep them maintainable. Existing tools for MDE, in particular model transformation approaches, The increasing complexity of software systems has been are often developed by small teams and cannot keep tackled in the past by increasing the abstraction of pro- up with advanced tool support for mainstream gen- gramming languages. Today, it seems as if the abstrac- eral purpose programming languages, such as IntelliJ tion level of modern programming languages can hardly or Visual Studio. Internal DSLs are a promising solu- be raised without losing general purpose applicability. tion to these problems. In this paper, we investigate In recent years, many domain-specific languages (DSLs) the impact of design decisions of an internal DSL to the [10] have been proposed, which can be used to describe reuse of tool support and modularization concepts from systems at a higher abstraction level in terms of domain the host language. We validate our findings in terms of concepts. understandability, applicability, tool support and ex- The merit of a DSL is based on how well it can tensibility using three case studies from academia, a be used to document, generate, or reason on a system model-driven engineering platform, and the industrial or its parts. For these tasks, several artifacts need to automation domain where we apply an implementation be created. They are typically deduced by reusing ex- of an internal model transformation language on the isting documentation systems, programming languages, or analyses through transformation. In this process, in- G. Hinkel stances of the DSL are transformed into documenta- FZI Forschungszentrum Informatik, Haid-und-Neu-Straße 10-14, tion, code, or input (models) for analysis. Therefore, 76131 Karlsruhe, Germany model transformations are sometimes called the “heart E-mail: [email protected] and soul” of model-driven approaches, which should be Thomas Goldschmidt supported by dedicated languages [49]. ABB Corporate Research, Wallstadter Straße 59, 68526 Laden- A variety of model transformation approaches [7] burg E-mail: [email protected] exists. They incorporate high-level abstractions, such as the composition of model transformations, into rules Erik Burger · Ralf Reussner Karlsruhe Institute of Technology, Am Fasanengarten 5, 76131 that describe the transformation for a particular model Karlsruhe, Germany element. Developers can use these languages to pro- E-mail: {burger,reussner}@kit.edu duce transformations that are more concise, more un- 2 Georg Hinkel, Thomas Goldschmidt, Erik Burger and Ralf Reussner derstandable and sometimes even more performant (cf. a mainstream general-purpose language, such as Java [14]) than transformations written in general purpose or C]1. Given the popularity of these languages, there programming languages. Nevertheless, model transfor- are also rich component frameworks available that can mation languages are still not widely adopted in indus- be reused as a technological foundation for a modular- try. Multiple studies [37, 38, 50, 58] suggest that tool ization concept. Examples for such component frame- support is a major factor in the adoption of model- works include OSGi on the Java platform or the .NET driven engineering. This applies especially to model trans- component model in .NET. formations, given their importance in model-driven ap- Although multiple transformation languages follow proaches. this approach of an internal language, there is no sys- Since model-driven approaches are not widely adopted, tematic analysis yet that would show how the design of often relatively few resources are spent to improve tools. such a language affects the quality of the derived tool This becomes evident when compared to integrated de- or modularization support. Neither has there been an velopment environments (IDEs) for mainstream lan- investigation on what types of tool support can be in- guages, such as IntelliJ or Visual Studio, which have a herited at all. The goal of this paper is therefore to close massive user base. Thus, much more resources are spent this gap by answering the following research questions: for the improvement of these tools. Many model trans- – What types of tool support can be reused from model formation tools are maintained by researchers rather transformation languages implemented as internal than commercial tool vendors, resulting in proof of con- DSLs? cept implementations rather than fully-featured, easy – How does the embedding of model transformation to use tools. concepts into object-oriented concepts affect the qual- An increased application of model-driven techniques ity of derived tool support? in industry would typically go along with the creation of – How can modularization concepts from general-pur- more complex models. Therefore, also the model trans- pose object-oriented host languages be reused for formations would become more complex. To reuse parts model transformation languages? of the transformations in new scenarios as often as pos- sible, the transformations would have to be modular- To answer these research questions, we analyze the ized. In contrast to this, Wimmer, Kusel et al. indicate different design alternatives of how model transforma- that reuse functionality of current model transforma- tion concepts can be embedded into object-oriented con- tions is hardly established in practice [33, 62]. cepts. We sketch how the resulting language would look Furthermore, as Meyerovich suggests [36], many de- like and discuss the implications on several kinds of tool velopers do not appreciate switching their primary pro- support. This discussion is guided by existing studies on gramming languages. They do so only if there is a signif- what kinds of tool support are most important to de- icant amount of code they can reuse, or if management velopers using Java with Eclipse [39]. We have analyzed requires them to do so. This is reasonable since such the model transformation language NTL in three case a change often makes valuable knowledge of particu- studies in order to validate and evaluate the results of lar technologies superfluous. Also, similar concepts are our discussion. sometimes implemented in slightly different ways, caus- This paper extends prior work on reusing compo- ing subtle bugs. As an example in the world of model nent models for model transformation [24] and on in- transformations, the difference in OCL between is-type- vestigating editing and navigation support for inter- of (= is of the exact type of) and is-kind-of (= is of nal model transformation languages [22]. The exten- the exact type or of a subtype of) often causes confu- sion consists of a more holistic view on the subject, sion for developers who are not confronted with it on and an evaluation of open questions from the discus- an everyday-basis. sion through case studies. Thus, two sides of the problem can be identified: The remainder of this paper is structured as fol- On the one side, general purpose languages lack model lows: Section 2 explores what tool support we suspect transformation concepts, and on the other side, dedi- to inherit from the usage of internal DSLs. Section 3 cated model transformation languages lack tool or mod- 1 The choice of a textual languages such as Java or C] as host ularization support. A promising approach to the solu- languages for a model transformation language inevitably leads tion of these problems is the combination of both worlds to a textual model transformation language. Even from the early in an internal DSL [10] for model transformation: The days on, there has always been a demand for graphical model transformation language is embedded in another lan- transformation languages [49]. However, as the success of textual model transformation languages [29, 31], but also the experience guage, called host language. To gain best tool support, with graphical languages [64] imply, textual model transforma- the model transformation language should be hosted in tions may be better suited for certain kinds of problems. Using Internal Domain-Specific Languages to inherit Tool Support and Modularity for Model Transformations 3 describes the abstract syntax of the transformation lan- or support deployment. The features of the compo- guage extracted from other model transformation ap- nent model determine the tools that can be used. De- proaches. Section 4 discusses adaptation points how tecting version conflicts requires