The SPLevo Approach
3. Approach Overview
3.1. Main Consolidation Phases
Figure 3.1 illustrates the three main phases of the SPLEVO approach to consolidate customized product copies into an SPL: Difference Analysis, Variability Design, and Consolidation Refactoring. This section provides an overview of the main phases of the SPLEVO approach. The details of the process and the other contributions are described in the following chapters. In the first phase, the differences between the product copies must be identified. In the second phase, a variability design (i.e., the structure and characteristics of the future variability) must be created to specify how to reflect related differences as variability in the future SPL. Finally, in the third phase, the copies’ implementations must be transformed into a single code base containing the implementation of the SPL core and included features, according to the previously created variability design. All these phases are integrated based on a Variation Point Model as a common data model (Section 3.2). In addition to the main phases, pre- and post-processing phases exist to setup the consolidation process and to handover the resulting SPL to the continuous maintenance (not presented in Figure 3.1 for the sake of brevity).
Focus on Difference Analysis and Variability Design According to Pigoski and April [148, page 6–4], developers spend 40%–60% of their maintenance effort on program comprehension (Section 2.4.9). Thus, one can argue that Difference Analysis and Variability Design are reasonable phases to investigate support for. Furthermore, many approaches exist in the field of refactoring (Section 2.4.11) providing infrastructure that can be reused in the Consolidation Refactoring phase. Thus, the main focus of the SPLEVOapproach is on the Difference Analysis and Variability Design phases. The Consolidation Refactoring is supported in the direction of ensuring consistent variability implementations, which is not covered by existing approaches, today.
Leading and Integration Copies Before starting the consolidation, SPL Consolidation Developers select one of the copies to consolidate as the Leading Copy. During the consolidation, this copy will be transformed into the final SPL instead of building a new separate code base. This procedure
3.1. Main Consolidation Phases
allows benefiting from development infrastructures, such as Version Con-trol Systems (Section 7). Furthermore, consolidation activities can use the Leading Copy as a fixture for their processing. For example, the Differ-ence Analysis can use it as referDiffer-ence for normalizing renaming. All other product copies to be integrated into the Leading Copy are called Integration Copies.
Definition 3 (Leading Copy) ALeading Copy is one of the copies to con-solidate what was selected as the main code base for the resulting SPL. It is used as reference code base throughout the consolidation process. Fur-thermore, the accepted variants of all other copies will be merged into the Leading Copy’s code base during the refactoring. The Leading Copy is selected as part of the process configuration activity.
Definition 4 (Integration Copy) An Integration Copy is any of the copies to consolidate what was not selected as Leading Copy.
The following subsections briefly introduce the main phases of the consol-idation, their challenges, and the contributions of the SPLEVOapproach to cope with. Section 4 discusses the activities in detail.
3.1.1. Difference Analysis Phase
Phase summary Understanding the customizations from one copy to another starts with identifying the differences of their implementations in place. The Difference Analysis consumes the copies’ implementations and produces an initial model of the future SPL’s variability design representing the individual differences. This phase is crucial for the overall process as the downstream phases’ qualities and processing strongly depend on this output.
Challenges In general, a Difference Analysis phase is challenging due to a possibly large amount of differences, irrelevant modifications (e.g., com-ments), preferred variability mechanisms, and copying practices (e.g., nam-ing conventions or Derived Copies referencnam-ing their origin).
Related contributions The contribution of the SPLEVOapproach to sup-port developers in the Difference Analysis phase is a fully automated differ-ence detection as described in Section 5. In addition, the SPLEVOprocess specification identifies stakeholders and information sources to incorporate to gain export knowledge to be considered (e.g., applied company guidelines for copy-based customization).
3.1.2. Variability Design Phase
Phase summary Designing variability in a consolidation process means to identify copy-specific code contributing to the same copy-specific feature and to decide about its representation as variability in the future SPL (e.g., run time or compile time configuration). The variability design must ensure a consistent configuration of variable code locations related to each other as well as the necessary flexibility for instantiating reasonable products from the future SPL. Thus, the differences returned by the Difference Analysis must be related to each other and it must be decided how to reflect them in the future SPL.
Challenges Designing the variability of an SPL is affected by many factors. Technical constraints between the differences (i.e., code depend-encies) and logical relationships (e.g., a copy-specific functionality which makes no sense without another one) must be identified and soft factors, such as organizational reasons or product management decisions [33], must be re-spected to achieve a satisfying variability design. Reviewing the differences and deriving reasonable design decisions is tedious because of the amount of differences, their potential relationships, and the degrees of freedom in deciding about their combination and characteristics. In particular, the soft factors eliminate the chance for a fully automated consolidation and require involving different stakeholders.
Related contributions The contributions of the SPLEVO approach to cope with this challenges are i) a novel software analysis providing variability design recommendations, ii) a definition of explicit design activities to reduce wasted efforts, and iii) an SPL requirements specification (i.e., SPL
3.1. Main Consolidation Phases
Profile) to guide consistent design decisions. The software analysis allows for identifying technical dependencies as well as similar and simultaneous modifications as indicators for relationships in the copy-specific code to automatically derive refinement recommendations for the variability design.
The consolidation process specified in the SPLEVOapproach distinguishes several explicit design activities and identifies sources of information to consider as well as stakeholders to involve for achieving consistent and prevent redundant and reverted design decisions. Third, an SPL Profile is specified to define guidelines for choosing variability characteristics as part of the variability design in a more consistent way.
3.1.3. Consolidation Refactoring Phase
Phase summary In the final Consolidation Refactoring phase, the copies’
implementations are transformed into a single code base, and appropriate variability mechanisms (e.g., conditional execution based on configuration files or user information) are introduced at the same time to switch between the available variants. Based on the copies’ implementations and the vari-ability design created before, the implementation of the SPL core and the included features have to be created. This requires deciding which mechan-isms to implement for the variability specified in the variability design and to refactor the implementations themselves.
Challenges Deciding for appropriate variability mechanisms is challen-ging as many different techniques and mechanisms are available (Sec-tion 2.3.3) to choose from. Furthermore, ensuring a consistent implementa-tion even for the same type of variability mechanisms is tedious as developers have to agree on an implementation style and manually ensure its consistent realization. Mature refactoring solutions exist, but not for introducing vari-ability mechanisms as part of consolidating code from several code bases.
Accordingly, there is no automation to be used here.
Related contributions The contributions of the SPLEVOapproach to sup-port the Consolidation Refactoring phase are i) a specification concept for
consolidation refactorings, ii) an automated variability mechanism recom-mendation, and iii) support for selecting intended variability mechanisms when defining SPL guidelines. The specification concept allows for de-scribing refactorings for introducing variability mechanisms including their supported characteristics (e.g., binding time) in a structured manner, enabling automation. Furthermore, it includes a specification of how to implement the mechanism for different types of software elements. The SPLEVO ap-proach includes a recommendation system automatically assigning the most appropriate variability mechanism to a variation point. The recommendation evaluates the characteristics and implementing elements of a Variation Point (VP), the specifications of the available refactorings, and the list of intended variability mechanisms defined in the SPL guidelines. When specifying these guidelines, the selection of reasonable mechanisms is supported by auto-matically recommending available mechanisms based on the characteristics chosen before.