Task Modeling Notations

The concept of task analysis and modeling as a means to analyze and describe user interfaces is not new. In the following we give a short introduction into task analysis and modeling with a strong emphasis on formal task modeling approaches. A comprehensive overview on concepts, methods and languages of task modeling can be found in [DS03].

Hierarchical task analysis (HTA) was one of the rst methods of task anal- ysis, developed at the University of Hull in the late 1960s by Annett and

4.2 Related Work 35 Duncan. Their goal was to create a rational basis for understanding the skills required in complex non-repetitive operator tasks, especially process control tasks such as those found in steel production, chemical and petroleum re- ning, and power generation [DS03]. HTA describes task models in terms of three main concepts: tasks, task hierarchy, and plans. Tasks are recursively decomposed into subtasks to a point where subtasks are allocated either to the user or the user interface, thus becoming observable. The task hierarchy statically represents this task decomposition. A plan species informally an ordering in which subtasks of a given task could be carried on.

Task models have been applied in dierent contexts. Stanton and Young ap- ply task models in cognitive psychology to improve the understanding how users may interact with a given interface [SY98]. They are also used for task planning and allocation, in order to assess task workload, to plan and to al- locate tasks to users in a particular organization [KA92]. In these areas task modeling has the goal to understand and structure the user interface of a system.

In software engineering, the goal of task analysis is to provide engineering models of human performance [JK96b]. In the ideal, such models produce a useful qualitative description of how the user uses a computer system to perform a task, particularly at an earlier stage in the development process than prototyping and user testing [JK96a].

The used task modeling notations are often informal descriptions without a formal foundation. In order to use task models during development of user in- terfaces there are several approaches that introduce task modeling notations for the early formal description of tasks and their relationships, such as MDL [Sti99], UAN [HSH90], DIANE+ [TB96], and the Concur Task Tree Notation [Pat99]. The goal of these notations is to support the design process of user interfaces by providing a precise description of tasks and their dependencies as well as the ability to generate development artifacts such as code or proto- types. In the following, we introduce the Concur Task Tree Notation in more detail.

Concur Task Trees

The concur task tree (CTT) notation has been developed by Paternò et al. [Pat99, PMM97]. Their goal is to enable the formal modeling of user interfaces in an early development phase. CTT are based on ve concepts: tasks, objects, actions, operators, and roles. Figure 4.3 shows a CTT that describes the tasks of three features: Seat Control, CD and Incoming Call. The task model has been created with the CTT modeling environment CTTE [MPS02]. In the CTT notation, task models are trees where each node represents a task and where the descendants of a task represent its sub tasks. Leaf tasks are called basic tasks and represent atomic actions. CTT supports four dierent types of tasks depending on the involved actors:

User Tasks: are entirely performed by the user.

AIS Adjust Seat* Move Forward [] Move Backward ||| Entertain Listen to CD* Control CD Player Insert >> Control Playback* Play >> Interrupt Playback Pause [] Stop [] Eject []

Insert Corrupt Disc |>

Phone*

Call

Signal Incoming Call [] Select Number Select Address [] Enter Number >> Speak [] Cancel Call

Fig. 4.3. Concur Task Tree.

Interaction Tasks: are performed by the user interacting with the system. Abstract Tasks: are complex tasks, which are divided in dierent subtasks. Temporal operators are used to link sibling tasks on the same level of decom- position. The temporal operators are dened based on LOTOS [BB87]. They connect two adjacent sibling tasks and apply for all subtasks. For example, the task Phone in the case study suspends all subtasks of the task CD. In detail there are the following kinds of temporal relations:

Choice ([]): It is possible to choose between a set of tasks. If one task is active the other tasks from the set can not be selected. For example the user can stop or pause the playback.

Order Independence (| = |): Both tasks have to be performed, but if one task has started, it has to be nished, before the other can start.

Concurrent (|||): Both tasks can be executed concurrently.

Concurrent with info exchange (|[]|): Both tasks can be executed con- currently, but have to be synchronized in order to exchange information. Disabling ([>): When one task is nished, it disables another task. For example if a disc is ejected, the task play disc is disabled.

4.2 Related Work 37 Suspend/Resume (| >>): The execution of a task t1 interrupts the execu- tion of another task t2, which resumes after t1 has nished.

Enabling (>>): If a task nishes, it enables the execution of another task. For example the task insert disc enables the task play.

Enabling with info exchange ([] >>): If a task nishes, it enables the execution of another task with additional information exchange. For example, if a CD is inserted, the playback of the CD is enabled and the track list is exchanged.

Iteration (∗): The task can be performed multiple times.

Actions and objects are specied for each basic task. Objects could be per- ceivable objects or application objects. Application objects are mapped onto perceivable objects in order to be presented to the user. An interesting feature of CTT is that both input actions and output actions associated with an ob- ject are specied. The last modication made to CTT was to add the concept of platform in order to support multi-platform user interface development. Our rst approach of test case generation from task models used the CTT notation [Ben07]. When we tried to describe several features comprising of multiple intentional interactions, CTT did not provide the means of encap- sulating feature-specic tasks due to the constraint that temporal operators are only allowed between sibling tasks. Furthermore, CTTs have a dedicated operator to describe the concurrent execution of two tasks. An AIS, for ex- ample, has a large number of tasks that can be performed concurrently which therefore must all be explicitly dened. Therefore, we decided to create a new task modeling notation that provides a formal foundation which can be used to generate test cases and that provides a concise way to model large systems such as AIS.