Product Line Engineering

Versions, Variants and all the rest – Basic definitions

Posted in Article by danilo on July 4, 2008

When talking about product line engineering and variant management, it is important to share a common understanding of some of the basic terms. I learned over the years that the distinction between “version” and “variant” is one of the most complicated ones because in many context outside the product line engineering (PLE) context those terms are used more or less interchangeably. That’s one of the reason why we often get visitors to our show booths saying something like “I see you are doing some kind of version management, what are you doing differently compared <put name of a version control system here>”. In the following text I will try to give simple definitions for all the relevant terms around versions and variants as I use them. I will also try to illustrate who those things related together and explain why they often are seen as describing the same thing.

A version of an asset is the recorded state / content of that asset at a given point in time. Two versions of an asset may represent same or different content of that asset. Thus versions reflect the same asset at different points in time. In most cases versions are identified by some labels or numbers. In some cases there is a distinction made between a revision (created whenever an element changes) and a version (referring to a labeled/named revision).

A baseline refers to a (named) snapshot of versions of a set of assets.

A variation is simply a difference between two comparable (sets of) assets.

A variation point represents a decision leading to different variants of an asset. A variation point consists of a set of possible instantiations (legal variations of the variation point). A variation point usually specifies the binding times, that is the time/times at which an decision about the instantiation has to be taken. Examples for binding times are compile time, installation time, or runtime.

The variant derivation is the action in which assets are combined from the set of available assets and contained variation points are bound/instantiated. If there are variation points with multiple binding times, the derivation will happen stepwise at each binding time. The result of such an derivation is a set of derived assets. The derivation can be executed technically in many ways. The most simple ( and in general not recommend) way is to copy assets and modify (parts of) them (e.g. the configuration parameters) manually. The result of such a derivation is often called a configuration.
In product line engineering the derivation is a central part since changes to a product line asset ( for example when fixing a bug) often requires the recreation of all derived products including the changed assets. To minimize effort for this, often tools supporting automated derivation are used here.

An asset X’ represents a variant if it has been derived from an asset X and has stakeholder relevant properties which differ from other variant assets derived from the same asset X. These differences allow distinguishing it from other derived assets from the same asset X.
If a machine can produce blue and red (and otherwise identical) balls by coating a ball with blue or red paint, it is able to create two variants (blue ball, red ball). The number of balls coated blue or red is not relevant here.

Please note here, that the definition of the term variant does not talk about the time the derivation happens. The notion of a variant is independent from time.

It is important to understand that not every small difference between two assets creates a variant, it depends whether the involved stakeholder see a relevant variation. For instance if you buy first one shirt and a week later a second one with same brand, same color, same cut, same size these shirts could have a small difference in the washing labels for instance but this does not play a role for you, you will treat them as equal (until wear takes its toll). If you however buy the shirt for you and another person with a different size, they are variants (relevant variation being the confection size). Translated to software systems: Most bug fixes to an asset create a new version of the asset but do not cause new variants to be created, since a bug fix does not change the perspective of a customer of the desired and required properties of an asset.

Last but not least, variability describes the possible variations of assets with variation points. Since listing all possible variants is due to the large number of possible variants not feasible in most cases, variability models such as feature models or configuration rules are often used to describe the variability of a system.

The next article will look at feature models and will also try to answer the question “What is a feature?”.

4 Responses

Subscribe to comments with RSS.

  1. […] first postings give basic definitions of Versions and Variants and comment on Markus Voelter’s JAOO video describing […]

  2. […] have multiple feature groups as children. When specifying which features are to be included in a variant the following rules apply: If a parent feature is contained in a […]

  3. […] The next level of product relationship is the Product Gang. Your products are build from sets of reusable assets by way of configuration and customization. Reuse means that for a new product you take the reusable assets and put them together in a way that they can be used for developing the missing piece for the new product. Changes to the reusable assets (here called the “Platform” PF) do not directly affect a product until the application developer decides to pull in the new version of the PF. The products of the product gang are now sharing more / most assets and are technically derived from the platform assets. Hence products are now in fact instances of the platform, and  I start calling them Product Variants (PV0-PV3) instead of products as in the earlier figures. Read more about my definition of variants and version in this post. […]

  4. […] course, you’ve read in this blog about  variants not being version and also found out clone-and-own leads to a product bush and thus is not the most recommended reuse […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: