Upload
david-mendez-acuna
View
57
Download
5
Embed Size (px)
Citation preview
David Méndez-Acuña, José A. Galindo, Benoit Combemale, Benoit Baudry, Gurvan Le Guernic DiverSE team INRIA – Rennes. Bretagne Atlantique. France
Reverse-engineering reusable language modules from legacy DSLs
International Conference on Software Reuse (ICSR) 04/06/2016. Limassol, Cyprus
1
Research Context: Language-oriented software development
Software Developer
3
GUI Navigation Rules Data base management
Control Testing
ABSTRACTION
Cryptol, a DSL for cryptographic algorithms XIS-mobile: a DSL for mobile applications
A DSL for intrusion detection based on constraint programming
Basic concepts to design a DSL for parallel finite volume applications: extended abstract
Ebb: A DSL for Physical Simulation on CPUs and GPUs
A DSL for writing type systems for Xtext languages A DSL for cross-domain security
A DSL for describing the artificial intelligence in real-time video games
Ziria: A DSL for Wireless Systems Programming
Green-Marl: a DSL for easy and efficient graph analysis
A Domain-Specific Language for XML Security Standards
A Unified DSL for Testing Architectural Rules
…
Research Context: Many, many DSLs
4
Useful for increasing the level of abstraction at which software is designed
and implemented
Their construction and maintenance is expensive requiring specialized
knowledge and skills.
Phenomenon: Not all the DSLs are completely different!
e.g., Expression Language x + y = 1
5
SQL Logo
FSM JavaScript
Phenomenon: Not all the DSLs are completely different!
6
SQL Logo
FSM JavaScript
How to reuse formerly defined language
constructs to reduce the effort invested in the
implementation of DSLs?
DSL1
An archetypical development scenario
FSM Action scripting for states’ behavior
Constraints for guards in the transitions
8
DSL1
DSL2
How to reuse?
An archetypical development scenario
Logo Turtle
Constraints to specify conditions
9
An archetypical development scenario
copy/paste/modify
copy/paste/modify
copy/paste/modify
Δ Δ
Δ Δ Δ
Δ
DSL1
DSL2
DSL3
DSLn
…
Specification clones + Deltas
11
Bugs replication The evolution is more difficult
Proposed Approach: Reverse-engineering reusable language modules
13
Language designers
DSLs portfolio
Specification clones
Classical DSLs development
Reverse Engineering
for reuse
Language designers
Modularization-based DSLs development
REUSE
Components Catalog
Modules composition
Copy&Paste
Scope: DSLs implemented through executable metamodeling
14
Abstract Syntax
StateMachine
State Transition
Semantics
transitions 0..* states 0..*
S1
T1
S2
T2
T3
T4 S3
void eval () {…}
void eval () {…}
void fire() {…}
1 from
1 to outgoing 0..*
incoming 0..*
call$
call$
weave$
weave$
weave$
Instance: executable model
name : String name : String
Meta-classes Domain-specific actions
Reverse-engineering reusable language modules
5 principles: Principle 1: DSL specifications are comparable. Hence, specification clones can be automatically detected through static analysis
Comparison operators for meta-classes
Comparison operators for domain-specific actions
15
5 principles: Principle 2: Specification clones are viewed as overlapping.
Syntactic overlapping Semantic overlapping
Metaclass Domain-specific action
Constraint.eval() LogoPro.eval()
State.eval() Transition.fire()
StateMachine.eval()
Logo State Machines State Machines
Constraint LogoProgram
Logo
StateMachine
State Transition
16
Reverse-engineering reusable language modules
Step 1: Reverse-engineering language modules
5 principles: Principle 3: Breaking-down overlapping produces reusable language modules.
depends
A B A B B A
A∩B
A∩B
A∩B
depends
17
Step 1: Reverse-engineering language modules
5 principles: Principle 3: Breaking-down overlapping produces reusable language modules.
Semantics (Domain-specific
actions)
Abstract Syntax (Metamodel)
Requiring Module
Semantics (Domain-specific
actions)
Abstract Syntax (Metamodel)
Providing Module <<Model Type>> Requiring Interface
<<Model Type>> Providing Interface
subtypeOf
18
Step 1: Reverse-engineering language modules
5 principles: Principle 4: Abstract syntax first, semantics afterwards.
Syntactic overlapping
Metaclass
Semantic overlapping
Domain-specific action
1 2 Constraint.eval()
LogoPro.eval() State.eval()
Transition.fire()
StateMachine.eval()
Logo State Machines State Machines
Constraint LogoProgram
Logo
StateMachine
State Transition
19
Step 1: Reverse-engineering language modules
5 principles: Principle 4: Abstract syntax first, semantics afterwards.
Meta-classes
Domain-specific actions
20
Warning! Semantic variability: Coming from the diverse interpretations that different DSLs provide to the same constructs.
Step 1: Reverse-engineering language modules
5 principles: Principle 4: Abstract syntax first, semantics afterwards.
21
Step 1: Reverse-engineering language modules
5 principles: Principle 5: Metamodels are directed graphs. Hence, breaking-down a metamodel is a graph partitioning problem. graph-partitioning
22
Validation: Research questions
RQ 1: Ok for the toy examples but… what about real scenarios?
RQ 2: Is this approach actually useful for the community in software languages engineering?
24
The state machines case study. A real set of DSLs.
+ Main case study of the VaryMDE Project!
25
RQ 1: Ok for the toy examples but… what about real scenarios?
The state machines case study. A real set of DSLs.
!!
Language vs. Construct St
ateM
achi
ne
Regi
on
Abs
trac
tSta
te
Stat
e
Tran
sitio
n
Trig
ger
Not
Trig
ger
And
Trig
ger
OrT
rigge
r
Pseu
dost
ate
Initi
alSt
ate
Fork
Join
Dee
pHis
tory
Shal
low
His
tory
Junc
tion
Cond
ition
al
Choi
ce
Fina
lSta
te
Cons
trai
nt
Stat
emen
t
Prog
ram
Nam
edEl
emen
t
Tota
l
UML ! ! ! ! ! ! - ! - ! ! ! ! ! ! ! - ! ! ! ! ! ! 20 Rhapsody ! ! ! ! ! ! - - - ! ! ! ! - ! ! ! - ! ! ! ! ! 18 Harel ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! - ! ! ! ! ! 22
!!! !!!!!
There are known specification clones and deltas in the syntax and semantics
26
RQ 1: Ok for the toy examples but… what about real scenarios?
The state machines case study. A real set of DSLs.
27
RQ 1: Ok for the toy examples but… what about real scenarios?
��
��
���
���
���
�0%+��+!��&-�)#�''!%����%�+�)$*�&������ ��������
��$�%+!��&-�)#�''!%����%�+�)$*�&������������ ��� �� �������
�+�+���� !%����������+�+���� !%���������
�+�+���� !%����������+�+���� !%���������
�+�+���� !%����������+�+���� !%���������
The state machines case study. A real set of DSLs.
28
RQ 1: Ok for the toy examples but… what about real scenarios?
Module 1
UMLLike.aspects
RhapsodyLike.aspects
HarelLike.aspects
Module 3
UMLHarelLike.aspects
! StateMachine ! Region ! AbstractState ! State ! Transition ! Trigger ! Pseudostate ! InitialState
! Fork ! Join ! ShallowHistory ! Junction ! FinalState ! Constraint ! Statement ! Program ! NamedElement
! AndTrigger
Module 2
HarelLike.aspects
! NotTrigger ! OrTrigger
Module 4
UMLLike.aspects
! Choice
Module 5
RhapsodyHarelLike.aspects
! Conditional
Is specification cloning a real phenomenon in the construction of DSLs?
RQ 2: Is this approach actually useful for the community in software languages engineering
Let us ask
29
Reverse-engineering language product lines Future Work
✔ ✔
✔ ✔ ✔
Reverse-Engineering Reusable Language Modules
Legacy DSLs
Reverse-Engineering Languages Variability Models
Assembling Language Modules
Languages Configuration
32
Conclusions
- We provide an approach to detect specification clones in a set of legacy DSLs.
- We provide a reverse-engineering process to extract those specification clones in a set of reusable language modules.
- The extracted modules are defined in terms of language interfaces.
- We use a real case study to validate the correctness of our approach.
- We explore GitHub repositories to confirm that specification cloning is a real phenomenon in software languages engineering.
33