Page History
...
Bound constraints restrict parameter values that can only be tested together.
Imagine that you have these parameters & values…
You will have the following issue when you click on the “Scenarios” button:
Even though the test calls for not adding the hotel, the data row proceeds to specify the preference and type of room, which is clearly incorrect.
To solve this problem, you first need to add “Not Applicable” as parameter values
This is because something will need to appear in test cases that include the value “Do Not Add a Hotel”.
...
This is the quick option… Bound Constraints!
- Click on the green arrow icon to the right from the first value name (it appears on hover)
- Click on the green arrow icon to the right from the second value name (it appears on hover)
- Confirm how you’d like to have the bound constraint operate:
Most of the time when you have “Not Applicable” as an option, you will use “mutually bound constraints” as in this case. Here, we want “Do Not Add a Hotel” to be bound with Type of Room as “Not Applicable” AND we want to have Type of Room of “Not Applicable” to be bound with “Do Not Add a Hotel” so we mark this one as a Mutually Bound Constraint.
Problem solved!
Summary
So what really just happened there?
...
- You can use the Invalid Constraint Feature to accomplish anything that the Bound Constraint feature can do.
- The Invalid Constraint feature is frequently less confusing for new users . Don’t hesitate to use the Invalid feature instead of the Bound Constraint feature.
- If you have more than 10 or so Bound Constraints or Invalid Constraints in a plan, you might find that it is easier and faster to document your paired values in Excel. If so, we would recommend (a) adding multiple paired values before you export into Excel, and (b) ensuring that you use the exact spelling of Values (e.g., ‘cutting and pasting’ is usually safer than typing)
- Especially watch out for situations where you have MULTIPLE related “Not Applicable” values in a plan. Would it make sense to create a “Bound Constraint” between, say, ‘Hotel Chain Preference = Not Applicable’ and ‘Type of Room’ = Not Applicable’? In the example above, it WOULD make sense to include that Bound Constraint. Every time ‘Hotel Chain Preference’ = ‘Not Applicable’ we would want ‘Type of Room’ to also be ‘Not Applicable’ also. Similarly, every time ‘Type of Room’ = Not Applicable, we would want ‘Hotel Chain Preference’ to also be ‘Not Applicable’. This is an example of a type of constraint that the human brain would handle effortlessly without even consciously applying logical rules.
“Bound Constraints” are rules for your model algorithm to ensure that two values must appear together. Knowing which type to use depends on your plan structure and business & technology requirements.
We will be using this set of values to demonstrate:
As a reminder, to apply a bound constraint, you need to hover over value 1, click the green arrow icon to the right from the value name, then do the same for value 2, and select the appropriate option from the 3 provided ones.
One-way Bound Pair
The underlying relationship type: many-to-one, represented by WHEN-THEN statements in the left column.
We would like to exclude combinations like ‘Breed of Animal = Shiba Inu’ and ‘Type of Animal = Cat’ from the generated scenarios. We have 2 breeds for each of the first 2 types of animal. Therefore, we can set up 4 one-way bound pairs from "Breed of Animal" to "Type of Animal":
You can check your logic by reading the statement at the bottom of the dialog.
The order in which you set the pair matters!
In this case, we wouldn't be able to say WHEN ‘Type of Animal = Cat’ THEN ‘Breed of Animal = Siamese’ because that would prevent 'Cat + Persian' from appearing and would leave 'Persian" without any possible pairing.
Important note: you may argue that the statement at the bottom still looks correct in this direction, however you need to keep in mind how the word "must" is interpreted by the algorithm. Since the evaluation is done at the "pair of values" level, "must have Breed of Animal as Siamese" = "must NOT have Breed as Persian, Shiba Inu, Golden Retriever, Arabian" - of which "Persian" is incorrectly excluded, therefore this direction wouldn't work for this example. We could use such direction if we had multiple types that can be with only 1 breed.
Mutually Bound Pair
The underlying relationship type: one-to-one, represented by ALWAYS-ALWAYS statements in the left column.
With Mutually Bound Constraints, the values are exclusive to each other. In this example, there is only one horse breed in the second parameter. So, with 1 constraint, we can specify that "Horse" should not be paired with "Siamese, Persian, Shiba Inu, Golden Retriever" AND "Arabian" should not be paired with "Cat, Dog" - i.e. "Horse" and "Arabian" must only be tested together.
Summary
The final set of rules for this model (in the verbal form) would look like this:
In essence, Bound Constraints and Invalid Constraints perform similar tasks: they ensure that certain values only or never appear together - making all generated scenarios valid within the model scope. From a different point of view, Bound Constraints and Mutually Bound Constraints actually invalidate many values and Invalid Constraints bind many values, behind the scenes.