1. Presenters Names | Aviram Mizrahi & Sara Ziada
Apples and Oranges: - Comparing Top-Down and Bottom-Up Language Product Lines
Presenters Names | Aviram Mizrahi & Sara Ziada

2. Authors Walter Cazzola Thomas Kühn Computer Science Department
Università degli Studi di Milano
Thomas Kühn
Software Technology Group
Technische Universität Dresden

3. Basic Terms Domain-Specific Languages (DSL)
Source: Domain Specific Languages by Martin Fowler
Small languages, focused on a particular aspect of a software system. You can't build a whole program with a DSL, but you often use multiple DSLs in a system mainly written in a general purpose language.
Software product lines (SPL)
Source: Software Engineering Institute | Carnegie Mellon University
Set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.
Language product lines (LPL)
Source: Leveraging Software Product Lines Engineering in the Construction of Domain Specific Languages by David Mendez-Acuna
Software product line where the products are languages. The main principle behind language product lines is to implement DSLs through language features.
Role-Based Programming Languages (RPL)
Source: Apples and Oranges: - Comparing Top-Down and Bottom-Up Language Product Lines
Enable programmers to distinguish between classes and role types as
well as enable objects to dynamically assume and relinquish roles.
Source:
Metamodel
A model that defines the components of a conceptual model, process, or system

4. ABSTRACT Over the past decade language development tools have been
significantly improved.
Multiple researchers have combined different language variants to form families of DSLs. Unfortunately, Current language development tools cannot directly support the development.
Applied ideas from software product lines (SPL) to create product lines of compilers/interpreters for language families, denoted language product lines (LPL)
These product lines can be created either using a top-down or a bottom-up approach. Yet, there exist no case study comparing the suitability of both approaches to the development of LPLs

5. Software Product Line Development
Software product lines (SPL) have been established to increase
the reuse of software artifacts between multiple related products as well as to reduce the cost for the creation of new products.
By means of feature models There are generally two approaches to the construction of feature-oriented SPLs.
Top-Down Approach
Bottom-Up Approach
Related products are analyzed to separate the common base of a product from features provided by individual products.
Reduces the effort of variability analysis and feature modeling by automatically deducing and constructing a feature model and mapping.
Feature model is designed by capturing all possible configurations of a product.
Each feature is mapped to the corresponding software artifact.
Requires the product’s
decomposition into components with respect to their implemented
Features.
To apply this approach, the underlying software system must be refined to support the required variability.
Scales better to larger families of products,
as it supports iterative inclusion of new components by automatically updating.
As the manual analysis of products is time consuming, this approach is usually applied to few products or for new product lines.

6. Language Product Lines
Apply the ideas of SPLs to the design of DSLs and programming languages.
LPL is an SPL of compilers for a family of languages accepting language variants
A language component contains all corresponding
syntactic and semantic descriptions, such that each component
implements a language feature.
It is unclear whether approach is more suitable for the development of LPLs for programming language families.

7. Role-based programming languages (RPL)
Although the notion of roles is very old, their introduction
to programming languages is rather recent.
Basic idea is that objects play multiple roles during their
lifetime when collaborating with other objects.
Enable programmers to distinguish between classes and role types as well as enable objects to dynamically assume and relinquish roles.
To distinguish the various RPLs a feature classification generally distinguishing among three natures of roles: behavioral, relational and contextual.
Most RPLs support the behavioral nature of roles, yet only
few support all three natures.

8. Survey Combine different rolebased languages.
Have access to both the language’s grammar and implementation.
Found 11 approaches ranging from 2003 to 2015.
Six approaches are language extensions to Java, two Scala libraries, and three full-fledged languages (indicated by ).
To account for full-fledged languages, Include two approaches whose syntax and semantics are closely related to Java. As a result, five languages, gray highlighted in Table 1, have been selected as constituents of the family of RPLs.

9. Examples

10. More Examples

11. TOP-DOWN APPROACH
Applied the feature modeling process, however, adapted it to the needs of LPLs. In particular, employed the metamodeling approach to construct a family of RPLs.
In the first phase, variability analysis, uncovered the features provided by the different languages.
Afterwards, those language features are mapped to the metamodel, such that each selected feature corresponds to one or more model elements.
In the last phase, the language’s grammar must also be aligned to the respective metamodel variant.
This approach allows for evolving the syntax of a language family and its language features by means of its abstract syntax separately, as well as reusing the abstract syntax throughout different language variants.

12. TOP-DOWN APPROACH – Feature Model
Only showed features that are supported by languages in the
case study.
Notably though, Relations provides Occurrence Constraints as new language feature to the feature model

13. BOTTOM-UP APPROACH
Follows an iterative process. Starting from a base language (Java), each new language is decomposed into its parts and hooked into the base language
Language decomposition determines not only the granularity of the language features to select, but also the amount of reuse.
If there are multiple language components providing the same language feature for different languages, these components are factored out into the base language
Finally, the feature model and mapping are automatically generated from the language components.

14. Neverlang Framework Approach
Language components are denoted as language modules and encompass any information required to parse, type-check, and evaluate an underlying language construct.
Each component carries a set of provided and required features, as well as a set of tags for each provided feature. These tags denote either the components position in the grammar and / or classify the language feature.
Able to generate both the feature model and the mapping for a given set of language components. Neverlang Framework is perfectly apt for the bottom-up approach.
For more information by Walter Cazzola

15. BOTTOM-UP APPROACH – Feature Model
To generate the feature model for the LPL the base language as well as all language components must be provided to AiDE, which generates the feature model in two simple steps. It first uses the tags to create an initial feature tree and subsequently adds the dependencies between language
components to reflect mandatory, alternative, or required features.
The automatically generated feature model is very complex and hard to understand.
AIDE (Advanced Intrusion Detection Environment) is a file and directory integrity checker.

16. Decomposition of the five languages

17. Comparison Top-Down Approach Bottom-Up Approach
Can create an LPL using the Neverlang Framework.
the effort of the language decomposition limits its utility to closely related or long-living language families.
Although, currently lacks a mechanism to embrace variability in language definitions, the product line could still provide a family of its abstract syntax. This family is very easy to configure and generate due to the good tool support.
The concrete grammar must still be written and maintained manually.
The initial set of decomposed language components will be only gradually extended by new language features reusing most of the already provided language components.
While this might suffice for a small number of language variants, it becomes intractable for a large number of variants, and thus limiting its scalability.
As all language components are consistently tagged, the feature model can be automatically regenerated.
The fluctuating position of features and huge number of dependencies between features impairs the language configuration process.
very hard to maintain if new language features must
be included successively, because for each new language feature the feature model, the feature mapping, and several language variants must be manually updated.
Overall, the scalability of the bottom-up approach is restricted by the effort of the initial language decomposition and limited tool support.

18. CONCLUSION
The top-down approach is more suitable for DSLs with a limited set of features
The bottom-up approach is more scalable and sustainable with respect to the number of language features as well as in case of continuously introducing new features.

19. Still open research questions
How must current language development tools be extended to provide better support for the construction of feature-oriented LPLs?
Can the benefits of a designed feature model be combined with the flexibility of an automatically generated counterpart?
Can the results of this case study be generalized to other families of programming languages (or extensions)?

20. How can the ideas in the paper be utilized for conducting SPLE in the domain you chose?
Mobile Fitness & Health VS

21. Thank You
Any Questions ?