Mapping features to automatically identified object-oriented variability implementations

Abstract

In Software Product Line (SPL) engineering, mapping domain features to existing code assets is essential for variability management. When variability is already implemented through Object-Oriented (OO) techniques, it is too costly and error-prone to refactor assets in terms of features or to use feature annotations. In this work, we delve into the possible usage of automatically identified variation points with variants in an OO code base to enable feature mapping from the domain level. We report on an experiment conducted over ArgoUML-SPL, using its code as input for automatic detection through the symfinder toolchain, and the previously devised domain features as a ground truth. We analyse the relevance of the identified variation points with variants w.r.t. domain features, adapting precision and recall measures. This shows that the approach is feasible, that an automatic mapping can be envisaged, and also that the symfinder visualization is adapted to this process with some slight additions. CCS CONCEPTS • Software and its engineering → Software product lines.

A framework for managing the imperfect modularity of variability implementations

“…Ongoing work that tackles the automatic capturing and modeling of vp-s in similar kinds of code structure [89,66] or a recommendation approach based on our framework for modeling vp-s with variants, comparable to the code recommendation approaches for reuse [61], could also be considered to be coupled to the proposed contribution, so to reduce the burden of manual variability capturing and modeling and only on relevant or intricate variations points. In addition, we are working on the interoperability of our tool with other variability management tools, such as pure::variants, by using the variability exchange language (VEL) [69], as a coming standard for exchanging variability information between variability management tools.…”

“…Because of this deficiency of information during our experiments, we decided to classify all used techniques as variability related techniques. However, in real systems this may not be always true [66]. For instance, there are approaches that consider that all C preprocessor directives in a system are used for implementing some PL variability, whereas some others disagree [95].…”

“…Although this is not a concern that is particular to our framework or its realization, it shows a limitation to the generalization of the approach. Recent works [89,66] on automatic detection of some object-oriented techniques rely on the density of variability implementations within a set of classes to determine areas of interest in terms of variability, but this technique is not precise enough and still needs some human expertise to map features to variability implementations [66].…”

Identifying and Mapping Implemented Variabilities in Java and C++ Systems using symfinder

“…This system contains a ground truth for domain features with their traces in code assets [9]. By using this ground truth, we manually mapped the potential vp-s with variants to domain features in ArgoUML, found out those that are actual vp-s with variants, and then calculated precision and recall for the symfinder identification [12] (definitions are given below). In complement to the mapping experiment manually made in [12], the presented version of symfinder now automates this mapping process and provides an enhanced visualization.…”

“…The first visualization by symfinder displayed all potential vps with class granularity and only their variants that have vp-s with a method granularity. However, during the measurement of symfinder's precision and recall [12], we noticed that a considerable number of feature traces were mapped to class level variants, which were hidden in the visualization. Because of their importance, we added the option to visualize at once all class level variants, including those that are without method level vp-s.…”