## 5 Prototypical Validation and Case Study
### Variability4 TOSCA: An Extension of the TOSCA Standard
#### 5.1.2 Extending TOSCA for VDMM
In addition, the deployment model includes OR and XOR gateways. These gateways state which subtrees can be selected. In comparison, our deployment model does not require a tree-like structure, is not specialized for NFV, and does not include such gateways but complex conditions assigned to components and relations. [PERSON] et al. [66] presented a utility function to select a hosting stack for each business component based on key performance indicators. However, only the underlying hosting stack is variable, whereas in our concept, also business components are variable. Furthermore, we provide a formal metamodel along with algorithms to derive a deployment model. [PERSON] et al. [67] combined the functional and deployment variability concepts of Abstract Behavioural Specification (ABS) [68]. ABS is a specification for modeling the behavior of concurrent and distributed processes of software systems in a Java-like syntax. Following SPLE and delta-oriented programming [69; 70], functional variability is modeled using a feature model for a delta-oriented base model. Selected features are linked to deltas which are applied to the base model to derive the desired product. Deployment variability refers to execution costs of process statements and resource capacities of compute nodes. The concepts are combined by integrating the feature model for functional variability with a feature model for execution costs and another one for resource capacities. As a consequence, deltas patch the base model not only regarding functionality but also regarding execution costs and resource capacities. In a given example, a _MapReduce_[71] master uses this information to decide which and how many workers to use. This delta-oriented approach is fundamentally different from our approach to generate the desired outcome since they add new elements to a common base model while we remove elements from a model containing all possible elements. Furthermore, we focus on modeling conditional components and relations inside a deployment model which is not only restricted to compute nodes. [PERSON] et al. [43] presented a feature-oriented Domain-Specific Language (DSL) to be used in a model-driven engineering-based development process for configuring robot software architecture in the context of the BRICS robot application development process (RAP) [72]. The DSL enables to declaratively describe the deployment in a vendor-neutral manner. Thereby, a feature model describes features whose selection is used along with a resolution model to transform a template system model into the desired architecture. In comparison to our work, they focused on robotics, while we do not restrict to any domain. Furthermore, our approach is not restricted to a specific DSL. [PERSON] et al. [73] presented a method to transform a deployment model depending on the context by applying graph transformations. Thereby, context refers to the state and structure of the application. Management plans are then automatically generated and executed to provision and manage the application. In comparison, we do not apply graph transformations but use conditional elements and refer, for example, to costs or scalability as context. Terraform and Ansible support conditional components and relations. In the following, we briefly discuss their concepts since we mentioned them previously. In Terraform, the _count_ attribute [74] can be used in _resource_ or _module blocks_ to model conditional components. A corresponding numeric expression sets the value of _count_ either to zero or one. This expression might be based on user-provided inputs. Relations between components are modeled using the _depends_ on attribute of a component or implicitly by accessing attributes of other resources. However, conditions cannot be assigned to relations. They are present as long as their source component is. This restriction does not apply to our concept.