Page 199 -

190 M. Pesic
<> delivery (! bill) W pickup

1..*
<> bill
delivery
precedence 1..*
pickup bill
precedence
(b) Automaton for
(! pickup) W bill
the model
(a) a ConDec model
Fig. 6.12 The ConDec model has a conflict as shown by the empty automaton

constraint 1..* requiring that task bill should be executed at least once. However, task
bill is a dead task (see Figure 6.11), that is, it cannot be executed without violating
constraints. So, there are no traces that can satisfy all constraints in this model.
Detection of conflicts can also be done using the automaton generated for the
mandatory formula of the model. If the automaton is empty (i.e., it has no states),
then this model has a conflict, otherwise it is conflict free. Figure 6.12b shows the
automaton generated for the model from Fig. 6.12a. The automaton is empty, thus
indicating that Fig. 6.12a has a conflict.
In the previous examples, dead tasks and conflicts were not caused by the com-
bination of all constraints in the model. Instead, they were caused by a specific
group of constraints. Dead tasks pickup and bill in Example 5 are caused by the
two precedence constraints and the conflict in Example 6 by the two precedence
constraints and the 1..* constraint on task bill. The smallest subset of mandatory
constraints that causes the error is called the cause of the error. In ConDec models,
the cause of error can be found by searching through the powerset of mandatory
constraints. For each element (i.e., subset of mandatory constraints) in the power-
set, the automaton for the mandatory formula can be analyzed for the presence of
dead tasks and conflicts as described in previous paragraphs. Detecting the smallest
group of mandatory constraints that causes an error supports the user in developing
error-free constraint models.

6.3 Enactment of Constraint Model Instances

Thus far, we focused on the modeling and analysis of constraint models. In this
section, the focus is on the enactment of these models, that is, the actual execu-
tion environment. Section 6.3.1 introduces the notion of constraint model instances,
Sects. 6.3.2 and 6.3.3 describe how states of constraints and instances can be moni-
tored during the execution, respectively. Enforcing a correct instance execution and
completion is discussed in Sects. 6.3.4 and 6.3.5, respectively.