Comparison Between Internal and External DSLs via RubyTL and Gra2MoL

Domain Specific Languages (DSL) are becoming increasingly more important with the emergence of Model-Driven paradigms. Most literature on DSLs is focused on describing particular languages, and there is still a lack of works that compare different approaches or carry out empirical studies regarding the construction or usage of DSLs. Several design choices must be made when building a DSL, but one important question is whether the DSL will be external or internal, since this affects the other aspects of the language. This chapter aims to provide developers confronting the internal-external dichotomy with guidance, through a comparison of the RubyTL and Gra2MoL model transformations languages, which have been built as an internal DSL and an external DSL, respectively. Both languages will first be introduced, and certain implementation issues will be discussed. The two languages will then be compared, and the advantages and disadvantages of each approach will be shown. Finally, some of the lessons learned will be presented.

Design Patterns and Design Principles for Internal Domain-Specific Languages

Internal DSLs are a special kind of DSLs that use an existing programming language as their host. To build them successfully, knowledge regarding how to modify the host language is essential. In this chapter, the author contributes six DSL design principles and 21 DSL design patterns. DSL Design principles provide guidelines that identify specific design goals to shape the syntax and semantic of a DSL. DSL design patterns express proven knowledge about recurring DSL design challenges, their solution, and their connection to each other – forming a rich vocabulary that developers can use to explain a DSL design and share their knowledge. The chapter presents design patterns grouped into foundation patterns (which provide the skeleton of the DSL consisting of objects and methods), notation patterns (which address syntactic variations of host language expressions), and abstraction patterns (which provide the domain-specific abstractions as extensions or even modifications of the host language semantics).

Iterative and Pattern-Based Development of Internal Domain-Specific Languages

Internal DSLs are a special kind of DSLs that use an existing programming language as their host. In this chapter, the author explains an iterative development process for internal DSLs. The goals of this process are: (1) to give developers a familiar environment in which they can use known and proven development steps, techniques, tools, and host languages, (2) to provide a set of repeatable, iterative steps that support the continuous adaptation and evolution of the domain knowledge and the DSL implementation, and (3) to apply design principles that help to develop DSLs with essential properties and to use host language independent design patterns to plan and communicate the design and implementation of the DSL. The process consists of three development steps (analysis, language design, and language implementation) and applies four principles: open form, agile and test-driven development, design pattern knowledge, and design principle knowledge.

Evaluating the Usability of Domain-Specific Languages

Domain-Specific Languages (DSLs) can be regarded as User Interfaces (UIs) because they bridge the gap between the domain experts and the computation platforms. Usability of DSLs by domain experts is a key factor for their successful adoption. The few reports supporting improvement claims are persuasive, but mostly anecdotal. Systematic literature reviews show that evidences on the effects of the introduction of DSLs are actually very scarce. In particular, the evaluation of usability is often skipped, relaxed, or at least omitted from papers reporting the development of DSLs. The few exceptions mostly take place at the end of the development process, when fixing problems is already too expensive. A systematic approach, based on techniques for the experimental evaluation of UIs, should be used to assess suitability of new DSLs. This chapter presents a general experimental evaluation model, tailored for DSLs’ experimental evaluation, and instantiates it in several DSL’s evaluation examples.

Abstraction of Computer Language Patterns

In general, designing a domain-specific language (DSL) is a complicated process, requiring the cooperation of experts from both application domain and computer language development areas. One of the problems that may occur is a communication gap between a domain expert and a language engineer. Since domain experts are usually non-technical people, it might be difficult for them to express requirements on a DSL notation in a technical manner. Another compelling problem is that even though the majority of DSLs share the same notation style for representing the common language constructs, a language engineer has to formulate the specification for these constructs repeatedly for each new DSL being designed. The authors propose an innovative concept of computer language patterns to capture the well-known recurring notation style often seen in many computer languages. To address the communication problem, they aim for the way of proposing a DSL notation by providing program examples as they would have been written in a desired DSL. As a combination of these two ideas, the chapter presents a method for example-driven DSL notation specification (EDNS), which utilizes computer language patterns for semi-automated inference of a DSL notation specification from the provided program examples.

Towards Dynamic Semantics for Synthesizing Interpreted DSMLs

Domain-specific languages (DSLs) provide developers with the ability to describe applications using language elements that directly represent concepts in the application problem domains. Unlike general-purpose languages, domain concepts are embedded in the semantics of a DSL. In this chapter, the authors present an interpreted domain-specific modeling language (i-DSML) whose models are used to specify user-defined communication services, and support the users’ changing communication needs at runtime. These model changes are interpreted at runtime to produce events that are handled by the labeled transition system semantics of the i-DSML. Specifically, model changes are used to produce scripts that change the underlying communication structure. The script-producing process is called synthesis. The authors describe the semantics of the i-DSML called the Communication Modeling Language (CML) and its use in the runtime synthesis process, and briefly describe how the synthesis process is implemented in the Communication Virtual Machine (CVM), the execution engine for CML models.

Extensible Languages

Out of a concern for focus and concision, domain-specific languages (DSLs) are usually very different from general purpose programming languages (GPLs), both at the syntactic and the semantic levels. One approach to DSL implementation is to write a full language infrastructure, including parser, interpreter, or even compiler. Another approach however, is to ground the DSL into an extensible GPL, giving you control over its own syntax and semantics. The DSL may then be designed merely as an extension to the original GPL, and its implementation may boil down to expressing only the differences with it. The task of DSL implementation is hence considerably eased. The purpose of this chapter is to provide a tour of the features that make a GPL extensible, and to demonstrate how, in this context, the distinction between DSL and GPL can blur, sometimes to the point of complete disappearance.

DSLs in Action with Model Based Approaches to Information System Development

In this chapter, the authors give an overview of the evolution of Information System (IS) development methods used in the last few decades and show how model driven approaches and Domain Specific Languages (DSLs) have managed to take an often essential role in the modern IS development process. To present an overall picture, the authors discuss significant breakthroughs, popular approaches, their strong and weak points, along with the examples of their practical use in the domain of IS development and generation of software applications. In order to further support the aforementioned points, the chapter offers a synopsis of Integrated Information Systems CASE Tool (IIS*Case), a model driven software development tool for IS modeling and prototype generation. A special attention is drawn to its evolution and position relative to some of the key changes in IS development approaches in recent history. The authors highlight the significance of DSLs in this context and present a DSL featured in the tool. The DSL was created to provide platform independent model (PIM) IS specifications which can be transformed into executable application prototypes through a chain of model-to-model and model-to-code transformations. Since the authors have developed both a textual DSL, and visual repository-based tools (visual DSLs) for this purpose, a discussion of pros and contras of textual vs. visual DSLs in the context of creating PIM specifications is also included. Furthermore, the chapter communicates practical experiences about creating meta-meta models of PIM concepts by means of attribute grammars and MOF meta-modeling language.

Integrating DSLs into a Software Engineering Process

The development of large and complex systems involves many people, stakeholders. Engineeringly speaking, one way to control this complexity is by designing and analyzing the system from different perspectives. For each perspective, stakeholders benefit from means, tools, languages, specific to their activity domain. A Domain Specific Language (DSL) per perspective is such a dedicated means. While DSLs are used for modeling, other means, tools, and languages are needed for other connected activities, like testing or collaborating. However, using such different types of tools together, integrating DSLs into stakeholders’ software process is not straightforward. In this chapter, the authors advance an integration process of DSLs with other tools. The chapter proposes each stakeholder have their own DSL with associated graphical editor, operational semantics, and generation of scripts for off the shelf simulators, e.g., testing. Additionally to the integrated stakeholders’ software process, the authors introduce a model driven process dedicated to the tool vendor which creates the DSLs and its associated tools. Due to the integration of DSLs into this process, they contend that stakeholders will significantly reduce system construction time. The chapter illustrates the two processes on Telecommunications service construction.

Software Language Engineering with XMF and XModeler

XMF and XModeler are presented as technologies that have been specifically designed for Software Language Engineering. XMF provides a meta-circular, extensible platform for DSL definition based on syntax-classes that extend object-oriented classes with composable grammars. XModeler is a development environment built on top of XMF that provides an extensible client-based architecture for developing DSL tools.