Sunday, October 4, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec S -- By Mathias Weske

Temporal Aspects

Activities in workflow nets are represented by transitions. When a transition
fires, it withdraws tokens from its input places and puts tokens in its
output places, depending on the decision made by the transition. These steps
(withdrawing tokens, determining where to put tokens, and finally putting the
tokens) in Petri nets are represented by the firing of the transition, which does
not consume time. This assumption is in contradiction with activity instances,
which do take time. The processing of an insurance claim, the preparation of
a quote, and the checking of a warehouse inventory are activities that take
The fact that activities take time is also reflected by the state transition diagram
of activities. In state transition diagrams, state transitions are triggered
by events. For instance, the completion of an enter customer order activity
enables a check inventory activity. This means that activity instances have
lifecycles that consist of a number of steps, from their instantiation, their enabling,
and their execution to their termination. In workflow nets, these steps
are not represented, because firing puts an activity from the enabled state
immediately into the terminated state.
This contradiction is partly solved in workflow management systems using
Petri nets. Assume that a business activity represented by a transition is
realized by invoking a piece of software. The invocation of the software is
often represented by the firing of the transition. However, software procedures
also take time. In addition, the follow-up activities should not be enabled
when the previous activity is started, but when it completes. If an activity is
implemented in software, then the follow-up activities should not be enabled
when the software is invoked, but after it has completed.
The timeliness of activity instances represented by workflow nets also implies
that no events can occur during an activity instance. In real-world business
processes, however, this is not true. Many things do happen during the
execution of a business process activity. For instance, while an inventory is being
checked, new items may enter the warehouse. These issues are not covered
by workflow nets; it is the responsibility of business process management tools
to solve issues that might result from these abstractions in workflow nets.

Yet Another Workflow Language

The motivation for the development of Yet Another Workflow Language
(YAWL) was the lack of a process language that directly supported all control
flow patterns. While it uses workflow nets as a major ingredient, the execution
semantics of process instances is specified by state transition systems and not
by Petri nets. In this section, YAWL and its support for control flow patterns,
as well as its execution semantics, are investigated.
While Petri nets provide a sound formalism for expressing most control
flow patterns, the following deficiencies have been identified that hamper the
expression of the full set of control flow patterns.
• Multiple Instances: Multiple instances patterns describe business processes
with multiple instances of specific activities. The number of activity instances
of one particular activity model might not be known at design time.
Petri nets do not provide adequate means to describe multiple instances
• Advanced Synchronization Patterns: Petri nets can directly express and
split/join and exclusive or split/join using places, transitions and firing
rules of traditional Petri nets. Advanced synchronization patterns such as,
for instance, or split and or join and discriminator patterns, however,
cannot be conveniently expressed in Petri nets.
• Nonlocal Firing Behaviour: The enabling of activities in a business process
is based onlocal knowledge only. In the context of Petri nets, the presence
of tokens in the input places of a transition indicates activation of that
transition. In business processes, there are situations in which nonlocal
parts of the process are affected by a decision. For instance, the cancellation
pattern somehow vacuum-cleans defined parts of the Petri net when being
activated. If used to cancel a customer order, different activities in different
parts of the Petri net need to be cancelled in order to cancel the overall
customer order.

No comments:

Post a Comment