coping with semantic variation points in domain-specific modeling languages

Coping with Semantic Variation Points inDomain-Specific Modeling Languages1st International Workshop on Executable Modeling (EXE 2015)

MODELS 2015 Workshops

Florent Latombe1 Xavier Cregut1Julien De Antoni2 Marc Pantel1 Benoıt Combemale3

1University of Toulouse, IRIT, Toulouse, [email protected]

2Univ. Nice Sophia Antipolis, CNRS, I3S, Inria, Sophia Antipolis, [email protected]

3University of Rennes I, IRISA, Inria, Rennes, [email protected]

2015/09/27

IntroductionConcurrency and SVPs

Implementing SVPsConclusion

Table of contents

Introduction

Concurrency and SVPs

Implementing SVPs

Conclusion

F. Latombe, X. Cregut, J. De Antoni, M. Pantel, B. Combemale Coping with Semantic Variation Points in DSMLs 2/36



Context: xDSMLsSemantic Variation Points

Overview

IntroductionContext: xDSMLsSemantic Variation Points


Implementing SVPs

Conclusion





eXecutable Domain-Specific Modeling Languages(xDSMLs)

I Modern systems: Too big to be addressed only as a whole.I Domain-Specific Languages (DSLs) capitalize domain knowledge

(security, fault tolerance, etc.) as language constructs.I Modeling Languages (MLs) provide user-friendly abstractions for

domain experts.I eXecutable DSMLs ease the design, verification and validation of modern

systems.





Overview

IntroductionContext: xDSMLsSemantic Variation Points


Implementing SVPs

Conclusion





Semantic Variation Points

Semantic Variation Point (SVP) , language specification part left intentionallyunder-specified to allow further language adaptation. Usually dealt with:

I Further refinement of the specification (e.g., stereotypes or profiles inUML).

I Arbitrary choices in the implementation (e.g., multithreaded programs inCPython or Jython, fUML, etc.).

I Tool vendors responsible for specifying and documenting theimplemented solution.





Example: priorities of conflicting transitions inStatecharts

Figure 1: Simple music player statechart.

When Event “StopEvent” occurs inStates “On” and “Playing”.

I Original formalism: Transitionfrom “On” to “Off” is fired.

I UML/Rhapsody: Transition from“Playing” to “Paused” is fired.

Courtesy of the comparative study of the dif-ferent Statecharts dialects and their SVPs by M.Crane and J. Dingel [3].





Vocabulary Clarification

I Language: syntax and semantics specification that may contain SVPs.I Dialect: language implementation, making choices about some – possibly

all – its SVPs.





Problem

I SVPs usually identified informally in the syntax and semanticsspecification documents.

I Tools usually only provide one dialect, constraining the end-user.I Complicates cooperation between tools (providing different dialects) and

users (who may assume different meanings for the same syntax).I Hinders cooperation in larger projects using different variants of the

same language that may be better fit for some aspects.





Summary of our Contribution

I A concurrent executable metamodeling approach enabling thespecification of Concurrency-aware eXecutable Domain-SpecificModeling Languages.

I Specification of operational semantics that makes explicit the languageconcurrency concerns in an adapted formalism based on concurrencytheory.

I That allows to explicitly specify and implement xDSML’s SVPs.




Concurrency-aware xDSMLsStatechart Example

Overview

Introduction

Concurrency and SVPsConcurrency-aware xDSMLsStatechart Example

Implementing SVPs

Conclusion





Designing xDSMLsLanguage designLanguage , AS + SD +M(AS,SD) Where:

I Abstract Syntax (AS): concepts and relations between conceptsI Semantic Domain (SD): meaningfull existing languageI Semantic Mapping (M(AS,SD)): maps concepts from the AS to their

meaning in the SD.Three main approaches to the Semantic Mapping: Axiomatic, Translational(incl. Denotational) and Operational.





Overview of the GEMOC Approach

Separation of Concerns(SLE 2013 [2])Split the Semantic Mapping in:

I Semantic Rules: Operationalspecification of the modelruntime state evolution.

I Concurrency Model: Partialordering of abstract actions in aformalism inspired byconcurrency theory.

I Communication Protocol: Relatesabstract actions and SemanticRules.





Concurrency Model

I Called Model of Concurrencyand Communication (MoCC) inGEMOC.

I Focuses on concurrency,synchronization and the, possiblytimed, causalities betweenactions.

I Actions are opaque (datamanipulations are abstracted).

I Given as an EventType Structurewhich builds the EventStructure [10] for each modelconcurrent control flow.





Communication Protocol

I Relates the Concurrency Modeland the Execution Functions

I See Weaving Concurrency ineXecutable Domain-SpecificModeling Languages (SLE2015) [8].





Class Diagram of the concurrent executablemetamodeling approach





Execution

TranslationModel-specific specifications are generated (i.e., Semantic Rules,Communication Protocol and MoCC all specific to the given model).

RuntimeI The Event Structure (MoCC at the model level) gives a partial ordering

over abstract events.I Abstracts all the possible model executions paths (including all

interleavings of concurrent events).I Event occurrences are mapped to model runtime state changes by the

Communication Protocol.I Nondeterministic situations are resolved by runtime heuristics.





Overview

Introduction

Concurrency and SVPsConcurrency-aware xDSMLsStatechart Example

Implementing SVPs

Conclusion


Event Structure for our example modelAt the Language Level

I Main EventTypes:Event.et occur,Transition.et fire

I Main constraints: When anEventoccurs, one of the Transitions ittriggers will be fired.

Event StructureNodesareconfigurations:Unsorted set ofevent occurrenceswhich occured atthis executionpoint.




Illustration of the Separation of Concerns at themodel level




SVPs and Concurrency ModelsExample: Statecharts

Overview

Introduction


Implementing SVPsSVPs and Concurrency ModelsExample: Statecharts

Conclusion





Event Structures and SVPs

I Nondeterminism in Event Structures gives potential SVPs.

I SVPs can be implemented by constraining the Event Structure partialordering.

I Done at the language level in the EventType Structure.





Overview

Introduction


Implementing SVPsSVPs and Concurrency ModelsExample: Statecharts

Conclusion





Example: Conflicting Transitions SVP

Main IdeaI Most of the concurrency concerns are shared by Statecharts dialects.I Statecharts MoCC specifies the superset of possible partial orderings.





Example: Conflicting Transitions SVP (2)

SVP ImplementationsI Dialects extend the common MoCC to restrict partial orderings.

I Removes On2Of for UML/Rhapsody dialects, and Playing2Paused forOriginal dialect.




ImplementationOverviewPerspectivesQuestions

Overview

Introduction


Implementing SVPs

ConclusionImplementationOverviewPerspectivesQuestions





Implementation

I GEMOC Studio1 implementation based EMF [7].I Abstract Syntax: Ecore (EMF implementation of EMOF [9]).I Semantic Rules: Kermeta 3 [6] (based on Xtend [1]).I Concurrency Model: MoCCML [4] and ECL [5].I Communication Protocol: Gemoc Events Language (GEL) [8].

1http://www.gemoc.org/studio


http://www.gemoc.org/studio




Overview

Introduction


Implementing SVPs






Overview of our contribution

I SVPs are usually poorly identified in language specifications.I GEMOC concurrent executable metamodeling approach, based on Event

Structure for the Concurrency Model of concurrency-aware xDSMLsprovides potential SVPs as nondeterministic situations.

I Restricting the partial ordering defined in the Concurrency Modelimplements SVPs.

I SVP implementations are weaved in the language definition, allowing theexecution tool to remain independent from any arbitrary choice.





Overview

Introduction


Implementing SVPs






Perspectives

I Distinguish wanted nondeterminism from potential SVPs (forbidrestrictions).

I Other kind of SVPs using Semantic Rules and/or CommunicationProtocol.

I Integration with SVPs at the syntax level, both abstract and concrete.I Experiment the use of variability management techniques to handle

dialects.

AcknowledgementThis work is partially supported by the ANR INS Project GEMOC(ANR-12-INSE-0011).





Overview

Introduction


Implementing SVPs






Thank you for your attention.Questions?





References IL. Bettini.Implementing Domain-Specific Languages with Xtext and Xtend.Packt Publishing Ltd, 2013.

B. Combemale, J. De Antoni, M. Vara Larsen, F. Mallet, O. Barais,B. Baudry, and R. France.Reifying Concurrency for Executable Metamodeling.In SLE 2013, LNCS. Springer-Verlag.

M. L. Crane and J. Dingel.UML vs. Classical vs. Rhapsody statecharts: not all models are createdequal.SoSyM, 2007.

J. De Antoni, P. Issa Diallo, C. Teodorov, J. Champeau, and B. Combemale.Towards a Meta-Language for the Concurrency Concern in DSLs.In DATE’15, Mar. 2015.





References II

J. De Antoni and F. Mallet.ECL: the event constraint language, an extension of OCL with events.Technical report, Inria, 2012.

DIVERSE-team.Github for K3AL, 2015.

Eclipse Foundation.EMF homepage, 2015.

F. Latombe, X. Cregut, B. Combemale, J. Deantoni, and M. Pantel.Weaving Concurrency in eXecutable Domain-Specific ModelingLanguages.In 8th ACM SIGPLAN International Conference on Software LanguageEngineering (SLE 2015), Pittsburg, United States, Oct. 2015. ACM.





References III

OMG.MOF specification v2.5, 2015.

G. Winskel.Event structures.Springer, 1987.


coping with semantic variation points in domain-specific modeling languages

Science