L'approche orientée objet et les réseaux de Petri pour la spécification formelle des tâches

L'approche orientée objet et les réseaux de Petri
pour la spécification formelle des tâches

Dimitri TABARY

LAMIH (UMR CNRS 8530), Université de Valenciennes et du Hainaut Cambrésis

Le Mont Houy BP 311

59304 VALENCIENNES Cedex, France

[e-mail] Tel : [phone]

Résumé — Cet article présente une méthode, nommée TOOD (Task Object Oriented Design) pour le développement d'un système interactif. Nous nous intéressons ici à décrire plus particulièrement son approche de construction de modèle de tâches. Cette approche est basée sur une notation formelle qui donne des résultats quantitatifs pouvant être utilisés par les concepteurs et offre la possibilité d'effectuer des vérifications mathématiques sur les modèles. Le formalisme de modélisation est fondé sur l'utilisation conjointe de l'approche objet et des réseaux de Petri de haut niveau. Les concepts empruntés à l'approche objet permettent de décrire les aspects statiques de tâches et les réseaux de Petri la dynamique et le comportement.

1. Introduction

Plusieurs travaux ont été dédiés à la modélisation des tâches utilisateurs, dans le domaine de la conception des systèmes interactifs (voir par exemple les travaux consacrés aux méthodes: MAD [1], DIANE [2], GOMS [3], TKS [4], Action Theory [5]) pourtant leur utilisation effective est loin d'être une pratique très répandue. L'une des raisons possibles est leur manque d'utilisation de méthodes véritablement formelles qui permettent d'apporter aux modèles de tâches la concision, la cohérence et la non-ambiguïté, [6]. De plus, ces travaux souffrent de leur manque d'intégration dans un processus global de conception couvrant l'ensemble du cycle de vie de l'IHM. Afin de surmonter ces problèmes, les recherches actuelles s'orientent vers un cadre méthodologique qui s'étend de la phase amont de l'analyse de l'activité jusqu'à la phase de spécification détaillée de l'IHM Les méthodes MAD* [7], DIANE+ [8], GLADIS ++ [9], ADEPT [10], TRIDENT [11] vont dans ce sens. Ces méthodologies de conception sont basées sur plusieurs modèles (modèle de la tâche, modèle de l'utilisateur, modèle de l'interface) et assistée par des outils d'implémentation de ces modèles. Nos travaux s'inscrivent dans cette orientation tout en mettant l'accent sur les aspects formels de représentation des modèles et leur transformation tout au long des étapes du processus de conception. La méthode TOOD est fondée sur la représentation que l’utilisateur a de la tâche en dehors des considérations de traitement informatique. Elle utilise l’approche objet et les réseaux de Petri objets pour décrire, d'une part les aspects fonctionnels et la dynamique des tâches utilisateur, et d'autre part les aspects comportementaux de l'IHM et de l'utilisateur pour spécifier comment s’effectuent les tâches. Son formalisme vise à couvrir la totalité du cycle de développement de l’analyse de l’existant jusqu’à la conception détaillée et l’implémentation.

Dans cet article, on se limitera à présenter seulement l'étape de modélisation des tâches avec TOOD, le lecteur trouvera une description plus détaillée de la méthode dans[12].

2. Le cycle de développement TOOD

Le processus de conception TOOD peut être divisé en quatre grandes étapes, figure 1 :

Figure : Cycle de développement de TOOD.

L’analyse du système existant et du besoin s’appuie sur l’activité de son utilisateur, et constitue le point d'entrée et la base de toute nouvelle conception.

Le Modèle structurel de la tâche concerne la description des tâches utilisateurs du système à concevoir. Il permet de décrire, de façon cohérente et complète, la tâche utilisateur. Deux modèles sont élaborés à ce niveau : le modèle statique et le modèle dynamique de la tâche, afin de l’exploiter pour la spécification de l’IHM.

Le Modèle opérationnel permet de spécifier les objets IHM ainsi que les procédures opérateur du système à concevoir. Il exploite les besoins et les caractéristiques du modèle structurel de la tâche pour aboutir à une interface compatible avec les objectifs et les procédures des opérateurs.

La Réalisation de l’IHM concerne l’implémentation informatique des spécifications issues de l’étape précédente.

3. Modèle structurel de la tâche (MST)

Le MST a pour objectif principal d'établir une description, cohérente et complète, de la tâche "future" de l'utilisateur d’une part sous forme structurelle et fonctionnelle (modèle structurel statique de la tâche MSST) et d’autre part sous forme dynamique (modèle structurel dynamique de la tâche MSDT) afin de l'exploiter pour la spécification conceptuelle de l'interface.

1. Décomposition hiérarchique et tâche

La construction de la structure du modèle de tâches est guidée à partir des objectifs fondamentaux de l'utilisateur. Cette construction repose sur les tâches actuelles qui sont traduites et organisées progressivement en une nouvelle tâche qui reflète une autre manière de travailler. Cette manière imaginée peut faire apparaître de nouvelles tâches, un nouveau découpage fonctionnel et des nouveaux rôles opérateurs.

Le modèle structurel permet une décomposition du travail prescrit de l'utilisateur avec le système interactif en éléments significatifs, appelés tâches. Chaque tâche est considérée comme une entité autonome correspondant à un but ou à un sous-but pouvant se situer à différents niveaux hiérarchiques. Ce but reste inchangé dans différentes situations de travail.

Pour parfaire cette définition TOOD formalise le concept de tâches à partir d'un modèle de représentation objet, dans lequel la tâche peut être vue comme un Objet: Classe Tâche. Cette représentation tente par conséquent de modéliser la classe tâche par une structure générique de données cohérente et robuste, permettant de décrire et d'organiser les informations nécessaires à l'identification et la réalisation de chaque tâche.

Ce rapprochement au génie logiciel assure un lien fort entre une spécification centrée utilisateur basée sur des modèles d'ergonomie, et la conception logicielle basée sur le modèle objet

2. Modèle Structurel Statique de la Tâche (MSST)

Dans l'objectif d'identifier et d'utiliser les caractéristiques pertinentes de la tâche à prendre en compte au niveau de l'interface, nous avons associé à une Classe Tâche quatre types de besoins :

• 
  Besoins d'activation : les événements qui, par leur présence, initient et terminent l’exécution de la tâche.
  
• 
  Besoins informationnels : les informations nécessaires à la tâche qui interviennent en entrée et en sortie de la tâche
  
• 
  Besoins de contrôle : les contraintes qui doivent être respectées et vérifiées lors du déroulement de la tâche soit par l'utilisateur soit par l'application elle-même (e. g. les contraintes temporelles, les tolérances d'erreurs, les limites fonctionnelles, etc.).
  
• 
  Besoins Ressources : définissent les rôles opérateurs et applicatifs qui supportent l'exécution de la tâche.
  

Sur cette distinction des besoins, la classe tâche est étudiée comme une entité formée à partir de quatre descripteurs différents : l'Interface d'Entrée, l'Interface de Sortie, les Ressources et le Corps. Chaque classe tâche est définie par deux types de documents graphique et textuel comme le montre la figure 2



Figure : Structure générique de la classe-tâche

Aux descripteurs, nous associons aussi un certain nombre d’identificateurs qui permettent de distinguer la Classe Tâche parmi les autres :

• 
  Un nom, verbe d'action suivi d'un complément (objet traité par la tâche), reflète le traitement à réaliser par la tâche. Il est souhaitable que le nom reprenne le vocabulaire utilisé par les opérateurs de manière à respecter la terminologie lors du développement de l'interface.
  
• 
  Un but donne une explication en langage naturel du but que l'opérateur ou l'application veut atteindre au travers de la tâche.
  
• 
  Un indice identifie formellement de la tâche. Il est formé à partir du numéro de la tâche mère, à laquelle on ajoute le numéro séquentiel correspondant à la dite tâche.
  
• 
  Un type indique la nature de la tâche (humaine, automatique ou interactive)
  
• 
  Une hiérarchie, symbolisé par des petits carrés, définit le nombre de classes-tâches composantes.
  

Le Corps représente l'unité centrale de la classe tâche. Pour les tâches intermédiaires ou hiérarchiques, il donne le schéma de procédures tâches c.à.d les relations logico-temporelles des sous-tâches. Ces relations reflètent, d'une certaine manière, l'organisation du travail de l'utilisateur. Par contre pour les tâches terminales, il définit les procédures d'actions du couple IHM/opérateur. La spécification de ces procédures est réalisée dans le modèle opérationnel de la tâche. Une présentation sommaire de ce modèle est donnée à la fin de ce papier.

Les Ressources représentent les opérateurs humains et/ou les entités du système d'interaction impliquées dans l'exécution de la tâche.

L’Interface d’Entrée représente les données nécessaires à l'exécution de la tâche. Dans un certain sens, ces données constituent les conditions d'exécution à satisfaire obligatoirement au début de la tâche. Elle est composée de trois catégories d'informations : les Déclencheurs, les Conditions contextuelles et les Données d'Entrée.


Tableau : Données de l'interface d'entrée.

	Description
Déclencheurs	Evénements qui provoquent l'exécution de la tâche. Ils sont classés en deux catégories : Les événements déclencheurs formels ou explicites, qui correspondent à des déclencheurs extérieurs. Ils apparaissent de façon observable dans l'environnement du travail (information sur écran, appui sur un bouton, communication, …). Les tâches déclenchées par ce type d'événement sont considérées comme obligatoires. Les événements déclencheurs informels ou implicites, qui correspondent à des déclencheurs provoqués suite à une décision de l'opérateur, à partir d'un ensemble d'informations caractérisant sa situation de travail..
Données d'Entrée	Informations nécessaires lors de l'exécution de la tâche.

L'Interface de Sortie spécifie l'état final de la tâche. Elle est composée de deux types de données : Les comptes-rendus et les Données de Sortie.

Tableau : Données de l'interface de sortie.

	Description
Comptes-rendus	Résultats produits par l'exécution de la tâche. Leur contenu indique les modifications d'ordre : physique et dans ce cas, il désigne la modification de l'environnement (appel applicatif, changement d'état….). mental, désignant la modification ou la nouvelle représentation de la situation par l'opérateur. Les comptes-rendus déterminent ainsi si les objectifs sont atteints ou non et, dans tel cas, la tâche sera reprise après une éventuelle évolution de la situation.
Données de Sortie	Données transformées ou créées par la réalisation de la tâche.

3. Modèles des données du MST

Les ressources, et les informations des interfaces d'entrée et de sortie sont modélisées par des objets, appelés "objets descripteurs" qui ont une structure et un comportement. D'un point de vue informatique, ces objets descripteurs représentent les composants d'une Classe Tâche, mais ils n'ont un sens que s'ils spécifient des objets du monde. Ceci signifie qu'il y a une relation de correspondance entre les objets du domaine et les objets descripteurs d'une classe tâche. D'un point de vue opérateur, ces objets représentent aussi les données par lesquelles il comprend son environnement de travail et élabore une image mentale pour effectuer sa tâche. Par conséquent, ces objets pour les tâches interactives constituent les "Objets Opérateur". Ces derniers auront une existence dans l'image finale du système interactif.

Les classes d'objets descripteurs sont organisées selon une relation d'héritage (généralisation spécialisation) afin de traduire la similitude de structure qui existe entre elles, figure 3.

Ces classes sont définies par :

• 
  Nom : identification de la classe. Chaque classe spécialisée porte le nom qui définit la nature de sa spécialisation.
  
• 
  Indice : référence l'objet de manière formelle.
  
• 
  Description : Explication en langage naturel du rôle de l’objet.
  
• 
  Attribut : indique les caractéristiques que l'on souhaite modéliser en référence aux objets du monde réel.
  

.

Figure : Hiérarchie des classes.

4. Modèle Structurel Dynamique de la Tâche (MSDT)

Le Modèle Structurel Dynamique de la Tâche (MSDT) a pour objectif d'intégrer la dimension temporelle (séquencement, synchronisation, concurrence, interruption) en complétant le modèle statique. Le comportement dynamique de tâches est défini par une structure de contrôle, appelée TCS (Task Control Structure), basée sur un réseau de Petri à objets (RPO) [13], figure 4. Cette TCS décrit la consommation des objets descripteurs de l'interface d'entrée, l'activité de la tâche, la libération des objets descripteurs de l'interface de sortie ainsi que l'occupation des ressources. La TCS est typée par l'ensemble C constitué des six classes d'objets descripteurs C= {DECLENCHEMENT, CONDITION, DONNEE_ENTREE, RESSOURCE, DONNEE_SORTIE, REACTION}.

Figure : Structure de Contrôle de la classe-tâche.

Chaque TCS possède une transition d’entrée t1 et une transition de sortie t2. Les fonctions associées à chaque transition permettent la sélection des objets et définissent leurs répartitions par rapport à l’activité de la tâche.

La transition t1, est composée de trois fonctions: d, b, c

• 
  La fonction de priorité d permet de sélectionner le déclencheur le plus prioritaire pour la tâche. Cette fonction est à la base du système d'interruption. Elle permet d'initier l'exécution d'une tâche, même si une autre tâche moins prioritaire est en cours d'exécution. Cependant l'exécution de la tâche par rapport à ce déclencheur reste conditionnée à la vérification des fonctions de complétude et de cohérence.
  
• 
  La fonction de complétude b vérifie la présence de tous les objets descripteurs relatifs à l'événement observé, c.à.d les données d'entrée, de contrôle et les ressources utilisées pour activer la classe tâche par rapport à un événement de déclenchement donné.
  
• 
  La fonction de cohérence c évalue la recevabilité de ces descripteurs par rapport aux conditions envisagées pour la tâche.
  

La transition t2 possède une fonction de complétude r qui vérifie la présence des données de sortie et des ressources associées aux réactions libérées par le corps

Les tâches hiérarchiques sont considérées comme des tâches de contrôle de leurs tâches composantes. Par conséquent les transitions d'entrée et de sortie de leurs TCS possèdent respectivement une fonction d'émission et une fonction s de synchronisation.

• 
  La fonction définit pour la transition t1 les règles d’émission (constructeurs de la transition d’entrée) d’activation des sous-tâches, ainsi que la répartition des données consommées par ces dernières.
  
• 
  La fonction s définit les règles de synchronisation (constructeurs de la transition de sortie) des sous-tâches.
  

4. Modèle opérationnel (MO)

L’objectif du modèle opérationnel est la spécification de l’interface utilisateur à un haut niveau d’abstraction. Il définit pour ce faire l'interaction entre le Modèle Utilisateur (MU) et le Modèle Local de l'Interface (MLI), pour chaque tâche terminale, en termes d’objets, d’actions, d’états et de structure de contrôle, figure 1.

La description de l'interface finale est spécifiée par un processus d'agrégation de tous les MLI dans le Modèle Abstrait de l'Interface (MAI).

Le Modèle d’Implémentation de l’Interface (MII) est la spécification de bas niveau de la présentation de l’interface finale. La construction de ce modèle s’effectue par la traduction des objets, états, actions et enchaînements du modèle abstrait sous forme d’écrans, menus, fenêtres, icônes en s’appuyant sur un ensemble de critères et règles ergonomiques [11].

5. Conclusion

Nous avons montré dans cet article que l'utilisation de l'orienté objet et des réseaux de Petri objet présente plusieurs avantages pour modéliser la tâche de l'utilisateur. En effet, le modèle de tâches de TOOD, par sa description statique et dynamique, permet la modularité des spécifications, l'expression des interruptions et de la concurrence. L'adjonction des objets descripteurs à l'entité tâche permet un rapprochement à un langage de programmation ce qui simplifie le passage à l'implémentation.

Bibliographie

Scapin, D.L., Pierret-Golbriech, C.: Towards a method for task description: MAD. In Berlinguet L. and Berthelette D. (Eds.). Work whith Diplay Units 89. Elsevier science publishers, Amsterdam, North-Holland (1990) 371-380

1. 
   Barthet, M.F. : Logiciels interactifs et ergonomie : modèles et méthodes de conception, Dunod (1988)
   
2. 
   Card, S.K, Moran, T.P, Newell A.: The Psychology of Human-Computer Interaction. In Lawrence Erlbaum Ass (Ed.). London. (1983)
   
3. 
   Johnson, H., Johnson, P. : Task Knowledge Structures: Psychological Basis and Integration into System Design. Acta Psychologica. North Holland (1991) 3-26
   
4. 
   Norman, D.A: Cognitive enginneering. In Norman, D. and Draper, S. (Eds.). User centered system design: new perspectives on human-computer interaction, Erbawn, New Jersy (1986) 31-61
   
5. 
   Palanque, P. Spécifications formelles et systèmes interactifs, Habilitation à diriger des recherches, université de Toulouse I, France (1997)
   
6. 
   Buisine, A. Vers une démarche industrielle pour le développement d'Interfaces Homme-Machine. thèse, INSA Rouen, France (1999)
   
7. 
   Gamboa, F., Scapin, D.L.: Editing MAD* task descriptions for specifying user interfaces, at both semantic and presentation levels. In Harrison, M.D. and Torres, J.C. (Eds.), Proceedings of DSV-IS'97, Springer-Verlag, Vienne (1997) 193-208
   
8. 
   Tarby, J.C., Barthet, M.F.: The Diane+ Method. In Vanderdonck, J. (Ed.): CADUI'96. Presses Universitaires de Namur, Namur. (1996) 95-119
   
9. 
   Johnson, P., Johnson, H. Wilson, S.: Scenario-based design and task analysis. In Carroll, J.M. (Ed.). Scenario-based design: Envisioning work and technology in system development. Willey (1995)
   
10. 
    Vanderdonckt, J.: Conception assistée de la présentation d'une interface homme-machine ergonomique pour une application de gestion hautement interactive. Thèse, Faculté Notre Dame de la Paix, Belgique (1997)
    
11. 
    Tabary, D., Abed, M.: TOOD: An Object-oriented methodology for describing user tasks in interface design and specification. In La Lettre de l’IA, vol 134 (1998) 107-114.
    
12. 
    Sibertin-Blanc, C. High-level Petri nets with Data Structure. 6^th European Workshop on Petri Net Application, Espoo (Finland), june 1985