7.1 Overview
Domain-specific modeling languages are frequently used to model systems that interact with their environment in various ways: interaction may occur between software components, (multiple) user(s), or the physical surroundings in e.g. embedded systems. Such requirements manifest at design time in the usage ofdynamic modeling languagesthat allow high level specifications of such interactions. Moreover, dynamic semantics are not only specified, but – if possible – alsoexecuted in development tools, in order to allow debugging and experimentation with the models themselves (instead of e.g. generating code and testing the software directly in the target environment).
Model simulation is typically carried out using dedicated simulators (such as MATLAB). These tools support high-performance analysis that allows the analysis of critical system properties such as reliability and performance, prior to actual implementation and deployment. Unfortunately, these powerful features may come at a high implementation cost, as these specialised tools rely on com-plex specification languages, may need expensive hardware/software environments and, most im-portantly, as the analysis is performed in their special, mathematical domain, the results may be hard to translate back to the original modeling language. For thisback annotationof e.g. simulation runs (dynamic traces) and analysis results, model transformations are frequently used[13].
In many practical applications, the dynamic semantics of DSMLs do not require elaborate, high-precision mathematical computations that tools like MATLAB offer. Instead, they can be mapped to simple dynamic languages such as state machines, Petri nets or data flow networks (as emphasized in e.g. [KRDM+10]). These support discrete simulation scenarioswhere (i) the dynamic state of the system can be expressed in terms of discrete (model-based) configurations, and (ii) state transitions occur at discrete time intervals. This category of systems belong toDiscrete Event System Specification (DEVS)[Zei84] that have been used in the past decades in a wide spectrum of practical model-based simulation applications.
Within this framework, many model and graph transformation tools [dLV02, LLMC04, EEHT05, GBG+06, Ren04a, KW07, KPP08] may be used as alternatives or complementary technologies to dedi-cated model simulation tools [SV08]. As a common approach, these tools allow to use the underlying transformation engine directly to ’animate’ domain-specific models at editing time, which makes the rapid prototyping of dynamic languages feasible. However, such tools are not intrinsically targeted at language engineering, so they are also typically used as complementaries to DSM frameworks, which, in turn, leads to the same back-annotation problem encountered with dedicated tools.
Contributions In this chapter, we present a novel domain-specific model simulation framework for discrete domains, that combines event-driven transformations to support both automatic and inter-active dynamic semantics execution, within a fully featured language engineering environment. As a core contribution, our tool – based on incremental pattern matching – provides high performance simulation that scales to large model sizes, which allows its direct application in exploratory sys-tem simulation (instead of dedicated simulators). The simulator has also been adapted to support stochasticexecution, where probability distribution functions can be assigned to rule-match pairs that govern their scheduling. This work is discussed in detail in Appendix B.
7.2. MODEL SIMULATION BY EVENT-DRIVEN TRANSFORMATIONS 135
elements can be freely created and deleted (birth-and-death processes), this approach supports a flexible modeling framework for dynamic systems where not only a designated subset of the model (such as token distributions in Petri nets or active states in state machines), but the entire structure can evolve as time progresses (dynamic reconfiguration).
Definition 32 (Discrete simulation process) Adiscrete model simulation processover a model space (Def. 12) is a trajectory of model changes, equivalent to a sequence oftransactions(Def. 29):M SP = T~. In simple terms, such a simulation process can consist of the following model changes in-between state transitions: (i) creation/deletion of model elements, (ii) attribute value changes (changes in the valueVPM function), (iii) structural changes (changes in src,trg,supertypeOf,instanceOf VPM predicate values).
To support this flexible specification approach, dynamic semantics of domain-specific modeling languages are described by simulation rulesthat are essentially event-driven graph transformation rules (Def. 27). Simulation rules have two states that are evaluated at discrete time intervals by the execution mechanism: they can either be (i)enabled(meaning that they can be executed on the model to transfer the system to the next state), or (ii)disabled(meaning they cannot be executed).
Definition 33 (Model simulation rule) Similarly to event-driven rules, simulationrules are defined by enabledness conditions that are event definitions (Def. 25) and action sequencesaugmented with conditions(Def. 26). Formally, a model simulation ruleM SRis defined asM SR= (EDR).
Example 20 (Petri net firing simulation rule) Figure 7.1 shows an example simulation rule for Petri nets. We reuse the code from Figure 5.7 but use the @SimulationRule annotation instead of
@Triggerto indicate that this graph transformation rule should be used as a simulation rule. As the precondition, this example calls to thefireable(Tr)graph pattern (Figure 4.2) which (i) defines the execution context of the simulation rule to be individualTransitioninstances (as Tris the only parameter of the rule), and (ii) reuses thefireTransition(Tr)ASM rule (Figure 4.13) as the action.
1 @ S i m u l a t i o n R u l e (s e n s i t i v i t y=r i s e) 2 g t r u l e f i r e A s L o n g A s P o s s i b l e (i n o u t Tr ) = 3 {
4 p r e c o n d i t i o n f i n d f i r e a b l e ( Tr ) 5 a c t i o n {
6 c a l l f i r e t r a n s i t i o n ( Tr );
7 }
8 }
Figure 7.1: Simulation rule example for Petri net firing
7.2.1 Execution of simulation processes
The execution of a simulation process can be regarded on two abstraction levels: (i) on themodel space level, it corresponds to a sequence of model manipulation transactions; (ii) on thesimulation level, it corresponds to a sequence of simulation state transitions. Thesimulation statedefines the rule-match pairs that correspond to model contexts where the execution of a simulation rule is en-abled: for instance, a particular simulation state in a Petri netP N may correspond to the case where only transitiont1 is enabled for firing; another state occurs where both transitions t0 and t2 are
fireable etc. Asimulation transitionoccurs when the execution of a simulation rule for a concrete match is performed. The high-level model for such a simulation process is defined by asimulation schemeas follows:
Definition 34 (Simulation scheme) Asimulation schemeSIM over a model spaceM Sis a structure SIM = ({S}, S0,{M SR}, act), where
• {S}is a set of states (given by all possible configurations of the underlying model spaceM S),
• M SR}is a set of simulation rules,
• S0is the initial state corresponding to the initial state of the model spaceM S,
• act:S →SM SR×mis a function that gives the set of enabled simulation rule-match pairs enabled in a state.
The execution semantics for simulation schemes is similar to that of event-driven rules (based on queue automata) described in Section 5.2.2.5 (especially Figure 5.6), albeit with a crucial difference: for simulations,eventsare not arbitrary model manipulation transactions, instead the execution follows an implicit state trajectory where each state corresponds to the currently enabled set of rule-match pairs, and a state transition occurs whenever a rule-match pair has been selected (by the user, or an automated algorithm) for execution. In other words, while event-driven transformations are reactive to model changes, simulations areguidedeither interactively or automatically. To define this behav-ioral difference more precisely in previously established terms: in simulation execution, theexecution mode(Section 5.2.2.4) can be thought of as a special case ofchoose modewhere the choice is either made by the user or an automated algorithm.
Execution algorithm for simulation The detailed execution algorithm is illustrated in Figure 7.2.
Here, theWAIT superstaterepresents an abstract state where the execution is suspended and is wait-ing for input on how to proceed. ThePOP Queue (which is a waiting state indicated by grey color) represents the selection of an enabled simulation rule-match pair that can be performed by the user or automatically. When a simulation rule has been selected, it will be executed as with event-driven transformations. In theEVALstate, a re-calculation is performed for enabledness conditions, and the model simulation rule (MSR) queue is updated accordingly. Scheduling rules here are trivial as no priority etc. needs to be considered, all such logic is implemented in the POP Queue state.
Technically, the system relies on the same supporting infrastructure as event-driven transfor-mations: transaction log, RETE-based incremental pattern matching and delta monitors. The MSR registry is used for managing model simulation rules. It is important to note that model simula-tion scheme execusimula-tion may very well interact with the event-driven transformasimula-tion engine as all manipulation is performed in transactions.
Additionally to user input, the scheduling in the POP Queue state can be determined algorith-mically. This can be based on factors such as contents of the model (as in e.g. higher order trans-formations where the transformation engine can manipulate its own program by making changes to the model space), or probability distribution functions for stochastic simulation purposes. The latter application scenario is described in more detail in Appendix B.
Example 21 (Petri net simulation) The most important phases of the simulation process in the Petri net example are illustrated on Figure 7.3.
7.2. MODEL SIMULATION BY EVENT-DRIVEN TRANSFORMATIONS 137
Figure 7.2: Simulation execution algorithm
(a) Initial state (b) Choice point (c) Trap state
(d) On-the-fly model editing (e) Final state
Figure 7.3: Petri net simulation phases
1. The simulation begins by the evaluation of all enabledness conditions; for the single simulation rule of the Petri net example, this is done by retrieving the matching set for the isTransition-Fireable pattern (Figure 4.2) from the RETE network. For the sample Petri net in Figure 7.3a, the initial matching set only includes theforktransition. Thus, the initial simulation state has been calculated; since there is only one enabled transition, the user may proceed by firing that transition, or by invoking the automatic execution mode to proceed to the next simulation state.
2. Figure 7.3b shows the sample Petri net after theforktransition has been fired. As theToken model elements have been moved by the simulation rule, the RETE network was automatically updated to indicate that now transitions joinand exitare enabled. Since two possible con-tinuation paths exist, this non-determinism may be resolved randomly (in case of automated execution) or by user choice (guided simulation). If the exittransition is chosen, the system will reach atrap state(Figure 7.3c). In a trap state, no enabledness conditions are fulfilled, thus there are no possible continuation paths.
3. As the simulation system is fully integrated into the ViatraDSM domain-specific modeling framework, the user can make various changes as the simulation is being executed. The simu-lation engine calculates the simusimu-lation state incrementally based on the actual model, the user may influence the simulation process byediting the model on-the-fly. In Figure 7.3d, two pos-sible editing actions are shown: the user may re-enable the transitionjoinby either placing a newtokeninto the empty input place (denoted with1), or delete the input arc (denoted with2).
In both cases, the RETE network is automatically updated following the editing action, moving the simulation system back into a state wherejoinis enabled for firing. This feature is analo-gous to variable overwriting in program debuggers, however it allows for modifications on the DSM level. The user may also execute model editing which does not influence the simulation state. Fig. 7.3e shows a possible final state for the simulation (when a cycle has been completed) where the user has fired thejointransition and removed a token from the output place ofexit, which does not influence any enabledness condition.
7.2.2 User interface integration
Simulation runs can be initiated and managed using the graphical user interface provided by the ViatraDSM framework (Chapter 3). The interface provides support for three key functionalities: (i) interaction with the simulator(scheduling simulation rules to be fired when the simulator enters the IDLE state); (ii) domain-specificmodel query and manipulationby graph patterns, elementary oper-ations and graph transformation rules, while the simulation is being executed (waiting in the IDLE state); (iii) simulation rule managementmeaning that simulation rules can be added and removed from the active simulation rule registry any time.
Interaction with the simulator In Figure 7.4, the interactive Petri net simulation is displayed in the concrete syntax model (diagram), shown on the left. In addition to the synchronization of abstract syntax models (tree viewer) and diagrams, the system provides an extensible programming interface to provide decoration for elements included in the context of simulation rules; in Figure 7.4, fireable transitions are highlighted with red colour. In this case, these fireable transitions correspond to vari-ous matches of the only simulation rule (Figure 7.1) and the user may select any one to be scheduled for execution (”fired”).