Default Values¶

Typically, a configuration is set by users entering values for enumeration instances and primitive type instances. Using default values allows the suggestion of values for these elements. A default value is applied to a field if the user has not previously entered a value and if the value does not conflict with any constraints.

Defaults may be specified with or without conditions, as illustrated in the following example.

behavior {
    // Bikes should have white color by default
    default color = White

    // For blue bikes we propose a stand by default
    condition color = Blue
    default   withStand = true
}

Using default values offers several benefits:

They provide sensible, yet optional, recommendations to the user.
They offer a valid starting point at the beginning of the product configuration session.
They reduce the duration of the configuration session, as users are not required to manually select each value.

Roles of Configuration Values¶

The values in a configuration session can take different roles, here given in decreasing in priority:

Selected: A user explicitly set the value.
Consequence: The shown value is the only valid value left to choose for a feature. All other values would yield contradictions with respect to constraints.
Default: The value was derived because of a default behavior.
Completion/Undefined: The value was randomly chosen during the session by the reasoner. In a non-optimization configuration scenario, this role is equivalent to undefined.

Note that these roles are only valid within the context of a specific configuration session.

Defaults in Action¶

We distinguish multiple scenarios when modelling defaults for a configuration knowledge base.

Basic Defaults¶

Basic defaults provide pre-selections on the startup of the configuration session. They will be overridden in case they conflict with constraints or the user selects a different value.

behavior {
    default color = White
}

Conflict-Overridden Default¶

Due to a constraint, using a default value does not result in a valid configuration. We anticipate that this constraint will remain in effect and that user inputs will override these defaults. If an alternative default value is available and does not conflict with the constraint, it should be chosen when the user has not made a selection. If no suitable default exists, the feature should remain unspecified (role: Completion).

// Basic default (1)
behavior {
    default color = White
}

// Conditioned default (2)
behavior {
    condition withStand = true
    require color != White
}

When the user selects withStand = true, then the conditioned default behavior (2) overrides the basic default (1).

Cascading Defaults¶

Since default behaviors can have conditions, fulfilling one default might satisfy the pre-conditions of another default. Thus, there can be a cascading propagation of defaults.

behavior {
    default color = White
}

behavior Carrier {
    condition root.color = White
    default carrierColor = White
}

The example illustrates, that the color of the Carrier should be white, when the color of the bike is set to white. Please note, that the second behavior block has the type Carrier as the relative path root and thus the statement carrierColor = White points to root.carrier.carrierColor.

Conflicting Defaults¶

Using conditional defaults enables modeling scenarios where two features might independently have default values, but their combination is prohibited due to constraints. To ensure that derived configurations remain valid, certain defaults cannot be applied to prevent conflicts. We manage such conflicts between default values effectively by establishing two types of priorities.

Automatically derived Priorities¶

A default has a higher priority, if it has more conditions. The reasoning here is, that a default with more conditions applies to a more specific situation and is thus more important.

// Behavior (1)
behavior {
    condition suspensionFork = true
    default handle.extraSoftGrips = true
}

// Behavior (2)
behavior {
    default lights = true
}

// Behavior (3)
behavior {
    // not both, extraSoftGrips and lights can be simultaneously true
    require ! (handle.extraSoftGrips = true && lights = true)
}

Assuming the element suspensionFork was set to true, the default behavior (1) would win over the basic default behavior (2), since it applies in a more specific situation. Please note, that the constraint in behavior (3) creates a conflict in this situation and a resolution strategy need to apply.

Manually specified Priorities¶

The developer of the knowledge base can manually attach priority values to the default keyword. Integer numbers represent the different priorities, where higher numbers gain a higher priority during the reasoning. Note, that manually specified priorities always overrule automatically derived priorities.

// Behavior (1)
behavior {
    condition suspensionFork = true
    default/2 color = Red   // Priority level 2
}

// Behavior (2)
behavior {
    condition lights = true
    default/3 color = Blue   // Priority level 3
}

When the configuration session has the values suspensionFork = true and lights = true, then the default color = Blue will be set, since behavior (2) has the higher priority level.

Exclusive Defaults¶

If selecting default value A results in another feature having only one valid value B available, both values will assume the role of Default, even if there is no explicit default behavior designated for B.

behavior {     // (1)
    default frontWheel = W24
}

behavior {     // (2)
    combinations ( frontWheel  rearWheel  )
    allow        ( W24         W24        )
    allow        ( (W26 W28)   W28        )
}

The example sets frontWheel = W24 because of behavior (1). Due to the combination table (2), also rearWheel = W24 is set as default, since there is no other valid value left for rearWheel.