pure::variants supports the hierarchical composition of variants as explained in Section 5.6, “ Hierarchical Variant Composition ” . A variant hierarchy is set up by creating links to VDMs or Configuration Spaces in a Feature Model. Three different kinds of links are available:
Variant Reference
A variant reference is simply a link in a Feature Model to a concrete VDM of another Configuration Space. The selections in the linked VDM are locked and can not be changed in the resulting variant hierarchy.
Variant Collection
A variant collection is a link in a Feature Model to another Configuration Space. The VDMs defined in this Configuration Space are automatically linked. The selections in the linked VDMs are locked and can not be changed in the resulting variant hierarchy.
Variant Instance
A variant instance is a link in a Feature Model to another Configuration Space. In a VDM of a Configuration Space with this Feature Model as input, it is possible to create concrete Instances below the variant instance link, which just means to construct a new linked VDM with an empty and free editable selection for the linked Configuration Space.
While Feature Models from a linked Configuration Space are directly linked below the link elements of the parent Feature Model, the Family Models from the linked Configuration Space are linked into the first Family Model of a corresponding Configuration Space, flat below the special element LINKED_FAMILY_MODELS that is automatically created.
Note
Intentionally there is no restriction towards linking VDMs and Configuration Spaces recursively. Thus it is possible for example to link a VDM which itself links other VDMs or whole Configuration Spaces.
To create a link to a Configuration Space or VDM below an element of a Feature Model select that element, click right and select the wanted kind of link from the context menu (one of Variant Reference , Variant Collection or Variant Instance ). This opens a wizard that allows to select the Configruation Space or VDM to link. In case of a variant collection link additionally the variation type of the link element has to be specified. The actual linking of VDMs and Configuration Spaces is not performed directly in the Feature and Family Models containing the links. It is performed when opening the VDMs of a corresponding Configuration Space.
If a variant instance link is created, then the VDM Editor provides two additional actions in the context menu on the corresponding link elements, i.e. New->Instance and Remove Instance . These actions allow to create and remove the concrete instances, i.e. VDMs, of the linked Configuration Space.
Relations between the variants of a variant hierarchy can be expressed using restrictions and constraints. See Section 9.7.8, “Name and ID References” for details on how to reference elements from specific variants.
To distinguish multiple instances of the same variant in a variant hierarchy, all IDs and the element unique names in the models of each linked variant are changed according to the position of the variant in the hierarchy. Element unique names are prefixed with the unique name of the corresponding link element in the parent variant, separated by a colon (":"). If the parent variant is not the top of the variant hierarchy, then the unique names of its elements also are prefixed this way. Figure 6.7, “Unique Names in a Variant Hierarchy” and shows a hierarchy of three variants and how the unique names are prefixed in each variant.
The unique IDs are prefixed in the same way except that the unique ID of the link elements is used as prefix.
Figure Figure 6.8, “Example Variant Hierarchy” shows how a simple house is modeled using Hierarchical Variant Composition. The VDMhouse is top-level and contains a Variant Instance Link namedrooms . The house contains a kitchen, a kids room, a living room and a bedroom. The figure shows the kids room and the kitchen. These rooms are linked VDMs with the nameroom . This name is prefixed with the name of the corresponding Variant Instance Link element, i.e.Kids_Room:Rooms . This ensures uniqueness of the element unique names. Same rule is applied to the element IDs. The room VDM also contains a Variant Instance Link with name doors . It refers to the doors Configuration Space, visible on the left. For the kids room two doors are available, i.e. Back_Entry and Front_Entry . Note the exclusions in this model. For the concrete house the kitchen is excluded, and for the kids room the back door is also excluded. The exclusion causes the Model Evaluator not to propagate selections of elements that are below the excluded element. Thus the selection is valid although for examplekitchen:Doors or Front_Entry:Material are explicitly selected. Warnings are shown to give the user a hint for this fact, e.g.Excluded 'kitchen' overwrites selection of kitchen:Room .
pure::variants supports sharing common feature selections/exclusions between several variant descriptions. This allows users to define the models for each VDM from which selections are to be inherited. Changes in the inherited model selection will be propagated automatically to all inheriting models. Inheritance is possible across Configuration Spaces and projects. See Section 5.7, “ Inheritance of Variant Descriptions ” for details.
The VDM inheritance hierarchy can be configured on the Inheritance Page of the Model Properties. See Section 7.5.3, “ Inheritance Page ” for a detailed description of this page.
It is possible to load the feature selection from another VDM into the currently edited VDM. Right-click in the VDM Editor window and choose from the context menu. This opens the dialog shown inFigure 6.9, “Load Selection Dialog” .
In this dialog the VDM from which to load the selection has to be selected. All selections in the currently edited VDM are overwritten with the selections from the loaded VDM.
If this action is called in an instance element the selections are changed for the selected instance only.
A reused Variant Description Model ("instance") can be renamed by selecting from the context menu as shown inFigure 6.10, “Rename Reused Variant Description Model” .
The opened dialog lets you choose a new name for the instance at hand and also has the option to allow a name comparison. If the option is set in two instances with the same name and the same parent, these instances will be treated as equal in comparisons. If the option is left out, the instance will be treated as unique and independent, although it might be named and positioned as another instance in another Variant Description Model.
The reused Variant Description Models ("instances") can be reorder by selecting from the context menu as shown in Figure 6.12, “Reorder Reused Variant Description Models” . The context menu can be found by right clicking on the instance group or any instance in the variant model editor.
The reordering is only allowed for non-inherited variant instances. The order of the inherited instances is the same as in the inherited models and are grouped together in the order of the inherited models themselfs. Instance order mutation is allowed only between not inherited instances. Nonetheless, it is not allowed to move an instance out of the containing group.
A dialog for reorder instances will pop up as shown in Figure 6.13, “Reorder Instances Dialog”, which lists two categories of variant instances. Inherited instances are in the immutable list and non-inherited instances are in mutable list. Any or consecutive number of multiple instances can be selected and moved up or down using or button. To confirm the order, button can be pressed. Then Save the variant model to store the instance order. The categories themselves are not movable. Inherited instances are always showed at the top of the group.
