This Chapter presented the results of a mapping study on SPL evolution. In total, 107 articles were included in this mapping study from 1994 to mid 2015. The aims were (1) to provide a consolidated overview on “SPL evolution”, and (2), to identify well-established topics, trends and open research issues. As for the first goal, we described the SPL specifics and their impact on the traditional software change mini- cycle proposed by Yau et al. [YCM93]. On these grounds, we further elaborated on this mini-cycle, and classified the literature accordingly. This permitted a finer grained classification of studies. The answers to the research questions of our mapping study are summarized below.
RQ1, Research type. Solution papers are the most common type of contribution (31%), followed by “Validation research” (24%). Nevertheless, a tendency can be observed towards more evaluation and validation papers. The area reaches a peak in 2012 with 25 papers, and it maintains a steady contribution of around 10 papers a year. Four main conferences stand out as the main venues, though SPLC takes the lion’s share with a 28%. Surprisingly, the number of “Experience papers” is rather limited (17%) which contrasts with the increasing use of SPLs in industry [Sav14]. A plea is then for practitioners to report their SPL evolution efforts, rather than reporting only SPL adoption effort. This would certainly be a spur for the whole field.
RQ2, Product derivation approach. Efforts go as follows: “Annotation” (4%), “Clone” (7%), “Hybrid” (8%), “Model-driven” (15%), and “Composition-based” (29%), the later specially for component-based SPLs. Studies on FOP, AOP or DOP took the form of academic evaluations aiming at proving their resiliency upon SPL evolution. No evidences were found on the applicability of these approaches in an
industrial setting. Interestingly, we observed a recent interest in both “Annotation” and “Clone” approaches since 2012 on. Since, both annotation and clone-based SPLs are the approaches widely used in industry, this interest might be interpreted as the research community making the effort to provide means for SPLs in industry.
RQ3, Asset type. Basically, all assets received coverage: variability model (30%), SPL architecture (18%), code assets (30%) and SPL products (13%). Products lag behind other assets as for attention received. This is bad news for SPLs evolving following a grow-and-prune model. Though some proponents regard products to be derived on the fly from core-assets, the current state of affairs is that products are still in need of being customized, and hence, having their detached life-cycle from the SPL. This advices for products to be kept in the radar of SPL evolution.
RQ4, Evolution Activity. The least addressed topic is “Identify change” (%6), followed by “Verify change” (14%). On the other hand, “Analyze and plan change” and “Implement change” have received significantly more attention (37% and 43%, respectively). A finer-grained analysis uncovered some tasks as being underexposed, namely, (1) decision-making on whether product specifics should be promoted to SPL core-assets; (2) change impact analysis upon architectural changes; (3) inconsistency detection for assets other than variability models. “Document change” was left out since no study was found on this activity.
2.8 Conclusion
From the results of this systematic mapping, we can observe that SPLs have received considerable attention by the Software Engineering community, with conferences fully dedicated to this topic. The increasing focus on evolution might be a symptom of maturity where SPL solutions start being tested out. Nevertheless, we have spotted how the SPL research community has left products behind when considering SPL evolution. This means that little support is given for incrementally evolving SPLs from product development. This is unfortunate since capitalizing on the changes that happen at the product level becomes vital during the initial phases of the SPL life- time. As shown in Chapter 1, at these initial phases, commonly the SPL core-asset base does not fulfill all the requirements needed by products, and hence, products need to customize the core-assets, as well as, create brand new assets in order to develop the “remaining” requirements themselves. In this context where both core-assets and products need to co-evolve, the SPL evolution is governed by pruning seasons, where product functionalities deemed useful are promoted to core-assets. Specifically, means are required to help SPL engineers:
• identify and analyze how products have changed the core-assets after they were derived from the SPL core-asset base,
• propagate product customizations to the SPL core-asset base, and vice versa. This thesis aims at addressing both gaps. The next two chapters delve into each of the issues.
Chapter 3
Analyzing product
customization
3.1 Overview
The previous Chapter presented a mapping study on SPL evolution research. We saw how the existing research does not sufficiently address the issue of co-evolving both core-assets and products. In such SPLs, evolution is driven by new functionalities implemented in products, and these need to be identified and analyzed in order to elucidate which ones to promote.
In this Chapter1, we explore how to aid SPL engineers on “customization
analysis”, i.e. analyzing how products have changed the core-assets they were derived from. Customization analysis is intended to help SPL engineers identify interesting customizations to be promoted to reusable core-assets for the next core-asset release. Deciding when and what should go into the next SPL release is far from trivial. A main decision-making input is the effort that has been put into product customization. We propose the use of data warehouses to analyze this customization effort. Requirement analysis, dimensional modeling and reporting tools are discussed in Sections 3.5, 3.6, and 3.7, respectively. As a proof-of-concept we developed CustomDIFF, a data warehouse tool that uses Git as the operational system and pure::variants as the SPL framework. An 8-minute video showing CustomDIFF highlights is available at https://tinyurl.com/ycjhwzpc. This research has been motivated and validated in the context of the Danfoss Drives, a SPLC-awarded hall-of-fame company [Dan].
Figure 3.1: Depicting the problem definition for customization analysis with a mind map. Interact with it online at https://tinyurl.com/yay46us8.