SPL Profile
6. Variability Design
6.1. Variation Point Structure Design
6.1.2. Variation Point Filtering
Variation Point Filtering removes detected VPs from the VPM (e.g., irrelevant differences such as representing code beautifying) to increase the precision of subsequent relationship analyses. This section describes the Variation Point Filtering concept proposed as part of the SPLEVOapproach to allow for reusing existing program analyses to identify candidates of VPs to be filtered. The concept has neither been implemented nor evaluated in the case studies as no corresponding variability-irrelevant modifications could be identified by reviewing the code. However, we argue for the value of such a filtering because of the reports on such modifications by the authors of the approaches proposed for reuse.
V1
id=A
VPM Copy B
Copy A
V2
id=B
VP2
SE1 SE1'
VP1 Unmatched Variability-Irrelevant Differences
Matched
Variability-Irrelevant Differences
V2
id=B V1
id=A
VPM Copy B
Copy A
SE1 SE1'
VP1
Model reference Indicator for variability-irrelevant modification VP Variation Point V Variant SE SoftwareElement
Figure 6.4.:Shapes of variability-irrelevant differences
Filtering variation points In addition to feature-specific modifications in the product copies, there are differences irrelevant for the variability of the future SPL. The SPLEVODifference Analysis already filters formatting changes. Furthermore, code beautifying, such as renaming, is typically variability-irrelevant too. VPs identifying such variability-irrelevant differ-ences can be removed from the VPM and, thus, no longer result in variability of the future SPL. However, such VPs are not automatically filtered because they might represent code optimization that must be reflected as variabil-ity (e.g., as professional or free option). Hence, a manual confirmation is necessary.
Variability-irrelevant differences As illustrated in Figure 6.4, two altern-atives exist how variability-irrelevant differences can be reflected by VPs. If an identifying part of a SoftwareElement (e.g., its name) has been modified, the SPLEVODifference Analysis does not match the origin and the copy of this element and reports two separate VPs (Section 5.3.1.2), for example if the name of an identifier was changed. As illustrated on the left side of Fig-ure 6.4, an indicator for such an unmatched variability-irrelevant difference
6.1. Variation Point Structure Design
must relate two SoftwareElements with each other that originate in different copies and are identified by different VPs. In contrast, if a modification did not change an identifying part of an element, the matched variability-irrelevant differences are reflected as variants of a single VP, for example if the expression defining the initial value of a variable declaration has been simplified. As illustrated on the right side of Figure 6.4, an according in-dicator must relate two SoftwareElements with each other that originate in different copies and are identified by a single VP.
Proposal for reusing existing approaches The SPLEVOapproach pro-poses to reuse existing approaches for identifying such indicators of variability-irrelevant differences. Existing approaches from the fields of clone detection, renaming detection, and change assessment provide mature strategies that can be applied in this context. However, these proposals have neither been implemented in the SPLEVOprototype nor evaluated as no corresponding modifications have been identified in the case studies.
Clone Detection In the field of clone detection, many approaches have been proposed to identify similar code, reaching from exact matches up to semantic equivalent computations (Section 10.3.3). The SPLEVO ap-proach proposes to reuse existing apap-proaches for clone detection to identify similar SoftwareElements implementing Variants from different copies for finding any variability-irrelevant differences of both shapes mentioned above.
SoftwareElements moved to different locations represent similar code and thus clones of each other. Such moved elements can have been additionally modified, which requires to reuse a more mature type of clone detection.
A reasonable candidate for being reused is the clone detection algorithm proposed by Baxter et al. [12]. Their Abstract Syntax Tree (AST)-based approach fits to the hierarchical structure of software models assumed by the SPLEVOapproach (Definition 7). However, a clone-detection-based filtering has not been implemented and evaluated because no corresponding modific-ations were identified in the case studies, as mentioned in the introduction of this section.
Renaming Detection Renaming means to change the identifier of a Soft-wareElement. This leads to unmatched software elements and, thus,
differ-ences in the shape presented on the left side of Figure 6.4. Malpohl et al.
[126] propose an algorithm for detecting renaming operations in the field of software difference analysis. They use programming language-specific structures to compare SoftwareElements while ignoring formatting informa-tion as well as identifier names. Thus, their approach can be compared to the AST-based clone detection of Baxter et al. [12] but operates on a linear representation of the parse tree for improved performance. However, apply-ing their renamapply-ing detection to SoftwareElements implementapply-ing Variants from different product copies potentially allows for detecting renamed and thus unmatched variability-irrelevant differences. The SPLEVOapproach proposes to reuse the renaming detection of Malpohl et al. [126]. However, a renaming-detection-based-filtering has not been implemented and evaluated because no corresponding modifications were identified in the case studies, as mentioned in the introduction of this section.
Non-Essential Changes Kawrykow and Robillard [94] proposed an ap-proach for detecting “non-essential changes” based on change history in-formation. In addition to renaming, they aim for identifying “Trivial Type Updates”, “Local Variable Extractions”, and “Trivial Keyword Modifica-tions”. They propose to add type resolving to existing difference analyses and use similarity rules for detecting and filtering such potentially irrelevant changes. They facilitate Partial Program Analysis (PPA)-based type resolv-ing due to the limitation of the difference sets their approach originates from.
SPLEVOVPMs provide access to the software models of the product copies under study, providing already resolved types. Thus, the detection rules of Kawrykow and Robillard [94] are proposed for being reused but have not been implemented, as mentioned in the introduction of this section.
Necessity of manual confirmation The SPLEVO approach does not automatically remove VPs. Instead, identifying indicators as described above are recommended to be used to guide SPL Consolidation Developers to the appropriate candidates of variability-irrelevant differences. Hence, SPL Consolidation developers can actively decide to manually remove VPs from the model. This manual investigation is required as it is crucial to not lose any VPs unintentionally, and not all of the approaches mentioned above offer a 100% precision in their findings. For example, Kawrykow and
6.1. Variation Point Structure Design
Relationship
Relationship Meaning
Relationship Type
Restrictive
Suggestive
Dependent Modifactions
Simultaneous Modifications Similar Modifications
Relationship Analysis
0..*
identifies
1
1
1..2
Figure 6.5.:Relationship meanings and types
Robillard [94, page 352] report a precision of 98.8% in their overall findings.
In addition, SPL Consolidation Developers might have preferences for a spe-cific alternative due to improved naming or other reasons. However, to use an alternative that does not originate from the Leading Copy requires manual code adaptation later on. Such modifications are not explicitly targeted by the SPLEVOapproach, as they represent regular software development tasks.