Page 342 -

338 M. Pesic et al.
verify against create instance
dead tasks mandatory set to verification start from
and conflicts automaton initial state (replay trace) current state

? starting X X X
instance
developing
model
? changing X X ? ok X
instance
not ok not ok
report error
report error
cancel change
Fig. 12.12 Procedure for starting and changing instances in DECLARE

its execution based on the old model. Naturally, when applying a dynamic change,
it is also possible to verify the new model against dead tasks and conflicts but these
errors will not disable the change. Actually, the procedure for dynamic change is
very similar to the procedurefor starting instances in DECLARE, as Fig. 12.12 shows.
It is possible to perform basic model verification in both cases. The only difference
is in the execution of the automaton. When an instance is started, the execution of the
automaton begins from the initial state. In case of a dynamic change, DECLARE first
makes an attempt to “replay” the current trace of the instance on the new automaton,
that is, the new model is verified against the current trace. If this is possible, the
dynamic change is successful and the execution continues from the current set of
possible states in the new automaton, that is, the instance state, enabled tasks, and
states of constraints are determined using the new automaton and the current trace.
If this is not possible, the dynamic change fails and the instance must continue using
the old model.
Besides changing a single instance, DECLARE offers two additional options:
migration of all instances and changing the original constraint model. It is possible
to request a migration of all instances, that is, that the dynamic change is applied to
all running instances of the same constraint model. DECLARE performs migration
by applying the same procedure for dynamic change to all instances of the same
constraint model, that is, only instances with traces that can be replayed on the new
automaton are migrated. It is also possible to change the original constraint model.
In this case, all instances created in the future will be based on the new model.
Consider, for example, the dynamic change scenario described in Chap. 6 with
two instances of the ConDec model for the Less than Truck Load process shown
in Fig. 12.13a. For the first instance, tasks hpickup; deliveryi have been executed,
and tasks hpickup; bill; deliveryi have been executed for the second instance. Fig-
ure 12.13b shows a DECLARE screenshot of a changed model where task pickup,
constraint 1..* on the delivery task, and the precedence constraint are removed,
and a new precedence constraint is added between delivery and bill. As a conse-
quence of adding the precedence constraint, task bill can now be executed only
after task delivery. The migration of all active instances of this model are requested.
Figure 12.13c shows the DECLARE report for the requested dynamic change. The
migration is applied to the two currently running instances. The change failed