A DiVA system can be seen as the evolving composition of a set of co-existing, co-dependent configurations, where the number of possible configurations grows exponentially with the number of variability dimensions.

The figure "DiVA @ runtime" referred to in "Related Content" presents an overview of a DiVA system at runtime. In the lower part of the figure, a running DiVA system is depicted alongside its causally connected adaptation model. The causal connection between the running system and its adaptation model indicates that the system can be managed during execution by manipulating its model. This will be achieved in WP3 by using meta-modelling languages (such as Kermeta) which allow the definition of the semantics of meta-models and the execution of a corresponding model. The execution of this model will eventually trigger reconfiguration in the running DiVA system. In DiVA, the adaptation model provides manipulation and reconfiguration of crosscutting features by means of aspect-oriented techniques. The causal connection between the model and the running system deals with the adaptive parts of the system, not its basic functionality. The basic functionality of the system is represented as a grey-box component, referred to as “Base”. The running system and the platform upon which it executes are expected to have a set of APIs that the adaptive part of the system can use in order to monitor the system and do the required adaptation actions.

The adaptation layer may choose to adapt based on changes in context and QoS requirements. The adaptation layer evaluates available adaptation alternatives and selects the most appropriate variant based on context information and QoS requirements, where the variants are represented with the base model and the aspects models specifying variability dimensions. There are two categories of context information: Social context information such as information regarding noise, light and geographical position and System context such as information regarding network bandwidth, memory and CPU. The adaptation layer uses sensors to monitor and receive context information. Actuators are used to manipulate and reconfigure the running application according to the context and QoS changes.

The full range of possible system variants is defined by the viable combinations of the Base and aspect models. Such combinations will be defined as composition policies. The policies will also reflect the types of incompatibilities and ways of their possible resolutions (for instance, Y cannot be composed with Base, but this incompatibility is resolved if X is composed with Base before Y). In addition, preceding their instantiation and deployment both the Base and aspect models may encompass unresolved variation points (e.g., unresolved parameters, optional elements, possible specializations etc.). This is indicated in Figure "DiVA @ runtime" by drawing the Base and aspect models using dotted lines.  Employing these mechanisms to implicitly represent the full set of possible variants DiVA will provide a novel solution to tackle the problem of combinatorial explosion. The full set of possible variants is not derived beforehand; instead required variants are derived dynamically through composition.

To avoid deployment of incorrect configurations, dependency rules are specified for each variability dimension (e.g., using assumption/guarantee specifications), where the rules themselves can be dynamically updated. During adaptation a variant is derived by resolving variation points. This is an automated process based on common product line variability resolution mechanisms. The relevant resolution rules are triggered based on the QoS and context information received. Then a proper set of variability dimensions is selected and variation points of these are resolved in a similar way as for the Base. The set of models is then composed and this new configuration is mapped and deployed.

The adaptation layer also derives a suitable migration path from the existing variant to the new one. This involves an analysis of differences between the original and the new configuration, and a planning of the migration. To make the adaptation process more efficient, the runtime system can cache commonly used configurations avoiding the process of configuration, instantiation, composition and mapping when one of these are selected. The system can also cache the most recently used configurations according to some algorithm.