Eclipse ProR

The ProR adapter identifies traceable artifacts based on requirements that are stored in the ReqIF (Requirements Interchange Format) file format. More precisely, the adapter creates artifacts for ReqIF specification objects that fulfill certain conditions. These conditions are configurable. The adapter propagates the selection of artifacts from YT to the ProR requirements engineering platform and vice versa.

ProR is the graphical component of the open-source RMF (Requirements Modeling Framework) software framework. It allows for creating and editing ReqIF models. Requirements in these models are defined as „specification objects”, each of which has a user-defined type and a user-defined set of attributes. Based on these types and attributes, the ProR adapter supports filtering of those specification objects that should be recognized as traceable artifacts.

ProR displays specification objects and their attributes in tables. It also displays specification objects in Eclipse’s Overview view. The ProR adapter recognizes selections both in tables and in the overview.

Data access

Configuration

Open the YT configuration with the YT configuration editor, and add a new data access as described in section "Data accesses". Select Eclipse ProR as data access type.

Supported options:

  • resource – File filter pattern

Example:

resource *.reqif

This configuration rule specifies that YT should load ReqIF models from all files in the workspace whose filename extension is .reqif.

Artifact type

The ProR artifact type identifies specification objects in ReqIF models as traceable artifacts. The set of identified artifacts can be constrained, based on their types and the values of their attributes. These constraints can be configured.

For each combination of constraints to derive artifacts for, you can define how the artifact name and the values of custom attributes should be computed. In both cases, you can specify expressions that refer to the attributes of the specification objects that were identified as artifacts.

Configuration

Open the YT configuration with the YT configuration editor, and add a new artifact type as described in section "Artifact types". Select your previously-configured Eclipse ProR data access in the Data access drop-down list.

Identifying specification elements as artifacts

We will now introduce the configuration language, including its syntax, by an example. You can find the complete list of keywords below.

Let’s consider a specification Functional Requirements that contains specification objects, some of which have the type Functional Requirement. This type defines the attributes ID, Title, Description and Status.

To identify artifacts, we need to create a mapping and configure it. The following mapping configuration for a ProR artifact type derives artifacts for specification objects of type Functional Requirement and assigns values to their custom attributes. These values depend on conditions on the artifacts themselves. The configuration will be explained in more detail below.

name valueOf(ID) + "-" + valueOf(Title)
map to type "Functional Requirement" if (valueOf("Status") != "REJECTED" and isSet("Status")==true) {
	Description to valueOf(Description)
	Status to valueOf("Status")
	SpecificationDescription to Specification.valueOf("Description")
}
map to type "Functional Requirement" if (isNotSet("Status")== true) {
	Description to valueOf(Description)
	Status to "(unknown)"
	SpecificationDescription to Specification.valueOf("Description")
}

Let us assume that we want to identify artifacts for any specification objects of type Functional Requirement. We can express this by writing map to type "Functional Requirement". If we additionally want to restrict these functional requirements to those that don’t have the status „REJECTED”, we can do this by adding the condition if (valueOf("Status") != "REJECTED"). By adding and isSet("Status")==true to the if condition, we can exclude those requirements that have no known status. Combining these three conditions, we get the second line of the example above.

In general, the keyword map introduces a set of conditions for specification objects. If a specification object fulfills these conditions, it will be identified as an artifact. The to type keyword simply excludes all specification objects that don’t have the type with the indicated name. The if keyword opens a boolean expression that must evaluate to true for a given specification object to fulfill the constraint. Via valueOf, we can access the value of a specification object’s attribute, like Status in the above example. The keyword isSet allows us to check whether a given attribute has any value at all.

Now we want the artifacts identified for functional requirements to have names that consist of the respective requirement’s ID and its title. We can define this by adding name valueOf(ID) + "-" + valueOf(Title) to the top of the configuration. Here, a minus character is used to separate ID and title.

If we want to assign attribute values of functional requirements to custom attributes of the corresponding artifacts, we can do this in a separate block of statements, included between curly braces ( {, }) and appended to the map statement.

Let’s say we want to assign the values of the Description and Status attributes to custom attributes of the same name. We can do this by using the statements Description to valueOf(Description) and Status to valueOf("Status").

In ReqIF, specifications can be used to structure specification objects hierarchically. Like specification objects, specifications have their own sets of attributes. We can access these attributes by using the command Specification.valueOf instead of valueOf. Please note that this always refers to the specification of the specification object that valueOf refers to. We now want to assign the Description attribute of this specification to the variable SpecificationDescription. We can do this using the expression SpecificationDescription to Specification.valueOf("Description").

In conclusion, these variable assignments make up the following block, which completes the first map statement in the example above:

{
 	Description to valueOf("Description")
	Status to valueOf("Status")
	SpecificationDescription to Specification.valueOf("Description")
}

Now we also want to consider functional requirements that have an undefined status. We could include them by removing the condition isSet("Status")==true. However, here we also want to assign a special value to the custom attribute Status. Usually we would get an empty string for the undefined value, but instead we want the string to be „(unknown)”. We can do this by adding a second map statement with the condition isNotSet("Status")== true. The keyword isNotSet is true whenever an attribute is not set, i.e., isNotSet is the opposite of isSet. We will now identify an artifact for a specification object if it fulfills the conditions of either of the two map statements. However, we assign different attribute values depending on which one matches.

Configuration keywords

The ProR artifact type configuration supports the following keywords:

  • if( constr) – Defines a constraint to filter specification objects by attributes. Artifacts will only be created for those specification objects for which constr evaluates to true. The latter is a boolean expression that consists of either a single comparison or of several comparisons, combined by the boolean operators and or or. The left-hand side of the comparison is a string expression that may include the keywords isNotSet, isSet, Specification.valueOf or valueOf. The right-hand side is always a static string. You may choose between the comparison operators == (checks for equality), != (checks for inequality) and contains. The latter checks for an occurrence of the string on the right-hand side within the string computed for the left-hand side.
  • isNotSet( attr) – Evaluates to the negation of isSet( attr) (see there).
  • isSet( attr) – Evaluates to true if the attribute attr of the „current” specification object is set. Otherwise it evaluates to false. See below for what the „current” specification object is.
  • map constraints – Starts a block associated with constraints defined by the expression constraints. These constraints select the specification objects for which to identify artifacts. Within the block, you can assign custom attributes of artifacts identified for this block. The expression constraints may be empty, in which case all specification objects in the configured resources will match. Otherwise, the expression can consist of one of the keywords to type, if or both (see there). An artifact is identified if it matches all constraints of the block. Within the optional block in curly braces following map, you can map attributes of specification objects to custom attributes of matching artifacts. For each attribute, it contains an expression of the form attribute to expression, where attribute is the custom attribute’s name and expression defines how the assigned value is computed.
  • name expr – Specifies the name of the artifact as the value the expression expr evaluates to. By default, the artifact name is equal to the identifier of the corresponding specification object.
  • Specification.valueOf( attr) – Evaluates to the value of a specification attribute with the name attr. The expression always relates to the specification that contains the „current” (see below) specification object. If more than one specification contains the current object, the expression refers to the first one in the list.
  • to type type – Defines a constraint to filter specification objects by type. Artifacts will only be created for those specification objects which are of type type.
  • valueOf( attr) – Evaluates to the value of a specification object’s attribute with the name attr. The expression always relates to the „current” (see below) specification object.

The keywords isNotSet, isSet, Specification.valueOf and valueOf refer to the „current” specification object. In case of the if expression, this is the specification object that is currently being checked for whether it should be identified as an artifact or not. Otherwise (attribute assignment, name expression) the „current” specification object is one that has already been qualified as a traceable artifact.

The configuration may include one or several map statements – or none at all. If no map statement is specified, all specification objects will be identified as artifacts. The same is true if one of the map statements has no constraints. In case of several map statements, an artifact will be created for a given specification object if it fulfills the constraints of any statement.

Version

An artifact’s version is used for suspicious links validation. The version of an artifact of this type is evaluated as a JSON-like concatenation of all artifact custom attribute values.