1. MODULAR LANGUAGE
PRODUCT LINES
A GRAPH TRANSFORMATION APPROACH
MODELS’2022, Montreal
Juan de Lara1, Esther Guerra1, Paolo Bottoni2
1Universidad Autónoma de Madrid (Spain)
2Sapienza University of Rome (Italy)
2. FROM DSLs TO
DSL FAMILIES
Modelling languages
• Essential for engineering disciplines
• Model-driven Engineering
• Domain-specific Languages (DSLs)
Does ONE language fit ALL?
• Different users: education, low-code development
Example: Class diagrams with different levels of sophistication
• Different expressivity: modelling purpose, analyses
Example: Petri nets with inhibitor, read arcs, time, colours
• Different levels of precision: to support different project phases
Example: From sketch-like diagrams to fully precise models
Language families!
2
4. 4
Simple link with node
failures and acks
Rich links with
communication failures
EXAMPLE
A DSL FAMILY FOR NETWORKING
5. 5
Simple link with node
failures and acks
Rich links with
communication failures
Rich links with
communication failures
and time
EXAMPLE
A DSL FAMILY FOR NETWORKING
6. HOW TO DEFINE A
LANGUAGE FAMILY?
Define each DSL separately (clone & own)
• Meta-models and rules share commonalities
• Adding a new feature (e.g., ad-hoc networks) doubles the
family size
Define just one “super-language” with all features
• Language difficult to use for users
• Unnecessary concepts
• What about alternative elements (rich vs. simple links)?
6
7. OUR GOAL
A technique to define and manage DSL families that is
• Succinct
(much) less effort than specifying each language variant in isolation
• Extensible
Adding a new variant should be easy, leave existing variants unchanged
Incremental language construction
• Reusable
Specifications of variants as reusable as possible to minimise effort and
avoid duplications
• Analysable
Ensure the behaviour of its variants is compatible with the base behaviour
of the language
7
11. 11
Meta-model elements are identified by name
top module
Cross-tree
constraints
LANGUAGE PRODUCT LINE
EXAMPLE
12. USING THE PRODUCT LINE:
CONFIGURATIONS
12
A set of modules such that
• All top modules are selected
• If a module is selected, then the configuration needs selecting:
1. all mandatory extension modules
2. exactly one alternative extension modules
3. at least one OR extension module
4. its dependency
• The cross-tree constraints evaluate to true
18. DERIVATION:
GETTING THE META-MODEL
Given a configuration
• Merge the meta-model fragments of all modules (co-limit)
18
1= {Networking, SimpleLink,
NodeFailures, Ack}
MM1
19. BEHAVIOUR
Modules have sets of
• Standard rules
• -rules: add elements to standard or -rules
• NAC-rules: add negative application conditions to standard rules
19
Standard rule -rule NAC-rule
20. BEHAVIOUR
Modules have sets of
• Standard rules
• -rules: add elements to standard or -rules
• NAC-rules: add negative application conditions to standard rules
20
Standard rule -rule NAC-rule
{n1→n1, n2→n2}
{n→n1}
{n→n2}
22. CONSISTENT
EXTENSIONS
Product lines made of
extensions preserve semantics
• For every application of the
extended rule, there is a
derivation of the original rule
22
Modular extensions
• - and NAC-rules only add
elements typed by the
module’s meta-model (and not
by the dependency’s meta-
model)
(more details in the paper)
24. EXPERIMENTS
24
Effort reduction w.r.t. explicit definition of each language variant
• Reduces specification size by 86% – 96.6%
• Reduces rule size 91.7% – 97.7%
Effort of adding a new feature?
• Meta-model of sizes 3 – 4 (vs. meta-model size 12 – 22 +
replicating the existing meta-models)
• Between 1 and 2 rules of sizes 3 – 6 (vs. 3 to 12 rules with sizes
between 7 and 14)
(results for rules omitted)
25. CONCLUSIONS AND
FUTURE WORK
Modular approach to define language families
• Considers abstract syntax and semantics
Analysis, tool support, experiments
Future Work
• Fine-granular analysis of (in-)consistency
• Effective testing techniques
• Consider richer meta-model notions (e.g., OCL)
• Modules with several dependencies
• Consider concrete syntax
25
