Van der Aalst classification .5B1.5D Workflow pattern

1 van der aalst classification

1.1 basic control patterns
1.2 advanced branching , synchronization patterns
1.3 structural patterns
1.4 multiple instances (mi)
1.5 state-based patterns
1.6 cancellation patterns

van der aalst classification

a well-known collection of workflow patterns proposed wil van der aalst et al. (2003) in paper workflow patterns. earlier versions published in 2000-02. collection of patterns focuses on 1 specific aspect of process-oriented application development, namely description of control flow dependencies between activities in workflow/process. these patterns divided following categories:

basic control patterns

sequence - execute 2 or more activities in sequence
parallel split - execute 2 or more activities in order or in parallel
synchronize - synchronize 2 or more activities may execute in order or in parallel; not proceed execution of subsequent activities until preceding activities have completed; known barrier synchronization.
exclusive choice - choose 1 execution path many alternatives based on data available when execution of process reaches exclusive choice
simple merge - wait 1 among set of activities complete before proceeding; assumed 1 of these activities executed; typically, these activities on different paths stemming exclusive choice or deferred choice (see below)
terminate - terminate execution of activities upon defined event or status change

advanced branching , synchronization patterns

multiple choice - choose several execution paths many alternatives
conditional choice - choose 1 execution path many alternatives according discriminated status conditions
synchronizing merge - merge many execution paths; synchronize if many paths taken; same simple merge if 1 execution path taken
multiple merge - wait 1 among set of activities complete before proceeding; if several of activities being waited executed, simple merge fires each time 1 of them completes.
discriminator - wait 1 of set of activities complete before proceeding; if several of activities being waited executed, discriminator fires once.
n-out-of-m join - same discriminator possible wait until more 1 of preceding activities completes before proceeding setting parameter n natural number greater one.

structural patterns

arbitrary cycle - not impose structural restrictions on types of loops can exist in process model.
implicitly terminate - terminate instance of process if there nothing else done

multiple instances (mi)

mi without synchronizing - generate many instances of 1 activity without synchronizing them afterwards
mi prior known design time knowledge - generate many instances of 1 activity when number of instances known @ design time (with synchronization)
mi prior known runtime knowledge - generate many instances of 1 activity when number of instances can determined @ point during runtime (as in loop in parallel)
mi without prior runtime knowledge - generate many instances of 1 activity when number of instances cannot determined (as in while loop in parallel)

state-based patterns

deferred choice - execute 1 of number of alternative threads. choice thread executed not based on data available @ moment when execution has reached deferred choice, rather determined event (e.g. application user selecting task worklist, or message being received process execution engine).
interleaved parallel routing - execute number of activities in order (e.g. based on availability of resources), not execute of these activities simultaneously.
milestone - allow activity @ time before milestone reached, after activity can no longer executed.

cancellation patterns

cancel activity - stop execution of enabled activity
cancel case - stop execution of running process
cancel wait - continue execution of running process without prior completion event

the above workflow patterns have been used evaluate functionality of commercial products supporting development of process-oriented applications. have been used evaluate number of proposed standards, including bpel, bpmn, uml activity diagram, xpdl, etc. has been noted not these patterns relevant in application domains, care must taken when using above workflow patterns select particular language or system given application.

the workflow patterns have been used initial requirements in design of workflow language , open-source system called yawl (yet workflow language).

several extensions above set of workflow patterns have been proposed. in particular, same research groups developed these patterns, have proposed set of workflow data patterns, workflow resource patterns, workflow exception handling patterns, , service interaction patterns.