On the Execution of Deep Models Colin Atkinson, Ralph Gerbig, Noah Metzger University of Mannheim Software Engineering Group Mannheim, Germany Email: {atkinson, gerbig, metzger}@informatik.uni-mannheim.de Abstract—A variety of tools today support the dynamic execu- advantages. First, it makes it possible to naturally represent tion/simulation of models within a single modeling environment. run-time instance information alongside model type informa- However, they all suffer from limitations resulting from their tion (with inherent support for the semantics of instantiation) implementation on a traditional, two-level modeling platform. The most prominent of these is the inability to represent the without polluting the model execution blueprint. Second, it specification of the modeling language, the domain model and provides natural support for debugging by allowing model model execution state at the same time in a uniform and seamless execution traces (i.e. instances) to be directly checked against manner. They therefore invariably have to resort to some kind model execution blueprints (i.e. types). Third, it allows the of ad hoc extension mechanism or workarounds to represent behavior of the system to be dynamically modified at any all three levels, with corresponding increases in accidental complexity and potential for misunderstandings. In this paper time by simply changing model execution instances without we demonstrate how deep modeling environments provide a changing the blueprint. Fourth, the execution blueprint can be conceptually cleaner and more powerful environment for model extended dynamically at any time, without the need for any execution and simulation thanks to their inherent support for code generation or editor redeployment, simply by adding new the representation of arbitrary numbers of classification levels, types to the language definition. Finally, it allows domains that and the ability to define customizable, domain specific languages within them. inherently feature more than three classification levels to be modeled and executed in a natural and uniform way since there I. I NTRODUCTION is no limitation on the number of levels that can be modeled. Modeling languages and tools aiming to support the ex- In this paper we illustrate the advantages of the deep mod- ecution of models are available in various different flavors eling approach for model execution by presenting an example and degrees of maturity. Some tools support the graphical of the execution of a simple but intuitive deep model from definition of executable models (e.g. fUML [1] in xMOF [2] the domain of gaming. The example represents an executed or graph transformations in AToMPM [3]). Others support game in which, from a birds-eye view, two players play against the textual definition of execution semantics (e.g. ALF [4]). each other on one computer. One uses the mouse to control Sophisticated, industry-quality simulation environments such the game and the other the keyboard. Changes to the state of as Simulink [5] or AnyLogic [6] are also available, with the game (i.e. the deep model) are immediately visible to all accompanying languages. parties, and a third player is able to manipulate the game while All these languages and tools are based on traditional “two- the other two players play. level” modeling technology which limits the modeler to two The paper is structured as follows: in the next section “physical” levels for modeling - one containing types and one (Section II) the deep modeling approach is introduced. The containing instances of those types. Usually the type level is prototype game demonstrating the advantages of deep models used to define the modeling language (meta-level) and the for model execution is then shown in Section III and discussed instance level is used to represent the user model (e.g. UML in Section IV. Finally the paper closes with a discussion class or state diagrams). However, with such an arrangement of related work (Section V) and a few concluding remarks there is no place left to model the instances of the user (Section VI). model which is where the majority of the execution actions conceptually take place. In general, at least three levels are II. D EEP M ODELING needed to naturally represent model execution in a modeling Deep modeling environments allow domains with more tool. To address the lack of sufficient modeling levels in than one logical class-/instance level to be represented within traditional OMG-based technologies, workarounds are needed one physical model. In the domain of model simulation and to show run-time data at the level of the executed user model execution at least three levels are usually required — one (i.e. execution blueprint). defining the modeling language, one describing “the model” Deep modeling provides a natural solution to this problem and one capturing the execution state of the model in the form by providing uniform, “out-of-the-box” support for modeling of instances. Figure 1 shows an excerpt of the deep model used over multiple classification levels. As well as supporting the for modeling the executed game environment. Although this extra classification level required to store execution informa- model has only three levels (i.e. O0 , O1 , O2 ) the number of tion. Deep modeling also provides a number of additional levels is unlimited in general. 28 Element PlayerType has a potency of 2, and is thus instantiable over name the following two levels. At the level below, it is instantiated Level Method by GeoWarsPlayer which has a potency of 1. This, in turn, * Clabject Feature Attribute is instantiated at the level below as Keyboard with potency 0. content potency durability mutability L2 * feature Keyboard cannot be instantiated further since the potency of O0 O1 O2 a model element must be a non-negative integer. The potency 1 value next to an attribute’s name specifies over how many PlayerType 2 GeoWarsPlayer Keyboard0:GeoWarsPlayer 2 2 1 1 subsequent levels that attribute can endure and, therefore, has health = health =100 health0=0.820 L1 to be possessed by instances of the clabject. Hence, it is also referred to as the attribute’s “durability”. Finally, the potency ? next to the value of an attribute specifies over how many L0 ?-Player Keyboard-Player levels the value of that attribute can be changed. It is thus also referred to as the “mutability” of that attribute. Durability and Fig. 1. The orthogonal classification architecture. mutability follow the same decrementation rule as the potency for model elements. The first thing that can be observed from the model is that III. G EOWARS : A D EEP M ODEL E XECUTION C ASE - STUDY two kinds of classification relationships are present, one kind Since games can be understood without any domain- represented in the vertical dimension and one kind represented expertise the demonstration prototype was chosen from this in the horizontal dimension. These two classification dimen- domain. The game consists of two components as shown in sions give the underlying architecture of deep modeling envi- Figure 2: the Deep Model representing the executed game ronments its name - the Orthogonal Classification Architecture (left-hand side) and the Game Engine executing the deep (OCA) [7]. The vertical dimension shows the model from the model (right-hand side). The model is implemented in the perspective of a traditional “two-level” implementation of such deep modeling environment Melanee [8] and the game engine an environment within a UML or EMF tool. The top level, is implemented in Java. Both parts communicate via sockets, L2 , defines all model elements that are available in the deep a widely used way to enable communication between two modeling language and is thus called the “linguistic (meta) software components. An alternative would be to connect the model”. The middle level, L1 , contains the domain content two components via a file storing exchange data but this has defined by the user and thus actually contains the so called the disadvantage of possible read/write conflicts. Since the deep model and its multiple “ontological classification levels”. Melanee tool is written in Java, the game component could All model elements in the L1 level, except model elements also have been implemented directly in Melanee because it residing at the most abstract ontological classification level, is implemented using Java, too. However, the goal was to O0 , have two types: an ontological type (horizontal dashed create a scenario in which the model is executed by an external arrows) and a linguistic type (vertical dotted arrows). The execution engine since we assume this is a common situation. lowest linguistic level, L0 , contains the real world entities The Melanee component uses the Melanee API to manip- represented by the deep model (i.e. the ontological content in ulate the deep model. This API offers a transaction-based L1 ). When working with a deep model, L0 and L2 are usually command framework for manipulating deep model content not visible since they do not contain any information that is and several meta-model oriented query operations. In cases immediately relevant to the development and execution of the where this API is not sufficient, the widely used and well domain model. documented capabilities of the Eclipse Platform on which Since model elements in the middle ontological levels are Melanee is built can be employed. Visual appearance is instances of the types at the ontological level above and types usually not changed through this API but can be. The size for instances at the ontological level below, they are (or play and location of model elements can be manipulated through the role of) classes and objects at the same time. In deep the attached visualizers, and the visual appearance of model modeling they are therefore referred to as “clabjects” (a name elements can be influenced by means of an aspect-oriented, derived from “class” and “object”) to emphasize that they context-sensitive, concrete syntax definition mechanism [9]. should be represented and thought of as integrated, unified Using these features, visualizations of model elements can be model elements. The notation used to represent clabjects is dynamically changed based on the values of their attributes. designed to be as UML-like as possible whilst being fully The deep model used to describe the game, shown in level-agnostic. The main notational difference to the UML Figure 3, has four levels: O0 containing a general language from an end-user’s point of view are the numeric “potencies” for describing games; O1 containing the language to describe next to the names of clabjects, attributes and attribute values the GeoWars game featured in this demonstration; O2 con- as seen in Figure 1. The potency next to the name of a taining the designed game levels which can be played and clabject specifies over how many subsequent model levels it O3 containing the current state of an executed GeoWars game can be instantiated. Each instantiation step reduces the potency level. At level O0 , generic types and attributes common to value by one until 0 is reached. In the example in Figure 1, all games are modelled. An instance of LevelType represents 29 Level 1 Model2SimulationBridge Simulation2ModelBridge D Shield( 0.001) Melanee API A Sockets Shuriken( 0.005) 100% A Rocket( 0.005) 100% D Telekinesis( 0.001) Deep Model (Melanee) Game Engine Fig. 2. The GeoWars implementation the environment in which players play a game. The name it is red. Below the circle the current health is indicated as attribute of LevelType is used to identify a particular game a percentage next to a heart icon. As the health attribute is level. Levels can have obstacles such as walls, rivers etc., of datatype real between 0 and 1 a formula multiplying this which are represented by instances of LevelComponentType, value by 100 is used to calculate the actual percentage value. while players are represented as instances of PlayerType which A very generic symbol is provided for weapons through is composed of PlayerComponentTypes. Such components can the Weapon clabject. Two join-points are defined, JI holding be weapons, power-ups etc. the icon to represent the weapon and JT indicating whether The GeoWars game modeling language is described at level a Weapon is an AttackWeapon or a DefenseWeapon. The O1 using instances of the generic game types at level O0 . name of the weapon and its regeneration speed (indicated GeoWars takes place in a level, the GeoWarsLevel , which by the upwards facing arrow) are displayed at the bottom. has a unique name for identification. It consists of Walls The subclasses of Weapon provide aspects of type around , which are obstacles that cannot be passed-through by players. enabling them to replace the content in the joinpoints. Whether Two GeoWarsPlayers are located in the level, one mouse- a weapon is for attacking or defense is indicated through an A controlled and the other keyboard-controlled as expressed in the first case or D in the later case. The icons are provided by through the control attribute. Furthermore, size (describing the the specific weapon classes (e.g. Rocket , Shuriken, Shield and player radius), speed (describing the player movement speed) Telekinesis). The icons for the other two Weapon subclasses and health (describing the damage that can be tolerated by a are not shown in the figure for space reasons. player until the end of the game) attributes are specified for Level O2 shows a blueprint of a game level modeled using GeoWarsPlayers. Each player has two Weapons, one Attack- the GeoWars DSL. A game level with two players each Weapon and one DefenseWeapon. Since the corresponding possessing one attack weapon and one defense weapon has clabjects exist purely for the purpose of grouping weapons been created. This game level is instantiated for execution at they are abstract clabjects as expressed by their potency the O3 level. In the example, the state of the executing game of 0 . Three AttackWeapons and three DefenseWeapons are is represented at O3 indicating that the keyboard-controlled predefined in the game, but new weapons can be added to the player has a health value of 64% and the mouse-controlled model as needed. The available AttackWeapons are Rocket , player a health value of 32%. Both players have also moved Shuriken and Minion while the available DefenseWeapons are from the starting position, which is visible from the position Telekinesis, Shield and Grenade. of their icons. Multiple instances of the same game level can The visualization of the level designer is realized using be displayed side-by-side and analyzed by reasoning services Melanee’s context-sensitive and aspect-oriented concrete syn- to check if the current execution state is valid. The simulation tax definition features [9]. A model element’s visualization can also be paused and resumed based on the information information is defined using a graphical, domain-specific visu- stored in the executing game model content. alizer. In the figure, this is shown as a cloud symbol containing A pragmatic approach is used to define the semantics of the the shape of the symbol to be used to represent instances of Deep Model by translating each concept in the deep-model to the clabject. The simplest graphical visualization is the one for one concept in the data model of the Game Engine with clear Walls which are represented as black rectangles. A GeoWar- execution semantics defined in Java. Deep modeling, however, sPlayer , on the other hand, is visualized as a solid colored- allows semantics to be defined in a translational, denotational circle whose color depends on the selected value (mouse or and operational style (cf. [10]) but the pragmatic approach was keyboard ) of the control attribute. The circle representing the used here as it was the most suitable. player is indicated by the dotted circle, with B being a place- The final deep model and game implementation is shown holder for the background-color of the circle. The expression in Figure 4. The top of the figure shows the deep model, which calculates the color is expressed in square brackets. If which is an instance of a game level description at level O3 , the player is keyboard-controlled the color is blue otherwise opened in Melanee. A one-to-one representation of this game 30 O0 LevelComponentType3 has * LevelType 3 name3:String= 2 PlayerType 3 PlayerComponentType 3 has * * component O1 GeoWarsLevel2:LevelType has JI= JI= name2:String= 1 * Wall2:LevelComponentType JT=A Rocket2:PlayerComponentType Shuriken2:PlayerComponentType has 2 name2:String=Rocket 0 name2:String=Shuriken0 1 AttackWeapon0 GeoWarsPlayer2:PlayerType regeneration2:Real=0.0051 attack health 2:Real=2 control2:ControlType={Mouse, Keyboard} 2 Weapon0 Minion2:PlayerComponentType size2:Integer= 2 2 name :String= 0 name2:String=Minion 0 JI= speed2:Integer= 2 regeneration2:Real= 1 JT Telekinesis2:PlayerComponentType B JI name( regenration) name2:String=Telekinesis 0 [health*100]% DefenseWeapon 0 1 2 1 B=[if control=keyboard then defense regeneration :Real=0.001 blue else red] Shield2:PlayerComponentType Grenade2:PlayerComponentType JT=D JI= name2:String=Shield 0 name2:String=Grenade 0 O2 Level 1 D Shield( 0.001) A Shuriken( 0.005) 100% A Rocket( 0.005) 100% D Telekinesis( 0.001) O3 Level 1 D 64% Shield( 0.001) A Shuriken( 0.005) 32% A Rocket( 0.005) D Telekinesis( 0.001) Fig. 3. The GeoWars example model. 31 level which would contain the GeoWars modeling language located at O1 in Figure 3 and an instance level which would contain the executed level blueprint which is located at level O2 in Figure 3. The execution information is then displayed as additional information in the model execution blueprint (i.e. the model game level) by applying workarounds such as UML Profiles or the annotation model approach [13] because a dedicated classification level for representing execution information is not available in such a modeling approach. From a conceptual point of view the deep modeling ap- proach is much cleaner than model execution approaches based on the aforementioned traditional “two-level” modeling approach. In particular, it naturally includes all the classifica- tion levels needed to represent the currently executed model. Changes to a running model execution can be defined at the level of a specific model instance to influence the state and behavior of that one particular game only. The model instances can also be used to pause and resume model executions. Such a stack of classification levels is not available in “two- level” modeling technologies and thus data about the state of the executed model has to be saved externally outside the modeling stack. Moreover, modifications to the executed model on a per-instance basis cannot be defined without applying workarounds. In such an architecture, changes can only be performed at the blueprint level which then effects all executions of the model and not a single instance only. Visualizing the current state of an executed model is also typically done at the blueprint level rather than at the instance Fig. 4. The GeoWars example running in Melanee and the GeoWars Engine. level today. This highlights the conceptual problem faced in the representation of executing models within a two-level environment as the user gets the impression that the blueprint level executed by the game engine is shown at the bottom is executed instead of a model instance. Deep modeling on of the figure. A video of the running tool can be found on the other hand supports the visualization of model instances the Melanee homepage [11] while the game and source are during model execution and leaves the blueprint untouched. available at [11] and [12]. To summarize, the example demonstrates that deep mod- eling naturally supports the key features needed for model IV. D ISCUSSION execution which are: 1) the availability of additional classi- This GeoWars game example shows that it is possible to fication levels dedicated to executed model instances, 2) the naturally implement sophisticated model execution environ- presentation of the current execution state of a system at the ments using deep modeling tools such as Melanee. Melanee instance level, 3) storing instance information of executed provides all the capabilities required for a model execution models in the model itself and 4) level-agnostic action and scenario including: 1) services for model query and manip- transformation languages to define execution semantics. All of ulation, 2) services for accessing and manipulating graphical these features are available in today’s tools but as extensions model representation definitions, 3) extensibility via a plug- to, and workarounds on, the underlying modeling approach in framework supporting a general purpose programming which is not optimal for the tasks previously mentioned. language (Java) and 4) support for defining execution seman- Unnatural extensions and workarounds increase the accidental tics through action languages and transformations. In areas complexity [14], [15] of models. where the Melanee API is not powerful enough the well- established technologies of the Eclipse Platform can be used V. R ELATED W ORK as a fallback. The tools ongoing use for other projects allows Three different areas of work are relevant to the technology missing features to be continuously discovered and added to presented in this paper: deep modeling tools with model the Melanee modeling environment and made available via the execution capabilities, standard modeling tools with built-in Melanee API. execution/simulation support and approaches to connect pure The model execution scenario shown here can also be modeling tools with third party execution/simulation tools. implemented with traditional modeling technologies available The only deep modeling tool besides Melanee which allows today. These “two-level” modeling technologies provide a type execution of models is Metadepth [16] which is shipped with 32 an action language from the Eclipse Epsilon Framework [17]. [2] T. Mayerhofer, P. Langer, M. Wimmer, and G. Kappel, “xmof: However, MetaDepth, itself only provides textual visualiza- Executable dsmls based on fuml,” in Software Language Engineering, ser. Lecture Notes in Computer Science, M. Erwig, R. Paige, and tions which limits the kind of applications that it can support. E. Van Wyk, Eds. Springer International Publishing, 2013, vol. The example shown in this paper is mainly graphical but 8225, pp. 56–75. [Online]. Available: \url{http://dx.doi.org/10.1007/ Melanee can support multi-format visualizations (e.g. text, 978-3-319-02654-1 4} [3] E. Syriani, H. Vangheluwe, R. Mannadiar, C. Hansen, S. V. Mierlo, forms, tables). and H. Ergin, “Atompm: A web-based modeling environment,” in In the two-level modeling space, Atom3 [18] and its Joint Proceedings of MODELS’13 Invited Talks, Demonstration Session, successor AtomPM [3], are the best known academic tools Poster Session, and ACM Student Research Competition co-located with the 16th International Conference on Model Driven Engineering with simulation and execution capabilities. The best known Languages and Systems (MODELS 2013), vol. 1115, 2013, pp. 21–25. industrial tools are AnyLogic [6] and Simulink [5]. AtomPM [4] E. Seidewitz, “Uml with meaning: Executable modeling in foundational allows a model to be simulated/executed by specifying a graph uml and the alf action language,” Ada Lett., vol. 34, no. 3, pp. 61–68, Oct. 2014. [Online]. Available: http://doi.acm.org/10.1145/2692956. transformation which is much more intuitive and easier to 2663187 realize than writing a plug-in for the Melanee tool. On the [5] J. B. Dabney and T. L. Harman, Mastering simulink. Pearson, 2004. other hand, we believe that this approach is less flexible and [6] A. Borshchev, The Big Book of Simulation Modeling: Multimethod Modeling with AnyLogic 6. AnyLogic North America, 2013. powerful when it comes to complex computations or the use of [7] C. Atkinson, M. Gutheil, and B. Kennel, “A flexible infrastructure for third party components as shown in this paper. One of the most multilevel language engineering,” Software Engineering, IEEE Transac- advanced academic tools supporting model execution is xMOF tions on, vol. 35, no. 6, 2009. [8] C. Atkinson and R. Gerbig, “Melanie: Multi-level modeling and ontol- [2], which operates on fUML [1] specifications. However, ogy engineering environment,” in Proceedings of the 2nd International because of its exclusive focus on UML it cannot be applied Master Class on Model-Driven Engineering: Modeling Wizards, ser. to arbitrary domain-specific languages unlike Melanee. MW ’12. New York, NY, USA: ACM, 2012, pp. 7:1–7:2. [9] ——, “Aspect-oriented concrete syntax definition for deep, user-defined An approach for connecting modeling tools with external modeling languages,” ser. MULTI’15, 2015. execution capabilities is described by Fritzsche et. al. [19]. [10] A. Kleppe, Software Language Engineering: Creating Domain-Specific Languages Using Metamodels, 1st ed. Addison-Wesley Professional, They present an approach which allows simulation information 2008. to be attached to any model and subsequently exported and [11] Melanee, “Project Website,” http://www.melanee.org, 2015. simulated/executed in another external tool. The model can [12] ——, “Source Code,” https://melanee2.informatik.uni-mannheim.de/ stash, 2015. then be updated by importing the simulation/execution trace [13] M. Fritzsche, J. Johannes, U. Aßmann, S. Mitschke, W. Gilani, I. Spence, back into the modeling tool. However, this approach adds a J. Brown, and P. Kilpatrick, “Systematic usage of embedded modelling lot of extra effort to modify existing modeling environments languages in automated model transformation chains,” in Software Lan- guage Engineering, ser. Lecture Notes in Computer Science, D. Gasevic, if an integrated tool experience is desired. R. Lämmel, and E. Van Wyk, Eds. Springer Berlin Heidelberg, 2009, vol. 5452. VI. C ONCLUSION [14] J. Brooks, F.P., “No silver bullet essence and accidents of software engineering,” Computer, vol. 20, no. 4, pp. 10–19, 1987. This work shows the advantages of deep modeling for sup- [15] C. Atkinson and T. Khne, “Reducing accidental complexity in domain models,” Software & Systems Modeling, vol. 7, no. 3, pp. 345–359, porting the simulation and execution of models. The prototype 2008. [Online]. Available: http://dx.doi.org/10.1007/s10270-007-0061-0 implementation shows that even the prototype deep modeling [16] J. de Lara and E. Guerra, “Deep meta-modelling with metadepth,” in tools available today are already up to the task. In the paper Proceedings of the 48th international conference on Objects, models, components, patterns, ser. TOOLS’10. Berlin, Heidelberg: Springer- we described the conceptual shortcomings of current modeling Verlag, 2010, pp. 1–20. technologies and explained how deep modeling overcomes [17] D. S. Kolovos, R. F. Paige, and F. A. C. Polack, “The epsilon them. The shortcomings mainly revolve around the inability object language (eol),” in Model Driven Architecture Foundations and Applications, ser. Lecture Notes in Computer Science, A. Rensink and of traditional “two-level” modeling environments to naturally J. Warmer, Eds. Springer Berlin Heidelberg, 2006, vol. 4066, pp. support more than one type and one instance level. The 128–142. [Online]. Available: http://dx.doi.org/10.1007/11787044 11 proposed deep modeling approach addresses this limitation [18] J. Lara and H. Vangheluwe, “Atom3: A tool for multi-formalism and meta-modelling,” in Fundamental Approaches to Software Engineering, through 1) the availability of additional classification levels ser. Lecture Notes in Computer Science, R.-D. Kutsche and H. Weber, dedicated to executed model instances, 2) the presentation of Eds. Springer Berlin Heidelberg, 2002, vol. 2306, pp. 174–188. the current execution state of a system at the instance level, [19] M. Fritzsche, “Performance related Decision Support for Process Mod- elling,” Ph.D. dissertation, Queen’s University Belfast, 2010. 3) storing instance information of executed models in the model itself and 4) level-agnostic action and transformation languages to define execution semantics. We are continually enhancing the capabilities of the Melanee deep modeling tool and hope the example in this paper will encourage other researchers to investigate the benefits of this technology for model simulation and execution. R EFERENCES [1] OMG, “Semantics of a foundational subset for executable uml models (fuml),” http://www.omg.org/spec/FUML/1.1/, 2013. 33