1. Ancienne définition de MAD

MAD est une Méthode Analytique de Description de tâches orientée Conception d'Interfaces Utilisateur.

Cette définition se retrouve dans de nombreux articles et rapports publiés par Scapin ([Scapin 1988], [Scapin, Pierret-Goldbreich 1989] par exemple). Celle qui semble la plus complète et qui correspond en quelque sorte à “l'état de l'art” est celle trouvée dans [Scapin, Pierret-Goldbreich 1989]. Pour mémoire, nous la rappelons ici.

“Dans le formalisme MAD, les principaux concepts sont ceux d'objet-tâche, d'action, de structure :

Le concept de tâche est représenté par un objet générique (au sens de frame, catégorie, prototype, etc.) appelé objet-tâche (O.T.). Cet objet comporte les éléments suivants :

-  un état-initial (I) : sous ensemble de l'état du monde constitué de la liste des objets, arguments d'entrée de la tâche.

-  un état-final (F) : sous ensemble de l'état du monde constitué de la liste des objets, arguments de sortie de la tâche. Il s'agit des objets directement créés ou modifiés suite à l'exécution de la tâche. Certains objets peuvent naturellement apparaître à la fois en entrée et en sortie.

-  un but (B) : sous-ensemble de l'état-final (B est inclus dans F), indiquant explicitement le but recherché dans l'exécution de la tâche.

-  des préconditions (C.N.) : ensemble des prédicats exprimant des contraintes sur l'état initial et qui doivent nécessairement être satisfaites pour pouvoir déclencher l'exécution de la tâche. On distingue un type particulier de préconditions, les conditions-nécessaires déclenchantes (C.N.D.) qui décrivent des états particuliers qui non seulement doivent être satisfaits pour permettre l'exécution de la tâche mais qui de plus ont un rôle dynamique de déclenchement de la tâche. (condition nécessaire et suffisante à son déclenchement).

-  des postconditions (P.C.) : ensemble des prédicats exprimant des contraintes sur l'état final et qui doivent nécessairement être satisfaites après l'exécution de la tâche. Les postconditions sont des contraintes qui portent sur l'état final.

On distingue deux types d'objet-tâche : l'objet-tâche est donc la racine de deux sous-classes particulières : la classe tâche élémentaire et la classe tâche composée :

-  Une tâche élémentaire est une tâche indécomposable dont le niveau opérationnel est caractérisée par un objet méthode de type simple, c'est-à-dire une action. Une tâche élémentaire comporte donc en plus des éléments précédents un descripteur de l'action à exécuter.

-  Une tâche composée est une tâche dont le niveau opérationnel est défini par une structure décrivant le corps de la tâche. Celle-ci comporte donc un champ supplémentaire structure.

Le concept de structure est représenté par un objet générique caractérisé par un constructeur et ses arguments constitués d'une liste d'objet-tâche. Les constructeurs décrivent l'agencement des différentes tâches impliquées. Certains constructeurs sont prédéfinis :

-  SEQ : tâches séquentielles (par exemple dans le scénario suivant : localiser un fichier, puis déplacer le curseur, puis ouvrir un fichier).

-  PAR : tâches parallèles (par exemple dans le scénario suivant : soit insérer des fichiers déjà constitués, puis rédiger un autre texte, soit l'inverse).

-  ALT : tâches alternatives (une manière ou une autre de faire; par exemple dans le scénario suivant : effectuer un copie soit par commande clavier, soit par désignation d'options de menu).

-  BOUCLE : tâches itératives (par exemple dans le scénario suivant : effectuer des opérations d'insertion de fichier d'un collègue, puis recommencer pour un autre membre de l'équipe).

-  FAC : tâches facultatives (pour les opérations non requises, par exemple ajouter un sigle au rapport d'activité de son équipe).”

Sous l’impulsion de l’expansion des modèles objet en informatique, une deuxième définition, esquissée dans [Pierret-Goldbreich et al. 1989], précisée dans [Hammouche 1993], définit les différents éléments d'une tâche MAD sous forme d'objets. Chaque élément devient un objet à attributs. Ainsi une tâche est un objet avec les attributs suivants : nom de la tâche, type, état initial, état final, préconditions, postconditions, structure de sous-tâches... Chaque attribut regroupe en fait des ensembles d'objets. Ainsi l'attribut préconditions est une liste d'objets de type “préconditions”. Un objet de type “préconditions” a les attributs suivants : nom, type, prédicats. De même les états initiaux et finaux sont des listes d'objets d'un type appelé “objet” qui contient les attributs nom, type...

La définition objet a permis de développer une première implémentation d’un outil d’acquisition et de représentation des tâches orienté objet appellé EMAD [Delouis, Pierret, 1991]. Celle-ci utilisait le langage de frames SHIRKA [Rechenman et al., 1988]. Malheureusement, le langage SHIRKA n’était pas stabilisé et demandait beaucoup de ressources. L’outil EMAD est donc resté limité à une capacité de manipulation de quelques tâches seulement. Néanmoins, l’intérêt de l’approche objet avait pu ainsi être démontré.

Dans le même temps, MAD a été utilisé sur le terrain dans le cadre de l’analyse de l’activité. La définition a alors été interprétée pour satisfaire les besoins des ergonomes. On peut trouver l’essentiel de ces interprétations dans [Sebillotte 1991]. Elles concernent en particulier les définitions des préconditions et du but.

On constate donc la necéssité d’établir une nouvelle définition qui regroupe les conclusions des différents travaux de modélisation et d’utilisation sur le terrain.

2. Nouvelle définition

Ceci est la nouvelle définition de MAD : Méthode Analytique de Description de tâches. Elle se présente comme une précision et une extension de la définition précédente trouvée dans [Scapin, Pierret-Goldbreich 1989]. Elle tient compte des remarques et problèmes rencontrés dans les études d’analyse de tâche utilisant MAD tout en respectant l’esprti initial.

Nous commencerons par préciser certaines concepts utiles pour bien comprendre l’esprit du formalisme :

•  le concept d’objet

•  le concept de prédicat

Ensuite, nous énoncerons les nouvelles définitions des différents éléments origininels de MAD. Chaque paragraphe contiendra la définition de l’élément et des exemples. Si nécessaire, des sous-catégories seront définies. Eventuellement, des remarques seront faites pour préciser certains points et éviter les interprétations. La liste des éléments est la suivante :

•  le but

•  l’état initial

   -  les opérateurs humains

•  l’état final

   -  le résultat

•  les préconditions

   -  état du monde

   -  déclenchantes

   -  opérateur

•  les postconditions

   -  résultat

   -  état du monde

   -  fin de tâche

•  le corps

   -  l’action  élémentaire

   -  la séquence

   -  l’alternative

   -  la parallèle

   -  la simultanée

•  le nom

Puis nous énoncerons les définitions des nouveaux éléments rajoutés ou radicalement modifiées. La liste des éléments est la suivante :

•  la boucle

•  la facultative

•  la priorité

•  l’interruptibilité

•  l’état du monde en cours de tâche.

3. Concepts

Les paragraphes ci-après sont les définitions de concepts assez généraux que sont les objets et les prédicats. Elles sont fortement orientées par l’utilisation que l’on en fait dans MAD, elles ne se veulent donc en aucun cas être exhaustives. Néanmoins, elles permettent d’établir des bases pour faciliter la compréhension du formalisme et limiter les interprétations possibles.

3.1. Notion d'objet

Les objets des états sont des parties du monde et plus particulièrement du monde de l'activité décrite. Pour concrétiser le concept d'objet, on peut dire qu'ils ont généralement la forme d'un groupe nominal ou d'un nom. Ce nom peut représenter un ou plusieurs objets physiques (avion, strip, navire, alarme) ou “abstraits” (environnement, incident), une ou des personnes (pilote, contrôleur, commandant, équipe de sécurité).

L'objet peut être spécifié avec plus ou moins de précision, c'est-à-dire, on peut parler d'une alarme en général ou bien d'une alarme sonore en particulier. La spécificité d'un objet peut apparaître sous la forme d'adjectifs ou de proposition relative mais ils doivent toujours porter sur des caractéristiques statiques de l'objet. Par statique, on entend que ces caractéristiques ne changeront pas pendant l'activité décrite. Ainsi, on peut avoir par exemple l'objet “alarme sonore” car l'alarme va garder son caractère sonore pendant toute l'activité. Dans l'exemple de la tâche de la relève tiré du contrôle aérien, on peut ainsi définir les objets “contrôleur organique relevant” et “contrôleur organique relevé”. Le caractère relevant et relevé des contrôleurs ne va pas changer pendant la tâche et il permet de les distinguer aisément.

D'un autre côté, il est intéressant de regrouper les objets en classes ou catégories. Ainsi pour continuer notre exemple, on pourrait définir la classe “alarme” qui contiendrait des sous-classes “alarme sonore” et “alarme lumineuse”. La classe “alarme” pourrait elle-même être sous-classe de “instrument” et ainsi de suite. Les objets sont alors des instances des classes ainsi définies. Ceci permet de distinguer les niveaux de généralité et permet d'établir une hiérarchie de classes.

.m8.Exemple de hiérarchie d'objets

Par contre, il ne doit pas apparaître de caractéristiques dynamiques sur ces objets. Par dynamique[1], on entend que ces traits décrivent l'état de l'objet à un moment donné de l'activité, ce qui veut dire qu'ils sont susceptibles de changer au cours de l'activité. Ces caractéristiques sont exprimées sous la forme d'attribut.

3.1.1. Attribut

Un attribut[2] est une donnée variable associée à un objet. Le plus souvent, ces données seront de type booléen, c'est-à-dire pouvant prendre comme valeur VRAI ou FAUX. Ce sera par exemple le cas d'un attribut sous forme d'adjectif. Si on considère l'objet “alarme sonore”, on pourra avoir l'attribut “détectée” qui pourra être VRAI ou FAUX.

D'autres attributs pourront être de type énuméré, c'est-à-dire qu'ils peuvent prendre un certain nombre de valeur pré définies. Ce sera par exemple pour l'objet “alarme sonore”, l'attribut “mode de fonctionnement” qui pourra prendre les valeurs “veille”, “éteinte”, ”déclenchée”. Il conviendra lors de la création d'un tel attribut de préciser l'ensemble exhaustif des valeurs possibles.

On peut aussi avoir un type numérique. Pour un objet de type “four”, on pourrait avoir un attribut “température en degrés” qui pourrait prendre des valeurs numériques. Il conviendra lors de la création d'un tel attribut de préciser les limites numériques des valeurs.

D'autres types peuvent être imaginés, bien que ceux décrits ci-dessus dussent suffire à caractériser la plupart des attributs.

Si on observe les arbres existants, on constate que la plupart des attributs sont de la forme booléenne bien que certains d'entre eux puissent être regroupés en attributs énumératifs.

3.1.2. Evénements

Comme on l'a remarqué, un objet a des caractéristiques statiques et dynamiques. Les caractéristiques dynamiques peuvent changer. On appellera événement l'instant de temps bien précis qui correspond au changement de valeur d'un ou plusieurs attributs d'un objet. Un événement peut être de type interne ou externe.

Un événement est dit de type interne si le changement de valeur de l'attribut est du directement à l'activité de l'opérateur. Dans ce cas, les changements de valeur sont explicitement indiqués dans des postconditions résultat.

Un événement est dit de type externe si le changement de valeur de l'attribut n'est pas du directement à l'opérateur. L’événement se produit en dehors du monde local de la tâche ou bien est un “effet de bord” de la tâche courante. Dans ce cas, les changements de valeur ne sont pas explicitement indiqués dans l'arbre des tâches. Ils seront néanmoins indirectement “visibles” dans des conditions état du monde.

On distingue trois catégories d'événements qui marquent la “vie” d'un objet : la création, les modifications et la destruction. Pour chacune des catégories, on montre dans les tableaux suivants la “visibilité” et les changements de valeurs d'attributs.

3.1.2.1. Création

Un événement de création n'arrive qu'une seule fois par objet. La plupart des objets existent avant l'activité. L'événement de création est dans ce cas situé avant l'activité. On place alors l'objet dans l'état initial de la tâche de plus haut niveau pour exprimer que les attributs sont positionnés aux valeurs initiales.

3.1.2.2. Modification

Il peut y avoir plusieurs événements de modification pour un même objet. Il est aussi possible qu'un objet n'ait aucun événement modification. C'est par exemple le cas des objets (du type outils ou information utilisés) n'ayant pas d'attributs, dont seule l'existence nous intéresse. Dans ce cas, les objets apparaîtront uniquement dans les états initiaux.

3.1.2.3. Destruction

Un événement de destruction n'arrive qu'une seule fois par objet. C'est un événement assez rare mais qui mérite d'être cité. Sa particularité est de rendre les attributs de l'objet détruit sans sens. Le seul attribut qui subsiste est “existe”.

Le concept d'objet ayant été précisée, la définition des états devient assez simple. Les états sont des listes de ces objets.

3.2. Notion de prédicat

Cette définition du prédicat se veut volontairement assez restrictive. En effet, le concept de prédicat est beaucoup plus général que ce qui est énoncé ci-après. Néanmoins, pour clarifier et simplifier le formalisme dans un premier temps, il nous a semblé pertinent de rester à ce niveau. La définition orientée objet [Hammouche 1993] utilise la définition complète de prédicat mais demeure compatible avec les définitions suivantes.

Un prédicat est composé d'un objet et d'une contrainte sur celui-ci. Cette contrainte prend la forme de conditions sur la valeur d'un attribut de l'objet. On a explicité le concept d'attribut lorsqu'on a défini le concept d'objet. Ce prédicat a une valeur logique booléenne, c'est-à-dire qu'il est possible d'évaluer un prédicat à VRAI ou à FAUX. Ceci se fait en vérifiant si la condition est satisfaite ou pas au moment de l'évaluation. Si elle l'est, le prédicat est vérifié et sa valeur est VRAI, sinon la valeur est FAUX.

Nous allons maintenant expliciter les différentes formes que peuvent prendre les contraintes. Celles-ci varient selon le type de l'attribut.

3.2.1. Attribut booléen

Pour un attribut de type booléen (VRAI ou FAUX), deux formes sont possibles :

•  = VRAI. Le prédicat est vérifié si la valeur de l'attribut est égale à VRAI.

•  = FAUX. Le prédicat est vérifié si la valeur de l'attribut est égale à FAUX.

 On pourra simplifier leur écriture de la manière suivante :

-  alarme sonore détectée = VRAI  alarme sonore détectée

-  alarme sonore détectée = FAUX  alarme sonore non détectée

On s'approchera ainsi du langage naturel sans perdre le côté formel de MAD.

Ainsi un prédicat pourrait être de la forme suivante :

On veut donc que l'attribut “détectée” ait la valeur VRAI pour que la condition soit satisfaite. On a donc bien un objet, un attribut et une contrainte sur l'attribut.

3.2.2. Attribut énuméré

Pour un attribut de type énuméré, deux formes sont possibles :

•  Î[4] (valeur1, valeur2, …). Le prédicat est vérifié si la valeur de l'attribut est égale à l'une des valeurs de l'ensemble (valeur1, valeur2, …).

•  Ï[5] (valeur1, valeur2, …). Le prédicat est vérifié si la valeur de l'attribut n'est égale à aucune des valeurs de l'ensemble (valeur1, valeur2, …).

Ainsi un prédicat pourrait être de la forme suivante :

3.2.3. Attribut numérique

Pour un attribut de type numérique, de nombreuses formes sont possibles :

•  = valeur. Le prédicat est vérifié si la valeur de l'attribut est égale à la valeur indiquée.

•  ¹ valeur. Le prédicat est vérifié si la valeur de l'attribut est différente de la valeur indiquée.

•  Î(respectivement Ï) [6] d'intervalles. Le prédicat est vérifié si la valeur de l'attribut appartient (respectivement n'appartient pas) à la liste d'intervalles. Ces intervalles pourront être ouverts (notés ]min, max[), fermés (notés [min, max]) ou semi-ouverts (notés ]min, max] ou [min, max[).

Ainsi un prédicat pourrait être de la forme suivante :

Pour d'autres types d'attributs, il conviendra de définir les différentes formes possibles que pourront prendre les contraintes.

On peut aussi imaginer des prédicats qui impliqueraient plusieurs objets. Par exemple : Four1 (objet) température (attribut) > Four2 (objet) température (attribut). Ces contraintes sont de même type que précédemment, elles portent en effet sur des attributs d'objets, elles s'insèrent donc parfaitement dans le formalisme de MAD. Elles sont par contre plus compliquées à représenter. Une possibilité serait :

4.      Définitions des éléments de base

4.1. But

4.1.1. Définition

Il indique explicitement le but recherché et atteint par l'exécution de la tâche. Le but n'a pas d'utilité formelle mais est une aide précieuse à la compréhension de la tâche. Il se présente sous la forme d'un texte écrit en langage naturel sans aucune restriction de style ou de longueur.

On peut retrouver certaines postconditions de résultat, des objets du résultat, des parties du corps de la tâche. Il sert le plus souvent à expliciter de manière détaillée le corps de la tâche.

4.1.2. Exemples

•  Ne plus avoir faim

•  Satisfaire son désir gustatif

•  Eteindre l'incendie

•  Etre prêt à lutter contre l'incendie

•  Faire en sorte que le trafic traverse le secteur sans problèmes particuliers.

•  S'assurer que la position d'un avion correspond bien à la route suivie par rapport au plan de vol.

•  Reclasser les strips selon les critères choisis.

4.2. Etat initial et état final

4.2.1. Définition de l'état initial

L'état initial est une liste d'objets permettant de représenter la partie du monde dans laquelle la tâche va s'exercer et qui va éventuellement être modifiée par le corps. Ils appartiennent à l'environnement de l'activité. En terme “informatique”, ces objets sont les paramètres d'entrée de la tâche.

Le fait de les placer dans l'état initial permet d'exprimer que la tâche a besoin d'accéder à ces objets pour être exécutée. On pose donc à la tâche une contrainte d'existence des objets. C'est une sorte de précondition de la tâche, qui doit avant toute autre chose, vérifier si les objets existent bien. Ce qui veut dire que les objets cités dans l'état initial devront soit, exister indépendamment de l'activité, soit, avoir été créés par une tâche s'étant déroulée avant la tâche courante.

Une autre manière d'exprimer ce qui vient d'être dit est de considérer que chaque objet a au moins un attribut que l'on appellerait “existe”, de type booléen. Celui-ci serait positionné à VRAI au moment où l'objet est créé par l'activité ou bien dès le début si l'objet existe indépendamment de l'activité. Le fait de mettre un objet dans l'état initial veut dire que l'on ajoute implicitement la précondition “objet existe =VRAI”.

On peut distinguer un certain nombre de grandes catégories d'objets. Ces catégories ne sont pas du tout exhaustives. Elles peuvent être elles-mêmes divisées en sous catégories et d'autres complètement différentes pourraient être imaginées. Ces catégories sont :

-  Les objets apparaissant dans les préconditions et/ou le corps. La tâche pourra poser des contraintes sur ces objets dans les préconditions et agir sur eux au niveau du corps. Cela implique réciproquement que tout objet cité dans les préconditions et/ou le corps doit figurer dans l'état initial.

-  Les objets n'apparaissant que dans l'état initial. Ce sont des objets qui doivent juste exister, d'où leur absence dans les préconditions. La plupart du temps, ils n'auront pas d'attributs et le corps ne les utilisera pas explicitement. L'observation des arbres nous indique deux grandes sous-catégories de ce type : les informations et les outils utilisés. Les deux sous-catégories citées sont très importantes dans l'analyse de l'activité, il sera donc utile de distinguer clairement leurs objets. Néanmoins, ils seront inclus dans l'état initial.

4.2.1.1. Opérateurs humains

Dans le cas d'activité impliquant plusieurs opérateurs, il est intéressant de distinguer un sous ensemble intéressant de l'état initial qui est l'ensemble des opérateurs exécutant la tâche. Comme nous l'avons dit précédemment, chaque opérateur est un objet avec éventuellement ses attributs. Dans certaines activités, un groupe d'opérateurs qui conservent une unité de lieu, d'action et d'état pendant toute l'activité et dont les attributs sont globaux, sera aussi considéré comme un objet.

Ainsi, dans l’état initial de chaque tâche, on distinguera un sous-ensemble particulier qui contiendra  la liste des opérateurs pouvant exécuter la tâche.

Ces opérateurs se retrouvent dans les préconditions opérateur qui permettent de déterminer quels seront le ou les opérateurs qui réaliseront effectivement la tâche.

4.2.1.2. Remarques

Il est important de noter que la tâche de plus haut niveau contiendra dans son état initial l'ensemble des objets impliqués dans l'activité et qui existent avant le début de celle-ci. On énoncera ainsi les parties du monde existantes au moment du début de l'activité et qui ont un rapport avec l'activité.

Par suite, les objets des états initiaux des sous-tâches seront soit, inclus dans cet état initial de plus haut niveau, soit, créés par une tâche antérieure à la tâche courante.

4.2.2. Définition de l'état final

L'état final est aussi une liste d'objets permettant de représenter la partie du monde qui a été modifiée par la tâche ainsi que la partie créée par la tâche. En terme “informatique”, ces objets sont les paramètres de sortie de la tâche. On peut distinguer trois catégories d'objets :

-  Les objets qui ont été modifiés par le corps de la tâche. Ceux-ci doivent donc aussi apparaître dans l'état initial. Un certain type de modification mérite notre attention : la destruction ou disparition. Dans ce cas, une post-condition résultat explicite doit apparaître de type “objet existe =FAUX”.

-  Les objets qui ont été créés par le corps de la tâche. Ceux-ci ne peuvent donc pas appartenir à l'état initial, puisqu'ils n'existaient pas avant la tâche. Ils doivent par contre apparaître dans le corps. Le fait de les placer dans l'état final positionne l'attribut booléen “existe” à VRAI, ce qui est équivalent à ajouter une postcondition résultat de type “objet existe =VRAI”.

-  Les objets qui n'apparaissent que dans les postconditions fin de tâche. Ils n'ont donc pas été ni modifiés, ni créés par la tâche en cours.

4.2.2.1. Résultat

La définition du résultat est celle qui était auparavant donnée au but. L'élément but a été modifié. Le résultat est maintenant intégré à l'état final.

Le résultat n'est en fait qu'un sous-ensemble de l'état final. C'est une liste d'objets strictement incluse dans l'état final. Ces objets sont ceux qui définissent explicitement le résultat de la tâche. Dans le cas d'une tâche élémentaire, les objets du résultat seront nécessairement cités dans le corps.

On peut préciser que les objets du résultat appartiennent obligatoirement à une des deux premières catégories d'objets de l'état final décrites précédemment, c'est-à-dire ceux qui ont été créés ou modifiés par la tâche.

4.2.2.2. Remarques

Il est important de noter que la tâche de plus haut niveau contiendra dans son état final l'ensemble des objets qui ont été modifiés ou créés par l'activité. On énoncera ainsi les parties du mondes qui ont été modifiées ou créées à la fin de l'activité.

4.2.3. Exemples d’objets que l’on trouve dans les états

•  gâteau

•  navire en état de marche

•  rapport de l'incident

•  alarme sonore

•  environnement

•  conditions météo

•  écran-radar

•  digitatron

•  fréquence du secteur

•  strips

4.3. Préconditions et postconditions

Les deux types de conditions sont très similaires. Leurs formes sont les mêmes. Il est donc possible de les traiter en partie en même temps. Dans la suite, ce que nous appellerons condition désignera aussi bien une précondition qu'une postcondition. De même, les objets seront respectivement ceux de l'état initial ou de l'état final, selon si on parle de précondition ou de postcondition.

4.3.1. Définition générale des préconditions et des postconditions

Les préconditions (respectivement postconditions) sont un ensemble de prédicats exprimant  des contraintes sur les objets de l'état initial (respectivement de l'état final).

Les conditions sont reliées entre elles par des connecteurs logiques. Par défaut, on considérera que toutes les conditions doivent être satisfaites, c'est-à-dire qu'elles sont liées par un ET logique. Mais on peut utiliser d'autres types de connecteurs logiques (OU, OU EXCLUSIF…). Ainsi, les préconditions ou postconditions d'une tâche pourraient s'exprimer sous la forme :

En résumé, les éléments préconditions et postconditions sont constitués d'expressions de la forme “objet(s), attribut(s), contrainte sur attribut” reliées entre elles par des connecteurs logiques du type ET, OU, OU EXCLUSIF...

Il faut préciser qu'il ne doit jamais apparaître d'actions dans les conditions. Les conditions ne sont que des descriptions de l'état du monde avant et après la tâche. Si l'on est tenté de mettre une action dans les préconditions, on doit créer une nouvelle sous-tâche se trouvant avant dans la logique temporelle des sous-tâches. De même, si on veut mettre une action dans les postconditions, on doit créer un nouvelle sous-tâche se trouvant après dans la logique temporelle des sous-tâches.

Après avoir décrit la forme, il convient maintenant d'expliciter la signification des préconditions et des postconditions.

4.3.2. Préconditions

Les préconditions doivent nécessairement être satisfaites pour pouvoir déclencher l'exécution de la tâche. On les appelle aussi conditions nécessaires.

Alors que l'état initial précise les parties du monde dans et sur lesquelles vont s'exercer l'activité, les préconditions précisent l'état de ces parties du monde au moment du début de la tâche. Si cet état n'est pas vérifié, la tâche ne peut pas s'exécuter. Pour préciser cet état du monde, les préconditions sont exprimées en prédicats sous la forme de contraintes sur les valeurs des attributs des objets.

Il est important de préciser la différence entre le prérequis d'une tâche et les préconditions. Un prérequis est une procédure qu'il faut avoir accomplie pour pouvoir exécuter la tâche. Or, cette procédure est en fait une autre tâche. Cette autre tâche devra être définie entièrement et se situer avant la tâche courante temporellement. Pour s'assurer que la tâche prérequis a bien été effectuée avant la tâche courante, on pourra placer une précondition qui portera sur le résultat de la tâche prérequis. Ainsi, on sera sûr que la tâche prérequis a bien été effectuée avant la tâche courante. On donne ci-après un exemple de prérequis exprimé dans MAD.

.m8.Exemple de prérequis

On distingue trois types de préconditions : les préconditions état du monde, les préconditions déclenchantes et les préconditions opérateurs.

4.3.2.1. Préconditions état du monde

Les préconditions état du monde sont des conditions qui doivent être vérifiées avant le début de la tâche. Elles expriment un certain état du monde pour que la tâche puisse commencer à se dérouler sans problèmes.

4.3.2.2. Préconditions déclenchantes

Les préconditions déclenchantes sont des conditions qui déclenchent une tâche interrompante. Si une tâche avec des préconditions déclenchantes est activée[7], celles-ci sont testées en permanence. Dès le moment où elles sont vérifiées, si la tâche en cours est interruptible, la tâche interrompante est déclenchée et devient la tâche courante. Les préconditions état du monde sont alors testées.

Si une tâche n'a pas de préconditions déclenchantes, on considère qu'elle peut se déclencher dès que possible, c'est-à-dire dès que la tâche parallèle ou simultanée de niveau supérieur est commencée.

4.3.2.3. Préconditions opérateur

Les préconditions opérateur sont des conditions qui peuvent apparaître dans le cas d'activité impliquant plusieurs opérateurs. Elles permettent de déterminer quels seront le ou les opérateurs qui vont effectuer la tâche.

Elles sont assez particulières. D'une part, elles font aussi partie d'une des deux catégories précédentes : état du monde ou déclenchantes. D'autre part, celles qui seront vérifiées détermineront explicitement les opérateurs qui vont réaliser la tâche. Ainsi, à chaque série de préconditions opérateur sera associée un ou plusieurs opérateurs qui seront les exécutants de la tâche.

4.3.2.3.1. Exemple

4.3.3. Postconditions

Les postconditions doivent nécessairement être satisfaites lorsque la tâche se termine.

Alors que l'état final précise les parties du monde ayant été modifiées ou créées pendant la tâche, les postconditions précisent l'état de ces parties du monde au moment de la fin de la tâche. Pour préciser cet état du monde, les préconditions sont exprimées en prédicats sous la forme de contraintes sur les valeurs des attributs des objets.

Il est important de préciser la différence entre le postrequis d'une tâche et les postconditions. Un postrequis est une procédure que l'on doit accomplir après avoir terminé  la tâche courante. Or, cette procédure est en fait une autre tâche. Cette autre tâche devra donc être définie entièrement et se situer après la tâche courante temporellement. Comme l'idée de postrequis exprime que l'exécution d'une tâche doit obligatoirement être suivie par une autre tâche, il suffit de les réunir par un constructeur SEQ. Ainsi on sera sûr que les deux tâches s'effectuent l'une après l'autre. On donne ci-après un exemple de postrequis exprimé dans MAD.

.m8.Exemple de postrequis

On distingue trois types de postconditions : les postconditions résultat, les postconditions état du monde et les postconditions fin de tâche.

4.3.3.1. Postconditions résultat

Les postconditions résultat expriment les modifications de l'état du monde qui sont dues à l'exécution de la tâche courante. Elles correspondent en fait aux résultats visibles d'événements de type interne c'est-à-dire dus à l'activité de l'opérateur.

4.3.3.2. Postconditions état du monde

Les postconditions résultat expriment les modifications de l'état du monde qui ne sont pas dues à l'exécution de la tâche courante. Elles correspondent en fait aux résultats visibles d'événements de type externe, c'est-à-dire non dus à l'activité de l'opérateur. On peut néanmoins les situer temporellement par rapport à la tâche puisque le fait de placer ces événements dans les postconditions signifie qu'on est sûr qu'ils se sont passés avant la fin d'une tâche donnée.

4.3.3.3. Postconditions fin de tâche

Les postconditions fin de tâche expriment les modifications de l'état du monde qui vont arrêter l'exécution de la tâche. Pendant l'exécution du corps de la tâche, les postconditions fin de tâche sont testées en permanence. Dès le moment où elles sont vérifiées, la tâche en cours se termine.

Ces conditions d'arrêt sont souvent indépendantes de la tâche (événements externes).

4.3.4. Exemples

4.4. Le corps

Le corps d'une tâche peut prendre deux formes : une action élémentaire ou une structure de sous-tâches. Nous allons examiner les deux formes possibles.

4.4.1. L'action élémentaire

Le corps est composé d'une méthode  dans le cas d'une tâche élémentaire. Si deux actions sont nécessaires pour une tâche donnée, cela veut dire que la tâche n'est pas élémentaire, elle doit être décomposée en deux sous-tâches élémentaires.

Une méthode prend souvent la forme d'un verbe qui exprime une action. Cette méthode est le plus souvent associée à un ou plusieurs objets. Cette action s'exerce sur le ou les objets associés. Ainsi le corps a la forme “verbe objet1 objet2”.

Il est souvent utile de rajouter des articles et des prépositions pour mieux expliciter l'action. Mais, il est important de faire ressortir la méthode (le verbe sera indiqué en italique) et les objets (ils seront indiqués en gras) impliqués.

Il est à noter que l'activité réelle de l'opérateur est exprimée uniquement dans ces actions élémentaires, c'est-à-dire que toutes les actions observables de l'opérateur devraient pouvoir se retrouver dans les actions élémentaires. Les seules actions que l'on ne retrouverait pas dans les actions élémentaires seraient celles qui consistent pour l'opérateur à vérifier les préconditions ou les postconditions d'une tâche.

Les objets doivent apparaître dans l'état initial s'ils existaient avant l'exécution de la tâche. Si la méthode sert à créer un objet (écrire un rapport) ou à le modifier (éteindre l'incendie), l'objet doit apparaître dans l'état final, normalement dans le résultat. De toute façon, les objets doivent être présents dans au moins un des états.

Une extension possible de MAD qui permettrait une analyse automatique plus fine consisterait à donner des valeurs sémantiques aux différents objets. On pourrait ainsi distinguer les agents, les instruments, les lieux…

4.4.2. Exemples

•  Repérer l'avion à l'écran radar.

•  Envoyer l'équipe de secours sur les lieux de l'incident.

•  Eteindre l'incendie.

4.4.3. Structure de sous-tâches

Une tâche composée est une tâche dont le niveau opérationnel est défini par une structure décrivant le corps de la tâche.

La structure est définie par un constructeur et un ensemble de sous-tâches. Un constructeur décrit l'agencement des différentes sous-tâches.

Nous allons maintenant décrire les différents constructeurs.

4.4.3.1. Séquence SEQ

4.4.3.1.1. Définition

La séquence est la structure la plus simple. Les sous-tâches sont exécutées en séquence, c'est-à-dire, l'une après l'autre dans un ordre donné. Ce constructeur permet d'exprimer des relations temporelles fortes entre les tâches. Ainsi lorsque deux tâches sont dans une séquence, tant que la première n'est pas complètement terminée, on est sûr que la deuxième ne sera pas faite.

Or, lors d'une observation naïve d'une activité, les tâches vont presque toutes paraître en séquence. Il faudra donc bien veiller, lors de la construction de l'arbre de modélisation de l'activité, à distinguer les tâches dont l'ordre d'exécution est contraint et toujours le même, de celles où l'ordre peut varier et être plus ou moins contraint. Parfois, certaines tâches peuvent paraître en séquence si elles sont toujours exécutées dans le même ordre mais il faudra toujours examiner si cet ordre est une routine ou s'il se justifie logiquement ou temporellement.

Les sous-tâches d’une séquence ne peuvent pas s'interrompre entre elles. Ainsi, des préconditions déclenchantes n'auront elles aucun sens dans les sous-tâches d'une séquence. Par contre, la séquence elle-même peut être sous-tâche d'une parallèle. Ainsi les sous-tâches peuvent être interruptibles ou pas par une autre sous tâche de la parallèle.

4.4.3.1.2. Exemple

.m8.Exemple de séquence

4.4.3.2. Alternative ALT

4.4.3.2.1. Définition

L'alternative est une structure permettant d'indiquer une tâche pouvant s'exécuter de plusieurs manières différentes. Il est important de noter qu'une seule des sous-tâches est effectuée. Pour déterminer quelle sous-tâche s'effectue, les préconditions déclenchantes de chacune sont testées. Il est donc nécessaire qu'elles soient mutuellement exclusives, c'est-à-dire qu'il ne soit pas possible que plus d'une sous-tâche n'ait ses préconditions vérifiées au moment du début de l'alternative.

4.4.3.2.2. Exemples

.m8.Exemple d'alternative

4.4.3.3. Parallèle PAR

4.4.3.3.1. Définition

La parallèle exprime que l'ordre des sous-tâches n'est pas contraint à priori et qu'il peut exister des tâches d'interruption. Chaque sous-tâche a un niveau de priorité. Les préconditions des sous-tâches de plus haute priorité sont testées. Si plusieurs sous-tâches de même priorité ont leurs préconditions vérifiées, alors l'ordre d'exécution est déterminé au hasard. Si aucune des tâches de priorité maximale n'est déclenchée, on regarde alors les tâches de priorité juste inférieure et ainsi de suite en descendant dans les niveaux de priorité.

Pendant qu'une tâche interruptible s'exécute, les tâches de priorité supérieure sont dites d'interruption, c'est-à-dire que leurs conditions déclenchantes sont testées en permanence. Si l'une d'entre elles est vérifiée, la tâche courante est alors interrompue et la tâche d'interruption se déclenche. Celle-ci peut être elle-même interrompue par une autre tâche d'interruption de priorité plus élevée et ainsi de suite. Lorsque la ou les tâches d'interruption sont terminées, on examine les conditions de reprise de la tâche interrompue (Cf. § 7.4. pour plus de détails)

Une tâche parallèle se termine quand toutes les sous-tâches non facultatives ont été exécutées au moins une fois ou bien quand les postconditions fin de tâche sont vérifiées.

Il est important de noter que dans le cas d'une structure parallèle, une sous-tâche et une seule est exécutée à un moment donnée. Celle-ci peut être interrompue par une tâche d'interruption mais dans ce cas, elle est suspendue et c'est la tâche d'interruption qui devient active.

4.4.3.3.2. Exemple

.m9.Exemple de parallèle

4.4.3.4. Simultanée SIM

La structure simultanée est une structure très proche de la structure parallèle mais qui implique plusieurs opérateurs[8]. Le fonctionnement est le même que celui de la parallèle à la différence que plusieurs tâches peuvent s'exécuter en même temps.

Dans une tâche simultanée, chaque opérateur éventuellement impliqué dans la tâche vérifie par ordre de priorité les préconditions déclenchantes des sous-tâches qu'il peut effectuer, c'est-à-dire celles où son nom figure dans l'élément opérateur. Si un ou plusieurs opérateurs trouvent des préconditions vérifiées, ils exécutent les tâches en simultané. Les préconditions et les priorités permettent de déterminer le séquencement logico-temporel.

Une tâche simultanée se termine quand toutes les sous-tâches non facultatives ont été exécutées au moins une fois ou bien quand les postconditions fin de tâche sont vérifiées.

Il est à remarquer que les préconditions peuvent impliquer les opérateurs eux-mêmes qui sont alors considérés comme des objets (!) avec des attributs. On peut ainsi représenter un certain type d'interactions entre les opérateurs.

Ce constructeur permet de rendre le formalisme MAD utilisable pour décrire une activité impliquant plusieurs opérateurs. Néanmoins, certaines singularités d'activité multi-opérateurs comme les interruptions ou communication entre opérateurs peuvent être difficiles voire impossibles à exprimer alors que les activités mono-opérateur devraient pouvoir être couvertes quasiment entièrement.

4.4.3.4.1. Exemple

.m9.Exemple de simultanée

4.5. Nom

4.5.1. Définition

Le nom est un identificateur de la tâche. C’est le meilleur descripteur en language naturel de la tâche.

Deux cas sont à distinguer :

•  Tâche élémentaire :       le nom est le contenu du corps.

•  Tâche décomposée :      le nom est un résumé du but. Il peut arriver qu'une tâche décomposée n'ait pas de nom. Cela peut-être le cas lorsque le but est trop compliqué pour pouvoir être résumé en quelques mots. Dans ce cas, on pourra attribuer un nom sur le modèle “sans nom x” avec x un numéro différent pour chaque tâche sans nom.

Chaque tâche se verra aussi attribuer un numéro unique, dépendant de son niveau qui permettra de la distinguer explicitement.

Dans les représentations graphiques des arbres, ce sera certainement la seule information visible. Il faut donc que le nom soit à la fois clair et concis. On peut considérer qu'une dizaine de mots constitue une bonne limite maximale. Des explications plus détaillées seront placées dans le but.

4.5.2. Exemples

•  Faire un repas

•  Manger un gâteau

•  Lutter contre l'incendie

•  Préparer les équipes incendie

•  Surveiller le trafic

•  Vérifier la position au radar

•  Reclasser les strips

5. Autres éléments

Les éléments que nous présentons ci-après sont des extensions au formalisme MAD. Certains d'entre eux reprennent des concepts déjà évoqués dans les travaux précédents sur MAD : boucle, facultative. D'autres sont nouveaux et répondent aux besoins exprimés lors de la réalisation d'arbres : priorité, interruptibilité, état du monde en cours de tâche.

5.1. Boucle

Chaque tâche a un nouvel attribut nommé boucle qui est booléen. La boucle n'est pas un constructeur, c'est une caractéristique supplémentaire de la tâche qui peut être élémentaire ou structurée (SEQ, ALT, PAR ou SIM).

Lorsqu'une tâche est une boucle, elle peut se répéter plusieurs fois. Lorsque la tâche termine une itération, qui correspond à une action, les préconditions déclenchantes sont toujours valables. Ainsi, si aucune tâche plus prioritaire n'est déclenchable (une tâche d'interruption par exemple), la tâche recommence à son début. Et ce, jusqu'à qu'elle soit réellement terminée. Dans ce cas les préconditions déclenchantes seront toujours testées mais jamais vérifiées.

Nous allons maintenant préciser les conséquences pour les différents types de corps de tâches :

•  Tâche élémentaire         : l'action élémentaire est répétée.

•  Séquence                        : toutes les sous-tâches sont répétées en séquence

•  Alternative                     : une des sous-tâches est répétée. La sous-tâche mise en oeuvre peut être différente entre chaque itération.

•  Parallèle                         : les sous-tâches bouclées peuvent s'exécuter plusieurs fois quelque soit la valeur de l'attribut boucle de la tâche parallèle mère. Les sous-tâches non bouclées sont normalement exécutées une seule fois, c'est-à-dire, qu'une fois qu'elles ont été exécutées une fois, leurs préconditions déclenchantes ne sont plus testées. Si la parallèle est bouclée, les sous-tâches non bouclées peuvent être répétées une fois si la tâche mère est terminée et redéclenchée à nouveau.

•  Simultanée                     : idem parallèle.

5.2. Facultative

Chaque tâche a un nouvel attribut nommé “facultative” qui est booléen. La “facultative” n'est pas un constructeur, c'est une caractéristique supplémentaire de la tâche qui peut être élémentaire ou structurée (SEQ, ALT, PAR ou SIM).

Par cet attribut, on exprime qu'une tâche ne va pas obligatoirement être exécutée pendant l'activité mais qu'elle peut être observée dans certaines conditions, Elles ne sont ni bloquantes ni indispensables pour la tâche mais méritent tout de même d'être notées surtout dans une perspective de conception.

Nous allons maintenant préciser les conséquences pour les différents types de corps de tâches :

•  Tâche élémentaire         : pas de conséquences directes.

•  Séquence                        : si une sous-tâche est facultative et si les préconditions ne sont pas satisfaites au moment où elles sont testées, la sous-tâche est purement sautée.

•  Alternative                     : les sous-tâches d'une alternative sont toujours facultatives de part le constructeur. Néanmoins, l’une d’entre elles doit être exécutée.

•  Parallèle                         : si une sous-tâche est facultative, ses préconditions seront testées comme toutes les autres tâches en considérant toutefois qu'elles ont une priorité inférieure aux tâches de même niveau de priorité (!!!). Par contre, les préconditions seront toujours testées pendant toute l'exécution de la parallèle. D'autre part, la parallèle se terminera dès que toutes les tâches non facultatives auront été effectuées.

•  Simultanée                     : idem parallèle.

5.3. Attributs de sous-tâches de parallèle ou de simultanée

Lorsque des tâches sont parallèles ou simultanées, on peut avoir besoin d'exprimer les niveaux de priorité et les interruptions entre les tâches. Pour cela, on introduit deux attributs : la priorité et l'interruptibilité. Ces attributs n'ont une signification qu'au niveau des tâches élémentaires. Dans certains cas explicités dans les définitions ci-après, ils pourront être placés sur des tâches composites.

5.3.1. Priorité

Certaines tâches ont un nouvel attribut nommé priorité qui est numérique. Cela permet d'attribuer des niveaux de priorité entre des tâches parallèles ou simultanées. La priorité permet d'exprimer les deux concepts suivants :

•  L'importance relative des tâches : Bien que l'on ne définisse pas l'ordre à priori de sous-tâches en parallèle, il peut être utile d'exprimer que certaines tâches ont plus d'importance que d'autres ou bien que certaines ont la même importance. En attribuant des niveaux de priorité différents ou égaux, cette notion peut être exprimée.      
D'autre part, pendant qu'une tâche parallèle ou simultanée est en cours, toutes les préconditions déclenchantes sont testées en même temps. Si plusieurs préconditions sont vérifiées au même moment, les priorités permettent d'indiquer celle qui va s'exécuter en premier.                                                                                          
Les tâches de niveau de priorité égal permettent de rendre un ordre indifférent des tâches. Il existe une exception à cette règle dans le cas de tâches de niveau de priorité égal mais dont certaines sont facultatives et d'autres pas. Dans ce cas, on considère que les tâches non facultatives sont prioritaires.

•  Les interruptions de tâche : Chaque sous-tâche élémentaire d'une parallèle ou d'une simultanée peut, si elle est interruptible, être interrompue par une autre tâche. Pour exprimer quelles sous-tâches peuvent interrompre la tâche en cours d'exécution, on utilise la priorité. Toutes les tâches de priorité strictement supérieure peuvent ainsi interrompre la tâche en cours. Il suffit que leurs préconditions déclenchantes soient vérifiées.

Seules les tâches élémentaires, descendantes de parallèle ou de simultanée à un degré de parenté[9] quelconque, ont un niveau de priorité. On peut assigner un niveau de priorité à une tâche décomposée. Dans ce cas, on considère que toutes les sous-tâches élémentaires de niveau inférieur ont la même priorité qui est égale à celle de la tâche décomposée.

5.3.2. Interruptibilité

Certaines tâches ont un nouvel attribut nommé interruptibilité qui est énuméré. Les différentes valeurs possibles de l'attribut sont : non interruptible, interruptible reprise au début, interruptible reprise en cours, interruptible pas de reprise.

Cet attribut permet d'exprimer qu'une tâche peut être interrompue ou pas, par des événements externes. Lorsqu'une tâche est interrompue, son exécution est suspendue. Lorsque la tâche d'interruption est terminée, la tâche interrompue est reprise dans certaines conditions explicitées par la valeur de l'attribut.

Habituellement, seules les tâches élémentaires, descendantes de parallèle ou de simultanée à un degré de parenté quelconque, ont un attribut interruptibilité. Néanmoins, on peut assigner une interruptibilité à une tâche décomposée. Les conséquences sont explicitées ci-après.

Les différentes valeurs que peut prendre l'attribut interruptibilité sont les suivantes :

•  Non interruptible : La tâche ne peut jamais être interrompue quels que soient les événements extérieurs. Cela correspondra par exemple à des tâches très courtes qu'il est impossible d'arrêter en cours.

•  Interruptible pas de reprise : La tâche peut être interrompue par une tâche de priorité supérieure. Si une interruption a lieu, la tâche en cours est arrêtée brutalement. Lorsque la tâche d'interruption est terminée, toutes les préconditions déclenchantes sont de nouveau vérifiées pour savoir la tâche qui va s'exécuter par la suite.

•  Interruptible reprise au début : La tâche peut être interrompue par une tâche de priorité supérieure. Si une interruption a lieu, le travail en cours est perdu. Lorsque la tâche d'interruption est terminée, la tâche interrompue est donc reprise au début.                                                                                                           
Dans le cas d'une tâche décomposée, la tâche en cours est reprise au début, c'est-à-dire en considérant qu'aucune des sous-tâches n'a déjà été effectuée.

•  Interruptible reprise en cours : La tâche peut être interrompue par une tâche de priorité supérieure. Si une interruption a lieu, le travail en cours n'est pas perdu. Lorsque la tâche d'interruption est terminée, la tâche interrompue est donc reprise en cours, où elle en était.                                                                               
Dans le cas d'une tâche décomposée, c'est la sous-tâche qui était en cours qui est reprise.

5.4. Etat du monde en cours de tâche

Chaque tâche a un nouvel élément nommé état du monde en cours de tâche qui se présente sous la forme d'un ensemble de prédicats. L'état du monde en cours de tâche n'est pas une condition, c'est un élément supplémentaire de la tâche qui peut aussi avoir des préconditions et des postconditions.

Par cet élément, on exprime l'état du monde pendant que la tâche s'exécute. Ce sont des attributs d'objets de l'activité qui sont positionnés à certaines valeurs pendant toute la durée de l'exécution de la tâche.

Elles se distinguent des préconditions et des postconditions dans le sens où ces dernières ne sont vérifiées qu'à des instants très précis qui correspondent respectivement au début et à la fin de la tâche. L'état du monde, par contre, est composé de prédicats qui sont vérifiés pendant tout l'intervalle de temps qui correspond à l'exécution de la tâche.

Si la tâche est interrompue, l'état du monde peut éventuellement changer pendant l'interruption et être rétabli lors de la reprise de la tâche.

En terme d'événements, on peut dire qu'un événement modification intervient éventuellement juste au début de la tâche pour positionner les attributs aux valeurs de l'état du monde. On est sûr ensuite qu'aucun événement modification qui serait contraire à l'état du monde, ne surviendra avant la fin de l'exécution de la tâche. D'autres événements de tout type peuvent arriver pendant la tâche.

6. Bibliographie

Alonso B. (1993) : Le partage des tâches entre contrôleurs aériens, Rapport convention INRIA/CENA 91/C.0007.

Delouis I., Pierret C. (1991) : EMAD, manuel de référence, Rapport interne INRIA.

Delsol P. (1992) : Description des tâches de contrôle aérien, amélioration du formalisme MAD, modifications de la description. Prise en compte du partage des tâches entre les contrôleurs, Rapport convention INRIA/CENA 91/C.0007.

El Farouki L., Scapin D.L., Sebillotte S. (1991) : Prise en compte des tâches du contrôleur pour l'ergonomie des interfaces, Rapport convention INRIA/CENA 90/C.0008.

Fallah D. (1992) : Description des tâches selon le formalisme MAD par l'étude des traces : résolution d'incidents maritimes, Rapport de DESS, DEA, INRIA, à paraître.

Hammouche H. (1993) : De la modèlisation des tâches à la spécification d’interfaces utilisateur , Rapport de recherche INRIA à paraître.

Pierret-Goldbreich C., Delouis I., Scapin D.L. (1989) Un outil d'acquisition et de représentation des tâches orienté objet, Rapport de recherche INRIA N°1063

Rechenman F., Fontanille P., Uvietta P. (1988) : SHIRKA, système de gestion de bases de connaissances centrées-objet, manuel d’utilisation.

Richard J.F., Poitrenaud S., Tijus C.A. (1990) : An object-oriented semantic description of procedures for evaluation of interfaces, Proceedings, ECCE-5, Fifth European Conference on cognitive ergonomics.

Scapin D.L. (1988) : Vers des outils formels de description des tâches orientés conception d'interfaces, Rapport de recherche N°893, INRIA Rocquencourt.

Scapin D.L., Pierret-Goldbreich C. (1989) : MAD : une méthode analytique de description des tâches, colloque sur l'ingénierie des interfaces homme-machine, Sophia-Antipolis.

Sebillotte S. (1991) : Décrire des tâches selon les objectifs des opérateurs, de l'interview à la formalisation, Le Travail Humain 54,3 p193-223.