Reverse-Engineering Reusable Language Modules from Legacy DSLs

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

2

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?

The problem

7

DSL1

An archetypical development scenario

FSM Action scripting for states’ behavior

Constraints for guards in the transitions

8

DSL1

DSL2

How to reuse?


Logo Turtle

Constraints to specify conditions

9

DSL1

DSL2


Logo Turtle

Constraints to specify conditions

10


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

12

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


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


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



Meta-classes

Domain-specific actions

20

Warning! Semantic variability: Coming from the diverse interpretations that different DSLs provide to the same constructs.



21


5 principles: Principle 5: Metamodels are directed graphs. Hence, breaking-down a metamodel is a graph partitioning problem. graph-partitioning

22

Validation

23

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



!!

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



27


��

��

��

��

��

�0%+��+!��&-�)#�''!%��%�+�)$*�&��

��$�%+!��&-�)#�''!%��%�+�)$*�&��

�+�+�� !%��+�+�� !%��

�+�+�� !%��+�+�� !%��

�+�+�� !%��+�+�� !%��


28


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

Analyzing the metamodels which name

starts with ‘a’ or ‘b’

30

Analyzing the metamodels which name

starts with ‘u’

31

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

FOR YOUR ATTENTION, THANK YOU!

QUESTIONS, COMMENTS, FEEDBACK?

34