A framework for managing the imperfect modularity of variability implementations

https://doi.org/10.1016/j.cola.2020.100998Get rights and content

Abstract

In many industrial settings, the common and varying features of related software-intensive systems, as their reusable units, are likely to be implemented by a combined set of traditional techniques. Features do not align perfectly well with the used language constructs, e.g., classes, thus hindering the management of implemented variability. Herein, we provide a detailed framework to capture, model, and trace this imperfectly modular variability in terms of variation points with variants. We describe an implementation of this framework, as a domain-specific language, and report on its application on four subject systems and usage for variability management, showing its feasibility.

Introduction

Software product line (SPL) engineering is the common methodological process for developing together a set of related software-intensive systems. The process is intended to achieve mass customization with methodological reuse of the software systems seen as products, leading to lower cost and time-to-market and improved quality. At the domain level, the variability of considered systems is commonly described in terms of their common and varying features, as their reusable units, in a feature model (FM) [1], [2], [3]. Then, in a forward engineering approach, their features are realized in different software assets, including code assets. Consequently, the objective is that various systems can be systematically derived from a common and managed set of software assets.

Although variability is largely studied in the context of software product lines and product families [3], most modern software-intensive systems, being organized as a software product line or not, are variability-intensive [4], [5]. In systems that are not part of a product line, that is, variability-rich systems, the implemented variability in their code assets is neither explicit nor documented. This is because the variability of code assets is typically realized by a diverse and combined set of traditional techniques, such as inheritance, design patterns, overloading, or generic types. However, their used code units, such as classes, or methods in object-oriented programming, do not align well with the domain features or, simply put, neither features nor variation points with variants (their definition is given in Section 2) are by-product of traditional techniques [6]. This hinders the management of the variability of code assets, which seems to be extensive in real variability-rich systems [7], [8].

For example, let us consider the system of JavaGeom [10], an example of a real variability-rich system, which is not organized as a software product line but is variability-intensive, and was used in a previous study [8]. It is an open-source geometry library for Java that is easily understandable. Although not presented and organized as an SPL, it is architected around well-identified features. Compared to similar real variability-rich systems that are of over 100 K LoC and thousands of potential vp-s with variants [7], [8], JavaGeom has over 35 K LoC, being a medium-size variability-rich system. In Fig. 1 is given an excerpt of its created feature model, which consists of five features. The abstract feature [11] JavaGeomFM does not require an implementation, it is used to represent conceptually the JavaGeom variability-rich system. As for the other four concrete features, StraightCurve2D, Line2D, Segment2D, and Ray2D, a form of their implementation is given in Listing 1, using Java language. At first sight, the mapping between features in Fig. 1 and used code units, classes, in Listing 1 seems to be straightforward, but it is more complicated. First, the feature names and class names are mostly different, for instance, the feature name Line2D is different from its implementation class StraightLine2D. Besides, the classes extend or implement other classes and interfaces, showing more dependencies at the code level than that features have at the domain level. Then, the implemented variability by method overloading, distance() in lines 4–18, is not modeled in the FM. This single example, where only the techniques of inheritance and overloading are used, shows some difficulties in mapping features at the code assets of a given variability-rich system. In real variability-rich systems, the problem is exacerbated as features are often not implemented by a single class or method. This is due partly to the many design choices that influence the usage of different implementation techniques to structure the variability implementations, and partly to the crosscutting nature of features with code units [12].

To overcome such variability management difficulties, existing approaches use annotations, often preprocessor directives [13], or have proposed to put into separate modules, for example, into aspects, feature modules, or delta modules [14], all lines of code that belong to each specific domain feature [15], [16]. In addition, different tools are proposed, for example, pure::variants [17], code tagging [18], or those that propose to use colors, at the representation layer of code, for distinguishing the lines of code that implement each feature [19]. Analyzing which technique, tool, or combination of them [20] fits best to implement or manage some variability is hard to conclude as none of them is yet a preferred one [14], while the SPL application domains are themselves largely diverse. However, except for tool-based approaches, most of the proposed solutions affect the initial decomposition or design of code assets, such as their object-oriented design [15], and in case of migration from a variability-rich system to an SPL, a massive code refactoring is required. As a consequence, when an object-oriented design is refactored, for example, to a feature-oriented design [14], the logical relation among code units is usually lost at the code level. For instance, the alternative relation among the three child features in Fig. 1 may lose, which relation is realized by subclasses through the technique of inheritance in Listing 1.

Facing these issues, our work takes the assumption that one can keep unchanged the initial design of code assets of a variability-rich system, that is, without the need to migrate it to an SPL, and manage its variability in terms of variation points with variants, as initial variability abstractions [21]. To the best of our knowledge, no variability management approach is currently addressing the early steps of capturing and modeling the variability of code assets of a variability-rich system [22], [23], [24], [25], [26], [27], especially not when a subset of variability implementation techniques are used in combination [21], [28].

Towards an approach that meets our assumption and goal on managing variability implementations in code assets of a variability-rich system, we proposed, in a previous work [29], a three step framework to manage such variability when a combined set of traditional techniques is used (Section 4). Such techniques expose a form of what we define as imperfectly modular variability (Section 3), as domain features do not perfectly align with the used code units. The framework is devised by analyzing up to ten common variability implementation techniques used in variability-rich systems, which are revealed in a recent catalog of 21 traditional and emerging techniques [30] (cf. Section 2.2.3). This catalog is at first based on 7 previous frameworks, taxonomies, and catalogs [14], [28], [31], [32], [33], [34], [35]. For the purpose of our framework, we analyzed the characteristics properties of these techniques, such as binding time.

  • 1.

    The framework provides the means to make explicit the variability of code assets by capturing the used variability implementation techniques in terms of variation points (vp-s) with variants, as variability abstractions.

  • 2.

    It then makes possible to use the captured vp-s with variants to model the variability of code assets in a fragmented way into so-called technical variability models (Section 4.2.2). Towards this, five types of vp-s are identified and suggested for use, whereas what is a fragment aims at being flexible. It can be a package, file, or class with variability that worth to be modeled separately.

  • 3.

    The framework also introduces the possibility to establish n-to-m trace links between the modeled variability of code assets and their respective features in some feature model at the domain level.

Herein, we extend this work in several aspects:

  • First, we further detail the concept of imperfectly modular variability and determine its induced challenges (Section 3), which motivate the whole presented work.

  • We present the three steps of our framework with all necessary details, formal definitions, and related illustrations (Section 4), mainly by using a running variability-rich system introduced in Fig. 1 and Listing 1.

  • We present the implementation of the framework as a small textual domain-specific language (DSL) in Scala, publicly available. Its technical foundations are also given in Section 5.

  • We report on a series of experiments on the application of this DSL to four subject systems (Section 6). This evaluation was conducted around four research questions to study the encountered implementation techniques, types of vp-s, the multiplicity of trace links, and to evaluate the overhead in modeling with the DSL.

  • We also evaluate the capacity of usage of the proposed framework for variability management by adapting a previous work on early consistency checking [36] and showing how the tooled framework enables us to integrate such a checking method in one of the subject systems (Section 7).

Threats to the validity of the framework and its implementation are discussed in Section 8. We also put our contribution into perspective with some related work, including industrial approaches for managing variability at the implementation level (Section 9). Finally, Section 10 concludes this article by summarizing the contributions and discussing future work.

Section snippets

Background

Some of the key aspects of the variability management of a system, being it organized as an SPL or not, is the ability to model the realized variability of code assets and then possibly to trace it to its specified variability. In the following, we provide a background on variability modeling, realization, and traceability.

Imperfectly modular variability

Variability management would be simplified in case that each domain feature was implemented in a modular way, by a single language code unit [14], as the mapping of domain features to their implementation would be straightforward. But, this is clearly not the case in real variability-rich systems [8], with the current language constructs and design methods, where variability is implemented by using a combined set of traditional techniques, such as inheritance, overloading, generic types, or

A three step framework

To address Challenge1, we propose a three step framework for managing the imperfectly modular variability of code assets of a given variability-rich system. It supports the following tasks, which are also depicted in Fig. 5:

  • 1.

    Capturing the imperfectly modular variability of code assets in terms of vp-s with variants, as abstract concepts.

  • 2.

    Modeling this variability in terms of vp-s with variants while keeping the consistency with their implementation in code assets.

  • 3.

    Establishing the trace links

Framework implementation

To address Challenge3 (cf. Section 3), we developed a prototyped tool to support the three steps of our framework. Different mapping studies [65], [66], [67] and surveys on industrial practices [7], [18] show that, from the variability modeling tooled approaches, textual variability modeling languages have an increased attention. The main stated reasons are against the scalability issues and the difficulties in comprehending a large amount of variability when competing graphical tooled

Applications

The provided framework is expected to be applicable to realistic variability-rich systems where traditional techniques are used. Therefore, to show its applicability, we decided to apply its tool support, the VM-DSL, in several relevant variability-rich systems, as subject systems, to model and trace their implemented variability.

Framework usage

To complement the previous validation and directly tackle the Challenge2 (cf. Section 3), we demonstrate here the usage of our framework for variability management. We aim at showing that our proposed approach for modeling some implemented variability and establishing trace links can be exploited to check the consistency of available models of variability. To do so, we rely on one of our previous work [36], which was only focusing on consistency checking, and put it into perspective to show how

Threats to validity

In addition to the VM-DSL limitations given in Section 6.7, we discuss here several validity threats in our validation.

Related work

In the context of product lines and product families, several approaches related to our framework exist on variability management, including variability modeling and variability traceability of code assets. On the other side, there are alternative approaches to our framework. Further, several textual variability modeling languages related to our VM-DSL have been proposed. In the following we discuss the related and alternative approaches to our framework, as well as related works to our DSL

Summary .

Variability management is a complicated activity during the engineering phases of software product lines or variability-rich systems. In many settings, variability is specified in terms of features, and they are implemented by using a combined set of traditional techniques, such as inheritance, overloading, or design patterns. In such a case, they do not have an explicit mapping at the implementation level, which leads to a form of imperfectly modular variability and strongly hinders the

CRediT authorship contribution statement

Xhevahire Tërnava: Conceptualization, Methodology, Software, Writing - original draft. Philippe Collet: Supervision, Conceptualization, Writing - review & editing.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

References (95)

  • TërnavaXh. et al.

    Identifying and visualizing variability in object-oriented variability-rich systems

  • MeinickeJ. et al.

    Mastering Software Variability with FeatureIDE

    (2017)
  • LeglandD.

    JavaGeom - Geometry library for Java

    (2019)
  • ThumT. et al.

    Abstract features in feature modeling

  • KästnerC. et al.

    The road to feature modularity?

  • LiebigJ. et al.

    An analysis of the variability in forty preprocessor-based software product lines

  • ApelS. et al.

    Feature-Oriented Software Product Lines

    (2016)
  • ApelS. et al.

    Feature cohesion in software product lines: An exploratory study

  • SobernigS. et al.

    Quantifying structural attributes of system decompositions in 28 feature-oriented software product lines

    Empir. Softw. Eng.

    (2016)
  • pure-systems GmbHS.

    Pure::variants

    (2020)
  • HeymansP. et al.

    A code tagging approach to software product line development

    Int. J. Softw. Tools Technol. Transfer

    (2012)
  • KästnerC.

    Virtual Separation of Concerns: Toward Preprocessors 2.0

    (2010)
  • MukelabaiM. et al.

    Multi-view editing of software product lines with PEoPL

  • JacobsonI. et al.

    Software Reuse: Architecture, Process and Organization for Business Success

    (1997)
  • KimJ. et al.

    A comparison of software product line traceability approaches from end-to-end traceability perspectives

    Int. J. Softw. Eng. Knowl. Eng.

    (2014)
  • AnquetilN. et al.

    A model-driven traceability framework for software product lines

    Softw. Syst. Model.

    (2010)
  • M. Becker, Towards a general model of variability in product families, in: Workshop on Software Variability Management,...
  • BergK. et al.

    Tracing software product line variability: From problem to solution space

  • PohlK. et al.

    Software Product Line Engineering: Foundations, Principles and Techniques

    (2005)
  • CoplienJ.O.

    Multi-Paradigm Design for C++

    (1999)
  • TërnavaXh. et al.

    Tracing imperfectly modular variability in software product line implementation

  • TërnavaXh. et al.

    On the diversity of capturing variability at the implementation level

  • GacekC. et al.

    Implementing product line variabilities

  • MuthigD. et al.

    Generic implementation of product line components

  • PatzkeT. et al.

    Product Line Implementation Technologies. Programming Language View, vol. 57Technical Report IESE-Report, 057.02/E

    (2002)
  • PatzkeT.B. et al.

    Sustainable Evolution of Product Line Infrastructure Code (PhD Theses in Experimental Software Engineering)

    (2011)
  • PatzkeT. et al.

    Product line implementation with frame technology: A case study

    Fraunhofer IESE Rep.

    (2003)
  • TërnavaXh. et al.

    Early consistency checking between specification and implementation variabilities

  • CzarneckiK. et al.

    Cool features and tough decisions: A comparison of variability modeling approaches

  • TurnerC.R. et al.

    A conceptual basis for feature engineering

    J. Syst. Softw.

    (1999)
  • CzarneckiK.

    Overview of generative software development

  • RabiserR.

    Feature modeling vs. decision modeling: History, comparison and perspectives

  • TërnavaXh.

    Handling Variability at the Code Level: Modeling, Tracing and Checking Consistency

    (2017)
  • BachmannF. et al.

    Variability in Software Product LinesTechnical Report CMU/SEI-2005-TR-012

    (2005)
  • FritschC. et al.

    Evaluating variability implementation mechanisms

  • SvahnbergM. et al.

    A taxonomy of variability realization techniques

    Softw. - Pract. Exp.

    (2005)
  • BassettP.G.

    Framing Software Reuse: Lessons From the Real World

    (1996)
  • Cited by (1)

    View full text