Product Line Engineering

Feature Models and Features – What’s this?

Posted in Article by danilo on July 21, 2008

Talking about variability informally is interesting but finally there is a need to capture information about variability in a “standard” way. Of course research and industry found numerous ways to do so. For several reasons, one of the most popular ways to record variability is called feature modeling. This article will try to explain the very basic concepts of feature models. And this article will also try to give hints for answers to the interesting question “What is a feature?”.

In a nutshell, feature models are simple, hierarchical models that capture the commonality and variability of a Product Line. Each relevant characteristic of the problem space becomes a feature in the model. A feature in this sense is a characteristic of a system relevant for some stakeholder. Depending on the interest of the stakeholders a feature can be for the example a requirement, a technical function or function group or a nonfunctional (quality) characteristic. That is the bad news, features models are an abstract concept for describing commonalities and variabilities. What a feature is needs to be decided for each product line individually. However, in general features are defined in a way that they are decoupled from their actual implementation concepts (i.e. the solution space). For instance if the color of a car would be a feature, it would get a nice name (“dark marine blue”) but the ordering number for the paint from a specific manufacturer wouldn’t be mentioned here (that is solution space). Same for software. Whether a feature maps to a single function or is spread across dozens of components, is irrelevant here. If the stakeholder recognizes it as a relevant property and it represents variability, it should be a single feature.

Feature models have a tree structure, with features forming nodes of the tree. Feature variability is represented by the arcs and groupings of features. In most feature modeling approaches these days there are four different types of feature groups available: “mandatory”, “optional”, “alternative” and “or”. Each feature can 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 variant,

  • all its mandatory child features must be contained also (“n from n”),
  • any number of optional features can be included (“m from n, 0 <= m <= n”),
  • exactly one feature must be selected from a group of alternative features (“1 from n”),
  • at least one feature must be selected from a group of or features (“m from n, m>=1”).

Obviously all these terms like “optional” or “alternative” are mapped to the concept of group cardinality expressed by specifying an lower and upper limit of features to be selected in any valid selection from the group. However, those four special instances are the ones most commonly used. The concepts behind these words are commonly understood in the right way even without seeing the formal definition (except for “or” feature groups, often thought of being a synonym for “alternative”).

Most approaches allow also to specify additional constraints like mutual exclusion between features ( “Nice Shirt” conflicts with “Shirt Color Pink”) and requirement relationship (“Nice Shirt” requires (“Shirt Color White” or “Shirt Color Black”) ). These constraints crosscut the tree (or even between models if multiple feature models are used). Depending on the approach and tooling the language for expressing this kind of constraints can range from simple special purpose languages to generally available languages like XPath or even OCL, obviously with varying expressiveness and complexity. However, such constraints should be used sparingly. The more constraints there are, the harder it is for a human user to visualize/understand connections in the model.

Some approaches support a concept called feature cardinality, allowing to express multiplicity rules on subtrees of a feature model. E.g. if you have multiple configurable sensors attached to a system, instead of creating a (identically structured) feature subtree for each possible sensor, one writes on sensor and gives a cardinality statement like [1-3], requiring at least one sensor subtree being configured and at most 3 subtrees. I will put a special article on feature cardinality and associated issues later on this blog and leave it at this right now. Have a look at the Read On section below and read the paper of Kryzstof Czarnecki.

Unfortunately, no single standard has yet been agreed on for the graphical notation of feature models. There are lots of different notations. However, in the literature, extended forms of the graphical notation of the original FODA method are most commonly used. However, this can be represented with standard text tools and graph libraries only with difficulty so some of us prefer simpler ones 🙂 .

With the (very) abstract definition of the term feature as given above just about everything could be a feature. And in some sense this is true. So what is a feature then and how can one know which ones to choose for a feature model?

The most important action here is to clearly define the stakeholder for whom the feature model is made. If the feature shall be used by end users of a product line to define their very own product instance derived from the product line, clearly the features have to be easily understood by those. A good example are the car configurators provided by most car manufacturers on their web site these days. Also the structure of the feature model should follow the line of thinking of end users then.

As simple as it sounds, that is in fact very hard to do perfectly (well, it is impossible to be honest). In many cases there are different ways to approach the configuration of a system depending on the type of user you are (looking for some special small features vs. making some general decisions like engine type and size, color of the car, etc.). While in general the feature model allows free navigation (it does not prescribe a specific order of selecting features) but still more general decisions tend be closer to the root of the model which often guides the user to go deeper into this or that part of the tree.

So what if there are different stakeholders with different “languages”? Shall we make multiple feature models (for each group of stakeholders) or just one for the most important stakeholder group (which is which?). Again no clear answer is possible. The smaller and simpler the dependencies are, the better. For many product line applications, one feature model is a good choice. However if parts of the product line form an individual product line itself, multiple feature models are almost inevitable. Think of an application running on top of a configurable middleware. The variabilities of the middleware have to be captured in the language of application developers and should use the same feature model for all applications the middleware is used in. Obviously in this case there needs to be a mapping between variabilities of the application domain to variabilities in the middleware domain. Creating this mapping is the responsibility of the application product line engineers. In some cases there might be no mapping at all, since the middleware is used just in one specific configuration. In other cases they can be fairly complex. For instance if on the application layer there is a choice between a secure and non secure application operation, certain features in the middleware (e.g. encryption support, authentication via certificates, and support for the SSL protocol) are to be enabled whenever the “secured application operation” feature, except when the application shall run on a mobile phone, where there is no certificate support allowed (due to lack of certificate management applications on the mobile devices).

Another aspect to consider is the granularity of the features. If the features only describe coarse grained variabilities, the individual instances of valid configurations probably do not describe the system in enough detail to be useful. Too fine grained, and the number of to be managed features grows and also the complexity. Here again, think of what is the context: automatic product configuration requires much higher level of detail than product roadmap planning and scoping. And later adding details is easier than removing features from a model.

In my experience, the easiest way to get a good feature model is just to start creating one and try to use it to describe known/envisioned product variants in the product line. In most cases it turns out quite quickly that some of the decisions were not very wise. Sometimes the chosen features do not describe the variability good enough (level of detail). Or the tree structure was not right, e.g. an option A was placed as child of a feature B, but sometimes the parent feature B of the option A should not be selected, when A is selected.

But those mistakes help to create a better one in the next round. In most cases it will be the structure rather than the features itself which are problematic.

A lot more about features and feature models could be written. I will do exactly this later in this blog. Stay tuned.

But there is one thing left to mention: I do think that feature models are a very important element when describe variability in product lines. But there are cases when feature models alone are not enough, and even cases where feature models are not the way to go. If the variability is rather of the compositional type, that this, there is a number of basic elements (think of brick stones used to build a house) which can be combined following some formal rules. These rules allow potential unlimited numbers of bricks being used. In this case a feature model simply does not allow you to describe this efficiently. When it however comes to describe the potential properties of a brick stone (color, material it is made from etc.) feature models are quite appropriate to describe the available variability.

So there is an awful lot of cases where feature models are just the way to go.

Read on

A short paper explaining different feature model notations (FODA, Czarnecki-Eisenecker, FeatuRESB, …) This makes a nice reference for those among us who tend to forget the graphical notations easily.

Feature Models are Views on Ontologies A paper by Kryzstof Czarnecki et al, introduces basic and advanced feature modeling concepts like feature cardinalities and then relates those to the ontologies world. Even if you are not interested in the ontologies stuff, the feature modeling concepts part is worth reading.

Software Product Line Engineering with Feature Models An article I wrote together with Mark Dalgarno of Software Acumen, gives an introduction to software product lines with feature models on a concrete example.

2 Responses

Subscribe to comments with RSS.

  1. Nadeem Abbas said, on September 2, 2011 at 10:20

    A good introduction on Feature Model, it really help to understand the basics with good examples there.

  2. […] we taken the choices described above together, we can construct a nice feature model with two groups of three alternatives plus two groups with two […]


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: