## 5 Prototypical Validation and Case Study
### Variability4 TOSCA: An Extension of the TOSCA Standard
#### 5.1.2 Extending TOSCA for VDMM
[58] presented the concept of using a _Cloud Knowledge Model_ to automatically select features of a feature model representing a cloud provider which finally results in the deployment of an application. Thereby, the Cloud Knowledge Model is an abstract view on available cloud offerings and is mapped to the cloud provider feature models. The selected features have assets such as configuration files or deployment scripts, which are then executed. In comparison, we generate a declarative deployment model based on conditional elements which is then executed. [PERSON] et al. [59] proposed a framework for adaptive real-time applications for OSGi. Their deployment model consists of components and communication relations and allows to enable or disable components based on a Boolean flag. In comparison, we explicitly model the conditions under which components and relations are present. Furthermore, our model is not focused on OSGi, allows to model any relations between components, and includes the management of hosting components. [PERSON] et al. [60] presented a middleware for a self-configuring automotive control system. Software components are configured by policies that are loaded into the components. These policies execute actions based on information monitored by the middleware. In comparison, they assigned conditions to actions that should be triggered to adapt the application, whereas we assign conditions to components and relations to derive a model of the desired application. [PERSON] et al. [61] presented a goal-driven approach for self-adaptive systems for Internet of Things (IoT). Their framework is based on MAPE-K [62], which includesmonitoring, analyzing, planning, and executing components along with a knowledge base. For example, a user defines the goal to adjust the light level in a meeting room. A deployment planner generates a topology by mapping required software components to existing hardware components while considering expected and current workload. In contrast, they expected that hardware components already exist, whereas we are able to provision, e.g., virtual machines. Furthermore, they only simulated the deployment inside their prototype, whereas we actually deployed our motivating scenario. [PERSON] et al. [63] presented an approach for context-aware deployments of component-based applications on top of existing deployment technologies by using a deployment model that is platform independent. The deployment model consists of components and communication relations. Components are semantically described by types that define their interface, properties, implementations, component dependencies, and placement constraints regarding hardware. Software components are automatically matched to existing hardware components during deployment. Thereby, properties, implementations, dependencies, and placement constraints may have conditions on the context. Furthermore, the components and relations can have conditions assigned which specify if the component or relation is present in the deployment. They also detect inconsistencies such as multiple assignments of the same property or missing connection targets already during design time [64], whereas we check for inconsistencies during the deployment phase. However, they focus on software components and dynamic placement of software components to hardware components and expect that hardware components already exist. In contrast, our deployment model also allows to model, e.g., hardware components that should be automatically provisioned. Furthermore, our deployment model is based on EDMM [1] and, therefore, can be mapped to TOSCA, Terraform, Ansible, Kubernetes, Docker Compose, and more deployment technologies [1; 11]. [PERSON] et al. [65] integrated feature models into a deployment model specialized for Network Function Virtualization (NFV) infrastructures. They represented the deployment model as a tree whose nodes are, for example, virtual compute nodes or virtual storage, and relations, such as composition, allocation, and connection.