The SPL engineering process consists of two main activities: (i) domain engineer- ing and (ii) application engineering [CN01,vSR07,PBv05,WL99].
&
als
• Domain Engineering. This process is responsible for creating a repository of reusable software assets, i.e., software features, and identifying common- alities and variability of an SPL. The domain engineering process, depicted in the upper part of Figure2.5, consists of five activities: product manage- ment, domain requirement engineering, domain design, domain realization, and domain testing. This engineering process results in a software reposi- tory that contains parts of the system in the form of reusable assets, such as requirements, design artifacts, implemented components, tests, etc.
• Application Engineering. The application engineering process, depicted in the lower part of Figure 2.5, deals with the configuration of each individual software product. The process consists of four activities: application re- quirement engineering, application design, application realization, and ap- plication testing. The application engineering results in a software product that is built by reusing assets developed during the domain engineering.
D om ain En gi ne erin g A pp lic at io n E ng in ee ri ng Domain Requirements Engineering Domain Realisation Domain Testing Domain Design Application Requirements Engineering Application Realisation Application Testing
Application 1 – Artefacts incl. Variability Model
Architecture Components Tests
Requirements
Domain Artefacts incl. Variability Model Product
Management
Application N – Artefacts incl. Variability Model Application
Design
Requirements Architecture Components Tests
Figure 2.5:Software Product Line Engineering Approach [PBv05]
The expected positive effects of such an approach are an optimization of the main- tenance of software, the overall software quality, development costs and time-to- market of individual products of the SPL [Bos01,vSR07]. For a detailed introduc- tion into the engineering process of SPLs, I refer to [PBv05].
Example 2.10 (Smartphone Products).
Figure 2.6 shows two different products of the android operating system as a software product line. The products share common elements, which are aggregated in the building blockStock Android. However, the products differ
I ntr od uction F und ament St o ck A n do ir d Se n se St o ck A n do ir d To uc h w iz
Figure 2.6:Two Product Variations of a Smartphone
in their user interface. The software product on the left-hand side usesTouchwiz from Samsung, whereas the product on the right-hand side uses theHTC Sense as a graphical user interface.
This example illustrates the main concept of a product line: the identification of commonality and variability between different products of a software product line. These common and variable characteristics of an SPL are represented as features.
“[. . . a feature is] a prominent or distinctive user-visible aspect, qual- ity, or characteristic of a software system or systems.” [KCH+90].
Thus, features provide the means to customize, i.e. configure, a specific software product at design time to the needs and requirements of a stakeholder.
Example 2.11 (Software Features of a Mobile Device).
Considering mobile devices, software features are the driver for the integrated WLAN chip, a protocol, such as the border gateway protocol, or an application, such as the navigation system Google Maps.
To derive a final software product, the SPL has to be configured. The process of configuration results in a product configuration that is tailored to the custom needs of a stakeholder.
“A product configuration is a collection of parameterized feature assignments specifying a customized product of an SPL.” [Loc12]
Thus, a configured product is a customized instance of an SPL. The configuration of a resulting software product consists of features that are selected according to certain constraints imposed by the SPL [CE00]. Therefore, every feature is either bound to be included into the resulting product, i.e., selected, or it is bound to be excluded from the resulting product, i.e., deselected. Once the configuration process of a software product is finished and the product is deployed, the resulting product is static and fixed regarding the selection of features.
Figure2.7shows an abstract illustration of a configuration of a smartphone SPL. The model on the left side represents the variability specification. During the con- figuration process, features of the SPL are explicitly selected (features with a check mark) and deselected (feature with a cross mark) to derive the final smartphone product configuration.
A key artifact to configure a product of an SPL is the domain variability model. It defines the variability of the SPL and introduces dependency relations between
& als f1 f2 f5 f3 f4 f6 f7 f1 f2 f5 f3 f4 f6 f7
Variability Specification Configuration Product
Figure 2.7:Configuration of a Product Line
different features. Thus, variability denotes the ability of a software system to be adapted, customized, or configured for a specific application scenario or to the custom needs of a stakeholder.
Example 2.12 (Product Configuration of a Mobile Device SPL).
The Android operating system from Google supports various heterogeneous devices. The mobile devices Google Nexus 41and Google Nexus 72require two different product configurations because of their individual hardware charac- teristics. The Nexus 4 is a smartphone with
• a 4.7” display,
• a front-facing camera,
• a rear camera,
• GPS,
• a light-sensor,
• and wireless loading.
In contrast to that, the Nexus 7 tablet has the following characteristics
• a 7” display,
• a front-facing camera,
• and GPS.
Although both devices use Android 4.2 as operating system, they use different product variants of the operating system. Both devices require the features for a front-facing camera and GPS, i.e., the necessary drivers have to be integrated into the system kernel. Therefore, every constraint that is related to these fea- tures, e.g., navigation system requires GPS, is satisfiable and applications such as Google Maps are supported by both devices.
Both devices differ in their capabilities. The Nexus 7 is missing a rear camera, light-sensors, and wireless loading. Therefore, the according software features are not included into the product variation that is specific for the Nexus 7. This restricts the Nexus 7 in its support for applications. Light-sensitive applications,
1http://www.google.de/intl/ALL/nexus/4/specs/ 2http://www.google.de/intl/ALL/nexus/7/specs/
I ntr od uction F und
ament e.g., a night-stand clock, or applications that are executed when the device in a charging tray, e.g., overview of the loading process, are not compatible with the Nexus 7 but it are compatible with the Nexus 4.
The variability constraints imposed by an SPL are specified by using features models. In a feature model, features and their relations are modeled during the domain engineering phase. The next section introduces feature models.