Using Data Flow Diagrams for Supporting Task Models

Abstract. When developing interactive applications, data flow diagrams are onepossible form of task model that focuses on sequencing aspects rather than onstructural aspects of a task to be modelled. As such, they are going against thecurrent of traditional task models which graft sequencing aspects on top ofstructural aspects. The function chaining graph, an extension of data flow dia-grams, is examined as an alternative way of providing a task model that couldserve as a first starting point for deriving other models pertaining to a user in-terface design. Some advantages and disadvantages of this approach are dis-cussed and compared with respect to traditional models.Keywords. Data flow diagrams, Dialogue Model, Model-based approach, Mod-elling activities, Presentation model, Task-based design, Task model, User in-terface design. 1 Introduction Recently, several specification and modelling techniques have been employed to fa-cilitate the development of a user interface (UI) for an interactive application. Amongthese, task models are today widely recognised as a recommended starting point[4,6,815,16].Task models generally try to model two aspects of the task :1. the task structure : task analysis often proceeds by a top-down functional decom-position of a task into sub-tasks, which are, in turn, further decomposed into sub-tasks to end up with procedures, actions and objects. Most task analysis methodsproduce a hierarchical decomposition of task into task units.2. the task sequencing : task analysis also organises identified task units by linkingthem with various sequencing relationships, constraints or operators.Some task models sometimes consist in only one of these aspects (e.g., a structure, asequencing), sometimes superimposes a second aspect on top of a first one (e.g., se-quencing on structure or structure on sequencing), sometimes combine both aspectstogether. For example, the TKS task analysis method [8] creates a tree of task unitsaugmented by pre- and post-conditions for procedures. ConcurTaskTrees [4] consistsin a diagrammatic notation for describing task models. It starts with a hierarchical de-composition of a task into task units. Temporal relationships are then specified be-tween the task units from a set of ten operators : interleaving, synchronisation, ena-bling, enabling with information passing, choice, disabling/deactivation, disabling/deactivation with information passing, iteration, finite operation, and optional task. In