Tâches et Tâches&Concepts

Selon notre cadre conceptuel (voir chapitre précédent), le modèle des Tâches et le modèle des Tâches&Concepts sont distincts. Le premier est une description initiale tandis que le second est une description transitoire. Dans ARTStudio, ces deux modèles ne sont pas dissociés. Cette section traite donc de modélisation de tâches et des liaisons entre tâches et concepts. Notre analyse porte en 2.1 sur la structuration de tâche suivie en 2.2 d’une réflexion sur la notion de tâche élémentaire. Puis en 2.3, nous traitons des liens entre tâche et concepts avec la pon-dération de concepts pour terminer en 2.4 avec le formalisme d’expres-sion du modèle.

2.1. STRUCTURE

DESTÂCHES

Il existe de nombreuses façons de décrire la décomposition des tâches et leur enchaînement.

Concernant la décomposition de tâches, tous les formalismes s’accor-dent sur la notion de but et de sous-buts bien que la terminologie varie d’un modèle à l’autre [Balbo 1994].

Concernant l’enchaînement des tâches, on distingue deux approches :

• L’expression explicite des enchaînements au moyen d’opérateurs de séquence (séquence, parallélisme, entrelacement, etc.)comme dans ConcurTaskTree [Paternò et al. 1997] ou MAD [Gamboa et Scapin 1997]

• L’expression implicite des enchaînements de tâches au moyen de post et pré-conditions comme dans PROSPECT [Brisson et Andre 94] ou Diane⁺.

Notons que cette dichotomie est simpliste : [Tarby 1993] montre la possibilité de passer d’une modélisation Diane⁺ en une modélisation avec des relations d’enchaînement ; et MAD inclut aussi des post et pré-conditions.

Nous optons pour une expression explicite des enchaînements qui, selon nous, facilite la projection de l’arbre de tâches en un contrôleur de dialogue.

2.2. TÂCHES

ÉLÉ-MENTAIRES

Lors de la définition d’un arbre de tâches, le bon “grain” des tâches élé-mentaires doit être décidé. Certains modèles, comme PROSPECT avec ses notions d’objectifs, de but, sous-but et tâche finale, fixent quatre niveaux d’affinement tous indépendants des actions physiques de l’uti-lisateur sur les dispositifs d’entrée. D’autres modèles comme UAN (User Action Notation) [Hix et Hartson 1993] et GOMS avec le niveau

107

Avec notre objectif de spécification indépendante de la plate-forme cible, il convient que les feuilles des arbres de tâches soient indépen-dantes des actions physiques. Ces feuilles constituent les tâches élé-mentaires de notre arbre de décomposition.

Définition. Une tâche élémentaire est la plus petite tâche d’interac-tion indépendante de la plate-forme. Si elle devait être décomposée plus avant, on obtiendrait des tâches d’interaction dépendantes de la cible.

Ainsi nous faisons l’hypothèse que toute tâche que l’utilisateur désire réaliser avec l’interface de son application, se décompose en un enchaî-nement de tâches élémentaires. Nous distinguons deux grandes catégo-ries de telles tâches : Les tâches d’utilité publique et les tâches métier qui, elles, sont dépendantes du domaine.

Nous proposons quatre types de tâches d’utilité publique identifiés à partir des interacteurs des boîtes à outils graphiques usuelles. Il s’agit de :

• sélectionner,

• spécifier,

• activer,

• consulter.

Cette catégorisation appelle les remarques suivantes :

• Les tâches d’utilité publique ne sont pas nécessairement mutuelle-ment exclusives. Par exemple, sélectionner est un sous-cas de spéci-fier. Mais nous préférons dire sélectionner pour un menu déroulant ou une liste, et spécifier pour un champ texte. En suivant le précepte “qui peut le plus peut le moins”, un champ texte permettra de faire de la sélection mais au prix d’une perte importante de proactivité (cf. chapitre “Génération et Inférence dans ARTStudio” à la page 142).

• L’ensemble des tâches d’utilité publique ne prétend pas être exhaus-tif — ce serait illusoire. Aussi, le concepteur pourra ajouter à sa con-venance les tâches qu’il jugera utiles lorsqu’il rajoutera de nouveaux interacteurs permettant d’accomplir de nouvelles tâches, et notamment les tâches métier associées à des interacteurs métier.

• Enfin une tâche élémentaire doit être la plus indépendante possible du contexte d’interaction. Ainsi nous dirons Consulter plutôt que Visualiser, qui sous-entend un dispositif de sortie graphique.

2.3. PONDÉRATION

DESCONCEPTS

Lors de la description des tâches, le concepteur doit associer les con-cepts manipulés par chaque tâche. Selon la tâche, certains concon-cepts sont indispensables, d’autres sont simplement utiles.

108

Prenons l’exemple d’un gestionnaire d’énergie de domicile et considé-rons la tâche “changer la température d’une pièce” (cf. figure 6). Pour cette tâche, le nom de la pièce et la température demandée sont de pre-mière importance tandis que la température actuelle est utile, mais pas indispensable. Selon la surface écran disponible (une contrainte de res-sources interactionnelles dépendante de la plate-forme cible), l’IHM rendra directement observables toutes les informations nécessaires et utiles à l’accomplissement de la tâche (cas a) ou bien ne seront obser-vables que les concepts nécessaires, les autres étant inspectables (par exemple, via le bouton “Infos” du cas b).

L’expression des pondérations par le concepteur permet, pour une tâche donnée, la distinction entre concept observable et concept ins-pectable.

Dans une optique de génération multicible, la pondération peut chan-ger. Par exemple, en fonction du lieu de la console de changement de la température, il peut être utile ou nécessaire de rappeler la zone pour laquelle l’utilisateur change la température. Par exemple, s’il existe une console fixée au mur par zone, alors il est inutile de rappeler la zone, sinon c’est nécessaire. Cette description dépendante de l’environne-ment peut s’exprimer sous forme d’une décoration (non gérée actuelle-ment dans ARTStudio), ou se traduire par un deuxième arbre de tâches. Dans notre système de pondération, nous distinguons deux valeurs possibles : requis/complémentaire. Un concept est dit requis pour la tâche si celle-ci ne peut être réalisée sans lui. Un concept est dit complémentaire pour la tâche s’il n’est pas requis et qu’il apporte une aide ou des informations pour la réalisation de la tâche. Cette notion d’information requise ou complémentaire a été introduite par [Sutcliffe 1997] et [Johnson et al. 1993]. Elle est équivalente à la notion d’opération obligatoire et facultative dans Diane⁺ [Tarby 1993].

température demandée : température actuelle : 16 °C

20 °C Changer la température du Salon

Température demandée pour 20 °C température actuelle du Salon : 16 °C Ok Annuler Ok Ok Annuler Infos le Salon :

Figure 6. IHM possibles en fonction de la pondération des concepts du domaine. Selon le niveau de pondération et les contraintes (surface d’affichage disponible) un concept de moindre importance est direc-tement accessible si la surface écran est suffisante (a) ou accessible via une tâche articulatoire (b).

(b) (a)

109

2.4. NOTRE

NOTA-TION

Notre modèle des Tâches&Concepts s’appuie sur la notation Concurr-TaskTree [Paternò et al. 1997]. C'est un modèle des tâches augmenté des concepts manipulés dans les tâches. En l’état de l’implémentation de ARTStudio, la pondération n’est pas utilisée dans le processus de génération.

Définition d’une tâche

Une tâche est définie par :

• un nom ;

• un type (abstraction / interaction) ;

• le type de l’interaction dans le cas d'une tâche d'interaction (tâches élémentaire : consulter / spécifier / sélectionner / activer) ;

• un identificateur (déterminé automatiquement dans ARTStudio) ;

• l’identificateur de la tâche mère (défini automatiquement par ARTS-tudio).

Le lien avec le noyau fonctionnel est défini par :

• un prologue (actions initialisant la tâche) ;

• un épilogue (actions terminant la tâche) ;

• les concepts manipulés dans la tâche.

C’est dans le prologue et l’épilogue que sont définies les nouvelles ins-tances des concepts et sont spécifiés les appels au noyau fonctionnel. Aujourd’hui ce lien avec le noyau fonctionnel est décrit avec le langage cible de l’application (dans notre cas Java). Les prologues et les épilo-gues sont de la forme :

• #NomClasse NomInstance# ;

• #NomClasse NomInstance# = du code ;

• du code ;

Une nouvelle instance de concept est déclarée entre ‘#’ ‘#’. La figure 7 en montre un exemple.

Enchaînement des tâches

Les tâches sont reliées par des liens d’enchaînement temporel. Ce sont les opérateurs Lotos repris dans ConcurrtaskTree. Il existe différents types d’enchaînement dont l'activation avec passage de paramètre qui requiert la spécification du concept transmis en paramètre. Pour chaque lien, sont à spécifier :

• l'identificateur de la tâche de départ ;

• l'identificateur de la tâche d’arrivée ;

• le type du lien (opérateur lotos : entrelacement, choix, activation, activation avec paramètres, synchronisation et désactivation). Les

110

deux derniers types ne sont pas gérés à la génération ;

• et éventuellement l'instance du concept, qui est passée en paramètre. Ce lien définit une relation de parenté entre deux tâches sœurs. On a évidemment :

• une tâche T et sa mère ne peuvent-être sœurs ;

• deux tâches qui n’ont pas la même mère ne peuvent être sœurs. ARTStudio prévient les erreurs en créant les liens automatiquement. Le concepteur peut ensuite modifier le type d’enchaînement. La figure 8 montre un exemple de description de liens entre tâches.

Portée des concepts Etant donné une tâche T et un concept c manipulé par T, la visibilité de c depuis d’autres tâches se définit comme suit :

• c est visible de toutes les tâches filles de T;

• c est visible de la tâche T’ sœur de droite de t, si un opérateur d’enchaînement avec passage de paramètres lie les deux tâches et Figure 7. Interface de spécification d’une tâche dans ARTStudio.

Figure 8. Spécification de l’enchaînement de tâches.

Enchaînement _{Choix du type}

d’enchaînement

Concept passé en paramètre

111

que ce paramètre est c.

Par récursivité sur T’, c peut-être visible dans d’autres tâches. La figure 9 illustre la portée des concepts.