## 2 Background
### Dynamic Software Product Lines in FamiWare  
Dynamic software product lines (DSPLs) [6; 7] represent an emerging field that is producing software products capable of adapting to requirements that change at runtime. A product is defined as a unique composition of features from a set of common and variable features (_i.e._, variants), where some of the variable features may vary at runtime (_i.e._, variation points). Therefore, the products have the capacity to reconfigure themselves by binding variation points at runtime, several times, in accordance with the changes in the environment. DSPLs use a variability model to specify the variation points that can be dynamically modified. In particular, in our approach, the use of non-standard languages or formalisms is avoided, and we use the Common Variability Language (CVL) [10] proposed as the standard by the Object Management Group (OMG) [11]. CVL is a domain-independent language for specifying and resolving variability. The CVL variability models allow modeling the variability separately from the base model, but both the variability and the base models are connected and can be managed using the same tool (see Figure 1). In CVL, VSpecs (Variation Specifications) are tree structures representing choices or elements (called \"features\" in most SPL terminologies) and can include logical constraints defined in a subset of the Object Constraint Language (OCL) [12]. The main characteristics of CVL that we use to model the FamiWare variability model are shown in Figure 1. In DSPLs, a variability model configuration is the set of features currently bound at runtime that represents a particular product of the SPL. In this way, dynamic reconfiguration is defined in terms of replacing the current variability model configuration with a new configuration in which the variation points have been re-bound to adapt them to a context change. Therefore, using the CVL approach, we automatically generate both the initial configuration and also the successive adapted configurations. Figure 1: FamiWare variability model. As shown in Figure 1, the inherent heterogeneity and the variability of WSNs are modeled in FamiWare using CVL variability models (_i.e._, the VSpec trees). FamiWare proposes the customization of the piece of software related to the middleware platform that is deployed in each device of the WSN according to: (1) the device features (device [1..*] feature in Figure 1 with a 1..* cardinality to represent the different devices in the system); (2) the application requirements (application feature); and (3) the global characteristics of the network used to connect the different devices (network feature). Each device is represented, among other features, by its type (choice DeviceType) and the FamiWare services that need to be instantiated in that particular device according to the application's requirements and the network's characteristics (service choice). Regarding their types, devices can be of high capacity (such as desktop computers or smartphones) or they can be sensors (sensor choice). The sensors, among other things, have one or more sensor units (choice SensorUnit) (e.g., accelerometer, distance or movement sensors). For FamiWare, the variability is decided for each device, so the FamiWare services instantiated in each device can be different. Among other services, FamiWare is composed of three optional services: monitoring, context awareness and reconfiguration. The FamiWare monitoring service observes different types of contexts (e.g., memory consumption, battery level, status of network connection). These contexts are optional choices that will be selected or not in a particular configuration depending on the capacities of the sensor nodes. The context awareness service receives events with the monitored data (modeled as CVL variables in Figure 1) and checks whether these data imply that a context change has occurred (e.g., the memory consumption of a sensor is very high).