Domain-Specific Modeling Languages (DSMLs) provide user-friendly abstractions for domain experts who are not necessarily well-versed in the use of programming languages even when limited to domain-specific libraries (i.e., API dedicated to a domain like security, fault tolerance, etc.). A DSML is called executable (xDSML) when it represents systems which evolve during time (i.e., it captures the behavior(s) of the systems). Being domain-specific eases the design of complex software-intensive systems whereas being executable enables early verification and validation of the systems [1].
Semantic Variation Points (SVPs) are language specification parts left intentionally under-specified to allow further language adaptation to specific uses. SVPs must be dealt with either through further refinement of the language specification (in the case of UML, through stereotypes or profiles) or by making arbitrary choices in the implementation. The latter is most often the case when accommodating specific types of execution platform (e.g., distributed, highly-parallel, etc.), allowing various implementations of the concurrency concerns (e.g., parallelism or thread interleaving). For instance, the concurrency in CPython, the reference implementation of Python, is subject to the Global Interpreter Lock (GIL), which prevents multithreaded programs from taking advantage of multiprocessor systems; while Jython, the Java implementation of Python supports parallelism through the Java Virtual Machine (JVM). Another example is fUML [2], whose specification delegates the notions of time, communications and concurrency to the tool implementors. Tool vendors are thus responsible for specifying and documenting the implemented solution.
SVPs are usually identified informally in the DSML syntax and semantics specification documents. In the context of this paper, we will draw the difference between a Language (the specification of a syntax and of a semantics that may contain SVPs) and its Dialects (which implement a language, making choices about some -possibly all -SVPs of the language). Tools commonly only provide one dialect, thus constraining the end-user to work with the selected specific implementation of SVPs, which may not be the best-suited for their needs. Besides, it also complicates the cooperation between tools, since they may implement SVPs differently, giving a different semantics to the same syntax. Two engineers with different backgrounds may also assume different meanings for the same model, which impairs communication. Finally, large projects may need to use several dialects cooperatively, which means that this issue cannot be simply reduced to the choice of a unique tool: one dialect with an associated tool may be the best fit for a particular aspect of a system, but other ones may be better-suited for other aspects of the system.
This paper describes an approach to the specification of the execution semantics of an xDSML that eases the specification and management of SVPs. The approach is implemented in the GEMOC Studio1 . It is illustrated with Finite State Machines (FSMs), a common formalism to represent complex system behaviors. StateCharts [3] is a common xDSML to model FSMs that exhibits many SVPs, as shown by a comparative study of its most popular versions [4].
Modern systems (IoT, etc.) increasingly rely on concurrency, and modern platforms provide more and more concrete concurrency facilities (many-core, GPU, etc.). xDSMLs must provide sophisticated concurrency concepts with well-defined semantics, to enable early concurrency-aware analyses, and SVPs related to the concurrency concerns to allow refinements to specific platforms. But the concurrency concerns and SVPs of xDSMLs are usually implicit, embedded in the underlying execution environment or in the meta-languages used to define the xDSMLs. The GEMOC executable metamodeling approach makes explicit the concurrency aspects in an xDSML specification, relying on event structures [5] which define a partial ordering over a set of events. This paper advocates that this paradigm is not only suitable for specifying the concurrency concerns, but also for defining many of the concurrency-related SVPs by leaving some parts of the semantics under-constrained. Then, implementing these SVPs consist in reducing the partial ordering of the event structure with additional constraints.
This paper is structured as follows: Section II summarizes the StateCharts example. Section III describes the GEMOC executable modeling approach and illustrates how it is particularly suitable for the specification of SVPs. The implementation in the GEMOC Studio is described in Section IV. Finally, Section V gives related work and Section VI concludes and proposes insights on future works.
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 Original) [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.
The bulk of the semantics is common to all three StateCharts dialects. When an Event occurs, it enables all the Transitions whose Trigger references the occurring Event. Depending on their Guard evaluation result, they may then be fired. When a Transition is fired, its source State is exited, its Effect is executed and its target State is entered.
We consider the three following SVPs:
• Simultaneous Events: Can different Events occur at the same time? In the original formalism, they can, and they are dealt with simultaneously (concurrently). The UML formalism adheres to the concept of run-to-completion (RTC) which means that Event occurrences are handled one by one (possibly with priorities), thus simultaneous Events are not allowed. The following scenarios illustrate the 3 targeted SVPs:
• When in State "Off", "StartEvent" and "StopEvent" occur.
-Original: they are dealt with concurrently, resulting in the Transition from "Off" to "On" being fired. -UML: not supported.
• When, in States "On" and "Paused", the Event "StartEvent" occurs (assuming x and y both start at 0), triggering the firing of the Transition from "Paused" to "Playing".
-Original: when reaching State "Playing", the values of x and y are respectively 1 and 0. -UML: when reaching State "Playing", the values of x and y are respectively 1 and 1.
• When, in States "On" and "Playing", the Event "StopEvent" occurs.
-Original: the Transition from "On" to "Off" is fired.
-UML: the Transition from "Playing" to "Paused" is fired. So far, these differences have to be deduced from the documentation of the respective tools or specifications, or through tests of the tools. It is not explicit, when considering the model, what the associated version of the semantics is.
This section describes the GEMOC executable metamodeling approach and how we propose to deal with SVPs. We illustrate it on StateCharts.
The language and modeling communities specify languages with an Abstract Syntax (AS), one or more Concrete Syntaxes (CSs) and mappings from the AS to one or more Semantic Domains (SDs) [8]. Based on this proposal and work from the concurrency theory community, previous contributions [9,10] have proposed to cross-fertilize both approaches to specify Concurrency-aware xDSMLs by making the concurrency concerns explicit and suitable for analyses like determinism or deadlock freeness. The mapping between the AS and the SD, inspired from Structured Operational Semantics (SOS) [11], is 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 summarizes the architecture of the specification of concurrencyaware xDSMLs execution semantics in GEMOC. The Semantic Rules specify the sequential evolutions of the model state at runtime (not to be confused with StateCharts States). The Execution Data (ED) represent at the language level the runtime state of the model. Execution Functions (EF) specify how the ED evolve during execution. For instance, a Region has a "currentState" reference in its ED which represents its current State during the execution. It is updated by the EF "fire" on Transitions.
The Concurrency Model is captured by the Model of Concurrency and Communication (MoCC). The MoCC is an EventType structure, specifying at the language level how, for a given model, the event structure [5] defining its concurrent control flow is built from a partial ordering over events (events of the event structure, not to be confused with StateCharts Events). This event structure represents all the possible execution paths of the model (including all possible interleavings of events occurring concurrently). Figure 3 shows the simplified event structure corresponding to the example from Figure 1. In this representation, a node is a configuration : an unordered set of event occurrences that have happened at this point in the execution. Event structures allow focusing on the concurrency, synchronization and the, possibly timed, causalities between actions. The actions themselves are opaque, thus the data manipulation they realize are abstracted away. In other words, it allows specifying the pure concurrent control flow of a model in order to ease reasoning on it. Note that in the case of StateCharts, the nature of the language (with 3 different possible inputs at every steps, depending on which events occur) makes the Event Structure very large and difficult to represent. 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 element of the model. For instance, if the Communication Protocol specifies that the EventType "et FireTransition" is mapped to Transition::fire(), then the event "e FireOn2Off" (instance of "et FireTransition" for the Transition from "On" to "Off", "On2Off") triggers the execution of On2Off .fire(). Communication Protocol allows the MoCC and the Semantic Rules to remain independent, enabling modular changes in either part.
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 model is sequential, so there is no need for parallelism or interleavings. The second one means that there is a disjunction among the possible execution paths, which ultimately results in different final configurations of the event structure. Conflicts are a sign of nondeterminism in the semantics of the language, which means that either the language is indeterministic by intention, or that there is a SVP pertaining to the concurrency concern of the language. In the case of StateCharts, depending on the Events occurring, the execution will go one way or another, therefore there are many conflicts to represent the possible inputs (Events occurring).
SVPs can occur in any parts of the execution semantics. The ones in Semantic Rules target the model runtime state representation and/or evolution. For instance, changing a List into a Stack to have a LIFO policy instead of FIFO, or incrementing 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.
Thus, we propose to rely on the language's declarative MoCC to represent the superset of possibilities for all allowed concurrency-related SVPs, and to refine the MoCC for each dialect by removing the execution paths that do not correspond 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 MoCC specification.
For instance, let us consider the SVP concerning simultaneous Events. The part of the event structure corresponding to this situation is represented in Figure 5. For this particular 5. event structure showing the Semantic Variation Point of Event occurrences.
SVP, the UML dialect implements a subset of the original formalism's possibilities. Individual Events "e StartEvent" and "e StopEvent" are possible in both situations, but having both "e StartEvent" and "e StopEvent" is only allowed in the original formalism. The part of the MoCC responsible for implementing this SVP in UML is an extension of the part of the MoCC for the original formalism, with the addition of a constraint preventing simultaneous Event occurrences. The SVP concerning conflicting Transition is different: there is a disjunction between the original formalism and the UML one. Figure 6 shows an example event structure of a situation where, in the State "On" and "Playing", the Event "StopEvent" (or both "StartEvent" and "StopEvent") occur. In this case, the original formalism gives priority to "On2Off", while UML gives priority to "Playing2Paused". Therefore, the MoCC of the language representing the superset of possibilities for all allowed variants must allow both solutions. Each dialect then extends the MoCC of the language to add constraints resulting in the removal of some of the execution paths not corresponding to the implemented semantics.
The difference between specializing a language for a specific environment and implementing a Semantic Variation Point is blurry. SVPs sometimes represent adaptation points for a specific platform (distributed, highly parallel, . . . ). Therefore 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 extending the concurrency model. SVPs can also be implemented in a modular way so that dialects are then realized by merging specific SVP implementations; similar to creating a new class in Aspect-Oriented Programming by extending an existing class and weaving existing aspects onto it.
The GEMOC executable metamodeling approach is implemented in a language workbench, the GEMOC Studio2 based on previous work [10]. It is integrated in the Eclipse Modeling Framework (EMF) [12] to benefit from its large ecosystem.
The AS is specified with Ecore, the Eclipse Modeling Framework implementation of EMOF, and with the Object Constraint Language (OCL) for the static semantics. Both EMOF [13] and OCL [14] are standards from the Object Management Group (OMG).
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 operation implementations specifying the ED and the EFs. K3AL, just like xTend, compiles into Java Bytecode and provides an executor based on the Java Reflection API to dynamically execute the EFs. Listing 1 shows the implementation of the StateMachine.initialize() Execution Function in K3AL. MoCCML [17], a declarative meta-language designed to express constraints between events, is used to specify the MoCC. The definition of the EventType structure relies on the Event Constraint Language (ECL) [18], an extension of OCL which allows the definition of EventTypes for concepts from the AS. It can also use constraints defined in MoCCML to specify how the event structure at the model level is built. Listing 2 shows an excerpt from the MoCC of the fUML dialect of StateCharts. EventTypes are declared in the context of concepts from the AS, and the exclusion constraint implements the simultaneous events SVP for fUML. This relation ensures that events cannot occur simultaneously. The MoCC is compiled to a Clock Constraint Specification Language (CCSL) [19] model interpreted by the TimeSquare [20] tool. Practically, computing the whole Event Structure is not doable because if the model is very large or highly parallel, then the exponential number of configurations (possibly infinite) makes it too costly to compute or too big to be usable. Instead, TimeSquare provides only the next set of possible configurations of the Event Structure. Due to its constraint-based approach, the runtime of CCSL provided by TimeSquare is called a Solver. The Communication Protocol is specified using the Gemoc Events Language (GEL) [21]. Listing 3 shows an excerpt of the Communication Protocol of StateCharts. Mappings are implemented by what we call Domain-Specific Events (DSEs) which link an EventType (specified in ECL, see Listing 2), to an Execution Function).
At runtime, an Execution Engine written mostly in Java coordinates the K3AL interpreter, the GEL interpreter and the CCSL solver to execute a model. Figure 7 shows the sequence diagram for an execution step. First, the Execution Engine retrieves from the CCSL Solver the next set of possible configurations (scheduling solutions). Its heuristic The modularization of our approach effectively allows the reuse of part of the operational semantics (in our case, of the ED and EFs and of parts of the Communication Protocol and of the MoCC) for the various dialects of StateCharts.
To implement our second SVP, "Communication Protocol for UML" maps "Transition.executeEffectSequentially()" while for original StateCharts, "Transition.executeEffectInParallel()" is mapped. In "UML StateCharts MoCC", a constraint is added to exclude simultaneous occurrences of Events (as shown in Listing 2). Priority is given to the inner Transition in case of conflicting Transitions (third SVP) while the "Original StateCharts MoCC" gives priority to the outer Transition.
V. RELATED WORK 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 semantic 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 level, with the assumption that behaviors are encapsulated in 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 resolved beforehand. In [28] is introduced the notion of inner semantics of a language (semantics where the SVPs are left open) which corresponds, for us, to using the common MoCC of the language without extending it with SVP implementations. Our approach is closer to what was done for the SVPs of UML State Machines in [29], where the SVPs are reified in their own models to avoid tying the semantic choices to the implementing tool. The UML model to be executed 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.
Semantic Variation Points (SVPs) are usually poorly identified in language specifications, and their implementations are often hardcoded into the implementing tools, hindering the end-users from choosing their own variation of the language, particularly one that may be a better fit for a particular class of problems. The GEMOC executable metamodeling approach separates the semantic mapping of xDSMLs to make explicit the Concurrency Model, completed by Semantic Rules describing how the runtime state of the model evolves, and by a Communication Protocol to connect both. Its event structure-based approach to the concurrency model eases the specification of nondeterministic situations, corresponding to potential SVPs. Implementing a SVP is then done by extending the concurrency model with additional constraints, resolving partially or totally nondeterminisms that were left in the language's Concurrency Model. The SVP implementations are thus weaved into the language definition, allowing the execution tool to remain independent from any arbitrary choice with regards to the SVPs. Future work will be concerned with adding the possibility to hinder parts of the concurrency model of the language from being extended by dialects. So far in our approach, every point of nondeterminism left in the concurrency model is considered as a potential SVP. But sometimes, the nondeterminisms left in the concurrency model are integrally part of the semantics of all variants allowed and should not be extended and resolved by dialects. We also plan to consider the case of SVPs which spread through the three units constituting the semantics (Concurrency Model, Semantic Rules or Communication Protocol) because so far, we have only considered SVPs which are contained in only one of these units. At last, we target the integration of these proposals with SVPs at the syntax level, both abstract and concrete; and to experiment the use of variability management techniques to make the management of language variants more explicit.
ACKNOWLEDGMENT This work is partially supported by the ANR INS Project GEMOC (ANR-12-INSE-0011).