r2 - 16 Jun 2010 - 09:38:47 - KevinVlaanderen

Variability management in software product lines

Introduction
Process description
Example
Further reading

Introduction

Variability management in software products lines is becoming more and more important because of the increasing complexity of software systems. Variability management concerns about managing the commonalities and differences between software products. Variability creates the possibility in a product line to be flexible and support diverse products, reuse parts that are the same in each product and to be able to absorb new features and functionality [3]. It can be said that software without variability is not reusable; therefore reuse requires variability [1]. Well known advantages that reuse can bring are; reduce costs, reduce time-to-market and improve quality. Variability can be retrieved in every abstraction level within the software development process e.g. variability can be implemented in the source code by using an abstract class or within running code by the use of an interface. The earlier variability’s are bound on a high abstraction level the less flexible the system will become, so postponing the variability to a lower abstraction level will make a product more flexible. During product development the number of potential systems decreases until finally at run-time there is exactly one system [1].

The more variability in software the greater the range of contexts that it will support what finally leads to more reusable software. However the amount of variability should be in balance with cost and complexity. Added variability will cost extra development time and make the product more complex.

Background and origins

At the end of the 1960 the idea of reusability by the use of components was already discussed. In the following decades there were several approaches that provided reuse at the level of individual components that could be used as building blocks of new applications.

The first general accepted model that depicted variability was the feature model developed Kang et al. in 1990 [8]. One of the first papers about managing variability in software product lines was written by Bosch et al. in 2000, [9] they adopted the feature model from Griss et al., [10] added binding time and created a framework of terminology with new concepts regarding variability [1]. At the moment almost all concepts and activities regarding variability management are defined, tools are now constructed that support variability management in software product lines. Sinnema et al., [4] designed the COVMOF framework and implemented this by a plug-in for Microsoft Visual Studio 2003, they are currently working on a plug-in for the 2005 version. Bühne et al. [5], realized an implementation in the requirements tool DOORS.

In the following section the activities and concepts as proposed by Bosch et al. and Bühne et al. are put together, explained and depicted in a process-deliverable diagram.

Process description

Opportunistic reuse does not work. Therefore, software needs to be prepared for reuse. To be able to reuse you need variability. The best time to introduce variability is before you design the system [1]. The management of variability can be divided in three different phases; in the first phase the variability is identified, in the following phase the variability is constrained and in the last phase of the process the variability will be implemented.

Identify the variability

The aim of this process is not to come up with a complete specification of the software but rather to identify where the products differ and what is shared by all products. Feature models are an excellent way for modeling the variability. [6] Software development always starts with defining the functional and non-functional (quality) requirements. Within the variability management method, requirements are used as input to identify the variability. The requirements first transformed into features. Features are defined as a unit of change and variability allows change. The features are modeled in a feature diagram by the use of variants and variation points. The variants and variation points are constructed in a tree like manner. Variation points are defined as places in a design or implementation that identify the locations at which variation occurs. They are the central elements in managing variability [4]. On a variation point different variants are connected. One variant is allowed to belong to more then one variation point. A variant forms the design alternative that can resolve the variability. Variants can be seen as concrete products [3]. When all the variation points and variants are defined, then the next step is to identify the product line where they belong to. The last step in identification phase is to add the variation points and variants to the new/existing feature model of a product line [5].

Constraining the variability

Once a variation point has been identified, it needs to be constrained. After all the purpose is not to provide limitless flexibility but to provide just enough flexibility to suit the current and future needs [1]. First the multiplicity of a variant needs to be defined. The multiplicity of a variation point indicates the minimum number of elements of the associated variant set that must be chosen. The following multiplicities are used:

Mandatory: variants that are mandatory must be selected therefore, their multiplicity is 1.

Optional: variants that are optional may be selected and therefore, their multiplicity is 0 or 1.
Alternative variant: by the alternative multiplicity the variants are grouped and labeled as exclusive alternative variant or inclusive alternative variant. By the inclusive alternative variant, at least one variant from a set of variants must be selected, but selecting more is also allowed. By the exclusive alternative variant, only one variant from a set of variants must be selected. Therefore the multiplicity of the inclusive alternative variant is 1 or more, while for the exclusive alternative variant the multiplicity is 1.

In figure 1 there is graphical representation of the multiplicity between variants and variation points. I’ve adopted the graphical feature model notation from [4] however a textual representation defined by Bűhne [5] or an UML notation as defined by Oliveira et al. can be used instead [3].

Figure 1: The notation of variation points

Now that the multiplicity is set, the binding time can be defined. Binding time is a product line lifecycle milestone in which one of the variants associated with the variation point will be chosen. The binding time can be defined at different abstraction layers that are categorized as follow:

Design time: the variation point is resolved during the specification of the product line or of its products.
Implementation time: the variation point is resolved at programming time, before compilation.
Compiling time: The variation point is resolved during the module or library linkage process.
Link time: The variation point is resolved during the module or library linkage process.
Run time: The variation point is resolved at the product line execution time.
Update time: The variation point is resolved during the product line update.

When the variants are bound at a higher abstraction level, the amount of possible future systems decreases. Bosch [1] has point this out by stating that; before the requirements are defined, every system is possible, while at run-time there is exactly one system. In general a single feature at a particular level of abstraction is specialized into a group of less abstract features in the lower level. Or the other way around, variation points in one abstraction layer can realize the variability in a higher abstraction level. When the multiplicity and binding time are defined the last step is to define the state of the variation point. When a variation point is open new variants may be added, while when it is closed no new variants can be added. The state of a variation point may change from one development phase to the next.

Figure 2: The amount of possible system as proposed by Bosch

Implementing the variability

Once the variation points are identified and constrained, the realization technique, dependency and rationale need to be described. Because, there is almost no place on the feature diagram the realization, technique and dependency are usually described in a separated table with references to the variation points and variants. Bosch depicts binding time in the feature diagram while Oliveira et al. chooses to add these to the table.

The realization technique describes the technique that needs to be used to implement the variant. An example of such a technique is a plug-in for visualizations in Winamp. The rationale can help the software configuration manager to make the right choice for which variant to select. The rationale will explain why a variant is mandatory or optional but, also why a variant from a set of alternative variants needs to be selected. Dependencies in the context of variability are restrictions on the variant selection of one or more variation points, and are indicated as a primary concern in software product lines. Dependencies are specified in terms of requires and excludes relations and expressed along the lines of “the binding of variant A1 to variation point A excludes the binding of variant B1 to variation point B”. [4] Dependencies, in many cases can not be stated formally, but have a more informal character (e.g. “these combinations of parameter settings will a negative effect on the performance of the overall software system”.)

When all the three phases are executed, all the current variability’s in the software product line are documented in a clear way. The way of documentation is flexible enough, so that new requirements can be adopted from any phase during the software development process. The benefit of the feature diagram is that it can be easily interpreted by all the managers involved in the software product line development. All the previous mentioned activities and concepts are depicted in figure 3 in a process-deliverable diagram.

Figure 3: Process deliverable diagram

Activity table

Activity	Sub activity	Description
Identify variability	Identify variation points	The gathered functional and non-functional requirements from the process requirement are composed into features. Features are defined as a unit of change and variability allows change. Therefore, the main elements in a feature model are VARIATION POINTS and VARIANTS. On a VARIATION POINT different VARIANTS are connected. VARIANTS are concrete deliverables like a use case or a piece of code. [1]
	Identify the product line	When all the requirements are composed into VARIATION POINTS and VARIANTS. The product line needs to be identified where VARIATION POINTS and VARIANTS belong to. If the product line or set of product lines not already exist a new ABSTRACT PRODUCT LINE needs to be created. [5]
	Add variation points and variants	Now the VARIATION POINTS and VARIANTS need to be added into the new/existing feature model. [3]
Constrain variability	Define multiplicity of variants	When the VARIATION POINTS are defined and a feature model is constructed, they need to be constrained. Each variant has a certain MULTIPLICITY that now needs to be defined. [3]
	Define binding time	The VARIATION POINTS and VARIANTS can be added any-time during the system development process. Therefore, the BINDING TIME needs to be identified for the VARIATION POINTS. [1]
	Define state	When the MULTIPLICITY and BINDING TIME are defined the VARIATION POINT STATE needs to be added. An OPEN STATE means new variants may be added in the future. [1]
Variability implementation	Define realization technique	When the constrains are familiar, the REALIZATION TECHNIQUE for the VARIATION POINTS can be identified. Examples of a REALIZATION TECHNIEQUE are the #define technique in a language like c or a plug-in for Winamp. [1]
Variability implementation	Define rationale & dependency	Now that almost everything is known the DEPENDENCY and RATIONALES can be described. The RATIONALE can help the software configuration manager to make the right choice which VARIANTS to select. Where the DEPENDENCY can describe what happens if a VARIATION POINT will be changed (updated/ removed). [5]

Concept table

Concept	Definition
FEATURE MODEL	Decorated tree that contain features identified for a system family [5]
VARIATION POINT	A concrete point in one of the representations of the software where VARIANTS of an entity can be inserted. Specific place in a product line artifact to which a design decision is connected [3]
VARIANT	Design alternative to resolve the variability [3]
BINDING TIME	The product line lifecycle milestone in which one of the VARIANTS associated with the VARIATION POINT will be chosen. The binding time can be classified as follow: Design: The VARIATION POINT is resolved during the specification of the product line or of its products. Implementation: The VARIATION POINT is resolved at programming time, before compilation. Compiling: The VARIATION POINT is resolved during the module or library linkage process. Linking: The VARIATION POINT is resolved during the module ore library linkage process. Runtime: The VARIATION POINT is resolved at the product line execution time. Updating: The VARIATION POINT is resolved during the product line update [3]
MULTIPLICITY	The multiplicity constrains the VARIANTS of the VARIATION POINTS. And can be classified as follow: MANDATORY: there multiplicity is 1 and those are compulsory, they must be selected. OPTIONAL: optional are VARIANTS that may be selected and therefore there multiplicity is 0 or 1. ALTERNATIVE VARIANT: by the alternative the VARIANTS are grouped in and labeled as EXCLUSIVE ALTERNATIVE VARIANT or INCLUSIVE ALTERNATIVE VARIANT: INCLUSIVE ALTERNATIVE VARIANT: at least one VARIANT must be selected but more is also allowed. There multiplicity is 1..*. EXCLUSIVE ALTERNATIVE VARIANT: at most one VARIANT must be selected. Selecting more then one VARIANT is not allowed. There multiplicity is 1. [3]
IMPLEMENTATION MODEL	Because it’s not possible to depict all the concepts into the FEATURE MODEL a table needs to be added with the extra information about the IMPLEMENTATION MECHANISM, THE RATIONALE and the DEPENDENCY. [5]
IMPLEMENTATION MECHANISM	Is a technique that needs to be used to implement the VARIATION POINT. An example of such a technique is a plug-in for visualizations in Winamp. The IMPLEMENTATION MECHANISM is constrained by the BINDING TIME and is in this example linking. [1]
RATIONALE	The VARIATION POINTS have different VARIANTS that are constraint by there multiplicity. The RATIONALE can help the software configuration manager to select the right VARIANT. In the RATIONALE it can be explained why a variant is MANDITORY or OPTIONAL. But also which of the ALTERNATIVE VARIANTS needs to be selected. [1]
DEPENDENCY	A VARIATION POINT can depend upon another VARIATION POINT. It could be that a VARIATION POINT can only be implemented if another VARIATION POINT is also selected. This is the so called REQUIRE DEPENDENCY. It could also be that when a VARIATION POINT is implemented, that it is not possible to implement another VARIATON POINT. This is the so called EXCLUDES DEPENDENCY. [1]
STATE	A VARIANTION POINT can be OPEN or CLOSED. When a VARIATION POINT is OPEN new VARIANTS may be added. When it is CLOSED no new variants can be added. [1]
ABSTRACT PRODUCT LINE	A product line is a software family where different software products can produced of. It could be possible that different product lines have variability points in common. Therefore there exist the SET OF PRODUCT LINES. An example is a CD and DVD player that have a lot in common. While a TV is completely different and will have its own product line. [5]

Example

To clarify all the text above I will construct an example wherefore the variability management processes could be applied. I have chosen for a portable audio player as a product line. The requirements for such a portable audio player could be: play audio, record audio and visualize audio. These requirements will be transformed into features as depicted in figure 7.

Figure 7: Feature diagram of a portable audio player product line.

To be able to satisfy the requirement play audio, a processor variation point and play audio variant is necessary. For the requirement audio visualization a display variation point and visualization variant need to be present. The processor and audio variation points are mandatory, because without them there won’t exist a portable audio player. The display and plug-in variation points are optional features.
In this example most variation points are open, only the MP3 encoder has a closed state. So, the management has chosen to only allow a low and high quality encoder and it will not be possible to add a medium quality encoder variant to the product line in a later stadium.

The feature diagram is still missing information about the binding time, realization technique, rationale and dependencies. These are presented following tables.

ID	Variation point	Variant	State	Multiplicity	PL
VP2	Audio	-	Open	Mandatory	PAP
V2.1	Audio	Play audio	Open	Mandatory	PAP
VP2.2	Audio	Record audio	Open	Optional	PAP
VP2.2.1	Record audio	MP3 encoder	Closed	OR	PAP
V2.2.2	Record audio	ATRAC3 encoder	Open	OR	PAP
V2.2.1.1	MP3 Encoder	Low quality MP3	Open	OR	PAP
V2.2.1.1	MP3 Encoder	High quality MP3	Open	OR	PAP

ID	Binding-time	Realization tech	Dependency
VP2	Implementation	Interface	Requires a processor
VP2.2	Linking	Linking encoder	Excludes ATRAC3

ID	Rationale
VP2.2.1	To be able to record MP3 a MX 500 processor and a relative large storage will be necessary

The variation point audio will be implemented by the use of an interface that takes care about how to play and record audio. The interface can later bind the encoder by using a linking technique. Dependencies can be useful, like the ATRAC3 encoder may not be implemented in combination with a MP3 encoder, hence of legal regulations. The rationale will speak for itself.