On the Executable Nature of Models (Position Paper) Eric Cariou, Olivier Le Goaer, and Franck Barbier Université de Pau / LIUPPA, PauWare Research Group, BP 1155, 64013 PAU CEDEX, France Email: {firstname.name}@univ-pau.fr Abstract—Within the model-driven engineering field, the con- determine if a model is executable. These criteria are then cept of “i-DSML” (interpreted Domain Specific Modeling Lan- applied on well-known DSML from the OMG. guage) 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 II. C HARACTERIZATION OF MODEL EXECUTION is the class of models that are executable by nature and those Model execution has been studied by several works, espe- that are not? This paper attempts to provide some answers by cially [2], [3], [4], [5], [6], [7]. All these works built a consen- proposing two discriminating criteria: The possibility of defining execution steps and the reification of the behavior of the running sus on the rationale of model execution and how to design an system into the executed model. On this basis, we reconsider some i-DSML. Figure 1 summarizes our characterization from [4]. well-known DSML and notice a paradoxical situation with UML An i-DSML is a specific kind of DSML whose metamodel diagrams. contains two types of elements: Elements called ’static’ which describe the steady structure of a model, and elements called Keywords—MDE, model execution, i-DSML, xDSML ’dynamic’ which indicate the global model state at a given execution step. In the case of a state machine for example, the I. I NTRODUCTION static elements are states and transitions while the dynamic elements are the current active state(s). A precise execution The Model-Driven Engineering (MDE) aims to bring mod- semantics is attached to an i-DSML. It specifies how to make els as productive artifacts for the software development. Hav- evolving the model at runtime, acting only on the dynamic ing productive models means that they are directly the base elements of the model under execution. Reconsidering the for obtaining the final software system, for instance through state machine example, it specifies how the transitions have the ability to generate code from them. The ultimate challenge to be fired according to both the current active state(s) and an within productive models field is to skip the implementation incoming event, leading to modify the current active state(s). stage and that the models at design-time are fully reifying This execution semantics is implemented through an execution the whole system at run-time. This can be achieved through engine. The engine takes an executable model (conforming to model execution. Recent initiatives at the OMG such as fUML1 an i-DSML) in input and is in charge of its interpretation, or ALF2 enable to add an executable behavior for instance that is, making evolving it, thereby generating a sequence of on UML3 class diagrams that are basically static structures. execution steps (a.k.a an execution trace). In a more general way, the MDE enables to define its very- own modeling language dedicated to a specific purpose within It is worthwhile mentioning that the aforesaid characteriza- the concept of DSML (Domain Specific Modeling Language). tion assumes that the current state of a model under execution Therefore one can also define DSML for executable models. is stored in the model itself. This is not always the case, Such DSML are called i-DSML [5] for interpreted DSML or since knowledge about the current state can also be internally xDSML [6] for executable DSML. managed by the engine. As an example, PauWare4 is an execution engine for UML state machines, written in Java. Model execution has been widely studied and a consensus Nevertheless, the genuine UML specification did not planned has been established on the constituent elements of an i-DSML to store in a state machine diagram what are the current active and so, on how carrying out model execution. This answers state(s). Consequently, the PauWare engine is responsible for the question: “How to build an i-DSML?”. In this paper, we this. To our opinion, storing the execution state inside the try to answer a symmetrical question that is: “If we are facing model rather than inside the engine has the advantage that a model, can we determine if this is an executable model, or it provides a self-contained execution trace. Thanks to that, it worded other way, if the DSML used is actually an i-DSML?”. is possible to perform failure recovery or to apply verification We are then looking for characteristics of the executable nature techniques onto the trace. of a model. As a side note, we identified a paradoxical situation about In the next section, we recall the constitutive elements of UML. Indeed, the genuine UML specification does not focus an i-DSML. In section III, we give two criteria allowing to enough on the execution of the different types of diagrams it 1 Semantics of a Foundational Subset for Executable UML Models (http: defined, and especially about the behavioral ones that yet are //www.omg.org/spec/FUML/) executable a priori. Reconsidering the state machine diagram, 2 Concrete Syntax for a UML Action Language: Action Language for the UML specification defines a kind of a dynamic part and Foundational UML (http://www.omg.org/spec/ALF/) 3 Unified Modeling Language (http://www.omg.org/spec/UML/) 4 http://www.pauware.com 44 Model conforms to MetaModel <> Static Part <> Dynamic Part conforms to Executable Model i-DSML <> Execution Semantics applies on takes input defined for Execution Engine <> Figure 1. Conceptual framework of model execution an execution semantics but only in an informal manner, in floor. As another example, a travel booking system inserts natural language. The dynamic elements are missing from customers data into database or call Web services provided by the UML metamodel (in [3] we proposed an extension in air transport companies. The behavior of a system determinates that purpose). Conversely, the famous class diagram, whose when these business routines have to be executed and under execution is counter-intuitive at first sight, is curiously released what conditions. with dynamic elements thereof: Those of the object diagram. In this context, the question is whether the decisions to Indeed, despite that the object diagram has not been invented carry out these actions are impelled by the model itself or with execution concerns in mind, it may serve to capture a if they come from elsewhere, in which case the model is current state of the instances of a class diagram, at a given considered as mere input data helping to take the decisions. moment of the future running system. These ideas of state and Reconsidering the examples above, the actions of the elevator time are clearly expressed in the OMG’s specification of the may be triggered according to a set of states and transitions UML Object diagram5 : “A static object diagram is an instance modeled through a finite state machine. Similarly, the calls of a class diagram; it shows a snapshot of the detailed state of to the various Web services may be orchestrated through a a system at a point in time”. BPEL6 or BPMN7 model. In both cases, the behavior of the system is fully defined by the model. Conversely, in the spirit III. C HARACTERIZATION OF THE EXECUTABLE NATURE of models@run.time [1], the elevator system may leverage OF A MODEL during its execution from a model about the extent of wear of The aforesaid characterization of model execution does not the components or about daily uses, etc. Such kind of models allow knowing explicitly what are models that can be executed, ought to be queried by the business actions, but in no case to and those who cannot. This is rather a matter of intuition trigger them. Hence, these are not executable models. In the from the software engineer, sometimes giving rise to debate wake, if a model defines the global behavior of a system, then or controversy. In order to draw a clearer demarcation line, let the software unit taking the latter as input can be referred as us describe two criteria that seems enough to characterize the an execution engine. executable nature of a model: B. Determinism of execution steps • The behavior of the software system is located into the model; As discussed in Section II, model execution consists in carrying out execution steps; each step making the model • It is always possible to determine the execution next evolving from an active state to another one. The model must step and an initial state. then intrinsically enable to pinpoint different execution states. However, being able to define the current state of the model These two simple criteria tell us if execution semantics can is necessary, but not sufficient. Indeed, we highlighted that be defined for a given DSML and hence if an engine can be the object diagram can be seen as the current state of a implemented thereafter. In other words, they tell us if a DSML class diagram although the class diagram is absolutely not is an i-DSML. executable. Unless it is associated and complemented with behavioral diagrams (sequence, state machines, . . . ) or fUML A. Location of the system behavior specifications, taken in isolation, a class diagram does not Let us assume some kind of software system which uses a enable to determine how making evolving a related object model during its execution (at runtime). The question is how diagram. to know the role of this model against the overall behavior Consequently, the second criterion of the executable nature of the running system. We recall that a system performs of models is to be able to carrying out execution steps. This “business actions”. For example, an elevator system opens and closes doors, winds/unwinds the cable to reach a given 6 Web Services Business Process Execution Language (https://www. oasis-open.org/committees/download.php/23964/wsbpel-v2.0-primer.htm) 5 http://doc.omg.org/formal/2000-03-01.pdf, section 3-20, page 278 7 Business Process Model and Notation (http://www.omg.org/spec/BPMN/) 45 feature can be found for example within activity diagrams, cases, curiously, the UML meta-model defines the concept finite state machines or Petri nets. In all these types of models, of use case instance that could be used as a dynamic part. modeling elements exist in that purpose, typically transitions However there is no way to determine how to execute a use that can be followed between states, activities or places. In case as the notion of execution step is totally missing in use some other cases, the “computing” of the next state can be cases. It is not possible to know which use case or in which made without dedicated modeling elements. For instance, for order use cases must be executed. Moreover, the description SBVR models8 , it is the execution engine that browses the of a use case is informal, written in natural language, and does entire rules set to determine the ones to trigger, as for any not permit to execute a case on its own. declarative language. SVBR models are executable without internal dynamic part There is a step which stands out from others: The one that and have the particularity to define implicit execution steps. starts the model execution by placing it in its initial state. The This is due to the declarative nature of this modeling language. model must then define a starting point. Making an analogy with programming languages, it can be seen as the equivalent IV. C ONCLUSION of a main() operation defining what to do when the program is just launched. For finite state machines, activities diagram In this paper, we first recalled what is an i-DSML from a or Petri nets, the starting point is defined explicitly as special technical point of view: An i-DSML defines a dynamic part modeling elements exist for this purpose. Having an ending within the meta-model, an execution semantics is specified and point is optional as some executions are not expected to end. is implemented by an execution engine. Then, we studied, in a more “philosophical” way, the executable nature of models. Having the capability to make the model evolving from a We have identified two criteria allowing determining if a model given running state to another one is a fundamental feature is executable and consequently if the DSML it is conforming because, without it, it will be impossible to specify an execu- to, is actually an i-DSML: 1) the fact that the behavior of tion semantics. Indeed, the goal of an execution engine is to the running system can be reified in the model and 2) that carrying out the model evolution accordingly to an execution the DSML enables to define execution steps during the model semantics. execution. These two features make possible to define an execution semantics and execution engines for this i-DSML. C. Some examples of OMG’s DSML Finally, we applied these criteria of some known DSML of the OMG and showed a completely backward situation: All System Current Execution the executable models may not have their DSML defining a Modeling language Executable? behavior state steps BPMN Yes External Explicit Yes dynamic part while some non-executable models do have a UML use case Yes Internal None No possible dynamic part. UML class diagram No Internal None No UML component diagram No Internal None No This characterization of the executable nature of a model UML state machines Yes External Explicit Yes is presumably not comprehensive but we guess that these two SBVR Yes External Implicit Yes UML sequence diagram Yes External Explicit Yes criteria are the most important to take into account. We will Table I. E XECUTABLE NATURE OF SOME DSML FROM THE OMG study more deeply several other i-DSML to make new criteria emerge. Table I applies our criteria on some well-known DSML of the OMG, based on their OMG specifications1,7,8 . For sake R EFERENCES of simplicity, we consider each UML diagram as a DSML. A [1] Gordon S. Blair, Nelly Bencomo, and Robert B. France. Mod- model is considered as executable if it reifies the behavior of els@run.time. IEEE Computer, 42(10):22–27, 2009. the system and if execution steps can be defined. The current [2] Erwan Breton and Jean Bézivin. Towards an understanding of model state of a model can either be defined as a full-fledged part of executability. In Proceedings of the international conference on Formal Ontology in Information Systems (FOIS ’01). ACM, 2001. the model or in an external way. [3] Eric Cariou, Cyril Ballagny, Alexandre Feugas, and Franck Barbier. Unsurprisingly, models defining structural software arti- Contracts for Model Execution Verification. In Seventh European Conference on Modelling Foundations and Applications (ECMFA 2011), facts such as component or class diagrams are not executable. volume 6698 of LNCS, pages 3–18. Springer, 2011. None of them enables to have execution steps. All UML [4] Eric Cariou, Olivier Le Goaer, Franck Barbier, and Samson Pierre. diagrams classified as behavioral diagrams (state machines, se- Characterization of Adaptable Interpreted-DSML. In 9th European quence diagram, etc.) are unquestionably executable. However Conference on Modelling Foundations and Applications (ECMFA 2013), the OMG has never planned to add to them their dynamic volume 7949 of LNCS, pages 37–53. Springer, 2013. part. For these models, the management of the current model [5] Peter J. Clarke, Yali Wu, Andrew A. Allen, Frank Hernandez, Mark state will be left to the responsibility of the execution engine. Allison, and Robert France. Formal and Practical Aspects of Domain- Specific Languages: Recent Developments, chapter 9: Towards Dynamic The specification of BPMN models suffers from the same Semantics for Synthesizing Interpreted DSMLs. IGI Global, 2013. limitation. [6] Benoit Combemale, Xavier Crégut, and Marc Pantel. A Design Pattern to Paradoxically, some non-executable models such as class Build Executable DSMLs and associated V&V tools. In The 19th Asia- Pacific Software Engineering Conference (APSEC 2012). IEEE, 2012. diagrams or use case diagrams have a dynamic part defined by [7] Grzegorz Lehmann, Marco Blumendorf, Frank Trollmann, and Sahin their meta-model. Indeed, as seen before, for class diagrams, Albayrak. Meta-Modeling Runtime Models. In Models@run.time the object diagram plays the role of its dynamic part. For use Workshop at MoDELS 2010, volume 6627 of LNCS. Springer, 2010. 8 Semantics of Business Vocabulary and Business Rules (http://www.omg. org/spec/SBVR/) 46