You are on page 1of 4

Modeling work:

Workflow and Task modeling


Hallvard Trtteberg
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 mod-
eling 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 organizations IS must support work being performed at three levels: the organiza-
tional, group and individual levels. Workflow modeling languages are often used for
describing the former two, while task analysis and task modeling are used for describ-
ing 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 inter-
face 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 struc-
ture. 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. Com-
posite 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 work-
flow 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 implic-
itly define who can perform them. Sets of actors can be defined extensionally, by list-
ing 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 intro-
duced 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 formal-
ity 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. Paternos Con-
curTaskTrees[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 differ-
ent levels. By using the workflow model as a context for the task modeling, we should
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 low-
level actions as the top-level tasks, most of the elements of the task model, like roles,
information and tools are already identified.
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
Generic Abstract Composite Task interpretation
Action: basic
unit of work,
data flow or
speech act
based
Delayed defini-
tion, action tem-
plate parameter
Provides hierar-
chical composi-
tion, also called
process, job,
activity
Task, task/subtask hierarchy
Data availability defines
necessary pre-conditions
Work practice as additional
constraints
Actor: inten-
tional beings
performing
actions
Role: Intension-
ally defined set
of actors, based
on actor charac-
teristics
Group: Exten-
sionally defined
set of actors
User, user group, stereotype
Multi-user task models
Multiple work practices
Design targeted at different
user groups
Tool: soft-
ware support-
ing 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
A1
Write
report
User App
A2
Provide
Secretary
details
A3
Sign
Manager
report
Adm.
resources
output
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.
REPORT
FINAL
REPORT
FINAL
DETAILS
OBJECTIONS
REPORT
returned
from
travel
dataflows
condition
tasks are decomposed into tasks for sending, receiving and handling the relevant infor-
mation. We see that the workflow model can provide both initial task model elements
and opportunities for further refinement. The communication tasks suggests that com-
munication tools should be included in the design.
4 Conclusion and further work
We have shown that Marshaks four dimensions[2] for describing workflow have nat-
ural 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 Lan-
guage. 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 Univer-
sity Press
4. Van Welie, M., Van der Veer, G.C., Elins, A.:An Ontology for Task World Models. In:
Markopoulos, P., Johnson, P. (eds.): Proceedings of DSV-IS98, 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
A1.1 Write report
User App
Make initial report Add details Handle objections
Submit Receive
report objections
Request Receive
details details
React to
objections
Fill in
details
Fig. 2. Task model for USER based on the workflow model example
Secretary Manager Secretary Manager

You might also like