-Within the model-driven engineering field, the concept of “i-DSML” (interpreted Domain Specific Modeling Language) refers to executable models which are interpreted through an engine. While several works discussed the key ingredients of an i-DSML, few of them answered the original question: What is the class of models that are executable by nature and those that are not? This paper attempts to provide some answers by proposing two discriminating criteria: The possibility of defining execution steps and the reification of the behavior of the running system into the executed model. On this basis, we reconsider some well-known DSML and notice a paradoxical situation with UML diagrams.
The Model-Driven Engineering (MDE) aims to bring
models as productive artifacts for the software development.
Having productive models means that they are directly the base
for obtaining the final software system, for instance through
the ability to generate code from them. The ultimate challenge
within productive models field is to skip the implementation
stage and that the models at design-time are fully reifying
the whole system at run-time. This can be achieved through
model execution. Recent initiatives at the OMG such as fUML1
or ALF2 enable to add an executable behavior for instance
on UML3 class diagrams that are basically static structures.
In a more general way, the MDE enables to define its
veryown modeling language dedicated to a specific purpose within
the concept of DSML (Domain Specific Modeling Language).
Therefore one can also define DSML for executable models.
Such DSML are called i-DSML [
Model execution has been widely studied and a consensus has been established on the constituent elements of an i-DSML and so, on how carrying out model execution. This answers the question: “How to build an i-DSML?”. In this paper, we try to answer a symmetrical question that is: “If we are facing a model, can we determine if this is an executable model, or worded other way, if the DSML used is actually an i-DSML?”. We are then looking for characteristics of the executable nature of a model.
In the next section, we recall the constitutive elements of an i-DSML. In section III, we give two criteria allowing to 1Semantics of a Foundational Subset for Executable UML Models (http: //www.omg.org/spec/FUML/)
2Concrete Syntax for a UML Action Language: Action Language for Foundational UML (http://www.omg.org/spec/ALF/) 3Unified Modeling Language (http://www.omg.org/spec/UML/) determine if a model is executable. These criteria are then applied on well-known DSML from the OMG.
II.
Model execution has been studied by several works,
especially [
It is worthwhile mentioning that the aforesaid characterization assumes that the current state of a model under execution is stored in the model itself. This is not always the case, since knowledge about the current state can also be internally managed by the engine. As an example, PauWare4 is an execution engine for UML state machines, written in Java. Nevertheless, the genuine UML specification did not planned to store in a state machine diagram what are the current active state(s). Consequently, the PauWare engine is responsible for this. To our opinion, storing the execution state inside the model rather than inside the engine has the advantage that it provides a self-contained execution trace. Thanks to that, it is possible to perform failure recovery or to apply verification techniques onto the trace.
As a side note, we identified a paradoxical situation about UML. Indeed, the genuine UML specification does not focus enough on the execution of the different types of diagrams it defined, and especially about the behavioral ones that yet are executable a priori. Reconsidering the state machine diagram, the UML specification defines a kind of a dynamic part and
Executable Model conforms to i-DSML <<structure>> Static Part <<structure>> Dynamic Part <<behavior>> Execution Semantics applies on takes input
defined for
Execution Engine
<<implements>>
an execution semantics but only in an informal manner, in
natural language. The dynamic elements are missing from
the UML metamodel (in [
The aforesaid characterization of model execution does not allow knowing explicitly what are models that can be executed, and those who cannot. This is rather a matter of intuition from the software engineer, sometimes giving rise to debate or controversy. In order to draw a clearer demarcation line, let us describe two criteria that seems enough to characterize the executable nature of a model:
The behavior of the software system is located into the model; It is always possible to determine the execution next step and an initial state.
These two simple criteria tell us if execution semantics can be defined for a given DSML and hence if an engine can be implemented thereafter. In other words, they tell us if a DSML is an i-DSML.
Let us assume some kind of software system which uses a model during its execution (at runtime). The question is how to know the role of this model against the overall behavior of the running system. We recall that a system performs “business actions”. For example, an elevator system opens and closes doors, winds/unwinds the cable to reach a given 5http://doc.omg.org/formal/2000-03-01.pdf, section 3-20, page 278 floor. As another example, a travel booking system inserts customers data into database or call Web services provided by air transport companies. The behavior of a system determinates when these business routines have to be executed and under what conditions.
In this context, the question is whether the decisions to
carry out these actions are impelled by the model itself or
if they come from elsewhere, in which case the model is
considered as mere input data helping to take the decisions.
Reconsidering the examples above, the actions of the elevator
may be triggered according to a set of states and transitions
modeled through a finite state machine. Similarly, the calls
to the various Web services may be orchestrated through a
BPEL6 or BPMN7 model. In both cases, the behavior of the
system is fully defined by the model. Conversely, in the spirit
of models@run.time [
As discussed in Section II, model execution consists in carrying out execution steps; each step making the model evolving from an active state to another one. The model must then intrinsically enable to pinpoint different execution states. However, being able to define the current state of the model is necessary, but not sufficient. Indeed, we highlighted that the object diagram can be seen as the current state of a class diagram although the class diagram is absolutely not executable. Unless it is associated and complemented with behavioral diagrams (sequence, state machines, . . . ) or fUML specifications, taken in isolation, a class diagram does not enable to determine how making evolving a related object diagram.
Consequently, the second criterion of the executable nature of models is to be able to carrying out execution steps. This 6Web Services Business Process Execution Language (https://www. oasis-open.org/committees/download.php/23964/wsbpel-v2.0-primer.htm) 7Business Process Model and Notation (http://www.omg.org/spec/BPMN/) feature can be found for example within activity diagrams, finite state machines or Petri nets. In all these types of models, modeling elements exist in that purpose, typically transitions that can be followed between states, activities or places. In some other cases, the “computing” of the next state can be made without dedicated modeling elements. For instance, for SBVR models8, it is the execution engine that browses the entire rules set to determine the ones to trigger, as for any declarative language.
There is a step which stands out from others: The one that starts the model execution by placing it in its initial state. The model must then define a starting point. Making an analogy with programming languages, it can be seen as the equivalent of a main() operation defining what to do when the program is just launched. For finite state machines, activities diagram or Petri nets, the starting point is defined explicitly as special modeling elements exist for this purpose. Having an ending point is optional as some executions are not expected to end.
Having the capability to make the model evolving from a given running state to another one is a fundamental feature because, without it, it will be impossible to specify an execution semantics. Indeed, the goal of an execution engine is to carrying out the model evolution accordingly to an execution semantics.
Modeling language bSeyhstaevmior sCtautrerent sEtxepecsution BPMN Yes External Explicit Yes UML use case Yes Internal None No UML class diagram No Internal None No UML component diagram No Internal None No UML state machines Yes External Explicit Yes SBVR Yes External Implicit Yes UML sequence diagram Yes External Explicit Yes Table I. EXECUTABLE NATURE OF SOME DSML FROM THE OMG Executable?
Table I applies our criteria on some well-known DSML of the OMG, based on their OMG specifications1;7;8. For sake of simplicity, we consider each UML diagram as a DSML. A model is considered as executable if it reifies the behavior of the system and if execution steps can be defined. The current state of a model can either be defined as a full-fledged part of the model or in an external way.
Unsurprisingly, models defining structural software artifacts such as component or class diagrams are not executable. None of them enables to have execution steps. All UML diagrams classified as behavioral diagrams (state machines, sequence diagram, etc.) are unquestionably executable. However the OMG has never planned to add to them their dynamic part. For these models, the management of the current model state will be left to the responsibility of the execution engine. The specification of BPMN models suffers from the same limitation.
Paradoxically, some non-executable models such as class diagrams or use case diagrams have a dynamic part defined by their meta-model. Indeed, as seen before, for class diagrams, the object diagram plays the role of its dynamic part. For use 8Semantics of Business Vocabulary and Business Rules (http://www.omg. org/spec/SBVR/) cases, curiously, the UML meta-model defines the concept of use case instance that could be used as a dynamic part. However there is no way to determine how to execute a use case as the notion of execution step is totally missing in use cases. It is not possible to know which use case or in which order use cases must be executed. Moreover, the description of a use case is informal, written in natural language, and does not permit to execute a case on its own.
SVBR models are executable without internal dynamic part and have the particularity to define implicit execution steps. This is due to the declarative nature of this modeling language.
In this paper, we first recalled what is an i-DSML from a technical point of view: An i-DSML defines a dynamic part within the meta-model, an execution semantics is specified and is implemented by an execution engine. Then, we studied, in a more “philosophical” way, the executable nature of models. We have identified two criteria allowing determining if a model is executable and consequently if the DSML it is conforming to, is actually an i-DSML: 1) the fact that the behavior of the running system can be reified in the model and 2) that the DSML enables to define execution steps during the model execution. These two features make possible to define an execution semantics and execution engines for this i-DSML. Finally, we applied these criteria of some known DSML of the OMG and showed a completely backward situation: All the executable models may not have their DSML defining a dynamic part while some non-executable models do have a possible dynamic part.
This characterization of the executable nature of a model is presumably not comprehensive but we guess that these two criteria are the most important to take into account. We will study more deeply several other i-DSML to make new criteria emerge.