-A variety of tools today support the dynamic execution/simulation of models within a single modeling environment. However, they all suffer from limitations resulting from their implementation on a traditional, two-level modeling platform. The most prominent of these is the inability to represent the specification of the modeling language, the domain model and model execution state at the same time in a uniform and seamless manner. They therefore invariably have to resort to some kind of ad hoc extension mechanism or workarounds to represent all three levels, with corresponding increases in accidental complexity and potential for misunderstandings. In this paper we demonstrate how deep modeling environments provide a conceptually cleaner and more powerful environment for model execution and simulation thanks to their inherent support for the representation of arbitrary numbers of classification levels, and the ability to define customizable, domain specific languages within them.
I. INTRODUCTION advantages. First, it makes it possible to naturally represent run-time instance information alongside model type information (with inherent support for the semantics of instantiation) without polluting the model execution blueprint. Second, it provides natural support for debugging by allowing model execution traces (i.e. instances) to be directly checked against model execution blueprints (i.e. types). Third, it allows the behavior of the system to be dynamically modified at any time by simply changing model execution instances without changing the blueprint. Fourth, the execution blueprint can be extended dynamically at any time, without the need for any code generation or editor redeployment, simply by adding new types to the language definition. Finally, it allows domains that inherently feature more than three classification levels to be modeled and executed in a natural and uniform way since there is no limitation on the number of levels that can be modeled.
In this paper we illustrate the advantages of the deep modeling approach for model execution by presenting an example of the execution of a simple but intuitive deep model from the domain of gaming. The example represents an executed game in which, from a birds-eye view, two players play against each other on one computer. One uses the mouse to control the game and the other the keyboard. Changes to the state of the game (i.e. the deep model) are immediately visible to all parties, and a third player is able to manipulate the game while the other two players play.
The paper is structured as follows: in the next section (Section II) the deep modeling approach is introduced. The prototype game demonstrating the advantages of deep models for model execution is then shown in Section III and discussed in Section IV. Finally the paper closes with a discussion of related work (Section V) and a few concluding remarks (Section VI). L2 L1
The first thing that can be observed from the model is that
two kinds of classification relationships are present, one kind
represented in the vertical dimension and one kind represented
in the horizontal dimension. These two classification
dimensions give the underlying architecture of deep modeling
environments its name - the Orthogonal Classification Architecture
(OCA) [
Since model elements in the middle ontological levels are instances of the types at the ontological level above and types for instances at the ontological level below, they are (or play the role of) classes and objects at the same time. In deep modeling they are therefore referred to as “clabjects” (a name derived from “class” and “object”) to emphasize that they should be represented and thought of as integrated, unified model elements. The notation used to represent clabjects is designed to be as UML-like as possible whilst being fully level-agnostic. The main notational difference to the UML from an end-user’s point of view are the numeric “potencies” next to the names of clabjects, attributes and attribute values as seen in Figure 1. The potency next to the name of a clabject specifies over how many subsequent model levels it can be instantiated. Each instantiation step reduces the potency value by one until 0 is reached. In the example in Figure 1,
PlayerType has a potency of 2, and is thus instantiable over the following two levels. At the level below, it is instantiated by GeoWarsPlayer which has a potency of 1. This, in turn, is instantiated at the level below as Keyboard with potency 0. Keyboard cannot be instantiated further since the potency of a model element must be a non-negative integer. The potency value next to an attribute’s name specifies over how many subsequent levels that attribute can endure and, therefore, has 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 levels the value of that attribute can be changed. It is thus also referred to as the “mutability” of that attribute. Durability and mutability follow the same decrementation rule as the potency for model elements.
III. GEOWARS: A DEEP MODEL EXECUTION CASE-STUDY
Since games can be understood without any
domainexpertise the demonstration prototype was chosen from this
domain. The game consists of two components as shown in
Figure 2: the Deep Model representing the executed game
(left-hand side) and the Game Engine executing the deep
model (right-hand side). The model is implemented in the
deep modeling environment Melanee [
The Melanee component uses the Melanee API to
manipulate the deep model. This API offers a transaction-based
command framework for manipulating deep model content
and several meta-model oriented query operations. In cases
where this API is not sufficient, the widely used and well
documented capabilities of the Eclipse Platform on which
Melanee is built can be employed. Visual appearance is
usually not changed through this API but can be. The size
and location of model elements can be manipulated through
the attached visualizers, and the visual appearance of model
elements can be influenced by means of an aspect-oriented,
context-sensitive, concrete syntax definition mechanism [
The deep model used to describe the game, shown in Figure 3, has four levels: O0 containing a general language for describing games; O1 containing the language to describe the GeoWars game featured in this demonstration; O2 containing the designed game levels which can be played and O3 containing the current state of an executed GeoWars game level. At level O0, generic types and attributes common to all games are modelled. An instance of LevelType represents 100% 100%
D Shield( 0.001)
A Shuriken( 0.005)
A Rocket( 0.005)
D Telekinesis( 0.001) e g d i r IeePnA litaounB lae iSm
2 M l e d o M s t e k c o S
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 [
LevelType 3
name3:String=2
O1 GeoWarsLevel2:LevelType
name2:String=1
Fig. 4. The GeoWars example running in Melanee and the GeoWars Engine.
level executed by the game engine is shown at the bottom
of the figure. A video of the running tool can be found on
the Melanee homepage [
This GeoWars game example shows that it is possible to naturally implement sophisticated model execution environments using deep modeling tools such as Melanee. Melanee provides all the capabilities required for a model execution scenario including: 1) services for model query and manipulation, 2) services for accessing and manipulating graphical model representation definitions, 3) extensibility via a plugin framework supporting a general purpose programming language (Java) and 4) support for defining execution semantics through action languages and transformations. In areas where the Melanee API is not powerful enough the wellestablished technologies of the Eclipse Platform can be used as a fallback. The tools ongoing use for other projects allows missing features to be continuously discovered and added to the Melanee modeling environment and made available via the Melanee API.
The model execution scenario shown here can also be
implemented with traditional modeling technologies available
today. These “two-level” modeling technologies provide a type
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 [
From a conceptual point of view the deep modeling approach is much cleaner than model execution approaches based on the aforementioned traditional “two-level” modeling approach. In particular, it naturally includes all the classification 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 “twolevel” 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 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 is executed instead of a model instance. Deep modeling on the other hand supports the visualization of model instances during model execution and leaves the blueprint untouched.
To summarize, the example demonstrates that deep
modeling naturally supports the key features needed for model
execution which are: 1) the availability of additional
classification levels dedicated to executed model instances, 2) the
presentation of the current execution state of a system at the
instance level, 3) storing instance information of executed
models in the model itself and 4) level-agnostic action and
transformation languages to define execution semantics. All of
these features are available in today’s tools but as extensions
to, and workarounds on, the underlying modeling approach
which is not optimal for the tasks previously mentioned.
Unnatural extensions and workarounds increase the accidental
complexity [
Three different areas of work are relevant to the technology presented in this paper: deep modeling tools with model execution capabilities, standard modeling tools with built-in execution/simulation support and approaches to connect pure modeling tools with third party execution/simulation tools.
The only deep modeling tool besides Melanee which allows
execution of models is Metadepth [
In the two-level modeling space, Atom3 [
An approach for connecting modeling tools with external
execution capabilities is described by Fritzsche et. al. [
This work shows the advantages of deep modeling for supporting the simulation and execution of models. The prototype implementation shows that even the prototype deep modeling tools available today are already up to the task. In the paper we described the conceptual shortcomings of current modeling technologies and explained how deep modeling overcomes them. The shortcomings mainly revolve around the inability of traditional “two-level” modeling environments to naturally support more than one type and one instance level. The proposed deep modeling approach addresses this limitation through 1) the availability of additional classification levels dedicated to executed model instances, 2) the presentation of the current execution state of a system at the instance level, 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.