Dead path elimination is used to describe the execution semantics of process instances that are represented in graph-based languages.In this example, the Accept Credit activity can only be enabled after request approval has signalled its outgoing edge. If Request Approval is executed, then the signalling is true; otherwise, the edge is signalled false. Therefore,
after the Assess Risk activity has provided a high risk factor as output value,
Accept Credit cannot be started, at least not immediately after Assess Risk
Since the risk is assessed to be high, the start condition of the Request
Approval activity is evaluated to true. This activity is started and approves
the credit request; this approval is represented by changing the value of the
risk factor from high to low. When the edge to the Accept Credit activity is
signalled, the start condition of that activity is evaluated to true, and the
credit is granted In this process instance,
Assess Risk determines a low risk factor, so Request Approval is not required.
In this case, the edge from Assess Risk to Request Approval is signalled false,
indicating that request approval is not required.
On receiving this signal, Request Approval immediately relays a false signal
to its outgoing edge, in this case, to the Accept Credit activity. Now all incoming
edges of the Accept Credit activity have been signalled, so that the start
condition can be evaluated. Since the risk factor is low, the start condition is
evaluated to true, so that the credit can be granted.
Graph-based workflow languages are useful for implementing business processes,
in which process activities are realized by software systems. Just as procedures realized by software systems read input parameters on their start
and write output parameters on their termination, so do process activities in
graph-based workflow languages.
Data flow can be expressed well by relating output parameters of process
activities to input parameters of follow-up activities. Since control flow is
defined by edges between activities and start conditions of activities, basic
control flow patterns, such as sequence, splits, and joins can be expressed.
Graph-based workflow languages do not support arbitrary cycles, because
in cyclic process models, dead path elimination causes problems. Advanced
control flow patterns, such as multiple instances patterns or discriminator
pattern, are also not supported by graph-based workflow languages.
Business Process Modeling Notation
In this section, the Business Process Modeling Notation (BPMN), developed
under the coordination of the Object Management Group, is introduced. The
focus of this section is not a complete presentation of the standard, but a
discussion of the main concepts of business process diagrams expressed in the
Business Process Modeling Notation.
The intent of the Business Process Modeling Notation in business process
modelling is very similar to the intent of the Unified Modeling Language for
object-oriented design and analysis. To identify the best practices of existing
approaches and to combine them into a new, generally accepted language. The set of ancestors of BPMN include not only graph-based and Petri-netbased
process modelling languages, but also UML activity diagrams and eventdriven
While these modelling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, the Business Process
Modeling Notation aims at supporting the complete range of abstraction levels,
including business levels and software technology levels. This goal is also
laid out in the standards document, which states, “The primary goal of BPMN
is to provide a notation that is readily understandable by all business users,
from the business analysts that create the initial drafts of the processes, to
the technical developers responsible for implementing the technology that will
perform those processes, and finally, to the business people who will manage
and monitor those processes.”