User Tools

Site Tools


Variability Modeling


Variability Modeling is to efficiently describe more than one variant of a system. Variability modeling is often closely associated with product lines. The resulting systems are often fairly complex and variations are described explicitly. Variability can be expressed in stand-alone models, such as feature diagrams. Software Product Lines refer to methods, tools and techniques for creating and maintaining a collection of similar software systems from a shared set of software assets.

The intention of variability modeling is to create and manage many variants of a product, also known as mass customization. Variability modeling is regarded as the enabling technology for delivering a wide variety of software systems of high quality in a fast, consistent and comprehensive way. The key is to build a base on the commonalities and efficiently express and manage the variability of the systems.

Variability can also be described in annotations or extensions to the base model, or totally separated out to represent in an independent variability model.

Ways to model variability → Framework/ Configuration Union-of-all-systems Domain Specific Languages
How? By mechanisms of a general language As annotations to a language By the specific language mechanisms
Constructs Function, Type, Inheritance, Template, Plugin Pragma, Stereotype, feature diagram Proprietary language constructs
unforeseen modeling needs Just enhance the final model Enhance the product line model If not expressible, enhance the language

Table 1 Evaluation matrix of ways to model variability[16]

How to Model Variability

Variability models for system families come in different forms:

Variability Expressed by Feature Models

Feature modeling by means of Feature Diagrams (FD) is a popular technique for capturing commonality and variability in Software Product Lines (SPL). It was first introduced by Kang as part of Feature-Oriented Domain Analysis (FODA) in [18] FODA is a domain analysis method that focuses on the “features” of the domain’s systems, where a feature is perceived as an aspect or characteristic of a system that is viable to the end-user. FODA provides a tree-structural notation to model feature level commonality and variability graphically. Features are marked to indicate optional or mandatory by a hollow or filled circle along the sub-feature or containment line. Alternative features are connected with arcs on their lines to indicate XOR decomposition. Also two types of composition rules: requires and mutually-exclusive-with can be declared for how features constrain other features.

Several extensions of FODA FD have been proposed since its initial proposal as part of the following methods: FORM [19], FeatureRSEB [14], Generative Programming [7], PLUSS [10], and also in the work of the following authors: Czarnecki et al. ([9], [8]), van Gurp et al. [23], Batory et al. [1], Benavides et al. [3], van Deursen et al. [22] and Riebisch et al. [21], [20]).

Feature diagrams say very little about how the features are combined into a product. A feature diagram could express that your password policy should contain expiration and a password with certain characters, but this does not tell how the password policy is actually implemented on any given platform. Thus there will normally be a need to combine the feature diagram with an underlying platform, which is often performed manually during realistic software development.

Variability Expressed in relation to a base model

In this form, elements of the base model will become elements of specific models (or not) according to resolutions of related variability models. Two approaches can be distinguished mainly by how much new languages are defined for variability modeling:

  • Annotating the base model by means of extensions to the base modeling language, e.g. UML profiles with stereotypes ([11], [13]). The annotations are input to a model transformation process that produces a system model in the base modeling language that was annotated. The advantage of this approach is that model elements that are subject to variability is clearly marked, while the disadvantage is that base models are intimated with variability specifications.
  • Making separate, orthogonal variability models that apply to a single base model. By using a separate variability language, variability models can be produced after the DSL is put into production without any modification to the DSL itself or the supporting tools. Since the variability is represented in separated models, more than one set of variation points and resolution rules can be expressed for each base model. Since the generator and other tools remain the same, new language concepts cannot be introduced, thus in this sense the DSL needs to be relatively complete and stable. In the project MoSiS there is a language CVL (Common Variability Language) [15] for modeling variability that follows the separate language approach. CVL is still in development, and it is based on the work in the Families project [2]. The MoSiS project aims to produce a variability language and supporting tools for expressing variability in DSLs.

Dynamic Variability

Software systems more and more have to be configurable both before deployment (thus creating different product variants) as well as during run-time (allowing for dynamic adaptations), not at least be-cause they often are integrated into dynamic and ad-hoc networks. Runtime adaptation is becoming a key requirement in many modern software applications ranging from large scale systems of systems to dedicated mobile applications. Such so called Dynamic Software Product-Lines (DSPLs) must intensively use variability transformations at run-time in order to adapt their configuration to a changing context and environment.

Bosch et al. [4] point out several potential problems we may face in traditional static variability handling mechanisms:

  • First-class representation. The knowledge gap between a domain expert and software engineers/programmers leaves the mapping from high level design to low level implementation a critical issue.
  • Traceability. Without traceability support, it requires domain experts to have intimate understanding of the architecture internals to address run-time variability, which in most cases they lack.
  • Implicit dependencies. Since the dependencies between architectural elements are often implicit, it is not often clear that which parts of the product line architecture need to be reused for a specific product.
  • Scattering variation points. Since features may often scatter across any part of the system in implementation code, variability at higher level is not easily and explicitly mapped to the implementation level. Therefore, the resulting code with variation points resolved is not easy to understand for non-programmers.

Several related work has been done to explore possible solution to address run-time variability, as stated in the work of the following authors: Zdun [24], Hoek [17], Bragança et al. [5], Goedicke et al. [12], Cetina et al. [6] and etc.


  1. Batory, D., Chen, G., Robertson, E., and Wang, T.: Design Wizards and Visual Programming Environments for Genvoca Generators. IEEE Transactions on Software Engineering. 26, 441-452 (2000)
  2. Bayer, J., Gerard, S., Haugen, Ø., Mansell, J., Møller-Pedersen, B., Oldevik, J., Tessier, P., Thibault, J.-P., and Widen, T.: Consolidated Product Line Variability Modeling. In, T. Käkölä and J. C. Dueñas, (eds.) Software Product Lines: Research Issues in Software Product-Lines. Springer (2006)
  3. Benavides, D., Trinidad, P., and Corté, A.R.: Automated Reasoning on Feature Models. In: Lecture Notes in Computer Schience, vol. 3520, pp. 491-503. Springer (2005)
  4. Bosch, J., Florijn, G., Greefhorst, D., Kuusela, J., Obbink, H., and Pohl, K., “Variability Issues in Software Product Lines,” the 4th International Workshop on Product Family Engineering (PFE-4), Bilbao, Spain, (2001)
  5. Bragança, A. and Machado, R.J., “Run-Time Variability Issues in Software Product Lines,” the Workshop on Implementation of Software Product Lines and Reusable Components, ICSR’8, Madrid, Spain, (2004)
  6. Cetina, C., Fons, J., and Pelechano, V., “Applying Software Product Lines to Build Autonomic Pervasive Systems,” the 12th International Software Product Line Conference, Limerick, Ireland, (2008)
  7. Czarnecki, K. and Eisenecker, U.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, (2000)
  8. Czarnecki, K., Helsen, S., and Eisenecker, U.: Formalizing Cardinality-Based Feature Models and Their Specifications. Software Process Improvement and Practice. 10(1), 7-29 (2005)
  9. Czarnecki, K., Helsen, S., and Eisenecker, U.: Staged Configuration Using Feature Models. Software Process Improvement and Practice. 10(2), 143-169 (2005)
  10. Eriksson, M., Börstler, J., and Borg, K., “The Pluss Approach : Domain Modeling with Features, Use Cases and Use Case Realizations,” 9th international conference of Software Product Line, Rennes, France, (2005)
  11. Fontoura, M., Pree, W., and Rumpe, B.: The Uml Profile for Framework Architectures. Addison-Wesley, (2001)
  12. Goedicke, M., Pohl, K., and Zdun, U., “Domain-Specific Runtime Variability in Product Line Architectures,” 8 th International Conference on Object-Oriented Information Systems, (2002)
  13. Gomaa, H.: Designing Software Product Lines with Uml: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley, (2004)
  14. Griss, M.L., Favaro, J., and d' Alessandro, M., “Integrating Feature Modeling with the Rseb,” the 5th International Conference on Software Reuse, Vancouver, BC, Canada, (1998)
  15. Haugen, O., Møller-Pedersen, B., Oldevik, J., Olsen, G.K., and Svendsen, A., “Adding Standardized Variability to Domain Specific Languages,” SPLC 2008, Limerick, Ireland, (2008)
  16. Haugen, Ø., Møller-Pedersen, B., and Oldevik, J., “Comparison of System Family Modeling Approaches,” SPLC 2005, Rennes, France, (2005)
  17. Hoek, A.v.d.: 'Design-time product line architectures for any-time variability', Science of Computer Programming, 2004, 53, (3), pp. 285 - 304
  18. Kang, K., Cohen, S., Hess, J., Novak, W., and Peterson, A., “Feature-Oriented Domain Analysis (Foda) Feasibility Study,” Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Tech. Report CMU/SEI-90-TR-21, Nov., (1990)
  19. Kang, K., Kim, S., Lee, J., and Kim, K.: Form: A Feature-Oriented Reuse Method. Annals of Software Engineering. 5, 25 (1998)
  20. Riebisch, M.: Towards a More Precise Definition of Feature Models - Position Paper. In: Modelling Variability for Object-Oriented Product Lines, pp. 64-76. BookOnDemand Publ. Co. (2003)
  21. Riebisch, M., Böllert, K., Streitferdt, D., and Philippow, I., “Extending Feature Diagrams with Uml Multiplicities,” the 6th Conference on Integrated Design & Process Technology, Pasadena, California, USA, (2002)
  22. van Deursen, A. and Klint, P.: Domain-Specific Language Design Requires Feature Descriptions. Journal of Computing and Information Technology. 10(1), 1-17 (2002)
  23. van Gurp, J., Bosch, J., and Svahnberg, M., “On the Notion of Variability in Software Product Lines,” The Working IEEE/IFIP Conference on Software Architecture (WICSA), (2001)
  24. Zdun, U., “Dynamically Generating Web Application Fragments from Page Templates,” the 2002 ACM symposium on Applied computing, Madrid, Spain, (2002)
introduction_to_variability_modeling.txt · Last modified: 2009/07/28 05:44 by xiaorui.zhang