Software Product Line Engineering with Feature Models - Part 2

Danilo Beuche, pure-systems http://www.pure-systems.com/
Mark Dalgarno, Software Acumen, http://www.software-acumen.com/

Modelling the Problem Space

We will now convert the informal, natural-language specification of variability noted above into a formal model, in order to beable to process it. Specifically, we will use a Feature Model. Featuremodels are simple, hierarchical models that capture the commonality andvariability of a Product Line. Each relevant characteristic of the problem spacebecomes a feature in the model. A definition of the term "feature" is given in Definition 1.

Features are an abstract concept for describing commonalities and variabilities. What this means precisely needsto be decided for each Product Line.

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 forthe example a requirement, a technical function or function group or a non-functional (quality) characteristic.

Definition 1 Features

Feature models have a tree structure, with features forming nodes of the tree. The arcs and groupings of features represent featurevariability. There are four different types of feature groups: "mandatory","optional", "alternative" and "or".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 also contained ("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").

Unfortunately, no single standard has yet been agreed for the graphical notation of feature models. However, in the literature, the graphicalnotation of the original FODA method [Ste04] is common.

However this is representable with standard text tools and graph libraries only with difficulty. Therefore in this article a simplifiednotation has been used. Alternatives and groups of or features arerepresented with traverses between the matching features. In this representationboth colour and box connector are used independently to indicate the type of group. Our notation is shown in Figure 2.

Figure 2 Structure and notation of feature models

Using this notation, our example feature model, with some modifications, is shown in Figure 3:

Figure 3 Feature model for our meteorological Product Line (click on picture to see a larger image)

Each Feature Model has a root feature. Beneath this are three mandatory features - "Measurements", "Data Source"and "Output Format". Mandatory features will always be included in aproduct variant if their parent feature is included in the product variant.Mandatory features are not variable in the true sense, but serve to structure ordocument their parent feature in some way. Our example also has alternativefeatures, e.g. "External Sensors", "Demo" and"Internet" for data sources. All product variants must contain one and only one of these alternatives.

At this stage we can already see one advantage that feature modelling has over a natural-language representation - it removes ambiguities -e.g. whether an individual variant is able to process data from more than onesource. When taking measurements any combination of measurements is meaningfuland at least one measurement source is necessary for a sensible weather station, to model this we use a group of Or. Usually simple optional features are used, such as the example of the freezing point alarm. Refining the model hierarchy can also make further improvements. So the strict choice between Web Server output formats - HTML or XML - can be made explicit.

Feature models also support transverse relationships, such as requires and mutually exclusive, in order to model additional dependencies between features other than those already described. So, in the example model, a selection of the "Freeze Point" alarm feature is only meaningful in connection with the temperature measurement capability.

This can be modelled by a "Freeze Point" requires "Temperature" relationship (not shown in the figure). However, such relations should be used sparingly. The more transverse relations there are, the harder it is for a human user to visualize connections in the model.

When creating a feature model it can be difficult to decide exactly how problem space variabilities are to be represented in the model. In this case it is best to discuss this further with the customer. It is usually better to base these discussions around the feature model, since such models are easier for the customer to understand than textual documents and / or UML models. Formalising customer requirements in this way offers significant advantages later in Product Line development, since many architectural and implementation decisions can be made on the basis of the variabilities captured in the feature model. In the example, the use of the output format XML and HTML can be clarified. The model explicitly defines that the choice of output format is only relevant for Web Server, a format selection is not possible for File or Text output. However, in the context of a discussion of the feature model it could be decided that HTML is also desirable for the on-screen (Window) representation and could also be applicable for file storage.

This results in the modified feature model shown in Figure 4.

Figure 4 Enhanced Feature Model for our meteorological Product Line (click on picture to see a larger image)

We have added "Plaintext" to the existing features; this was implicitly assumed for output to the screen or to a file. We have modelled the mutual exclusion of XML and screen display ("Text") using a (transverse) relationship between these features (not shown).

The previous discussion describes the basic feature model approach commonly found in the literature, but a number of people have extended this basic approach. To complement the so-called hard relations between features (requires and conflicts) the weakened forms recommends and discourages have been added to many feature model dialects. A few tools also support the association of named attributes with features. This allows numeric values or enumerated values to be conveniently associated with features e.g. the wind force required to activate the storm alarm could be represented as a "Threshold" attribute of the feature "Storm Alert".

An important and difficult issue in the creation of feature models is deciding which problem space features to represent. In the example model, it is not possible to make a choice from the available hardware sensor types (e.g. use of a PR1003 or a PR2005 sensor for pressure). So, when specifying a variant, the user does not have direct influence on the selection of sensor types. These are determined when modelling the solution space. If the choice of different sensor types for measuring pressure is a major criterion for the customer / users, then appropriate options would have to be included in the feature model. This means that the features in the problem space are not a 1:1-illustration of the possibilities in the solution space, but only represent the (variable) characteristics relevant for the users of the Product Line. Feature models are a user-oriented (or marketing-oriented) representation of the problem space, not the solution space.

After creating the problem space model we can use it to perform some initial analysis. For example, we can now calculate the upper limit on the number of possible variants in our example Product Line. In this case we have 1,512 variants (the model in Figure 2 only has 612 variants). For such a small number of variants the listing of all possible variants can be meaningful. However, the number of variants is usually too high to make practical use of such an enumeration.

Modelling the Solution Space

In order to implement the solution space using a suitable variable architecture, we must take account of other factors beyond the variability model of the problem space. These include common characteristics of all variants of the problem space that are not modelled in the feature model, as well as other constraints that limit the solution space.

These typically include the programming languages that can be used, the development environment and the application deployment environment(s).Different factors affect the choice of mechanisms to be used for converting fromvariation points in the solution space. These include the available developmenttools, the required performance and the available (computing) resources, as wellas time and money. For example, use of configuration files can reducedevelopment time for a project, if users can administer their ownconfigurations. In other cases, using preprocessor directives (#ifdef)for conditional compilation can be appropriate, e.g. if smaller program sizes are required.

There are many possibilities for implementation of the solution space. Very simple variant-specific model transformations can be madewith model-driven software development (MDSD) tools by including informationfrom feature models in the Model-Transformation process. [Voel05] gives anexample using the OpenArchitectureWare model transformer. Aspect-orientedprogramming (AOP) can also be used as a means for the efficient conversion ofvariabilities in the solution space. Product Lines can also be implementednaturally using "classical" means such as procedural or object-oriented languages.

Page 1    Page 3   Back to the archive list