Caractéristiques générales

Cette section présente plusieurs caractéristiques générales, applicables à toutes les notations. Nous qualifions ces caractéristiques de générales car elles visent à identifier le périmètre d’une notation sans décrire ses capacités à spécifier l’interaction homme-machine.

1.1.1 Domaine d’origine

Une première caractéristique d’une notation est son domaine d’origine. En effet, une notation permet de décrire un ou plusieurs aspects d’un système selon des concepts et des relations qui sont propres à son domaine. Aussi, identifier le domaine d’origine d’une notation, c’est identifier les concepts sur lesquels elle s’appuie.

Les notations permettant de modéliser l’interaction homme-machine proviennent de plusieurs domaines : psychologie cognitive, ethnographie, ingénierie logicielle, TCAO. Ainsi par exemple, la

notation K-MAD (Kernel of Model for Activity Description) [Lucquiaud 2005, Baron 2006] est issue du

domaine de la psychologie cognitive et vise à décrire les tâches et les objets ayant une influence sur

l’activité de l’utilisateur. La notation CTT (Concurs Task Tree) [Paterno 1997] provient quant à elle du

domaine de l’interaction homme-machine, et propose de décrire l’interaction de manière plus

proche du système que K-MAD. Enfin, une notation comme GTA (Groupware Task Analysis) [Veer

2000] provient du domaine de la TCAO, et est enrichie des apports de domaines comme l’ethnographie dans sa méthodologie et la psychologie cognitive pour la forme de ses modèles et certains de ces concepts.

Nous utilisons cette caractéristique pour classer les différentes notations selon leur domaine d’origine.

1.1.2 Objectif

Une notation peut viser différents objectifs de modélisation. La notation CTT [Paterno 1997] par exemple cherche à répondre à plusieurs objectifs : permettre l’analyse de la tâche, et spécifier des solutions d’interactions, ainsi que servir de support à l’évaluation des modèles produits. Une

notation telle que CUA (Collaborative Usability Analysis) [Pinelle 2003] propose de réaliser l’analyse

de la tâche en s’appuyant sur des mécanismes de collaboration⁵, puis d’effectuer une évaluation

prédictive de l’utilisabilité sur les modèles produits. La notation GTA [Veer 2000] quant à elle repose sur une méthode de travail complète et couvre l’analyse des besoins et la spécification de solutions. La méthode inclut la description de modèles de tâches hiérarchiques pour l’interaction abstraite et la description d’interactions telles que des clics souris pour l’interaction concrète. La spécification de

l’interaction concrète est faite avec la notation NUAN (New User Action Notation) [Venema 1999]. En

termes de cycle de vie logiciel, ces notations sont utilisées pour réaliser l’analyse de la tâche et pour spécifier une solution d’interaction conçue. Les modèles produits peuvent ensuite servir à la génération de code ou de prototype, être embarqués à l’exécution, ou être le support pour des tests ou des évaluations.

Pour cette étude des notations existantes, nous analysons le positionnement des notations selon les grandes étapes du cycle de vie logiciel couverte : analyse des besoins, analyse de la tâche, spécification, conception générale, conception détaillée, et enfin support à la génération de code ou prototype. Nous analysons également la couverture logicielle des notations en termes de composants logiciels du modèle ARCH [Bass 1992] : noyau fonctionnel, adaptateur du noyau fonctionnel, contrôleur de dialogue, interaction abstraite et interaction concrète.

5 Mécanismes de collaboration : ensemble de primitives d’action de groupe définies par les auteurs de [Pinelle

67

Chapitre 2 : Etat de l’art des notations

1.1.3 Nombre et types de vues

Des notations proposent plusieurs vues pour décrire un système interactif. Chaque vue est associée à un ensemble de concepts. Certains concepts peuvent être identifiés au sein de plusieurs vues et être représentés de manière différente dans chacune des vues. Le nombre de représentations et leur type indiquent à gros grain les concepts pris en charge par une notation.

Ainsi, la notation CTT [Paterno 1997] propose une vue unique visant à décrire le modèle de tâche d’un système interactif : il s’agit d’un arbre de tâches. Les concepts secondaires tels que les rôles et les objets utilisés sont décrits au sein de la description de chaque tâche. Lorsque l’on décrit un système coopératif avec CTTE [Mori 2002], plusieurs vues sont définies : un arbre de tâches pour décrire la coopération et un arbre de tâches individuelles par rôle dans l’application. Néanmoins, ces différentes vues forment un seul et unique point de vue sur l’interaction : une description des tâches. Au contraire, la notation MABTA [Lim 2004] propose quatre vues d’une application interactive : un modèle des rôles et des utilisateurs, un diagramme de flot de travail, un modèle de tâches et enfin des maquettes de l’interface graphique.

Enfin, une notation comme GTA [Veer 2000] est elle-même une combinaison de plusieurs notations et permet la description de diagrammes de séquences, de modèles de dialogue NUAN [Venema 1999] et d’arbres de tâches. Ces différentes notations sont autant de vues complémentaires sur un système interactif.

1.1.4 Forme des représentations

Comme nous l’avons souligné précédemment, une notation peut proposer plusieurs vues pour spécifier un système interactif. Chaque vue peut représenter des concepts (parfois identiques) sous une forme différente. Aussi nous nous focalisons ici sur les différentes formes de représentation des vues véhiculées par une notation.

Par exemple le modèle des rôles et des utilisateurs de la notation MABTA [Lim 2004] est représenté sous la forme d’un arbre, tandis qu’un modèle similaire dans la notation TOUCHE [Penichet 2006] est représenté par un diagramme objet relationnel. En effet, la première notation s’intéresse strictement à la modélisation des relations d’héritage et d’instance entre rôles et utilisateurs, tandis que la deuxième s’intéresse à décrire des tâches de coopération entre ces rôles. Certaines notations proposent plusieurs vues ayant une représentation identique, à l’instar des arbres de tâches coopératives et individuelles de CTT [Paterno 1997, Mori 2002]. Pour d’autres notations, telles que la notation CUA [Pinelle 2003], chaque vue adopte une forme différente. Ainsi, les scénarios de CUA sont décrits sous une forme textuelle (à la façon d’une pièce de théâtre). Les modèles de flot de travail sont décrits sous la forme d’un diagramme non hiérarchique reliant plusieurs tâches. Enfin le modèle de tâches adopte une forme arborescente. Enfin, la notation NUAN [Venema 1999] propose de décrire sous la forme d’un tableau des séquences d’actions utilisateur et système. La disposition des actions dans le tableau indique les relations entre ces actions.

Dans le cadre de notre analyse, nous détaillons la forme de chaque représentation proposée par une notation : textuelle, tabulaire, dessin, diagramme. Pour cette dernière, nous précisons la forme du diagramme comme : non hiérarchique, hiérarchique par imbrication ou arborescent.

1.1.5 Outils logiciels

Un point important pour les notations de spécification concerne la disponibilité d’outils logiciels pour accompagner la notation. Les outils logiciels sont utiles car ils structurent le processus de conception et aident le concepteur à comprendre les concepts qu’il/elle manipule [Veer 2000]. L’importance d’outils accompagnant les notations a également été soulignée par [Mori 2002] et [Molina 2009] comme vecteur à l’utilisation et à la diffusion d’une notation. Enfin les auteurs de GTA [Veer 2000] insistent sur la diffusion publique des outils accompagnant les notations de spécifications.

Un outil accompagnant une notation peut être de multiple nature. Nous identifions trois grandes classes d’outils : des éditeurs de spécification, des assistants d’analyse des spécifications produites et des générateurs de code.

Ces éditeurs peuvent être complétés par des outils d’aide à l’analyse des modélisations produites. C’est le cas de l’outil CTTE qui permet l’édition d’arbre de tâches selon la notation CTT [Mori 2002], et qui permet aussi d’animer les spécifications. De même l’éditeur EUTERPE [Veer 2000] qui permet la spécification selon la notation GTA (arbre de tâches, NUAN) est étendu pour couvrir toute la méthode de conception DUTCH et inclut par exemple l’analyse semi-automatique des modèles produits. L’utilisateur de l’outil peut ainsi vérifier des assertions sur sa spécification, telles que la présence d’associations d’au moins une tâche par rôle décrit, qui détecte ainsi la présence de rôles non-utilisés dans le modèle.

Enfin, certain éditeurs de spécification permettent également de générer du code ou des prototypes

à partir de spécifications. L’outil de spécification de diagrammes UML StarUML [StarUML] permet par

exemple de générer des classes décrites au sein de diagrammes de classes UML. L’outil EUTERPE associé à GTA permet quant à lui de générer la spécification au format HTML à partir des diagrammes produits. Chaque tâche y est par exemple décrite sous la forme d’un tableau contenant l’ensemble des propriétés décrites dans l’outil. Cette présentation est plus utilisable lors du développement, puisqu’elle n’impose pas la manipulation de l’outil par les développeurs, mais seulement la consultation des pages web générées.