Kommentare
Melden Sie sich an, um einen Kommentar zu verfassen.
Neueste Beiträge
-
Markus Güntert hat den Text von Best Practice 'Workflow Patterns: the Original 20' geändert
vor 2 Jahre, 6 Monate -
Markus Güntert hat Best Practice 'Workflow Patterns: the Original 20' hinzugefügt
vor 2 Jahre, 6 Monate
Tags
Workflow Patterns: the Original 20
The original objective was to delineate fundamental requirements for workflow systems which are independent from languages and technologies. The patterns were found by examining vendor offerings and provided a basis for discussions and comparisons.
Over the last years the patterns have been the basis for language capability assessments including EPCs, BPMN, BPML and BPEL. Meanwhile the patterns approach was extended to not only cover the control flow perspective but also data, resource and exception handling patterns.
Further information on workflowpatterns.com.
An activity in a workflow process is enabled after the completion of a preceding activity in the same process.
Further information on workflowpatterns.com
The divergence of a branch into two or more parallel branches each of which execute concurrently.
Further information on workflowpatterns.com.
The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled.
Further information on workflowpatterns.com
The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is immediately passed to precisely one of the outgoing branches based on the outcome of a logical expression associated with the branch.
Further information on workflowpatterns.com
The convergence of two or more branches into a single subsequent branch. Each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.
Further information on workflowpatterns.com
The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is passed to one or more of the outgoing branches based on the outcome of distinct logical expressions associated with each of the branches.
Further information on workflowpatterns.com.
The convergence of two or more branches (which diverged earlier in the process at a uniquely identifiable point) into a single subsequent branch. The thread of control is passed to the subsequent branch when each active incoming branch has been enabled.
Further information on workflowpatterns.com.
The convergence of two or more branches into a single subsequent branch. Each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.
Further information on workflowpatterns.com.
The convergence of two or more branches into a single subsequent branch following a corresponding divergence earlier in the process model. The thread of control is passed to the subsequent branch when the first incoming branch has been enabled. Subsequent enablements of incoming branches do not result in the thread of control being passed on. The discriminator construct resets when all incoming branches have been enabled.
Further information on workflowpatterns.com.
Within a given process instance, multiple instances of an activity can be created. The required number of instances is known at design time. These instances are independent of each other and run concurrently. It is necessary to synchronize the activity instances at completion before any subsequent activities can be triggered.
Within a given process instance, multiple instances of an activity can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications, but is known before the activity instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent activities can be triggered.
Within a given process instance, multiple instances of an activity can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications and is not known until the final instance has completed. Once initiated, these instances are independent of each other and run concurrently. At any time, whilst instances are running, it is possible for additional instances to be initiated. It is necessary to synchronize the instances at completion before any subsequent activities can be triggered.
This pattern is not supported in BPMN as there is no means to add more instances once the multiple instances activity has started
A point in a workflow process where one of several branches is chosen based on interaction with the operating environment. Prior to the decision, all branches present possible future courses of execution. The decision is made by initiating the first activity in one of the branches i.e. there is no explicit choice but rather a race between different branches. After the decision is made, execution alternatives in branches other than the one selected are withdrawn.
A set of activities has a partial ordering defining the requirements with respect to the order in which they must be executed. Each activity in the set must be executed once and they can be completed in any order that accords with the partial order. However, as an additional requirement, no two activities can be executed at the same time (i.e. no two activities can be active for the same process instance at the same time).
An activity is only enabled when the process instance (of which it is part) is in a specific state (typically in a parallel branch). The state is assumed to be a specific execution point (also known as a milestone) in the process model. When this execution point is reached the nominated activity can be enabled. If the process instance has progressed beyond this state, then the activity cannot be enabled now or at any future time (i.e. the deadline has expired). Note that the execution does not influence the state itself, i.e. unlike normal control flow dependencies it is a test rather than a trigger.
