Spécification de l’interaction avec un arbre de tâches

Comme nous l’avons mis en avant dans le Chapitre 2, parmi les notations existantes, nombreuses sont celles qui reposent sur l’utilisation d’un modèle de tâche hiérarchique pour décrire l’interaction. La méthode consiste à décrire une tâche racine, puis de décomposer celle-ci en sous-tâches. Ces dernières sont également décomposées en sous-tâches de plus en plus concrètes jusqu’au niveau des tâches dites élémentaires ou atomiques. Celles-ci correspondent à une interaction élémentaire

sur les concepts de l’application, par exemple Supprimer un document, et ne décrivent pas les actions

de l’utilisateur pour les réaliser, tels que Cliquer sur un document puis Cliquer sur le bouton

supprimer.

• Elle induit une division en modules sur la base des tâches abstraites. En effet, la spécification s’effectue selon une approche descendante (top-down), de la tâche la plus abstraite à la tâche la plus concrète. La division s’opère donc à haut niveau d’abstraction, et sépare l’interaction concrète en module.

• Elle est adaptée à l’activité de conception, puisqu’elle repose sur un processus de

raffinements progressifs des spécifications. De plus, cela maintient un lien très fort entre les tâches de haut niveau d’abstraction correspondant aux fonctionnalités offertes par l’application, et les tâches de plus bas niveau d’abstraction qui correspondent à la mise en œuvre de ces fonctionnalités.

• De plus, elle centralise le lieu des modifications dans les spécifications. Ainsi, une

modification de l’application entraine le plus souvent l’ajout de quelques tâches dans la hiérarchie, et l’ajout de relations temporelles reliant ces nouvelles tâches à celles déjà présentes dans l’arbre.

• Les auteurs de [Caffiau 2009] identifient également le fait qu’ils ne dépendent pas de

technique d’interaction particulière. Ceci car les tâches élémentaires correspondent à des opérations sur les concepts de l’application et ne décrivent pas comment la tâche est réalisée concrètement en terme d’usage de modalité.

Par contraste avec les notations à base modèles de tâches hiérarchiques, plusieurs notations utilisent des diagrammes d’activités : UML [UML], SpieLAN [Bergh 2006] ou des diagrammes de flot de travail : BPMN [BPMN], Orchestra [David 2006]. Au sein de ceux-ci sont représentés des tâches similaires aux tâches élémentaires d’un modèle de tâches hiérarchiques. Les tâches abstraites ne sont pas représentées. Ce type de diagramme brise donc le lien entre interaction abstraite et concrète. C’est pourquoi, le modèle de tâche hiérarchique nous semble plus adapté pour décrire l’interaction, vis-à-vis de nos objectifs.

Parmi les modèles de tâches hiérarchiques, certains adoptent une forme d’arbre : CTT [Paterno 1997], K-MAD [Lucquiaud 2005, Baron 2006], GTA [Veer 2000], tandis que d’autres adoptent une forme à plat : MABTA [Lim 2004], CIAN [Molina 2006]. Dans une forme arborescente, les sous-tâches d’une tâche sont représentées comme ses nœuds fils. Au sein d’une représentation à plat, les sous-tâches d’une tâche sont représentées à l’intérieur de celle-ci. Représenter une décomposition en sous-tâches à l’intérieur des tâches décomposées est intéressante puisqu’elle permet de délimiter des frontières entre des ensembles de tâches. Cependant, lorsque plusieurs niveaux de décomposition interviennent, les représentations à base de rectangles imbriqués deviennent illisibles. En effet, le cadre de tâches de haut niveau devient alors immense, et il est difficile à rattacher visuellement au nom de cette tâche. A l’inverse, une forme arborescente décrit par ses relations père-fils le lien entre des tâches de haut niveau et les tâches feuilles. Il suffit en effet de suivre les relations père-fils en montant pour monter en niveaux d’abstraction, et en descendant pour descendre en niveaux d’abstraction. Aussi, la forme arborescente nous semble donc plus adaptée pour décrire la décomposition de l’interaction.

Parmi les notations existantes, la notation CTT [Paterno 1997] est très utilisée. Elle propose une forme d’arbre n-aires et de nombreux opérateurs pour décrire les relations entre les tâches. Le consensus autour de cette notation est tel que plusieurs autres notations et méthodologies reposent sur l’utilisation de CTT. C’est le cas de CTML [Wurdel 2008a], CIAN [Molina 2006], TOUCHE [Penichet 2006] et du Framework Dynamo-Aid [Clerckx 2005]. Le succès de cette notation peut s’expliquer par :

157

Chapitre 3 : Notation COMM

• L’utilisation de cinq types de tâches clairement identifiés par des icônes (utilisateur,

interactive, système, abstraite et coopérative). Un arbre CTT fait donc apparaître clairement le type de ces tâches ce qui améliore sa lisibilité par rapport à un arbre de tâches tel que celui de GTA [Veer 2000], de CUA [Pinelle 2003] ou de MABTA [Lim 2004].

• La présence de nombreux opérateurs logiques et temporels pour décrire les relations entres

les tâches. Ils permettent d’exprimer des relations communes à toutes les notations telles que la séquence, l’alternative ou le parallélisme, mais également d’exprimer des relations plus particulières tels que suspendre-reprendre, la désactivation ou encore des échanges d’information entre tâches. Ces relations permettent de démarquer CTT de notations telles que K-MAD [Lucquiaud 2005, Baron 2006], ou TaskMODL [Treatteberg 2002].

• Le placement des opérateurs qui permet d’exploiter au mieux la structure n-aires de l’arbre.

En effet, un opérateur CTT se présente comme une relation entre deux sous-tâches et non au niveau d’un nœud, comme cela est proposé dans K-MAD ou GTA. Il est ainsi possible d’utiliser plusieurs opérateurs différents pour une décomposition, tandis qu’avec K-MAD, il faut plusieurs niveaux de décomposition pour décrire la même interaction. Des règles de priorité entre les opérateurs permettent de désambiguïser une décomposition présentant de multiples opérateurs. Les arbres produits peuvent donc être plus concis.

• L’existence de l’outil CTTE [Mori 2002], permettant d’éditer des spécifications selon la

notation CTT est également une contribution importante.

Sur la base de ces constatations, nous choisissons d’adopter pour la notation COMM, la forme d’un arbre de tâches n-aires, et s’appuyant sur un ensemble d’opérateur de la notation CTT. La notation CTT ainsi que ses extensions comme CIAN et le framework Dynamo-Aid présente néanmoins des lacunes vis-à-vis de nos objectifs. Les lacunes identifiées concernent d’une part l’interaction multiutilisateur coopérative et collaborative, et d’autre part l’interaction concrète et notamment l’interaction multimodale.

Les éléments de la notation COMM ainsi que sa structure (pour l’instant équivalente à CTT) sont récapitulés au sein de la Figure 74. Elle comporte ainsi 5 types de tâches différents : utilisateur, système, interactive, abstraite et coopérative. Elle utilise les opérateurs binaires CTT : activation, alternative, désactivation, suspendre-reprendre, concurrence, ordre indéfini, concurrence avec échange d’information, activation avec passage d’information, ainsi que les opérateurs unaires suivants : optionnel, itération et itération finie. Les types de tâches et les opérateurs CTT sont décrits en détail dans le Chapitre 2.

Figure 74 : Eléments et structure de la notation initiale.