Feature Models and Features – What’s this?
by Danilo Beuche
Talking about variability informally is interesting, but ultimately, there is a need to capture information about variability in a "standard" way. Of course, research and industry found numerous ways to do this and one of the most popular ways is called feature modelling. This article will explain the basic concepts of feature models. And it will give some hints to answer the interesting question "What is a feature?".
A characteristic of problem space
In a nutshell, feature models are simple, hierarchical models that capture the commonality and variability of a product line. Each relevant characteristic in the problem space becomes a feature in the model. In this sense, a feature is a characteristic of a system relevant to some stakeholders. Depending on the interests of the stakeholders, a feature can be, for example, a requirement, a technical function, a function group, or a non-functional (quality) characteristic. The bad news is: feature models are an abstract concept for describing commonalities and variabilities. What a feature is exactly, needs to be decided for each product line individually. However, features are generally defined in a way that they are decoupled from their actual implementation (i.e., decoupled from solution space).
For instance, if the colour of a car was a feature, it would get a nice name, such as "dark marine blue". That name would never mention the ordering number of a specific paint supplier, because of specific suppliers and their ordering numbers - that’s solution space. It’s the same for software. Whether a feature maps to a single function or is spread across dozens of components, is irrelevant. If the stakeholder recognizes it as a relevant property and it represents variability, it is a single feature.
Feature trees and variation types
Feature models have a tree structure, with features forming the nodes of the tree and variability being represented by the arcs between the nodes and by their groupings into variation types. In most feature modelling approaches these days, four different variation types are available: "mandatory", "optional", "alternative", and "or". Each feature can have multiple groups of features with different variation types as children. When specifying which features can be combined in a variant, the following rules apply: If a parent feature is contained in a variant,
- all its mandatory child features must be contained as well ("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 a lower and an 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, which are often thought of being synonymous with "alternative").
When hierarchy and variation types aren´t enough
Most approaches allow you to specify additional constraints like mutual exclusion between features ("Formal Shirt" conflicts with "Shirt Colour Pink") and requirement relationship ("Formal Shirt" requires ("Shirt Colour White" or "Shirt Colour Black"). These constraints crosscut the tree or even cut across models if multiple feature models are used. Depending on the approach and tooling, the language for expressing this kind of constraint can range from a simple special purpose language to a generally available language like XPath or 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 and understand the connections in the model.
Reusing Feature Subtrees
Some approaches support a concept called feature cardinality, allowing to express multiplicity rules on subtrees of a feature model. For example, if you have a system to which multiple, configurable sensors are attached, then instead of creating an (identically structured) feature subtree for each possible sensor, you create only one feature subtree and give it a cardinality statement like (1-3), which requires at least one sensor subtree to be configured and at most three subtrees.
Graphical representation of a Feature Model
Unfortunately, no single standard has yet been agreed on for the graphical notation of feature models. There are lots of different notations, and in the literature, extended forms of the graphical notation of the original FODA method are most commonly used. However, this notation leads to difficulties when using standard text tools and graph libraries, which is why some of us prefer simpler notations - like the ones we use in pure::variants.
What is a good Feature Model?
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 and how can you know which ones to choose for a feature model?
The most important action here is to clearly define the stakeholders for whom the feature model is made. If the feature shall be used by end users to define their very own product variants, it is clear that the features have to be easily understandable. A good example are the car configurators provided by most car manufacturers on their websites. Apart from the feature names, the structure of the feature model, too, should follow the line of thinking of end users. And as simple as it sounds, creating such a structure is actually very hard. To be honest, it is impossible.
Feature Model Structure
The reason that creating a perfectly structured feature model is so difficult is that in many cases, there are different ways to approach the configuration of a system. Depending on the type of user you are, you may either be looking for some small, specialist features or you may be making some general decisions, e.g. on the engine type and size, the colour of the car, and so on. While a feature model does allow free navigation (it does not prescribe a specific order of selecting features), the more general decisions still tend be closer to the root of the model, which in turn, guides the user to go deeper into this or that part of the tree.
One Model or Several Models
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 …?). Again, it’s impossible to give a clear answer. The fewer dependencies you have and the simpler they 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 in which the middleware is used. In such a case, there must 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 not even be a mapping, because the middleware is only used in one specific configuration. In other cases, the mapping can be very complex. For instance, if the application layer offers a choice between a secure and a non-secure application operation, certain features in the middleware (e.g. encryption support, certificate-based authentication, and SSL support) must be enabled whenever the "secure application operation" feature is selected - except if the application is intended for mobile phones, which lack support for certificate-based authentication.
Another aspect to consider is the granularity of the features. If the features are too coarse-grained, the individual instances of valid configurations probably do not describe the system in enough detail to be useful. On the other hand, if the features are too fine grained, the number of features grows and so does the complexity and the effort to manage and maintain the features. Again, consider the context: automatic product configuration requires a much higher level of detail than product roadmap planning and scoping. Also keep in mind that adding details later is easier than removing them.
An iterative approach
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 well enough (level of detail). Or the tree structure was wrong, for example, feature B was modelled as child of a feature A, when in fact, you also want to be able to select only feature B but not feature A.
Those mistakes help to create a better feature model 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, and I will do exactly this later in future articles. Stay tuned.
The limits of Feature Modelling
There is one thing left to mention: While I do think that feature models are a very important technique to describe variability in product lines, there are cases when feature models alone are not enough. There are even cases where feature models are not the way to go at all! If the variability is rather of the compositional type, 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. However, when it comes to describing the potential properties of a brick stone (colour, brick material, etc.), feature models are quite appropriate to describe the available variability - which only shows the following: There is an awful lot of cases where feature models are just the way to go.
About the author
Prof. Dr. Danilo Beuche is co-founder and CEO of pure-systems and one of the leading minds in Product Line Engineering (PLE). Danilo is driven by the idea of helping companies to develop better, longer-lasting products while always paying attention to economic reuse and sustainability. In 2001, he co-founded pure-systems, a software company specialized in services and tool development for the application of product line technologies in embedded software systems. As the market leader in PLE, pure-systems helps global enterprises and medium-sized companies to keep costs low while improving the quality and safety of their products.
Before founding pure-systems, Danilo worked on tool support for feature-based software development at the University of Magdeburg. Since 2016 he is also an Honorary Professor at the Information Systems Institute (IWI) of Leipzig University.