2.2 Software Product Line Engineering
2.2.2 Feature Models
A set of features describes an increment in product functionality constituting a distinctive characteristic of a software product and, therefore, provide a notion for specifying and distinguishing the members of a product line [AK09]. In general, not all combinations of features lead to a meaningful or usable product. Therefore, the commonalities and variability associations between features are specified via explicit constraints. Every product configuration of an SPL consists of a distinct combination of features, which has to be valid w.r.t. the constraint specification.
Feature models are used to describe the problem space, i.e. the variability within an SPL. The configuration space, i.e., every valid product configuration, is directly defined by the problem space. The size of the problem space depends on the amount of features and constraints defined in a feature model. For instance, if the feature model does not contain any constraints to restrict the configuration space, the size of the configuration space corresponds to 2|number of features| configurations. In a configuration, a feature is bound to one of the two different states
• selected – the feature is bound to be included into the resulting product, or
• deselected – the feature is bound to be excluded from the resulting product.
Example 2.13 (Software Features of a Mobile Device).
For instance, considering a smartphone, a software feature may be the driver for the integrated WLAN chip, a protocol, e.g., the border gateway protocol, or an application, e.g., Skype for Voice over IP (VoIP) calls. To make a VoIP call, an Internet connection has to be active via the border gateway protocol via a WLAN access point. These feature constraints are specified in a feature model. Thus, if a VoIP call is taken, the featuresVoIP, border gateway protocoland WLAN driverhave to be selected to be part of the product configuration.
Feature model diagrams are a common graphical notation to specify such charac- teristics of a feature and variability constraints amongst different features.
Feature Model Diagrams. Feature model diagrams are used to describe the variable and common parts within an SPL. This graphical representation of variability depicts a structured, hierarchical overview of dependencies, restriction, and constraints between features [HST+08]. For that purpose graphical notations have been defined such that a broader audience of stakeholders, e.g., developers,
&
als
managers, and customers, are able to interpret and understand the variability within an SPL.
Feature model diagrams are introduced by Kang et al. in [KCH+90] as a part
of the feature-oriented domain analysis. They are usually represented as a hier- archical tree to specify dependencies and constraints between features. In feature model diagrams features not only represent user-visible distinctive functional as- pects of an SPL, but may furthermore be annotated with non-functional properties, e.g., cost or reliability. The features are organized as tree-nodes and tree-edges to specify the dependencies and constraints between the features. The hierar- chical ordering of a tree structure allows for a grouping of sibling features as a parent-child-group to constitute the different kinds of variability constraints.
A multitude of competitive graphical representations of feature model dia- grams exists within the SPL community. In the remainder of this thesis, a graph- ical notation according to [CE00] is adopted. Figure2.8provides an overview of the graphical representation for the different kinds of tree edges and node groups used in this thesis. Edges connect parent nodes and child nodes, thus repre-
Parent Feature
Child Feature
(a) Mandatory Feature
Parent Feature Child Feature (b) Optional Feature Parent Feature Child Featuren ... Child Feature1 (c) Alternative Group Parent Feature Child Featuren ... Child Feature1 (d) Or-Group
Figure 2.8:Syntactical Constructs of Feature Model Diagrams
senting hierarchical decomposition relations between the corresponding parent feature and its child feature(s). This hierarchical decomposition of features into sub features is used to impose constraints between the involved features on the validity of product configurations. Hence, the selection of a child feature into a product configuration implies the presence of the parent feature within the same configuration [Bat05].
A structurally well-formed feature model has to follow several modalities for de- composing features into groups of sub features to impose further constraints on a valid configuration. The four kinds of feature decompositions as depicted in Figure2.8are to be interpreted as follows.
• A mandatory feature is always part of the product configuration if its parent feature is selected. The presence of the parent feature implies the selection of all of its mandatory child features. Figure 2.8(a) depicts the graphical notation of a mandatory feature.
I ntr od uction F und ament Featurex Featurey
(a) Binary Require Constraint
Featurex Featurey
(b) Binary Exclude Constraint
Figure 2.9:Binary Cross-Tree Constraints between Features
• An optional feature may or may not be selected into product configurations if its parent feature is selected. The presence of the parent feature offers the possibility to select or not select any of its optional child features. Fig- ure2.8(b)depicts the graphical notation of an optional feature.
• From the features contained in an alternative-group exactly one feature must be selected into a product configuration if the parent of the group is selected. The presence of the parent feature, therefore, implies the selection of exactly one of its child features. Figure 2.8(c) depicts the graphical notation of an alternative-group.
• From the features contained in an or-group at least one feature must be selected into a product configuration if the parent of the group is selected. The presence of the parent feature implies the selection of at least one of its or-related child features. Figure 2.8(d) depicts the graphical notation of an or-group.
The feature model diagram constructs introduced above are not yet expressive enough to specify the inherent variability of SPLs. Thus, further constructs to ex- press additional constraints among features have to be provided [SHT06]. Those constraints are often represented as additional propositional formulas over fea- tures arbitrarily crosscutting the feature tree [BSRC10]. Schobbens et al. [SHT06] discussed that a directed acyclic graph structure for implication dependencies among feature nodes is at least to be supported by a feature model language in or- der to be conceptually complete for an SPL. Therefore, the introduced tree-struc- ture has to be extended with binary require and exclude cross-tree constraints as shown in Figure2.9. The meaning of those edges is given as follows.
• If a feature requires another feature then the required feature must also be selected into the configuration if the requiring feature is selected.
• If a feature excludes another feature then both features may never be part of the same configuration.
The constraint relations introduced above are sufficient to model the variability usually apparent in mobile devices. A feature model is structurally well-formed if it is a composition of the introduced group-constraints mandatory, optional, or, and alternative as well as the cross-tree constraints require and exclude.
&
als
Figure 2.10 depicts an excerpt of the Google Nexus SPL3 for mobile devices.
The feature model organizes the supported features in a tree-like hierarchy. For
mandatory alternative or optional require exclude EDGE Nexus Connectivity Display Driver Android OS Sensors GSM 4,7" 7" V4.4 V4.3 v4.2 GPS Front Camera UMTS HSPA+ LTE Cellular WLAN Accelerometer Light Gyroscope Barometer Environmental Bluetooth
HW Extension Rear Camera
10"
NFC
Wireless Loading
Figure 2.10:Google Nexus SPL
instance, the Connectivity feature of the SPL comprises WLAN, Cellular and Bluetooth as direct child features. Depending on its modality, a single child feature is either mandatory for its parent feature, or it is optional. For example, theConnectivityfeature constitute mandatory core functionality to be part of every variant of a mobile device, whereas the HW Extension feature with its child features is optional, e.g., not all products of the Nexus SPL necessarily include the features NFC, Rear Camera, and Wireless Loading. However, if a child-feature is selected for a product then the parent feature must also be a part of the feature selection, e.g., ifNFCis selected thenHW Extensionhas to be selected additionally.
A Nexus product is able to support a multitude of different connection types. Every product supports the mandatory features WLAN and Bluetooth, whereas the child features of the optional featureCellularconstitute an or-group. There- fore, whenever a Cellular connection is a required feature for the product configuration at least one and up to every of the features within an or-group have to be selected.
The software of every mobile device has to support a display, thus Display is a mandatory feature. In addition to that, features are collectable in an alter- native-group. For a display, it is sufficient to support one category of displays 3http://www.google.de/intl/ALL/nexus
I ntr od uction F und ament EDGE Nexus Connectivity Display Driver Android OS Sensors GSM 4,7" 7" V4.4 V4.3 v4.2 GPS Front Camera UMTS HSPA+ LTE Cellular WLAN Accelerometer Light Gyroscope Barometer Environmental Bluetooth
HW Extension Rear Camera
10"
NFC
Wireless Loading
(a) Valid Configuration
EDGE Nexus Connectivity Display Driver Android OS Sensors GSM 4,7" 7" V4.4 V4.3 v4.2 GPS Front Camera UMTS HSPA+ LTE Cellular WLAN Accelerometer Light Gyroscope Barometer Environmental Bluetooth
HW Extension Rear Camera
10"
NFC
Wireless Loading
(b) Invalid Configuration
Figure 2.11:Product Configuration Google Nexus 4
exclusively, e.g., either a 4.7”, a 7”, or a 10” display. Therefore, the display features are collected within an alternative-group, which implies the selection of exactly one of those group features.
Finally, cross-tree edges denote feature dependencies that crosscut hierarchies, e.g., Rear Camerarequires aLightsensor for an automatic filter correction and Barometerrequires the most recent Android operating systemv4.4. In addition to require edges, features may be incompatible, e.g., due to space restrictions. For example, Wireless Loading is never used in a device with large displays such as7”and10”.
Figure 2.11 depicts two variants of a product configuration for the stake- holder selection of the features 4.7”, EDGE, GSM, UMTS, HSPA+, v4.2, NFC, and Rear Camera. Features that are selected for the final product are highlighted in light-grey and have a check-mark, whereas deselected features are highlighted in a dark-grey and have a cross-mark. A valid product configuration is de- picted in Figure2.11(a), in which the selection of the features is completed w.r.t. the constraints imposed by the feature model. For example, sinceRear Camera is required by the stakeholder selection, theLightsensor has to be selected to satisfy the variability constraints of the Nexus SPL. In contrast to that depicts Figure 2.11(b)an invalid configuration of the Nexus SPL. In this example the stakeholder additionally requires theLightsensor to be excluded from the final product configuration, e.g., to reduce production costs. However, this require- ment contradicts the selectionRear Camera of the stakeholder, which requires theLightsensor. Therefore, it is not possible to derive a valid product config- uration according to the requirements of the stakeholder.
Feature models may not only be used to specify the static variability of an SPL but are also capable to specify variability of an adaptive system. The concept of
&
als
dynamic software product lines is introduced in the next section as an approach to manage variability dynamically at runtime.