Customized Product Copies
2. Foundations
2.3. Software Variability
2.3.3. Variability Implementation
2.3. Software Variability
{complete, disjoint} {complete, disjoint} {complete, disjoint}
Variant
Internal Variation Point
External Variation Point
Alternative Choice min max
Optional Mandatory Artefact
Dependency
VP Artefact Dependency Requires
VP_VP
Excludes VP_VP
Excludes V_VP Requires
V_VP
Excludes V_V Requires
V_V
Variation Point to Variant Constraint Dependency
Variant Constraint Dependency Variation Point
Constraint Dependency
{complete, disjoint}
Variability Dependency {complete, disjoint}
Development Artefact Variation Point
constrains constrains constrains
part of 2..n
0..1
0..n
1..n 0..n 0..n 0..n 0..n
0..n
1..n 1..n
0..n
0..n
0..n
realisedby
represented by
Figure 2.6.:Orthogonal Variability Model by Pohl et al. [149]
Variability Realization Technique vs. Variability Mechanism In the literature, the terms “Variability Realization Technique” [183, 72] and “Vari-ability Mechanism” [22, 171, 68] are used to describe concepts of how to implement variability. These terms are not clearly distinguished in the literature. For example, Clements and Northrop [33, page 69] refer to the
“techniques” defined by Jacobson et al. [88, page 102] and repeated by Svahn-berg and Bosch [182, page 150] as “Mechanisms for achieving variability”.
However, the former is used more frequently for concrete variability im-plementations, while the latter often describes more general concepts of software engineering such as “inheritance” or “generation” (e.g., Jacobson et al. [88, page 102]).
Within the SPLEVOapproach, the terms are explicitly distinguished accord-ing to Definitions 1 and 2. In this thesis, the termVariability Realization Techniqueis used for general software engineering techniques or concepts and the termVariability Mechanismfor concrete forms of variability im-plementation.
Definition 1 (Variability Realization Technique) AVariability Realization Technique is a general software engineering technique or concept capable of implementing variability. Examples for Variability Realization Techniques are “inheritance”, “code generation”, or “dependency injection”.
Definition 2 (Variability Mechanism) A Variability Mechanism is a con-crete way to realize variability. It is technology-specific and, for example, uses programming-language capabilities to evaluate a configuration and decide for a variant to execute. Examples for Variability Mechanisms are If-Else conditional statements in Java [70, page 372] or dependency injections with Google Guice [187].
In the field of object-oriented languages, different techniques and mechan-isms exist to implement variability as described below.
2.3.3.1. Variability Techniques
Many different classifications for structuring the field of variability tech-niques in context of software reuse and SPL have been proposed. The most widely used classification was proposed by Jacobson et al. [88, page 102] in
2.3. Software Variability
the context of software reuse and is presented in Table 2.4. Others such as Svahnberg and Bosch [182, page 150] and Clements and Northrop [33, page 69] reused this classification in context of software product lines.
This classification of variability techniques has been designed to cover and structure variability implementation with a top-down approach. It aims for supporting decisions about the general software engineering technique to be used for implementing variability. However, it does not provide guidance for developers and architects to choose a concrete variability mechanism to implement a specific variation point, such as how to realize a concrete configuration mechanism. As identified by the descriptions included in Table 2.4, the categories of this classifications are abstract and each of them identifies a variety of mechanisms.
2.3.3.2. Variability Mechanisms
Variability mechanisms provide guidelines how to implement variability. For example, a variability mechanism can be about implementing a conditional execution in a Java method with an IF-statement that evaluates a property of a Java properties file. Thus, variability mechanisms are specifications of variability techniques.
A variability mechanism defines how a variant is chosen as well as how the according configuration is evaluated. Thus, variability mechanisms cover generic as well as custom mechanisms. For example, the Java example above can be used in any Java-based application. In contrast, a company might have defined a custom license mechanism to be evaluated at run time. This requires a custom variability mechanism as well.
Thus, there is a theoretically unlimited amount of variability mechanisms and there is no general classification of mechanisms available. However, context-specific descriptions of concrete variability mechanisms exist, such as provided by Schnieders and Puhlmann [171].
Technique Time of Specialization Description
Inheritance At class definition time Inheritance is used when the variation point is a method that needs to be implemented for every plication, or when an ap-plication needs to extend a type with additional func-tionality.
Extension At requirements time One use of a system can be defined by adding to the definition of another use.
Uses At requirements time One use of a system can be defined by including the functionality of another use.
Configuration Previous to run time A separate resource, such as a file, is used to special-ize the component.
Parameters At component implementa-tion time
A functional definition is written in terms of un-bound elements that are supplied when actual use is made of the definition.
Template Instanti-ation
At component implementa-tion time
A type specification is written in terms of un-bound elements that are supplied when actual use is made of the definition.
Generation Before or during run time A tool produces defini-tions from user input.
Table 2.4.:Classification of variability techniques proposed by Jacobson et al. [88, page 102] and summarized by Clements and Northrop [33, page 88]
2.3. Software Variability
2.3.3.3. Limitations of Variability Techniques and Mechanisms In addition to provided variability characteristics, individual variability tech-niques and mechanisms come with technical limitations. Developers and architects must consider those limitations when deciding how to implement variability.
For example, Kästner et al. [92, 93] report limitations of Aspect Oriented Programming (AOP) they have identified within a case study. They describe difficulties with statements in the middle of methods and accessing local variables. They mention that some limitations result from AspectJ as a concrete technology used for AOP, but some limitations relate to AOP in general. In addition, Gacek and Anastasopoules [64, page 5] report about the shortcoming of AOP to not support run time variability.
2.3.3.4. Granularity
Variability techniques and mechanisms can exist on different levels of granu-larity in terms of software elements. Apel et al. [7, page 59] distinguish three levels of granularity: coarse, medium and fine-grained (Table 2.5). While the first two are not ordered and can be referenced explicitly, variability on a fine-grained level is more difficult to handle but allows for significant code reduction. Apel et al. [7] also refer to Kästner et al. [93] and Liebig et al.
[118], who stated “that feature implementations take place at all levels of granularity”.
Granularity Description
Coarse Grained Classes and above such as new files Medium Grained Members (e.g., fields and methods) Fine-Grained Statements and below
Table 2.5.:Variability granularity types defined by Apel et al. [7]
2.3.3.5. Delta-Oriented Programming
In addition to the feature-oriented programming approach for implementing variability, Schaefer et al. [167] propose an approach named delta-oriented programming.
Feature-oriented programming focuses on the features to be realized and exists as additive and subtractive strategies which relate to positive and negative variability described in Section 2.3.1.3.
In contrast, delta-oriented programming focuses on the differences between the core of the SPL and the concrete products. A delta-oriented approach uses transformations to modify the SPL core to achieve the intended product instance. Thus, the application engineering phase (Section 2.2.1.3) is realized in a transformation-driven manner.