Benoît Combemale
email: benoit.combemale@irisa.fr

Xavier Crégut
email: xavier.cregut@enseeiht.fr

Marc Pantel
email: marc.pantel@enseeiht.fr

A Design Pattern to Build Executable DSMLs and associated V&V tools

Model executability is now a key concern in modeldriven engineering, mainly to support early validation and verification (V&V). Some approaches allow to weave executability into metamodels, defining executable domain-specific modeling languages (DSMLs). Model validation can then be achieved by simulation and graphical animation through direct interpretation of the conforming models. Other approaches address model executability by model compilation, allowing to reuse the virtual machines or V&V tools existing in the target domain. Nevertheless, systematic methods are currently not available to help the language designer in the definition of such an execution semantics and related tools. For instance, simulators are mostly hand-crafted in a tool specific manner for each DSML.

In this paper, we propose to reify the elements commonly used to support state-based execution in a DSML. We infer a design pattern (called Executable DSML pattern) providing a general reusable solution for the expression of the executability concerns in DSMLs. It favors flexibility and improves reusability in the definition of semantics-based tools for DSMLs. We illustrate how this pattern can be applied to ease the development of V&V tools.

I. INTRODUCTION

Model executability is now a key concern in MDE, especially to support early validation and verification (V&V) in the development process. Recently, several ways have been explored to implement the execution semantics of DSML (Domain Specific Modeling Language). Basically, they map the abstract syntax, defined by the metamodel, to a semantic domain [START_REF] Harel | Meaningful Modeling: What's the Semantics of "Semantics[END_REF]. Most proposals translate models into an existing semantic domain in order to reuse available tools (e.g., simulators or model-checkers). Such a semantics, called translational semantics, is used for instance by the group pUML in order to formalize some UML diagrams [START_REF] Clark | The Metamodelling Language Calculus: Foundation Semantics for UML[END_REF]. Even if more expressive languages like Maude [START_REF] Romero | Formal and Tool Support for Model Driven Engineering with Maude[END_REF] or FIACRE [START_REF] Berthomieu | FIACRE: an Intermediate Language for Model Verification in the TOPCASED Environment[END_REF] may be used to ease the writing of the translation between the DSML high level concepts and the formal language low level ones, this approach may require complex transformations to implement the semantic mapping. Furthermore, execution results are only obtained in the target domain. Getting back the results in the source language is difficult and usually requires to extend its abstract syntax in order to model these results.

Other approaches propose to weave executability into metamodels using an action language (e.g., Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-Languages[END_REF], xOCL [START_REF] Clark | SUPERLANGUAGES -Developing Languages and Applications with XMF[END_REF] or even JAVA with the EMF API). Similarly, in-place model transformations, including graph transformations [START_REF] Rozenberg | Handbook of graph grammars and computing by graph transformation: volume I. foundations[END_REF], were widely investigated to give a declarative specification of the execution semantics. For example, in [START_REF] Markovic | Semantics of OCL specified with QVT[END_REF] the authors use QVT [START_REF]MOF 2.0 Query/ View/ Transformation (QVT)[END_REF] to express rewriting rules that gradually compute the values of an OCL expression. Kuske et al. [START_REF] Kuske | An Integrated Semantics for UML Class, Object and State Diagrams Based on Graph Transformation[END_REF] have used graph transformation to define the executable semantics for some UML diagrams. These approaches allow a more intuitive definition of executable DSMLs. The semantic domain is an extension of the abstract syntax, and the semantic mapping is defined using an action language. Thus, the language designer has only to deal with concepts of the DSML and not with another language and an explicit mapping. Nevertheless, such approaches require to implement for each DSML all the execution-based tools.

In all cases, the definition of DSMLs is facing today hard methodological problems for the specification of tool supported execution semantics. DSMLs are often empirically defined without any uniformity and underlying best practices [START_REF] Cho | Design patterns for metamodels[END_REF]. For example, the information capturing the state of a model being executed, a key part of the semantic domain, is often scattered in a tool-specific way, without any explicit relation to the abstract syntax. Thus, different tools such as simulators, model checkers or code generators may easily be inconsistent, and not interoperable as they rely on slightly different semantic domains. In the same way, no methodology to define an executable DSML provides the flexibility to associate different semantics to the same DSML, to combine different models of computation (e.g., multi-modeling), and to easily weave time and communication models; nor the evolvability to manage semantics changes. Consequently, semantics-based tools (e.g., simulators and graphical animators) are most of the time redefined without any capitalization (e.g., dynamic execution related information, execution engine, etc.), and without any guidances to ease this error prone and time consuming development task.

In this paper we introduce a general, reusable and toolsupported approach to assist a DSML designer in the definition of an execution semantics and the related tools. It relies on capturing the different concerns involved in the definition of an executable DSML. These concerns are reified, in a structural design pattern to support executability into DSML: the Executable DSML pattern. It addresses several common use cases relying on execution semantics, especially model V&V. Based on this pattern, generic and generative approaches are proposed to partially or totally automate the definition of DSML tools for V&V. This work has been applied in TOPCASED [START_REF] Farail | The TOPCASED project: a Toolkit in OPen source for Critical Aeronautic SystEms Design[END_REF], an opensource MDE toolkit for safety critical application design. V&V capabilities for MDE are one of its key features. It is therefore of uttermost importance to ease the development of V&V tools for the various DSMLs considered in TOPCASED. Especially, the application of this work led to the development of the current SYSML/UML model simulator and graphical animator that handle the Class, State Machine and Activity diagrams. With the help of our design pattern, we show how a model execution framework has been defined to offer an independent Model of Computation (MoC) shared by different DSMLs. We also present generative tools to automate the definition of dedicated (i.e., DSML-dependent) graphical model animators.

The remainder of this paper is structured as follows. Section II introduces the Executable DSML pattern illustrated with model animation for validation. Section III details this use of the pattern and proposes both a reusable MoC-specific model execution framework, and the associated generative approach to ease the definition of DSML-specific graphical model animators. Section IV summarizes related works. Section V concludes and gives insights on perspective.

II. A METAMODELING PATTERN FOR MODEL EXECUTION

In this section, we follow the common design pattern description format used in [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. We rely on the model simulation and graphical animation of UML State Machine (UML-SM) diagrams [START_REF]Unified Modeling Language (UML)[END_REF] in order to introduce the requirements for model execution at a conceptual level (further detailed in section III).

A. Motivation

As explained in the introduction, the DSML semantics is usually enclosed (generally hard-coded) in the execution and transformation functions hidden in the system development tools. Our purpose is to make its definition explicit, including the semantic domain and the mapping as advocated in [START_REF] Harel | Meaningful Modeling: What's the Semantics of "Semantics[END_REF].

The designer of a model that describes a system behavior usually needs to simulate and animate it to check whether it behaves as expected. Unfortunately, the metamodel does not generally describe all the information that has to be managed at execution time (i.e. the semantic domain). For example, UML-SM defines the concepts of Region, State, Transition, Event, etc. but lacks the notions of active states in a region, or of fireable transitions (cf. Figure 1). Also, no elements are available to store the sequence of events received by a state machine. Furthermore, during model animation, the designer has to simulate the behavior of the system environment through stimuli. The UML-SM designer will inject UML events in a state machine that will trigger fireable transitions and change the current states of the regions. Obviously, the way the system reacts to the stimuli defines its execution semantics. This reaction updates the execution related data according to the current state of the model and the received stimulus. In the end, the designer may want to replay the same execution, for example, to check whether defects have been corrected or not, or to be able to perform non regression tests. Scenarios are then useful to describe a sequence of stimuli.

We have highlighted that model execution requires the extension of a DSML metamodel with: i) the definition of information managed during execution, ii) the definition of the stimuli that trigger the evolution of the model, iii) the organization of stimuli as scenarios, iv) the definition of an execution semantics (or transition function) that describes how the model state evolves when a stimulus occurs.

An executable DSML (xDSML) is a DSML which defines the execution of its conforming models for a particular purpose. Therefore, an executable DSML at least includes the definition of its language abstract syntax, and its execution semantics (including semantic domain and semantic mapping related information)

We propose to reify execution related elements to make them explicit and manageable. We aim to provide flexibility, evolvability and interoperability in the semantics definition. Furthermore such elements must ease the development of tools related to model execution, for example V&V tools.

B. Structure

Figure 2 shows the structure of the proposed Executable DSML pattern. It is built from four structural parts (detailed in the next subsection) that are woven together using the «merge» and «import» predefined package operators of MOF [START_REF]Meta Object Facility (MOF) 2.0 Core[END_REF]. These parts organize the data related to the DSML and its execution semantics. A fifth part called Semantics provides the execution semantics itself relying on the previous four parts (i.e., the semantic mapping based on the previous reification of the semantic domain information). As it is a pattern to organize data at the metamodel level (i.e., a metamodeling pattern, as motivated in [START_REF] Cho | Design patterns for metamodels[END_REF]), the structure shows dependencies between packages that represent parts of a metamodel. This pattern is architectural like MVC or 3-tiers. It emphasizes the common structure that a metamodel for an xDSML should use in order to define the language semantics. In addition to provide guidelines in language definition, the purpose is to be able to define generic and generative tools relying on that architecture.

C. Participants 1) Domain Definition MetaModel (DDMM):

It is the usual metamodel used by standardization bodies to define the modeling language. It provides the key concepts of the language (representing the considered domain) and their relationships. For instance, the UML metamodel defined by the OMG is a DDMM (see Figure 1 for a small subset). Usually, the DDMM does not contain all the execution-related information. For instance, the UML DDMM does not formalize the notions of active state nor event queue. Thus, even if a model describes the implicit potential behavior of a system, it does not usually provide explicitly the elements for its execution.

Events Definition MetaModel

EDMM

Domain Definition MetaModel

DDMM

States Definition MetaModel

SDMM

2) State Definition MetaModel (SDMM): During the execution of a model, additional data is usually mandatory for expressing the execution itself (a.k.a. dynamic information). Such data must be manipulated and recorded (in the form of metaclass instances). For example, each active UML region must have one active state and a state machine must store the sequence of received events. These execution related data make up the SDMM, and are related to the semantic domain: the data required to express the execution semantics. Thus the SDMM is built on top of the DDMM. For example, the UML State Machines SDMM may add a reference from Region to State (both defined in the DDMM) to record the active state of one region.

3) Event Definition MetaModel (EDMM): The EDMM of a given DSML specifies the concrete stimuli (called runtime events) that drive the execution of a model that conforms to this DSML. These stimuli are not only concrete system hardware events, but also more abstract software events like storage events for reading or writing, communication events for sending or receiving, clock events as ticks, function events like computation results given parameters, etc. Concrete stimuli define properties of events related to the formal execution semantics to be supported.

As an illustration, the runtime event we consider for the UML State Machine stores an UML event (an instance of Event, see Figure 1) in a state machine queue. When the UML event in the queue is handled by the state machine, it fires the transitions that it triggers.

4) Trace Management MetaModel (TM3):

The TM3 is specific to a particular MoC and is reused for all DSMLs using this MoC. As an example, Figure 3 shows a simplified TM3 dedicated to discrete-events system modeling [START_REF] Zeigler | Theory of Modeling and Simulation[END_REF]. It defines three main metaclasses called Trace, Scenario and RuntimeEvent. RuntimeEvent is an abstract metaclass which Exogenous runtime events are injected by the environment, while endogenous runtime events are produced internally by the system in response to another runtime event (cf. cause in Figure 3). As stated by the OCL constraint in Figure 3, a scenario is made of exogenous runtime events whereas a trace corresponds to one possible execution of a scenario and is thus composed of any kind of runtime events. A more sophisticated trace management metamodel or a "standard" one (like the UML Testing Profile [START_REF][END_REF]) may be integrated in our pattern.

5) Semantics:

The last and key participant is the package Semantics. It abstracts both the semantic mapping [START_REF] Harel | Meaningful Modeling: What's the Semantics of "Semantics[END_REF] (DSMLspecific part) and the interactions with the environment (MoCspecific part). It describes how the running model (SDMM) evolves according to the stimuli defined in the EDMM. An important point in applying the pattern is to define the content of the package Semantics that depends on the application context. On the one hand the semantic mapping may be explicitly defined as a transition function and thus conforms to an action language (a.k.a. operational semantics). In this case, the four previous participants correspond to the semantic domain. On the other hand, the semantic mapping may be implicitly defined thanks to a translation to another language (a.k.a. translational semantics). Consequently SDMM and EDMM do not correspond to the semantic domain but help in defining the mapping, and in getting results back.

D. Consequences

According to the Executable DSML pattern, an xDSML is supported by an executable metamodel MM x structured as three DSML-specific parts (DDMM, SDMM, and EDMM) and one MoC-specific part (TM3):

MM x = {DDMM, SDMM, EDMM} ∪ {T M3}
MM x reifies the elements involved in model execution. The DDMM is the starting point. It is usually standardized and cannot be changed in order to preserve interoperability. The TM3 is shared by any DSMLs relying on the same MoC. Thus, a semantics is defined by a triplet (SDMM, EDMM, Semantics). The SDMM and the EDMM introduce the needed information to express the execution semantics (i.e. the semantic domain) whereas the package Semantics implements the semantic mapping. These three different parts should not be defined independently in order to reduce the risks of inconsistencies. Any change in this triplet entails a new semantics. In order to reduce these risks, we propose through the use of this pattern to reify the various aspects linked to the definition of the execution semantics in order to allow systematic specification, analysis and validation of an executable DSML metamodel.

Applying this pattern produces several consequences, both for the definition of the semantics, and for the definition of the execution-related tools.

1) Definition of the Semantics:

The pattern allows a modular implementation of the execution semantics (i.e., an implementation that is separated out, encapsulated, and easily replaceable) with respect to the core language metamodel. The specification of the DSML semantics is split in two parts: first, a generic MoC based on the TM3, and shared with other DSMLs; and then DSML specific elements based on the SDMM and EDMM. This strong property provides several benefits described here after.

It favors the evolvability of the semantics during the DSML lifetime thanks to the separation of concerns involved in the definition of an execution semantics.

It eases the factorization of commonalities. The pattern favors the definition of a family of semantics for a single language as well as the semantics of a family of languages. For example, semantic variation points (like in UML) lead to different but similar semantics definitions. In most cases, SDMM and EDMM are the same and only the package Semantics has to be adapted.

It provides flexibility in the association of semantics to a given DSML in order to define several purpose driven semantics for the same DSML. Obviously, runtime information (SDMM), concrete runtime events (EDMM) and the package Semantics are dependent on the user purpose during the execution of models. For instance, the user may prefer to carry out more abstract execution with fewer runtime events and/or runtime information that demonstrates one aspect of the system under assessment or the user may want to define a fine-grained semantics that exhibits most aspects of the system. Each semantics will have its own set of events in the EDMM and states in the SDMM.

No specific method is enforced to apply the pattern. Nevertheless, we have proposed in [START_REF] Combemale | A Property-Driven Approach to Formal Verification of Process Models[END_REF] a method for the definition of DSML execution semantics dedicated to verification activities. It advocates a property driven approach: only runtime information and events required to evaluate properties of interest to the end user are described. In doing so, the EDMM and SDMM are a minimal mandatory subset of data to express the semantics relevant for the user, as advocated by the substitutability principle [START_REF] Minsky | Matter, mind, and models[END_REF].

The definition of the package Semantics is postponed. The pattern is mainly an architectural pattern that helps in structuring information required to make a DSML executable while ensuring interoperability between tools based on this DSML. Thus, the semantic mapping and the interaction with the environment are not described in the pattern (as discussed in Section II-C). According to the purpose of empowering a DSML with execution, the content of the package Semantics may be detailed. For example, Section III shows a MoCspecific framework for model execution. In most cases, the architecture of the MM x eases the definition of the package Semantics. However, for scalability, efficiency, and some time readability purposes, it might be useful to introduce a new metamodel not relying on the standard DDMM. For example, the use of matrices to encode Petri nets instead of graphs is mandatory to allow the execution of huge models. This is also true in the case of General Purpose Modeling Languages (GPML) whose standard metamodel (DDMM) and semantics can be extremely complex. The introduction of purpose specific metamodels allows to ease the definition of the semantics for a subset of the language that the end user wants to assess.

Semantics is discrete event oriented. The EDMM part of the pattern stresses the use of discrete events to represent system stimuli. It may not be well-suited for all systems, like continuous one. Nevertheless, we can notice that when one wants to observe a continuous system, a discretization (on events or time) is performed. Thus, the pattern is still applicable as this is done in PTOLEMY II [START_REF] Lee | Overview of the Ptolemy project[END_REF] for example. Time may be managed continuously as part of the MoC or discretized as runtime events.

2) Definition of the Execution-Related Tools:

The formalization of pattern elements favors the definition of generic and generative execution-based tools. Examples are given in Section III.

Several models of computation (MoCs) may be used to support symbolic execution semantics. The description of the EDMM and TM3 might give the impression that the semantics is restricted to a discrete event MoC. In fact, these parts of the pattern define the discrete observations and interactions between the user/environment and the system, but any MoC can be used, including continuous ones. Our aim is to describe systems that in the end will be managed by either discrete software or human end users. Both can only handle a finite discrete history of the system. The MM x architecture is strongly based on the user point of view: observation of the interaction between the model and its environment (depicted by the model state) at some key points in time represented by the runtime events. However, the package Semantics can implement any MoC or abstract the translation to an existing one.

Cosimulation and models at runtime can be integrated. The package Semantics can also be implemented as a wrapper over, either real physical systems in which sensors and actuators are mapped to MM x directly or through software layers, or existing softwares and execution engines. Several DSMLs can It favors interoperability between the various semanticsrelated tools for a given DSML. Different kinds of tools may be based on the same executable DSML. The separation between MM x and the package Semantics makes possible to share data between tools (i.e., a counter example provided by a verification tool can be analyzed using a graphical animator). However, this relies only on structural similarities and thus requires to assess the compatibility of both packages Semantics (i.e., by checking the bisimilarity of the transition relations).

III. APPLICATION TO GRAPHICAL MODEL ANIMATION A. A MoC-specific Framework for Model Execution

The TOPCASED project addresses the domains of aeronautics, aerospace and more generally transportation systems. Dynamic behaviors and real-time features prevails in the design of such systems. During the design of their software parts, discrete (synchronous or asynchronous) modeling [START_REF] Law | Simulation Modeling and Analysis[END_REF] is the most adequate way to represent them. Thus, in this context, only the discrete event MoC is used for the model execution of any DSMLs.

We have applied the Executable DSML pattern for model execution and developed a framework (cf. Figure 4) included in the TOPCASED toolkit. The execution engine is the core of the framework. It implements a model execution engine for a discrete event based MoC. It is independent of any DSMLs (top of Figure 4) as it only depends on the TM3 (RuntimeEvent) and the Interpreter interface from the package Semantics which abstracts the transition function that will be provided by DSML-specific packages Semantics. Its run method updates the dynamic information of the model defined in the SDMM according to one runtime event (instance of the events defined in EDMM) and returns the list of generated endogenous runtime events. For a particular DSML, one has to provide both the implementation of the Interpreter and the concrete runtime events in EDMM (bottom of Figure 4).

Besides the interpreter, the execution engine is composed of two main components which implement the discrete events MoC: Agenda and Driver. The agenda (Agenda) stores the runtime events (RuntimeEvent) corresponding to one particular execution. These events are ordered according to their occurring date. The agenda provides the API required by the driver to handle the events (e.g., retrieving the next event and adding a new event). The driver (Driver) controls the execution. It contains a step method, which gets the next runtime event from the agenda and asks the interpreter (Interpreter) to handle it. The generated endogenous runtime events are then added to the agenda. The driver provides an API that allows both batch and interactive execution.

For each execution semantics of a given DSML, a Concrete Interpreter must implement Interpreter (cf. Figure 4). For the TOPCASED animators, the run method was initially handcoded using JAVA and the EMF API. Then, it was implemented using SMARTQVT, an open source implementation of the OMG QVT specification [START_REF]MOF 2.0 Query/ View/ Transformation (QVT)[END_REF] that generates JAVA code relying on the EMF API. SMARTQVT mainly eases the navigation on model elements. Any other techniques for semantics implementation may be considered (cf. Introduction).

B. A Generative Approach for Model Animation

Figure 5 shows the components of the TOPCASED Eclipsebased animators for UML-SM. The main view displays the graphical syntax which is reused from the DSML editor. This one is decorated with dynamic information (coming from the SDMM): active states are highlighted with a green background, fireable transitions are in red with an icon. Other decorations like gauges or progress bars could be used. This visualization has been chosen because it allows the user to view dynamic information directly on the domain model he has built. Nevertheless, other specific visualization tools could be developed. The Eclipse Explorer, the outline of the diagram and the tree view of the underlying model are on the left side. The bottom view is the Control Panel that manages the execution (start/stop the animation, move forth/back in the trace, etc.). During interactive animation, the user may inject an instance of a runtime event by clicking on the concerned graphical element. A dialog box prompts the user for the UML event name. It is part of the Scenario Builder of which the purpose is to manage a scenario before the animation starts (based on the requirements, a test case generator, or a counter-example provided by a model-checker), or during the animation in an interactive fashion.

All parts of the Executable DSML pattern are used to derive the animators' components. Some implementation insights are given hereafter (see [START_REF] Crégut | Generative technologies for model animation in the TopCased platform[END_REF] for further details). The graphical editor is built from the DDMM. It is generated from a TOPCASED configuration file that maps graphical elements to the metamodel elements. The animator's view (i.e., the visualization of dynamic information) is based on the SDMM. It is implemented using the decorators provided by GMF and relies on the EMF notifications to update the graphical representation when the running model is changing. The Scenario Builder relies on the EDMM (and thus on the TM3). It mainly consists in defining a concrete syntax for the runtime events defined in the EDMM of a given DSML to provide the way of building scenarios. The underlying tooling can be built using existing tools (e.g., GMF, TMF). In interactive mode, the dialog boxes are generated from the runtime event attributes. The TM3 is used by the execution engine that stores all the events in the agenda as a trace. It is also used by the control panel to go back and forth in that trace.

IV. RELATED WORK

A language semantics is usually defined operationally or by translation (cf. Section I). Both may be considered with the Executable DSML pattern and correspond to the technology used to implement the semantic mapping in the package Semantics. The objective of the Executable DSML pattern is twofold: it provides a methodological framework to ease the use of such approaches as well as an architectural framework to be supported by generative and generic tools.

Such an engineering of semantics for DSMLs is at the heart of some previous work. Sadilek et al. have followed a similar purpose to ours in the EPROVIDE project: provide execution power to DSMLs and ease the development of related tools [START_REF] Sadilek | Using grammarware languages to define operational semantics of modelled languages[END_REF]. Their framework enables the implementation of a DSML semantics using various technologies (including JAVA, PROLOG, ASM, QVT). They have prototyped its use for PetriNet and SDL DSMLs. In such a context, the Executable DSML pattern assists the DSML designer in structuring the dynamic information and provides a more abstract basis to build graphical model animators without explicitly relying on APIs. In [START_REF] Scheidgen | Human comprehensible and machine processable specifications of operational semantics[END_REF] the authors propose a reification of the dynamic information according to the execution semantics specified thanks to UML Activity Diagrams. The Executable DSML pattern complements this approach by reifying runtime events to assist the implementation of both operational and translational semantics, and to be used by V&V tools.

V. CONCLUSION AND PERSPECTIVES

The Executable DSML pattern provides a methodological framework to ease and assist the definition of language semantics because it enforces a clear separation of concerns in metamodels for the recurring and general problem of model execution. The Executable DSML pattern favors also the definition of generic and generative technologies to ease the development of semantics-based tools for DSML such as model animators.

Similarly to object-oriented modeling (OOM), this paper emphasizes the need for design patterns in metamodeling to capitalize experiences for recurring problems. Moreover, in the same way that design patterns in OOM standardize the way designs are developed, design patterns in metamodeling should help the implementation of generative approaches.

The Executable DSML pattern claims an engineering of semantics in MDE. The overall objective is to provide a flexible and general framework for model execution, supported by generic and generative tools to ease the development of DSML-specific tools. We are currently experimenting the pattern to improve the specification and proof of correctness of semantic preserving model transformations.

Fig. 1 .

 1 Fig. 1. Subset of the UML StateMachine Metamodel

Fig. 2 .

 2 Fig. 2. The Executable DSML Pattern

Fig. 4 .

 4 Fig. 4. The TOPCASED Model Execution Framework

Fig. 5 .

 5 Fig. 5. The Initially Generated UML State Machine TOPCASED Animator

  RuntimeEvent is imported in the EDMM, and all the concrete runtime events must inherits from it. This metaclass has executability-related features, like (partially ordered) dates of occurrence (i.e., symbolic representation of the time when the runtime event occurs). Any RuntimeEvent that triggers a semantic action involving a state change should have a reference to its source and target states information in the SDMM. RuntimeEvent instances fall into two categories, which are modeled by the RuntimeEventKind enumeration.

	TM3
	context Scenario inv :
	self.runtimeEvent->forAll(re | re.kind = #exogenous)
	Trace	*			1	Scenario
		{ordered}	*	*	{ordered}
	<<enumeration>> RuntimeEventKind endogenous exogenous	RuntimeEvent date: Integer kind: RuntimeEventKind	cause 0..1
	Fig. 3. A simplified TM3 for Discrete-Events Modeling
	reifies the concept of stimulus. It is an abstraction for any
	kind of semantic related stimulus defined in the EDMM. To
	this end,