Page 205 -

196 M. Pesic
pickup delivery pickup bill
S0 S0 S1 S0 S0 X

temporarily
temporarily temporarily violated temporarily temporarily violated
violated violated violated violated
(a) The change is successful for ci 1 (b) The change is not successful for ci 2
Fig. 6.16 The dynamic change involving the model shown in Fig. 6.15

6.5 Conclusions

To conclude this chapter, we first reflect on the differences between procedural and
declarative languages. Then, we summarize the main capabilities of the approach
presented in this chapter by using the flexibility taxonomy given in Sect. 6.1.
Neither procedural nor declarative workflows represent a better solution when
it comes to automation of business processes. On the one hand, business processes
that are repeatedly executed in the same manner can clearly benefit from a procedu-
ral workflow specification. For example, for the handling of insurance claims, tax
declarations, customer orders, etc., a process where always the same procedure is
followed is desirable. On the other hand, some processes must be executed in a way
that fits best with frequently changing and personalized circumstances. These pro-
cesses are better specified in a declarative manner because they need a high degree
of flexibility, that is, it is desirable that they can be executed in various manners. For
example, many processes from the health care domain need flexibility because they
must be adjusted to specific circumstances and patients.
Moreover, for processes that are partly highly structured and partly loosely
structured, a combination of both approaches can be chosen to specify the overall
business process. For example, the declarative ConDec workflows Truck Load and
Less than truck Load can be subprocesses of the Carrier Appointment net, as shown
in Fig. 6.17. Also, when necessary, a YAWL workflow can be a part of a declarative
ConDec model. Using the service orientation it is possible to mix various modeling
styles. A concrete implementation that enables creating decompositions of YAWL
(e.g., procedural) and declarative models is presented in Chap. 12 of this book.
This chapter introduced a new way of modeling and enacting workflows. The
described approach aims to be more flexible than the existing proceduralapproaches.
Table 6.3 shows that declarative ConDec workflows can be used to support multiple
types of flexibility.
First, because they can easily include a wide range of execution alternatives,
ConDec workflows have a high degree of flexibility by design. For example, the
ConDec models shown in Figs. 6.9–6.11 and 6.15 all have infinitely many exe-
cution alternatives (i.e., the sets of satisfying traces of these models are infinite).
Second, decomposing ConDec tasks to sub-workflows (e.g., YAWL workflows)
allows for flexibility by underspecification. Moreover, this type of flexibility can
be achieved either by explicitly specifying the decomposed sub-workflow in the