# A Model-Driven Approach for Conducting Simulation Experiments
## 3 Model-Driven Approach for Conducting Simulation Experiments
### Meta Modeling Language  
At the highest level of abstraction in our framework, the meta meta model is situated. The meta meta model is essentially the language in which the meta models are specified. Meta meta models are usually self-referential (i.e., they define themselves). As a result, no further layers above \(M_{3}\) are required.  
A meta modeling language needs to encompass a means for comfortably developing a new meta model for a particular simulation domain and/or approach (base experiment) or  
Figure 2: Four-layered MDE architecture [37] for simulation experiments. The level of abstraction decreases from left to right. The experiment meta models (consisting of the base experiment and experiment type; see layer \(M_{2}\)), developed based on a meta modeling formalism (layer \(M_{3}\)), are at the heart of the approach. Based on \(M_{2}\), a tool-independent, exchangeable experiment specification can be generated (\(M_{1}\)), which then forms the basis to derive an executable, tool-specific specification (\(M_{0}\)) based on tool-specific mapping information. The generated experiment specification can then be automatically executed using a backend binding. Additional support components such as meta model repositories, GUIs, and validators assist users in conducting simulation experiments effectively, such that the remaining tasks concerning the user are entering or adapting information via the given interface and visualizing and interpreting the experiment results. The experiment generation pipeline may be used either as a stand-alone application or integrated with other support software, for example a workflow via a CLI.  
a particular type of simulation experiment (experiment type). We identified the following requirements:  
* Hierarchical structuring via components and nested input properties;
* Unique names for components and input properties;
* Standard data types such as Boolean, string, integer, real, as well as arrays;
* Enumeration of admissible values and specification of default values;
* Maps to associate a key property with one or more other properties;
* Alternative specifications for input properties;
* Constraints to define simple-type restrictions or the cardinality of an input property and, optionally, relations between multiple input properties.  
UML [38] is widely used for meta modeling software systems. UML class diagrams allow for a graphical notation that is intelligible to software developers, as well as domain experts. The expressiveness of UML class diagrams can be complemented with the Object Constraint Language (OCL) [41]. Another way of meta modeling is schema languages such as XML Schema [39] or JSON Schema [40]. They describe the structure of text documents and, therefore, directly ship with a data exchange format (XML or JSON) for the layer \(M_{1}\). They also encompass built-in means for defining simple constraints. For the detailed syntax and semantics of the constraint languages, we refer the reader to the OCL specification and the XML/JSON Schema specifications.  
We found that both UML and JSON Schema are appropriate ways of specifying the experiment meta models. With the workings of our model-driven approach in mind, we decided to use JSON Schema in the following. However, if conversions between the different meta modeling languages exist, the actual choice of formalism becomes less important.