Workflows

Objective

If models are to be put under a common roof, from requirements to design, some bridge has to be built between the description of business processes and UML activity and state models. Yet, if there is a broad consensus on basic artifacts, the focus is usually put on notations, which entails too many features hiding functional archetypes. The objective is to look beyond notation in order to identify workflow patterns depending on their impact on functional architecture.

Activities vs Processes

The objective here is to consolidate a description of patterns based upon architecture dependencies, namely functional scope and identification.  And that should be done not only between activities and processes, but also between objects and behaviors.
Regarding behaviors, two kinds of dependencies must be considered: flow dependencies are logical and set by the targeted objects and the nature of operations; execution dependencies combine flow dependencies and operational constraints.
Symbolic description of activities can be stereotyped as:

• Rules regarding the processing of actual objects.
• Rules regarding the processing of symbolic representations.
• Rules regarding the processing of interactions.
• Rules regarding the processing of events.
• Rules regarding symbolic computations.
• Rules regarding the control of actual processes.

The same classification is applied to actual states depending on:

• Processing of actual objects.
• Processing of symbolic representations.
• Agent’s expectations (“state of mind”).
• Events processing.
• Execution of symbolic computation.
• Control of actual processes.

Control Level

From an architecture point of view, the first concern is to identify the level under considerations: local control is supported by structural links between whole and parts, global control is supported by functional connectors between independent activities.  Depending on control level, the semantics of strong coupling will be different: for local activities it means instant (or real-time) synchronization, for independently run activities “real-time” only means that targeted objects must be protected from outside interference until the completion of the associated activity.

Since the objective of representation patterns is to extract architectural constraints from business requirements, responsibilities on functional domains and process controls must be established on purely organizational criteria:

• Who’s is responsible for defining business objects and setting business rules.
• How is the execution of business processes to be controlled, centrally or through collaboration.

For instance, putting invoice preparation and notification within the same structure means that all resources are managed by the same organizational unit and that activities can be synchronized under a single clock. But if notification is to be outsourced, some explicit representation must be included for messages and elapsed time.

Hence, the two solutions are explicitly represented:

• Structures are used when all activities are meant to be executed under a centralized control, which also implies a single location and a time capsule excluding interfering events.
• Functional connectors are used between activities are run independently. In that case there is no time capsule to isolate from external events and control must be explicitly modelled along execution paths.

Sequence

A logical sequence is used when the output of an activity is a necessary input of another one. It is adorned by an identifying qualifier when some synchronization is required. As noted above, sequencing can be used between local activities or independent ones.

Parallel Split

A parallel split means that the execution of several activities must follow a single event, usually the end of an initial activity whose output is used as input to the triggered ones. Parallel splits are said to be synchronized if the subsequent activities are instantly and simultaneously executed.

Multiplicity can be used if some paths are optional or can be repeated.

Synchronization

Workflow patterns are based upon stereotypes of activities synchronization, symbolic and/or actual levels:

• Symbolic synchronization means joining different activities which are processing the same object. It is described with symbolic activities.
• Actual synchronization means matching the timing of different activities. It is described with actual activities.

Timing

Synchronization uses events to initiate timing and time clocks to manage it. Descriptions of symbolic and actual timing use logical or physical clocks, respectively.

Merge and Join

Whereas split and merge are apparently symmetric, they nonetheless differ in the way actual activities are to be controlled:

• Splits are primarily activity-driven patterns since control can be supported by the source activity.
• Merges are primarily event-driven patterns since execution status or outcome from different or alternative sources must be considered in order to control the targeted activity.

Hence, even if events can be introduced in order to implement splits through event-driven mechanisms, or a controlling  activity may be created to control merges, at the root, splits and merges clearly entails different constraints on control architecture, and therefore calls for different patterns. For instance, assembling an equipage following a customer request can be driven by:

• Activity:  meters along a canal can be read occasionally duly time stamped for the readings being consolidated later.
• Event: readings are triggered by a scheduler and consolidated before further action to be taken if required.

As illustrated by the example, event-driven activities don’t necessarily require actual states modelling. Symbolic activities and flows (data and control) will suffice if control doesn’t use execution states.

Alternative (exclusive choice)

Alternatives are first introduced through partitions, and this pattern is used when one and only one path is to be executed (exclusive partition). Structural alternatives can be controlled locally, functional ones entail collaborations; depending on execution constraints, control policy can be activity-driven or must be event-driven.

Multiplicity

Structural and functional connectors between activities can be associated with tokens used to control activities. Since they refer to the number of runs that may or must occur, they are the equivalent of the multiplicity associated with object connectors, which indicate how many instances may or must be supported by a relationship.

Multiple Choices & Merges

Multiplicity can be used to describe overlapping options (multiple choices).

Merges can be needed to regroup what has been set apart by a split or a branch, or be applied to previously unrelated activities.

A Typology of Branches

Branches (aka extension points, aka gateways) define the way activities are performed depending on the contents of data and control flows. As rules they are best defined with regard to the semantics of their domains and co-domains, and since the objective is to factor out architecture concerns, that should be mapped respectively gateways’ footprint (domain) and purpose (co-domain):

• Footprint: functional gateways are driven by the contents of data flows, execution gateways are driven by events.
• Purpose: logical (aka computational) gateways are used to sequence activities independently of processes execution.

While branches usually cross footprints and purposes, business logic should be defined independently of its execution in processes, which means that branches targeting activities should be solely associated to data-driven rules:

• [IF data THEN branch]: business rules driven by data flows (b1).
• [IF data THEN merge]: process execution driven by data flows (m1).

When it comes to processes, branches are to combine data-driven event-driven rules:

• [WHEN data THEN branch]: business rules driven by data (b2).
• [WHEN data THEN merge]: process execution driven by data (m2).
• [WHEN event THEN branch]: process triggering driven by event’s features (b3).
• [WHEN event THEN merge]: process execution driven by external event and data flows (m3).

These basic gateways can be combined into complex ones, and using standard operators will help to align branches with lanes and tasks.

Further Reading

• Thread
• Use Cases shouldn’t know about classes
• Use Cases & Action Semantics
• Business Processes & Use Cases
• Use Cases are Agile Tools
• Focus: Business Processes & Abstraction
• Focus: Business Cases for Use Cases

External references

• http://www.workflowpatterns.com/patterns/control/index.php
• http://www.bpmn.org/Documents/Notations and Workflow Patterns.pdf
• Russell N., van der Aalst W., ter Hofstede A., “Workflow Patterns: The Definitive Guide”, MIT Press (2016)