Product-Line Selection

This section describes the process and concepts behind product-line selection in ArchStudio. Actual product-line selections are done by the product-line selector tool.

Product line architectures (PLAs) are used to describe a family of closely related products. A PLA describes a set of common core components as well as the variation points across the specific product architectures. The variation points modeled by xADL 2.0 are optional elements and variant types (in the Options and Variants schemas).

Optional elements may or may not be included in the selected product architecture. An element whose type is a variant type will always be included, but may take on alternative forms for different product architectures. Optionality is specified with a boolean guard (if the guard condition is met—that is, the boolean expression evaluates to true, the element is included) and variants are specified by mutually exclusive boolean guards (the variant whose guard condition evaluates to true is the selected variant).

ArchStudio's Product-Line Selector is used to automatically select a product architecture (or a smaller PLA) from a PLA based on user-specified variable-value bindings. These bindings are simply name-value pairs in a symbol table.

The selection process works as follows:

Each optional element in the PLA is identified. Variables in the element's boolean guard are replaced by their values from the symbol table, and the guard condition is evaluated. If the condition evaluates to true the element is made non-optional (i.e., mandatory) in the architecture. If the condition evaluates to false the element is removed from the architecture. If, after evaluation, there are still unbound variables in the expression, the expression is minimized (removing parts of the expression that can be fully evaluated based on bindings in the symbol table), and the element remains optional in the architecture.
Each element of variant type in the PLA is identified. For each variant in the variant type, variables in the variant's boolean guard are replaced by their values from the symbol table, and the guard condition is evalauted. If the condition evaluates to true, then the element's type is changed to be the associated variant. If conditions cannot be fully evaluated, the guards are reduced (as with optional elements) and the elements remain of variant type.

For example, an optional component before selection might look like this. Here is Comp2 shown with its optional field which contains the boolean guard:

x @[0, 50] || y > 0

(Note: x@[0, 50] is the notation for 'in range,' i.e. 0 <= x <= 50).

The xADL description of this component in abbreviated non-XML notation looks like this:

component{
  (attr) id = "comp1"

  //Description and other properties elided for
  //simplicity

  optional{
    guard{
      booleanExp{
        or{

          booleanExp1{
            inRange{
              symbol = x
              value = 0
              value = 50
            }
          }

          booleanExp2{
            greaterThan{
              symbol = y
              value = 0
            }
          }
        }
      }
    }
  }

  (xlink) type = "#Type_1"
}

If the guard condition is met, its optional field is removed. So for our example if in the symbol table we define x = 10 (regardless of y's value), after selection the optional component will look like this:

(Note that the dotted 'optional' border is replaced by a solid 'mandatory' border. That same component's xADL description (in abbreviated non-XML notation) will look like this:

component{
  (attr) id = "Comp2"
  (xlink) type = "#Type_1"
}

The optional field has been removed; this component is now a mandatory part of the architecture. However, if the guard were evaluated to false, the component would be removed from the architecture entirely. If parts of the guard could not be evaluated, the boolean expression will be simplified as much as possible.

The selector also selects variant types. Here is a variant component type (Variant Type) with two variants (Component Type 1 and Component Type 2):

In xADL, this would look like this:

componentType{
  (attr) id = "variantType"

  variant{
    guard{
      booleanExp{
        equals{
          symbol = language
          value = "English"
        }
      }
    }
    (xlink) variantType = "#ComponentType1"
  }

  variant{
    guard{
      booleanExp{
        equals{
          symbol = language
          value = "Spanish"
        }
      }
    }
    (xlink) variantType = "#ComponentType2"
  }
}

The first variant has the guard language == "English" and the second variant has the guard language == "Spanish". If we perform selection based on a symbol table with the entry language = "English", all references to type 'variantType' will be replaced with references to 'ComponentType1.'

Note that the algorithm will report an error if all of the guards for the variants (of a single variant component type) evaluate to false or if more than one guard evaluates to true.

The selector requires the Boolean Eval component to evaluate the boolean guards used in optional and variant elements. Please see the options and variants schema in xADL 2.0 for a list of optional and variant elements that are supported by the selector.

Symbol Table Files

The Selector component can load and store symbol tables (e.g., sets of variable-value bindings) in an ASCII text file. This section describes the formatting of that file.

Comments can be represented by // just as in C++ or Java. Otherwise, the basic layout of the file is as follows:

Variable = value
Variable = value
etc.

There can be leading and trailing spaces that will be stripped away. The value of the variable is represented by strings as specified here. Some examples:

/* Set the value of alarm variable to the date Jan 1st 2003 */
alarm    = #1/1/03#
/* Set the value of speed variable to the number 23.1 */
speed    = 23.1
/* Sets the value of language variable to the string 'English' */
language = "English"

Additional questions about the Selector should be sent to Ping H. Chen.