In pure::variants a variant description, i.e. the selection of features in a VDM, can be evaluated and verified using the Model Evaluation. See Section 5.8, “ Variant Description Evaluation ” for a detailed description of the evaluation process.
A variant description is evaluated by opening the corresponding VDM
in the VDM Editor
and clicking on button
in
the Eclipse toolbar. Detected selection problems are shown as problem
markers on the right
side of the editor window and in the Problems View. On the left side of
the editor window
only those markers are shown that point to problems in the currently
visible part of the
model. Clicking on these markers may open a list with fixes for the
corresponding
problem.
Automatic evaluation of the variant description is enabled by
pressing button
in the Eclipse
toolbar. This will cause an evaluation of the element selection each time it
is
changed.
If the variant description is valid, then the result of the
evaluation are the concrete
variants of the models in the Configuration Space shown in the Result View
(see
Section 7.4.8, “
Result View
”
). The concrete variants of the models are collected in the
Variant Result Model, that can be saved to an XML file using the button
. Saved Variant Result Models can be
opened with the VRM Editor. See
Section 5.9.2, “
Variant Result Models
”
for more
information about Variant Result Models, and
Section 7.3.5, “
Variant Result Model Editor
”
for a detailed description of the VRM Editor.
The model evaluation is configured on the Model Evaluation tab of the Variant Management->Model Handling preferences page (menu Window->Preferences , see Figure 6.2, “Model Evaluation Preferences Page” ).
When the "Evaluate Model" button is clicked in the VDM Editor, the current feature selection is analysed to find and optionally resolve conflicting selections, unresolved dependencies, and open alternatives. Additionally the implicitly selected and mapped features are computed. For this analysis a timeout can be set. It defaults to two minutes which should be long enough even for big configuration spaces. The timeout can be disabled by unchecking the "Timeout for checking a feature selection" check box.
Finding mapped features is an iterative process. Mapped features can cause other features to be mapped and thus included into the selection. The default maximal number of iterations is 32. Depending on the complexity of the dependencies between the mapped features it may be necessary to increase this value. In this case pure::variants will show a dialog saying that the maximal number of iterations was reached. The iterations limit can be disabled by unchecking the "Limited feature mapping iterations" check box.
If the automatic model evaluation is enabled, changing the current feature selection in the VDM Editor causes an automatic evaluation of the Configuration Space. The evaluation process is not started immediately but after a short delay. The default is 500 milliseconds. With the "Restart model evaluation after mouse move" switch it is configured whether the timer for the evaluation delay is reset if the user moves the mouse.
It is possible to define a list of element attributes that are ignored during the model evaluation.
Note
For listed attributes it is not possible to access them in restrictions and calculations during the model evaluation process. These attributes also do not become part of the Variant Result Model, i.e. the concrete models of the variant.
The default list of ignored attributes contains the administrative attributes ps:Source, ps:Changed, ps:ChangedBy, and ps:Created.
For each configuration space, the strictness of the evaluation of the contained variant description models regarding problematic modeling constructs can be configured (see Figure 6.3, “Configuration Space Evaluation Settings Page”).
The following problematic constructs are checked and for each of them the complain level is configurable. However, it is recommended to use the most strict settings if possible. One example for an exception of this recommendation would be the enabling of current pure::variants versions to use also legacy or baseline models containing such constructs.
- Violating one-definition rule for user functions in pvSCL
pvSCL user function definitions have to follow the one-definition rule (ODR). So, multiple definitions of pvSCL functions with the same signature, i.e., same name and same number of arguments, violate this rule. For the user it is usually unclear, which of these multiple function implementations will be called in which case. Hence, to ensure the adherence to the ODR, the evaluation checks for this violation.
- Comparing values of incompatible types in pvSCL
Comparing values of incompatible types in pvSCL, e.g., of values of type string and number, involves an implicit conversion of each value into a string followed by a string comparison. This could lead to potentially unexpected results for the user.
- Referencing non-existing models or elements in relations or pvSCL
Referencing non-existing models or elements is a common modeling issue. Especially, references to non-existing elements are interpreted as unselected by default. So they are not easy to find.
- Relation types to be considered in reference check
The scope of the non-existing references check is configurable: With option All all relation types are checked, whereas with option Built-in only the check is done for pure::variants' predefined relation types only (see Section 9.2, “Element Relation Types”).
- Using ambiguous element references in pvSCL
Using several models in a configuration space can result in non-unique element names. Referencing such elements by their name is ambiguous and can lead to unexpected results, since the first occurence is used by default.
- Resolving invalid default-selected alternatives
Multiple default-selected non-restricted alternatives result in an invalid configuration. In rare circumstances, this problem can be automatically resolved, but the automatic resolution could also lead to potentially unexpected results, e.g. invalid variants although a valid solution exists.
For pure::variant version 5 projects, the configuration mode can be set for each VDM separately during creation of a VDM or later at any time in the Configuration Mode page of the VDM's Properties dialog (see Figure 6.4, “Variant Model Configuration Mode Page” ).
Each feature and element has a default selection state defined in Feature and Family Model. Normally Family Model elements and mandatory features are created with the state "on". All other Feature Model elements are created with the state "off". Except for mandatory features and elements, the default selection state can be changed by the user.
In full configuration mode, a feature or element with the default selection state "on" is selected automatically if the parent element is selected. To deselect this element either the parent has to be deselected or the element itself has to be excluded by the user or the auto resolver.
In partial configuration mode, the default selection state is ignored, since this state controls the default handling of unselected elements. So, unselected elements stay open independent of the default selection state.
If a feature selection is evaluated to be invalid, selection problems will occur. Such selection problems are for instance failed relations, constraints or restrictions. Certain selection problems are eligible to be resolved automatically. For example, a not yet selected feature that is required by a relation can be selected automatically.
The pure::variants auto resolver component provides a set of heuristics to resolve failed relations, features selection ranges and basic propositional constraints. They are applied only in full configuration mode. In partial configuration mode the auto resolver is not executed.
Note
The auto resolver does not change the selection state of user selected or excluded features. It only adds new selections or exclusions.
As shown in
Figure 6.5, “Automatically Resolved Feature Selections”
, auto resolving for a VDM is enabled
by clicking button
in the tool bar.
The auto resolver does only resolve selection problems locally, i.e., it considers only a single relation or constraint. It cannot consider the potentially hidden dependencies of the complete set of the evaluated feature and family models.
The pure::variants extended auto resolving component therefore uses an approach to add feature selections and exclusions, which are logically mandatory based on the whole set of feature and family models and the user selections and exclusions. It will run before evaluation, so the evaluation already checks these new automatic selections. The extended auto resolving is executed both in full and partial configuration mode. For both modes the behavior is equal.
The extended auto resolving uses a SAT solver based approach. It covers the propositional part of the models, i.e., the feature and family model tree structure with selection ranges, all built-in relations, and the propositional parts of constraints and restrictions in pvSCL, like Boolean operations. It does not cover attributes with their values and parts of pvSCL expressions, which are not propositional, like comparisons, arithmetical operations and model element traversal. However, non-propositional expressions do not influence the reliability of the result. The not useable parts are simply mapped to open Boolean variables.
Considering the already done user selections and exclusions, the extended auto resolving will first check, if the propositional part is satisfiable, i.e., a configuration can be reached by adding more selections, which at least fulfills all propositional dependencies of the models. If the satisfiability is given, for each unselected feature and element it will be determined, whether it has to be selected or excluded to fulfill all the propositional rules. However, if the models also contain non-propositional parts, it is still possible that a configuration, which fulfills all model dependencies can never be reached.
If the propositional part of the models is not satisfiable, i.e., there is a conflict in the models or the user selections or exclusions, the extended auto resolving cannot determine any new selections and exclusions. Then also the complete model dependencies including the non-propositional parts, cannot be fulfilled.
Both auto resolving components are configured on the Auto Resolver tab of the Variant Management->Model Handling preferences page (menu Window->Preferences , see Figure 6.6, “Auto Resolver Preferences Page” ).
Usually weak relation types like ps:recommends and ps:discourages are not considered by the auto resolver. Checking box "Auto resolve weak relations..." causes the auto resolver to handle weak relations like hard relations. In detail, ps:recommends is handled like ps:requires , i.e. select the required feature if possible. And ps:discourages is handled like ps:conflicts , i.e. exclude conflicting features if they were automatically selected by a ps:recommends relation.
Conflicts usually are not automatically resolved. Checking box "Auto resolve ps:conflicts relations" enables a special auto resolving for conflicts. If the conflicting feature was automatically selected due to a ps:recommends relation, then this feature becomes automatically excluded.
To get a clean selection before evaluating a model, i.e. a selection only containing user decisions, "Remove auto resolved features..." has to be enabled.
The extended auto resolver can be enabled for Feature and Family Models separately. Depending on the complexity of the Input Models, measured by counting the number of variation points, the extended auto resolver may exceed the memory and time limits of the model evaluation component of pure::variants. In this case the extended auto resolver aborts. To solve this problem following actions may be tried:
Disable the extended auto resolver for Family Models. In most of the cases extended auto resolving is not interesting for Family Models.
Review the models and try to reduce its complexity. This can be done for instance by flatten nested alternatives.
Increase the model evaluation limits in the preferences.
Disable the extended auto resolver.
To disable the extended auto resolver automatically if the input models exceed a certain count of elements, a model element count limit can be specified. The default is 100,000 elements.