## 5 Prototypical Validation and Case Study
### Variability4 TOSCA: An Extension of the TOSCA Standard
#### 5.1.2 Extending TOSCA for VDMM
The prototype does not support the inheritance of the TOSCA type system as it is not required for our approach and expects that hosting relations are named \"host\" as commonly done in the TOSCA specification. The source code and documentation can be found in our repository. ### Case Study Based on the Prototype

This section presents a detailed case study in which we apply the Variable Deployment Modeling Method presented in Section 3 to the motivating scenario introduced in Section 2. A step-by-step guide, including corresponding TOSCA definitions, is provided in our repository. In Step  of our method, we first identify that we require a development variant and a production variant. With costs and simple installation in mind, the development variant deploys all components on a single virtual machine on a private OpenStack instance. For the database, we use a lightweight SQLite3 database because it is easier to manage compared to MySQL. Since an unexpected workload is expected during production, the web component and the database are deployed on GCP in the production variant. Figure 5: System architecture of a Variability4 TOSCA Deployment System. To create the Variability4 TOSCA model in Step, we start with creating the development variant, i.e., we model all components and relations as shown in Figure 1 on the left. To integrate the production variant, the components \"Prod Database\", \"Prod DBMS\" and \"Prod Runtime\" are added along with their relations. At this stage, the web component has two hosting relations and two database connections. Therefore, we define the Variability Input \"mode\" and assign a condition that checks if \"mode\" equals \"dev\" to the components and relations that are only present in the development variant (see Listing 1). Analogously, we assign a condition checking if \"mode\" equals \"prod\" to the components and relations that are only present in the production variant. Since the component \"Web Component\" should always be present, it does not have any conditions assigned. The final Variability4 TOSCA model is shown in Figure 3. Hereby, the manual modeling phase of the method is completed. In the execution phase, we want to deploy the application in the development variant. Therefore, we import the created Variability4 TOSCA model to OpenTOSCA Vintner and assign the Variability Input \"mode\" the value \"dev\" in Step. The Variability Resolver receives the model and our input in Step. Since only the conditions that check if \"mode\" equals \"dev\" evaluates to true, the resolver removes all components and relations whose conditions check for \"prod\". The resulting standard-compliant TOSCA model corresponds to the development variant given in Figure 1 on the left. In the final Step, we select xOpera or Unfurl as the TOSCA orchestrator to execute the deployment in a fully automated manner. This case study can be used to evaluate different aspects of our presented approach. First, the motivating scenario introduced in Section 2 can be realized using Variability4 TOSCA, which shows that our extension of the TOSCA standard provides all required features for this kind of scenario. Moreover, the case study also demonstrates that our prototypical implementation OpenTOSCA Vintner is able to automatically transform Variability4 TOSCA models for a given set of provided Variability Inputs into a standard-compliant TOSCA model that can be executed by unmodified TOSCA orchestrators, in this case, xOpera or Unfurl. Thus, these results pave the way for executing different deployment variants in practice on top of existing toolchains. ### Benchmark Evaluation of the Variability Resolver Prototype

To further evaluate our concept and prototype, we ran benchmark tests whose results are given in Table 1. The to-be-tested Topology Templates are generated based on a seed. For example, a seed of 1000 generates the 1000 Node Templates, which have a condition assigned that evaluates to true.