The purpose of the Variability Matrix is to facilitate work with variant models. The matrix enables users to easily work with features and components in a matrix layout. The view is tied to our variability meta model, but can be associated with any type of model, design, stakeholder, etc. The configuration supports multiple instances. This article describes how to configure the view.


Example Data

Configuring the View

  1. Go to File > Configure the explorer
  2. On the Item views tab, select Variability matrix.
  3. Click View example XML and copy the script as a starting point for your configuration. 
  4. Click Edit configuration and paste the configuration in the Edit XML window. 
  5. Modify the configuration to meet the needs of the use case. (See the explanation of available elements below.)
  6. When you are ready to test and make it available to users, check the Active box. Users must log out and back in to see the new option.

Example Configuration

Below is an example XML definition and model for the Variability matrix view. 

The illustration shows our standard Variability model (in red) along with placeholder item and part types for the model to be associated with features

The yellow numbers in the illustration above are included in the example configuration below.

    <Config id="Id1">
       <Caption>Set Variability</Caption>
       <Description>Hint shown in the ribbon</Description>
    1. <TopItemType>3PTA</TopItemType>
    2. <CurrentItemType>ARAS</CurrentItemType> 
    3. <ActionItemType>DREQ</ActionItemType> 
    4. <HandledFamiliesPath>/LCVAF</HandledFamiliesPath>
    5. <ParentItemType></ParentItemType>
    6. <ShowPartTypes>7IRC;7IRS;IDRE</ShowPartTypes>
    7. <FamiliesPath>/SDFM/10IVP</FamiliesPath>
    8. <ValuesPath>/SDFM/10IVA</ValuesPath>
    9. <ValueFamilyPartType>10IFP</ValueFamilyPartType> 
    10. <ExistsForPartType>DREF</ExistsForPartType>

Explanation of the Configuration Elements

<Configs> is the top tag which can include one or more <Config>.

<Config> is the top tag of each configuration and must have an id attribute. The id attribute identifies the specific configuration, and should be a unique string value when multiple configurations exist.

<ViewSettings> enables you to set a custom view label, hover-tip, icon, etc. See How to Configure Item View Menu Button Settings 

<TopItemType> is the SID of the item type that contains the feature model and connects it (creates a context for) the model to be associated with features. It can be any type of model, e.g., design, stakeholder, etc.

<CurrentItemType> defines the item type that activates the view.

<FixedColumnWidth> sets the width, e.g., 50, of the variant columns and disables the default auto-width behavior. If needed, a scrollbar will become visible. Should any column headers still be cut off due to lack of space, a hover-tip displaying the entire header value will be provided. 

<NameColumnWidth> sets the width, e.g., 100, of the Name column in the view. 

<ActionItemType> defines the item type where the association to the "Exists for" part is added, e.g., the design requirement in a Logical Design Component.

<HandledFamiliesPath> is the path from the CurrentItemType, or from the ParentItemType, to the valid Variability Family item.

<ParentItemType> If the CurrentItemType doesn't have a reference to a Variability Family, the ParentItemType should have one. The CurrentItemType should exist as a part to the ParentItemType.

<ShowPartTypes> sets the part types to be displayed in the substructure of the CurrentItemType.

<FamiliesPath> is the path from the TopItemType to the Variability Families in the Feature Model.

<ValuesPath> is the path from the TopItemType to the Variants in the Feature Model.

<ValueFamilyPartType> is the part type from Variant to the Variant Family.

<ExistsForPartType> is the part type from the ActionItemType to the logical expression for the variant condition.

Example Result

"Software component" selected.

Things to Consider

Note the difference between the CurrentItemType and the ParentItemType. If the substructure of, for instance, a logical component is normally small, then the CurrentItemType can have the relationship to the valid Families. This means that the ParentItemType can be empty.

If the structure can be large, the CurrentItemType can be a sub-set (like a requirement container). Then the CurrentItemType is the Requirement Container, and the ParentItemType is the Software Component. The view will be triggered from the Requirement Container.