Uml Patterns PDF
Uml Patterns PDF
Introduction
UML activity diagrams are intended to model both computational and organisational processes (i.e. workflows) [14, 15]. However, if activity diagrams are to
succeed as a standard in the area of organisational process modeling, they should
compare favorably to the languages currently used for this purpose, that is, those
supported by existing Workflow Management Systems (WFMS).
In this paper, we investigate the expressiveness and adequacy of the activity
diagrams notation for workflow specification, by systematically confronting it
with a set of control-flow workflow patterns, i.e. abstracted forms of recurring
situations related to the ordering of activities in a workflow, and the flow of
execution between them. Many of these patterns are documented in [3, 4], and
a comparison of several WFMS based on these patterns is provided in [4].
Our evaluation demonstrates that activity diagrams support the majority of
the patterns considered, including some which are typically not supported by
commercial WFMS. This is essentially due to the fact that activity diagrams
integrate signal sending and processing at the conceptual level, whereas most
commercial WFMS only support them as a low-level implementation mechanism.
While activity diagrams compare well to existing WFMS in this respect, they
exhibit the major drawback that their syntax and semantics are not fully de-
fined in the standards documentation1 . Indeed, while the features inherited from
Harels statecharts [9] have a formal operational semantics, the features specific
to activity diagrams are only partially formalised in the standard (through OCL
statements), and their description in natural language leaves room for some ambiguities that we point out throughout the paper. We hope that some of these
ambiguities will be clarified in future releases of the standard.
The rest of the paper is structured as follows. Section 2 discusses some semantical issues of the activity diagrams notation, focusing on control-flow aspects.
Sections 3, 4, and 5 evaluate the capabilities of activity diagrams against different families of workflow patterns. The patterns considered in sections 3 and
4 are extracted from [4], while those discussed in section 5 are variants of the
well-known producer-consumer pattern. Finally, section 6 points to related work,
and section 7 discusses directions for improving the activity diagrams notation.
The aims of the following overview are (i) to discuss the semantics and properties of critical constructs used in the rest of the paper, (ii) to identify some
ambiguities in the standard, and (iii) to explain how this paper deals with these
ambiguities. It is not intended as an introductory overview. Readers not familiar
with activity diagrams may refer to e.g. [8].
2.1
UML activity diagrams are special cases of UML state diagrams, which in turn
are graphical representations of state machines. The state machine formalism as
defined in the UML, is a variant of Harels statecharts [9].
State machines are transition systems whose arcs are labeled by ECA (EventCondition-Action) rules. The occurrence of an event fires a transition if (i) the
machine is in the source state of the transition, (ii) the type of the event occurrence matches the event description of the transition, and (iii) the condition
of the transition holds. The event (also called trigger), condition (also called
guard), and action parts of a transition are all optional. A transition without
an event is said to be triggerless. Triggerless transitions are enabled when the
action or activity attached to their source state is completed.
A state can contain an entire state machine within it, leading to the concept of compound state. Compound states come in two flavours: OR and AND.
An OR-state contains a single statechart, while an AND-state contains several statecharts (separated by dashed lines) which are intended to be executed
concurrently. Each of these statecharts is called a concurrent region. When a
compound state is entered, its initial transition(s) are taken. The execution of
a compound state is considered to be complete when it reaches (all) its final
state(s). Initial states are denoted by filled circles, while final states are denoted
by two concentric circles: one filled and one unfilled (see figure 1).
1
When discussing the syntax and semantics of activity diagrams, we take as sole
reference the final draft delivered by the UML Revision Task Force 1.4 [14].
To appear in UML2001.
e2
e1
B
A
*
C
[C2]
D
[C1]
by a heavy bar as in figure 1) is a special transition with one source state and
several target states. When this transition fires, the target states are all simultaneously entered, resulting in an increase in the number of concurrent threads.
A join (represented by a heavy bar as well) is a transition with several source
states and one target state, which reduces the number of concurrent threads.
An activity diagram with forks and joins must fulfill some well-formedness
criteria. These criteria state that it must be possible to replace all forks and joins
with AND-states. In particular, for every fork there should be a corresponding
join, the delicate point being to define what is meant by corresponding.
The well-formedness of activity diagrams is partially defined as OCL and
natural language statements in the standard ([14] pp. 2-161 through 2-169).
This definition however does not take into account the case where choice and
junction vertices are used within the paths leading from a fork to a join, thereby
permitting deadlocking situations which would not occur if forks and joins were
replaced with AND-states. We argue that if activity diagrams are to be used as
a workflow specification language, a precise definition of their well-formedness
is crucial, as it prevents several kinds of deadlocks. In a different context than
activity diagrams, [10] provides a formalisation of these well-formedness rules.
In this paper, we avoid the use of forks and joins, and use AND-states instead.
Forks and joins are only used in conjunction with synch state as discussed below.
2.3
Synch states
Dynamic invocations
After a thorough search through [14], we found that there are no indications
as to how multiple invocations of an action or activity synchronise once their
execution is completed. Assuming that these invocations are not required to
synchronise upon completion, inconsistencies may arise when a dynamic state
is followed by a non-dynamic one. Consider for example the diagram in figure 2,
where an action state A with dynamic multiplicity 2 is followed by an action state
B with no dynamic multiplicity. Suppose that two invocations of A are made,
and that the first invocation finishes before the second. If the two invocations
are not required to synchronise, state B can be entered at this point. Now, what
will happen when the second invocation of A finishes? Will it trigger activity
B again (in which case two instances of B will run simultaneously)? Because of
this semantical conflict, we consider in this paper that a dynamic state can only
be exited when all its associated invocations are completed. In particular, if one
invocation is aborted due to some external event, all the other invocations are
aborted too. This is in line with the interpretation suggested in [8].
A 2
Another point regarding dynamic invocation which is left open by the standard, is whether each invocation runs in its own memory space, or if it shares
the same memory space as the others. If two subactivities run in the same space,
chances are that this could lead to write-write conflicts over shared variables.
This and the following two sections, present a series of workflow patterns and
their description using UML activity diagrams. For each pattern we provide:
A
A
A
A
The discriminator2
Description. The discriminator is a point in a workflow that waits for one of its
incoming branches to complete before activating the subsequent activity. From
2
The term discriminator here, refers to a special kind of synchronisation. It should not
be mistaken with the use of the term discriminator in UML class diagrams, where
it refers to a dimension of specialisation within a class hierarchy.
To appear in UML2001.
that moment on, it waits for the other branches to complete and ignores them.
When the last incoming branch completes, the discriminator resets itself so that
it can be triggered again (in case it is embedded in a loop).
Example. To improve query response time, a complex search is sent to two
different databases over the Internet. As soon as the one of the databases comes
up with a result, the execution flow proceeds. The second result is ignored.
Degree of support offered by commercial WFMS. In all but a few WFMS,
the discriminator cannot be captured at the conceptual level [4]. A notable exception is Verve3 , which offers a specific construct for this pattern. In the SAP R/3
Workflow4 , for each AND-split/AND-join combination, it is possible to specify
for how many of the parallel branches started by the split, does the join need to
wait. One can be thus be tempted to capture the discriminator by specifying that
the AND-join only needs to wait for one of the branches started by the ANDsplit. However, the branches that are still running when the first branch finishes,
will be marked as logically deleted by the SAP R/3 Workflow, whereas in the
discriminator pattern these branches should proceed normally.
A solution using UML activity diagrams Figure 3 shows how to express
the discriminator as a set of concurrent regions communicating through signals.
Specifically, the incoming branches of the discriminator, as well as the outgoing
branch, are placed in separate regions of a single subactivity state. When this
subactivity state is entered, the regions corresponding to the incoming branches
of the discriminator are executed, while the region corresponding to the outgoing
branch sits in a wait state. When one of the incoming branches terminates, it
produces a signal which causes the outgoing branch to start its execution.
/send e
/send e
Fig. 3. Activity diagram capturing the discriminator pattern with 2 incoming branches.
This solution has a limitation when the discriminator is part of a loop. Consider for instance the situation depicted in figure 4(a), whose translation as an
activity diagram is given in figure 4(b). This activity diagram forces an undesired
synchronisation between activities B, C and D. Specifically, if B finishes before
C, D is started immediately. Now, if D subsequently finishes before C, and con3
4
http://www.verve.com or http://www.versata.com.
http://www.sap.com.
To appear in UML2001.
dition cond holds, activity A cannot be started immediately: it has to wait for
the completion of C. This is not in line with the semantics of the discriminator,
which does not impose any synchronisation constraint besides the fact that one
of its incoming transitions has to fire before firing the outgoing transition.
This example puts forward a limitation of activity diagrams inherited from
statecharts. Unlike Petri nets whose places can hold several tokens, states in a
statechart are boolean, in the sense that a state cannot be active several times
simultaneously. In the example at hand, if A was started immediately after the
completion of D, and if subsequently A finished before C, then the state labeled
C would have to be entered (i.e. activated) again.
C
/send e
/send e
discriminator
D
[cond]
[not cond]
[cond]
...
[not cond]
...
3.2
N-out-of-M join
i := 0
e[i < N 1]/i := i+1
B1
/send e
e[i = N 1]
B2
/send e
When the N-out-of-M join is part of a loop, the above solution has the same
limitation as the solution of the discriminator pattern presented in figure 4(b).
3.3
In real workflows, where human and material resources are not always available,
activities are more often in a waiting state than in a processing one [4]. This
fact is central in the following two patterns, where a distinction is made between
the moment when an activity is enabled, and that when it starts running. In
the first pattern, the choice between two alternative enabled activities is delayed
until an event occurs. In the second pattern, several enabled activities have to
be processed, but at any point in time, at most one of them can be running.
4.1
Deferred choice
e1
e2
4.2
To appear in UML2001.
between the activities is decided at run-time: it is not until one activity is completed that the decision on what to do next is taken. In any case, no two activities
among A1 , . . . , An can be active at the same time.
Example. The army requires every applicant to take 3 tests: an optical, a medical, and a mental. These tests can be conducted in any order but obviously not
at the same time. When an applicant completes a test, the decision of which test
to perform next is taken depending on the presence of the relevant doctors. If for
example the doctor responsible for the optical test is present, while the doctor
for the medical one is absent, the optical test is performed before the medical.
Degree of support offered by commercial WFMS. In many WFMS, this
pattern cannot be expressed at the conceptual level. At the implementation level,
it can be coded by introducing a resource shared by all activities A1 , . . . , An .
This shared resource acts as a semaphore, forcing a serialization of the activities.
Since this pattern can be expressed in terms of the deferred choice pattern
(see below), it can be captured in those WFMS supporting the deferred choice [4].
Solutions using activity diagrams. This pattern can be expressed in terms
of the deferred choice as follows. First, a deferred choice is made between n
branches, such that the ith branch starts with activity Ai (1 i n). In the
branch that leads to activity A1 , another deferred choice is made (after A1 is
executed) between n 1 branches respectively starting with A2 , . . . , An . A
similar nested deferred choice is also made in all the other branches of the first
deferred choice. This process of nesting deferred choices is recursively repeated,
until all the permutations of A1 , ..., An are enumerated. Clearly, for a large
number of activities, this combinatorial explosion is undesirable.
A better alternative is to enforce the interleaving of activities by placing each
activity in a separate concurrent region, and blocking their execution through
synch states emanating from a single blocking region (this is the leftmost
region in figure 7). A token is inserted into the synch state blocking an activity
Ai, only after the processing of the event that enables the execution of Ai.
When Ai starts its execution, the blocking region enters a state which defers
the occurrences of events that may unblock the execution of other activities. For
instance, in figure 7 events s1, s2 and s3 are used to indicate that activities A1,
A2 and A3 respectively, can be executed. If one of these events occurs while one
of the activities is being executed, the processing of this occurrence is deferred
until the ongoing activity execution has completed.
Producer-consumer patterns
The patterns in this section are variants of the producer-consumer pattern found
in distributed systems design. They correspond to situations where several instances of an activity A (the producer) are executed sequentially, and the termination of each of these instances triggers the execution of an instance of another
activity B (the consumer). The instances of A and B execute concurrently, but
some asymetric inter-dependencies link them (a B is caused by an A).
To appear in UML2001.
10
i := 3
s3
s2
s1
1
1
1
s1/ defer
s2/ defer
s3/ defer
done[i = 1]
A1
/send done
A2
/send done
A3
/send done
5.1
11
i := 0
A
[done]
[more]/i := i + 1
*
[i > 0]/i := i 1
[i = 0]
Fig. 8. Activity diagram for the producer-consumer pattern with termination activity.
This solution is such that at any point on time, at most one instance of B
is running. Although we do not have a proof, we believe that the version of this
pattern where multiple instances of B may run concurrently, cannot be expressed
as an activity diagram. Indeed, this would require a dynamic invocation operator
in which not all of the dynamic arguments are available at once, but rather arrive
one by one. Given such an operator, it would be possible to express that an
instance of B needs to be triggered each time that an instance of A terminates,
even if the previously generated instances of B have not yet completed.
5.2
12
A has been executed, and the number of times that activity B has been executed,
is bounded by an integer called the size of the queue.
Example. To obtain an ID card, an applicant has to complete a form and
present it to an officer for verification. Once the officer has checked the form,
the applicant is sent to a photographers room. However, the queue leading from
the officers counter to the photographers room cannot contain more than 5
persons. Should the queue contain 5 persons, the officer would stop accepting
applications until one of these persons enters the photographers room.
Degree of support offered by commercial WFMS. See previous pattern.
Solution. The idea is to modify the diagram of figure 8, in such a way that two
separate counters are kept: one counting the executions of A (na), and the other
counting the executions of B (nb). Every time that activity A is completed, if
the boolean variable more is true, a waiting state is entered, which is only
exited when the condition na nb < s holds (where s is the size of the queue).
Related work
13
Conclusion
14
References
1. J.. Aagedal and Z. Milosevic. ODP enterprise language: An UML perspective.
In Proc. of The 3rd International Conference on Enterprise Distributed Object
Computing, Mannheim, Germany, 1999. IEEE Press.
2. W.M.P. van der Aalst. The application of Petri nets to workflow management.
The Journal of Circuits, Systems and Computers, 8(1):2166, 1998.
3. W.M.P. van der Aalst, A.P. Barros, A.H.M. ter Hofstede, and B. Kiepuszewski.
Advanced workflow patterns. In Proc. of the 5th IFCIS Int. Conference on Cooperative Information Systems, Eilat, Israel, September 2000. Springer Verlag.
4. W.M.P. van der Aalst, A.H.M ter Hofstede, B. Kiepuszewski, and A. Barros. Workflow patterns. Technical Report WP 47, BETA Research Institute, 2000. Accessed
March 2001 from http://tmitwww.tm.tue.nl/research/patterns.
5. E. B
orger, A. Cavarra, and E. Riccobene. An ASM semantics for UML activity
diagrams. In Proc. of the International Conference on Algebraic Methodology and
Software Technology (AMAST), Iowa City, IO, USA, May 2000. Springer Verlag.
6. F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Conceptual modeling of workflows. In
Proc. of the 14th International Object-Oriented and Entity-Relationship Modelling
Conference (OOER95), pages 341354. Springer Verlag, December 1995.
7. R. Eshuis and R. Wieringa. A formal semantics for UML activity diagrams
Formalising workflow models. Technical Report CTIT-01-04, University of Twente,
Department of Computer Science, 2001.
8. M. Fowler and K. Scott. UML Distilled: A Brief Guide to the Standard Object
Modeling Language (Second Edition). Addison Wesley, Readings MA, USA, 2000.
9. D. Harel and A. Naamad. The statemate semantics of statecharts. ACM Transactions on Software Engineering and Methodology, 5(4):293333, October 1996.
10. B. Kiepuszewski, A.H.M. ter Hofstede, and C. Bussler. On structured workflow
modelling. In Proc. of the Int. Conference on Advanced Information Systems Engineering (CAiSE), Stockholm, Sweden, June 2000. Springer Verlag.
11. F. Leymann and D. Roller. Production Workflow: Concepts and Techniques. Prentice Hall, Upper Saddle River, NJ, USA, 2000.
12. P. Muth, D. Wodtke, J. Weissenfels, A.K. Dittrich, and G. Weikum. From centralized workflow specification to distributed workflow execution. Journal of Intelligent
Information Systems, 10(2), March 1998.
13. The precise UML group. Home page. http://www.cs.york.ac.uk/puml/.
14. UML Revision Task Force. OMG Unified Modeling Language Specification, Version
1.4 (final draft). February 2001.
15. J. Rumbaugh, I. Jacobson, and G. Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999.
16. M. Schader and A. Korthaus. Modeling business processes as part of the
BOOSTER approach to business object-oriented systems development based on
UML. In Proc. of The Second International Enterprise Distributed Object Computing Workshop (EDOC). IEEE Press, 1998.
17. The Object Management Group. UML Extensions for Workflow Process Definition, RFP-bom/2000-12-11. Accessed on June 2001 from ftp://ftp.omg.org/
pub/docs/bom/00-12-11.pdf.
18. The Workflow Management Coalition. The Workflow Reference Model. http:
//www.aiim.org/wfmc/standards/docs/tc003v11.pdf, accessed on January 2001.
To appear in UML2001.
15