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
Variability models for system families come in different forms:
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  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 , FeatureRSEB , Generative Programming , PLUSS , and also in the work of the following authors: Czarnecki et al. (, ), van Gurp et al. , Batory et al. , Benavides et al. , van Deursen et al.  and Riebisch et al. , ).
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.
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:
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.  point out several potential problems we may face in traditional static variability handling mechanisms:
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 , Hoek , Bragança et al. , Goedicke et al. , Cetina et al.  and etc.