Requirements and Product Lines (Variants / Feature Models) with ReqIF/RMF

Product Lines and Handling of the complexity of variants is one of the current challenges in many industries. In the engineering process, it is important to find the correct views on the engineering data for the product lines and variants. Requirements engineering is no exception.

Requirements and Variants

In the publicly funded research project IMES, itemis as one of the partners is investigating new tool platforms that seamlessly integrate the software engineering artifacts of OEMs and 1st-tier suppliers. This blog article describes our current implementation of variant handling for requirements. This solution allows the specification of presence conditions (i.e. specifying which requirements are applicable to which features) and the tailoring of the requirements models. We are using the Eclipse technologies Xtext, EFM and RMF – but everything is usable in standalone mode as a Java program from the command line, so it could be generally applied to any tool that handles ReqIF.

Eclipse Feature Model

For the modeling of features, we are using the Eclipse Feature Model Project, which contains meta-models for feature and variant models contributed by Pure Systems, a company specialised on tools for product line and variant management. The project does provide the basic EMF editors, and we added Xtext-based textual editors for features (but they are not part of this blog article).

Presence Conditions

For each requirement, we want to specify for which features the requirement is applicable. A simple selection box is not sufficient, since we might want more powerful expressions (e.g. a requirement applies for a specific car, if it is “sold in the Asian market and it has more then 200 hp”). Since the 2.x version of Xtext, it is easy to write for these expressions. Our Xtext solution examines the feature model and provides the features in the expression language.

RMF

The Eclipse Requirement Modeling Framework is the Eclipse-EMF based implementation of the ReqIF standard meta-model for requirements. It is expected that most tools will support the standard with some of the next releases.

Combining technologies

To support product line / variant management with requirements, we have the following steps:

  1. Model the features in the feature model
  2. Model one or more variants in a variant model
  3. Add an additional attribute for the presence condition to your requirements
  4. Define the presence conditions
  5. Run the tool

You will now have a tailored version of your requirements that provide a specific view on the variant. We are using a feature of the ReqIF standard: The hierarchy structure of requirements is not stored in the requirements. Instead, you can have one or more so-called “specification hierarchies”. The elements of these hierarchies are just used to build up the structure, they do not contain any data but only point to the actual requirements. So a requirement can be referenced by zero to one hierarchies.

We create a second hierarchy, that is a copy of the first hierarchy, with the presence conditions applied. So the original data is preserved.

Command Line and GUI

For the standalone version, only the variant model, feature model and an ReqIF file with presence condition attributes are required. So you could basically enter the presence condition in any tool with text input.

For Eclipse-based tooling, we provide additional support for the presence condition. The Xtext editors for the language can be embedded into the ProR editor of RMF, so you will get full content assist, error checking and navigation for your feature models.

ReqIF – Towards a scripting and constraint language

ReqIF is a very flexible meta-model and exchange format definition. The possible attributes of requirements are not predefined, but can be defined within the standard itself. This makes implementation of queries and constraints somewhat more complex. But with Xtext, we can easily create a language that knows about the data model of a ReqIF file and implements a language.

A simple definition of a string attribute “Description” for a requirement type “XType” would look like this in XML:

Because of this flexibility, you will not find just an attribute with the name “Description” in your requirements, but so-called AttributeValues that reference their attribute definitions, which actually define the attribute names.

To retrieve the value of an attribute, you’d have to traverse a requirement’s attribute value, compare the names and fine the object. There is a helper object for that (ReqIF10Util) that comes with RMF:

So, in your code you would have something like ReqIF10Util.getAttributeValueForLabel(element,”Description”). But since AttributeValue is an abstract class, your following code would have quite some case-statements depending on the actual type of AttributeValue, since the ReqIF meta-model does not define an abstract method for retrieving the actual value.

A user friendly language

We don’t want that. What we’d like to do is to have a language where we could just write requirement.Description. Actually, this is very easy to do in Xtext. As an example, we create a Xtext language that allows to specify expressions on requirement objects. It simply references the ReqIF object SpecObjectType and then is followed with an Expression. All is needed is a JvMModelInferrer that creates JvmTypes from the referenced ReqIF model. And voila, a complete editor that knows about the types of the referenced ReqIF and provides their attributes directly:

 

 

 

 

 

 

Description is a defined attribute in ReqIF and can be accessed directly know.

A constraint interpreter

Specifying expressions is nice, but executing is what’s interesting. As you see in the screenshot above, there is an error marker at the expression. It says:

 

This is because we simply added an interpreter for the language that is executed on the ReqIF model and is integrated into the validator. So if we have a requirement that causes the expression to evaluate to false, an error is flagged.

Further uses

Of course, the constraint evaluation can be integrated in the tabular editor that comes with RMF, called ProR. In addition, there are further uses of the approach

  • Could be used as a query language to filter requirements
  • In combination with Xtend2 expressions might be used for reporting infrastructure
  • It is not only possible to query models, but also to modify models.

Since the Xbase expressions can be both interpreted as well as compiled to Java, this is a fast and flexible infrastructure.

ReqIF – user friendly editing of data types and spec object types

ReqIF is a powerful and flexible format for specifying schemas for requirements. A ReqIF model contains both the definition of data types/requirement types and the actual requirement content. Both are stored in an XML format that is not designed for human readability, so a dedicated tool for the type specification increases usability. One kind of tools for that purpose are form-based tools, like the Eclipse RMF/ProR editor. However these do not present the whole type model at one glance.

Textual formats

The AUTOSAR standard faces a similar challenge. One approach here is the ARText tool, that allows you to specify AUTOSAR models in a textual way. One of the many benefits is the fact that textual definitions can easily be conveyed in e-mails, articles, presentations etc. So a similar approach can be used for ReqIF. With the Eclipse projects RMF and Xtext, the tooling described in this post has been created with an effort less than 3 hours.

Eclipse Frameworks

The Eclipse RMF project provides the meta-model of ReqIF in Eclipse’s de-facto standard EMF (Eclipse Modeling Framework), so it can be easily used with the many EMF-based Eclipse project. One of these project is Xtext, which allows the user to define textual domain specific languages (DSLs) and generates a user-friendly editing environment, including highlighting, content assist, validation etc.

Xtext for ReqIF

The main step is to create a Xtext grammar, that references the ReqIF meta-model (first highlighted line below). Xtext can then suggest a concrete textual syntax for that meta-model, but we prefer to define that manually (second highlighted block), since that is usually more concise. The highlighted block contains the necessary code for boolean types – the full grammar contains more code for all ReqIF supported types (Strings, Integers, XHTML, etc.)

The Runtime Editor

That’s basically it. From the definition above, Xtext generates the full editor with comfortable editing feature. The screenshot shows the ReqIF type editor with content assist. This textual representation is more user friendly than the XML.

 ReqIF-XML

However, Xtext files are stored in plain text. And we need to have a ReqIF-XML conforming representation. Since both the Xtext model and RMF are based on EMF, it is only a matter of saving the model with a different file extension – EMF does all the work! It knows about how to save models depending on the extension. Xtext also provides a so called “Builder” which is called every time the Xtext model changes and can be used for model-to-model or model-to-text transformations. So this can be easily used to save the model in ReqIF-format each time it changes.

 

 

 

 

 

That’s it. Each time the Xtext model is saved, Eclipse will automatically create a ReqIF, that can be opened e.g. with ProR/RMF (or any other ReqIF-enabled tool).

 

Existing ReqIF

Existing ReqIF XML can be transformed to textual representation in the same way. The code is basically the same as for saving in xml format:

Since ReqIF supports object identification through UUID, it is possible to update existing ReqIF files after editing their type definition in the textual representation.

 

Xtext End User / Domain Experts Cheat Sheet

The basic idea of domain specific languages is to provide domain experts with an easy to use language for their modeling needs. However, a domain specific language is always tied to a tool for editing the model. With Xtext, this is obviously Eclipse. Eclipse provides some rich editing features, especially for navigating in models.

Most existing cheat sheets refer to the Java IDE of Eclipse, which you cannot give to domain experts because it contains elements not relevant to them (debugging) or have a slightly different meaning.

So here is an attempt of a small cheat sheet for Xtext end users (domain experts):

 

Editing

ALT-Left and ALT-Right Back / forward Go back and forward in history of where you were in editors
CTRL-PgUp and CTRL-PgDown Cycle tabs  Cycle through tabs of open editors
CTRL-Up and CTRL-Down Scroll  Scroll line up and down
CTRL-M Maximize  Maximize / Restore current editor window
CTRL-W Close Close Current Editor
CTRL-D Delete Line Delete Current Line
CTRL-/ Toggle Comment Toggle Comment for line / selection
CTRL+SHIFT-F Format Auto format
ALT-UP / ALT-Down Move Move current line / selection one line up / down
CTRL-Q Last Edit Go to last edit location
CTRL-L Goto Go to line

Model Editing

Ctrl-Shift-G Find References Find all elements that refer to the current element
F3 or CTRL-MouseClick Follow Link Follow reference under cursor
Ctrl-O Pop up Outline Pops up an outline for easy navigation / filtering
CTRL-1 Quick Fix Quick Fix of Errors (where provided by DSL designer)
CTRL-SPACE Content Assist Get suggestions of possible values
ALT-SHIFT-R Rename Rename current element (will rename other occurrences as well.
CTRL-SHIFT-F3 Open Model element Locate a model element in your workspace (only exported elements are listed)
ALT-SHIFT-Up / Down Expand selection Expand selection to containing element