Customized Product Copies
1. Introduction
1.1. Motivation
When it comes to consolidating customized product copies, one cannot assume a complete and reliable documentation of all modifications performed in the copies. As confirmed by an industrial case study performed in the context of this thesis, one cannot even assume a list of custom features that have been implemented for a certain product copy. Furthermore, the developers, who originally introduced the copies might not be available anymore, as it was the case in the industrial case study as well.
Relevance in practice If done the naive way, a product copy consolid-ation results in a lot of manual effort and high complexity. For example, consolidations considering only parts of a copy and performed in an unstruc-tured manner come with the risk of too many unrelated and insufficiently documented variability. Svahnberg et al. [183] describe such variability as a threat to the manageability of an SPL in practice. The high effort and complexity reduce the advantages of introducing an SPL.
A survey performed as part of this case study confirmed that companies are aware of the disadvantages of customized product copies but do not actively target their consolidation (Section 8.5.3).
Limitations of related research directions Existing SPL engineering approaches either follow a top down approach (i.e., designing the SPL first), or do not support the consolidation of existing copies to an SPL in an implementation-aware manner. Existing approaches for analyzing differ-ences and merging them into a single code base do not allow for designing and introducing variability. On the other side, approaches in the field of clone detection allow for identifying commonalities within one or more code bases.
1.1. Motivation
developers in transforming the rest of the implementations into reasonable variability.
Scientific challenges described in literature Due to the limitations of existing directions of research, it is still an open scientific question which type of information and guidance allows for supporting developers in consolidat-ing copies into SPLs. In recent years, this scientific question raised additional awareness as several groups started to investigate this topic, such as Rubin et al. [165, 160, 162], Meister [129], Eyal-Salman et al. [57], or Alves et al.
[4], and the research community started according events such as the Interna-tional Workshop on Reverse Variability Engineering (REVE [123]). Rubin and Chechik [161] recently published a survey on feature location techniques and motivated their potential for a transition to SPLs. They concluded their survey with the demand for adapting and evaluating the benefit of feature location techniques for such transitions, which matches to the contributions of this thesis.
1.1.1. Example Scenario
Copy-based customization of existing software solutions is not limited to a specific domain or type of system. One can assume, the higher the need for customization, the lower the experience with variability, and the stronger the project constraints are, the more often customized product copies exist. To give an example, an online shop used in an e-commerce scenario as shown on the left side of Figure 1.1.
Starting position A software vendor has for example developed an integ-ration of a shop with a product database and an Enterprise Resource Planing (ERP) system for the customer operating the shop. The product database provides information about the products sold in the shop and the ERP system provides real time stock and price information. The solution is successfully deployed and used.
However, having the commonalities at hand, the approaches do not support
Customer 2 PD2 & ERP2
Customer 3 PD3 & ERP3 Customer
PD1 & ERP1
Time Pressure
Figure 1.1.:E-Commerce example of customized product copies
Customization need and project pressure Now, customer 2 and cus-tomer 3 request similar solutions but operate different product databases, different ERP systems, and adaptations in their data processing. These adap-tions are not foreseen configuration opadap-tions and require source code changes.
Furthermore, it is summertime already and the customers need to have these integrations before the Christmas business starts. As this time will be the peak of their business, the integrations will be useless if they are not available in advance. To cope with this time pressure, copying the existing software solution allows for two teams working in parallel on adapting the integration to the customer-specific needs.
Consolidation need When the Christmas time is successfully passed and the new year has started, the management of the software vendor decides to offer such integrations for varying ERP systems and databases as a product.
In particular, they want to offer the solution with the ability to support any combination of product databases and ERP systems supported so far. Thus, the software vendor needs to consolidate the customized copies into an SPL flexible enough to support this strategy. However, at the same time, the effort
1.1. Motivation
required for this consolidation must be as low as possible to finance the strategy and to offer the future SPL in a reasonable time frame.
1.1.2. Copy-Based Customization
Code copies are well-known for their disadvantages in the field of software engineering in general and software evolution in particular. Parnas [145] has discussed and criticized code duplication, what he calls the “Clone and Own”
approach, already in 1976. However, copying and customizing existing products is a still widespread procedure, as recently studied by Dubinsky et al. [45]. They have identified three reasons why copying code is still used in practice [45, page 28]:
• “Efficiency”
• “Short-term Thinking”
• “Lack of Governance”
The first reason has been illustrated in the example described above for coping with the short time frame to realize the customizations. “Short-term thinking”, exists according to Dubinsky et al. [45], when companies focus on delivering individual products and postpone activities for enabling reuse.
As a third reason, they describe that a “Lack of Governance” exists when knowledge about and responsibility for reuse are rarely maintained by a company. The improved “Efficiency” as reason for copying has additionally been confirmed by the participants of our online survey (Section 8.5.3).
The “Lack of Governance” was confirmed by the participants of the online survey and interviews we have performed (Section 8.5.1). Similarly, Rubin et al. [165, page 1] summarized the advantages of copy-based customization as “. . . the easiest and the fastest reuse mechanism, providing . . . existing already tested code, while having the freedom and independence to make necessary modifications. . . ”.
However, Rubin et al. [165] and Dubinsky et al. [45] do not aim for the completeness of their lists, and even more reasons, such as unstable domains, intellectual properties, and organizational structures, force copying code instead of introducing variability in advance. Copy-based customization practices are not limited to copying products as a whole. It is applicable for
Customized Product Copies
SPL with Extensions
Original Product
Product Copy Customer A
Product Copy Customer B
SPL Core
Extension Customer A
Extension Customer B
consolidation
Figure 1.2.:Customized product copies (left) and derived SPL with core and exten-sions (right)
copies of complete products as well as for copies of extensions or components of a product as illustrated by the following two scenarios.
Customized Product Copies Figure 1.2 presents a typical customization scenario with the whole product being copied and modified to match the needs of customer A or customer B. It represents the traditional “Clown and Own” strategy discussed and criticized by Parnas [145]. This type of scenario is typical for introducing an SPL. It requires to design variation points and alternative variants for these points.
Grown Extension Repository Another application scenarios for consol-idating customized copies are grown extension repositories. Figure 1.3 shows a software product that already implements an extension mechanism and appropriate extension points. Extension points are a certain type of variability realization mechanism. Extension points allow for flexibly adding new extending components according to a defined Application Programming Interface (API) as described by Klatt and Krogmann [98].
In practice, there are often grown extension repositories containing many ex-tensions serving the same functionality but modified or adapted to customer-specific needs. To keep such extension repositories manageable and simplify the selection and reuse of extensions, the existing extensions must be re-viewed and consolidated on a regular basis.
1.1. Motivation
Grown Extension Repository
SPL Core
Extensions
Consolidated Extension Repository
SPL Core
Extensions consolidation
Figure 1.3.:Grown extension repository (left) and repository with consolidated and flexible extensions (right)
1.1.3. Advantages of Software Product Lines
Reuse is one of the major goals since the early years of software engineering (Jacobson et al. [88]). It is expected to shorten the time-to-market, reduce maintenance costs, and lead to an improved quality as a result of more often tested components. About a decade ago, the Software Product Line approach has been introduced as a concept of explicitly managed variability (Clements and Northrop [33]). Meanwhile, the approach has proven as a valuable concept to reach the goal of software reuse by achieving an “improved time-to-market and quality, reduced portfolio size, engineering costs and more”
(Rubin and Chechik [164] referencing to Clements and Northrop [33] and Gomaa [67]).
1.1.4. Consolidation Challenges
Consolidating customized product copies is a typically challenging and expensive task. Especially, understanding the customizations from one copy to another is not obvious by nature. A possibly large amount of differences, irrelevant modifications (e.g., comments), relationships between those modifications, individual preferences on the future SPL and the need for a long-term manageable variability design, lead to challenges specific for consolidation activities.
Difference granularity and amount Independently customized product copies allow for flexible adaptations without any restrictions. As described by Alves et al. [4, page 4], tools for analyzing the differences between those copies provide many details one has to handle. Especially when text-based or line-based difference analyses approaches are used, their sensitivity to reformatting further complicates this challenge as described by Baxter et al.
[12] and Hunt and Tichy [84, page 2].
Related differences When merging code bases, one has to identify related differences to improve the merging or prevent conflicts due to renaming as described by Hunt and Tichy [84]. Not only merging code bases but introducing variability at the same time further extends the challenge of identifying related differences. Developers need to find related differences scattered to many locations and must decide which of them contribute to the same variable feature, as described by Rubin and Chechik [163], Eyal-Salman et al. [57], Alves et al. [4] and Koschke et al. [108].
Individual goals As described by Bosch [21], Software Product Lines can exist in different shapes such as deploying different sets of components or multi-tenant systems adapting their behavior to the current user. Depending on the individual goals of a company, one shape is preferable over the other. However, besides the general shape of an SPL, individual points of variability require different types of variability. For example, even if multi-tenant systems allow for deciding about variability features at run time, there will be some variable features configured at system start up time anyway (e.g., the type of database server to use). Such decisions are influenced by technical as well as product management requirements and need to involve the according stakeholders.
In addition to the shape of the intended SPL, a company can have different quality goals when deciding for a consolidation, such as reducing code complexity or redundancy as described by Rubin and Chechik [164]. Thus, individual goals of a consolidation should be considered to achieve a valuable SPL at the end of a consolidation.