Self-Adaptive Software Systems (SAS) are required to operate under the influence of a continuous changing context without interruption. This is especially true for highly mobile resource constraint systems, e.g., smartphones, tablets or notebooks. Contextual changes usually imply changes on the requirements imposed on the running system. Such scenarios motivate the adaptation of systems that react to external variations by adapting themselves dynamically at runtime in order to uphold certain functionality and service qualities.
Dynamic Software Product Lines (DSPLs) represent one possibility to handle the inherent changes emerging at runtime of a system [HSSF06]. DSPLs exploit the concepts of static SPL engineering. A traditional SPL product implements a static behavior and is not reconfigurable at runtime. However, DSPLs rely on the same concepts as SPLs but are intended to handle variability at runtime dy- namically. The DSPL development mainly intends to produce configurable prod- ucts [LK06] whose autonomy allows to reconfigure themselves and benefit from constant updating.
“Dynamic software product lines extend existing product line engi- neering approaches by moving their capabilities to runtime, helping to ensure that system adaptations lead to desirable properties.” [HPS12]
Thus, a DSPL supports feature (de-)selection dynamically at runtime, depending on the requirements imposed by a contextual situation.
Static and Dynamic Aspects. The dynamic character of DSPLs as well as the alignment to classic SPLs make a DSPL based adaptation a suitable candidate to manage dynamic systems such as mobile devices. On the one hand, mobile devices are representative examples for SPLs as shown in the case of the previ- ously introduced Nexus SPL for mobile devices. On the other hand, a user-visible aspect, quality or characteristic of a software system, i.e., the definition of a feature according to [KCH+90], represents exactly those properties of a mobile device, which are important to a user. However, the scope of a feature differs slightly in an SPL and a DSPL.
Features in an SPL refer to static characteristics of the software or system, i.e., the feature selection for a software product does not change once the configura- tion process is finished. Static features are selected during a configuration process at design time. The selection of static features depends on the requirements stated by a stakeholder, e.g., the user requires a navigation system, or on the restrictions imposed by the target domain, e.g., the hardware capabilities of a mobile device. Therefore, the general definition of a feature has to be refined to refer to the static features of an SPL.
I ntr od uction F und ament
Definition 2.1 (Static Feature). A feature is a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or system [KCH+90]. A static
feature is selected or deselected from a software product at design time.
In contrast to the static features of an SPL, at least features have to be dynamic in a DSPL, due to the continuous reconfigurations at runtime. Dynamic features have to be selected and deselected from a runtime configuration of the DSPL continuously, depending on the requirements stated by the context of a mobile device. Thus, dynamic features are selected during a reconfiguration process at runtime and not at design time. Therefore, the general definition of a feature has to be refined to refer to the dynamic features of a DSPL.
Definition 2.2 (Dynamic Feature). Dynamic features satisfy requirements stated by a contextual situation and are continuously reconfigurable at runtime.
Mobile devices are composed of static features as well as dynamic features. In a first step, the mobile device has to be configured statically at design time like a traditional SPL, due to the stakeholder requirements and capabilities of the target device. After the software product configuration is deployed on a device it becomes a DSPL, due to the requirements of a constantly changing context. This implies two aspects
• the configured SPL product still has to contain open variability, and
• the variability specification of SPLs and DSPLs are different.
If the configured software product does not contain any variability, e.g., features that may not be selected or deselected at runtime, the product is static. However, this contradicts the key aspect of DSPLs of a dynamically reconfigurable system at runtime.
The different scope of an SPL and DSPL results in different views on the vari- ability aspects [SvGB05]. An SPL is specified according to the static constraints imposed by software or hardware aspects, whereas a DSPL is specified accord- ing to dynamic aspects of the software. An SPL has to deal with issues such as the compatibility of features with the hardware capabilities of the target platform, e.g., a WLAN driver must not be deployed on a device without a WLAN hard- ware chip. In contrast to that, a DSPL has to deal with the dynamic changes in a software configuration, i.e., selection and deselection of features at runtime of the software. Thus, every feature in a DSPL has to be supported by the device, on which the DSPL is deployed. Additionally, the variability constraints are differ- ent for a static and a dynamic specification. For example, WLAN is a mandatory feature in the Nexus SPL, whereas WLAN may be activated or deactivated at runtime. Thus, WLAN is an optional feature in the respective DSPL.
Based on the previously introduced Nexus SPL the following example intro- duces an excerpt of a respective DSPL.
&
als
Example 2.15 (Nexus DSPL - Runtime Variability Specification).
Figure 2.12depicts a case study of a DSPL for a Google Nexus SPL [SOS+12, SLR13]. The DSPL is used as a running example throughout the remainder of this thesis. In contrast to the Nexus SPL example depicted in Figure2.10 the
Infrastructure mandatory alternative or optional require exclude Nexus DSPL Connectivity Routing Application Sensors Ad Hoc BGP LAR Phone Call Game Hub Navigation GPS Gyroscope WLAN Ad Hoc WLAN AP Cellular Cellular Call VoIP
Figure 2.12:Feature Model Nexus DSPL
DSPL focuses on the variability at runtime. Although there are some features in both specifications, these features have different constraint relations due to their static and dynamic scope. For example, GPSas a static feature in Figure 2.10is a mandatory feature and therefore deployed on every device of the Nexus SPL. In contrast to that the dynamicGPSfeature in Figure2.12is reconfigurable since it is in an or-group with the sibling featureGyroscope. Another example for a static and dynamic feature isWLAN. Within the Nexus SPL,WLANis a mandatory feature. However, there are two dynamic features in the DSPL specification, which depend on the WLAN driver, e.g., WLAN Ad Hoc uses the WLAN driver in an ad hoc mode and WLAN AP uses the WLAN driver to connect to an Access Point (AP).
The remaining variability at runtime is specified as follows. TheApplication feature of the Nexus DSPL comprisesNavigation,Game HubandPhone Callas direct sub features. A phone call is executable in two possible ways
• via VoIP. A Voice over IP (VoIP) call is always executable. Since Co- nnectivityis a mandatory feature, the device provides a connection that is usable byVoIP.
• viaCellular network. A standard phone call is taken via a cellular net- work provider. Therefore, this feature depends on an Infrastructure based connection to aCellulartower.
Thus, technically it is possible that several phone calls may be executed via both features in parallel, e.g., putting a call on hold.
I ntr od uction F und
ament The basic Connectivity feature constitutes a mandatory core functionality and has to be part of every smartphone variant, whereas theSensorsfeature is optional and may be deactivated at runtime. Depending on the environment, different Routingprotocols have to be used to provide an efficient connection. In the mobile device case study, there is an alternative-group of two different routing protocols
• BGP(Border Gateway Protocol) [RLH06] is an Internet Protocol (IP) based routing protocol, which is commonly used in infrastructure based net- works like the Internet. Hence, it is not compatible with ad hoc connec- tions.
• LAR(Location Aided Routing) [KV00] is a routing protocol for wireless ad hoc networks that uses the geographic location of the devices, provided by a GPS sensor. Instead of flooding the message to all devices in the neighborhood, the message is directed in a geographic direction. LAR cannot operate without an activeGPSsensor.
Thus, both routing protocols depend on a different connectivity configuration and may never be active at the same time.
Reconfiguration at Runtime. A reconfiguration adapts a running soft- ware system dynamically from one product configuration to another product con- figuration. As a result, a different product configuration becomes active and the behavior of the software system changes according to the new specifications. The new product configuration may be adapted into yet another product configura- tion and so forth [MCP13]. In the remainder of this thesis, I refer to the active product configuration that is about to be adapted as the current configuration and the product obtained after the reconfiguration as the target configuration.
Example 2.16 (Continuous Reconfiguration).
Infrastructure Nexus DSPL Connectivity Routing Application Sensors Ad Hoc BGP LAR Phone Call Game Hub Navigation GPS Gyroscope WLAN Ad Hoc WLAN AP Cellular Cellular VoIP Infrastructure Nexus DSPL Connectivity Routing Application Sensors Ad Hoc BGP LAR Phone Call Game Hub Navigation GPS Gyroscope WLAN Ad Hoc WLAN AP Cellular Cellular VoIP
...
Current Configuration Target Configuration
Figure 2.13:DSPL Reconfiguration Sequence
Figure 2.13 depicts an excerpt of a reconfiguration sequence for a mobile de- vice. The two depicted configurations differ slightly in their set of selected and deselected features. The left-hand side configuration provides the functionality to execute a phone call via aCellularnetwork connection. After the reconfigu- ration, the device executes phone calls viaVoIPby using anAd Hocconnection.
&
als
The left-hand side configuration in Figure 2.13 depicts the current configu- ration of the device. Due to a change in the context of the device, e.g., the cellular network broke down, the device has to be reconfigured to the target configuration on the right-hand side configuration in Figure2.13.
For every performed reconfiguration the variability specification, i.e., the fea- ture model, has to be analyzed. The contextual requirements and the specified feature constraints have to be solved to derive a new target configuration [BHS12, MBJ09]. Although this process is automatable by so called solvers, the process of deriving a target configuration is a difficult computational problem [Coo71].
The degree of difficulty for deriving a target configuration is directly related to the number of steps required by a solver to perform a satisfiability check of all imposed constraints and requirements. Therefore, the complexity of a variability specification grows with the number of features and constraints [MWC09]. The more complex the specification, the greater the number of required steps. For all known solving algorithms, the amount of executed steps grows exponential in the worst case. Especially on a mobile device, such a worst case reconfiguration be- havior has to be reduced to a minimum w.r.t. its processing time and its resource consumption [MWC09].