SAFE COMPOSITION OF CK-BASED PRODUCT LINES

products are valid. It is undesirable to generate invalid products. This might happen due to errors when designing and implementing a SPL. In this EPL example, the dependency on IntegerValue should have been taken into account when building the CK. In the EPL example, since there are few products in the SPL, a simple and naive process for verifying safe composition would be to generate, compile, and run each product to check for problems.

However, this approach is often impractical. For instance, in the release 7 of the MobileMedia SPL [FCS⁺08], it is possible to generate 272 product configurations, each around 3KLOC. The average time to compile a specific MobileMedia product configura-tion lies around 40 seconds. It would be needed around 3 hours to compile all products, besides the time for running and testing each product to detect if they are working prop-erly. There are SPLs that can generate thousands of products [BBRC06], which makes this brute-force approach impractical, and possibly unfeasible.

Thus, it is important to verify safe composition of software product lines without having to generate all products. Some of the existing approaches are based on the Feature-Oriented Programming paradigm, which, as discussed in Section 2.1.2, assume a 1:1 mapping of features into assets [TBKC07, DCB09]. Others are based on annotations similar to conditional compilation, which scatters the CK throughout the assets [KA08, CP06]. The following sections describe our approach for verifying safe composition of SPLs using CK models, explaining how it could be used to detect problems as the one demonstrated in this section.

3.2 SAFE COMPOSITION OF CK-BASED PRODUCT LINES

The previous section illustrates an example of the kind of problem we are concerned in avoiding. Our goal is to find problems such as the one mentioned in the previous section, without having to synthesize the entire SPL. This sections starts to describe our approach, discussing the main concepts that are used as basis to the verification process, which is detailed on Section3.3.

To enable the verification of safe composition using our approach, we define explicit interfaces for CK items. We have, for each CK item, provided and required interfaces that are used in the verification process. As a simple example using the EPL, consider

3.2 SAFE COMPOSITION OF CK-BASED PRODUCT LINES 35 the sixth row from the CK in Figure 3.3, containing the selection of the AddExp class.

From Listing 3.1, we know that AddExp depends on the following classes: {BinaryExp, Expression, Value, IntegerValue}. These dependencies constitute part of the set of required assets for the AddExp class. Besides syntactic dependencies, other possibilities include semantic dependencies, dynamic class loading, restrictions about the final size of the program generated and others. The provided interface, in this case, is constituted by the AddExp class itself. If there were inner classes, for example, the provided set would also include them.

A significant part of these provided and required interfaces can be derived automat-ically from the assets, specially syntactic dependencies, such as in the example above.

This derivation process is an orthogonal concern, and is not the focus of this work. It must be taken into account that such a derivation process can have limitations. For in-stance, in the case of dynamic loading of classes, if there is a Class.forName(x), where we do not know the value ofx, this might lead to a dependency that cannot be captured with such a derivation process. Besides that, a SPL is composed of different kinds of files, such as image files, configuration files, as we see on the mobile game in Section2.1, where interfaces cannot always be automatically extracted. Therefore, this work is based on the assumption that these interfaces are available, whether automatically derived from the assets or manually informed.

So, based on this concept, another view of the CK from Figure 3.3 is illustrated in Figure 3.5. This CK displays information of the interfaces for each CK item. There-fore, for each CK item, besides columns for feature expressions and assets, we also have columns for the provided and required interfaces², expressing, in this case, syntactic de-pendencies between classes and aspects. Therefore, when evaluating the CK for a product configuration, we yield not only the set of assets, which can be seen as a view on the provided interfaces set, but the required interfaces set is yielded as well. So, for the CK item on the sixth row in Figure3.5, provided consists ofAddExp and required consists of {BinaryExp, Expression, Value, IntegerValue}. For the items which have two or more classes or aspects, required for that item is the union of the required interface for each asset. We do likewise for the provided column.

With this extended CK, we are able to check safe composition of a product

configu-2For simplicity, we remove file extensions from the names on the provided and required columns.

3.2 SAFE COMPOSITION OF CK-BASED PRODUCT LINES 36

B0'57$0-!./$0112%3 =11051

!"#

"$%&$'()*'+',-!./$0112%3)*'+'

4350&0$ !"#$%$&'()*$+,(-(

./*0)$ ./*0)$'()*$+,(-(12 ./*0)$345$675$8#+(,

699 699:;5+,(-(

6992!2./*0)$ 699./*0)$345$675$8#+(,

<&/-=9$9

!"#$"%&'()*+",--.#/

0/1,$,"2%34, 5#463,2%34,'(

5#463,78+,9-+,:1

9;;)*+

9;;5#463,78+,9-+,:1

>$?*=&$9 )*+",--.#/'(2%34,

2%34,

5#463,2%34,'()*+",--.#/'(2%34,

<./%"8)*+'()*+",--.#/'(

0/1,$,"2%34,'(2%34, 5#463,78+,9-+,:1'(9;;)*+'(

5#463,2%34,'()*+",--.#/'(2%34,

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

6992!2@*0 A="(&4:;5+,(-(

@*0 @*0:;5+,(-(

@*02"2./*0)$ @*0./*0)$345$675$8#+(,

2%34,

<./%"8)*+

=46)*+

=465#463,78+,9-+,:1

)*+",--.#/

)*+",--.#/

<./%"8)*+'()*+",--.#/'(

0/1,$,"2%34,'(2%34, 5#463,78+,9-+,:1'(=46)*+'(

5#463,2%34,'()*+",--.#/'(2%34,

Figure 3.5 An improved Configuration Knowledge for the Expression Product Line.

ration without building it. Evaluation of the CK yields both the provided and required interface sets for the product. We only need to verify, for each product, that the required interfaces set is implied by the provided interfaces set. The following definition formalizes this intuition.

Definition 3. "Valid product#

A valid product is one which, after its product configuration is evaluated against the configuration knowledge, the required interfaces set is implied by the provided interfaces set.

!

For example, in the case of the product configuration {EPL, Value Type, Double, Operations, Add},

discussed in the previous section, CK evaluation yields the following set of provided interfaces:

{Program, Expression, Value, DoubleValue, DoubleTypeAspect, Binary-Exp, AddBinary-Exp, AddDoubleTypeAspect}.

3.2 SAFE COMPOSITION OF CK-BASED PRODUCT LINES 37 For the same product configuration, CK evaluation yields the following set of required interfaces:

{Expression, Value, DoubleValue, BinaryExp,IntegerValue, DoubleTypeA-spect, AddExp}.

When comparing required and provided interfaces for this product, it is noticeable that IntegerValue is required by some asset, but it is not provided. For that reason, this product has a non-satisfied dependency that results in a compile-time error. It is an invalid product. Therefore, we determine if a product is valid or not comparing required and provided sets.

As another example, in the case of the product configuration {EPL, Value Type, Integer, Operations, Add},

CK evaluation yields the following set of provided interfaces:

{Program, Expression, Value, IntegerValue, BinaryExp, AddExp}.

Configuration knowledge evaluation yields the following set of required interfaces:

{Expression, Value, BinaryExp, IntegerValue}.

Therefore, since the required set is implied by the provided set (it is a subset of provided), this is a valid product. Based on Definition3, which defines valid products, we can derive the definition of a valid SPL.

Definition 4. "Valid Software Product Line#

A valid SPL is one in which all product configurations generate valid products, according to Definition 3.

! A possible way to verify safe composition of SPLs using provided and required in-terfaces is to use an algorithm that evaluates the CK for all product configurations, comparing sets of provided and required interfaces, to determine if they are valid. How-ever, execution of this algorithm can become a complex task. The bigger a SPL is, in terms of the quantity of products, the longer it takes to execute. For example, from the FM in Figure 3.1, we can generate 6 valid products. The mere inclusion of an optional