ConcurTaskTrees and UML: how to marry them?

Not all UML notations are equally relevant to the design of Interactive Systems; the most important in this respect appear to be Use Case, Class diagrams and Sequence diagrams. In the initial part of the design process, during the requirement elicitation phase, use cases, supported by related diagrams should be used. They have shown to be successful in industrial practise. Use cases can give useful information for developing the CTT model in a number of ways. They identify the actors involved. Such actors can be mapped into the roles of the CTT models. Indeed, CTT allows designers to specify the task model of cooperative applications by associating a task model for each role involved and then a cooperative part describes how tasks performed by one user depend on the tasks performed by other users. In addition, a use case allows the identification of the main tasks that should be performed by users, the system or their interaction. This distinction in task allocation is explicitly represented in CTT by using different icons. Also abstract objects can be identified from an analysis of use cases: during Use Case elicitation, a number of domain objects are also identified, and collected in term of UML classes and relationships; this enables the incremental construction of the core of the domain model which is a principal result of analysis activities.

Next, there is the task modelling phase that allows designers to obtain an integrated view of functional and interactional aspects. Especially, interactional aspects cannot be well captured in uses cases and to overcome this limitation they can be enriched with scenarios, informal descriptions of specific use of the system considered. More user-related aspects can emerge during task modelling. In this phase, tasks should be refined, along with their temporal relationships and attributes. The support of graphically represented hierarchical structures, enriched by a powerful set of temporal operators is particularly important. It reflects the logical approach of most designers, allows describing a rich set of possibilities, is highly declarative, and generates compact descriptions.

The decomposition of the task model can be carried on until basic tasks (tasks associated with atomic actions) are reached. If this level of refinement is reached it means that the task model includes also the dialogue model, describing how user interaction with the system can be performed. If such a level of description is reached then it is possible to directly implement the task model in the final system to control the dynamic enabling and disabling of the interaction objects and to support features, such as context-dependent task-oriented help.

During the task modelling work, the domain modelling is also refined because designers need to associate tasks with objects in order to indicate what objects should to be manipulated to perform each task. There are two general kinds of objects that should be considered: the presentation objects, those composing the user interface, and application objects, derived from the domain analysis and responsible for the representation of persistent information, typically within a database or repository. These two kinds of objects interact with each other. Presentation objects are responsible for creating, modifying and rendering application objects. Given one application object there can be multiple presentation objects (a temperature can be rendered by a bar chart or a numeric value). The refinement of task and objects can be performed in parallel, so that first the more abstract tasks and objects are identified and then we move on the corresponding more concrete tasks and objects.

The association between domain objects and Use Cases can be inherited and further refined for the elements of the CTT model. This exploits the fact that in the CTT it is possible to specify the references between tasks and objects. For each task, it is possible to indicate the related objects, including their classes and identifiers. However, given the number of notations for object modelling existing, no new notation has been introduced for this purpose. Thus an integration with objects modelled with UML class diagrams can be easily and usefully performed.

CTTE, the tool supporting CTT, gives also the possibility of simulating the task model. This means that it is possible interactively select one task and ask the system to show what tasks are enabled after the performance of that task, and then carry on this activity iteratively. A sequence of interactions with the simulator allows designers to identify an abstract scenario, a specific sequence of basic tasks that are associated with a specific use of the system considered. Thus, scenarios can be represented using interaction diagrams that well represent limited sequential activities.

Finally, once the design has been sufficiently developed and analysed, it is possible to obtain the concrete user interface. A number of criteria have been identified [2] to take information in the task model that it is useful to obtain effective user interfaces: grouping of tasks can be reflected in grouping of presentation objects, temporal relationships among tasks can be useful to structure the user interface dialogue, and the type of tasks and objects (and their cardinality) should be considered when the corresponding widgets and presentation techniques are selected.

In conclusion, the rationale for the approach proposed is that in current UML notations it is possible to describe activities by activity diagrams or state chart diagrams (which activity diagrams are a specialisation of). However, these notations have mainly been conceived to describe either high level user work-flow activities, or low level interactions among software objects. They can be used to describe task models or user interactions - some research work in this direction has been done - but the results do not seem particularly convincing. Activity Diagrams do not seem to support well the possibility of multiple abstraction levels which has been found particularly useful in HCI (all successful approaches in task modelling, including HTA, GOMS, UAN share this feature). In addition, they do not seem to scale-up well: when medium-large examples are considered: it is easy to obtain graphical representations rather difficult to interpret. It is possible to define such diagrams hierarchically but then it is not immediate for designers to follow their relationships and obtaining an overall view of the specification.
 
 

3. Conclusions and Discussion