nomically reusable solutions, e.g. wrappers allowing the integration of third party .... later on, i.e. a network support component, has to be integrated into the ...
Comprehensive Variability Modelling to Facilitate Efficient Variability Treatment Martin Becker, Lars Geyer, Andreas Gilbert, Karsten Becker System Software Research Group University of Kaiserslautern D-67653 Kaiserslautern, Germany {mbecker, geyer, gilbert, kbecker}@informatik.uni-kl.de
Introduction Software Reuse is a promising approach to improve the efficiency of software development as regards time, cost and quality. Software development with reuse can be deployed more successful if the assets intended to be reused are developed for reuse to treat the typical problems (search for matching reusable artefacts and adaptation of found artefacts to the given problem) in a systematic and planned way. A reasonable approach that addresses these challenges within limited domains is system family engineering, especially product line software engineering. The rationale of system family engineering is to identify common core functionality which can be implemented once and reused afterwards for all members of the system family. In order to exploit this reuse potential, the construction of reusable artefacts has to be pre-planned. Therefore system family engineering comprises two major tasks. The first of them – often called domain engineering – is concerned with the engineering of the system family, i.e. constructing a reuse infrastructure. It defines the scope of envisioned family members, analyses the requirements and finally implements reusable artefacts – e.g. a common architecture or components – implementing common as well as variable requirements according to their reuse potential. These artefacts are used in the second task – the application engineering – to facilitate the derivation of concrete system family members. Ideally, during the adaptation phase only very specific requirements of the envisioned product cause further development effort to complete the specific product. In principle, common requirements among all family members are easy to handle; they simply can be integrated into the family architecture and are part of every family member. But intricate problems arise from the treatment with variable requirements. They aggravate the development of reusable artefacts as they necessitate sound approaches to handle the miscellaneous realisations in the affected artefacts efficiently. Interdependencies resulting from the overall impact of such variable requirements further complicate the treatment of variability as they have to be considered during the elicitation of application requirements and the subsequent derivation of the configured applications. Obviously, dealing with the variabilities brings about crucial issues that are characteristic for system family development.
In this paper we describe our approach to facilitate the treatment with variabilities in system family engineering by explicitly modelling the identified variabilities, their impacts on the reusable artefacts, and all kind of obtained knowledge and assumptions about them. Besides a discussion of the variability related issues, we motivate our variability modelling approach and illustrate the deployment of such models, e.g. to support the development and evolution of generic software artefacts, the configuration and instantiation of family members, and simply to represent the identified variabilities in a domain in a consistent manner. In the next section we present our notion of variability and address some related issues. In section 3 we motivate the elements of our variability model which is discussed in detail in section 4. Some remarks about the realisation and deployment of such variability models and the required tools support are given in section 5. Some related work is presented in section 6. The paper concludes with some closing remarks and a look into the future in section 7.
Variability Related Notions and Issues A system family is a set of systems which have so much in common, that it is worthwhile to study the common parts of all systems before analysing the variable properties of the single systems [Parn76]. A commonality thereby is a quality that all applications of a system family have, thus making the commonalities the elements with the highest reuse potential. In contrast, a variability represents a capability to change or adapt a system, i.e. it abstracts from the varying but coherent qualities of the considered systems to capture them in common but generalized artefacts, on the one hand, and controls the derivation of the family members from that artefacts, on the other. Variabilities can be seen as parameters that support a more concise identification of systems in a system family. They describe the alternative solutions which can be selected for the specific applications. Concerning the range of values a variability offers to specify the characteristics of a family member three different types of variabilities can be found: discrete, continuous and abstract. A discrete variability offers a set of possible features, from which a subset can be chosen Table 1. Example for the multiplicities of discrete variabilities. for the specific applications, e.g. the set of Variability: SupportedNetworks = {Ethernet, CAN, Token-Ring} network types supMultiplicity Valid Choices ported by an applica0..1 (Option) {},{Ethernet}, {CAN}, {Token-Ring} tion. Often restric1 (Alternative) {Ethernet}, {CAN}, {Token-Ring} tions regarding the 0..n (Option Set) {}, {Ethernet}, .., {Ethernet, CAN}, .. number of features in the chosen subset 1..n (Mandatory Option Set) {Ethernet}, .., {Ethernet, CAN}, .. have to be expressed, e.g. the variability may offer a set of options or alternatives. These restrictions are called the variability's multiplicity. An example discussing the most important ones is listed in table 1. A continuous variability represents differing realisations that can be parameterised by a numeric interval out of which the actual value of the variability is
chosen. The selected value may be a single value or a subinterval, e.g. the number of instances in a system (cf. example below). An abstract variability can be used if the two aforementioned types do not offer enough expressiveness. This may be due to gaps that have to be filled by complicated generators or with unknown or not economically reusable solutions, e.g. wrappers allowing the integration of third party components, or customer specific modifications of the systems. The range of valid values for such variabilities can be constrained through specifications provided with the variability, e.g. the language to use, or pre- and post-conditions. Variabilities further can be classified as qualitative or quantitative. A qualitative variability determines the presence of features or qualities in an application. These variabilities typically are addressed in feature models. On the other hand, quantitative variabilities represent variations in the number of instances of an entity type in the applications. They are often ignored in classical feature modelling techniques as FODA [Kang90], for instance. If the entity type is affected by further variabilities that have to be chosen for each instantiated entity in the application independently, then number of variabilities to be considered for a system family is not fix but depends on Domain Engineering
feedback, adaptions Domain Analysis
Domain Implementation
reference requirements Variability Model
Application Engineering
Domain Design
reference architecture reuseable components
VarX
Application Requirements Engineering
Application Design
Application Implementation
Fig. 1. The importance of the variability model in the context of a system family development process.
the quantitative variabilities. So quantitative variabilities – typically represented by continuous variabilities – may cause a varying number of variabilities. In the building automation domain, for example, a building contains a set of rooms controlled by the automation system. As a consequence the quantitative variability NumberOfRooms determines the number of room instances for which variabilities like temperature control (automatic vs. manually controlled) have to be specified independently from other instances.
A further important issue on variabilities is that they are typically not independent of each other: variability A can restrict the range of possible values of variability B (so-called requires or excludes relationships), or variability C is only relevant and therefore should only be visible if some characteristic has been chosen for variability D. Neglecting those interdependencies – especially the first mentioned – during the configuration of the application diminishes reuse benefits and can cause severe problems due to inoperative system realisations. After the discussion of pure variability-related issues, we now want to concentrate on the more realisation-related aspects. The construction of variability-aware reusable artefacts results in providing variation points that abstract from the specific realisations of the family members. Such software artefacts offering variation points are called generic software artefacts (GSA) in the following. To derive a concrete artefact deployable in application engineering each variation point in a GSA has to be resolved by a specific realisation based on the knowledge about the variabilities identified by the system family. To this end the resolutions are parameterised by the variabilities, i.e. the variabilities are used to specify the family member under development. The reuse infrastructure of a s system family can comprise GSAs for all kind of work products used in application engineering, e.g. architectural views, component code, or requirement models. It has to be pointed out, that variabilities often affect GSAs on several layers of abstraction as illustrated in figure 1, which shows the relations between variabilities, variation points, and GSAs in the context of the product family engineering process [ESAP99]. Ideally, the construction of an application from a system family starts with binding the offered variability, followed by the derivation of the configured system from the provided GSAs. But this scenario is far too optimistic most of the time, due to unknown or changing customer requirements, that lead to postponed decisions and iterations in the application engineering process. Realizing this inevitably leads to the question of binding time, i.e. the process phase a variability is assigned to a concrete value, and the implications on the resolution of the variability, which will be discussed in the following. The application engineering process can be separated into at least three major phases: requirements engineering, design, and implementation. Each GSA of a system family is associated to one of these phases, i.e. the GSA is instantiated and adapted during the execution of this phase and may be used in the following phases. As a consequence for each variation point of a system family it is clear in which process step the variation point is resolved to a concrete solution. In contrast to variation points, variabilities have no own pre-defined binding time, instead they may be in principle selected at any time during the application engineering process. There may be one alternative for a variability which requires a specific component that has to be integrated into the system during the architectural design, other alternatives allow to postpone this decision to a later process step. If the variability is selected, the associated variation points of the current binding time are bound to a specific solution, but also all variation points in GSAs which are relevant in later steps of the process are bound by the decision. On the other hand, if the variability is not selected, the variation points of the current binding time are also bound to a solution which allows the resolution of the variability, e.g. the integration of another alternative, in a later process step. To illustrate this, regard the network support example,
used above. Typically network support is realized by a component that is or is not integrated into the architecture of an application. Therefore, the architectural description contains a variation point which allows to integrate or leave out the network component. The first binding time, in which network support should be considered is therefore the architectural design. For some reasons it may be necessary to postpone the decision to a later process step. In this case, a solution to handle the variability later on, i.e. a network support component, has to be integrated into the architecture. In a later process step this component may be implemented with no internal functionality in the case that network support is not needed. However, due to the variations point resolutions in the GSAs it sometimes is favourable to allow the restriction of possible process steps a variability can be bound. By stating a latest binding time along with a variability, it can be clearly expressed that the affected GSAs only can handle the variability up to specified process step and that a decision has to be taken, if the variability is still unbound at that time. This section already gave a first impression about the possible bandwidth of variability-related information and the issues raised by the treatment with variabilities. To further motivate the need for a supportive variability model, the next section discusses some scenarios of system family engineering in which such a model can be beneficially deployed to facilitate the efficient and consistent handling of variability.
Deployment Scenarios for the Variability Model Variability, if explicitly considered during software development, as done in system family engineering, affects all phases of the corresponding development processes. As revealed above, a lot of knowledge and heuristics according the variabilities, e.g. their origins, range of values, interdependencies, associations to variation points etc., are gained and required during system family engineering to handle the variabilities efficiently and above all in a consistent manner. In principle, this information can be represented directly within the GSAs, if at all. But this would lead to redundant representations and would foster inconsistencies. Therefore, we favour a uniform variability model that can be applied throughout the development processes. As an explicit carrier of all variability-related information, it enables consistent and comprehensive variability representations. To further motivate the use of such extensive variability models, some typical deployment scenarios are presented in the following. During the domain analysis, the first phase of domain engineering, the emerging variability model is a means to represent the scope of the target domain by determining the range of values for the identified variabilities. For discrete variabilities each characteristic can be discussed for its reuse potential or relevance for the system family and its origins can be recorded. To increase the comprehensiveness of the modelled variabilities, an informal description and a classification should to be included. In the domain design phase, the variability model is the place of choice to record the dependencies of the generic software artefacts under design and the variabilities they adhere to. Already identified interdependencies between the variabilities in the variability model give valuable hints about the interdependencies of the generic software artefacts on the different levels of abstraction. The dependencies of generic
artefacts on the same abstraction level are implicitly represented through the associations of the variabilities with the GSAs and the dependencies among the variabilities. Information concerning the default values or strategies reflecting recommended binding sequences also should be captured in the variability model. Doing so, the variability model helps to preserve underlying domain knowledge and assumptions and can be used to validate the evolving design against the identified requirements in the domain. In the domain implementation phase, the variability model specifies the range of required genericity in the generic software artefacts and lines out the realizations. The implicit links to the corresponding variation points in other already implemented artefacts and the specification of the interdependencies between the variabilities facilitate the consistent realization of the variability throughout the different artefacts. A classification of the offered variability's resolution support can be used to state the required skills and knowledge to derive concrete artefacts from the generic ones. If the domain and in consequence the variabilities have to be evolved, the variability model also can provide supportive information, e.g. bi-directional links between the variabilities to their origins (e.g. the varying requirements) to support the assimilation of unforeseen adaptations during the application engineering. Links from the variabilities to the affected variation points and their average complexity can be exploited during change impact analysis. Finally, information about the maturity of a variation point can yield valuable information for the resolution support of a variability. In the application engineering process, the decision related part of the variability model – the decision model – in combination with the feature model, which may itself be influenced by the variability model, is the entry point for the application development. Here, the provided knowledge and heuristics regarding the variabilities, i.e. the range of supported values, the default values, the interdependencies and the strategies, but also information about the origins and the evolution of a variability can favourably be used to facilitate the consistent decision taking. The complexity of the decision taking in the different process phases can be reduced by determining the relevance or visibility of a variability for that phase. Finally, the links from the variability model to the artefacts are used to propagate the parameters into the artefacts to derive of the configured artefacts.
Variability Model Inspired by the aforementioned deployment scenarios and our experience in the area of decision and feature modelling [Geye00][Baum00], we have developed the variability model presented in figure 2. The variability model itself has an ID and a version number for management reasons. As central elements, the variability model comprises a set of variabilities. A variability is identified through its ID, but can also be identified through its name, if it is unique. To this end, hierarchical namespaces have been introduced into the variability model. A variability may define a namespace (namespace equals the full name of the variability) and may belong to one, in which case its full name will be the namespace concatenated with its name. To increase the
VariabilityModel ID Versi on
0..1 NameS pace
Strategy Name Descripti on
1
defines
n
1
Variability 1..n 1..n controls ID 0..1 Name +Predecessor 1..n Description Type n Sequence Origin +Successor 1..n 1..n belongs to
Variati onPoint
GSA n
Res olut ion Skill Compl exity
instantiated at Hierachy
latestBT
Dependency Type Description Origin
1..n 1.. n
Constraint
Opt ionalRange Included : Boolean
1
1
Range Default
0..n
1..n
DiscreteRange Multiplicity n Cat egories
rest ri cts
ContinuousRange Type LowerBound UpperBound
1
Bi ndi ngTime 0..n
AbstractRange Specification
Name Description Origin Relevance
Fig. 2. The variability model.
comprehensiveness of the model a general description and the type of the variability can be specified. As stated above, links to the origins of the variabilities are advantageous in case of evolution. If those links are specified in a computable form, this information can be used by supportive tools facilitating the economical and above all consistent evolution of the GSAs. The range of possible values for a variability together with the specification of the default value is represented through its range (abstract Range class in the model) from which the distinguished range types are derived. A OptionalRange classifies its variability as a simple option, for which it can decided, if it is included in the application under development or not. A DiscreteRange enumerates the set of possible choices (Categories) and determines the multiplicity of the decision. Each category has name, a description, and a may have links to its origins, in addition. The relevance attribute can be used to represent the reuse potential of the category, which can be used to assess the resolution effort to be spend for the corresponding variation points. Notice that the OptionalRange has been added for convenience; it can be also modelled through a DescreteRange with yes/no categories. To specify a ContinuousRange the type – integer or real so far –, a lower and an upper bound for intervals has to be provided. Finally, with AbstractRanges any specifications to restrict the range of values can be given.
To support the resolution of the variation points in the generic software artefacts, the first ones are associated with the variabilities they adhere to. For each variation point some additional information about the resolution can be provided. The skills required to resolve the variation point in the corresponding generic software artefact can be specified with the skill attribute. With this, the selection of appropriate generic software artefacts can be supported in case one has to chose one of several potentially deployable artefacts. The complexity attribute is intended to inform about the average complexity of the variation point's resolution. It can be used to roughly estimate change impacts in case of evolutionary considerations, e.g. the addition of a new variant. As modelled, the relation between the variabilities and the variation points can be n:m. The adherence of a variation point to many variabilities offers the possibility to provide less variation points. The binding time of a GSA, i.e. the sub-process its variation points have to be resolved, is specified for the GSA. For a variability the latest binding time can be stated. The two different types of interdependencies (Depend class) motivated above are distinguished: Constraints and Hiearchies. Constraints represent restrictions in the ranges of possible choices as Service.Email requires TCPIP in Network.Protocols, for instance. They limit the set of operable members that can be derived from the system family. Hierarchies can be used to express the conditional visibilities of variabilities, like Network.Support.yes enables Network.Protocols. With both types of interdependencies a type, a description, and an origin can be provided. Finally, recommended strategies to fix the variabilities can be specified. They partially order the set of variabilities by so-called sequences. Hereby, sequences state that all predecessors have to be chosen before the successors should be taken into consideration. As several strategies may be denoted in the variability model, they can be identified by their name and can provide a description of the intention behind the ordering.
Realization of the Variability Model After the presentation of the conceptual elements of our variability model, some words about the realisation and deployment of such variability models have to be said. The variability model of course can be realised in different ways: plain text, database, or XML-based realisations are sound approaches. As long as the variability model can be economically handled we favour XML-based realisations, for the clear data-structure, the extensibility, the extended linking support, and finally the available tools offered with the eXtended Markup Language [W3C01]. In case of huge variability models hybrid or pure database realisations of course offer a better performance. The decision-related information in the variability model has been formatively influenced by the design space technique [Lane90], which has extended in [Baum98]. We have already successfully deployed this technique for decision and feature modelling [Geye00] to support the configuration and instantiation of generic artefacts in product line and component-based contexts [Baum00] in the building automation domain and the operating system domain. By retaining the underlying data models
and extending them with the supplementary variability-related data, we are able to deploy our existing modelling (Reboost) and profiling (D-Space-1) tools also for variability modelling. These tools already have shown their applicability in feasibility studies in industrial product line contexts. With the profiling tool the decision taking, i.e. the configuration of an application in the application engineering process, can be supported to a large extend. After one of the predefined strategies has been chosen, the variabilities with non abstract ranges can be fixed in the specified order. Thereby the tool monitors the interdependencies of the variabilities, presents only the relevant decisions and reports inconsistent selections. The result of such a (iterative) configuration is a profile comprising the selected characteristics for an application, which are represented by variability value pairs. The relevant generic artefacts required to construct the configured can be determined from the variability model by inquiring all generic artefacts associated with the fixed variabilities in regard to their binding time. No special treatment is required for the artefacts that solely realize commonalities as they are simply included in all applications. In case of abstract ranges, the elicitation of appropriate specifications also can be supported by tools that help to identify the affected variation points and evaluate the predefined restrictions. The resulting specifications are enclosed in the profile, too. Doing so, the profile represents a concise specification of a family member that can be constructed with the generic artefacts. To propagate the actual parameter values into the generic artefacts and finally to resolve the corresponding variation points, almost any generative technique can be deployed to this end. As GSAs can be work products on all layers of abstraction, we are currently investigating XML-based approaches, since they are applicable to any textually represented work product in a uniform way. Our VML (Variability Markup Language) and the corresponding processor are results in the area of product instantiation. As generic software artefacts are more complicated and expensive to develop, information to facilitate the evolution of the variabilities had to be included in the variability model, too. The explicitly represented knowledge and heuristics about the variability, e.g. the elements' origins, the affected generic artefacts and with them the variation points, and the interdependencies are intended to support the consistent evolution of the variabilities and the generic artefacts. Through the representation of this information in a computable way, supportive tools can make use of it. To this end, we are currently investigating techniques that facilitate the evolution and management of such generic artefacts. They are supposed to show the profits that can be yielded by deploying a comprehensive variability model throughout system family engineering.
Related Work Variability modelling is closely related with feature modelling, as both approaches model the differences among a set of systems. Whereas variability modelling concentrates on the variabilities and captures all kind of related information, feature models represent the relevant characteristics of the system members, variable as well as common, but typically do not provide much information beyond than. A classical method of feature modelling is the FODA method discussed in [Kang90]. In this domain analysis method the features are modelled in a hierarchical graph classifying the features as mandatory, optional, or alternatives. An elaboration of this method can be found in [Czar00] where features can also be classified as or-features. Constraints (e.g. requires, excludes), default dependency rules and binding-related information additionally can be expressed within this method. Another approach that directly couples features and variabilities is presented in [Van01]. They represent variabilities throughout the development process with features, which are classified as mandatory, optional, variant, or external. The features are modelled in a hierarchical feature graph using an UML-like notation that also reflects the binding time of the variabilities. This paper also addresses some issues concerning the management of variabilities.
Conclusion and Further Work Variability, if explicitly considered during software development due to family engineering instead of single system engineering, affects all stages in the development processes. A uniform variability model to be applied throughout the development process bears a remarkable potential to increase the efficiency of variability treatment. Besides a motivation for the required information and its structuring, we presented our approach to model the variability-related information in a coherent manner and discussed the deployment of such variability models. Although just starting with extensive variability modelling, our experience with feature and decision modelling in the context of product lines gives us cause for optimism that our approach will be advantageous for efficient and economically product family treatment, especially as phases like configuration, instantiation and evolution can profit directly from such variability models. Our further work in that direction includes the consolidation and validation of the presented approach and the extension of our tool pool to support the modelling and deployment of the variability model with a special focus on the instantiation and the evolution of the generic software artefacts.
References [Baum98] Baum, L.; Geyer, L.; Molter, G.; Rothkugel, S.; Sturm, P.: Architecturecentric Software Development Based on Extended Design Spaces, Proc. of the 2nd ARES Workshop (Esprit 20477), Las Palmas de Gran Canaria, February, 1998 [Baum00] Baum, L.; Becker, M.; Geyer, L.; Gilbert, A.; Molter, G.; Tamara, V.: Supporting Cpmponent-Based Software Development Using Domain Knowledge, Proc. of 4th IIIS World Multiconference on Systemics, Cybernetics and Informatics (SCI2000), Orlando, USA, July 2000 [ESAP99] ESAPS: ESAPS – Engineering Software Architectures, Processes and Platforms for System Families, ITEA Full Project Proposal, June 1999 [Geye00] Geyer, L.: Feature Modelling Using Design Spaces, 1. Deutscher Produktlinien Workshop, Kaiserslautern, 2000 [Kang90] Kang, K.; Cohen, S.; Hess, J.; Nowak, W.; Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report, CMU/SEI90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA, November 1990 [Lane90] Lane, T.G.: Studying Software Architecture Through Design Spaces and Rules, Technical Report, CMU/SEI-90-TR-18, Carnegie Mellon Univ., 1990 [Parn76] Parnas, D. L.: On the Design and Development of Program Families, IEEE Transactions on Software Engineering, VOL. SE-2, No. 1, March, 1976 [W3C01] W3C: Extensible Markup Language (XML), http://www.w3.org/XML/, 2001 [Van 01] Van Gurp, J.; Bosch, J.; Svahnberg, M.: On the Notion of Variability in Software Product Lines, Proceedings of WICSA 2001, August 2001
