PeeringHub monitors the application-engineering process. Differences with other works mainly stem from what is being monitored, how is being monitored, and why is being monitored. Table 4.2 outlines the outcome that also includes the type of SPL being targeted. Next, the comparison is arranged along the “what”, i.e. the artefact being monitored.
Ref. The subject of change (what)
Purpose (why) Change Detection
Means (how) SPL type [CKM+08] Story-based requirements Feed-back Asynchronous communication na [HR10] Requirements, Variability model Feed-back Monitoring na
[LG15] Variability model Increase awareness of
changes in products
Monitoring Composition
[MBKM08] Clone code Feed-back Levenshtein distance Annotation
[PTS+16] Code Product synchronization Monitoring Clone&own
[SSRS16] Code Update propagation Diff Annotation
[?] Code Identifying features in
forks
Diff Clone&own
PeeringHub Code Alleviate the merge
problem
Diff Annotation
Table 4.2: Related work on monitoring the application engineering process. Requirements. Here, product engineers are instructed to suggest eventual SPL requirements to domain engineers (a kind of feed-back propagation). In Carbon et al. [CKM+08], product engineers resort to reuse stories to communicate changes
in SPL requirements to domain engineers. This approach adapts the agile practice “planning game” to SPLs [CKM+08]. In a similar vein, Heider et al. also advocate
for SPL requirements to be fed from requirements risen during application engineering [HR10]. Unlike Carbon et al, Heider et al. do not require explicit intervention of product engineers, but rather, application engineering is being transparently monitored at the requirement level. To this end, authors introduce EvoKing, a tool that monitors requirement-level activities by product engineers. Domain engineers can afterwards decide about each requirement being implemented at the product level or SPL level. This tools was later used in [LG15] through the notion of “features feeds”. Domain and application engineers can subscribe to the variability model elements, i.e. configuration units, features and variation points (elements in the Common Variability Language [HMO+08]). Say a product engineer needs to add a new feature to a product, and
hence, she adds a new feature to the configuration unit CU1. Engineers (both domain and application ones) subscribed to CU1 will be notified. Next, when the new feature is implemented, product engineers can propose their implementation to be promoted as reusable, and if so, other engineers can incorporate it into their developments.
PeeringHub differs from the aforementioned approaches in all: the target audience (domain engineers vs. application engineers), the artefact being monitored (requirements vs. code) and the SPL stage (requirement analysis vs. code development). At this respect, EvoKing and PeeringHub complements each other: requirement feed-back can be conducted through EvoKing; next, assigned to different product-engineering teams whose efforts and synergies are later tracked through PeeringHub. Monitoring wise, EvoKing requires product engineers to explicitly subscribe to the features they are interested in. By contrast, PeeringHub resorts
to the heuristic of “subscribing” products to those features that are being more intensively updated from those exhibited by the product at hand. Though products might potentially exhibit a large number of features, the heuristic limits the focus to only those features being upgraded in a short turnover (two weeks for Danfoss), hence averting the scalability issue in the presence of large feature models.
Source code. Mende et al. [MBKM08] tackles clone detection among functions during product customizations. To this end, they resort to the Levenshtein distance to measure the similarity between clones. They also propose metrics that aggregate similarities at the architectural level to sustain the need for the pruning phase. For the growing phase, Schulze et al. [SSRS16] address update propagation in Pure::Variants where products are upgraded with newer versions of the core-assets. Similar to our approach, authors resort to a 3-way diff/merge. However, the compared commits are different. Given a product generated out of BASELINE-1, they are interested
in upgrading it with a new release of core assets, e.g. BASELINE-2. Therefore,
their 3-way diff looks like: 3WAYDIFF(BASELINE-1, BASELINE-2, PRODUCT). By
contrast, our approach looks for differences between products generated out of the same baseline. That is, our 3-way diff looks like: 3WAYDIFF(BASELINE-1, PRODUC- 1, PRODUCT-2).
For clone&own SPLs, Pfofe et al. [PTS+16] address change synchronization
between cloned products. Their tool, an eclipse plugin called VariantSync, tracks changes as engineers conduct product development. Afterwards, developers need to tag these changes to feature expressions, and the tool aids engineers on automating propagating those changes to products sharing the same feature expression. Although thought for fork-based development in open-source projects, the work presented by Zhou et al. [?] comes close to ours. Notice that forking is a common approach in clone&own SPL (e.g. [RKBC12]). In open-source projects, forks (i.e. a clone of a whole repository) can be interested in what related forks are doing. Zhou et al. propose a tool that compares each fork with the Main repository from where forks were derived. Unlike annotated SPLs, no explicit feature-to-code mapping exists so authors need to rely on both concern location and dependency analyses in order to identify features in forks. Finally, clone&own SPLs are regarded as the “first step” towards a fully- integrated SPL approach [?, RCC13]. In this sense, Antkiewicz et al. [?] and Rubin et al. [RCC13], propose roadmaps as to iteratively transition from a clone&own setting towards a fully-integrated SPL platform.
Back to PeeringHub, our efforts are not so much about concern location (since changes happens within the scope of a variation point) but at integrating the practice of “peering” as part of product enginering process. This moves visualization and gradual unveiling to the forefront.