Modeling work:
Workflow and Task modeling
Hallvard Trætteberg
Dept. of Computer and Information Sciences
Norwegian University of Science and Technology
Abstract. In this paper, we motivate integration of workflow and task modeling,
present and compare workflow and task modeling concepts and suggest benefits
of integrating them. We show how a workflow model can be utilized when modeling the tasks of a workflow participant and propose that task enactment can be
a practical result of workflow and task model integration.
1
Introduction
An organization’s IS must support work being performed at three levels: the organizational, group and individual levels. Workflow modeling languages are often used for
describing the former two, while task analysis and task modeling are used for describing and formalizing that latter. The boundary, however, is blurred and in this paper we
look at integration of workflow and task modeling language and models, having the
following hypotheses:
•
•
•
At the language level, workflow modeling concepts can be used for task modeling.
At the model level, workflow models can provide a useful context for task models.
At the enactment level, an integrated approach to workspace design and user interface execution may result in better human workplaces.
Section 2 will introduce important workflow concepts and interpret them in the context
of task modeling. Section 3 will show how workflow models might influence task
modeling. In section 4 turn to how an integrated machinery for workflow enactment
and user interface execution might benefit the end user.
2
Aspects of work and its description
Marshak[2] identifies four dimensions for describing work: the action structure, the
actors that perform the work, the tools that are used and the information (sources) that
are needed. These concepts are presented below and exemplified in figure 1.
The action is the building block for actions structures. An actions is enabled by certain
implicit and explicit pre-conditions, e.g. the availability of necessary information. The
pre-conditions of an action may depend on other actions, giving a dependency structure. Dataflow, explicit pre-conditions and control flow are used to define necessary
constraints on action sequences, while speech acts[3] based on institutionalized dialog
patterns, gives more restrictive pre-conditions and constrained action sequences. Composite actions and action hierarchies help to reduce complexity. Actions can be
abstract, by defining the external characteristics and leaving the internals unspecified.
Task interpretation The action concept corresponds to the task concept, and the action
hierarchy to the task/subtask structure. At the model level, we believe low-level workflow actions may correspond high-level tasks. Most task modeling languages are based
on explicit sequencing primitives. Hence, it is not explicitly expressed whether a
sequence is due to necessary (e.g. data flow) or social conditions.
Actors are the intentional beings performing the actions. Technically, actors can be
viewed as resources with certain characteristics and abilities that are required by the
actions. By listing the needed characteristics, like rights and abilities, actions implicitly define who can perform them. Sets of actors can be defined extensionally, by listing their members, or intensionally, by defining their common characteristics, giving
groups and roles, respectively. An actor can be part of several groups and play several
roles, although not necessarily for all actions or in all contexts.
Task interpretation The actor and group concepts correspond to users and user groups,
which refer to concrete individuals, while roles’ counterpart are user stereotypes. The
former tow is typically used when describing current practice, while the latter is introduced when there is a need for more than a single “generic user”.
Objects are the material, mental or representational things that actions are performed
on, as well as useful contextual information used by actors. The objects granularity and
detail can be from whole databases and documents to records and words.
Task interpretation Most task models assume there is a model of the domain or the
application data, that task are defined in terms of. As for workflow, the level of formality and detail may vary, although it is common to use object oriented or similar models
with concepts, relations and attributes. We expect workflow objects, if further detailed
to a relevant level, to be directly usable in task models.
A tool is a kind of resource, which in workflow models typically are applications or
components. A tool can be concrete application like ‘Eudora’ or abstract like ‘email
client’. In addition, tools can be composite by listing several applications (classes) or
components in a suite or referring to the suite as a whole, e.g. ‘Internet access tools’.
Task interpretation Tools are software elements supporting the performance of actions,
which at the granularity of user tasks correspond to dialog elements or user interface
objects. The tool concept provides the link from the specification of the user interface
functionality to the user interface design elements providing it.
Table 1 summarizes our analysis of the action, actor and tools concepts, indicating
their correspondences with and opportunities for task modeling. The ontology or meta
model for task modeling presented in [4] seems to support our analysis. Paterno’s ConcurTaskTrees[5], embodies the idea that cooperation and coordination can be handled
by including a level above individual task models, which is consistent with our view.
3
Workflow and task modeling
Our suggested integration of workflow and task modeling languages is based on the
idea that workflow and task models essentially describe the same domain, but at different levels. By using the workflow model as a context for the task modeling, we should
Generic
Abstract
Composite
Task interpretation
Action: basic
unit of work,
data flow or
speech act
based
Delayed definition, action template parameter
Provides hierarchical composition, also called
process, job,
activity
Task, task/subtask hierarchy
• Data availability defines
necessary pre-conditions
• Work practice as additional
constraints
Actor: intentional beings
performing
actions
Role: Intensionally defined set
of actors, based
on actor characteristics
Group: Extensionally defined
set of actors
User, user group, stereotype
• Multi-user task models
• Multiple work practices
• Design targeted at different
user groups
Tool: software supporting actions
Application
class
Application
suite, integrated
components
Dialog element
• Links spec. and design
• Task based enactment
• Component composition
Table 1: Workflow and task modeling concepts
gain two important advantages: 1) The relevance of the task structure should be
ensured, since it is motivated by organizational goals. 2) In addition to using the lowlevel actions as the top-level tasks, most of the elements of the task model, like roles,
information and tools are already identified.
DETAILS
A1
returned
from
travel
condition
REPORT
Write
report
User
App
“FINAL”
resources
REPORT
dataflows
A2
Provide
details
Secretary
A3
Sign
report
OBJECTIONS
FINAL
REPORT
Adm.
output
Manager
Fig. 1. Write travel report workflow: USER must write a report upon return from a travel,
supported by the SECRETARY and MANAGER roles and a software tool (APP) that we want to
design. USER interacts with the others to fill in details and gather and respond to objections.
The APM[1] example in figure 1 illustrates our point. USER performs one low-level
action, A1, which can be used as the top-level task. The three ways of starting and
resuming this task, are defined as sub-tasks, as shown in figure 2. The data initiated
tasks are decomposed into tasks for sending, receiving and handling the relevant information. We see that the workflow model can provide both initial task model elements
A1.1 Write report
User
Make initial report
Request
details
Secretary
Receive
details
App
Add details
Fill in
details
Secretary
Handle objections
Submit
report
Receive
objections
Manager
React to
objections
Manager
Fig. 2. Task model for USER based on the workflow model example
and opportunities for further refinement. The communication tasks suggests that communication tools should be included in the design.
4
Conclusion and further work
We have shown that Marshak’s four dimensions[2] for describing workflow have natural correspondences in the task modeling domain. Suggestions for how these can be
used in task modeling have been presented, and we how shown how a workflow model
can be used as a context and starting point for a task model.
A strong motivations for workflow modeling is the process enactment In moving from
modeling to enactment, the tool resources of the actions must be refined. At some
point, workflow enactment will have to be in terms of tasks and the supporting user
interface elements, and this task enactment is an exiting direction for further research.
This requires the ability to reference the dialog elements indirectly through the task
dimension and motivates a stronger coupling between task and dialog models.
References
1. Carlsen, S., Action Port Model: A Mixed Paradigm Conceptual Workflow Modeling Language. Proceedings of CoopIS - Cooperative Information Systems ’98
2. Marshak, R.T., Workflow: Applying Automation to Group Processes. In: Coleman, D. (ed.):
Groupware - Collaborative Strategies for Corporate LANs and Intranets. Prentice Hall PTR
(1997) 143-181
3. Searle, J.R. and Vanderveken, D., Foundations of Illocutionary Logic. Cambridge University Press
4. Van Welie, M., Van der Veer, G.C., Eliëns, A.:An Ontology for Task World Models. In:
Markopoulos, P., Johnson, P. (eds.): Proceedings of DSV-IS‘98, Springer-Verlag 57-70
5. Paternò, F., Mancini, C., Meniconi, S.: ConcurTaskTrees: A Diagrammatic Notation for
Specifying Task Models. Proceedings of Interact ’97, Chapman & Hall (1997) 362-369