On The Suitability Of Uml 2.0 Activity Diagrams For Business ...

On the Suitability of UML 2.0 Activity Diagrams for Business
Process Modelling∗
Nick Russell1
Wil M.P. van der Aalst2,1
Arthur H.M. ter Hofstede1
Petia Wohed3
1School of Information Systems, Queensland University of Technology
GPO Box 2434, Brisbane QLD 4001, Australia
{n.russell, a.terhofstede}@qut.edu.au
2Department of Technology Management, Eindhoven University of Technology
GPO Box 513, NL5600 MB Eindhoven, The Netherlands
w.m.p.v.d.aalst@tm.tue.nl
3Centre de Recherche en Automatique de Nancy, Universit´e Henri Poincar´e, Nancy 1
BP239, 54506 Vandoeuvre les Nancy, France
petia.wohed@cran.uhp-nancy.fr
Abstract
description of system functionality in terms of
object interactions;
UML is posited as the “swiss army knife” for sys-
tems modelling and design activities. It embodies a
• Structure diagrams which capture the underlying
number of modelling formalisms that have broad ap-
static structure of a software system at various
plicability in capturing both the static and dynamic
levels from individual objects to overall applica-
aspects of software systems. One area of UML that
tion packages.
has received particular attention is that of Activity
At its heart, UML is an object-oriented set of no-
Diagrams (ADs), which provide a high-level means
tations and is particularly eﬀective for capturing de-
of modelling dynamic system behaviour. In this pa-
tailed design models of software systems in a form
per we examine the suitability of UML 2.0 Activity
which is suitable for translation into some form of en-
Diagrams for business process modelling, using the
actment technology (usually program code) either by
Workﬂow Patterns as an evaluation framework. The
suitably qualiﬁed developers or in a semi-automated
Workﬂow Patterns are a collection of patterns devel-
manner via CASE technology. However, the breadth
oped for assessing control-ﬂow, data and resource ca-
of UML ensures that it also has potential applica-
pabilities in the area of Process Aware Information
bility in a number of other scenarios such as business
Systems (PAIS). In doing so, we provide a compre-
process modelling although in such a distinct domain,
hensive evaluation of the capabilities of UML 2.0 ADs,
some notations (e.g. the class of behaviour diagrams)
and their strengths and weaknesses when utilised for
are likely to be more useful than others.
business process modelling.
Over the past decade, the economics of software
usage have begun to change, and it is increasingly
1
Introduction
common for new systems to be based on modiﬁcations
of widely distributed software products rather than
The Uniﬁed Modeling Language (UML) is increas-
being custom software developments. There is also a
ingly being seen as the de-facto standard for soft-
broader view being taken as to the scope in which a
ware modelling and design.
The most recent ver-
system operates and the recognition that true cost-
sion (2.0) (OMG 2004) includes 13 distinct modelling
beneﬁts can only occur when software processes are
notations ranging from high-level use case diagrams,
aligned with organisational processes. These notions
which depict the interactions and relationships be-
have been reinforced by the advent of organisation-
tween (human) actors and major business functions,
wide software packages such as Enterprise Resource
through to low-level object diagrams which capture
Planning (ERP), Customer Relationship Manage-
instances of individual data objects, their constituent
ment (CRM) and Workﬂow Management (WFM) sys-
data elements and values, and their relationships with
tems which bind together multiple operational groups
other data objects.
within an organisation in a set of integrated business
The various modelling notations essentially divide
processes.
into three main groups:
As a consequence of this shift, there is an in-
creased interest in software process modelling in an
• Behaviour diagrams, which describe the overall
organisational context – generally termed business
functionality of the software at a relatively high
process modelling or enterprise modelling, depend-
level of abstraction;
ing on whether the focus of the modelling is on the
business process or the overall organisation.
Sev-
• Interaction diagrams, which further augment the
eral modelling techniques have been proposed as an
behaviour diagrams and present a more detailed
all-encompassing standard for this role, however no
∗
one formalism is predominant in this area (Mendling,
This work is funded in part by ARC Discovery Project
DP0451092.
Neumann & N¨
uttgens 2005). One of the major rea-
Copyright c 2006, Australian Computer Society, Inc. This pa-
sons cited for this (zur Muehlen & Rosemann 2004)
per appeared at Third Asia-Paciﬁc Conference on Conceptual
is the wide disparity in the needs and viewpoints of
Modelling (APCCM2006), Hobart, Australia. Conferences in
various modellers and designers.
Research and Practice in Information Technology, Vol.
53.
In this paper, we investigate the suitability of Ac-
Markus Stumptner, Sven Hartmann and Yasushi Kiyoki, Ed.
tivity Diagrams for business process modelling. This
Reproduction for academic, not-for proﬁt purposes permitted
notation is the most detailed form of process mod-
provided this text is included.
elling within UML. However, its applicability to the

business process modelling domain in a general sense
goals in addition to more concrete details such as or-
is not immediately evident and merits more detailed
ganisational structure and signiﬁcant business activ-
examination in order to determine what advantages
ities (cf. (Vernadat 1996, Bubenko, Persson & Stirna
it oﬀers and what its shortcomings are.
2001, Eriksson & Penker 2000, Marshall 1999)).
We base this evaluation on the Workﬂow Pat-
Whilst there is signiﬁcant overlap between them,
terns1, a taxonomy of generic, recurring constructs
they are generally viewed as having distinct motiva-
originally devised to evaluate workﬂow systems, and
tions (Jablonski & Bussler 1996), and this is best ex-
more recently used to successfully evaluate workﬂow
empliﬁed by the formalisms used for modelling in the
standards, business process languages and process-
two areas. Process models are usually based on a sin-
aware information systems in general (Dumas & ter
gle technique, such as data ﬂow diagrams (DFDs),
Hofstede 2001, White 2004, Wohed, Perjons, Dumas
event-driven process chains (EPCs), UML Activity
& ter Hofstede 2003). In accordance with Jablon-
Diagrams or Petri-Nets, which is used to capture the
ski and Bussler’s original classiﬁcation (Jablonski &
details of the process in question. In contrast, en-
Bussler 1996), these patterns span the control-ﬂow,
terprise modelling generally requires a range of mod-
data and resource perspectives of PAIS. Our choice
elling techniques to be used in conjunction with each
of this evaluation framework is based on the fact that
other in order to capture the required domain infor-
it is 1) widely used, 2) well accepted, 3) comprehensi-
mation. This tends to favour the use of integrated
ble to the IT practitioner, 4) at a suﬃciently detailed
suites of modelling techniques such as ARIS (Scheer
level of abstraction to provide a comprehensive ba-
2000), UML (Eriksson & Penker 2000, Marshall 1999)
sis for assessing their capabilities of business process
and EKD (Bubenko et al. 2001) which possess a
modelling languages and 5) the most complete and
suﬃciently broad range of integrated modelling for-
powerful framework for this form of assessment cur-
malisms.
rently in existence.
Business process modelling essentially seeks to
The main contributions of this paper are as fol-
provide a detailed description of a business process
lows:
in an organisational context. There are a range of
potential modelling languages that can be used for
• It is the ﬁrst multi-perspective evaluation of the
this purpose and Kueng et. al. (Kueng, Kawalek &
expressive capabilities of UML 2.0 ADs;
Bichler 1996) have proposed a taxonomy of business
• It provides an assessment of the overall suitabil-
process modelling techniques which classiﬁes them
ity of UML 2.0 ADs for business process mod-
into four groups:
elling;
• Activity-oriented approaches - focusing on the de-
• It identiﬁes several areas of potential improve-
ﬁnition of business processes as a sequence of ac-
ments to UML 2.0 ADs to further strengthen
tivities;
their use for this purpose.
• Object-oriented approaches - leveraging the more
This paper focuses on the the new version of
comprehensive modelling constructs of object-
UML Activity Diagrams (ADs) 2.0 (OMG 2004),
orientation to capture business processes;
which diﬀer considerably from their precursor UML
• Role-oriented approaches - modelling business
1.4 ADs.2
Previous evaluations (cf. (Dumas & ter
processes based on the speciﬁc organisational
Hofstede 2001, Opdahl & Henderson-Sellers 2002))
roles and responsibilities involved;
have analysed the expressive power of UML 1.4
ADs. There has also been a review of the capabil-
• Speech-act approaches - viewing business proc-
ities of the control-ﬂow perspective of UML 2.0 ADs
esses in the context of the speech-act language
(White 2004), however the limited focus of this in-
action paradigm.
vestigation has restricted its usefulness as a means of
assessing their overall suitability for general modelling
Other considerations for the selection of an appro-
purposes.
priate business process modelling language to use in a
The remainder of this paper proceeds as follows:
particular scenario include the kind of process being
Sections 2 and 3 provide an overview of business
modelled and the purpose for which the modelling is
process modelling languages and UML 2.0 ADs re-
being undertaken. Rolland (1998) classiﬁes processes
spectively. Sections 4, 5 and 6 present evaluations
into three kinds: strategic – which investigate alter-
of the control-ﬂow, data and resource perspectives of
native ways of achieving a required outcome and pro-
UML 2.0 ADs. Section 7 reviews the suitability of
duce a plan for doing so; tactical – which focus on the
UML 2.0 ADs for business process modelling in light
tactics for achieving the plan; and implementation –
of the ﬁndings in the preceding sections. It also oﬀers
which describe how the plan will be achieved. Sim-
some recommendations for further improving their ca-
ilarly, individual process models may be developed
pabilities in this area.
with one of three possible aims: descriptive – which
describe what actually happens during a process; pre-
scriptive – which deﬁne how a process might or should
2
Business Process Modelling Languages
be performed; and explanatory – which detail the ra-
tionale for a process and link it to the requirements
Business process modelling is essentially a conver-
it must fulﬁll.
gence of two related modelling domains: process mod-
elling (cf. (Curtis, Kellner & Over 1992, Rolland 1997,
Rolland 1998)) which seeks to provide “an abstract
3
UML 2.0 Activity Diagrams
representation of a process architecture, design, or de-
ﬁnition” ((Humphrey & Feiler 1992), p.33) and enter-
In UML Activity Diagrams the fundamental unit
prise modelling or business modelling which focuses
of behaviour speciﬁcation is the Action.
“An ac-
on documenting an organisation from a holistic stand-
tion takes a set of inputs and converts them to a
point, capturing details of its overall purpose and
set of outputs, though either or both sets may be
empty” ((OMG 2004), p.229). Actions may also mod-
1 See www.workflowpatterns.com for comprehensive details.
ify the state of the system. The language provides a
2 The semantics of UML 2.0 ADs are based on token ﬂow instead
very detailed action taxonomy, identifying more than
of statecharts as in UML 1.4.
40 diﬀerent action types in detail. A comprehensive
2

discussion of them is beyond the scope of this paper
and in Figure 1a we only present the action types that
B
B
A
we have found to be most relevant to our evaluations.
A
C
C
These are the generic Action concept, Accept Event,
Send Signal, and Call Behavior Action constructs.
WCP1: Sequence
WCP2: Parallel split
WCP3: Synchronisation
[Guard1]
B
B
Action/Activity
AcceptEvent
InitialNode
ActivityFinal
FlowFinal
A
A
[Guard2]
C
C
CallBehaviorAction
SendSignal
Decision
Merge
Fork
Join
WCP4: Exclusive choice
WCP5: Simple merge
[cond1]
...
...
...
...
[cond n]
Figure 2: Basic control patterns in UML 2.0 ADs
a) Actions
b) Control Nodes
Figure 1: The main constructs in UML 2.0 ADs
4.2
Advanced branching & synchronisation
patterns
In order to represent the overall behaviour of a sys-
tem, the concept of the Activity is used. Activities are
This class of patterns corresponds to advanced bran-
composed of actions and/or other activities and they
ching and synchronisation scenarios that often do not
deﬁne dependencies between their elements. Graph-
have direct realisations in PAIS but are relatively
ically, they are composed of nodes and edges. The
common in real-life business processes. There are four
edges connect the nodes in sequential order. Nodes
of these patterns:
represent either Actions, Activities, Data Objects, or
control nodes. The various types of control nodes are
• WCP6: Multiple choice – the ability to represent
shown in Figure 1b.
a divergence of the thread of control into several
parallel branches on a selective basis;
4
The Control-Flow Perspective in UML 2.0
• WCP7: Synchronising merge – the ability to de-
ADs
pict the synchronised convergence of two or more
alternative branches;
In this section we examine the control-ﬂow perspec-
• WCP8: Multiple merge – the ability to represent
tive of UML 2.0 ADs and their ability to represent
the unsynchronised convergence of two or more
a series of twenty common control-ﬂow modelling re-
distinct branches. If more than one branch is
quirements that occur when deﬁning process mod-
active, the activity following the merge is started
els. These requirements are described in terms of the
for every activation of every incoming branch;
Workﬂow Control Patterns (van der Aalst, ter Hof-
stede, Kiepuszewski & Barros 2003). The material
• WCP9: Discriminator – the ability to depict
in this section summarises the ﬁndings in (Wohed,
the convergence of two or more branches such
van der Aalst, Dumas, ter Hofstede & Russell 2005)
that the ﬁrst activation of an incoming branch
thus providing the basis for a comprehensive evalua-
results in the subsequent activity being triggered
tion of UML 2.0 ADs from multiple perspectives.
and subsequent activations of remaining incom-
ing branches are ignored.
4.1
Basic control patterns
The multiple choice, multiple merge and discrim-
The basic control-ﬂow patterns deﬁne elementary
inator patterns can be captured directly in UML 2.0
aspects of process control.
These are analogous
ADs and they are illustrated in Figure 3. The syn-
to the deﬁnitions of elementary control-ﬂow con-
chronising merge pattern cannot be directly modelled.
cepts laid down by the Workﬂow Management Coali-
tion (WFMC 1999). There are ﬁve of these patterns:
A
[Guard1]
B
B
A
• WCP1: Sequence – the ability to depict a se-
[Guard2]
A
B
D
C
C
quence of activities;
C
• WCP2: Parallel split – the ability to capture a
WCP6: Multiple choice
WCP8: Multiple merge
WCP9: Discriminator
split in a single thread of control into multiple
threads of control which can execute in parallel;
Figure 3: Advanced branching & synchronisation pat-
terns in UML 2.0 ADs
• WCP3: Synchronisation – the ability to cap-
ture a convergence of multiple parallel subproc-
esses/activities into a single thread of control
4.3
Structural patterns
thus synchronising multiple threads;
Structural patterns identify whether the modelling
• WCP4: Exclusive choice – the ability to repre-
formalism has any restrictions in regard to the way
sent a decision point in a workﬂow process where
in which processes can be structured (particularly in
one of several branches is chosen;
terms of the type of loops supported and whether a
• WCP5: Simple merge – the ability to depict a
single terminating node is necessary). There are two
point in the workﬂow process where two or more
of these patterns:
alternative branches come together without syn-
• WCP10: Arbitrary cycles – the ability to repre-
chronisation.
sent loops in a process that have multiple entry
or exit points;
All ﬁve of these patterns can be captured by UML
2.0 ADs. The speciﬁc representation of each of these
• WCP11: Implicit termination – the ability to
patterns is illustrated in Figure 2.
depict the notion that a given subprocess should
be terminated when there are no remaining ac-
tivities to be completed (i.e. no explicit unique
termination node is needed).
3

Both of these patterns are directly supported in
• WCP18: Milestone – the ability to depict that
UML 2.0 ADs.
a speciﬁed activity cannot be commenced until
some nominated state is reached which has not
4.4
Multiple instance patterns
expired yet.
This class of patterns relates to situations where there
Owing to the absence of the notion of state, only
can be more than one instance of an activity active at
the deferred choice pattern can be captured in UML
the same time for the same process instance. There
2.0 ADs. This is illustrated in Figure 5.
are four of these patterns:
• WCP12: MI without synchronisation – the abil-
Signal 1
B
ity to initiate multiple instances of an activity
A
within a given process instance;
Signal 2
C
• WCP13: MI with a priori design time knowl-
WCP16: Deferred choice
edge – the ability to initiate multiple instances
of an activity within a given process instance.
Figure 5: Deferred choice pattern in UML 2.0 ADs
The number of instances is known at design time.
Once all instances have completed, a subsequent
activity is initiated;
4.6
Cancellation patterns
• WCP14: MI with a priori runtime knowledge –
Cancellation patterns characterise the ability of the
the ability to initiate multiple instances of an ac-
modelling formalism to represent the potential termi-
tivity within a given process instance. The num-
nation of activities and process instances in certain
ber of instances varies but is known at runtime
(speciﬁed) circumstances. There are two such pat-
before the instances must be created. Once all
terns:
instances have completed, a subsequent activity
is initiated;
• WCP19: Cancel activity – the ability to depict
that an enabled activity should be disabled in
• WCP15: MI without a priori runtime knowledge
some nominated circumstance;
– the ability to initiate multiple instances of an
activity within a given process instance.
The
• WCP20: Cancel case – the ability to represent
number of instances varies but is not known at
the cancellation of an entire process instance (i.e.
design time or at runtime before the instances
all activities relating to the process instance) in
must be created. Once all instances have com-
some nominated circumstance.
pleted, a subsequent activity is initiated. New in-
stances can be created even while other instances
Both of these patterns can be captured in UML 2.0
are executing or have already completed.
ADs. The ﬁrst is illustrated in Figure 6, the second
is captured via the ActivityFinalNode construct.
The ﬁrst three of these patterns can be captured
in UML 2,0 ADs as illustrated in Figure 4. The MI
without a priori runtime knowledge pattern is not di-
A
rectly supported in UML 2.0 ADs.
Cancel
A
Install
Book
WCP19: Cancel Activity
Flight
Build
Component
1
Component
Specify
Book
Print
Trip
[no more
Flight
Itinerary
Route
2
Figure 6: Cancel activity pattern in UML 2.0 ADs
components
[more components
to be built]
Book
to be built]
Flight 3
WCP12: MI without Synchronisation
WCP13: MI with a Priori Designtime Knowledge
5
The Data Perspective in UML 2.0 ADs
Book
Specify
Flight
Trip
Print
Extensions (Russell, ter Hofstede, Edmond & van der
Route
Itinerary
Book
Aalst 2005) to the Workﬂow Patterns Initiative have
Hotel
focused on identifying and deﬁning generic constructs
WCP14: MI with a Priori Runtime Knowledge
that occur in the the data perspective of PAIS. In
total forty data patterns have been delineated in four
Figure 4: Multiple instance patterns in UML 2.0 ADs
distinct groups – data visibility, data interaction, data
transfer and data-based routing. In this section, an
analysis of UML 2.0 ADs is presented using the data
patterns described in (Russell, ter Hofstede, Edmond
4.5
State-based patterns
& van der Aalst 2005).
This class of patterns characterise scenarios in a
process where subsequent execution is determined by
5.1
Data visibility patterns
the state of the process instance. There are three such
patterns:
Data visibility patterns seek to characterise the vari-
ous ways in which data elements can be deﬁned and
• WCP16: Deferred choice – the ability to depict
utilised within the context of a process. In general,
a divergence point in a process where one of sev-
this is determined by the main construct to which the
eral possible branches should be activated. The
data element is bound as it implies a particular scope
actual decision on which branch is activated is
in which the data element is visible and capable of
made by the environment and is deferred to the
being utilised. There are eight patterns which relate
latest possible moment;
to data visibility:
• WCP17: Interleaved parallel routing – the ability
• WDP1: Task data – data elements deﬁned and
to depict a set of activities that can be executed
accessible in the context of individual execution
in arbitrary order;
instances of a task or activity;
4

Nr
Pattern
2.0
Nr
Pattern
2.0
Basic Control
Multiple Instance
1
Sequence
+
12
MI without Synchronization
+
2
Parallel Split
+
13
MI with a priori Design Time Knowledge
+
3
Synchronisation
+
14
MI with a priori Runtime Knowledge
+
4
Exclusive Choice
+
15
MI without a priori Runtime Knowledge
–
5
Simple Merge
+
State-based
Adv. Branching & Synchronisation
16
Deferred Choice
+
6
Multiple Choice
+
17
Interleaved Parallel Routing
–
7
Synchronising Merge
–
18
Milestone
–
8
Multiple Merge
+
Cancellation
9
Discriminator
+
19
Cancel Activity
+
Structural
20
Cancel Case
+
10
Arbitrary Cycles
+
11
Implicit Termination
+
Table 1: Support for Control-Flow Patterns in UML 2.0 ADs
• WDP2: Block data – data elements deﬁned by
1. Where a task is speciﬁcally designated as having
block tasks (i.e. tasks which can be described
multiple instances in the process model – this fa-
in terms of a corresponding decomposition) and
cility seems to be provided by the ExpansionKind
accessible to the block task and all correspond-
construct (see (OMG 2004), p.394) where the
ing components within the associated decompo-
parallel option is chosen forcing parallel execu-
sition;
tion.
• WDP3: Scope data – data elements bound to a
2. Where a task can be triggered multiple times e.g.
subset of the tasks in a process instance;
it is part of a loop. This situation is allowable in
UML 2.0 ADs (see (OMG 2004), p.345).
• WDP4: Multiple instance data – data elements
speciﬁc to a single execution instance of a task
3. Where two tasks share the same decomposition.
(where the task is able to be executed multiple
This is also supported in UML 2.0 ADs as each
times);
activity decomposition is distinct and has a dif-
ferent set of tokens supplied to it at initiation
• WDP5: Case data – data elements speciﬁc to a
(see (OMG 2004), p.360-1).
process instance which are accessible to all com-
ponents of the process instance during execution;
Case and folder data are not supported as there does
not appear to be the notion of distinct execution in-
• WDP6: Folder data – data elements bound to
stances in UML 2.0 ADs, rather all instances of a
a subset of the tasks in a process deﬁnition but
process model execute in the same context and are
accessible to all task instances regardless of the
diﬀerentiated by distinct sets of control and object
case to which they correspond;
tokens ﬂowing through the diagram. Workﬂow data
• WDP7: Workﬂow data – data elements accessi-
is directly supported through data objects or Object-
ble to all components in all cases;
Nodes (see (OMG 2004), p.422) which are potentially
accessible to all of the components in a UML 2.0 ADs.
• WDP8: Environment data – data elements de-
There does not appear to be the ability within UML
ﬁned in the operational environment which can
2.0 ADs to refer to data outside of the context of
be accessed by process elements.
the diagram, and hence environment data is not sup-
ported.
In the case of UML 2.0 ADs, there is support for
several of these patterns. The smallest operational
5.2
Data interaction patterns
unit in the context of these diagrams is the action.
This corresponds to the notion of a process element
Data interaction patterns deal with the various ways
or task and although the notion of task data is not
in which data elements can be passed between com-
directly supported, there is indirect support in the sit-
ponents within a process instance and also with the
uation where a local action language is utilised which
operating environment (e.g. data transfer between a
provides action-speciﬁc variables (see (OMG 2004),
component of a process and an application, data store
p.338-9).
or interface that is external to the process). They ex-
Activities serve as the main grouping mechanism
amine how the characteristics of the individual com-
in UML 2.0 ADs and they have similar characteris-
ponents can inﬂuence the manner in which the traf-
tics to the block construct in process deﬁnitions. The
ﬁcking of data elements occurs.
block data pattern is directly supported through pa-
There are six internal data interaction patterns:
rameters to activities (see (OMG 2004), p.363) which
are accessible to all activity components. The concept
• WDP9: Data elements ﬂowing between task in-
of attributes (see (OMG 2004), p.341-7) is also pro-
stances;
vided which allows data elements to be deﬁned which
are scoped to a speciﬁc activity.
• WDP10: Data elements ﬂowing to a block ;
Scope data is not supported. The ActivityGroup
• WDP11: Data elements ﬂowing from a block ;
construct (see (OMG 2004), p.359) seems to oﬀer
something analogous however the semantics of the
• WDP12: Data elements ﬂowing to a multiple in-
construct are not deﬁned.
stance task instance;
Multiple instance data is directly supported and
there are three situations where multiple instances of
• WDP13: Data elements ﬂowing from a multiple
a given task may arise:
instance task instance;
5

• WDP14: Data elements ﬂowing between process
• WDP31: Data transfer by reference – with lock
instances or cases.
– similar to WDP30 except that concurrency re-
strictions are implied with the receiving compo-
Data interaction between tasks is directly supported
nent receiving the privilege of read-only or dedi-
in UML 2.0 ADs by the ObjectNode construct (see
cated access to the data element;
(OMG 2004), p.422) which is the standard means of
communicating data elements between activities.
• WDP32: Data transformation – input – where
Data interaction between block tasks and their de-
a transformation function is applied to a data
compositions has a similar analogy in UML 2.0 ADs
element prior to it being passed to a subsequent
in the form of data passing to and from activities.
component;
The standard means of doing this is via parameters
(see (OMG 2004), p.363).
Both the data interac-
• WDP33: Data transformation – output – where
tion block task to sub-workﬂow and data interac-
a transformation function is applied to a data
tion sub-workﬂow to block task patterns (WDP10 and
element prior to it being passed from a previous
WDP11) are directly supported.
component.
Data interaction to and from multiple instance
In the context of UML 2.0 ADs, only three of these
tasks has a direct analogy in UML 2.0 ADs in the
patterns are supported: WDP31: data transfer by
ExpansionRegion construct (see (OMG 2004), p.395)
reference – with lock - is the standard means of pass-
which allows nominated regions of a process model to
ing data elements into an activity as parameters. As
be executed multiple times in parallel (providing the
UML 2.0 ADs adopt a token-oriented approach to
ExpansionKind mode is set to parallel). Data pass-
data passing, these parameters – which typically re-
ing into and out of the ExpansionRegion occurs using
late to objects – are eﬀectively consumed at activity
ExpansionNodes which provide the ability to map dis-
commencement and only become visible and acces-
tinct sections of the input data set to speciﬁc execu-
sible to other activities once the speciﬁc activity to
tion instances and similarly completing instances can
which they were passed has completed and returned
map their output to a speciﬁc section of the output
them; WDP32: data transformation - input – can be
data set. Hence the data interaction to and from mul-
achieved through the ObjectFlow transformation be-
tiple instance task patterns (WDP12 and WDP13)
haviour (see (OMG 2004), p.418) which allows trans-
are directly supported.
formation functions to be applied to data tokens as
There is no notion of distinct execution cases in
they are passed along connecting edges between ac-
UML 2.0 ADs, hence the data interaction – case to
tivities; and WDP33: data transformation - output –
case pattern (WDP14) is not supported.
as for pattern WDP32.
There are 12 external data interaction patterns,
characterised by three dimensions:
5.4
Data-based routing patterns
• The type of process element – task, case or com-
plete process – that is interacting with the envi-
Data-based routing patterns capture the various ways
ronment;
in which data elements can interact with other per-
spectives and inﬂuence the overall execution of the
• Whether the interaction is push or pull-based;
process. There are seven (relatively self-explanatory)
patterns in this category:
• Whether the interaction is initiated by the proc-
ess component or the environment.
• WDP34: Task precondition – data existence;
Diﬃculties arise when examining UML 2.0 ADs in
• WDP35: Task precondition – data value;
the context of this class of patterns as the UML ap-
proach assumes that an Activity Diagram represents
• WDP36: Task postcondition – data existence;
the complete universe of discourse and does not pro-
• WDP37: Task postcondition – data value;
vide the ability to reference or interact with elements
that are external to it.
• WDP38: Event-based task trigger ;
• WDP39: Data-based task trigger ;
5.3
Data transfer patterns
Data transfer patterns focus on the way in which data
• WDP40: Data-based routing.
elements are actually transferred between one process
The majority of these patterns are supported in UML
element and another. They aim to capture the various
2.0 ADs.
Both action and activity constructs in-
mechanisms by which data elements can be passed
clude local preconditions and postconditions based
across the interface of a process element. There are
on logical expressions (which may include data ele-
seven distinct patterns in this category:
ments) framed in OCL (see (OMG 2004), p.336 and
• WDP27: Data transfer by value – incoming –
p.346).
As a consequence, all of the task pre and
incoming data elements passed by value;
postcondition patterns (WDP34 - WDP37) are di-
rectly supported. The AcceptEventAction construct
• WDP28: Data transfer by value – outgoing – out-
(see (OMG 2004), p.334) provides direct support for
going data elements passed by value;
the event-based task triggering pattern.
Similarly,
there is direct support for data-based routing via
• WDP29: Data transfer – copy in/copy out –
the DecisionNode construct and guard conditions on
where a process element synchronises data ele-
ActivityEdges (see (OMG 2004), p.387 and p.351).
ments with an external data source at commence-
The lack of support for persistent state management
ment and completion;
within UML 2.0 ADs means that the data-based task
trigger pattern cannot be captured.
• WDP30: Data transfer by reference – without
lock – data elements are communicated between
components via a reference to a data element in
some mutually accessible location. No concur-
rency restrictions are implied;
6

Nr
Pattern
Nr
Pattern
Data Visibility
Data Interaction (Ext.) (cont.)
1
Task Data
+/–
21
Env. to Case – Push-Oriented
–
2
Block Data
+
22
Case to Env. – Pull-Oriented
–
3
Scope Data
–
23
Workﬂow to Env. – Push-Orient.
–
4
Multiple Instance Data
+
24
Env. to Workﬂow – Pull-Orient.
–
5
Case Data
–
25
Env. to Workﬂow – Push-Orient.
–
6
Folder Data
–
26
Workﬂow to Env. – Pull-Orient.
–
7
Workﬂow Data
+
Data Transfer
8
Environment Data
–
27
by Value – Incoming
–
Data Interaction (Internal)
28
by Value – Outgoing
–
9
between Tasks
+
29
Copy In/Copy Out
–
10
Block Task to Sub-workﬂow Decomp.
+
30
by Reference – Unlocked
–
11
Sub-workﬂow Decomp. to Block Task
+
31
by Reference – Locked
+
12
to Multiple Instance Task
+
32
Data Transformation – Input
+
13
from Multiple Instance Task
+
33
Data Transformation – Output
+
14
Case to Case
–
Data-based Routing
Data Interaction (External)
34
Task Precondition – Data Exist.
+
15
Task to Env. – Push-Oriented
–
35
Task Precondition – Data Val.
+
16
Env. to Task – Pull-Oriented
–
36
Task Postcondition – Data Exist.
+
17
Env. to Task – Push-Oriented
–
37
Task Postcondition – Data Val.
+
18
Task to Env. – Pull-Oriented
–
38
Event-based Task Trigger
+
19
Case to Env. – Push-Oriented
–
39
Data-based Task Trigger
–
20
Env. to Case – Pull-Oriented
–
40
Data-based Routing
+
Table 2: Support for Data Routing Patterns in UML 2.0 ADs
6
The Resource Perspective in UML 2.0 ADs
In UML 2.0 ADs, the association of a particular
action or set of actions with a speciﬁc resource is illus-
Recent work (Russell, van der Aalst, ter Hofstede
trated through the use of the ActivityPartition con-
& Edmond. 2005) has focused on the resource per-
struct (see (OMG 2004), p.367). This may take many
spective and the manner in which work is distrib-
forms although the “swimlanes” notation is proba-
uted amongst and managed by the resources asso-
bly the most widely adopted means of presentation,
ciated with a business process.
Our investigations
where each lane indicates the resource that will be re-
have indicated that these patterns are relevant to
sponsible for executing a speciﬁc subset (i.e. a parti-
all forms of PAIS including modelling languages such
tion) of the actions within an activity. Each partition
as XPDL and business process enactment languages
has a name that corresponds to a speciﬁc resource or
such as BPEL4WS. In this section, we examine the
a group of resources to which the contained actions
resource perspective of UML 2.0 ADs and their ex-
should be allocated at run-time. Partitions may be
pressive power in regard to work distribution.
speciﬁed in four distinct ways: Classiﬁer, Instance,
Forty three workﬂow resource patterns have been
Part, and Attribute and Value. The ﬁrst two of these
identiﬁed in seven distinct groups:
schemes (i.e. Classiﬁer and Instance) are relevant in
• Creation patterns – which correspond to restric-
the context of resource allocation.
tions on the manner in which speciﬁc work items
The direct allocation pattern (WRP1) is directly
can be advertised, allocated and executed by re-
supported in UML 2.0 ADs as the ability to base a
sources;
partition on a speciﬁc instance allows the actions to
be associated with a single speciﬁed resource. There
• Push patterns – which describe situations where
is no direct notion of roles within UML 2.0 ADs, al-
a PAIS proactively oﬀers or allocates work to re-
though where a partition is based on a classiﬁer, it
sources;
is possible that the contained actions are allocated to
• Pull patterns – which characterise scenarios in
multiple objects corresponding to the classiﬁer (i.e.
which resources initiate the identiﬁcation of work
multiple resources). This is analogous to the notion
that they are able to undertake and commit to
of group allocation within a traditional workﬂow sys-
its execution;
tem. It is up to the individual resources to determine
whether one or all of them will execute the assigned
• Detour patterns – which describe deviations from
actions (see (OMG 2004), p.368-70). Consequently
the normal sequence of state transitions associ-
the requirements of the role-based allocation pattern
ated with a business process either at the insti-
(WRP2) are fully met and the pattern is directly sup-
gation of a resource or the PAIS;
ported. It is not necessary that actions within an ac-
•
tivity belong to a partition and have a corresponding
Auto-start patterns – which relate to situations
resource association, therefore the automatic execu-
where the execution of work is triggered by spe-
tion pattern (WRP11) is also directly supported.
ciﬁc events or state transitions in the business
None of the other Creation Patterns are supported
process;
within UML 2.0 ADs. In the main, this is a conse-
• Visibility patterns – which describe the ability of
quence of the restrictive manner in which partitions
resources to view the status of work within the
are speciﬁed and the lack of support for relationships
PAIS;
between distinct partitions. The attribute and value
partition speciﬁer seems to oﬀer a means of imple-
• Multiple resource patterns – which describe sce-
menting the deferred allocation pattern (WRP3) by
narios where there is a many-to-many relation-
delaying the need to identify a potential resource until
ship between speciﬁc work items and the re-
run-time, however it is not possible to specify alter-
sources undertaking those work items.
7

nate (i.e. parallel) courses of action based on diﬀerent
that may arise in actual business processes. In terms
values of an attribute and even if it were, the neces-
of addressing the patterns that are not directly sup-
sity to enumerate a distinct course of action for each
ported, we would like to make the following recom-
value (i.e. each potential resource) would make this
mendations:
approach unwieldy. Lack of an integrated authorisa-
tion framework, organisational model or access to an
• Given the diﬃculties in capturing state-based
execution history also rules out any form of support
patterns, most notably the interleaved parallel
for the authorisation (WRP4), organisational alloca-
routing pattern and the milestone pattern, it may
tion (WRP9) and history-based allocation (WRP8)
be worthwhile providing direct support for the
patterns respectively.
notion of the place as it exists in Petri nets.
The execution semantics of a UML 2.0 AD are
Petri net places capture the notion of “waiting
based on Petri Net token ﬂow, hence actions become
state” in a much less restrictive way than the
“live” once they receive a control-ﬂow token.
The
AcceptEventAction construct does;
resource associated with a given partition can have
multiple actions executing (possibly in diﬀerent parti-
• UML 2.0 ADs currently do not support the cre-
tions) at the same time. There is no notion of schedul-
ation of new instances of an activity while other
ing work execution or of resources selecting the work
instances of that activity are already running.
(i.e. the actions) they wish to undertake, hence there
This could be resolved through extensions to the
is minimal support for the Push, Auto-start or Mul-
ExpansionRegion construct to allow further in-
tiple Resource patterns within UML 2.0 ADs. The
stances to be dynamically created after the ac-
following patterns from these classes are directly sup-
tivity has started;
ported:
• Given the lack of support for the synchronising
• WRP14: Distribution by allocation - single re-
merge, a concept similar to the OR-join could be
source – the resource(s) associated with a given
added to UML 2.0 ADs.
partition is immediately allocated an action once
it is triggered;
The data patterns evaluation is summarised in Ta-
ble 2. This shows that the data perspective is also
• WRP19: Distribution on enablement – all ac-
well supported. Furthermore, the following remarks
tions in a partition are associated with the re-
can be made:
source responsible for the partition when they
are triggered;
• There is no notion of cases or distinct process
instances in UML 2.0 ADs, hence all data is
• WRP36: Commencement on creation – an ac-
eﬀectively block-scoped by default and paral-
tion is assumed to be live as soon as it receives a
lel threads of execution occur in the same data
control-ﬂow token;
space. This could lead to some problematic sit-
• WRP39: Chained execution – once an action is
uations when modelling highly data intensive
completed, subsequent actions receive a control-
and/or highly concurrent processes;
ﬂow token and are triggered immediately;
• The use of “tokens” as the fundamental under-
• WRP42: Simultaneous execution – there are no
pinning for control and data ﬂow introduces some
constraints on how many partitions a given re-
subtle variations that do not exist in other PAIS
source can be speciﬁed for or how many instances
(except those based on Petri-nets) – in particular
of these can be active at any one time.
data elements are truly consumed (and cease to
exist) when they are passed to an activity for the
None of the Pull, Detour or Visibility patterns are
duration of the activity. This also makes it diﬃ-
supported.
cult to actually share a data element/object be-
tween concurrent activities. On the other hand,
7
Conclusions
it minimises concurrency problems;
The pattern evaluations described in this paper indi-
• The token approach provides an eﬀective basis
cate that whilst UML 2.0 ADs have merit as a nota-
for internal data interaction (and hence all pat-
tion for business process modelling, they are not suit-
terns are “+”). In particular, multiple instance
able for all aspects of this type of modelling. They
data handling seems to be supported for all three
oﬀer comprehensive support for the control-ﬂow and
multiple instance situations: designated multiple
data perspectives allowing the majority of the con-
instance tasks, multiply triggered tasks (loops)
structs encountered when analysing these perspec-
and block tasks with a common decomposition;
tives to be directly captured. However, their suitabil-
• There does not seem to be any ability to model
ity for modelling resource-related or organisational as-
things “outside of the model” i.e. in the external
pects of business processes is extremely limited. It
environment. Hence there is no real ability to
is interesting to note that they are not able to cap-
support external data interaction patterns. This
ture many of the natural constructs encountered in
may be addressed by using UML ADs in con-
business processes such as cases and the notion of in-
junction with other diagrams such as UML in-
teraction with the operational environment in which
teraction, overview and sequence diagrams, but
the process functions. These are limitations that they
this requires that the relationships between these
share with most other business process modelling for-
diagrams be carefully established.
malisms and reﬂect the overwhelming emphasis that
has been placed on the control-ﬂow and data perspec-
The resource patterns evaluation is summarised in Ta-
tives in contemporary modelling notations.
ble 3. As discussed, it indicates that the support in
The level of support observed for control-ﬂow pat-
UML 2.0 ADs for the modelling of work distribution
terns (see Table 1 for a complete summary3) illus-
directives is relatively minimal. This reinforces the
trates that there is relatively broad support for cap-
fact that UML 2.0 ADs tend to be control-ﬂow and
turing the various types of control-ﬂow constructs
data-centric and mainly aim to capture simple static
routing directives associated with actions. They do
3 A “+” in the table indicates direct support for the pattern
not provide a means of representing the subtleties as-
(i.e. there is a construct in the language that directly supports the
pattern).
sociated with selective work allocation across a range
8

Nr
Pattern
Nr
Pattern
Creation Patterns
Pull Patterns (cont.)
1
Direct Allocation
+
24
System-Determ. Wk Queue Cont.
–
2
Role-Based Allocation
+
25
Resource-Determ. Wk Queue Cont.
–
3
Deferred Allocation
–
26
Selection Autonomy
–
4
Authorisation
–
Detour Patterns
5
Separation of Duties
–
27
Delegation
–
6
Case Handling
–
28
Escalation
–
7
Retain Familiar
–
29
Deallocation
–
8
Capability-Based Allocation
–
30
Stateful Reallocation
–
9
History-Based Allocation
–
31
Stateless Reallocation
–
10
Organisational Allocation
–
32
Suspension/Resumption
–
11
Automatic Execution
+
33
Skip
–
Push Patterns
34
Redo
–
12
Distrib. by Oﬀer - Single Resource
–
35
Pre-Do
–
13
Distrib. by Oﬀer - Multiple Resources
–
Auto-Start Patterns
14
Distrib. by Allocation - Single Resource
+
36
Commencement on Creation
+
15
Random Allocation
–
37
Creation on Allocation
–
16
Round Robin Allocation
–
38
Piled Execution
–
17
Shortest Queue
–
39
Chained Execution
+
18
Early Distribution
–
Visibility Patterns
19
Distribution on Enablement
+
40
Conf. Unalloc. Work Item Visibility
–
20
Late Distribution
–
41
Conf. Alloc. Work Item Visibility
–
Pull Patterns
Multiple Resource Patterns
21
Resource-Init. Allocation
–
42
Simultaneous Execution
+
22
Resource-Init. Exec. - Alloc. Wk Items
–
43
Additional Resource
–
23
Resource-Init. Exec. - Oﬀer. Wk Items
–
Table 3: Support for Resource Patterns in UML 2.0 ADs
of possible resources and the management of those
Dumas, M. & ter Hofstede, A. (2001), UML activity
work items at run-time. In particular, there is no real
diagrams as a workﬂow speciﬁcation language,
support for modelling any form of work distribution
in M. Gogolla & C. Kobryn, eds, ‘Proceedings
other than direct allocation or role-based allocation.
of the Fourth International Conference on the
There is no opportunity to utilise data resources (ei-
Uniﬁed Modeling Language (UML 2001)’, LNCS
ther within the model or externally from the environ-
2185, Springer, Toronto, Canada, pp. 76–90.
ment) thus any opportunity for modelling organisa-
tional, history-based or capability-based allocation is
Eriksson, H. & Penker, M. (2000), Business Modeling
obviated. Similarly, there is no support for specifying
with UML, OMG Press, New York.
any form of work distribution algorithm or employing
Humphrey, W. & Feiler, P. H. (1992), Software
varying styles of work distribution (e.g. push vs pull,
process development and enactment : Concepts
oﬀer vs allocation).
and deﬁnitions, Technical Report SEI-92-TR-4,
Other observations arising from the resource pat-
SEI Institute, Pittsburgh, USA.
terns analysis include:
Jablonski, S. & Bussler, C. (1996), Workﬂow Manage-
• The fact that the partitions can result in actions
ment: Modeling Concepts, Architecture and Im-
being simultaneously allocated to more than one
plementation, Thomson Computer Press, Lon-
resource can lead to diﬃculties where a means
don, UK.
of providing role-based work allocation to a sin-
Kueng,
P.,
Kawalek,
P. & Bichler,
P. (1996),
gle resource is required. It is important to note
How to compose an object-oriented business
that the resolution of this situation must be ad-
process model?, in S. Brinkkemper, K. Lyyti-
dressed as part of the implementation of the ac-
nen & R. Welke, eds, ‘Proceedings of the IFIP
tions within the Activity Diagram;
WG8.1/WG8.2 Working Conference’, Atlanta,
• The ability to use OCL statements in the speciﬁ-
GA, USA.
cation of partitions (and also for specifying rela-
Marshall, C. (1999), Enterprise Modeling with UML,
tionships between partitions) would enhance the
Addison Wesley, Reading.
capability of UML 2.0 ADs to capture possible
resource allocations, both in terms of precision
Mendling, J., Neumann, G. & N¨
uttgens, M. (2005),
and the range of work allocation strategies that
A comparison of XML interchange formats for
could be represented.
business process modelling, in L. Fischer, ed.,
‘Workﬂow Handbook 2005’, Workﬂow Manage-
ment Coalition, Lighthouse Point, Florida, USA,
References
pp. 185–198.
Bubenko, J., Persson, A. & Stirna, J. (2001), EKD
OMG (2004), UML 2.0 superstructure speciﬁca-
user guide, Technical report, Royal Institute of
tion, Technical report.
http://www.omg.org/
Technology (KTH) and Stockholm University,
cgi-bin/doc?ptc/2004-10-02.
Stockholm, Sweden.
Opdahl, A. & Henderson-Sellers, B. (2002), ‘Onto-
Curtis,
B.,
Kellner,
M.
&
Over,
J.
(1992),
logical evaluation of the UML using the Bunge-
‘Process modelling’,
Communications of the
Wand-Weber model’, Software and System Mod-
ACM 35(9), 75–90.
eling 1(1), 43–67.
9

Rolland, C. (1997), A primer for method engineering,
in ‘Proceedings of the INFormatique des ORgan-
isations et Syst`
emes d’Information et de D´
ecision
(INFORSID’97)’, Toulouse, France.
Rolland, C. (1998), A comprehensive view of process
engineering, in B. Pernici & C. Thanos, eds,
‘Proceedings of the 10th International Confer-
ence on Advanced Information Systems Engi-
neering (CAiSE’98)’, Vol. 1413 of Lecture Notes
in Computer Science, Springer, Pisa, Italy.
Russell, N., ter Hofstede, A., Edmond, D. & van der
Aalst, W. (2005), Workﬂow data patterns: Iden-
tiﬁcation, representation and tool support, in
‘Proceedings of the 25th International Con-
ference on Conceptual Modeling (ER’2005)’,
Springer, Klagenfurt, Austria.
Russell, N., van der Aalst, W., ter Hofstede, A. & Ed-
mond., D. (2005), Workﬂow resource patterns:
Identiﬁcation, representation and tool support.,
in O. Pastor & J. Falcao ´
e Cunha, eds, ‘Pro-
ceedings of the 17th Conference on Advanced
Information Systems Engineering (CAiSE’05)’,
Vol. 3520 of Lecture Notes in Computer Science,
Springer, Porto, Portugal, pp. 216–232.
Scheer, A.-W. (2000), ARIS - Business Process Mod-
elling, Springer, Berlin, Germany.
van der Aalst, W., ter Hofstede, A., Kiepuszewski, B.
& Barros, A. (2003), ‘Workﬂow patterns’, Dis-
tributed and Parallel Databases 14(3), 5–51.
Vernadat, F. (1996), Enterprise Modeling and Inte-
gration, Chapman and Hall, London.
WFMC
(1999),
Workﬂow
management
coali-
tion
terminology
and
glossary,
document
status - issue 3.0, Technical Report WFMC-
TC-1011,
Workﬂow
Management
Coalition.
http://www.wfmc.org/standards/docs/
TC-1011 term glossary v3.pdf.
White, S. (2004), Process modeling notations and
workﬂow patterns, in L. Fischer, ed., ‘Workﬂow
Handbook 2004’, Future Strategies Inc., Light-
house Point, FL, USA., pp. 265–294.
Wohed, P., Perjons, E., Dumas, M. & ter Hofstede, A.
(2003), Pattern based analysis of EAI languages
- the case of the business modeling language, in
O. Camp & M. Piattini, eds, ‘Proceedings of the
5th International Conference on Enterprise In-
formation Systems (ICEIS 2003)’, Vol. 3, Escola
Superior de Tecnologia do Instituto Politecnico
de Setubal, Angers, France, pp. 174–184.
Wohed, P., van der Aalst, W., Dumas, M., ter Hof-
stede, A. & Russell, N. (2005), Pattern-based
analysis of UML activity diagrams, in ‘Proceed-
ings of the 25th International Conference on
Conceptual Modeling (ER’2005)’, Springer, Kla-
genfurt, Austria.
zur Muehlen, M. & Rosemann, M. (2004), Multi-
paradigm process management, in J. Grund-
spenkis & M. Kirikova, eds, ‘Proceedings of
the Fifth Workshop on Business Process Mod-
eling,
Development,
and Support (BPMDS
’04), held in conjunction with the Conference
on Advanced Information Systems Engineering
(CAiSE) 2004’, Vol. 2, Faculty of Computer Sci-
ence and Information Technology, Riga Techni-
cal University, Riga, Latvia, pp. 169–175.
10

Document Outline

Introduction
Business Process Modelling Languages
UML 2.0 Activity Diagrams
The Control-Flow Perspective in UML 2.0 ADs
- Basic control patterns
- Advanced branching & synchronisation patterns
- Structural patterns
- Multiple instance patterns
- State-based patterns
- Cancellation patterns
The Data Perspective in UML 2.0 ADs
- Data visibility patterns
- Data interaction patterns
- Data transfer patterns
- Data-based routing patterns
The Resource Perspective in UML 2.0 ADs
Conclusions