A workflow pattern is a specialized form of design pattern as defined in the area of software engineering or business process engineering. Workflow patterns refer specifically to recurrent problems and proven solutions related to the development of workflow applications in particular, and more broadly, process-oriented applications.
Concept
Workflow patterns are concepts of economised development. Their usage should follow strategies of simplifying maintenance and reducing modelling work. Workflow is performed in real time. The mechanisms of control must support the typical pace of work. Design patterns must delay execution of workflow.
Aggregation
Workflow patterns may usually be aggregated as chains and the conditions for starting and terminating must be explicitly defined.
Application
Workflow patterns can be applied in various context, hence the conditions for use must be explicitly defined and shown in order to prevent misinterpretation.
Van der Aalst classification
A well-known collection of workflow patterns is that proposed by Wil van der Aalst et al. (2003) in their paper Workflow Patterns. with earlier versions published in 2000–02. This collection of patterns focuses on one specific aspect of process-oriented application development, namely the description of control flow dependencies between activities in a workflow/process. These patterns are divided into the following categories:
Basic Control Patterns
Sequence - execute two or more activities in sequence
Parallel Split - execute two or more activities in any order or in parallel
Synchronize - synchronize two or more activities that may execute in any order or in parallel; do not proceed with the execution of subsequent activities until all preceding activities have completed; also known as barrier synchronization. Exclusive Choice - choose one execution path from many alternatives based on data that is available when the execution of the process reaches the exclusive choice Simple Merge - wait for one among a set of activities to complete before proceeding; it is assumed that only one of these activities will be executed; typically, these activities are on different paths stemming from an exclusive choice or a deferred choice (see below) Terminate - terminate execution of activities upon defined event or status change
Advanced Branching and Synchronization Patterns
Multiple Choice - choose several execution paths from many alternatives
Conditional Choice - choose one execution path from many alternatives according to discriminated status conditions Synchronizing Merge - merge many execution paths; synchronize if many paths are taken; do the same as for a simple merge if only one execution path is taken Multiple Merge - wait for one among a set of activities to complete before proceeding; if several of the activities being waited for are executed, the simple merge fires each time that one of them completes. Discriminator - wait for one of a set of activities to complete before proceeding; if several of the activities being waited for are executed, the discriminator only fires once. N-out-of-M Join - same as the discriminator but it is now possible to wait until more than one of the preceding activities completes before proceeding by setting a parameter N to some natural number greater than one.
Structural Patterns
Arbitrary Cycle - do not impose any structural restrictions on the types of loops that can exist in the process model. Implicitly Terminate - terminate an instance of the process if there is nothing else to be done
Multiple Instances (MI)
MI without synchronizing - generate many instances of one activity without synchronizing them afterwards MI with a prior known design time knowledge - generate many instances of one activity when the number of instances is known at the design time (with synchronization) MI with a prior known runtime knowledge - generate many instances of one activity when a number of instances can be determined at some point during the runtime (as in FOR loop but in parallel) MI without a prior runtime knowledge - generate many instances of one activity when a number of instances cannot be determined (as in WHILE loop but in parallel)