Variability Issues in Software Product Lines - Springer Link

Variability Issues in Software Product Lines Jan Bosch1, Gert Florijn2, Danny Greefhorst3, Juha Kuusela4, J. Henk Obbink5, and Klaus Pohl6 1 University

of Groningen, Dept. of Computing Science, Groningen, The Netherlands. .ER&SWGL$GWVYKRPLXXT[[[GWVYKRPbFSWGL 2 Software Engineering Research Centre, Utrecht, The Netherlands JPSVMNR$WIVGRPLXXT[[[WIVGRP 3 IBM Global Services, Computerweg 8, Amersfoort, The Netherlands KVIIJLSVWX$RPMFQGSQLXXT[[[MFQGSQWIVZMGIWRP 4 Nokia Research Center, Helsinki, Finland NYLEOYYWIPE$RSOMEGSQLXXT[[[RSOMEGSQ 5 Philips Research ,IRO3FFMRO$TLMPMTWGSQ 6 University of Essen, Software Systems Engineering, Essen, Germany TSLP$MRJSVQEXMOYRMIWWIRHILXXT[[[WWIYRMIWWIRHI

Abstract. Software product lines (or system families) have achieved considerable adoption by the software industry. A software product line captures the commonalities between a set of products while providing for the differences. Differences are managed by delaying design decisions, thereby introducing variation points. The whole of variation points is typically referred to as the variability of the software product line. Variability management is, however, not a trivial activity and several issues exist, both in general as well as specific to individual phases in the lifecycle. This paper identifies and describes several variability issues based on practical experiences and theoretical understanding of the problem domain.

1 Introduction Software product lines (or system families) provide a highly successful approach to strategic reuse of assets within an organization. A standard software product line consists of a product line architecture, a set of software components and a set of products. A product consists of a product architecture, derived from the product line architecture, a set of selected and configured product line components and product specific code. Software product lines come in many different forms. In some cases, the architecture of the product line is used by all products without being adapted, whereas in other cases the product architectures may deviate substantially. Similarly, in certain cases, there is exactly one, configurable, component implementation associated with each F. van der Linden (Ed.): PFE-4 2001, LNCS 2290, pp. 13–21, 2002. © Springer-Verlag Berlin Heidelberg 2002

14

Jan Bosch et al.

architectural component, whereas in other product lines, multiple component implementations exist for an architectural component. The different forms discussed above exploit different variability mechanisms for describing the differences between the products. In our discussion, we will consider variability in the space dimension, e.g. a component is used in multiple products but needs to exhibit different behaviours, and the time dimension, i.e. a software artefact evolves over time. As we will see, the same mechanisms are used for achieving both dimensions of variability. In software product lines, variability is made explicit through variation points. A variation point represents a delayed design decision. When the architect or designer decides to delay the design decision, he or she has to design a variation point. The design of the variation point requires a number of steps, i.e. the separation of the stable and variant behaviour, the definition of an interface between these types of behaviour, the design of a variant management mechanism and the implementation of one or more variants. In the lifecycle stages before the design of the variation point, we consider the variation point to be implicit. At or after the stage at which the variation point is designed, the variation point is explicit. An explicit variation point can be bound to a particular variant. For each variation point, the set of variants may be open, i.e. more variants can be added, or closed, i.e. no more variants can be added. Within the existing set, different variants can be bound. Finally, a variation point can be permanently bound, i.e. one variant has been bound permanently.

Dom ain engineering

variability

Í

tim e analysis

design

coding

com pilation

linking

distribution installation

start-up

run-tim e

distribution installation

start-up

run-tim e

Í

Application engineering

variability

Í

tim e analysis

design

coding

com pilation

linking

Í

Fig. 1. Managing variability in time

Software development in software product lines can be viewed as being organized in two stages, i.e. domain engineering and application engineering. Domain engineering is, among others, concerned with identifying the commonality and variability for the products in the product line and implementing the shared artefacts such that the com-

Variability Issues in Software Product Lines

15

monality can be exploited while preserving the required variability. During application engineering individual products are developed by selecting and configuring shared artefacts and, where necessary, adding product-specific extensions. The variability of the software artefacts evolves according to Figure 1, i.e. during domain engineering new variation points are introduced, whereas during application engineering these variation points are bound to selected variants. The aim and contribution of this article is to identify and discuss the core issues of variability management. These issues were identified during a discussion group meeting at the ESAPS1 derivation workshop in Bad Kohlgrub held in April 2001. We believe that by increasing the awareness of these issues, practitioners are better able to avoid some of the difficulties associated with software product lines whereas these issues present a research agenda to the academic and industrial researchers. The remainder of this paper is organized as follows. In the next section, we describe a number of general issues. Section 3 discusses the issues associated with the identification and design of variability during domain engineering whereas section 4 discusses the resolution of variation points during application engineering, especially concerning run-time. Section 5 discusses the evolution of variability. Related work is discussed in section 6 and we conclude in section 7.

2

General Issues

The variability in a software product line is a concern in all phases of the life cycle. Most variability management issues are specific for each life cycle phase,. In this section we discuss the general issues.

• First-class representation: Most of the modelling mechanisms for variability do not have a first-class representation for features and variation points. As a result, it is difficult to see the variability at the requirements and realisation level. In particular, it is difficult to assess the impact of changes. There is a need for a standard process, notation and exchange format for describing variability within different modelling mechanisms. • Implicit dependencies: Dependencies between architectural elements and features are seldom made explicit. As a result it is often not clear what parts of the productline architecture are needed for a specific product. • Tool support: The number of variation points and associated variants as well as the dependencies may be so high that the effort required for managing these manually becomes prohibitive. Consequently, tool support for automatically maintaining variability information is critical. Current software configuration management tools were developed with the aim to support versioning rather than to support variability and, consequently, fail to support important features, in particular related to variability management in phases different from compilation and linking. 1

ESAPS (Engineering Software Architectures, Processes and Platforms for System-Families) is a European Eureka/ITEA project. For more information, see www.esi.es/esaps/esaps.html.

16

Jan Bosch et al.

• Phase selection: As we discussed in the introduction, variation points are introduced, extended and bound at particular phases in the lifecycle. Selection of the optimal phase for each of the aforementioned activities has a considerable impact on the flexibility of the system as well as the development and maintenance cost. However, we lack methods, techniques, guidelines and heuristics for trade offs between different alternatives. • Mechanism selection: Variability mechanisms are often chosen without consideration for specific advantages and disadvantages of specific mechanisms. Discovering late during development that the wrong mechanism was chosen, e.g. because a certain quality attribute appears to be violated, can be very costly. In our experience, developers often favour one or a few familiar mechanisms.

3

Domain Engineering

As we discussed in the introduction, the variability required in a software product line is introduced during domain engineering. Domain analysis is performed to understand the required variability. Subsequently, the required variation points need to be designed during architectural and detailed design. Finally, the designed variation points are constructed during the implementation phase. In the list below, we first discuss the main issues that play a role during domain analysis:

• Stakeholder concept overlap: Stakeholders often assign a different meaning to domain concepts, which can obfuscate feature semantics. Formal methods may be needed for specifying feature semantics. • Over-generalisation & over-trivialisation: Two issues frequently surface when a domain analyst performs an analysis of a new domain. First, there is a tendency to over-generalize the domain because the analyst does not yet understand the exact variability needs of the product line. Second, a domain is typically over-trivialised because the intricate details of the domain and the domain specific variability is not sufficiently understood. • Binding time selection: Although the domain experts often succeed in identifying the commonality and differences between different products in a software product line, they generally fail to specify an earliest binding time. As a consequence, software engineers may, during later phases, make an incorrect decision concerning the binding time. If the variation point is bound too early, flexibility of the product line artefacts is less than required. If the variation point is bound later than necessary, the resulting solution is more costly than necessary. The following issues with respect to the design phases were identified:

• Oversimplification: We have seen several cases where the software architect oversimplifies the design of the variability mechanisms. Typically, in such cases, all variability is mapped to one mechanism, i.e. alternative component implementations or #define constructs. Although focussing on one or a few mechanisms simplifies the resulting design, the drawbacks of the selected mechanisms are not always understood.


17

• Mechanism impact: Directly related to the above is the fact that, in our experience, software architects typically lack an awareness of the advantages, cost and impact of variability mechanisms. Because of this, software architects do not explicitly select the most appropriate variability mechanism for each case, but rather rely on earlier experience and subjective understanding. • Ιnflexible flexibility mechanisms: Each variability mechanism has an associated design and binding time that often is rather rigid. If a variation point should be bound earlier or later, the variability mechanism used has to be replaced with another one. This is an effort consuming activity since the variability mechanism tends to become intertwined with the other functionality. • Resource awareness: It is very difficult to predict the exact consequences of using a variability mechanism. In particular, the impact of certain mechanisms on resource-usage is often not known during design. The consequences of variability mechanisms, for example on the performance of a product, often do not become visible until run-time. Changing the variability mechanism at such a late moment in time may be costly. Once the variation points have been designed, these need to be implemented. We have identified the following issues:

• Scattering variation points: Variability at the requirements level often does not map nicely onto programming language code. This misalignment is known as scattering and tangling, which causes features to be scattered over the parts of the system, and multiple features to be tangled within one piece of the system. As a result, finding all code that belongs to one feature, a necessity for maintenance, becomes a real nightmare. There is a need for mechanisms that enable a good separation of concerns (features). Aspect-oriented mechanisms [9, 12] could provide an answer, but still have to be proven in practice. Even with the appropriate mechanisms, getting the right separation of concerns can be difficult.

4

Application Engineering

During application engineering, the shared product line artefacts are derived, i.e. selected and configured, for the construction of software products. In our experience, the general trend is to bind variation points as late as is possible, considering the cost associated with variation point management. This is because adding, discovering and binding variants at a late moment in time allows for a great deal of flexibility. It can prevent having to modify, rebuild, re-deploy, or even restart a software product upon certain types of addition or change. In the extreme case systems can even be composed at run-time [10]. Although issues exist with all phases of application engineering, we will focus on the issues associated with managing late-bound variability. In the remainder of this section, we discuss the issues deemed as being of primary importance:

18

Jan Bosch et al.

• Resource cost: One of the main issues is the impact on the amount of resources needed such as memory, network bandwidth and CPU cycles. The cause of this resource-need is that postponing binding means having to transport, store, load and run products that still contain all possible variants. The discovery and binding of variants also requires computational resources. Finally, mechanisms operating at a late moment in time, run-time mechanisms in particular, often require extra overhead. As an example consider mechanisms such as reflection, dynamic linking, dynamic invocation and interpretation. • Predictability: The predictability of the quality of the product is also negatively affected, because the exact configuration is not known beforehand and thus cannot be tested. A large amount of variability may make it virtually impossible to test all combinations during development. Mechanisms may be needed that allow testing at a late moment in time and that ensure the consistency of the product. • 3rd party variants: Third party variants added after construction of the product may be harder to trust; they may break the security or the reliability of the whole product (a chain is as strong as its weakest link). Certification mechanisms, such as the Authenticode mechanism used for ActiveX controls, could be used to make sure that a component can be trusted. Also sand box architectures, such as found in the Java environment, could help prevent unauthorised operations from being performed. • Development resources: Variability mechanisms that operate at a late moment in time generally require developers to write more code to handle the variability. As an example: effort is needed to transform a class into a dynamically linked Microsoft COM object. Also reducing the risks associated with the previous issues may require extra work from developers. • Implicit context dependencies: There is often no explicit representation of dependencies to elements needed in the target environment. This may cause a variant that was added during run-time to fail because the elements that it depends upon are missing. If dependency-information was explicit then a message could be generated, or the necessary elements could be installed on demand. • Reliability: The impact of variants that are added during run-time to a software product is often unclear. Addition may be prohibited at certain moments in time. Threads may need to synchronise before addition is allowed, and the state of the existing variant may need to be transferred.

5

Evolution of Variability

A central issue in the management of variability in software product lines is the evolution of variability. One can identify a number of typical evolution patterns that may occur during the life time of a software product line. Below, we discuss these patterns:

• New variation point: The first type of variability evolution is the introduction of a new variation point into an existing software artefact. This typically requires substantially more effort than the introduction of the variation point during initial development. Introducing a variation point is performed in the following steps. First,


•

•

•

•

•

19

the exact functionality that needs to be made variable needs to be identified in the software artefact. Second, an interface and associated protocol needs to be defined between the remaining and the variant behaviour. If the variation point is bound during installation or run-time, software for managing the variation point needs to be developed as well. Thirdly, the variant behaviour needs to be re-implemented as a component adhering to the specified interface. Finally, new variants can be implemented. Change binding time: A frequent evolution pattern is to change the binding time of a variation point. Typically, the binding time is delayed in order to increase the flexibility of the resulting software system. For instance, in mobile phones the selection of the network communication protocol was performed at compile and link time, leading to different products for different protocols. However, more recently, bi- and triple-band phones have appeared that select and bind the communication protocol at run-time. However, binding time can also be changed to an earlier phase. Typically, this is performed to increase the resource efficiency of the system. By removing all but the selected variant from the system and binding it permanently, both memory and computing resources are saved. Change variant addition time: In the introduction, we discussed that the state of a variation point could be open, i.e. new variants can be added, and closed, i.e. only the present variants can be used. A third type of evolution pattern is to change the point at which a variation point is closed. Typically, this requires the introduction of some variation management functionality for the variation point. Change variation point dependencies: Variation points often have dependencies on other variation points. Selecting one variant for one variation point may restrict the set of legal variants in other variation points. In section 2, we discussed that these dependencies normally lack a first-class representation. This complicates matters when dependencies between variation points need to change. For instance, configurations that worked well before may, after the change, suddenly be seize to work correctly. Remove variation point: An evolution of variation points not always identified is the removal of the variation point. This may occur in response to a narrowing of the scope of the product line or because one type of underlying infrastructure has captured market dominance, thereby removing the need to support different infrastructure implementations. Although one can just remove all but one variants and keep the variation point in place, one should be aware of the fact that variation points increase the complexity of the overall software and that, therefore, the actual removal of the variation point may be preferable. Add variants: A final evolution that may be considered not to be an evolution pattern, but rather ‘business as usual’, is the addition of new variants to an existing variation point.

One can identify that the discussed evolution patterns are complicated by the identified issues discussed in sections 2 through 4. However, for reasons of space, we are unable to discuss these relations in more detail as part of this paper.

20

Jan Bosch et al.

6

Related Work

A discussion on commonality and variability analysis, and the supporting FAST method is given by Coplien et al. [1]. They also describe a number of mechanisms such as inheritance, and parametric polymorphism. System family engineering is described by Jacobson et al. [6], where also a number of variability mechanisms are described such as inheritance, uses, extensions, parameterization, configuration and module interconnection-languages, and generation. Feature modeling is described in the feature-oriented domain analysis method FODA [7], and its extension FORM [8] that covers the entire spectrum of domain and application engineering. A more elaborate discussion on feature modeling is given in [3]. Generative programming is presented as a powerful variability mechanism. Schmidt et al. [11] describe a number of patterns that could help in managing variability, such as the Component Configurator pattern that describes how to link and unlink a component at run-time. In earlier work, the authors have studied the concept of variability independently, e.g. Bosch [1], Greefhorst [4] and van Gurp and Bosch [5].

7

Conclusions

The authors have shown that there is a need for explicitly representing variability in the requirements and in the realisation of a software product-line. Also, there should be a better understanding of the space of variability mechanisms and their specific advantages and disadvantages. While mechanisms operating at a late moment in time allow for a lot of flexibility, they are also have a negative impact on the testability, reliability, security, time-behaviour and resource-behaviour of a software product.

Acknowledgements The discussion group that identified the discussed issues during the ESAPS derivation workshop consisted of more persons than the authors of this article. We acknowledge their contributions.

References 1. J. Bosch, Design and Use of Software Architectures: Adopting and Evolving a Product Line Approach, Pearson Education (Addison-Wesley & ACM Press), ISBN 0-201-67494-7, May 2000. 2. J. Coplien, D. Hoffman, D. Weiss: Commonality and variability in software-engineering, IEEE Software, November/December 1999, pp. 37-45. 3. K. Czarnecki, U.W. Eisenecker: Generative programming, Methods, Tools, and Applications; Addison-Wesley, 2000.


21

4. D. Greefhorst, ‘Separating concerns in software logistics,’ Advanced Separation of Concerns Workshop, OOPSLA 2000, October 2000, Minneapolis. 5. J. van Gurp, J. Bosch, M. Svahnberg, ‘On the Notion of Variability in Software Product Lines,’ Accepted for The Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), April 2001. 6. I. Jacobson, M. Griss, P. Jonsson: Software Reuse: Architecture, Process, and Organization for Business Success; Addison-Wesley-Longman, May 1997. 7. K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, A.S. Peterson: Feature-Oriented Domain Analysis, Feasability Study; SEI Technical Report CMU/SEI-90-TR-21, November 1990. 8. K.C.Kang, S.J.Kim, J.J.Lee, K.J.Kim, E.Shin: FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures; Annals of Software Engineering, Vol. 5, 1998. 9. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopez, J.M. Loingtier, J. Irwin: Aspect Oriented Programming; European Conference on Object Oriented Programming (ECOOP), Springer-Verlag, LNCS 1241, Berlin, Germany, 1997. 10. B.R. Schmerl, C.D. Marlin: Versioning and consistency for dynamically composed configurations; 7th International Workshop on Configuration Management, Boston, May 1997. 11. D. Schmidt, M. Stal, H. Rohnert, F. Buschmann: Pattern-oriented software architecture – patterns for concurrent and networked objects, Wiley, 2000. 12. P. Tarr, H. Ossher, W. Harrison, S.M. Sutton: N degrees of separation: Multi-dimensional separation of concerns; In proceedings of the 1999 International Conference on ObjectOriented Programming, p. 107-119, May 1999.