=Paper=
{{Paper
|id=Vol-1560/paper4
|storemode=property
|title=Coping with Semantic Variation Points in Domain-Specific Modeling Languages
|pdfUrl=https://ceur-ws.org/Vol-1560/paper4.pdf
|volume=Vol-1560
|authors=Florent Latombe,Xavier Crégut,Julien Deantoni,Marc Pantel,Benoit Combemale
|dblpUrl=https://dblp.org/rec/conf/models/LatombeCDPC15
}}
==Coping with Semantic Variation Points in Domain-Specific Modeling Languages==
https://ceur-ws.org/Vol-1560/paper4.pdf
Coping with Semantic Variation Points in
Domain-Specific Modeling Languages
Florent Latombe∗ , Xavier Crégut∗ , Julien Deantoni† , Marc Pantel∗ and Benoit Combemale‡
∗ University of Toulouse, IRIT, Toulouse, France
first.last@irit.fr
† Univ. Nice Sophia Antipolis, CNRS, I3S, Inria, Sophia Antipolis, France
first.last@polytech.unice.fr
‡ University of Rennes I, IRISA, Inria, Rennes, France
first.last@irisa.fr
Abstract—Even if they exhibit differences, many Domain- multithreaded programs from taking advantage of multiproces-
Specific Modeling Languages (DSMLs) share elements from sor systems; while Jython, the Java implementation of Python
their concepts, notations and semantics. StateCharts is a well- supports parallelism through the Java Virtual Machine (JVM).
known family of DSMLs that share many concepts but exhibit
notational differences and many execution semantics variants Another example is fUML [2], whose specification delegates
(called Semantic Variation Points – SVPs –). For instance, when the notions of time, communications and concurrency to the
two conflicting transitions in a state machine are enabled by the tool implementors. Tool vendors are thus responsible for
same event occurrence, which transition is fired depends on the specifying and documenting the implemented solution.
language variant (Harel original StateCharts, UML, Rhapsody, SVPs are usually identified informally in the DSML syntax
etc.) supported by the execution tool. Tools usually provide
only one implementation of SVPs. It complicates communication and semantics specification documents. In the context of this
both between tools and end-users, and hinders the co-existence paper, we will draw the difference between a Language (the
of multiple variants. More generally, Language Workbenches specification of a syntax and of a semantics that may contain
dedicated to the specification and implementation of eXecutable SVPs) and its Dialects (which implement a language, making
Domain-Specific Modeling Languages (xDSMLs) often do not choices about some – possibly all – SVPs of the language).
offer the tools and facilities to manage these SVPs, making it
a time-consuming and troublesome activity. In this paper, we Tools commonly only provide one dialect, thus constraining
describe a modularized approach to the operational execution the end-user to work with the selected specific implementation
semantics of xDSMLs and show how it allows us to manage of SVPs, which may not be the best-suited for their needs.
SVPs. We illustrate this proposal on StateCharts. Besides, it also complicates the cooperation between tools,
since they may implement SVPs differently, giving a different
I. I NTRODUCTION
semantics to the same syntax. Two engineers with different
Domain-Specific Modeling Languages (DSMLs) provide backgrounds may also assume different meanings for the same
user-friendly abstractions for domain experts who are not nec- model, which impairs communication. Finally, large projects
essarily well-versed in the use of programming languages even may need to use several dialects cooperatively, which means
when limited to domain-specific libraries (i.e., API dedicated that this issue cannot be simply reduced to the choice of a
to a domain like security, fault tolerance, etc.). A DSML is unique tool: one dialect with an associated tool may be the
called executable (xDSML) when it represents systems which best fit for a particular aspect of a system, but other ones may
evolve during time (i.e., it captures the behavior(s) of the be better-suited for other aspects of the system.
systems). Being domain-specific eases the design of complex This paper describes an approach to the specification of the
software-intensive systems whereas being executable enables execution semantics of an xDSML that eases the specification
early verification and validation of the systems [1]. and management of SVPs. The approach is implemented in the
Semantic Variation Points (SVPs) are language specifica- GEMOC Studio1 . It is illustrated with Finite State Machines
tion parts left intentionally under-specified to allow further (FSMs), a common formalism to represent complex system
language adaptation to specific uses. SVPs must be dealt with behaviors. StateCharts [3] is a common xDSML to model
either through further refinement of the language specification FSMs that exhibits many SVPs, as shown by a comparative
(in the case of UML, through stereotypes or profiles) or by study of its most popular versions [4].
making arbitrary choices in the implementation. The latter Modern systems (IoT, etc.) increasingly rely on concur-
is most often the case when accommodating specific types rency, and modern platforms provide more and more concrete
of execution platform (e.g., distributed, highly-parallel, etc.), concurrency facilities (many-core, GPU, etc.). xDSMLs must
allowing various implementations of the concurrency concerns provide sophisticated concurrency concepts with well-defined
(e.g., parallelism or thread interleaving). For instance, the con- semantics, to enable early concurrency-aware analyses, and
currency in CPython, the reference implementation of Python,
is subject to the Global Interpreter Lock (GIL), which prevents 1 http://www.gemoc.org
21
SVPs related to the concurrency concerns to allow refine- C. Semantic Variation Points
ments to specific platforms. But the concurrency concerns
We consider the three following SVPs:
and SVPs of xDSMLs are usually implicit, embedded in the
underlying execution environment or in the meta-languages • Simultaneous Events: Can different Events occur at the
used to define the xDSMLs. The GEMOC executable meta- same time? In the original formalism, they can, and they
modeling approach makes explicit the concurrency aspects are dealt with simultaneously (concurrently). The UML
in an xDSML specification, relying on event structures [5] formalism adheres to the concept of run-to-completion
which define a partial ordering over a set of events. This (RTC) which means that Event occurrences are handled
paper advocates that this paradigm is not only suitable for one by one (possibly with priorities), thus simultaneous
specifying the concurrency concerns, but also for defining Events are not allowed.
many of the concurrency-related SVPs by leaving some parts • Order of execution of Actions: When a Transition is fired,
of the semantics under-constrained. Then, implementing these how are the Actions that compose its Effect executed? In
SVPs consist in reducing the partial ordering of the event parallel in the original formalism and in sequence in the
structure with additional constraints. UML version.
This paper is structured as follows: Section II summarizes • Priorities of conflicting Transitions: When several Tran-
the StateCharts example. Section III describes the GEMOC sitions are enabled by the same Event occurrence, how
executable modeling approach and illustrates how it is partic- are they handled if their executions conflict (e.g. their
ularly suitable for the specification of SVPs. The implementa- application would lead to an inconsistent model state) ? In
tion in the GEMOC Studio is described in Section IV. Finally, the original formalism, priority is given to the Transition
Section V gives related work and Section VI concludes and which is highest in the hierarchy, while in UML, priority
proposes insights on future works. is given to the Transition which is lowest in the hierarchy.
Let us consider the example model from Figure 1, repre-
II. S EMANTIC VARIATION P OINTS OF S TATE C HARTS
senting a simple music player.
The StateCharts formalism is an extension of Finite State
Machines (FSMs) with hierarchy, concurrency and broadcast
communications [3]. A comparative study by M. Crane and
J. Dingel [4] identifies and compares some of the existing
StateCharts dialects. For the purpose of this paper, we will
consider the original Harel Statecharts (denominated as Origi-
nal) [6] and the UML StateCharts [7]. The study also classifies
the differences between these dialects into three categories:
notation (the least critical, a notation translation can ensure
compatibility); well-formedness (when a formalism has an
exclusive construct, model refactoring can most of the time
make it compatible with the other formalisms); and semantics
(the most critical one). For the purpose of this paper, we only
consider the semantic differences between the dialects, and
assume that notation and well-formedness issues have been
solved beforehand.
A. Common Syntax of Statecharts Fig. 1. Example model of Statecharts representing a simple music player.
In StateCharts, an FSM is composed of Regions and Events.
The following scenarios illustrate the 3 targeted SVPs:
Each Region is composed of States and Transitions between
these States. A State can be composed of Regions, thus • When in State “Off”, “StartEvent” and “StopEvent” oc-
defining a hierarchy between the States. Each Region has an cur.
initial State. A Transition can have a Guard (predicate expres- – Original: they are dealt with concurrently, resulting
sion) and an Effect (collection of behavior expressions named in the Transition from “Off” to “On” being fired.
Actions). A Transition has a Trigger which is a reference to – UML: not supported.
an Event. • When, in States “On” and “Paused”, the Event
B. Common Semantics of Statecharts “StartEvent” occurs (assuming x and y both start at 0),
The bulk of the semantics is common to all three StateCharts triggering the firing of the Transition from “Paused” to
dialects. When an Event occurs, it enables all the Transitions “Playing”.
whose Trigger references the occurring Event. Depending on – Original: when reaching State “Playing”, the values
their Guard evaluation result, they may then be fired. When of x and y are respectively 1 and 0.
a Transition is fired, its source State is exited, its Effect is – UML: when reaching State “Playing”, the values of
executed and its target State is entered. x and y are respectively 1 and 1.
22
• When, in States “On” and “Playing”, the Event specify how the ED evolve during execution. For instance,
“StopEvent” occurs. a Region has a “currentState” reference in its ED which
– Original: the Transition from “On” to “Off” is fired. represents its current State during the execution. It is updated
– UML: the Transition from “Playing” to “Paused” is by the EF “fire” on Transitions.
fired. The Concurrency Model is captured by the Model of
So far, these differences have to be deduced from the Concurrency and Communication (MoCC). The MoCC is an
documentation of the respective tools or specifications, or EventType structure, specifying at the language level how, for
through tests of the tools. It is not explicit, when considering a given model, the event structure [5] defining its concurrent
the model, what the associated version of the semantics is. control flow is built from a partial ordering over events (events
of the event structure, not to be confused with StateCharts
III. C ONTRIBUTION AND APPLICATION TO S TATE C HARTS Events). This event structure represents all the possible execu-
This section describes the GEMOC executable metamod- tion paths of the model (including all possible interleavings of
eling approach and how we propose to deal with SVPs. We events occurring concurrently). Figure 3 shows the simplified
illustrate it on StateCharts. event structure corresponding to the example from Figure 1.
In this representation, a node is a configuration : an unordered
A. GEMOC Executable Metamodeling Approach set of event occurrences that have happened at this point in the
The language and modeling communities specify languages execution. Event structures allow focusing on the concurrency,
with an Abstract Syntax (AS), one or more Concrete Syntaxes synchronization and the, possibly timed, causalities between
(CSs) and mappings from the AS to one or more Semantic actions. The actions themselves are opaque, thus the data
Domains (SDs) [8]. Based on this proposal and work from the manipulation they realize are abstracted away. In other words,
concurrency theory community, previous contributions [9, 10] it allows specifying the pure concurrent control flow of a
have proposed to cross-fertilize both approaches to specify model in order to ease reasoning on it. Note that in the case
Concurrency-aware xDSMLs by making the concurrency con- of StateCharts, the nature of the language (with 3 different
cerns explicit and suitable for analyses like determinism or possible inputs at every steps, depending on which events
deadlock freeness. The mapping between the AS and the SD, occur) makes the Event Structure very large and difficult to
inspired from Structured Operational Semantics (SOS) [11], is represent.
split into two parts: the Semantic Rules, dedicated to sequential
actions (not to be confused with StateCharts Actions) specified
in an operational manner; and a declarative Concurrency
Model that orchestrates the Semantic Rules. A Communication
Protocol defines the relations between the Semantic Rules and
the Concurrency Model. The class diagram from Figure 2 sum-
marizes the architecture of the specification of concurrency-
aware xDSMLs execution semantics in GEMOC.
Fig. 3. Simplified event structure of the MusicPlayer example from Figure 1.
“...” in a configuration represents the preceding configuration. The figure is
limited to two steps of execution for representation purposes: every step offers
three possibilities (not considering steps where none of the events occur),
leading to three different execution paths.
The full semantics is built thanks to the Communication
Protocol which maps some of the EventTypes from the MoCC
to the EFs. This means that, at the model level, when an event
occurs, it triggers the execution of the associated EF on an ele-
Fig. 2. Class Diagram of our approach towards concurrency-aware operational
ment of the model. For instance, if the Communication Proto-
semantics of an xDSML. col specifies that the EventType “et FireTransition” is mapped
to Transition::fire(), then the event “e FireOn2Off”
The Semantic Rules specify the sequential evolutions of the (instance of “et FireTransition” for the Transition from “On”
model state at runtime (not to be confused with StateCharts to “Off”, “On2Off”) triggers the execution of On2Off
States). The Execution Data (ED) represent at the language .fire(). Figure 4 shows the different concerns, at the model
level the runtime state of the model. Execution Functions (EF) level, of our example: the bottom part of the Event Structure
23
(MoCC at the model level), the Execution Functions and dialect by removing the execution paths that do not correspond
the Communication Protocol (both at the model level). The to the expected semantics. Nondeterminisms in the MoCC
(resulting in conflicts in a model event structure) can be seen
as potential SVPs. SVP implementations restrain the number
of outgoing execution paths at a conflict point. In StateCharts
(where a scenario, user, or environment drives the execution),
there will be a lot of nondeterminisms left in the MoCC
even after implementing the SVPs of the various dialects (to
represent the possible inputs, Events being allowed to occur
at every step of the execution). SVP implementations cannot
add new EventTypes in the MoCC, as it would result in new
execution paths that were not initially present in the language’s
Fig. 4. Simplified view of the model-level specifications of our approach MoCC specification.
applied to the example StateCharts model of Figure 1.
For instance, let us consider the SVP concerning simulta-
Communication Protocol allows the MoCC and the Semantic neous Events. The part of the event structure corresponding
Rules to remain independent, enabling modular changes in to this situation is represented in Figure 5. For this particular
either part.
B. Coping with Semantic Variation Points
If several execution paths are allowed at a point in the
event structure, it means that there is either Concurrency or
Conflict. The first one means that other events are happening
concurrently (interleaved or in parallel), in which case the
execution paths will eventually merge. It does not mean that
the executed model reaches the same state, but instead that in
terms of pure control flow (independent of any data from the
model) it is at the same point in the execution. Our example Fig. 5. Simplified event structure showing the Semantic Variation Point of
model is sequential, so there is no need for parallelism or simultaneous Event occurrences.
interleavings. The second one means that there is a disjunction SVP, the UML dialect implements a subset of the original
among the possible execution paths, which ultimately results formalism’s possibilities. Individual Events “e StartEvent” and
in different final configurations of the event structure. Conflicts “e StopEvent” are possible in both situations, but having
are a sign of nondeterminism in the semantics of the language, both “e StartEvent” and “e StopEvent” is only allowed in
which means that either the language is indeterministic by the original formalism. The part of the MoCC responsible for
intention, or that there is a SVP pertaining to the concurrency implementing this SVP in UML is an extension of the part of
concern of the language. In the case of StateCharts, depending the MoCC for the original formalism, with the addition of a
on the Events occurring, the execution will go one way or constraint preventing simultaneous Event occurrences.
another, therefore there are many conflicts to represent the The SVP concerning conflicting Transition is different: there
possible inputs (Events occurring). is a disjunction between the original formalism and the UML
SVPs can occur in any parts of the execution semantics. one. Figure 6 shows an example event structure of a situation
The ones in Semantic Rules target the model runtime state where, in the State “On” and “Playing”, the Event “StopEvent”
representation and/or evolution. For instance, changing a List (or both “StartEvent” and “StopEvent”) occur. In this case, the
into a Stack to have a LIFO policy instead of FIFO, or incre-
menting a value twice instead of once to double a ressource
consumption. In StateCharts, a Transition Effect is a collection
of Actions executed in parallel (in the original formalism)
or in sequence (in UML). This SVP can be implemented
in the EF that executes the Effect of the Transition being
fired, with a parallel or sequential implementation. Another
solution consists in providing both versions of the EF, but in
changing the Communication Protocol to use the sequential
one or the parallel one depending on the dialect we wish to
use. The imperative nature of these implementations makes
them complex to manage.
Fig. 6. Simplified event structure showing the Semantic Variation Point of
Thus, we propose to rely on the language’s declarative conflicting Transitions.
MoCC to represent the superset of possibilities for all allowed
concurrency-related SVPs, and to refine the MoCC for each original formalism gives priority to “On2Off”, while UML
24
gives priority to “Playing2Paused”. Therefore, the MoCC of MoCC. The definition of the EventType structure relies on
the language representing the superset of possibilities for the Event Constraint Language (ECL) [18], an extension of
all allowed variants must allow both solutions. Each dialect OCL which allows the definition of EventTypes for concepts
then extends the MoCC of the language to add constraints from the AS. It can also use constraints defined in MoCCML
resulting in the removal of some of the execution paths not to specify how the event structure at the model level is
corresponding to the implemented semantics. built. Listing 2 shows an excerpt from the MoCC of the
The difference between specializing a language for a spe- fUML dialect of StateCharts. EventTypes are declared in the
cific environment and implementing a Semantic Variation context of concepts from the AS, and the exclusion constraint
Point is blurry. SVPs sometimes represent adaptation points for implements the simultaneous events SVP for fUML. This
a specific platform (distributed, highly parallel, . . . ). Therefore relation ensures that events cannot occur simultaneously.
the event structure used to define the concurrency concerns in
the semantics of xDSMLs is also a good fit for defining a
language while still allowing dialects to be implemented by Listing 2
extending the concurrency model. SVPs can also be imple- E XCERPT FROM THE M O CC OF THE UML DIALECT OF S TATE C HARTS
SPECIFIED USING ECL. T HE ADDITIONAL CONSTRAINT
mented in a modular way so that dialects are then realized by “ NO S IMULTANEOUS E VENTS ” IMPLEMENTS THE SIMULTANEOUS EVENTS
merging specific SVP implementations; similar to creating a SVP.
new class in Aspect-Oriented Programming by extending an 1 import ’platform:/resource/org.gemoc.sample.
existing class and weaving existing aspects onto it. statecharts.model/model/statecharts.ecore’
2
IV. I MPLEMENTATION 3 -- Defining the EventTypes in their context
4 context StateMachine
The GEMOC executable metamodeling approach is imple- 5 def: mocc_initialize : Event = self
mented in a language workbench, the GEMOC Studio2 based 6
7 context Transition
on previous work [10]. It is integrated in the Eclipse Modeling 8 def: mocc_fire : Event = self
Framework (EMF) [12] to benefit from its large ecosystem. 9
The AS is specified with Ecore, the Eclipse Modeling 10 context StatechartEvent
11 def: mocc_occur : Event = self
Framework implementation of EMOF, and with the Object 12
Constraint Language (OCL) for the static semantics. Both 13 -- Constraint for UML
EMOF [13] and OCL [14] are standards from the Object 14 context StateMachine
15 inv noSimultaneousEvents:
Management Group (OMG). 16 Relation Exclusion(self.events.mocc_occur)
The EFs are implemented with the Kermeta 3 Action
Language (K3AL) [15], built on top of xTend [16]. K3AL
allows the definition of aspects for Ecore metaclasses, allowing
us to weave the additional classes, attributes, references and The MoCC is compiled to a Clock Constraint Specifi-
operation implementations specifying the ED and the EFs. cation Language (CCSL) [19] model interpreted by the
K3AL, just like xTend, compiles into Java Bytecode and TimeSquare [20] tool. Practically, computing the whole Event
provides an executor based on the Java Reflection API to Structure is not doable because if the model is very large or
dynamically execute the EFs. Listing 1 shows the implemen- highly parallel, then the exponential number of configurations
tation of the StateMachine.initialize() Execution (possibly infinite) makes it too costly to compute or too big
Function in K3AL. to be usable. Instead, TimeSquare provides only the next set
Listing 1
of possible configurations of the Event Structure. Due to its
I MPLEMENTATION OF THE E XECUTION F UNCTION ” INITIALIZE ” OF constraint-based approach, the runtime of CCSL provided by
S TATE M ACHINE IN K ERMETA 3. TimeSquare is called a Solver.
1 @Aspect(className=StateMachine) The Communication Protocol is specified using the Gemoc
2 class StateMachineAspect { Events Language (GEL) [21]. Listing 3 shows an excerpt of
3 // Initializes each Region with its initial state
4 def public void initialize() { the Communication Protocol of StateCharts. Mappings are
5 self.regions.forEach [ region | implemented by what we call Domain-Specific Events (DSEs)
6 region.currentState = region.initialState which link an EventType (specified in ECL, see Listing 2), to
7 ]
8 } an Execution Function).
9 }
At runtime, an Execution Engine written mostly in Java
coordinates the K3AL interpreter, the GEL interpreter and
MoCCML [17], a declarative meta-language designed to the CCSL solver to execute a model. Figure 7 shows the
express constraints between events, is used to specify the sequence diagram for an execution step. First, the Execu-
tion Engine retrieves from the CCSL Solver the next set
2 http://gemoc.org/studio/ of possible configurations (scheduling solutions). Its heuristic
25
To implement our second SVP, “Communication Protocol for
Listing 3
E XCERPT FROM THE C OMMUNICATION P ROTOCOL OF S TATE C HARTS UML” maps “Transition.executeEffectSequentially()” while
SPECIFIED USING GEL. for original StateCharts, “Transition.executeEffectInParallel()”
1 DSE InitializeStateMachine: is mapped. In “UML StateCharts MoCC”, a constraint is added
2 upon mocc_initialize to exclude simultaneous occurrences of Events (as shown in
3 triggers StateMachine.initialize
4 end Listing 2). Priority is given to the inner Transition in case
5 of conflicting Transitions (third SVP) while the “Original
6 DSE FireTransition: StateCharts MoCC” gives priority to the outer Transition.
7 upon mocc_fire
8 triggers Transition.fire
9 end
V. R ELATED W ORK
DMSL editors, also called Language Workbenches [22],
such as Metacase’s MetaEdit+ [23] or JetBrain’s MPS [24]
usually do not provide explicit means to handle the SVPs
of the DSMLs. Existing executable metamodeling approaches
such as xMOF [25] or Kermeta [26] usually only provide se-
mantic variability through operations redefinitions and strategy
design pattern uses. SVPs are a recurrent issue for executable
metamodeling, in particular for executable UML. In [27],
the authors draw inspiration from the notion of Genericity
available in object-oriented GPLs such as Java or C++ to
introduce a notion of template parameters at the metamodel
level which can be bound either at the model level or at the
metamodel level. This approach is exclusively at a structural
Fig. 7. Sequence Diagram representing one step of execution of a model level, with the assumption that behaviors are encapsulated in
conforming to a Concurrency-aware xDSML. operations and triggered by operation calls. In our approach,
we only consider the behavioral aspects and how the SVPs
are implemented, assuming that the structural issues have been
then selects one solution among the possible ones. A default resolved beforehand. In [28] is introduced the notion of inner
implementation consists in letting the user do the selection to semantics of a language (semantics where the SVPs are left
manage indeterministic situations manually when developing open) which corresponds, for us, to using the common MoCC
an xDSML. Based on the Communication Protocol, the set of of the language without extending it with SVP implemen-
EFs to execute is deduced from the selected solution. All the tations. Our approach is closer to what was done for the
EFs are executed in parallel, resulting in an updated runtime SVPs of UML State Machines in [29], where the SVPs are
state of the model. reified in their own models to avoid tying the semantic choices
Figure 8 gives the architecture of our implementation of to the implementing tool. The UML model to be executed
StateCharts. is then transformed into a target UML model reflecting the
semantic variations selected. In our approach, the SVPs are
always specified in their own models at the language level
since our Execution Engine is generic and able to execute
any model conforming to a language described using our
language workbench. Our approach also bears resemblance
to [30], in which the authors have developed a framework
to analyze the different variants of StateCharts thanks to
pluggable semantics implemented in Java which parameterize
their execution engine. In our case, the different semantic
variants are models belonging to the language definition which
are interpreted (after compilation for a specific model) by the
generic execution engine making our approach generic and not
tied to a family of languages.
Fig. 8. Architecture of the different specifications constituting the
concurrency-aware operational semantics of the different versions of State-
VI. C ONCLUSION AND P ERSPECTIVES
Charts. Semantic Variation Points (SVPs) are usually poorly identi-
The modularization of our approach effectively allows the fied in language specifications, and their implementations are
reuse of part of the operational semantics (in our case, of often hardcoded into the implementing tools, hindering the
the ED and EFs and of parts of the Communication Protocol end-users from choosing their own variation of the language,
and of the MoCC) for the various dialects of StateCharts. particularly one that may be a better fit for a particular
26
class of problems. The GEMOC executable metamodeling eling and Models of Computation,” in SLE2012, ser. LNCS.
approach separates the semantic mapping of xDSMLs to make Springer, Sep. 2012.
explicit the Concurrency Model, completed by Semantic Rules [10] B. Combemale, J. De Antoni, M. Vara Larsen, F. Mallet,
O. Barais, B. Baudry, and R. France, “Reifying Concurrency for
describing how the runtime state of the model evolves, and Executable Metamodeling,” in SLE 2013, ser. LNCS. Springer-
by a Communication Protocol to connect both. Its event Verlag.
structure-based approach to the concurrency model eases the [11] G. D. Plotkin, “The origins of structural operational semantics,”
specification of nondeterministic situations, corresponding to The Journal of Logic and Algebraic Programming, vol. 60, pp.
potential SVPs. Implementing a SVP is then done by extending 3–15, 2004.
the concurrency model with additional constraints, resolving [12] Eclipse Foundation, “EMF homepage,” 2015. [Online].
partially or totally nondeterminisms that were left in the Available: http://www.eclipse.org/modeling/emf/
[13] OMG, “MOF specification v2.5,” 2015. [Online]. Available:
language’s Concurrency Model. The SVP implementations http://www.omg.org/spec/MOF/
are thus weaved into the language definition, allowing the [14] ——, “OCL specification v2.4,” 2014. [Online]. Available:
execution tool to remain independent from any arbitrary choice http://www.omg.org/spec/OCL/
with regards to the SVPs. Future work will be concerned [15] DIVERSE-team, “Github for K3AL,” 2015. [Online]. Available:
with adding the possibility to hinder parts of the concurrency http://github.com/diverse-project/k3/
[16] L. Bettini, Implementing Domain-Specific Languages with Xtext
model of the language from being extended by dialects. So and Xtend. Packt Publishing Ltd, 2013.
far in our approach, every point of nondeterminism left in [17] J. De Antoni, P. Issa Diallo, C. Teodorov, J. Champeau, and
the concurrency model is considered as a potential SVP. But B. Combemale, “Towards a Meta-Language for the Concurrency
sometimes, the nondeterminisms left in the concurrency model Concern in DSLs,” in DATE’15, Mar. 2015.
are integrally part of the semantics of all variants allowed [18] J. De Antoni and F. Mallet, “ECL: the event constraint language,
an extension of OCL with events,” Inria, Tech. Rep., 2012.
and should not be extended and resolved by dialects. We also [19] F. Mallet, “Clock constraint specification language: specifying
plan to consider the case of SVPs which spread through the clock constraints with uml/marte,” Innovations in Systems and
three units constituting the semantics (Concurrency Model, Software Engineering, vol. 4, no. 3, pp. 309–314, 2008.
Semantic Rules or Communication Protocol) because so far, [20] J. De Antoni and F. Mallet, “Timesquare: Treat your models
we have only considered SVPs which are contained in only with logical time,” in Objects, Models, Components, Patterns.
Springer, 2012.
one of these units. At last, we target the integration of these [21] F. Latombe, X. Cregut, B. Combemale, J. Deantoni, and
proposals with SVPs at the syntax level, both abstract and M. Pantel, “Weaving Concurrency in eXecutable Domain-
concrete; and to experiment the use of variability management Specific Modeling Languages,” in SLE 2015. ACM, Oct.
techniques to make the management of language variants more 2015. [Online]. Available: https://hal.inria.fr/hal-01185911
explicit. [22] M. Fowler, “Language workbenches: The killer-app for
domain specific languages,” 2005. [Online]. Available: http:
ACKNOWLEDGMENT //martinfowler.com/articles/languageWorkbench.html
[23] J.-P. Tolvanen and S. Kelly, “MetaEdit+: defining and using
This work is partially supported by the ANR INS Project
integrated domain-specific modeling languages,” in OOPSLA,
GEMOC (ANR-12-INSE-0011). 2009.
[24] M. Voelter and V. Pech, “Language modularity with the MPS
R EFERENCES language workbench,” in ICSE. IEEE, 2012.
[1] T. Kosar, N. Oliveira, M. Mernik, V. J. M. Pereira, [25] T. Mayerhofer, P. Langer, M. Wimmer, and G. Kappel, “xMOF:
M. Črepinšek, C. D. Da, and R. P. Henriques, “Comparing Executable DSMLs based on fUML,” in Software Language
general-purpose and domain-specific languages: An empirical Engineering. Springer, 2013, pp. 56–75.
study,” ComSIS, 2010. [26] J.-M. Jézéquel, O. Barais, and F. Fleurey, “Model driven lan-
[2] OMG, “fUML specification v1.1,” 2013. guage engineering with kermeta,” in Generative and Transfor-
[3] D. Harel, “Statecharts: A visual formalism for complex sys- mational Techniques in Software Engineering III. Springer,
tems,” Science of computer programming, 1987. 2011, pp. 201–221.
[4] M. L. Crane and J. Dingel, “UML vs. Classical vs. Rhapsody [27] A. Cuccuru, C. Mraidha, F. Terrier, and S. Gérard, “Templatable
statecharts: not all models are created equal,” SoSyM, 2007. metamodels for semantic variation points,” in Model Driven
[5] G. Winskel, Event structures. Springer, 1987. Architecture-Foundations and Applications. Springer, 2007.
[6] D. Harel and A. Naamad, “The STATEMATE semantics of [28] H. Grönniger and B. Rumpe, “Modeling language variability,”
statecharts,” TOSEM, vol. 5, no. 4, pp. 293–333, 1996. in Foundations of Computer Software. Modeling, Development,
[7] OMG, “UML superstructure specification v2.4.1,” 2011. and Verification of Adaptive Systems. Springer, 2011.
[Online]. Available: http://www.omg.org/spec/UML/2.4.1/ [29] F. Chauvel and J.-M. Jézéquel, “Code generation from UML
Superstructure/PDF/ models with semantic variation points,” in Model Driven Engi-
[8] D. Harel and B. Rumpe, “Meaningful modeling: what’s the neering Languages and Systems. Springer, 2005, pp. 54–68.
semantics of ”semantics”?” Computer, 2004. [30] D. Balasubramanian, C. S. Păsăreanu, M. W. Whalen, G. Karsai,
[9] B. Combemale, C. Hardebolle, C. Jacquet, F. Boulanger, and and M. Lowry, “Polyglot: modeling and analysis for multiple
B. Baudry, “Bridging the Chasm between Executable Metamod- statechart formalisms,” in ISSTA. ACM, 2011.
27