Task Pattern Model

In the thesis a task pattern is considered as a reusable task structure, comprising one task with its sub-task hierarchy and the complete context information of the contained tasks such as name, description, used artifacts or involved persons (cf. Definition 4.2). A task pattern provides explicit best-practice recommendation for handling of recurring cases as introduced in [RRMvdA05, GOR+07] and clearly refers to the case dimension of business processes [vdABV+99]. Task patterns aim at providing enhanced capabilities for exchange, adaptation and reuse of process knowledge (R4) and serve as models for ad-hoc task instances in informal business processes.

Task patterns, which have been extracted from a task delegation graph, represent process execution examples that are abstracted from a specific process instance. Such task patterns can be reused in recurrent cases to reconstruct an ad-hoc process according to the captured previous example flow in the sense of the programming by example paradigm [Cyp93, Lie01]. The task pattern model is shown in Figure 4.6 and discussed in the following sections.

4.5.1 Task Pattern Structure

Parent/sub-task self references of task patterns, enable hierarchical decomposition similarly to task instances. However, in contrast to task instances, task patterns do not require a root task because they do not belong to a concrete process instance. Instead, task patterns represent reusable building blocks for ad-hoc task instances, which describe how a given generic business task can be accomplished. Task patterns can be defined to different level of details in terms of hierarchical decomposition and task context information depending on the users’ attitude towards managing reusable task and process data.

Suggested task pattern association in a given task pattern points at a task pattern, which can be used for further guidance and task decomposition, and which may be applicable also for other (similar) business cases. For example, a generic task for organizing a workshop can involve a task for ordering food, including finding a suitable catering company, comparing menus and prizes etc. The task for ordering food can be also relevant for another generic task for organizing a Christmas party. Hence, the food ordering can be stored as a separate task pattern and provided as suggestion for the food ordering tasks in the top-level task patterns for both – workshop and Christmas party organization. Task pattern decomposition and suggestions are discussed in Chapter 5.

0..1

0..* 0..1

ancestor

descendant 0..*

0..1 parent sub-task

task pattern suggested pattern

0..1

0..*

artifact

0..*

0..*

0..* owner user

artifact change

role

0..*

0..*

0..* 1

1

0..*

0..* 0..*

task pattern change

task task pattern

0..*

external artifact manager 0..1

0..*

delegation

recipient 1 0..*

requester task

0..*

1 recipient task

Figure 4.6: Task pattern model 4.5.2 Task Pattern Attributes

Task patterns aim at providing guidance for recurring cases by abstracting from a concrete process instance. Therefore task patterns do not contain attributes, related to concrete task instances. The task pattern attributes are shown in Figure 4.7.

identifier index name description execution time

task pattern

Figure 4.7: Task pattern attributes

The identifier servers to uniquely identify a task pattern in the task management system.

Identifiers support overall the associations between the task management model entities.

The index attribute identifies the index at which a task pattern resides in the sub-task hierarchy of a parent task pattern. This attribute thus supports appropriate ordering of sub-tasks in a parent task within task pattern hierarchies.

Thename anddescription attributes are self-explanatory and provide human-readable context information in textual form.

Theexecution time stores the time, which is needed for accomplishing a task. While users can set start and due dates for task instances (cf. Figure 4.3), these dates may not match the actual time needed. Dichotomies between target and actual execution times are discussed in related task management models [GOR+07]. Similarly to the latter study, the thesis suggests capturing actual execution time based on the task change history, i.e. calculating time between changes that indicate task processing and task completion.

4.5.3 Task Pattern Changes

Task patterns can undergo various changes. Similarly to task instances, these changes can be structural changes, changes in the context attributes or artifact changes. Artifacts can be associated to task patterns to enable artifacts’ reuse in recurring cases. The association of artifacts depends on the type of the declared task pattern and is discussed in the method for composition of weakly-structured process models in Chapter 5.

Tracking of task pattern changes can help to see how a task pattern definition has evolved over time. The thesis considers that a task pattern keeps the up-to-date knowledge of how a specific business case needs to be handled, whereas different task pattern variations are derived for variations in the business case. If a single task pattern is used and updated for different business case variations, eventually the frequent changes can make the task pattern unreliable for any of these variations. Hence, best-practice variations need to be represented through different task patterns rather than through the history of a single task pattern. As a result, task pattern changes are introduced here for completeness. The focus in the thesis is set on managing different best-practice variations that are reflected through different, interrelated task patterns and the management of task pattern change history is not discussed further.

4.5.4 Delegation Flow

As task patterns aim at providing guidance for recurring cases by abstracting from a concrete process instance, they do not involve collaborative delegation flow like task instances. Messages and dialogs related to ad-hoc task instances are considered as depending on the given execution context of the respective ad-hoc process. When a task pattern is extracted from a task delegation graph, the messages and dialogs related to ad-hoc task instances are removed from the pattern. In order to enable reuse of recipient information and recipients’ tasks, the task pattern model considers transformation of task delegation dialogs to delegation entities (cf. Figure 4.6). The transitions between task instances and task patterns and the different ways to compose task patterns are discussed in Chapter 5. Here the focus is set on the underlying model entities.

Thedelegation entities exclude the message flow but inherit a reference to the requester task, the recipient, and the recipient’s task which has resulted from the acceptance of the associated task request. Hence, in task patterns recipients are associated to a requester task through task delegation entities. Requester information is not considered in delegation entities because a task pattern provides a task model, where no information is available who will be the actual requester for the delegated task in an ad-hoc task instance that results from this task model.

Thus, in case of task pattern extraction from a task delegation graph, a delegation entity defines how a requester task has been handled by a single recipient. In case of multiple recipients, one requester task is associated to multiple delegation entities. Each of these delegation entities specifies how the delegated requester task has been handled by one recipient through one (accepted) recipient’s task. The different interpretations of task delegation towards consolidating process knowledge from multiple recipients are discussed in more detail in Chapter 5.