David Méndez-Acuña
email: david.mendez-acuna@inria.fr

José A Galindo
email: jagalindo@inria.fr

Thomas Degueule
email: thomas.degueule@inria.fr

Benoît Combemale
email: benoit.combemale@inria.fr

Benoît Baudry
email: benoit.baudry@inria.fr

Leveraging Software Product Lines Engineering in the Development of External DSLs: A Systematic Literature Review

Keywords: Software Language Engineering, Domain-Specific Languages, Variability Management, Software Product Lines Engineering

The use of domain-specific languages (DSLs) has become a successful technique in the development of complex systems. Consequently, nowadays we can find a large variety of DSLs for diverse purposes. However, not all these DSLs are completely different; many of them share certain commonalities coming from similar modeling patterns -such as state machines or petri nets-used for several purposes. In this scenario, the challenge for language designers is to take advantage of the commonalities existing among similar DSLs by reusing, as much as possible, formerly defined language constructs. The objective is to leverage previous engineering efforts to minimize implementation from scratch. To this end, recent research in software language engineering proposes the use of product line engineering, thus introducing the notion of language product lines. Nowadays, there are several approaches that result useful in the construction of language product lines. In this article, we report on an effort for organizing the literature on language product line engineering. More precisely, we propose a definition for the life-cycle of language product lines, and we use it to analyze the capabilities of current approaches. In addition, we provide a mapping between each approach and the technological space it supports.

Introduction

The increasing complexity of modern software systems has motivated the need of raising the level of abstraction at which software is designed and implemented [START_REF] Chechik | Raising level of abstraction with partial models: A vision[END_REF]. The use of domain-specific languages (DSLs) has emerged in response to this need as an alternative to express software solutions in relevant domain concepts, thus hiding fine-grained implementation details and favoring the participation of domain experts in the software development process [START_REF] Jézéquel | When systems engineering meets software language engineering[END_REF].

DSLs are software languages whose expressiveness is localized in a well-defined domain, and which provide the abstractions (a.k.a., language constructs) intended to describe certain aspect of a system under construction [START_REF] Combemale | Globalizing modeling languages[END_REF]. Naturally, the adoption of such a language-oriented vision relies on the availability of the DSLs needed to describe the diverse aspects of the system [START_REF] Clark | Domain Engineering: Product Lines, Languages, and Conceptual Models[END_REF]; consequently, nowadays there is a large variety of DSLs conceived for diverse purposes [START_REF] Mernik | When and how to develop domain-specific languages[END_REF]. We can find, for example, DSLs to build graphical user interfaces [START_REF] Oney | ConstraintJS: Programming interactive behaviors for the web by integrating constraints and states[END_REF], or to specify security policies [START_REF] Lodderstedt | SecureUML: A UML-Based modeling language for model-driven security[END_REF].

Although each of the existing DSLs is unique and has been developed for a precise purpose, not all the existing DSLs are completely different among them. Recent research has shown the existence of DSLs providing similar language constructs [START_REF] Zschaler | Domain-specific metamodelling languages for software language engineering[END_REF][START_REF] Lara | Domain-specific textual meta-modelling languages for model driven engineering[END_REF]. A possible explanation to such phenomenon is the recurrent use of certain modeling patterns that, with proper adaptations, are suitable for several purposes. Consider, for instance, the case of finite state machines which have inspired many DSLs dealing with diverse problems such as the design of integrated circuits [START_REF] Agron | Domain-specific languages[END_REF], performing software components composition [START_REF] Anlauff | Using domain-specific languages for the realization of component composition[END_REF], or the alignment of business processes with legislation [START_REF] Nešković | Using protocols and domain specific languages achieve compliance of administrative processes with legislation[END_REF].

In this context, the challenge for language designers is to take advantage of the commonalities existing among similar DSLs by reusing, as much as possible, formerly defined language constructs [START_REF] Zschaler | VML* a family of languages for variability management in software product lines[END_REF]. The objective is to leverage previous engineering efforts to minimize implementation from scratch. Ideally, the reuse process should be systematic. This requires, on one hand, to define reusable segments of language specifications that can be included in the definition of several DSLs, and on other hand, an appropriate management of the variability introduced by the particularities of each DSL [START_REF] Jézéquel | When systems engineering meets software language engineering[END_REF].

To overcome this challenge, the research community in software language engineering has proposed the use of Software Product Lines Engineering (SPLE) in the construction of DSLs [START_REF] White | Improving domain-specific language reuse with software product line techniques[END_REF]. Indeed, the notion of Language Product Lines Engineering (LPLE) -i.e., construction of software product lines where the products are languages -has been recently introduced [START_REF] Zschaler | VML* a family of languages for variability management in software product lines[END_REF][START_REF] Kühn | Choosy and picky: Configuration of language product lines[END_REF]. The main principle behind language product lines is to implement DSLs through language features. A language feature encapsulates a set of language constructs that represents certain functionality offered by a DSL [START_REF] Liebig | Feature-oriented language families: A case study[END_REF].

Language features can be combined in different manners to produce tailor-made DSLs targeting the needs of well-defined audiences. This feature-oriented approach for DSLs engineering requires the definition of DSLs in a modularized fashion where language features are implemented as interdependent and composable language modules. Additionally, language designers should model the existing variability [START_REF] Cengarle | Variability within modeling language definitions[END_REF][START_REF] Grönniger | Modeling language variability[END_REF], and provide a configuration mechanism that enable the selection and composition of the language features required in a concrete scenario [START_REF] Méndez-Acuña | Variability management in domain-specific languages[END_REF]. The aforementioned challenges constitute the life-cycle of a language product line.

Nowadays, there are several approaches that result useful in the construction of language product lines. Yet, it is difficult to realize what are the most appropriated approach to build a language product line in a particular language engineering project. This difficulty is due to two reasons. Firstly, approaches rarely address the whole life-cycle of language product lines. Rather, many of them focus on a specific issue, and integral solutions are rarely provided. Secondly, approaches are quite dependent on the technological space where DSLs are implemented. For instance, an approach conceived for grammars-based DSLs might be not applicable for metamodels-based DSLs.

This article reports on an effort for organizing the literature on language product line engineering through a systematic literature review. We consider two different perspectives. On one hand, we propose a definition to the life-cycle of language product lines. We use such a life-cycle to analyze the current approaches available in the literature. On the other hand, we establish a mapping between each approach and the technological space it supports. In this sense, this article targets both researchers and practitioners. Researchers will find a comprehensive analysis of the life-cycle of language product lines, as well as a deep study of the strategies used in the state of the art to address such a life-cycle. In turn, practitioners will find in this article a practical guide that they can use to find out the most convenient approach for a particular project according to the technological space used in the implementation of the involved DSLs.

The reminder of this article is structured as follows. Section 2 introduces some background knowledge and states the motivation of this literature review. Section 3 describes the used research method. Section 4 presents the results of this literature review. Section 5 discusses the threats to validity of our study. Finally, Section 6 concludes the article.

Background and Motivation

Basics on Domain-Specific Languages and Software Product Lines Engineering

In this section, we introduce a unified vocabulary to facilitate the comprehension of the ideas presented in the rest of the article. In particular, we present a brief background in domain-specific languages and software product line engineering.

Domain-Specific Languages (DSLs)

In recent years, growing interest in DSLs has led to the proliferation of formalisms, tools, and methods for software language engineering. Hence, numerous techniques for implementing DSLs have emerged. In this section, we shed some light on the most prominent approaches.

Implementation concerns for DSLs. Just as traditional general purpose languages, domain specific languages are typically defined through three implementation concerns: abstract syntax, concrete syntax, and semantics [START_REF] Harel | Meaningful modeling: what's the semantics of "semantics[END_REF]. The abstract syntax of a DSL specifies the set of language constructs that are relevant to its domain and the relationships among them. The concrete syntax of a DSL maps its language constructs to a set of symbols (either graphical or textual) that the users manipulate to create models and programs conforming to its abstract syntax. These representations are usually supported by editors that enable users to write programs using the symbols defined by the concrete syntax acting as the graphical user interface of the DSL. Finally, the semantics of a DSL assigns a precise meaning to each of its language constructs. More precisely, static semantics constrains the sets of valid programs while dynamic semantics specifies how they are evaluated at runtime.

Technological spaces for the implementation of DSLs. There are different technological spaces available for the realization of each of these concerns. The abstract syntax of a DSL can be expressed using grammars or metamodels. Since concrete syntax and semantics are usually defined as a mapping from the abstract syntax, the choice of the abstract syntax formalism strongly impact the choice of concrete syntax and semantics specification.

Regarding concrete syntax, DSLs can have either textual or graphical representations (or a mix of both). This decision is usually motivated by the requirements of final users, and the scenarios where the DSL will be used [START_REF] Selic | The theory and practice of modeling language design for model-based software engineering: A personal perspective[END_REF]. The implementation of a concrete syntax may for instance rely on the definition of a parser, or a projectional editor [START_REF] Vöelter | Language and IDE modularization and composition with MPS[END_REF].

Regarding the specification of static semantics, there are not many design decisions to make beyond the constraints language to use. Usually, this selection is based on technological compatibilities with the formalism in which the abstract syntax is defined.

In turn, there are different methods for the definition of dynamic semantics: operational semantics, denotational semantics, and axiomatic semantics [START_REF] Mosses | The varieties of programming language semantics and their uses[END_REF]. Operational semantics expresses the meaning of the language constructs of a DSL through the computational steps that will be performed during the execution of a program [START_REF] Mosses | The varieties of programming language semantics and their uses[END_REF]. The definition of the operational semantics thus consists in an endogenous transformation that changes the execution state of conforming programs. Typically, the implementation of operational semantics corresponds to the definition of an interpreter.

Denotational semantics expresses the meaning of a DSLs through functions that map its constructs to a target formal language where the semantics is well-defined [START_REF] Kutter | Integrating domain specific language design in the software life cycle[END_REF][START_REF] Mannadiar | Debugging in domain-specific modelling[END_REF]. When the target language is not a formal one (e.g., another programming language with its own semantics), the term translational semantics is favored. The implementation of the translational semantics typically takes the form of a compiler.

Axiomatic semantics offers a mechanism for checking if the programs written in a DSL own certain properties. Examples of such properties are equivalence between programs or functional correctness (e.g., checking if the program is correct with respect to its specification in terms of pre-and post-conditions) [START_REF] Schmidt | Denotational Semantics: A Methodology for Language Development[END_REF].

It is worth noting that the different methods for implementing the semantics of software languages are not mutually exclusive. Indeed, some works suggest that one language should own the three types of semantics since each of them provides better support for certain kind of users [START_REF] Gupta | Specification, implementation, and verification of domain specific languages: A logic programmingbased approach[END_REF][START_REF] Schmidt | Denotational Semantics: A Methodology for Language Development[END_REF].

Figure 1 sums up the discussed taxonomy in the form of a feature model [START_REF] Schobbens | Generic semantics of feature diagrams[END_REF]. Each feature represents a technological space, and the relationships between features represent constraints on the combination of technological spaces. This taxonomy is compatible with the state of the art of language workbenches presented in [START_REF] Erdweg | The state of the art in language workbenches[END_REF]. Nevertheless, our taxonomy is more focused on the characteristics of the languages themselves rather than on the characteristics of the language workbenches. Our taxonomy also complies with the classification of DSLs introduced in [START_REF] Langlois | DSL classification[END_REF]. External versus internal DSLs. Another important decision when designing a DSL concerns the shape of the resulting language. Language designers can choose to build either an external or an internal DSL1 . The construction of an external DSL can be viewed as the creation of a new language [START_REF] Mernik | When and how to develop domain-specific languages[END_REF] with its own dedicated infrastructure: editors, compilers and/or interpreters, tools, etc. In such a case, language designers must write a complete specification of their language using dedicated formalisms that offer the suitable expressiveness for defining each implementation concern. Since those formalisms are languages intended to specify languages, they are usually known as meta-languages and vary depending on the technological space chosen for the construction of the DSL.

In the case of internal DSLs, the principle is to take advantage of the infrastructure already provided by a host language [START_REF] Mernik | When and how to develop domain-specific languages[END_REF]. The high-level domain concepts of the DSLs are implemented using the language constructs offered by the host language. Editors, parsers, or compilers of the host language are reused, thus lowering the development costs compared to external DSLs. However, following this approach also implies that the capabilities of an internal DSL are restricted to the capabilities of the host language. The DSL must work with the programming paradigm, the type system, and the tooling provided by the host language. Because of all these reasons, an appropriate selection of the host language is of vital importance [START_REF] Renggli | Why smalltalk wins the host languages shootout[END_REF].

Language workbenches. The notion of language workbench originates from the seminal work of Martin Fowler [START_REF] Fowler | Language workbenches: The killer-app for domain specific languages[END_REF]. The main intent of language workbenches is to provide a unified environment to assist both the language designers and users in, respectively, creating new DSLs and using them. Modern language workbenches typically offer a set of meta-languages that the language designers use to express each of the implementation concerns of a DSL [START_REF] Visser | A language designer's workbench: A one-stop-shop for implementation and verification of language designs[END_REF], along with tools and methods for composing and analyzing their specifications.

Most state-of-the-art approaches for software language engineering thus ultimately materialize as features of a language workbench. Therefore, language workbenches occupy a prominent place in this literature review. Similarly, future approaches for language product line engineering should be integrated in language workbenches to promote their adoption by a wide audience. The interested reader can refer to [START_REF] Erdweg | Evaluating and comparing language workbenches: Existing results and benchmarks for the future[END_REF] for an in-depth study of the features offered by different popular language workbenches.

Software Product Lines Engineering (SPLE)

While traditional approaches to software development are intended to build individual software products, the SPLE approach proposes the construction of families of software products through a production lines' perspective [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. A software product line is an infrastructure that enables to assembly several software products that share some commonalities with well-defined variations [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. The central principle of the SPLE approach relies on the notion of feature. A feature encapsulates a characteristic that might be included in a software product. In that sense, a software product line can be viewed as a set of features available for the construction of a family of software products. Figure 2 shows the life-cycle of a software product line; it is divided into two phases: domain engineering and application engineering [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF].

During the domain engineering phase, the objective is to build the product line itself (i.e., the infrastructure). This process includes the design and implementation of a set of common assets, as well as the explicit representation of the possible variations. The common assets of a software product line correspond to the software artifacts that implement the features. In turn, the possible variations of a software product line correspond to the combination of features that produce valid software products [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF].

Since the notion of feature is intrinsically associated with encapsulation of functionality (i.e., characteristics), the implementation of the common assets requires a modular design of software artifacts that allows the definition of interdependent and interchangeable software modules. Those modules should be linked to the features they implement. In turn, the explicit representation of the variations requires a formalism to express the rules defining which are the valid combinations of features. Typically, those rules encode dependencies and/or conflicts between features. Feature models (FMs) [START_REF] Kang | Feature-oriented domain analysis (FODA) feasibility study[END_REF] became the "de facto" standard to express these rules [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF].

During the application engineering phase, the objective is to derivate software products according to the needs of specific customer segments [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. Such derivation process comprises the selection of the features that should be included in the product, i.e., product configuration, as well as the assembly of the corresponding software modules, i.e., modules composition.

It is worth mentioning that both, the domain engineering and the application engineering phases are intended to be formal software development process. Hence, these phases require the typical steps towards the construction of software: requirements analysis, solution design, implementation, and testing [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. Besides, software product lines are not static in time. The market needs evolve, and software product lines should support changes and adaptations to new business needs [START_REF] Macala | Managing domain-specific, product-line development[END_REF].

Motivation for a systematic literature review

As aforementioned, there is synergy between the construction of DSLs and software product line engineering [START_REF] Kühn | Choosy and picky: Configuration of language product lines[END_REF]. The ideas towards systematic management of software variants provided the product line engineering approach can be used to build similar DSLs while adapting them to specific application contexts [START_REF] White | Improving domain-specific language reuse with software product line techniques[END_REF]. To this end, the life-cycle of software product lines should be adapted to the particularities of DSLs development process. In addition, language workbenches should provide the capabilities that allow language designers to adapt those ideas in concrete DSLs [START_REF] Jézéquel | When systems engineering meets software language engineering[END_REF]. Nowadays, we can find several approaches from the software language engineering community that directly or indirectly support this vision. Each approach provides insights and/or tooling that can be used during the construction of a language product line. However, it is yet difficult for language designers to realize how those approaches can be used in a concrete DSLs development project. Such difficulty has two dimensions.

The first dimension is the partial coverage of the language product lines life-cycle. Not all the approaches address all the steps of the life-cycle. Rather, they are often focused on a particular step (such as modular design) without discussing the other ones. This can be explained by the fact that approaches that result useful in language product line engineering were not necessarily conceived to this end. For example, not all the approaches in languages modular design are intended to support variability; many of them are motivated by other factors such as domain evolution and maintenance [START_REF] Cazzola | DSL evolution through composition[END_REF].

The second dimension is the misalignment between the technological space supported by each approach and the technological constraints of a particular DSLs development project. Approaches in software language engineering are quite dependent of a specific technological space which not always matches the requirements of a specific DSL development project. For example, an approach conceived for grammars-based DSLs with operational semantics may be difficult (or even impossible) to apply in a project where DSLs are meant to be metamodels-based with denotational semantics.

Research questions. The objective of this literature review is to help language designers to find out approaches to leverage software product line engineering in the development of DSLs. To this end, we need to first analyze how the life-cycle of software product line engineering can be adapted to the construction of language product lines. Then, we need to explore the current approaches that result useful in the construction of language product lines, and identify what are the steps of the life-cycle they address as well as the technological space they support. Finally, we need to identify open issues. In summary, this literature review is intended to answer the following research questions:

• RQ.1: What is the life-cycle of a language product line?

• RQ.2: What are the approaches supporting language product line engineering?

• RQ.3: How those approaches support the life-cycle of a language product line?

• RQ.4: What are the technological spaces that current approaches support?

• RQ.5: What are research open issues in language product line engineering? Scope. It is worth mentioning that this literature review is restricted to approaches for external DSLs. Conducting a literature review that also includes internal DSLs might be too broad, specially because the development of internal DSLs can resemble to the development of traditional software libraries [START_REF] Hofer | Polymorphic embedding of DSLs[END_REF]. Establishing the boundary of the discussion is quite difficult.

Other surveys and literature reviews on software languages engineering. There are other literature studies in the field of software languages engineering. Perhaps the most notable one is presented by Mernik et. al. [START_REF] Mernik | When and how to develop domain-specific languages[END_REF] which provides a comprehensive analysis of the different development phases in the construction of DSLs: analysis, design, and implementation. Besides, the study introduces some insights to identify the situations in which the development of a DSL is a correct decision, and discusses the capabilities of some of the language workbenches available in 2005. Some years later, Kosar et al., [START_REF] Kosar | Domain-specific languages: A systematic mapping study[END_REF] published a new research work in the form of a systematic mapping study which analyzes the trends of the research in DSLs from 2006 to 2012. The conclusions of the study permit to identify the issues that require more attention in the research of DSLs. For example, the authors clearly identify a lack of research on domain analysis and maintenance of DSLs.

A similar study is presented by Marques et al. [START_REF] Marques Do Nascimento | A systematic mapping study on domain-specific languages[END_REF]. In this case the objective is to provide a systematic mapping study that allows to identify the tools and techniques used in the construction of DSLs. For example, the authors provide a comprehensive list of the host languages used in the development of internal DSLs. Besides, this work permit to understand in which domains the DSLs are being used. One of the conclusions in this regard is that the most popular domain for DSLs is the construction of Web-based systems. Other popular domains are embedded systems and networks.

Apply selection driteria

Another relevant study on the literature of software languages engineering is the one presented by Erdweg et al. [START_REF] Erdweg | Language composition untangled[END_REF]. More than studying research trends and techniques, this work focus on the analysis of language workbenches. The authors identify a comprehensive set of features provided by the current language workbenches. Then, these features are used to compare the language workbenches among them. The technological spaces are viewed as features of the language workbenches.

As the reader might notice, all the studies presented so far are intended to provide a general vision on the field of software languages engineering. They analyze a large amount of approaches and offer different perspectives on the past, the present, and the future of the research in software languages. The literature review that we present in this article is intended to be more specific. Instead of global perspectives, we propose a detailed study in a localized issue: the use of software product lines techniques to increase reuse in the construction of domain-specific languages.

In that sense, our literature review can be compared with other studies addressing localized issues. Some examples of those localized studies are: (1) the work presented by Ober et al. [START_REF] Ober | Dealing with variability within a family of domain-specific languages: comparative analysis of different techniques[END_REF] surveys different techniques to deal with interoperability between DSLs; (2) the work presented by Kusel et al. [START_REF] Kusel | Reuse in model-to-model transformation languages: are we there yet?[END_REF] studies approaches to leverage reuse in model-to-model transformations; and (3) the work by Silva et al. [START_REF] Da | Model-driven engineering: A survey supported by the unified conceptual model[END_REF] focus on describing the elements of model-driven software development which has been used as technological space in the implementation of domain specific languages.

Research Method

In this section we provide the details about the research method that we followed during the conduction of this literature review. Concretely, we describe the search protocol that we used to find and select the articles included in the discussion that ends up to the answers for the research questions introduced in section 2.2. The search protocol is illustrated in Fig. 3; it was inspired on the guidelines for systematic literature reviews presented by Kitchenham et al [START_REF] Kitchenham | Systematic literature reviews in software engineering -a tertiary study[END_REF].

Perform automatic search. The first phase of the protocol corresponds to an automatic search that collects a preliminary set of articles potentially interesting for the discussion. It was performed on four digital libraries: ACM-DL, IEEEXplore, SpringerLink, and ScienceDirect. These digital libraries where selected because they are used to publish the articles accepted in the conferences and journals typically targeted by the community of software languages engineering. We decided to discard other sources such as GoogleScholar that do not guarantee that the indexed documents are validated through peer-reviewing.

That the automatic search was based on the following boolean expression: (A OR B OR C) AND (D OR E OR F) AND (G) where the corresponding strings are presented in the Tab 1. Naturally, there might be several variants of these strings. For example, we can consider plurals and acronyms. However, at the end of the searching protocol we performed a validation of the results (that we will explain later in this section) and we concluded that the strings we used are appropriate. This first phase resulted in 1.018 articles.

Research Area

Challenge Scope A: "languages engineering" D: "variability" G: "domain-specific languages" B: "languages implementation" E: "modularity" -C: "languages definition" F: "composition" -Remove duplications. There are some cases in which an article is indexed by more than one digital library. As a consequence, some of the entries resulting from the first phase corresponded to the same article. Then, the second phase of our protocol was dedicated to remove those repetitions by checking the title of the paper as well as the target (conference or journal) in which it was published. This phase ends up with a set of 829 unique articles.

Apply discarding criteria. The keywords-based automatic search retrieved many articles discussing problems and solutions on software language engineering. However, not all of them where relevant to the scope of the literature review. Therefore, we conducted a discarding process based on a two-fold discarding criteria presented below. Those criteria were applied on titles, abstracts and conclusions. At the end of this phase we obtained 236 articles.

• Discard the articles which do not deal with design and/or implementation of DSLs.

• Discard the articles which do not target any of the issues that we have identified as relevant language product line engineering i.e., modularity, composition, and variability management.

Apply selection criteria. After applying the discarding criteria, we applied a second filter intended to select the articles will be definitely part of the discussion. To this end, we defined a two-fold selection criteria that we applied on the article's introductions. This phase resulted in 38 articles.

• Select the articles that have a clear contribution to one or several issues which are relevant on language product line engineering for external DSLs. It is worth highlighting that this filter will exclude works, such as the one presented by Sánchez Cuadrado et al. [START_REF] Sánchez Cuadrado | A model-based approach to families of embedded domain-specific languages[END_REF], dealing with issues on language product lines of internal DSLs.

• Select the articles that present case studies if and only if they offer clear insights to address at least one issue of language product line engineering.

Final result. Figure 4 presents the selected articles classified by year and type of publication. Of the 38 articles included in this literature review, 9 were published in journals, 17 in conferences, 11 in workshops.

The figure shows an increasing interest on the subject represented in an increasing number of publications. The list of articles selected and discarded and in each step of the search protocol is available on-line2 . It is worth mentioning that a possible threat to validity associated to our research protocol is that all the phases were performed by the same person. This decision favors the uniformity of the results but, at the same time, avoids possible discussions which might enrich the selection process.

Validation of the searching protocol. Despite the rigorous process that we followed in order to identify the articles discussed in this literature review, we wanted to be sure that we considered all the papers that are relevant in the area. In particular, we wanted to be sure that the automatic search does not omit any important article. So, we used three strategies to reduce such a risk. First, before conducting this literature review we established a set of articles that we knew in advance and that are relevant in this study. Afterwards, we checked if those papers were included by the automatic search. The results were positive, all papers in the predefined set were included in the automatic search. Second, we checked the papers cited by the 38 articles finally included in the literature review. We select those references that we considered as relevant and we checked that they were also included in the automatic search. The results in this second validation strategy were positive as well; all these relevant articles were included in the automatic search. Finally, we ask a variety of researchers to check our corpus and see if it has some missing works. We obtained several answers pointing out that the main works were considered.

Results

In this section, we answer the research questions introduced before. These results were achieved through a systematic process where each paper was read and analyzed according to the vocabulary presented in Section 2.

RQ.1: The life-cycle of a language product line

The life-cycle of a language product line addresses the same issues addressed by the life-cycle of a software product line (introduced in section 2). However, there are certain particularities that should be considered. Those particularities come out from the specificities of the DSLs development process., and are discussed in many of the articles we selected during the search protocol. We recapitulate these discussions in the rest of this section.

Languages modularization

During the construction of a language product line, language designers should implement DSLs in the form of interdependent language modules which materialize language features. Each module provides a set of language constructs, and a DSL is obtained from the composition of two or more language modules.

Just as in components-based software development [START_REF] Tripakis | Automated module composition[END_REF], languages modularization supposes the existence of two properties: separability and composability. Separability refers to the capability of designing and verifying language modules independently of other language modules it may require. Separability relies on the definition of interfaces specifying the interactions between language modules. In turn, composability refers to the capability of integrate several language modules to produce a complete and functional DSL. Composability relies on the usage of the interfaces between language modules in such a way that they can interchange both control and information. Modular languages design to reach separability. To achieve a modular language design that effectively reaches separability, language designers must (1) decide how to group language constructs into different language modules, and (2) establish the dependencies among them. The first task corresponds to a design process which, ideally, consider classical good practices such as high-cohesion and low-coupling. The second task corresponds to the definition of the interfaces among those language modules. These design dimensions have been discussed in the literature in the form of modularization scenarios [START_REF] Erdweg | Language composition untangled[END_REF][START_REF] Vöelter | Language and IDE modularization and composition with MPS[END_REF][START_REF] Haber | Integration of heterogeneous modeling languages via extensible and composable language components[END_REF]. A modularization scenario describes a situation where two language modules interact each other according to the nature of the dependencies existing among their constructs. Those scenarios are explained in the following. As the reader will notice, the modularization scenarios have named differently along the literature. A unified vocabulary is presented in Table 2.

The modularization scenario called self-extension will not be discussed in this literature review because it is only applicable to the case of internal DSLs.

• Extension: Extension is a modularization scenario where a base language module is enhanced with new capabilities provided by an extension language module. Such new capabilities can be either new language constructs or additional behaviors on top of the existing constructs [START_REF] Torgersen | The expression problem revisited[END_REF].

For instance, a language for expressing finite state machines can be extended to support hierarchical state machines by introducing the notion of composite state [START_REF] Keating | Hierarchical state machines[END_REF]. In such a case, the extension module introduces a new construct (i.e., CompositeState) completing the specification at the level of the abstract syntax, the concrete syntax, and semantics. The same language can be also extended with a pretty printing operation that returns a string representation of the entire state machine.

• Restriction: Unlike extension, restriction refers to the modularization scenario where capabilities of a base language module are reduced by a restriction language module. In other words, some of the constructs offered by the base language are disabled so they cannot longer be used. In [START_REF] Mernik | An object-oriented approach to language compositions for software language engineering[END_REF] the author introduces an illustrative example for restriction where a base language for controlling a robot is restricted by removing some of the movement commands initially provided.

Restriction is commonly identified as a particular case of extension [START_REF] Erdweg | Language composition untangled[END_REF][START_REF] Vöelter | Language and IDE modularization and composition with MPS[END_REF]. A language construct can be disabled by either overriding an existing language construct, or introducing additional constraints that, in the validation phase, avoid the acceptance of models/programs which include the restricted construct. In this article, we consider extension and restriction as different modularization scenarios -they have not only different but also opposite purposes -that can be addressed by means of similar modularization techniques.

• Aggregation: Aggregation refers to the modularization scenario where a requiring language module uses (and incorporates) some language constructs provided by a providing language module. Consider for example the case where a language for modeling finite state machines uses the functionality provided by a constraint language for expressing guards in the transitions.

• Referencing: Similarly than aggregation, in referencing a requiring language module uses some constructs provided by a providing language modules. However, in this case the requiring language It is worth mentioning that, although this modularization scenario has been discussed in the literature of software language engineering, we did not found evidence that demonstrates its relevance in the language product lines life-cycle. This is because the objective of a language product line is to provide mechanisms to compose complete variants of a DSLs specification and, in this case, composition has a different meaning being more related to orchestration of models/programs.

• Unification: Unification refers to the modularization scenario where two independent languages, initially conceived for different purposes, are composed to produce a language with more powerful functionality. The main difference with respect to the other modularization scenarios introduced so far is that in this case there is not dependency between the involved languages. Rather, they are independent one from the other, and some glue code is needed for the composition. Note that in this case, the interface between the involved language modules is specified as a third language module containing the glue code.

As an example of unification consider the research presented in [START_REF] Oney | ConstraintJS: Programming interactive behaviors for the web by integrating constraints and states[END_REF] where a language for state machines is unified with the CSS (Cascading Style Sheets) language. The purpose is to facilitate the definition web interfaces. The work is based on the idea that a state machine can be used to represent user interactions whereas CSS can be used for expressing web pages' style.

The modularization scenarios presented so far can be applied in complex situations involving more than two language modules. This case is known in the literature as extension composition. Consider for example the case presented in Fig. 5 where the web styling language CSS is unified with a state machines language that, in turn, uses the functionality of a constraints language (i.e., aggregation) and that is extended by the notion of composite states. It can be viewed as a sort of algebra that allows to structure relationships composition among several language modules in terms of the scenarios presented so far.

Language modules composition to reach composability. One of the particularities of the DSLs implementation is that the tooling associated to a DSL (e.g., parsers or validators) is rarely built by language designers. Rather, such a tooling is automatically generated from the DSLs specification by language workbenches. For example, the parsers of the DSLs are often generated from a BNF-like grammar; those parsers might include capabilities such as syntax coloring or auto-completion.

As a consequence of this particularity, language modules composition can be performed either at the level of the specification [START_REF] Erdweg | Language composition untangled[END_REF][START_REF] Mernik | An object-oriented approach to language compositions for software language engineering[END_REF] or at the level of the tooling [START_REF] Wu | Component-based {LR} parsing[END_REF]. In the first case, the principle is to compose the specifications of each language module thus producing one joint specification that is used to automatically generate the tooling of the entire DSL. In doing so, the composition phase should compose the implementation artifacts containing the language modules specifications while clearly defining the semantics of the composition so the language constructs can correctly interact among them. In the second case, the principle is to first generate the tooling corresponding to each language module, and enable mechanisms to support the interaction between those "tooling modules".

It is worth mentioning that language modules composition requires a previous phase of compatibility checking. In this context, compatibility checking corresponds to verify that the interface between two language modules is consistent according to the modularization scenario. In the case of extension, the interface is consistent if the elements used in the extension module correspond to elements defined in the extension points of the base module. Similarly, in restriction we need to check that the elements that are being restricted in the restriction module corresponds to elements that actually exist in the restriction point of the base module. For the case of aggregation and referencing, compatibility checking is performed by verifying that the requirements of the requiring language module are correctly fulfilled by the constructs offered in the providing language module. Finally, in unification we need to check compatibility between the glue code with respect to the left and right modules.

The substitutability principle. Substitutability is an important property in components-based software development. It states that software modules should be easily interchangeable with other software modules providing the same functionality. Substitutability has been largely discussed in object oriented programming [START_REF] Liskov | A behavioral notion of subtyping[END_REF], and it is also relevant in modular language design [START_REF] Jézéquel | When systems engineering meets software language engineering[END_REF]. Indeed, when language designers are facing the problem of variability, substitutability becomes not only relevant issue, but also necessary.

Being transversal to modular languages design, and to language modules composition, substitutability is not easy to address. Language modules should be as less coupled as possible, and properties such as polymorphism are required. We will discuss later how current approaches address this challenge.

Languages variability management

Language variability management is the second component of the language product line's life cycle. The specificities of the application contexts where a DSL can be applied suppose adaptations should be systematically managed. In the case of DSLs, the variability management process should take into account the three dimensional nature of the specification of a DSL. In this section, we discuss the impact that this fact has on the variability management of a language product line.

Multi-dimensional variability modeling. The variability existing between DSLs should be explicitly represented in order to identify the combinations of language modules that, once assembled, will produce valid DSLs. The fact that a DSL is specified in different implementation concerns implies different dimensions of variability [START_REF] Cengarle | Variability within modeling language definitions[END_REF][START_REF] Grönniger | Modeling language variability[END_REF]. Let us summarize each of these dimensions.

• Abstract syntax variability (or functional variability) One of the motivations for the construction of language product lines is to offer customized languages that provide only the constructs required by a certain type of users. The hypothesis is that it will be easier for the user to adopt a language if the DSL only offers the constructs he/she needs. If there are additional concepts, the complexity of the DSL (and the associated tooling) needlessly increases and "the users are forced to rely on abstractions that might not be naturally part of the abstraction level at which they are working" [START_REF] Zschaler | VML* a family of languages for variability management in software product lines[END_REF].

Abstract syntax variability refers to the capability of selecting the desired language constructs for a particular type of user. In many cases, constructs are grouped in language features in order to facilitate the selection. Such grouping is motivated by the fact that, usually, selecting constructs can be difficult because a DSL usually has many constructs, so a coarser level of granularity is required.

• Concrete syntax variability (or representation variability) Depending on the context and the type of user, the use of certain types of concrete syntax may be more appropriate than an other one. Consider, for example, the dichotomy between textual or graphical notations. Empirical studies such as the one presented in [START_REF] Mora | Graphical versus textual software measurement modelling: an empirical study[END_REF] show that, for a specific case, graphical notations are more appropriate than textual notations whereas other evaluation approaches argue that textual notations have advantages in cases where models become large [START_REF] Eichelberger | A systematic analysis of textual variability modeling languages[END_REF]. Representation variability refers to the capability of supporting different representations for the same language construct. • Semantic variability: Another problem that has gained attention in the literature of software languages engineering is the semantic variation points existing in DSLs. A semantic variation point appears where the same construct can have several interpretations. Consider, for example, the semantic differences that exist between state machines languages explored in [START_REF] Crane | UML vs. classical vs. rhapsody statecharts: not all models are created equal[END_REF]. In that case, a state machine can either comply with the run-to-completion policy or accept simultaneous events. In the first case, events are processed sequentially (one after the other and one at a time) even if two events arrive at the same time. In the second case, simultaneous events can be attended at the same time. Semantic variability refers to the capability of supporting different interpretations for the same construct.

These dimensions of variability are not mutually exclusive. Several types of variability appear at the same time in the same language product line. In such cases, an approach for multi-dimensional variability modeling [START_REF] Rosenmüller | Multi-dimensional variability modeling[END_REF] is required; it should take into account the fact that decisions taken in the resolution of the functional variability may affect decisions taken in the representation and semantics variability.

Figure 6 illustrates multi-dimensional variability in the case of state machines. Each dimension of variability is expressed as a sub-tree. In the case of functional variability, a DSL for state machines is a mandatory feature that requires of an expression language. Timed transitions can be optionally selected as an extension of the DSL for state machines. The semantic variability dimension represents the decisions with respect to the behavior of the state machine. In this example, semantic choices regard to the perfect synchrony hypothesis (an event takes zero time for being executed) and events concurrency. Finally, the representation variability dimension presents the choice between graphical or textual DSLs for state machines.

Multi-staged languages configuration. Once the variability of the language product line is correctly specified, and as long as the language features are correctly mapped to language modules, language designers are able to configure and derive DSLs. There are two issues to consider. First, the multi-dimensional nature of the variability in language product lines, supposes the existence of a configuration process supporting dependencies between the decisions of different dimensions of variability. For example, decisions in the functional variability may impact decisions in semantic variability. Second, language product lines often require multi-staged languages configuration. That is, the possibility of configuring a language in several stages and by different stakeholders.

Multi-staged configuration was introduced by Czarnecki et al. [START_REF] Czarnecki | Staged configuration using feature models[END_REF] for the general case of software product lines, and discussed by Dinkelaker et al. [START_REF] Dinkelaker | Supporting variability with late semantic adaptations of domain-specific modeling languages[END_REF] for the particular case of DSLs. The main motivation to support such functionality is to transfer certain configuration decisions to the final user so he/she can adapt the language to exactly fits his/her needs [START_REF] Dinkelaker | Supporting variability with late semantic adaptations of domain-specific modeling languages[END_REF]. In that case, the configuration process is as follows: the language designer provides an initial configuration. Then, the configuration is continued by the final user that can use the DSL as long as the configuration is complete. In doing so, it is important to decide what decisions correspond to each stakeholder.

As an example, suppose the multi-staged configuration scenario presented in Figure 7. In that scenario, the language designer configures the abstract and the concrete syntax of a DSL for finite state machines. Using those decisions, the language designer can produce a parser and an editor for the DSL. However, the semantics of the DSL remains open so the final user can configure it according to his/her modeling needs. Under the literature, this capability is known as late semantic adaptation [START_REF] Dinkelaker | Supporting variability with late semantic adaptations of domain-specific modeling languages[END_REF]. It is important to mention, however, that this configuration scenario is just an example that illustrates the complexity of the configuration process associated to a multi-dimensional variability modeling approach.

4.1.3. Top-down vs. bottom-up language product lines So far, we have presented the stages that compose the life-cycle of a language product line. We reviewed the main challenges that language designers have to overcome in terms of languages modularization and variability management through the domain engineering and the application engineering phases. Now, we will discuss the order in which those challenges are addressed during the development process, for which there are two different perspectives: top-down and bottom-up [START_REF] Kühn | Apples and oranges: Comparing top-down and bottom-up language product lines[END_REF].

In the top-down perspective, the domain engineering phase is performed first. Then, the produced artifacts are used to conduct the application engineering phase. Language engineers use domain analysis to design and implement a set of language modules and variability models from some domain knowledge owned by experts and final users. Those artifacts can be later used to configure and compose particular DSLs. This top-down approach is appropriated when language designers know in advance that they will have to build many variants of a DSL, and they have some clues indicating that the effort of building a language product line will be rewarded.

Differently, in the bottom-up perspective, the application engineering phase is performed before the domain engineering phase. Language designers start by building different DSLs that address different needs of final users. Then, when language designers realize that there is potential enough to build up a language product line from a set of existing DSLs, these DSLs are analyzed to extract that commonalities and variability that, with appropriated mechanisms, can be used to reverse engineer language modules and variability models.

RQ.2: Approaches supporting language product line engineering

After reading the articles obtained from the search protocol, we identified a set of approaches supporting (partially or completely) the language product line's life-cycle. Those approaches are listed in table 3.

There is a clarification to point out in this table. There are two approaches i.e., Neverlang+AiDE and ASF+SDF+FeatureHouse that are more than single approaches are the combination of several approaches. Whereas Neverlang and ASF+SDF are approaches for the construction of DSLs, AiDE and FeatureHouse are tools for variability management. In this literature review, we group those approaches since they have been used together to support language product line engineering. This decision facilitates the study of the approaches.

RQ.3: Current support for the language product lines' life-cycle

In this section, we analyze how the aforementioned approaches support each step of the language product line's life-cycle.

Support for languages modularization

Languages modularization has been largely discussed in the literature. Indeed, the most part of the approaches that we discuss in this article aim to support languages modularization. In the following we discuss current advances in modular languages design and language modules composition.

Support for modular languages design. We have identified two modularization techniques intended to support modular languages design. Those techniques vary with respect to the way in which bindings between language modules are expressed; they are explained below:

• Endogenous modularity. In endogenous modularity, bindings between language modules are defined as part of the modules themselves. Usually those bindings are direct references between language modules such as the import clause. One important characteristic of endogenous modularity is that, because the modules are linked each other, the importing module has direct access to all the definitions provided by the imported one. As a result, the importing module can easily extend or use these definitions.

This approach results quite useful from the language designer's point of view because it is straightforward, and it enables IDE facilities such as auto-completion. Contrariwise, the disadvantage of endogenous modularity is that it does not favor language modules substitutability because dependent modules are strongly linked each other. Replacing one language module for another one requires some refactoring to change the direct reference and, in many cases, adapt to the definitions of the new imported module. This form of modularization favors high coupling between modules.

• Exogenous modularity. In exogenous modularity, bindings between language modules are defined externally. Usually, approaches based on exogenous modularity provide mechanisms (for example composition scripting languages) to describe those bindings in third-party artifacts that are the input of the composition process. In this case, language modules do not know the language modules they will be composed with. Hence, they cannot directly use foreign language constructs. To deal with this problem, language modules declare a set of requirements that are intended to be fulfilled in the composition phase. Those requirements are indirect references to language constructs that are defined in another module.

Note that this approach favors language modules substitutability. Since there are not direct references between language modules, the bindings can be changed in the external artifact without modifying the modules themselves. Besides, because the dependencies between language modules are expressed as declarations, modules can be interchanged by any module that provide language constructs compatible with the declarations. The disadvantage of this approach is that it introduces additional complexity in the development process. Language designers need to consider not only the construction of the modules, but also the binding artifacts and manage indirect references.

The importance of these modularization techniques relies in two issues. First, they influence the way in which the interfaces that support the modularization scenarios (introduced in section 4.1.1) are addressed. Second, they constraint the type of composition strategy used for the composition of language modules. In the reminder of this section, we will discuss how the modularization scenarios are addressed through the modularization techniques. Afterwards, we analyze the composition strategies required in each case. We do not include the modularization scenario called referencing in our analysis because, as we said earlier, we did not find evidence of its relevance in the language product lines life-cycle.

• Endogenous modularity to support extension and restriction. Endogenous modularity is useful to support extension and restriction of language modules. In this case, base modules are imported by extension modules; then extension modules can access and enhance the definitions of the base modules while introducing new constructs, behavior or constraints.

LISA is one of the approaches that use endogenous modularization to support extension/restriction of language modules. In LISA, language designers define language modules thought attribute grammars that can be imported and extended by extension modules. Extension modules can introduce new production rules and/or overriding existing ones. • Exogenous modularity to support extension and restriction. Also, there are approaches based on exogenous modularization to support extension and restriction of language modules. In this case, the extension modules do not import a specific base module. Rather, the binding between the extension and the base module is specified eternally, so extension modules have not direct access to the constructs of the base module. In the composition phase, both base and extension modules are composed thus introducing to the base module the constructs, behavior, or constraints defined in the extension module. Following this strategy, the base module can be easily substituted by another one as long as it provides the constructs used as extension points.

Neverlang is one of the approaches that use exogenous modularity to support extension of language modules. In Neverlang, a base module is specified in a BNF-like grammars that can be enhanced by extension modules introducing new production rules. Figure 9 illustrates this capability with the example of state machines and composite states. The base module is a simple DSL for state machines and the extension module introduces a new production rule for the construct State, thus introduction the notion of composite state. Note that there is a composition script (in the middle of the Figure 9) that indicates that a language called CompleteStateMachine is the result of the composition of the language modules called StateMachines (base module) and CompositeStates (extension module).

• Endogenous modularity to support aggregation. Endogenous modularity is also useful to support aggregation of language modules. As we said before, in aggregation of language modules we have a requiring language module that uses the language constructs provided in a providing language module. In the case of endogenous modularity, the requiring language module imports the providing language modules thus having access to all its language constructs.

Figure 10 illustrates endogenous aggregation of language modules in LISA. In the top of the figure, there is a language module that defines a DSL for state machines which requires boolean expressions to express guards in the transitions. Such boolean expressions are provided by the language module presented at the bottom of the figure, and which is imported by the state machines DSL. In this case, we use the import clause not for extend some language constructs, but to use those language constructs in the definition of new ones. Hence, the language constructs used by the requiring language are used at the left of the production rules.

• Exogenous modularity to support aggregation. Aggregation of language modules can be supported via exogenous modularity. In this case, the requiring module declares a set of language constructs that are supposed to be implemented in a providing language module.

Consider the example introduced in Figure 11 that uses Neverlang in the same example of the state machines language and expressions. In that case, the production rule for the construct transition uses the non-terminal Expression. Since this non-terminal is not implemented in the language module, it represents a declaration that is intended to be fulfilled by another language module. At the bottom of the figure, we introduce an expression language which implements the required language constructs. At a first view, one might think that there is not difference between endogenous and exogenous aggregation. However, the fact that the requiring language module does not reference directly the providing language module results quite useful for facilitating modules substitutability. Note that the providing language can be replaced for any other language that implements the construct Expression.

To do so, language developers need just to change the binding and execute the composition. As a matter of fact, we can find approaches in which the substitutability is even more favored by introducing some mechanisms that permit to declare those requirements in a more abstract way.

• Endogenous modularity to support unification and extension composition. Endogenous modularity is also useful to support unification of two language modules (a.k.a., left/right modules).

As aforementioned, ideally these language modules should not be modified during the unification process, so the most common solution is to create a third language module (a.k.a., integration module) containing the glue code that specifies the semantics of the integration. In the case of endogenous new parsing algorithm that supports modular parsing. In this approach, the parser of a DSL can be defined as a set of interdependent parser modules, and the complete parsing process is supported by the parsing algorithm that can "visit" several parser modules.

In the case of specification composition, we found two different techniques used for the composition techniques; we briefly explains those techniques in the following.

• Direct linking to compose endogenous modules. In endogenous modularization, implementation artifacts are physically related via direct linking usually realized through the import clause. In direct linking, all the content of the referenced artifact is included at the beginning of the referencing one.

The involved artifacts should be viewed as a unique specification.

• Artifacts merging to compose exogenous modules. In exogenous modularization, implementation artifacts are completely independent so there are not direct links between them. Hence, their content should be unified during the composition phase, thus producing a unique artifact containing a joint specification.

Many of the approaches studied in this literature review propose composition strategies based on direct linking. Despite the limitation of direct linking with respect to the substitutability principle, it has demonstrated to be useful to support the modularization scenarios presented in Section 4.1.1. This is because the importing language module can access all the language constructs of the imported one, thus enabling any type of relationship among them. However, there are other approaches whose composition strategy is based on some composition operators, which formally define the semantics of the composition. Such operators are optional in the case of direct linking, but mandatory in the case of artifacts merging. In the following we explain the composition operators that we found during the conduction of this literature review.

• Inheritance. Inheritance is a mechanism to exploit reuse coming from object oriented programming.

It has demonstrated to be useful as composition operator for language modules [START_REF] Mernik | An object-oriented approach to language compositions for software language engineering[END_REF]. Generally, approaches that use inheritance as composition operator are based on endogenous modularity. This can be explained by the nature of the inheritance relationship, which is intended to reuse the specification provided in a concrete implementation artifacts for which direct linking results quite useful.

In inheritance, the composition rules are based on the notions of extending and overriding, which are useful to compose the interfaces of the modularization scenarios introduced in section 4.1.1. In the case of extension, the extension point is a language construct in the base language that is extended by some language construct in the extension module. In restriction, the restriction point is a language construct in the base language that is overridden by some language construct in the restriction module. In aggregation, the provided module accesses the requiring module through an inheritance relationship. Indeed, if the requiring module inherits the providing one, then it will be permitted to access (and use) all their constructs. In the cases of unification and extension composition, the glue code can be implemented by a language module that inherits all the modules involved in the composition. Naturally, multiple inheritance is needed to support this scenario.

• Merge. Merging can be defined as the combination of two artifacts where "the common elements are included only once, and the other ones are preserved" [START_REF] Marchand | A categorical model of model merging and weaving[END_REF]. In language modules composition, merging is an additive operator that sums the language constructs provided by the language modules involved in the composition while avoiding repetition. Due to the capability of merging to integrate independent artifacts, it is generally used by approaches based on exogenous modularization.

When using the merge operation, the "common elements" become quite important. They represent the interfaces between the language modules, and can be used to address all the modularization presented in section 4.1.1. In the case of extension, the extension module declares language constructs corresponding to the extension point as part of their definitions. In the composition phase, the declaration of the extension point provided by the extension module is merged with the implementation of those constructs provided by the base module. A similar approach is used in the case of aggregation.

The requiring language module declares the language constructs that it uses, and in the composition phase these declarations are merged with the actual implementation of the constructs provided by the providing language module. This idea can be generalized for the composition of more than two language modules to support both unification and extension composition.

• Superimposition. Superimposition is a particular case of merging. Indeed, the superimposition operator is defined as the merge of two implementation artifacts. As a result, its applicability for language modules composition is quite similar than the one for merging. The difference between merge and superimposition is that, in the later, the implementation artifacts are intended to be modeled in a tree-based structure. This is because the superimposition operator is recursive, and their semantics are formalized as composition of trees. Similarly than in the case of merging, superimposition is used in approaches based on exogenous modularization.

• Weaving. Weaving is another operator has been used in the literature to support languages modularization. It supposes the existence of a base module and an aspect [START_REF] Marchand | A categorical model of model merging and weaving[END_REF]. The base module is enhanced by the features introduced by the aspect. Language designers must define the exact point (i.e., the join cut) in which those features will be injected. The definition of weaving let it open to be applicable in both endogenous and exogenous modularization. That means that the binding between the aspect and the base module can be defined either in the aspect itself or in an external artifact.

The nature of the weaving operator makes it appropriate to support languages extension and restriction. In that case, the extension point is the point cut which is enhanced with the functionality implemented in the advice. During the conduction of this literature review we did not find any evidence that indicates that weaving can be used to support the other modularization scenarios.

Current approaches dealing with languages modularization. Fig. 4 shows how current approaches support languages modularization. In particular the figure presents table which, for each approach, indicates:

(1) the modularization scenarios it supports, (2) the modularization techniques it uses, (3) whether the composition is performed at the level of the specification or tooling, and (4) the composition operator it provides (if any).

The most remarkable conclusion of this figure is that endogenous and exogenous modularization are not mutually exclusive. Indeed, Monticore uses endogenous modularization in junction with the inheritance operator to support language modules extension and restriction. In turn, Monticore it uses exogenous modularization and merge to support language modules aggregation.

Support for languages variability management

In contrast to the large amount of articles on languages modularization, we found few articles addressing languages variability management. In the following we discuss the current advances in this regard.

Support for multi-dimensional variability modeling. All of the current approaches supporting languages variability modeling are based on feature models, and vary with respect to the modeling approach they use to represent the variability. In particular we found three different modeling approaches.

• Feature models supporting functional variability. Wende et al. [START_REF] Wende | A role-based approach towards modular language engineering[END_REF] use feature models as a documentation artifact to present a catalog of language features that can be combined each other to produce different variants of a DSL. The modeling approach that they propose is illustrated in Figure 14. In that approach, each feature is associated to a language module that is completely specified in terms of abstract syntax, concrete syntax, and semantics.

This approach is quite useful in language product lines with functional variability. Each language feature can be viewed as a fully specified set of language constructs that will be selected or not according to the needs of the final user. However, support for concrete syntax variability and semantic variability is limited. For example, if a language designer needs to represent semantic variability, he/she will have to define two language modules with the same abstract and concrete syntax but with

Extension ! ! - ! - ! ! ! - ! - ! ! ! Restriction ! ! - ! - ! ! ! - ! - ! ! ! Aggregation ! ! ! ! ! ! - ! ! ! ! ! ! ! Unification ! ! ! ! ! ! ! ! ! ! ! ! ! ! Extension Composition ! ! ! ! ! ! ! ! ! ! ! ! ! !

Modularization technique

Endogenous modularization

! - - ! ! ! - ! - ! - ! - - Exogenous modularization - ! ! - - - ! - ! - ! ! ! !

Composition strategy

Specification composition

! ! ! ! ! ! ! ! ! - ! ! ! ! Tooling composition - - - - - - - - - ! - - - - Composition operator Inheritance ! - - - - - - - - - - ! - - Merge - ! ! - - - ! - ! - ! ! ! - Superimposition - - - - - - - - - - - - - ! Weaving - ! - - - - - - - - - - - -

LISA

Abstract syntax

Grammars-based

! - - - - - - - - - ! ! ! Metamodels-based - ! ! ! ! ! ! ! ! ! - - -

Concrete syntax

Textual

! - ! ! - ! - - - ! ! ! ! Graphical - - - ! - - ! - - - - - - Semantics Static ! ! - ! - ! - - - - ! ! ! Operational - ! - ! - - - - - ! - ! - Denotational ! - ! - ! ! - ! - - ! - ! Axiomatic - - - - - - - - - - - - -
Table 4: Mapping current approaches with language modularization different semantics. In doing so, language designers would introduce specification clones (repeated segments of specification) all along the language product line, thus increasing maintenance costs.

• Multi-dimensional variability with concern-specific features. The approach presented in [START_REF] Vacchi | Variability support in domain-specific language development[END_REF] proposes to deal with variability management on top of Neverlang using the Common Variability Language. This approach considers not only abstract syntax variability, but also concrete syntax and semantic variability. To this end, the approach proposes to use feature models by following the modeling strategy illustrated in Figure 15 where abstract features are used to represent a segment of abstract syntax that may vary in terms of concrete syntax or semantics. The children features represent the possible variations.

Consider, for example, the feature called "Feature 1" that represents a language feature with a variation point in the concrete syntax. The "Feature 1" is mapped to a language module that encapsulates the corresponding abstract syntax and semantics (that do not vary). Besides, there are two children that indicate the different representations of the feature. Each of these children is mapped to a language module that implements the corresponding concrete syntax.

• Multi-dimensional variability with concern-specific subtrees. The approach to support variability management is based on feature models to represent multi-dimensional variability [START_REF] Cengarle | Variability within modeling language definitions[END_REF]. In other words, this approach supports not only abstract syntax variability, but also concrete syntax and semantic variability. To support multi-dimensional variability, the authors propose an approach in which the variability model has (at the first level) one child feature of the root for each dimension of variability. Figure 16 illustrates this modeling approach. In that example, the sub-tree concrete syntax has two language features (i.e., feature 1 and feature 2) that represent two different representations of a particular construct (or set of constructs). Each feature is implemented in a language module that The approach presented in [START_REF] Liebig | Feature-oriented language families: A case study[END_REF] proposes the use of FeatureHouse as a languages variability management framework on top of ASD+SDF. It supports not only functional variability but also syntactic and semantic variability. The variability modeling approach is quite similar to the one used in Mon-tiCore and illustrated in Figure 16. This variability management mechanism provides facilities to configure and derivate languages from a given feature model.

Multi-dimensional variability requires a modularization approach that supports the definition of each implementation concern (i.e., abstract syntax, concrete syntax, and semantics) in a different language module. In the cases where such a separation is not provided, multi-dimensional variability is not possible.

There are some approaches that go further in the study of variability management in language product lines by proposing to automatically infer variability models from a given set of language modules. The first approach (presented in [START_REF] Vacchi | Automating Variability Model Inference for Component-Based Language Implementations[END_REF]) proposes a search-based technique to find a features model that represents the variability existing in a set of language modules while optimizing an objective function. This approach uses a domain ontology that describes the main concepts of the domain of the language product line. The second approach (presented in [START_REF] Kühn | Choosy and picky: Configuration of language product lines[END_REF]) refines the former by removing the ontology as an input. This improvement is motivated by the difficulty behind the construction of such ontology. Then, the authors propose to annotate the BNF-like grammar with certain information that is used to create a variability model.

Is worth highlighting that these approaches support not only abstract syntax variability but also concrete syntax and semantic variability. In the first case, since the ontology represents the domain from both the syntax and semantic point of view, then it is possible to use it to identify all the existing variation points. In the second case, the annotations provide the expressiveness enough to address all these dimensions of the variability. Support for multi-staged languages configuration. The use of feature modeling to represent the variability of language product lines entails some support for languages configuration. Indeed, the most part of the tools for feature modeling, provide capabilities to create different configurations from a given variability model. As a result, once the variability of a language product line is modeled in a tool-supported feature model, language designers already have some facilities to produce configurations that can be used in to select the corresponding language components and start the composition process.

Once language designers have a tool for configuration of feature models, they should define a multi-staged configuration process involving final users if needed. As the reader might imagine, multi-staged configuration is more an organizational capability that defines the configuration decisions each stakeholder should make and basic configuration tool support can be used to this end.

There are, however, some approaches that enable certain tool features to ease this process. In particular, the approach presented in [START_REF] Cengarle | Variability within modeling language definitions[END_REF] proposes to express configurations of a feature models configuration files. Each file is a refinement of of the configuration decisions then providing certain traceability and more clear assignation of the configuration decisions. This is particularly relevant when feature models become bigger.

Current approaches dealing with languages variability management. Figure 5 shows how current approaches support languages variability management. In particular, the figure presents a table that, for each approach, indicates the capabilities it provides in terms of multi-dimensional variability modeling and multi-staged languages configuration.

Variability modeling

Functional variability

- - - - - - - - - - ! ! ! ! Multi-dimensional variability - - - - - - - - - - - ! ! !

Languages configuration

Features selection In the following, we describe the technological space supported by each of the approaches studied in this literature review.

- - - - - - - - - - - ! ! ! Multi-staged configuration - - - - - - - - - - - ! ! !
• LISA. LISA supports the construction of textual DSLs where the abstract syntax, concrete syntax, and semantics are specified through attribute grammars 3 . LISA supports modular language design and language modules composition. To this end, this approach uses ideas from object-oriented programming. In particular, it introduces the notion of inheritance in attribute grammars. In LISA, language modules are defined as attribute grammars that can have inheritance relationships among them.

• Mélange + Kermeta. Mélange supports the construction of DSLs where the abstract syntax is specified in metamodels, static semantics are defined as class invariants, and the dynamic semantics is defined operationally as aspects in the Kermeta meta-language [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF][START_REF] Jézéquel | Mashup of metalanguages and its implementation in the kermeta language workbench[END_REF]. Melange supports modular languages design and language modules composition.

• Keywords-based modularization. Keywords-based modularization supports the construction of textual DSLs where the abstract syntax is defined in an object-oriented model (a sort of metamodel) and the semantics is defined denotationally through transformations. Keywords based modularization supports modular languages design and language modules composition. To this end, this approach introduces the notion of keyword. A keyword is a language module that contains an object-oriented model to express abstract syntax, a regular expression to express concrete syntax, and a localized transformation to express semantics.

• Meta Programming System (MPS). MPS supports the construction of graphical and textual DSLs whose abstract syntax is defined in metamodels, the concrete syntax is defined through projectional editors, and the semantics is defined operationally in Java programs. This approach supports modular languages design and language modules composition. To this end, MPS enables modularization of the metamodels and provides mechanisms to propagate such modularization at the level of the concrete syntax and semantics.

• Modularization on top of ATL. Modularization on top of ATL supports the construction of DSLs where the abstract syntax is defined in metamodels and the semantics is defined denotationally through transformations. This approach supports modular languages design and language modules composition. More concretely, it introduces modularization on top of the ATL transformation language [START_REF] Jouault | Transforming models with ATL[END_REF].

• Modularization of top of MetaDepth. MetaDepth supports the construction of textual DSLs where the abstract syntax is defined in metamodels, static semantics defined in constraints, and dynamic semantics is defined denotationally through transformations. MetaDepth supports modular languages design and language modules composition. To this end, this approach is based on metamodels extensions, and structural concepts.

• Gromp. Gromp supports the construction of graphical DSLs whose abstract syntax is defined in metamodels, and the concrete syntax is defined in Picture (a platform for the definition of graphical DSLs built on top of EMF). Gromp supports modular languages design and language modules composition. To this end, this approach provides a composition language that allows language designers to manually describe the composition of several language modules.

• Domain-concepts based modularization. Domain-concepts based modularization supports the construction of graphical DSLs whose abstract syntax is defined in metamodels and dynamic semantics is defined denotationally through transformations. This approach supports modular design and language modules composition. To this end, the approach provides a pool of composition operators that can be used for expressing the composition of language modules (which are referred to as domain-concepts). This approach is applied to a real world case study that is presented in [START_REF] Pedro | Developing domain-specific modeling languages by metamodel semantic enrichment and composition: A case study[END_REF].

• Interfaces-based modularization. Interfaces-based modularization supports the construction of metamodels based DSLs. Neither concrete syntax nor semantics are addressed in this case. This approach supports modular languages design and language modules composition. To this end, the approach follows a principle based on language interfaces. The authors define metamodel interfaces to metamodel fragments that can be later composed according to some predefined operators.

• Components-based LR parsing. Components-based LR parsing is an approach that supports the modular definition of parsers defined through grammars. From all the articles reviewed in this literature review, this is the only one that uses tooling composition as composition strategy. The authors justify their decision by arguing that it favors low coupling in language modular design. Semantics are not addressed by the approach.

• Roles-based modularization. Roles-based modularization supports the construction of textual DSLs where the abstract syntax is defined in metamodels, the concrete syntax in BNF-like grammars, and semantics is specified operationally in Java programs. The ideas proposed in this approach are implemented in the LanGems workbench [START_REF] Dinkelaker | Implementing and composing mdsd-typical dsls[END_REF]. This approach supports modular languages design and language modules composition. Additionally, the authors propose a first step towards variability modeling. Languages configuration and derivation is not addressed.

• MontiCore. MontiCore supports the construction of textual DSLs where the abstract and concrete syntax are defined in BNF-like grammars, and semantics are defined denotationally in a theorem prover. MontiCore provides an extended format for grammars that enhances the classical context-free grammar notation with some mechanisms offered by metamodels (e.g., data types, inheritance, interfaces, and associations). This approach supports modular languages design and language modules composition. Additionally, we found an approach to address variability modeling and languages configuration on top of MontiCore [START_REF] Cengarle | Variability within modeling language definitions[END_REF].

• Neverlang+AiDE. Neverlang+AiDE supports the construction of textual DSLs where the abstract and concrete syntax are specified in BNF-like grammars, static semantics is specified as validation programs, and dynamic semantics is defined operationally in Java programs. This approach provides support for modular languages design and languages composition. Additionally, we found several approaches that support variability management on top of Neverlang.

• ASF+SDF+FeatureHouse. ASF+SDF+FeatureHouse supports the construction of textual DSLs where the abstract and concrete syntax are specified in BNF-like grammars, and semantics is specified denotationally through transformations. This approach is a tool chain composed of ASF, SDF, and FeatureHouse. ASF+SDF provides support for modular languages design and languages composition [START_REF] Klint | A meta-environment for generating programming environments[END_REF][START_REF] Van Den Brand | Compiling language definitions: The ASF+SDF compiler[END_REF][START_REF] Bravenboer | Stratego/XT 0.17. a language and toolset for program transformation[END_REF]. In turn, the approach presented in [START_REF] Liebig | Feature-oriented language families: A case study[END_REF] proposes the use of FeatureHouse as a languages variability management framework on top of ASD+SDF.

As a summary of the discussion presented in this section, we introduce the mapping that relates each approach with the DSLs technological spaces it supports. The results are summarized in Table 6.

RQ.5: Open issues and research roadmap

During the conduction of this literature review, we found an important amount of approaches to support the implementation of language product lines. We provide evidence enough to state that, with the current tool support, it is possible to build a language product line in several technological spaces. Concretely, we analyzed a considerable amount of approaches for languages modularization, and we show that the definition of language modules is possible as well as the use of feature models to represent variability in DSLs. We also presented some approaches to automatically generate a first version of those feature models.

Abstract syntax

Grammars-based Despite all these advances, there is a long path to follow. In particular, the methodological aspects of the construction of a language product line are rarely mentioned and never studied properly. The analysis, design, testing, evaluation, and evolution of language product lines are open issues that should be addressed to provide appropriate support to language designers. In the reminder of this section, we discuss the open issues and question that should be addressed to facilitate the construction of language product lines.

! - - - - - - - - ! - ! ! ! Metamodels-based - ! ! ! ! ! ! ! ! - ! - - - Concrete syntax Textual ! - ! ! - ! - - - ! ! ! ! ! Graphical - - - ! - - ! - - - - - - - Semantics Static ! ! - ! - ! - - - - - ! ! ! Operational - ! - ! - - - - - - ! - ! - Denotational ! - ! - ! ! - ! - - - ! - ! Axiomatic - - - - - - - - - - - - - -

Analysis in language product line engineering

In the development of software product lines, the requirements analysis phase is dedicated to the identification and documentation of the common and variable requirements of the product line's final users [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. Naturally, this analysis is quite important in the case of language product lines as well. Language designers must clearly identify and classify the final users of the products of the DSLs that will be produced by the product line, and define their common and variable requirements.

An example of this requirements analysis phase in the context of language engineering is presented by Cazzola and Olivares [START_REF] Cazzola | Gradually learning programming supported by a growable programming language[END_REF]. They identify common and variability requirements for programming languages in the context of education in computer science. In this case, the final users are the students that are classified according to their level in a programming course. The language product line permits to incrementally introduce language features to the students according to their evolution in the learning process.

The analysis phase in language product lines has certain particularities that should be better investigated, however. For example, the notion of requirements in DSLs should be better defined because there is no consensus about what it means. According to the example mentioned above, a requirement in language engineering is associated to the language constructs. Contrariwise, Kolovos et al. [START_REF] Kolovos | Requirements for domain-specific languages[END_REF] associate DSLs requirements to properties such as supportability, orthogonality, or simplicity. A definition of requirements in DSLs development should be accompanied with methodologies to identify them, as well to documentation well practices.

Design in language product line engineering

In the development of software product lines, the design phase is dedicated to the definition of a reference architecture that establishes the set of software modules provided by the product line and the interfaces between them. Besides, in this phase software engineers perform the construction of variability models that capture the variations required by the product line [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. To address this activity, software engineers often use design patterns and modularization properties (such as low coupling and high cohesion) [START_REF] Tizzei | Components meet aspects: Assessing design stability of a software product line[END_REF] to design appropriate reference architectures that support the product line's variability while favoring quality attributes such as extensibility and maintainability.

In the case of language product lines, however, the design of a reference architecture is rarely discussed. As a matter of fact, current approaches are mostly focused on providing the tooling (i.e., language workbenches) to define and compose language modules, and the design itself has been put aside. As a result, language engineers still have problems at the moment of breaking down a language into interdependent language modules to support variability. More concretely, some of the questions that language designers must face are: What is the current level of granularity at which language modules should be defined? How to modularize a language to support the three different types of variability? Is it possible to define design patterns and modularization principles to facilitate modular languages design? Are the properties of low-coupling and high-cohesion relevant in the development of DSLs? If so, how to realize and measure those properties in a given language product line?

Testing in language product line engineering

In the development of software product lines, the testing phase is dedicated to the validation of the implementation artifacts that compose the product line's infrastructure [START_REF] Linden | Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering[END_REF]. To achieve such validation, software engineers must test both the software modules and the variability models.

On one hand, testing interdependent software modules is usually performed in three phases: unit testing, integration testing, and system testing [START_REF] Vincenzi | Component-Based Software Quality: Methods and Techniques[END_REF]. In unit testing, each language module is validated independently to guarantee that the functionality it provides is correctly implemented. In integration testing, the interaction between modules is validated to guarantee that the contracts between modules are respected. In system testing, the system as a whole is validated. Naturally, these basic testing steps should be adapted to the fact that language modules are pieces of abstract syntax enhanced with concrete syntax and semantics.

On the other hand, testing the variability models correspond to verify that the configurations that can be obtained from the feature models produce valid products. To this end, software engineers must design an appropriate set of test scenarios and execute them on the possible configurations. This process can be extremely expensive when variability models become bigger, and prioritization strategies might be required [START_REF] Galindo | Testing variability-intensive systems using automated analysis: an application to android[END_REF].

All the issues mentioned above are still open in language product lines; they are never discussed in the literature discussed in this article. Language designers usually face questions such as: How a language module can be tested independently to verify its localized functionality? How to perform integration tests to validate the interaction between several language modules? How to test entire DSLs produced as a composition of language modules? The difficulty of answering those questions relies on the fact that current approaches in languages testing (such as [START_REF] Wu | Unit testing for domain-specific languages[END_REF], or [START_REF] Semeráth | Formal validation of domain-specific languages with derived features and well-formedness constraints[END_REF]) are intended to test completely specified languages. When a language is partially identified -a language module is a partial language -it cannot be compiled/interpreted and current testing approaches fail. Some research is needed to find out mechanisms that permit to express the requirements that a language module has with its environment (i.e., the required interface) and artificially simulate these requirements as done by mock objects in object oriented programming. It is worth mentioning that in doing so, researchers should into consideration the different implementation concerns of DSLs; not only the abstract syntax but also concrete syntax and semantics [START_REF] Erdweg | The state of the art in language workbenches[END_REF].

Evolution in language product line engineering

Because of the dynamism of business needs, requirements in software products are constantly changing, and evolution is a recurrent concern in software development. The situation is not different in software product line engineering. When the requirements of the stakeholders of a product line change, there is an impact on the product line's infrastructure, and some adaptations might be needed [START_REF] Inoki | Software product line evolution method based on kaizen approach[END_REF].

Evolution in software product lines supposes several challenges and depending on the nature of the evolution in the requirements the infrastructure might change differently [START_REF] Svahnberg | Evolution in software product lines: Two cases[END_REF]. Those changes can be relatively simple to manage (such as the introduction of a new feature without impacting existing ones), or quite painful (such as split or combination of existing features, which supposes adaptations in the variability model re-modularization of the common assets). Besides, requirements evolution might impact not only the implementation artifacts but also documentation and tests.

Evolution is also a recurrent issue in the development of DSLs due to the domain evolution problem. Changes in the domain rules, or simply improving the domain understanding might an impact on DSLs specifications [START_REF] Laird | Towards dynamic evolution of domain specific languages[END_REF]. As a result, the problem of evolution in language product lines is also a concern that language designers must address. Some of the questions to deal with are: How to re-modularize a components-based DSL? How to capture changes in the domain as evolution in variability models?

Threats to Validity

In this section, we discuss the possible threats to validity of our study. Concretely, we discuss three of the different types of validity proposed by Wohlin et al. [START_REF] Wohlin | Planning[END_REF]: construct validity, internal validity, and external validity.

Construct validity. Construct validity evaluates the quality of the methodology followed to obtain the income of the study. In the case of this literature review, this process corresponds to the research method we used to obtain the set of articles included in the discussion (described in Section 3). Does our study include all the relevant articles existing in the literature on language product line engineering?

In order to answer this question, we used a three-fold strategy intended to validate our research method. Such strategy was explained at the end of Section 3; it includes the participation of experienced researchers in the area. Despite such a rigorous process, our methodology could miss some relevant articles. This limitation comes up from four aspects. First, the automatic search phase of our process is based on arbitrary strings. Those strings were carefully selected through a criteria; however there is still a risk of missing some papers that do not fit in the search expression. Second, we performed the automatic search in a set of four digital libraries while excluding other potential sources such as Google Scholar. This decision is also well argued in Section 3; however those sources might also contain relevant articles that we are missing in this study. Third, both selection and discarding processes were performed by only one of the authors of this article. Hence, potential errors might appear at the moment of applying the selection/discarding criteria specially due to the large amount of articles provided by the automatic search. Finally, the discarding and selection process where conducted by reading only titles, abstract, introductions, and conclusion sections. This decision permitted us to deal with the large amount of articles resulting from the automatic search; however, we might be missing some details in the body of the articles that contribute to the discussion.

Internal validity. Internal validity concerns the process used to extract the results from a given income. In the case of this literature review, evaluating internal validity corresponds to evaluate whether our results are consistent with respect to the articles we included in the discussion.

The most important risk in terms of internal validity for this study is the low level of agreement in terms of vocabulary used in the articles. The same word is often used in different articles to refer to different concepts. To deal with this issue, we introduced a background section intended to unify the vocabulary that we used in this paper. Besides, we provide equivalences of vocabulary when needed to clarify the concepts (such as the one presented in Table 2). Still, the vocabulary that we are using might be conflictive with respect to pre-conceived ideas of some of our readers.

External validity. External validity evaluates whether the results obtained in the study can be generalized to closely related areas of endeavor. In the case of this literature review, the evaluation of the external validity corresponds to verify whether our methodology and results can be generalized to other areas of application of Software Product Lines Engineering. For example, we might ask us if the life-cycle of Language Product Lines can be generalized to describe the life-cycle of other product lines such as Games Product Lines [START_REF] Alves | Extracting and Evolving Mobile Games Product Lines[END_REF] or Embedded Systems Product Lines [START_REF] Kim | Applying Product Line to the Embedded Systems[END_REF].

The study provided in this article is based on an abstraction of the generalities of Software Product Lines Engineering. In section 2, we introduced a general life-cycle for software product lines while doing abstraction of the type of products. This permitted to map such a life-cycle to the case in which those products are DSLs. However, while doing such a mapping, we realized that there are certain particularities to consider coming from the specificities of DSLs with respect to other types of software produces. In that sense, we claim that, even if some coarse grained phases of the life-cycle of a software product line can be generalized, there are still some important details to take into consideration coming up from the particularities of each type of software product.

Conclusion

This article reports on an effort for organizing the literature on the applicability of software product line engineering techniques un the construction of domain-specific languages i.e., language product line engineering (LPLE). Being the intersection of two different bodies of knowledge of software engineering, LPLE is motivated by the need of building DSLs that, sharing some commonalities with existing DSLs, have their proper particularities emerging from their specific application contexts.

The main contribution of this article is a detailed study that shows how the works existing today in the literature adapt the life-cycle of a software product line where the software products resulting of configuration processes are DSLs. To this end, we conducted a systematic literature review which includes a large amount of articles, and then we present the results structured in such a way that they are useful for researchers and practitioners. From the point of view of the researchers, this article provides a conceptual framework to understand the challenges behind the construction of language product lines as well as a roadmap envisioning future research directions. From the point of view of the practitioners, this article presents a catalog of approaches that they can use to select the best approach according to the needs of a particular development project involving language product lines.

Figure 1 :

 1 Figure 1: Technological spaces for the implementation of domain-specific languages

Figure 2 :

 2 Figure 2: Phases of the SPLE's life cycle

Figure 3 :

 3 Figure 3: Protocol used to chose the articles included in the discussion.

Figure 4 :

 4 Figure 4: Number of articles per year and type of publication

Figure 5 :

 5 Figure 5: Example of extension composition

Figure 6 :

 6 Figure 6: Multi-dimensional variability for a state machine language

Figure 7 :

 7 Figure 7: Example for multi-staged configuration of a language product line

Figure 8 :

 8 Figure 8: Exogenous extension in LISA

Figure 9 :

 9 Figure 9: Exogenous extension of language modules in Neverlang

Figure 10 :

 10 Figure 10: Endogenous aggregation of language modules in LISA

Figure 14 :Figure 15 :

 1415 Figure 14: Boolean feature models for representing functional variability

Figure 16 :

 16 Figure 16: Boolean feature models for representing multi-dimensional variability

Table 1 :

 1 Strings for automatic search

Table 2 :

 2 Modularization scenarios in the literature

	This article	Erdweg et al.	Vöelter et al. Haber et al.
		[45]	[22]	[52]
	Extension	Extension	Extension	Inheritance
	Restriction	Restriction	Restriction	-
	Aggregation	-	Combination	Embedding
	Unification	Unification	-	-
	Self-extension (-)	Self-extension	Embedding	-
	Referencing	-	Referencing	Aggregation
	Extension composition Extension composition -	-

Table 3 :

 3 Approaches that support language product line engineering

	Name	Articles
	LISA	[65, 66, 67, 68, 55]
	Melange	[69, 70, 71]
	Keywords-based modularization	[72]
	Meta Programming System, MPS	[73, 22]
	Modularization on top of ATL	[74]
	Modularization on top of MetaDepth	[75, 76]
	Gromp	[77]
	Domain-concepts based modularization [78, 79]
	Interfaces-based modularization	[80]
	Components-based LR parsing	[56]
	Roles-based modularization	[81, 82]
	MontiCore	[83, 84, 31, 17, 18]
	Neverlang+AiDE	[85, 41, 86, 87, 88]
	ASF+SDF+FeatureHouse	[89, 90, 91, 16]

Table 5 :

 5 Current approaches dealing with languages variability management 4.4. RQ.4: Mapping current approaches with technological spaces

Table 6 :

 6 Mapping between current approaches and technological spaces for the implementation of DSLs

Although the terms "internal" and "embedded" are sometimes used interchangeably, we use the term internal DSL to avoid the confusions sometimes associated with embedding as composition operator[START_REF] Krahn | MontiCore: a framework for compositional development of domain specific languages[END_REF].

Website of the systematic literature review: http://spltosle-survey.weebly.com/

Semantics defined through attribute grammars is associated to a form of denotational semantics[START_REF] Mayoh | Attribute grammars and mathematical semantics[END_REF].

Acknowledgments

This work is supported by the ANR INS Project GEMOC (ANR-12-INSE-0011); the bilateral collaboration VaryMDE between Inria and Thales; the bilateral collaboration FPML between Inria and DGA; and the European Union within the FP7 Marie Curie Initial Training Network RELATE" under grant agreement number 264840. We thank the anonymous reviewers for their insightful comments, which helped us improve the manuscript.

modularity, the integration module directly imports the left/right modules and uses (or extends) their language constructs to define a unified language.

Consider the example introduced in Figure 12. In that case, the idea is to unify a DSL for state machines with a CSS to provide an approach to define the style of web pages. In particular, the idea is to define state machines with associated style sheets. To this end, there are a glue module that imports both the module containing the state machines language and the module containing the CSS language. Such a glue module extends the construct State to add a new property corresponding to the style sheet. Note that this idea can be generalized to support more complex modularization scenarios. Hence, extension composition can also be supported.

• Exogenous modularity to support unification and extension composition. Exogenous modularity is also useful to support unification of language modules. In this case, the relationship between the third module and the other two is not direct importing but indirect and specified in a composition artifact.

Consider the example presented in the Figure 13 regarding the case of state machines for styling web pages. In this case, the approach for unification is the same that in endogenous modularity with the difference that the binding between language modules is specified externally by a composition artifact. These ideas can be generalized to support extension composition.

Support for language modules composition. As aforementioned, language modules composition can be performed either at the level of the specification (i.e., specification composition) or at the level of the tooling (i.e., tooling composition). The first strategy is most common; in most of the approaches reviewed in this article language modules composition produces a unified specification from a set of language modules. Differently, tooling composition is rarely mentioned in the literature of software language engineering. Indeed, we found only one approach using tooling composition [START_REF] Wu | Component-based {LR} parsing[END_REF].

The solution strategy to implement tooling composition can be compared with the classical mechanisms to achieve software composition. After all, parsers, interpreters, or compilers are software tools that can use classical composition strategies such as interfaces. The article presented by Wu et al., [START_REF] Wu | Component-based {LR} parsing[END_REF] introduces a