Abstract

Task models are useful when designing and developing interactive
systems. They describe the logical activities that have to be
carried out in order to reach the user’s goals. This document
covers the specification of Task Models, with a meta-model
expressed in UML, and an XML Schema that can be used as the basis
for interchange of Task Models between different user interface
development tools.

Status of This Document

This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document defines a meta-model and XML serialization for
task models for describing user interfaces. This is an update to
the First Public Working Draft to conform to the policy for W3C namespace
URIs, and to make minor changes to terminology.

Publication as a Working Group Note does not imply endorsement
by the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in progress.

Introduction

Interactive systems cover a wide range of possibilities, e.g.
the means for controlling a microwave oven, or Web applications
where the user interface runs in a Web browser and is coupled via
HTTP to back-end
services in the network.

Task models provide a goal-oriented description of interactive
systems suitable for reviewing temporal relationships between
tasks, and their decomposition into subtasks, but avoiding the need
for the level of detail required for a full description of the user
interface. This makes it easier to talk through a user interface
design without getting distracted by the details.

Each task describes an activity that has to be carried out to
fulfil the user's goals. Tasks can be represented at various
abstraction levels. When designers only want to specify
requirements on how activities should be carried out, they just
need to consider the main high-level tasks. On the other hand, when
designers aim to provide more precise design indications, then the
activities are represented at a finer granularity, for example,
covering the temporal sequence of tasks to be carried out by the
user or system, as well as any preconditions for each task.

The purpose of this document is to define a standard for
interchange of task models, based on the widely adopted
ConcurTaskTrees (CTT) notation.

CTT is a visual notation for describing task models. Here is an
example for the task of reserving a hotel room:

Figure 1. Example of a Task Model in the
CTT Notation

This specification defines a meta-model and XML schema for
interchange of task models based on the CTT notation, but does not
normatively define how such models should be visualized.

Specific requirements for task meta-model

In this section there are some requirements that have been
specifically identified for task models.

Req1: Separation of static aspects from dynamic aspects

Req2: Separation of the hierarchical structure from other
aspects

Req3: Possibility of relating task performance to the context
of use (even if modelling the context of use is not in the scope of
this document)

Req4: Provide an initial taxonomy of task types (optional
usage)

The requirements are not normative, and rather intended to give the
reader a sense of the assumptions that underlay the notation.

Meta-Model

This section defines a normative meta-model for the task model notation. Tasks have a
hierarchical structure and use the set of temporal operators to
describe the relations between them, which are based on those used
in CTT.

Operators

The operators include both N-ary operators and 1-ary operators.
They are described in the following list:

Interleaving (T1 ||| T2
||| … TN): The connected tasks can be performed
concurrently, without any specific constraint.

Order independence
(T1|=|T2 |=| … TN): the tasks can
be performed in any order;

Synchronisation
(T1|[]|T2 |[]| … TN): The tasks
are concurrent and can exchange information among them;

Parallelism (T1||T2 || …
TN): The tasks are performed in true paralllelism.

Choice (T1[]T2[] …
TN): in this case it is possible to choose one task from
a set of tasks and, once the choice has been made, the chosen task
can be performed

Disabling
(T1[>T2[> … TN): the
left-hand task is deactivated once the right-hand task has
started;

Suspend-Resume (T1 |>
T2|> … TN): The right-hand task interrupts
the left-hand task one. When it is finished, the left-hand task can
be reactivated from the state it was before the interruption.

Enabling
(T1>>T2>> … TN): There
are two cases:

without information passing - when T1
completes it enables T2, when T2 completes it
enables T3, and so forth through TN

with information passing, as before, except
information is passed from each completed task to the next
task

Iteration (T*): the task is performed
iteratively: when it terminates, its execution is started again
from the beginning.

Optional ([T]): the task is optionally
performed.

A comparison of which operators are supported in different task
modelling languages is given in Table 1.

The temporal operators are
all N-ary except iteration and optionality, which are both unary.
The N-ary operator relationship is associated to 2..N subtasks to
model that N-ary operators are associated to the decomposition of a
task into its subtasks. The N-ary operators are associative and
commutative except for disabling, suspend-resume, and enabling,
which are associative but not commutative.

It is also worth pointing out that the operators have different priorities.
For N-ary operators the priority associated to each operator is
expressed by the order in which it appears in the UML class diagram
in Figure 2 (e.g. the choice is the operator
which has the highest priority).

Another key concept (inherited from the CTT notation) is task allocation: how each
task is to be carried out is indicated by the related category and
is explicitly represented using different subclasses for each
category. There are four possibilities:

Task Categories

user task — an internal cognitive activity,
such as selecting a strategy to solve a problem

system task — performed by the application
itself, such as generating the results of a query

interaction task — user actions that may
result in immediate system feedback, such as editing a diagram

abstract task — a task that has subtasks
belonging to different categories, and thus cannot be allocated
uniquely using the previous three categories

Task Types

Designers can also classify tasks according to their semantics,
i.e. by giving each task a type. It is important to note
that each of the above categories has its own predefined set of
task types, thus such sets of predefined task types are indicated
separately in the class diagram, as defined below:

System Tasks

Comparison — the system provides information that is useful for
comparing pieces of information

GenerateAlerts — the system generates an alert

Feedback — the system provides feedback about some intensive
computational activity

Grouping — the system provides pieces of information that are
somehow grouped

Locate — the system provides information useful to locate
something

Overview — the system provides an overview of some data

Interaction Tasks

Single Selection — the user interacts with the system to select
one piece of information

Multiple Selection — the user interacts with the system to
select multiple pieces of information

Edit — the user interacts with the system to change some piece
of information

Control — the user interacts with the system to trigger some
functionality

Zooming — the user interacts with the system to change the
level of detail presented, e.g. zooming on a map or photograph

Filtering — the user interacts with the system to filter how
some data is visualised, e.g. to show some aspects and to hide
others

DetailOnDemand — the user interacts with the system to ask for
some detail on some item

User Tasks

ProblemSolving — the user performs a cognitive activity to
solve a problem

Comparing — the user performs a cognitive activity to compare
pieces of information

Planning — the user performs some activity to plan what to
do

Abstract Tasks

Search Information — the user performs an iterative search for
a piece of information

Additional task types may be used for added flexibility. In
order to model this, each task category has two attributes:
predef_type, which contains the task type when it
is included in the predefined set of tasks already identified;
ext_type, which contains the task type in case a
new task type has to be defined.

Additional Task Properties

It is possible to specify additional information associated with
each task through a number of attributes. For instance, it is
possible to specify the context of use that supports the task
concerned, if there are tasks that are meaningful only for some
contexts of use. Modelling the context of use is out of the scope
of this document.

In addition, for each task it is possible to specify the domain
objects that are manipulated by the task, and whether they are
read-only or can be updated.

Task Meta Model in UML

Figure 2 shows the class diagram
representing the task meta-model. A task model is composed of a set
of tasks; a subtask relation is defined among them, and N-ary
operators are associated with the 2..N subtasks of a task.

Figure 2. Main Aspects of the Task
Meta-model

Each task can be associated with one or multiple domain objects
that it can manipulate. In addition, each task has a number of
properties/attributes: an identifier, the context of use
(indicating what contexts are suitable for its performance),
informal description, and so forth.

Moreover, since the execution of a task is often subject to the
availability of a given resource or depends on the value of a
certain variable, in order to express such dependencies, the
language contains the Precondition and Postcondition classes
(pre-conditions indicate what must be true before the task is
carried out, while post-conditions indicate what will be true after
task execution).

A precondition (which can occur or not as associated to a
certain task, see related multiplicity 0..1 in Figure 2) is an instance of the ConditionGroup class.
It returns a Boolean value, which is obtained by applying the
logical operators to the operands. An operand is a
ConditionLiteral, which can be used to represent values. It can be
either a constant or a variable manipulated during the task
execution. In the former case, the value is expressed by the value
attribute of the ValueLiteral subclass, in the latter it is
expressed by the DomainObjectLiteral class, which represents a
reference to a domain object manipulated by the task itself. An
operand can also be represented in turn by a ConditionGroup, in
order to create complex Boolean expressions. The operators express
the Boolean relation between the operands. An operator can be one
of the following: and, or, xor, contains, stars, ends, greater
than, greater than or equals to, less than, less than or equals to,
equals to, not equals. This hierarchical structure of preconditions
allows the representation of complex conditions.

The same structure is also possible for specifying
postconditions associated to the tasks.

Examples

The example below (see Figure 3) has been
taken from the SERENOA Project. It is about a case study on a car
rental service, which the user can access in order to reserve a
car. To this goal, users have to specify a number of
characteristics they are searching for about the car, also
providing some other information about themselves (name, surname,
address, city..). Then, the user can submit the request and the
service responds with the list of results.

In the following, we will specify the task model as a nested
list of tasks, where nesting is used to model the hierarchy between
parent and children. In addition, for each task we will specify -in
brackets beside its name- the relationship(s) in which the
concerned task is involved.

Please also note that in this example all the tasks are
interactive apart two tasks -Access Service and Show results- which
are application tasks: the first (Access service) models the system
task access the service for doing the search with the parameters
provided by the user; the second one is the system task that is in
charge of showing the results to the user.

Figure 3: A task model example modelled
through CTT notation

1) Make car reservation: this is the
root task

1.1) Enter info (Enter info
Disabling Submit Request: any time during the execution of
the task for entering information, the user can decide to submit
the search request)

1.1.1) Enter car info (Enter car
info Interleaving Enter user info: the two tasks can be
carried out in a concurrent way)

1.1.4) Set Preferences (Enter Other
Info Interleaving Set Preferences)

1.2) Submit request (Enter info
Disabling Submit Request Sequential Enabling with
Info Access Service): The task called “Submit request” can disable
at any moment the execution of the task for entering information.
The execution of the submission of the request also implies that
the parameters are passed to the system task that has to carry out
the search).

1.4) Show results (Access Service
Sequential Enabling with Info Show Results)

XML Schema Definition

Description

The root element of the schema is the TaskModel having a complex
type whose definition includes a group named “categoryGroup”
(indicating the allocation of a task:
user/system/interaction/abstract) and containing an attribute
for specifying its identifier (taskModelID).

The Task element contains all the sub elements and attributes
for the specification of a task. Such element contains the
following elements:

Description: a human-readable task description

Precondition: a structured precondition on the task
execution

Postcondition: a structured postcondition on the task
execution

UnaryOperatorGroup: the unary operators associated with the
task (Iterative: if the task is iterative;Optional: if the task is
optional)

N-aryOperatorGroup: the list of sub-tasks (if any), enclosed by
a tag representing the n-ary operator that connects them

ContextOfUse: the suitable context for carrying out the
task

DomainObject: the list of objects manipulated by the current
task

In addition, it contains the following attributes:

Identifier: a unique task identifier

Name: a human readable task name

Frequency: the task execution frequency

The N-aryOperatorGroup definition contains a choice among
elements representing a different n-ary temporal operator. Each one
of these elements contains the definition of a sub-task list
(SubTask type). Such list is represented by a group that defines
the task category (User, System, Interaction, Abstract) and its
type, according to the class hierarchy defined by the meta
model.

The possible task types have been indicated beforehand.

The ConditionGroup complex type contains one of the following
elements:

ConditionLiteral, which represents a literal value or object
(represented as different elements)

ConditionGroup, which represents an expression of
ConditionLiterals or ConditionGroups (also mixed), as a list of
elements. It contains also the operator attribute that contains the
boolean operator for the expression.

The possible values for the N-ary temporal operators are the
following:

Choice

Interleaving

OrderIndependence

Synchronisation

Disabling

SuspendResume

Enabling

Parallelism

The n-ary operators are repesented as tags that include the
connected sub-tasks. For instance, a sequence of three interaction
sub-tasks is represented with a “Enabling” tag that contains tree
“Interaction” tags.