EXTRACTING THE CONFIGURATION KNOWLEDGE

!"#$%&'

!&($)

*+","'

!)-).&/&-, 0%#1/'

!)-).&/&-,

2"3,$-.

4&%&,&' 0%#1/

53&),&' 0%#1/

6)7$8'*+","' 9:&3),$"-7

4&%&,&'

*+","

53&),&'

*+","

;($,'*+","'

<)#&%

=$&>'

*+","

Figure 5.2 Feature model for Release 2 of the MobileMedia SPL [FCS⁺08].

!"!#$%&'(#()&*

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%0',(120,.&-345'6'

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%$*(3#*&&-#%7'"-8*(3#*&&-#45'6'

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%"$#--("%9:*3*;,"3<$#--(45'6'

!!+++

!"#$%&'($"%)*+,&-)-.,'%$*#-%/3,&%2)'=-13,&45'6'

!"!#$%&'(#()&*

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%0',(120,.&-345'6'

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%$*(3#*&&-#%7'"-8*(3#*&&-#45'6'

!"#$%&'($"%)*+,&-)-.,'%$*#-%/,%"$#--("%9:*3*;,"3<$#--(45'6'

!!+++

!"#$%&'($"%)*+,&-)-.,'%$*#-%/3,&%2)'=-13,&45'6'

!"!,$-.&/0

!"#$%&'($"%)*+,&-)-.,'%*>3,*('&%"*#3,(=%<*#3,(=?">-$34'5 1*2!#$%&'(#()&*3&.4$5.,$-.&/0+'6. 1%2!#$%&'(#()&*3&.4,$-.&/0+'6.

Figure 5.3 Simplified build files for products from release 2 of the MobileMedia SPL [FCS⁺08].

product configurations. To enable the verification for SPL releases, we must have the CK, besides the FM. The next section explains how we use these build files to extract a CK model for the releases of MobileMedia SPL.

5.2 EXTRACTING THE CONFIGURATION KNOWLEDGE

This section presents how we extract the CK from the MobileMedia build files, in-cluding the provided and required interfaces. As discussed, in these files, there are annotations that describe which feature expression is associated to the following set of source files, in a sort of CK model which is product-specific. For instance, in the MobileMediaWithSorting.lst file of Figure 5.3 (b), the source file in the bottom is as-sociated with the feature expression Sorting. So, the concept is similar to the CK we

5.2 EXTRACTING THE CONFIGURATION KNOWLEDGE 74 present in Section 2.1.2: If this feature is selected, SortingAspect must be included on the build path for the build task.

For each release of MobileMedia, build files are used to describe a specific product configuration from the SPL. For releases 1 through 5, since there are not many variations, there is only one build file (.lst) for each release, with a complete mapping of feature expressions to assets for the entire SPL. So, they already represent the CK for those releases. For releases 6 and 7, there are build files describing only a subset of product configurations.

For example, consider release 6. On this release, as we see on Figure 5.1, there are 48 valid product configurations according to the FM. However, there are only 6 product-specific build files for this release. This difficults the process of analyzing build files to extract the CK. Therefore, careful work was needed when extracting the CK from these files, using diff tools to compare the common and variable parts between them.

One thing that helped us to make sure that this task was not introducing errors is that the name of some aspects also references the feature expressions associated. For example, PhotoAndMusicAndSMS aspect implements a certain behaviour associated with the feature expression Photo ∧Music ∧ SMS. Another thing worth mentioning is that for both sixth and seventh releases, there is a build file describing a product configuration with all features selected, which contains most of the associations of feature expressions to assets needed to extract the CK.

Figure 5.4 illustrates the derivation process for release 6. Based on the six product-specific build files available, we create another file — CK.lst. This file is created by analyzing associations of feature expressions with source files from all six files. CK.lst contains all associations of feature expressions to source files. This file is a representa-tion of the CK for this release, built from the individual build files for specific product configurations. It is not a valid build file for a product, but instead, we can derive build files for all 48 products based on this file. We extract the CK of release 7 likewise.

The CK model we use in this work associates feature expressions to assets. Therefore, the CK.lst file is a view on this CK model. However, to enable the verification of safe composition for this release, we need to have provided and required interfaces for each item of the CK. In this evaluation, we consider required interfaces as syntactic dependencies between classes and aspects. For example, an import statement, or a local variable

5.2 EXTRACTING THE CONFIGURATION KNOWLEDGE 75

!!"#$%&' !!"($%&'

!!"()$%&' !!"*$%&'

!!"*)$%&' !!"+$%&'

,-$%&'

,-Figure 5.4 Configuration knowledge derivation process for release 6 of the MobileMedia

!

SPL [FCS⁺08].

using a class defined in the same package. For this case study, we are only interested in dependencies specific to the MobileMedia artifacts. We only focus on classes and aspects under the lancs.mobilemedia package, because these are the ones that the build files associates with feature expressions. Thus, we do not capture Java API and external libraries dependencies, for example. While capturing these would make the provided and required sets richer, the problems we found and are discussed in Section 5.3 would still happen. Nonetheless, since we are only using a subset of all actual dependencies, it is possible that there exists more errors than those we found. Also, a build for a single product of MobileMedia is performed in the context of the Eclipse tool [Fou]. This tool provides support for managing external libraries.

Given that we know all classes and aspects names under thelancs.mobilemedia pack-age, these dependencies are captured from the code using a simple script that searches for these names throughout the code for each class. This way, we capture not only import statement dependencies, but also local variables, and so on. The provided interfaces con-sist of the names of classes and aspects itself, and if it is the case, inner classes and aspects names. While this information is needed for enabling the use of our verification approach, it is important to remind that we only need to perform this step because we do not have an available CK with required and provided interfaces already specified. We might cap-ture less dependencies than what really exists, but we do not capcap-ture dependencies that should not be captured, since we know all asset names.