Information Technology Reference
In-Depth Information
•
mutual exclusion of types
:
At most one of the types
t
1
and
t
2
may exist.
¬
(F(
t
2
))
Considering again the birthday card creation workflow scenario, the fol-
lowing lists some exemplary essential characteristics of the application that
should be covered by the domain constraints, and that can in fact easily be
expressed using templates from above:
(F(
t
1
)
∧
•
Enforce the use of
draw
.
Enforce the use of
polaroid
.
•
At most one of
border
and
polaroid
may be used.
•
Do not use
image improvement
more than once.
As indicated earlier, the domain model can not only be used as basis for
workflow synthesis, but also be applied for enhancing the workflow devel-
opment support via model checking as described in Section 2.2. While the
model checking is not necessary for workflow parts that were produced by
the synthesis (as it takes care of meeting the constraints automatically), it
can be useful in case that the workflow developer changes the synthesized
parts later. On the one hand, domain constraints can be re-used as global
workflow properties and evaluated by the model checker. On the other hand,
model checking constraints can be derived from the service interface descrip-
tions that allow for automatic checking of type consistency within a model
using the input and output specifications (cf. Section 2.2.3). To achieve this
kind of global type monitoring, PROPHETS generates the following formula
structure for every type
t
∈
T
automatically:
u∈USE
(
t
)
¬
u
WU
g
g∈GEN
(
t
)
where
USE
(
t
) denotes the services that have
t
as input (use) and
GEN
(
t
)
the ones that have
t
as output (gen). Intuitively, the formula expresses that
no service that uses
t
must be called before a service has been called that
generates
t
.
2.3.3 Workflow Design with Loose Specification
In the actual
workflow design
phase, the workflow designer benefits from
the domain model that has been set up according to his needs, referring
to services and data types using familiar terminology. As detailed in the
following, the concept of
loose specification
is central to workflow design with
PROPHETS: it is possible to mark branches between SIBs as loosely specified
to denote that they are abstract representations of the corresponding part of
the workflow, and that their translation into a readily executable workflow is
left to the synthesis framework.
Search WWH ::
Custom Search