On the Diversity of Capturing Variability at the Implementation Level

Abstract

In many Software product lines (SPLs), if domain variability can be properly speci ed in terms of features in a feature model (FM), their implementation in core-code assets is hard to capture and maintain, as there are di erent techniques to implement the variability. Even with an organization in variation points and variants, most of these techniques do not shape the code in terms of features, and inconsistencies appear when the variability evolves at one level with no co-evolution at the other. To help SPL architects, one possible solution is to be able to reconstruct the FM by capturing the variability in core-code assets, but di erent implementation techniques expose diverse characteristics, hampering the process. We study in this paper the diverse dimensions of the existing variability implementation techniques, and how they can be captured in an abstract way. We then categorize them regarding these dimensions in a single catalog, extending previous classi cations of such techniques. We also brie y show how the characteristics of the techniques could help to better capture the implemented variability, opening some potential in reverse engineering processes.

Identifying and Visualizing Variability in Object-Oriented Variability-Rich Systems

“…The diversity of these techniques is analysed in different frameworks, taxonomies, and catalogs, by comparing them on different criteria [6,20,22,46,56]. For instance, in a recent catalog, 16 traditional techniques are compared and classified based on 24 properties [58]. But, despite these comparative schemas, we are not aware that any common property of these techniques exists, and could be used to identify the different kinds of vp-s in a uniform way.…”

“…But, despite these comparative schemas, we are not aware that any common property of these techniques exists, and could be used to identify the different kinds of vp-s in a uniform way. For example, in Listing 1, the vp Shape has a class level granularity and is resolved at runtime, whereas the vp draw has a method level granularity and is resolved at compile time, during product derivation [58]. Both of them resemble two different kinds of vp, but with four different properties.…”

“…Nevertheless, there is a complete lack of approaches to identify variation points and variants [39] implemented with different techniques in a single variability-rich system. This could be due to the fact that each traditional technique differently supports the implementation of vp-s with variants [39,58]. Therefore, from a reverse perspective, it indicates that each vp requires its own way to be identified in code assets, depending on the used technique.…”

symfinder

“…While it looks preferable, it does not support well cross-cutting variability [8], and it implies code refactoring that may be completely unfeasible in practice for many systems. This is typically the case in variability-rich systems that have progressively introduced variability into object-oriented code, using many different traditional techniques, such as inheritance, overloading, and design patterns [4,17]. Variability implementations then do not align well with domain features and identifying where these implementations are precisely located is crucial to manage this kind of variability [15].…”

“…While approaches and techniques have been proposed to partially locate domain features at the code level [3,16], there is no work dealing with the identification of object-oriented variability implementations at the structural level, namely at the level of variation points (vp-s) and variants [14,17]. Contrary to a feature related to the variability domain, a variation point represents one or more locations in code at which variation will occur, while the way that a variation point is going to vary is defined by its variants [7].…”