Statestep Tutorial

Conflicts and Modeling Non-determinism

We've seen that two rules overlap when they specify the same outcome for some combination. Two rules conflict if they specify a different outcome for the same combination.

Load "activities.s2" once again, open the rules window and display rules A and B. Now edit rule B so that not only the value calm but also breeze is selected for Wind.

You might be expecting a conflict to be reported at this point - since rule A tells us to go windsurfing if it's warm, fine and breezy whereas, in exactly the same case, rule B says to go hillwalking. However, Statestep reports only that rules A and B overlap. The reason is that the inconsistency between the two rules exists only in a comment, that is, text following a '#' on the same line. Comments are ignored by the program - so, as far as it's concerned, no particular outcome is specified for either rule.

To correct this, we can formalize the outcome by making a new variable, Activity, with values for the various possible outcomes. Rather than doing this yourself, just open the model "activitiesOutcomes.s2". This contains the same rules as "activities.s2" but with the comments replaced by values for the new variable, Activity. Thus, rule B now looks like this:

Rule B:
Temperature Weather Wind Activity
cold
warm
fine
rain
calm  
      hillwalk

The value of Activity is given on the second row of the table because we are using it as an output, that is, a result or outcome of the rule. Conversely, Temperature, Weather and Wind may be called inputs to the rule. The difference between an input and an output variable comes only from how we decide to use it in a rule; Statestep does not have different types of variable for inputs and outputs (we'll see why shortly).

Note: Constraints should not mix variables used as inputs with variables used as outputs in rules. To have a constraint such as, "If Wind is calm then Activity must not be windsurf" is to try to repeat information which belongs in the rules.

Edit rule B as before, adding breeze to the selected values for Wind. The conflict between rules A and B is now reported as expected.

The conflicting rules A and B could be interpreted as offering a choice: if it's warm, fine and breezy then we could either go hillwalking or windsurfing. The term used to describe a situation where a model allows choice or uncertainty about an outcome is non-determinism.

One problem with using conflicts to model non-determinism is that some conflicts may be unintended contradictions, that is, errors that you would want to correct. However, there is no way to tell which conflicts are deliberate and which are not without examining them every time.

The alternative way to model non-determinism is to confine it within individual rules, thus avoiding conflicts between rules. For example, to express the choice between windsurfing and hillwalking in the cases covered by the conflicting rules above, you could remove from each rule the combinations covered by both (getting rid of the conflict) and instead create a new rule to cover those combinations:

Temperature Weather Wind Activity
warm fine
rain
breeze  
      hillwalk
windsurf

Tip: In the second row of a rule, unselected values are never shown - but that doesn't mean you always need to right-click and navigate the popup menu to select a value: if the value you want is visible on the top row then hold down Ctrl or Shift and double-click or middle-click on it there; the value will then be selected in the cell below it.

Now that we know what the second row of the tables is for, the format of these rules looks a bit wasteful: For input variables (like Weather) the cells on the second row of the table are always empty, while for output variables (like Activity) the cells on the first row are always empty. In fact, this format is designed to handle situations where most or all of the variables are inputs and outputs - that is, finite state machines.

Next: Finite State Machines, Violations