SQC, Single Site, Variability Exchange Language, Header

Variability-Exchange-Language

The Variability Exchange Language (Draft Version)

The current draft version of the Variability Exchange Language has been developed in the project SPES_XT by the partners Daimler AG, pure-systems GmbH, and the Fraunhofer Institute for Open Communication Systems FOKUS. The project SPES_XT has been funded by the German Federal Ministry of Education and Research (BMBF) from May 2012 to April 2015. One result of the project works is the present draft version of a specification of the Variability Exchange Language, that is intended to be standardized within OASIS in the near future.

A Generic Data Exchange Format for Variant Management

Tools for variant management frequently interact with artifacts such as model based specifications, program code, or requirements documents. This is often a two-way communication: variant management tools import variability information from an artifact, and in return export variant configurations. For example, they need to gather information about the variation points that are contained in the artifact, need to know which variants are already defined, and then modify existing or define new variants ("this variation point stays, that one goes away") or even define new variation points ("items a,b and c are alternatives").
VEL Figure 1
Fraunhofer FOKUS/ Daimler AG/ pure-systems GmbH

Without VariabilityAPI, many APIs need to be implemented

There is currently no standardized API available for such operations. Hence, a variant management tool needs to implement a separate interface – and possibly a new data format as well – for each new artifact. Worse, each variant management tool needs to do this separately. With m variant management tools and n artifacts, this may require the implementation of up to m x n different interfaces.

VEL Figure 2
Fraunhofer FOKUS/ Daimler AG/ pure-systems GmbH

With VariabilityAPI, only a single API needs to be implemented

In this project, we present a generic API (VariabilityAPI) that allows variant management tools to communicate with artifacts through a standardized interface. If implemented across both variant management tools and artifacts, this may reduce the number of required implementations significantly. A generic interface typically also lowers the barrier for adding new artifacts, and fosters the introduction of new tools for variant management.

The VariabilityAPI serves two purposes. First, it provides a generic description of the variation points that are contained in an artifact. Variation points may come in two flavors:
  • Variation points may be locations in an artifact which are removed or set inactive in a binding process. This is implemented by defining a condition for each variation point.
  • Variation points may be parameters. Such variation points provide expressions which are used by the binding process to assign a value to the parameter.
Variation points may also exhibit dependencies; for example a set of variation points may be designated as a set of alternatives, which means that all but one of them will be removed during the binding process (although the actual semantics of the binding process is beyond the scope of this concept).
Second, the VariabilityAPI can define specific variant configurations. In our context, a variant configuration is an assignment of fixed values to the conditions or expressions that are associated with variation points.
Finally, the VariabilityAPI defines a number of operations for exporting and importing variability information. It is not expected that every artifact or variant management tool implements the full set of operations, hence the API provides means to state the capabilities of a specific implementation.
The VariabilityAPI uses an XML based serialization as its data exchange format. The release of the finalized version of the Variability Exchange Language as a standard is planned for the near future.
Contact Person
Dr. rer. nat. Martin Große-Rhode
Business Unit SQC
+49 30 3463-7587
Email

More information