# A Model-Driven Approach for Conducting Simulation Experiments
## 3 Model-Driven Approach for Conducting Simulation Experiments
### Experiment Validation  
Before inputs are passed on to the next layer (\(M_{1}\)) to produce a concrete tool-independent experiment specification, the entered values have to be validated. The validator checks conformance with the chosen meta models, and thus, both structural checks and type checks are carried out. After each validation cycle, the validator gives immediate feedback to the user (see Figure 3) or the application, depending on which interface is used for the interaction. This step-by-step guidance supports inexperienced users, but also experienced users can benefit, as they do not have to concern themselves with the intricate details of simulation experiment specifications and, instead, can concentrate on important tasks such as output analysis and result interpretation. Figure 3: Screenshot of the experiment generation GUI. For a given meta model, and depending on the provided inputs, new input fields are generated. Validation errors are reported at the top right if the inputs do not conform to the meta model. In this example, a double value was entered for the number of replications, but an integer value was expected. Furthermore, the model path has not been specified yet. The generated experiment specifications (tool-independent and tool-specific) are displayed at the top left. Listing 2 shows a created JSON document at the layer \(M_{2}\). The document was validated according to the meta model example described above. The validation was unsuccessful due to the missing property modelPath and due to using the wrong data type for the input property replications. **Listing 2**: Simulation experiment filled according to the JSON meta model defined in Listing 1. Validation errors in the specification are marked red. ```
1{
2\"model\":{
3\"modelPath\":{
4},
5\"simulation\":{
6\"simulator\":\"SSA\",
7\"application\":100.4
8\"stopTime\":3000
9},
10...
11}
```  
**3.7**_Transformations and Bindings_  
The experiment meta models provide a general vocabulary that all modeling and simulation tools can refer to and communicate with. Meta models are therefore one way for improving the interoperability of modeling and simulation software. To go from an abstract experiment specification in a tool-independent format to executable code, the meta models have to be mapped to the syntax of actual modeling and simulation tools. During this transformation step, also differences in the terminology need to be resolved, e.g., the concept of the SSA has numerous implementations and is therefore known under different names such as the NextReactionMethod() or GibsonBruck() method. Often, one wants to generate code for a single tool and, thus, in a single language. However, it is not uncommon to run the simulations in one tool, collect the results, and then, run the analysis in another. Our transformation mechanism supports the combination of tools for simulation and analysis and, thus, allows generating a combination of two scripts in two different languages. Moreover, for certain experiment types, such as SA, the toolchain can be divided further (see Section 5.2). Another important feature of the transformations is their bidirectionality. This means that we can (backward) parse a concrete experiment specification of a specific language and represent it in the canonical format. From there, forward transformations can generate the same experiment for a different tool, or the experiment may be reused and adapted for a different purpose. Although it seems arduous to implement a transformation, it is far more efficient than connecting all pairs of tools individually. Moreover, once agreed upon in the community, the structure and vocabulary of a meta model are persistent and will rarely change, but rather be extended with new content, which will lead to some extensions in the transformations. It might also be beneficial to maintain transformations to distinct versions of the same M&S tool or to legacy systems for keeping older simulation experiments reproducible and, for example, for testing the tool itself.