List of Algorithms
Algorithm 6.1: Traversing a task delegation graph for workflow graph generation
A1 B D A
A2 B1
B2
D1 D2
C
… D2.1
E1
E Dn
U1 U2 U4
U3
… A2.m A2.1 Task delegation graph:
Strict delegation sub-graph for A1:
A1 B
C
C
D E
Ux
F
F
Figure 6.1: Strict delegation sub-graph for a task in a task delegation graph 6.2.2 Traversing a Task Delegation Graph
The thesis suggests enabling a step-wise, iterative transformation of a task delegation graph to a workflow model. Step-wise transformation enables users to better evaluate the reflection of user-defined process models into formal workflow graphs. This approach further allows derivation of workflow models with different granularity, i.e. the user can interrupt the transformation after only a set of high-level tasks in the hierarchy have been transformed. The generic algorithm for traversing a task delegation graph is provided in the following.
The introduced generic algorithm is detailed in the remained of this chapter where the transformation of root tasks, initial (parent) tasks and the generation of workflow blocks are discussed. An example traversal of a task delegation graph is shown in Figure 6.2, i.e. according to the graph fragments that are transformed in the different traversal steps. The processing starts from the root taskA, and continues with parent tasks in a breadth-first traversal. Each processing step assembles anevaluation set, which produces a workflow block. Different interpretations of hierarchical task decomposition and delegations result in different evaluation sets. These interpretations and the assembling of evaluation sets are discussed in the next sections.
A central point in the traversal procedure is that all tasks in astrict delegation sub-graph of a given requester task are considered as residing on the same level in the task hierarchy as the requester task, i.e. as being virtually children of the parent task of this requester task. Thus, tasks from the strict delegation sub-graph of a requester task are processed together with the requester task itself and reside in the sameevaluation set. For example whenA in Figure 6.2 is transformed, its sub-tasksA1 andA2 are processed together with the recipients’ tasks ofA1 (tasksB andC).
During each transformation step, non-atomic tasks are marked as initial tasks. For example, when taskA is transformed, tasksB andA2are marked as initial tasks. Initial tasks determine the target for the next transformation (traversal) step.
In case of delegations, requester and recipients tasks can be merged by selecting one of them as the preferred final task for the workflow model. In the latter case the sub-tasks of requester and recipients tasks are handled as children of the same parent, i.e. the selected preferred task. Thus, if any of the merged tasks has sub-tasks, the selected preferred task is marked as initial task even if it does not have sub-tasks in the task delegation graph. For example, when taskA is transformed, A1, B andC can be merged by selecting one of them as a preferred merge task M. IfA1 or C is selected as a merge task forB, the selected merge task is considered as initial task becauseB has sub-tasks. Merge is discussed in details in Section 6.2.4.3.
A1 B
D A
A2 B1
B2 D1
D2
C
… D2.1 E1
E
Dn U1
U2
U4
U3
… A2.m A2.1
Task delegation graph:
A1
A
A2
1) Process root task A :
B
C
C
3) Process next parent task A2: A2
… A2.m A2.1
2) Process next parent task B or merge task M = A1 B C : B
B1 B2
4) Process next parent task D or merge task M = B1 D :
D2 D2.1
5) Process next parent task D2: D
D1 D2
… Dn
6) Process next parent task E or merge task M = D2.1 E :
E1 D E
E
Figure 6.2: Example traversal of a task delegation graph
6.2.3 Interpretation of Hierarchical Task Decomposition
Hierarchical decomposition of tasks into sub-tasks enables end users to refine the working tasks and to specify them to a lower level of details. Decomposition of ad-hoc tasks in hierarchical to-do lists is largely considered in related literature on task management and user-centric process support [Ber00, HRD+06]. However, the transformation of hierarchical decomposition to workflow graphs is not discussed in the literature. The thesis proposes different interpretations of such decomposition for the transformation of task delegation graphs to structured workflows.
6.2.3.1 Parent Task to Sub-Process
Formal modeling notations enable modularization of process models through non-atomic sub-processes [OMG06]. On the one hand, this modularization provides simplification of the visual process models. On the other hand, modularization fosters reuse as sub-processes receive a single input and deliver a uniform output by performing a self-contained functionality [RM08]. Thus sub-processes can be reused as modules in different larger process models.
The thesis suggests enabling transformation of non-atomic tasks from a task delegation graph, to non-atomic sub-processes in a derived workflow model. This transformation is especially relevant if sub-tasks in a task delegation graph inherit some of the context attributes or artifacts of their parent task. Such inheritance would imply that the input of the parent task is distributed to the sub-tasks, similarly to the interpretation of sub-processes in formal process modeling.
6.2.3.2 Parent Task to Atomic Task
A parent task in a task delegation graph may have context attributes and artifacts which are not transferred to any of its sub-tasks. This can imply that the task decomposition in the task delegation graph is not correct in the sense that the sub-tasks do not represent single steps towards reaching the goal of the parent task. For handling such cases, the thesis suggests transformation of a parent task to an atomic workflow task, preceding the sequence of the sub-tasks.
Precedence is explicitly considered as the parent task cannot be completed before the sub-tasks during ad-hoc task management, i.e. completing the parent task completes also all sub-sub-tasks (cf. Section 5.1.5.2). Thus no evaluation of the execution sequence of the parent task and the sub-tasks based on the sub-tasks’ change history can be performed as discussed further in this chapter.
6.2.3.3 Parent Task to Logical Group Association
Formal process modeling languages [OMG06] consider logical association of tasks for documentation and analysis of process diagrams. The provided group association elements [OMG06] do not affect the task flow. The thesis considers transformation of a parent task from a task delegation graph to a logical group association for the case that a parent task does not contain any task details in terms of textual description or artifacts. In this case, a parent task may represent a logical unit which roughly identifies the overall goal of a task and serves mainly for grouping the concrete sub-tasks.
The proposed transformation of a parent task to a logical group association considers two basic options: (i)transformation withand (ii) transformation without merge of grouped sub-tasks at the hierarchical level of the initial parent task. The transformation options are exemplified respectively in Figure 6.3 (a) and Figure 6.3 (b) and discussed in the following.
During parent task transformation to logical group association with merge of the grouped sub-tasks at the hierarchical level of the initial parent task (Figure 6.3 (a)) the grouped sub-task nodesa2.1 toa2.m resulting fromA2.1 toA2.m are merged with the sub-task nodes resulting from the transformed parent taskA. The only sub-task ofA that is considered in Figure 6.3 isA1 asA2 itself is transformed to a logical group associationLA2. Transformation with merge allows evaluation of task sequence based on a common evaluation set comprising the sub-tasks ofA andA2(seeT in Figure 6.3 (a)). Thus, this transformation “flattens” the task hierarchy by considering the parent
taskA2 and its sub-tasks as residing on the same level. In this case the generated group element LA2 may encompass also workflow task nodes for sub-tasks of the previously processed parent task A such as a1 depending on the detected task sequence. Sequence generation from an evaluation set is discussed further in this chapter.
During parent task transformation to logical group association without merge of the grouped sub-tasks at the hierarchical level of the initial parent task (Figure 6.3 (b)) the sub-tasks A2.1 to A2.m of the processed initial parent task A2 are comprised in a single evaluation set. The sequence of the processed sub-tasks (A2.1 toA2.m) is generated independently from the sequence of the sub-tasks (A1 and A2) of the previously processed parent taskA. Thus the generated group element groups only workflow nodes (a2.1 to a2.m) that are generated from the sub-tasks of the transformed initial parent taskA2.
Independently of the transformation type agroup element association is established on system level between each grouped workflow node and the corresponding logical group element, i.e.a2.1
toa2.m receive a logical group association toLA2. This association on system level is required to recover group elements when redefining generated workflow blocks. For example, let A3 be a further non-atomic sub-task ofA. Let A3 be transformed to a logical group association through merge by producing a group elementLA3. After A3 is transformed,LA2 has to be recovered so that no group associations from previous transformations are lost. TherebyLA3 andLA2 may (visually) overlap depending on the detected sequence of the tasks in the evaluation set.
A1 A
A2
… A2.m
A2.1 a1
a
LA2 a2.1
a2.m
(a) (b)
a1 a
LA2 a2.1
a2.m
} { } ,...,
{A2.1 A2. A1
T m T {A2.1,...,A2.m}
Processing A2
… …
Figure 6.3: Transformation to logical group association - the transformed task isA2, the assembled evaluation set isT
6.2.3.4 Omitting Parent Tasks
Omission of parent tasks during transformation of a task delegation graph is considered for simplification of the derived structured process model. Omission is relevant if a transformed parent task does not have context information and thus merely groups its sub-tasks, and if the user intends to explicitly declare logical group association other than the existing parent task, not to declare any group association at all, or if the workflow modeling notation selected for export does not allow grouping. The transformation of a parent task through omission is performed in the same way as export to a logical group association and considers the same two options (with and without merge at hierarchical level of parent task) except that no logical group element is created from the transformed parent task.
6.2.4 Interpretation of Delegations
Task delegation graphs represent execution examples for ad-hoc processes, which emerge in an ad-hoc, underspecified manner. The unplanned behavior may produce collaborative tasks which have different meaning from business perspective and which require different interpretation during process model transformation. The thesis proposes transformation of collaborative tasks through three different interpretations: (i) omission, (ii) preserving, and (iii) merge. These are discussed in the following sections. An important notice for the following discussion is that delegations can be performed iteratively and a requester task may have an involved strict delegation sub-graph (cf. Figure 6.1). The thesis suggests that during the process model transformation the user should be able to inspect all collaborative tasks in the strict delegation sub-graph of a delegated task and to estimate which tasks to omit, preserve, and merge.
6.2.4.1 Omitting Collaborative Tasks
Omitted tasks are excluded from the transformation procedure and do not produce workflow task models. Omission aims at simplification of the derived workflow model.
Omission of requester tasks is considered for the case that a delegated task in a task delegation graph is fully processed by the recipient(s). For example, a managing director has created a task for organizing a steering committee meeting which they have delegated to their assistance. The director is not involved in the task but is able to refer to the local task representation in their to-do list, and to switch to the global process overview to inspect the further processing of the task. In this case the requester task does not incorporate information about the actual processing of the task.
Omission of recipient tasks is considered if a recipient has accepted the task, but was unable to process the task for some reason and the task has been processed by the requester or by another recipient(s). Following the above example, the managing director has delegated the task for organizing a steering committee meeting to one of their assistants, who has accepted the task but was unable to process it on time, e.g. because of illness leave or other unexpected circumstances.
Then the managing director has delegated the task to another assistant or processed it themselves.
A further use case for omission of recipient tasks may arise if the task assignment and distribution in ad-hoc processes differs from those in structured workflows. On the one hand, multiple recipient tasks may exist for a delegated task in a task delegation graph. On the other hand, in a workflow model a single task may be distributed to different stakeholders during workflow execution based on multiple task assignments. Thus, during process model transformation one of the tasks in the strict delegation sub-graph can bepreserved for generating a single workflow task in the derived workflow and the other recipient tasks can beomitted. Such omission prevents from exporting multiple, redundant tasks to the structured workflow model but requires that after the transformation the user (manually) assigns the derived workflow task to the owners of omitted recipients’ tasks. Omission further raises issues if some of the collaborative tasks have sub-tasks denoting low-level activities that need to be performed by the different stakeholders. These issues are addressed through the merge option as discussed later on.
6.2.4.2 Preserving Collaborative Tasks
All requester and recipients tasks that incorporate information about the actual task processing can be preserved during process model transformation. Requester tasks can be preserved if the requester task contains information about the task processing that is not contained in the recipient task(s) and the requester needs to perform on that task. An indication for preserving a requester task may be for example the availability of sub-tasks in the requester task. This case can arise if a user has delegated a task to other persons but later on noticed that they need to perform some activities on that task themselves and created sub-tasks for the already delegated task. Preserved tasks produce corresponding workflow task models. Preserving multiple tasks in a strict
delegation sub-graph may be unacceptable if the workflow model requires a single task node with multiple assignments, which is then distributed to multiple process participants during workflow execution. In this case the merge option can be applied.
6.2.4.3 Merging Collaborative Tasks
Merging can be applied to two or more preserved collaborative tasks from a strict delegation sub-graph. Preserved collaborative tasks are merged by selecting one of them as amerge task. More than one merge tasks can be selected if multiple collaborative tasks are preserved. A task from the strict delegation sub-graph is allowed to have only one merge task. The merge task cannot be a merge task to itself.
A task that has an associated merge task is referred to asmerged task. A merged task cannot be selected as a merge task itself. Instead the associated merge task of that merged task can be used for merging. The latter rule applies as merge aims at consolidation of collaborative tasks during process model transformation and all merged tasks are considered as describing a common logical unit of work.
A merge task produces a single workflow task model for all merged tasks. Context information and assignments of multiple merged tasks can be transferred to the workflow task model that is derived from the associated merge task. The sub-tasks of the merged tasks are handled as sub-tasks of the merge task and comprised in a single evaluation set. This allows grouping collaborative tasks of different users in the same logical group association or sub-process. The sub-tasks of the merged ad-hoc tasks are preserved and transformed to workflow tasks, which are assigned to the corresponding various owners of the original merged tasks.
6.2.5 Task Transformation
This section provides the algorithms for transformation of a task delegation graph. Following the generic procedure for task delegation graph traversal, the discussion starts with root task transformation and then continues with initial (parent) task transformation. A root task is handled as a special case insofar it is the first transformed task in a task delegation graph.
The provided algorithms consider the discussed interpretation of hierarchical decomposition and delegations and clarify the assembled evaluation sets. An assembled evaluation set is the associated evaluation set for all tasks in it. Merged tasks receive the evaluation set of the associatedmerge task as anassociated evaluation set. Ifcancelled ad-hoc tasks are encountered, the user is allowed to specify whether to include these in the evaluation set, or not.