Module IHM : Interaction Homme Machine.

Enseignant: M. LABENI
1. Introduction
2. Obstacles et risques
3. Définitions
3.1 Ergonomie
3.2 Programme ergonomique
3.3 Tâche, tâche élémentaire et décorations
3.4 Le modèle de tâches
3.5 Identification d'une tâche
3.6 Du modèle de tâches à l'IHM
3.7 Conception IHM et génie logiciel
4. Les étapes du processus de développement et IHM
4.1 L'ancrage de l'ergonomie dans le model en V
4.2 Besoins fonctionnels et cahier des charges
5. Le plan qualité et spécifications externes
5.1 Le plan qualité
5.2 Les spécifications externes
5.2.1 Le modèle UAN: User Action Notation
5.2.2 Le modèle HTA: Hierarchical Task Analysis
5.2.3 Le modèle MAD : Méthode analytique de description de tâches.
5.2.4 Le modèle CTT : Concur Task Trees
5.2.5 La méthode Diane+
6. Architecture logicielle des IHMs
6.1 Principe
6.2 Les étapes de développement des architectures logicielles
6.3 Les modèles de référence
7. Les formalismes de validation des IHMs
7.1 Les formalismes à états (diagrammes à états).
7.2 Les formalismes à événements (scénarios).
7.3 Les formalismes hybrides (réseaux de Petri).

1
1. Introduction

La conception des systèmes interactifs telle qu'on la pratique en ergonomie et les processus
de développement du génie logiciel s'effectuent le plus souvent de manière disjointe (une
équipe IHM et une autre pour la conception interne) et lorsque la collaboration existe entre
les équipes partenaires elle souffre de l'absence de support commun (modèles de la tâche,
notations et outils partagés), comme solution à ce problème les hommes du domaine des IHM
ont inventé des nouveaux modèles et méthodes qui prennent en compte l'aspect interactif des
systèmes (applications) par exemples: La méthode Diane+ (modèle de la tâche), le
formalisme UAN (User Action Notation) et le formalisme HTA (Hierarchical Task Analysis)
pour le modèle de tâches et les méthodes Seeheim, H4, MVC, PAC-Amodeus, ..Etc. pour
modéliser l’architecture des systèmes interactifs. Ces solutions sont intégrées aux processus
génie logiciel.

2. Obstacles et risques

La technologie de l'interaction homme machine s'est enrichie récemment d'outils de

développement dites efficaces, parmi ces outils nous citons les générateurs d'interface, tels
Interface Builder, XFace Maker et PyQt (son utilitaire graphique QtDesigner permet de créer
des interfaces Qt) qui permettent de créer des maquettes d'interfaces, ces interfaces sont
supposées faire l'objet d'évaluation avec les utilisateurs présentatifs, d'être modifiées de
manière itérative jusqu'à ce que les critères d'utilisabilité soient satisfaits.

Robustesse: elle vise la prévention des erreurs (augmenter les

chances de succès):
- Les listes de suggestion.
- Les boîtes de dialogue.
- Désactivation des champs après un certain nombre de tentatives.
Utilisabilité = +
Souplesse: elle exprime l'ensemble de choix utilisateur et système:
- Utiliser des icônes au lieu des menus.
- Utiliser des menus contextuels.
- Permettre différentes langues.

Le premier obstacle est donc d'éliminer les ergonomes des équipes de développement sous
prétexte que l'on dispose des générateurs d'interfaces, en effet ces générateurs d'interfaces ne
font pas du développeur un spécialiste en ergonomie. Le second risque est de croire que
l'exploitation sauvage des technologies modernes va permettre d'améliorer les interfaces, ici
on évoque les systèmes à base des réalités virtuelles, les systèmes multimédias mais aussi les
interfaces multi-modales (e.g., Systèmes de sécurité).
Malgré que les progrès des systèmes de reconnaissance et de synthèse permettent aujourd'hui
d'augmenter les capacités sensori-motrices et représentationnelles des applications, il
convient aussi de s'interroger sur leur adéquation aux besoins, aux objectifs et aux
caractéristiques de l'utilisateur (On doit respecter l'aspect ergonomique pendant le
développement de ces applications).

2
3. Définitions

3.1 Ergonomie: elle consiste à améliorer l'interface homme machine, en rendant l'outil le plus
simple et le plus logique possible aux yeux et aux caractéristiques de l'utilisateur.
3.2 Programme ergonomique: est une application utilisable sans avoir à se référer à l'aide en
ligne et diminue au maximum le nombre d'étapes nécessaires à l'utilisateur pour obtenir le
résultat recherché.
3.3 Tâche, tâche élémentaire et décorations:
Une tâche consiste en (voir figure 1) :
• un but (état souhaité) ; et
• une procédure pour atteindre ce but.
Une procédure est un ensemble de sous-tâches liées par :
• des relations de composition ; et
• des relations temporelles.
Une tâche abstraite (i.e., un nœud) est une tâche décomposable en sous tâches ou en tâches
élémentaires (atomiques), une tâche élémentaire (une feuille de l'arbre) est une tâche qui
correspond à une action physique.
Une action physique est une opération sur un dispositif d’entrée/sortie qui provoque un
changement d’état du dispositif (clic, mouvement, affichage, etc.)
Les modèles de tâche sont des structures arborescentes dont les nœuds sont les buts et les
sous-arbres sont les procédures pour atteindre ces buts.

Figure 1 : Décomposition de tâches en sous-tâches.

Les nœuds peuvent être décorés par :

• les concepts du domaine (objets référencés, i.e. paramètres, variables globales ...) ;
• les préconditions et les post-conditions ;
• la fréquence ;
• la complexité ;
• la criticité (niveau de danger, caractère irrévocable) ;
• les contraintes temporelles (durée maximale) ;
• l’acteur responsable de l’exécution de la tâche (utilisateur et/ou système) ;
• toute autre information pertinente (selon le domaine).

3
3.4 Le modèle de tâches: Les modèles de tâches sont des descriptions logiques des activités à
réaliser pour atteindre les objectifs des utilisateurs. Ils se sont révélés utiles pour concevoir,
analyser et évaluer les applications logicielles interactives. Les modèles de tâches décrivent
comment les activités peuvent être réalisées pour atteindre les objectifs des utilisateurs lors de
l’interaction avec l’application considérée.

Ces modèles permettent en général d'exprimer les caractéristiques suivantes:

la décomposition d'une tâche en sous-tâches (avec éventuellement une typologie de tâche)

des relations d'ordonnancement temporel des sous-tâches (séquence, alternative,
parallélisme, etc.)

les objets utilisés pour accomplir une tâche ou une action,

prédire ou expliquer les performances d’un utilisateur dans un environnement donné.

3.5 Identification des tâches: identifier une tâche consiste à :

Identifier l’objectif que cherche à atteindre l’utilisateur lorsqu’il se sert du système.

Identifier les informations dont il a besoin.
Connaître la tâche permet donc de structurer l’interface selon le point de vue de
l’utilisateur.
Pour analyser le besoin des utilisateurs, on procède généralement en deux étapes :

Des interviews qui permettent d’identifier la tâche prévue (ce qui doit être fait)

Cette analyse est ensuite consolidée par l’observation des utilisateurs afin de
comprendre l’activité effectivement réalisée (c-à-d, faire rédiger des scénarios par
des utilisateurs représentatifs, ou à défaut soi-même, et ça permet d’identifier ses
activités).

Tâche
abstraite

Les tâches sont décomposées

en tâches plus simples,
conduisant à des actions
physiques.

Figure 2: Scénario d'un utilisateur.

4
 La connaissance de l’utilisateur permet d’analyser son activité (ce qu’il fait indépendamment
du système). Ces résultats sont consignés sous la forme d’un graphe appelé modèle de tâches.

3.6 Du modèle de tâches à l'IHM:

Le modèle de tâches représenté par un arbre de tâches est segmenté en espaces de travail
(maquette ou interface abstraite), les relations entre les tâches permettent de déduire les
enchaînements entre les espaces de travail. Et l’interface concrète instancie les espaces de
travail en fenêtres ou canevas et le contenu des espaces en objets d’interactions.

Exemple : Soit l’arbre de tâches suivant :

1) La maquette pour des écrans de grande taille :

i) Une seule fenêtre à onglets :

ii) Plusieurs fenêtres

5
 2) La maquette pour des écrans de petite taille

3.7 Conception IHM et génie logiciel: La conception IHM est basée sur l'aspect ergonomique
de l'application par contre la conception génie logiciel est basée sur son aspect fonctionnel:

S'intéresse au côté interactif de l'application:

Style de l'utilisateur (Couleurs, forme des fenêtres

Conception IHM
et boutons ..etc)

Tâches de l'utilisateur

Fréquence des tâches

6
 Comme méthodes de modélisation IHM on cite : Diane+, les formalismes UAN et HTA
(permettant d'élaborer le modèle de tâches de notre IHM) et Seeheim, Arch, H4, PAC, etc
(permettant d’élaborer l’architecture logicielle de notre IHM).

S'intéresse au côté fonctionnel de l'application:

Les différents modules (fonctions, procédures et
Conception Génie
classes)
Logiciel
Intégration des différents modules

Implémentation et tests

Comme méthodes de modélisation génie logiciel on cite: UML, E/A.

4. Les étapes du processus de développement et IHM

4.1 L'ancrage de l'ergonomie dans le model en V:
Le modèle en V convient au développent des systèmes dont le but est bien fixé, pour les
systèmes à risque on adopte le modèle en spirale qui conduit par itérations et incréments à
une solution satisfaisante. En pratique le modèle en V n'est pas suivi à la lettre (il est
extensible) et nous le utiliserons pour sa ressemblance avec certaines méthodes déjà existées
en ergonomie

Figure 3: Les étapes de modèle en V avec l'intégration de l'ergonomie dans le processus de

développement.
La figure 3 montre la structuration du processus de développement du modèle V en étapes,
la pente descendante du V couvre les étapes de transformation progressive du système depuis
la définition des besoins jusqu’à sa production logicielle. Sur la pente ascendante,

7
 chacune des étapes de réification correspond à un ensemble de tests qui permettent de
vérifier et/ou de valider l’étape en regard du code produit.

L’analyse des besoins permet d’établir, en relation avec le client, les services requis du
système et les contraintes de développement. Cette activité donne lieu à un cahier des
charges qui sert de document contractuel entre l'entreprise et le client.

La conception du système consiste à définir une solution matérielle et logicielle qui

répond à l’analyse des besoins et aux contraintes. Cette activité produit des spécifications
externes décrivant notre IHM.

La conception globale constitue l’étape préliminaire orientée vers la mise en œuvre

logicielle: nous quittons l’espace de conception de l’IHM pour pénétrer dans l’espace
logiciel réservé aux informaticiens. La conception globale donne lieu à un dossier
d’architecture logicielle de l'IHM.

La conception détaillée décrit les choix algorithmiques, précise la définition des

procédures et des fonctions, définit les structures de données les plus pertinentes et
spécifie les protocoles de communication. C’est le monde privilégié du programmeur.
Ici, l’ergonome n’a plus sa place! Il n’est plus consulté alors que des décisions
logicielles dirigées par des considérations techniques peuvent avoir un impact néfaste ou
imprévisible sur l’utilisabilité.

Le codage, il s'agit de l'implémentation des solutions dans un langage de programmation

avant de faire les tests unitaires. Ces derniers permettent de vérifier que les composants
modulaires du système répondent chacun à ses spécifications.

Les tests d'intégration servent à vérifier que les modules réalisés indépendamment
interagissent correctement.

Les tests du système servent à vérifier que les éléments de la solution exprimés dans la 2ème
étape sont présents. Ici, nous pénétrons à nouveau dans un espace commun à l’ergonome et
au développeur.
Les tests d’acceptation permettent de vérifier que les besoins exprimés dans le cahier des
charges sont couverts. C’est le dernier contrôle avant la livraison du produit.

Dans de nombreuses entreprises, l’évaluation ergonomique du logiciel n’est envisagée qu’au

niveau des tests d’acceptation. Il est alors souvent trop tard pour l’ergonome de
recommander des modifications profondes du logiciel ( Le coût et les délais sont jugés
trop chers).

4.2 Besoins fonctionnels et cahier des charges (pente descendante)

En ergonomie, les besoins fonctionnels sont identifiés aujourd’hui via des méthodes
bien documentées (CTT: ConcurTaskTrees, Diane+, GTA (Groupware Task Analysis),
dédiée aux activités spécifiques, GOMS: Goal, Operator, Method Selection, MAD, N-MDA :
Noyau du Modèle de Description de l’Activité (ou K-MAD : Kernel of Model for Activity
Description), UAN, et les use case models d’UML ..) (L.Sanou et al., 2007). Ces méthodes

8
centrent l’analyse sur l’utilisateur et ses activités, alors que les méthodes adoptées par les
informaticiens ignorent ce côté pour ne modéliser que les services et les fonctions internes du
système (noyau fonctionnel). Il convient de ne pas sauter cette étape : il faut au préalable
représenter explicitement l’ensemble des tâches à réaliser, puis dans un second temps,
identifier celles qui devront migrer vers le système (ajouter, modifier, etc.), et celles dont la
migration sera négociée dynamiquement à l’exécution du système par l’utilisateur c à d,
représentant un changement dynamique de l’acteur responsable de l’accomplissement de la
tâche par exemple : les valeurs par défaut, la détection de tâches répétitives puis prise en
charge, la sauvegarde automatique de fichiers … etc.

De même, les informaticiens ignorent les critères de fréquence d’une tâche, de

complexité, de relations temporelles, et ça mène à une perte d’information entre les
notations utilisées par les ergonomes et celles adoptées par les informaticiens( basant
sur des représentations formelles telles UML, SADT et OMT). Pour cela les spécialistes
de l’ergonomie recommandent de spécifier explicitement le modèle de tâches dans le cahier
des charges. Et pour délimiter les problèmes, il peut être utile de développer une maquette.
Le maquettage est convaincant dès les premières étapes du processus de développement:
il engage d’emblée le client dans le processus de développement.

Figure 4: Modèle en V avec des exemples des modèles IHM conçus pour chacune de ses
étapes.

D’autres contraintes doivent être spécifiées dans le cahier des charges et notamment :
- le guide de style (il convient de ménager les habitudes du client),
- la portabilité de l’IHM sur différentes plates-formes (Linux, Windows , Macintosh, etc.) et
aussi sur différents équipements portables,
- la globalisation du logiciel et sa capacité de localisation, c’est-à-dire son adaptation aux
différentes cultures et langues vernaculaires (le caractère international d’un logiciel va
bien au-delà simple traduction linguistique, il doit prendre en considération la culture et les
traditions des peuples).

9
5. Le plan qualité et spécifications externes (pente ascendante)
5.1 Le plan qualité
Le plan qualité, qui fait généralement partie du cahier des charges, englobe les tests
d’évaluation du V. Il précise la qualité requise, les métriques et les moyens de mesure.
McCall était le premier qui caractérise la qualité de l’IHM en termes de facteurs et de
critères. Parmi ces facteurs, nous relevons l’utilisabilité. Cette dernière est évaluée au
moyen de deux mesures: le guidage (souplesse) et l'opérabilité (robustesse). Ensuite les
spécialistes de l'ergonomie ont orienté la notion de l'utilisabilité vers un ensemble de
propriétés précises (critères précis) telles:

L'observabilité (Rob.): elle exprime la capacité pour l'user d'explorer l'état interne du système
au moyens de commandes articulatoires (ou passives) (c'est-à-dire qui ne modifient pas l'état
du noyau fonctionnel) telles que zoom, défilement, etc.
Adaptabilité (Soup.): capacité du système à s'adapter à l'user sans intervention explicite de sa
part.
Plasticité (Soup.): capacité du système à s'adapter aux variations des ressources
interactionnelles et de calcul tout en conservant la continuité ergonomique. Exemple : IHM
d'un agenda sur smart phone ou sur PC.
Révisabilité (Rob.): Capacité pour l'user de réviser un message avant de l’émettre.
Atteignabilité (Soup.): Capacité du système à permettre à l'utilisateur de naviguer dans
l’ensemble des états observables du système. Un état q est atteignable à partir d’un état p s’il
existe une suite de commandes { ci } qui font passer de l’état p à l’état q.
Ces propriétés sont pertinentes à la fois pour les tests d’ergonomie et la conception
logicielle. Nous allons voir leur intégration dans les modèles conceptuels d’architecture
tel PAC-Amodeus. Ces modèles, qui concernent l’étape de conception globale du système,
jouent le rôle de charnière entre la conception ergonomique et la conception logicielle (Il est
donc important qu’ils véhiculent les bonnes propriétés).

5.2 Spécifications externes

Les spécifications externes désignent la spécification de l’IHM. Dans les pratiques
actuelles, l’IHM est sous-spécifiée. Le document de spécifications externes rassemble des
dessins d’écrans complétés par des commentaires en langue naturelle. Les détails sont passés
sous silence, la dynamique de l’interaction est difficile à évaluer et l’imprécision de la
description laisse place à l’interprétation. Les risques sont clairs:
- La découverte de défauts au moment des tests d’acceptation,
- La non-conformité entre les spécifications externes et le produit final.

Deux outils possibles pour résoudre le problème: faire appel au maquettage et à la

formalisation.
- Une maquette peut raisonnablement servir de spécifications externes. Elle doit résister
à la tentation de la modifier jusqu’à la version livrée. Cette approche exploratoire est
acceptable pour de petites applications.
- La formalisation est une approche plus sûre que le maquettage : le formalisme, s’il est bien
adapté au problème, donne les bonnes solutions. Par exemple le formalisme UAN dont le
format tabulaire permet de mettre en regard les actions de l’utilisateur et les réactions

10
 du système et d'augmenter la qualité du processus de développement mais il exige une
équipe pluridisciplinaire.

Les étapes des méthodes de conception centrées utilisateur sont:

1) Analyser l’activité des utilisateurs

2) Identifier les concepts (contexte)
3) Énumérer les opérations (tâches)
4) Organiser ces opérations (hiérarchie de tâches)
5) Décorer les tâches
6) Évaluer la décomposition (si nécessaire, raffinement de la hiérarchie).

5.2.1 Le formalisme UAN: User Action Notation

UAN signifie la notation des actions d'utilisateur, ce formalisme est prévu pour être écrit
principalement par quelqu'un qui modélise les composants interactifs d'une interface c.-à-d.
un ergonome, et pour être lu par tous les développeurs, en particulier ceux qui implémentent
le noyau fonctionnel d'une application.
L'UAN est un mécanisme utilisé pour décrire la conception d'une IHM qui doit être : Précise,
concise (brève), non ambigüe et détaillée.

Description de l'UAN:

L'interaction (ensemble de tâches utilisateur) est modélisée par des notations sous
forme de tables.

L'UAN représente le comportement User-Interface comme ils accomplissent une
tâche ensemble.

Basé sur la tâche comme élément primaire d'analyse.

L'interface compète est vue comme une hiérarchie des tâches non ordonnées.

Le niveau le plus bas d'une description UAN représente :
o L'action utilisateur (User Actions)
o La réaction du système (Interface FeedBack)
o Le changement d'état (Interface State)

À tous les niveaux, les actions et les tâches utilisateur sont contraintes par les relations
temporelles suivantes: Ordonnancement, imbrication et simultanéité (tâches parallèles) et
complétées par des scénarios (séquence d'images écrans) plus des diagrammes de transitions
d'états.

Syntaxe UAN: les tâches sont décrites sous forme tabulaire comme suit:

Task: <Name>
User Actions Interface FeedBack Interface State

Éléments d'UAN:
Les actions:

11
Table 1 : Les symboles modélisant les actions de l’utilisateur

Le Feed-Back : la réaction de l’interface

Table 2 : Les symboles modélisant les réactions du système

Plus de formalisme:
݇: Saisie des caractères (Keyboard).
݇"ܿ‫"ݕ݌݋‬: Commande littérale (ligne de commande).

12
݇(݂݈݅݁݊ܽ݉݁): Saisie du nom d'un fichier.
݇(‫ܣ[( = ܦܫ ݎ݁ݏݑ‬, ܼ]|[‫ܣ‬, ܼ − 0, 9])ା ): Expression régulière pour contrôler la saisie.
∼ ሾ‫ݔ‬, ‫ݕ‬ሿ∗ : Un nombre arbitraire de répétitions (inclut 0), exemple: déplacer un objet.
∼ ሾ‫ݔ‬, ‫ݕ‬ሿା : Un ou plusieurs, on peut spécifier.

݂݈݅݁_݅ܿ‫!݊݋‬: Fichier éclairé (file icon highlights)

݂݈݅݁_݅ܿ‫ ݊݋‬− !: Fichier ignoré (file icon unhighlights)
ܽ‫!! ݊݋݅ݐ݈ܽܿ݅݌݌‬: Application éclairée différemment (application file highlights differently).
݂݈݅݁_݅ܿ‫݊݋‬′: Icône sélectionnée.
¥ : Pour tous les objets.
¬ : Non logique.
= : Égalité.
∗ : Différent.
: : Séparation entre conditions et actions.

Exemples:
a) Actions utilisateur:

La description de la tâche ‘Sélectionner un fichier’ (dans cet exemple seulement la partie des
actions est considérée), cette tâche peut être décrite informellement par:

(1) déplacer le curseur vers l’icône du fichier;

(2) presser et immédiatement relâcher le bouton de la souris.
La partie action de l’user de la description UAN pour cette tâche est:
(1) ~[file_icon]
(2) M ∨∧
Et la description informelle pour la tâche ‘Déplacer un fichier’, est la suivante :
(1) Déplacer le curseur vers le fichier. Presser et maintenir le bouton de la souris en bas.
Presser le bouton de la souris permet de sélectionner le fichier, indiqué par la mise en valeur
de son icône.
(2) Avec le bouton en bas, déplacer le curseur. L’aperçu du ficher suit le curseur comme
nous le déplaçons dans l’écran.
(3) Relâcher le bouton. L’icône du ficher est maintenant déplacée à la place où nous
relâchions le bouton.
Les actions utilisateur de la description UAN correspondante est comme suit:

(1) ~ [file_icon]M ∨
(2) ~ [x, y]∗ ~ [x ᇱ , y′]
(3) M ∧

b) Sélectionner un fichier:

Task: Select file

User Actions Interface Feedback Interface State
~[file_icon] Mv file_icon !
¥ file_icon * file_icon' : file_icon-! selected = file
M^

13
 c) Supprimer un fichier:

Task: Delete file

User Actions Interface Feedback Interface State
~[file_icon] Mv file_icon-! : file_icon'! selected = file
¥file_icon * file_icon' : file_icon-!
~[x,y]+ outline( file_icon') >~
~[trash_icon] outline( file_icon') >~
trash_icon!
M^ erase( file_icon') selected = null
trash_icon!! Or trash_icon-!

5.2.2 HTA (Hierarchical Task Analysis)

Le modèle HTA est l’une des premières notations utilisées pour la collecte d’informations
sur les activités de l’utilisateur. Sa capacité d’abstraction (représentation des taches
abstraites) est réalisée par la décomposition hiérarchique des tâches en sous tâches, HTA est
une notation qui admet une description graphique (et une autre textuelle) de la représentation
des informations liées aux activités de l’utilisateur. En HTA, l’ordonnancement de taches et
sous taches est connu sous le nom de « plan ». Ce plan, requis pour tout nœud possédant des
sous-tâches (sous-buts), il montre comment il faut utiliser lesdites sous-tâches pour réaliser le
but ou la tâche du nœud associé. Ces plans, dont le langage n’est qu'une partie formelle,
permettent d'expliquer les instructions nécessaires, mais peut rendre difficile l’utilisation
d’outils de validation ou de simulation.

Dans le formalisme HTA les tâches sont numérotées hiérarchiquement. En général, les analystes
adoptent les conventions suivantes :

La racine porte le numéro « 0 ».

Les sous-tâches de la racine portent un nombre entier (« 1 » pour le plus à gauche et
successivement en allant vers la droite).
Les sous-tâches de tous les autres nœuds portent un numéro qui résulte de la concaténation du
numéro du parent, d’un point et d’un nombre entier (« 1 » pour le plus à gauche et
successivement en allant vers la droite).

Les énoncés disponibles pour les plans d'une HTA sont:

14
Table 3 : Les opérateurs HTA

L'exemple suivant représente l'activité «faire du café» selon la notation graphique de HTA. Dans cet
exemple l'enchainement des tâches est claire : mettre le café, ensuite de l’eau et en fin pousser ON:

15
 HTA suivante représente la tâche "Envoyer un courriel":

Au besoin

Comme tout arbre, une HTA peut être représentée sous la forme d’un tableau. La forme
tabulaire (ou textuelle) de l'exemple précédent, on peut noter que, par l’ajout de colonnes
supplémentaires au dit tableau, il est facile de montrer autant de propriétés que souhaité.

16
5.2.3 Le formalisme MAD: Méthode Analytique de Description de tâches
MAD comme HTA est une méthode basée sur une décomposition hiérarchique de tâches.
Dans sa forme, MAD diffère de l’HTA par la description de chaque nœud de l’arbre
d’analyse qui implique la quantité d’information à fournir pour chaque but (ou tâche)
identifié dans la décomposition hiérarchique.
Dans MAD et pour chaque nœud (but ou tâche) il faut entrer les informations suivantes
(indiquées dans la figure 5):

Des informations identifiant la tâche, incluant :
o un nom et un numéro;
o son but (en langue naturelle).

Différentes informations spécifiant les conditions d’exécution de la tâche, incluant :
o l’état initial, soit l’ensemble des objets représentant le monde dans lequel la tâche va
s’exécuter et qu’elle pourra ou non modifier;
o les préconditions, soit un ensemble de prédicats exprimant des contraintes sur les objets
de l’état initial qui doivent être réalisés pour que la tâche puisse commencer;
o le corps de la tâche, qui est une tâche élémentaire (donc, simple, indécomposable ou
dont l’analyse est jugée suffisante) ou alors un ensemble de sous-tâches avec une

17
 structure indiquant comment exécuter lesdites sous-tâches. Cette structure devant être
l’une des valeurs suivantes :

Figure 5: Description d'une tâche selon MAD.

• SEQ : si les sous-tâches doivent être exécutées séquentiellement;

• ALT : s’il faut ne choisir d’exécuter qu’une seule des sous-tâches;
• PAR : si les tâches doivent être exécutées en parallèle par une seule personne;
• SIM : si les tâches doivent être exécutées simultanément par plusieurs personnes;
• ET/OU : elle est utilisée pour indiquer que l’on peut exécuter autant de tâches que
désiré ou nécessaire;

o l’état final, soit l’ensemble des objets qui pourraient avoir été créés ou modifiés par la
tâche, ainsi que ceux qui doivent exister après son exécution;
o le résultat, soit un sous-ensemble strict de l’état final qui contient tout ce que la tâche a
créé ou modifié;
o les postconditions, soit un ensemble de prédicats exprimant des contraintes sur les
objets de l’état final qui sont assurément réalisés lorsque la tâche se termine.

Divers attributs affectant l’exécution de la tâche, incluant :
o FAC : lorsque la tâche est facultative;
o @ : lorsque la tâche peut être répétée;
o PRIOR et INTER : les paramètres définissant l’interruptibilité d’une tâche (en
spécifiant une priorité d’exécution qui sera comparée à celle des autres tâches voulant

18
 l’interrompre, ainsi que la manière dont l’exécution devra reprendre, s’il y a lieu, après
l’interruption).

La figure 6 montre comment la tâche « Envoyer courriel » pourrait être documentée selon
MAD.

Figure 6: Représentation possible de la tâche «Envoyer courriel».

Une notation alternative pour MAD:

19
Exemple: La représentation MAD de l'activité " Gestion des ressources"

5.2.4 CTT : Concur Task Trees

CTT est une notation pour spécifier les modèles de tâches couvrant les limitations des autres
notations utilisées pour la conception des applications interactives, le but principal est de donner une
notation facile à utiliser, qui permet de représenter les différentes relations temporelles d’un même
niveau d’abstraction et qui peut être utilisée par un novice en modélisation de tâches. Elle se focalise

sur l’activité de l’utilisateur en classant les tâches utilisateurs en quatre types (abstraite ,

utilisateur , interaction et application ) et utilise un ensemble d’opérateurs temporels

pour exprimer leurs relations temporelles [Paterno, 2001].

Table 4 : Opérateurs temporels CTT hérités de Lotos.

20
CTT utilise une représentation graphique et propose un outil constituant un environnement d’édition,
de simulation, et génération de scenarios de tâches, appelé CTTE (CTTEnvironment) [Paternò et al.,
2001].

Exemple :

Figure 7 : La représentation CTT du système DAB

La figure 7 représente le modèle de tâche d’un distributeur automatique de billet (DAB). Dans ce
modèle l’utilisateur doit insérer sa carte, ensuite (>>) saisir son code PIN pour avoir l’autorisation
d’accéder à son compte. La tâche Accès peut être effectuée plusieurs fois (*) et désactivée ([>) à tout
moment par la tâche Terminer Accès. L’utilisateur choisit ([]) ensuite de retirer de l’argent (Retirer
Argent), de déposer de l’argent (Déposer Argent) ou bien de consulter son compte (Interrogation
Compte). Seule la tâche Retirer Argent est détaillée sur cette figure.

5.2.5 La méthode Diane+

La méthode Diane+ est utilisée pour la spécification et la conception d'applications interactives.
Nous allons voir que cette méthode répond à certains problèmes non résolus par d'autres méthodes
tels que celui de l'intégration de l'utilisateur dans le dialogue homme-machine. Diane+ permet
également la construction de dialogues en fonction du niveau de l'utilisateur par l'intermédiaire des
procédures effectives, minimales et prévues.

5.2.5.1 Présentation de Diane

Diane+ est basée sur Merise dont elle comprend certaines lacunes principalement au niveau de
la conception de l’IHM. Pour chaque application, on doit définir tout d’abord les tâches à réaliser.
Puis pour chaque tâche, on construit les procédures minimales, prévues et éventuellement
effectives que les futurs utilisateurs devront suivre. Ces procédures fournissent à la fois la
répartition du dialogue homme-machine et les activités que les utilisateurs disposent. Elles sont

21
composées d’opérations (qui peuvent elles-mêmes se décomposer en sous-opérations) qui font
appels aux services du noyau fonctionnel. Contrairement à l'UAN, Diane ne décrit pas formellement
les traitements à réaliser.

5.2.5.2 Planification hiérarchique

La planification hiérarchique décompose les tâches (buts) en sous-tâches (sous-buts) et en opérations
(voir figure 8), elle définit par conséquence le chemin à emprunter pour atteindre un objectif (un
but). Cette décomposition peut être générale ou bien adaptée aux différents types d’utilisateur. Ainsi
on peut avoir une décomposition par niveau de connaissance (expert ou novice du domaine de
l’application), par fréquence d’utilisation de l’application (utilisateur occasionnel ou non) ou bien
encore par niveau de confidentialité (forte ou faible).

Figure 8 : La planification hiérarchique

La planification hiérarchique consiste à établir une sorte de plan d'actions pour atteindre un
objectif. Un exemple pour la tâche "Enregistrer client" est montré à la figure 9:

Enregistrer Vérifier OK
Code Client Code Client
Annuler

Vérifier Ok
Enregistrer Enregistrer Nom Client
Annuler
Client Renseignements
Ok
Vérifier
Email Client
Annuler
Taux de Clic 7%
Remise
Clic 10%

Figure 9 : Planification hiérarchique de la tâche ''Enregistrer un client"

5.2.5.3 Buts, tâches et activités

22
La planification hiérarchique est basée sur la notion de buts, un but étant un état désiré que l’on
cherche à réaliser. À ce but correspond également la notion de tâche, c’est-à-dire un ensemble de
traitements qui doivent être exécutés pour atteindre le but correspondant. Ainsi on peut écrire:

- la Tâche est l’ensemble des traitements devant être exécutés pour atteindre un but.

Exemple: Commander un livre.

-la Tâche Prévue est l’ensemble des traitements permettant un déroulement normal de la tâche (ce
que doit être fait). Dans le cas de la commande de livre, la Tâche Prévue pour un bibliothécaire serait
par exemple : chercher la référence du livre, puis remplir le bon de commande.

-Procédure prévue : elle englobe l'ensemble de tâches prévues, elle est surtout utile pour l’aide et
l’apprentissage, elle fournit la liste ordonnée des opérations à réaliser pour mener à bien une tâche,
et permet de libérer l’utilisateur du problème du choix de l’ordre d’exécution des opérations.

-la Tâche Effective est l’ensemble des traitements exécutés lors d’une session de travail (exécution
de l'application). Dans l’exemple de la commande, la Tâche Effective pour un bibliothécaire
serait par exemple : vérifier la disponibilité du livre, remplir le bon de commande, et envoyer le bon
de commande. La recherche de la référence du livre peut être ignorée car on peut supposer que
le bibliothécaire connaît suffisamment les livres qu’il commande. La Tâche Effective dépend donc
fortement du poste de travail et du niveau de l’utilisateur.

-Procédure effective (pour une exécution particulière): elle englobe l'ensemble de tâches effectives,
elle est utile pour optimiser les sessions de travail, un utilisateur régulier exécute généralement la
même séquence d’opérations et afin de gagner du temps et de réduire sa charge de travail, il
peut souhaiter enregistrer cette séquence où ce type d’enregistrement s’appelle une macro (Ceci
se produit déjà dans des logiciels tels qu'Excel ou Word). Avec Diane+, il est tout à fait possible
de recréer ces macros soit à la demande de l’utilisateur (celui-ci construit lui-même ses macros
de la même façon qu’avec Excel) soit de manière automatique (le système est capable de déduire
qu’un utilisateur exécute toujours les mêmes enchaînements).

Le noyau dur de l’ensemble de ces tâches donne naissance aux procédures minimales.

-Procédure minimale: elle correspond au noyau dur des procédures effectives et prévues. Elle est en
général extraite de ces dernières car il est rare que les utilisateurs ou les responsables du
futur système soient capables de la donner immédiatement. La procédure minimale contient d’une
part le contrôle minimal obligatoire sur les opérations et d’autre part le maximum d’opérations dont
l’utilisateur dispose pour le but associé. Elle fait apparaître les précédences correspondant aux
règles de gestion et d’organisation, contrairement aux procédures prévues et effectives qui utilisent
également les précédences pour augmenter l’utilisabilité de l’application

-l’Activité est l’occurrence d’une tâche pour un contexte donné (ici le livre Python 3).

Il faut différencier la notion de tâche de la notion d’activité. La tâche est statique; elle décrit les
traitements à exécuter et éventuellement les enchaînements qui lient ces traitements. L’activité est
dynamique ; elle décrit l’exécution d’une tâche dans un contexte donné. Ainsi la tâche Commander
un livre est statique (remplir le bon de commande, envoyer le bon de commande, etc.) alors
que l’activité ‘Commander le livre Python3’ correspond à l’occurrence de la tâche Commander
un livre pour le livre Python 3.

23
On peut différencier la tâche de l’activité de la façon suivante (voir Figure 10) :

Python 3

Figure 10 : Lien entre Tâche et Activité

5.2.5.4 Description d’une opération

Une opération est un ensemble de traitements qui permettent de passer le système d’un état à un
autre. Ainsi la saisie d’un code client se décomposera en une opération qui récupère le code entré
par l’utilisateur et une opération qui contrôle la validité de ce code.

Une opération Diane+ possède des attributs qui lui donnent différents statuts (voir Figure 11):

o
f

Figure 11 : Description d’une opération Diane+

Le cinquième attribut concerne le déclenchement des opérations. Celui-ci peut être soit
l’utilisateur soit l’ordinateur. Pour préciser qu’une opération est déclenchée par l’utilisateur, on
lui ajoute ce que nous appelons un déclenchement utilisateur (ou encore un déclencheur) que
nous représentons de la manière suivante (Figure 12) :

Figure 12 : Le symbole du déclenchement utilisateur

24
Par exemple pour l’impression, bien que cette opération soit automatique, elle demande à être
déclenchée par l’utilisateur. De même une consultation doit être déclenchée par l’utilisateur (Figure
13) :

Opération
par default

Figure 13 : Deux opérations facultatives, l’une interactive et l’autre automatique

Le déclencheur est donc synonyme de boucle sur une opération. La figure 14 représente deux
opérations en cascade et avec des déclencheurs, ainsi les séquences (‫ܣ‬ା ‫ܤ‬ା )ା sont autorisées:

(Modifier) Aide
f f
Relation de précédence
Indicative
Permanente
Calculer Impôt
(Enregistrer) f

Figure 14 : Deux opérations permettant une boucle sur chacune d’elles

5.2.5.5 Décomposition et contraintes

Diane+ permet d’intégrer des opérations dans d’autres opérations (figure 15) afin d’avoir des
vues plus ou moins détaillées sur ces opérations et ça sans limitation.

Figure 15 : Une opération et sa décomposition en sous-opérations

Sur la figure 15, l’opération “A” ne sera considérée terminée que lorsque toutes ses sous-
opérations (“A.1”, “A.2” et “A.3”) le seront également. Or “A.2” contient également des
sous-opérations. Le même processus doit être appliqué pour “A.2”. Donc le processus dans

25
lequel elles devront se dérouler est : “A” (début), “A.1” (début-fin), “A.2” (début), “A.2.1”
(début-fin), “A.2.2” (début-fin), “A.2” (fin), “A.3” (début-fin), “A” (fin).

Remarque: pour appliquer des contraintes sur les sous-opérations (filles) ces dernières doivent être
facultatives.

Pour représenter une opération mère avec une contrainte sur ses filles, nous employons un cadre
double contenant la contrainte dans sa partie supérieure. Le chiffre de gauche indique le nombre
minimum de filles facultatives à exécuter, le chiffre de droite le nombre maximum. Dans la
figure 16, l’opération “A” possède des sous-opérations avec la contrainte “une et une seule”
alors que l’opération “B” a la contrainte “au moins une”.

Figure 16 : Illustrations des contraintes sur les sous-opérations facultatives

La figure 17 montre deux cas d’exclusion mutuelle gérés par la contrainte « une et une seule »

Exemples:

On va exécuter une seule

sous-opération un nombre
non déterminé de fois

Figure 17 : Exclusion mutuelle gérée par la contrainte ‘une et une seule’

La représentation d’une opération subissant des contraintes sur ses filles ou sur elle-même est:
(Figure 18) :

26
 Figure 18 : Contraintes sur une opération et sur ses filles

Exemple:

L’opération “A” de la figure 19 comporte trois sous-opérations avec la contrainte “au plus une”.
Elle subit également la contrainte de n’être déclenchable qu’une seule fois. Cela signifie que si
l’utilisateur la déclenche, il ne pourra exécuter ensuite que “A.1” ou “A.2” ou “A.3” (les deux
“ou” sont exclusifs). Dans les deux premiers cas, il n’aura qu’une seule exécution possible de
l’opération fille, alors qu’avec “A.3” il aura droit à autant d’exécutions qu’il veut (0, n).

Figure 19 : Diverses contraintes appliquées sur une opération et ses filles

5.2.5.6 Les synchronisations ET, OU et OU EXCLUSIF:

Il est donc possible d’utiliser l’une ou l’autre de ces représentations ou bien encore de passer de
l’une à l’autre. Les figures suivantes donnent les représentations pour le ET, le OU et le OU
EXCLUSIF.

Figure 20.a : Représentation du ET avec Diane+

27
Sur la figure 20.a, le dessin de gauche montre une synchronisation avec un ET. Dans le dessin de
droite (qui est équivalent à celui de gauche), une opération “A” contient les deux opérations filles
“A.1” et “A.2”. Elle ne possède pas de contrainte et son type obligatoire implique l’exécution des
deux opérations filles pour que l’opération mère soit considérée comme terminée.

Figure 20.b : Représentation du OU avec Diane+.

Sur la figure 20.b, le dessin de droite donne l’équivalent du “OU” représenté à gauche. L’opération
“A” contient les deux opérations filles dont le type a été changé pour que l’on puisse appliquer une
contrainte sur “A”. Cette contrainte (“au moins une” opération fille) doit être validée pour que “A”
soit considérée comme terminée.

Figure 20.c : Représentation du XOR avec Diane+.

Sur la figure 20.c, le dessin de droite donne l’équivalent du “OU EXCLUSIF” représenté à gauche.
L’opération “A” contient les deux opérations filles dont le type a été changé pour que l’on puisse
appliquer une contrainte sur “A”. Cette contrainte (“une et une seule” opération fille) doit être
validée pour que “A” soit considérée comme terminée.

5.2.5.7 Intégration de l'utilisateur

Les caractéristiques de Diane+ que nous venons de voir prouve qu’elle intègre à la fois l’utilisateur et
la répartition du contrôle entre l’homme et la machine contrairement à des méthodes telles que
MAD. Cette intégration se retrouve à deux niveaux :

1) l’interaction de l’utilisateur sur l’application par l’intermédiaire :

28
 • du mode d’interaction des opérations. Si on précise qu’une opération est interactive, cela
implique que l’utilisateur devra intervenir au cours de l’exécution pour que l’opération
puisse se dérouler. Au contraire, si une opération est automatique, cela signifie qu’on
interdit à l’utilisateur d’intervenir au cours de l’exécution.

• du mode de déclenchement des opérations. Si une opération possède un déclenchement

utilisateur, cela implique que seul l’utilisateur peut la déclencher. Au contraire, si une
opération ne possède pas de déclencheur, cela signifie qu’on interdit à l’utilisateur le
déclenchement de l’opération.

Dans les deux cas, on spécifie à la fois le permis (autorisation de déclenchement et

d’interaction) et l’interdit (interdiction de déclenchement et d’interaction) ce qui donne des
spécifications plus rigoureuses et plus faciles à gérer.

2) La latitude décisionnelle de l’utilisateur par l’intermédiaire :

• du type des opérations. Si une opération est facultative, on laisse à l’utilisateur le choix de
l’exécuter ou non (aux contraintes près). Les opérations facultatives augmentent donc la
latitude décisionnelle alors que les opérations obligatoires la restreignent. Là encore les deux
types sont nécessaires pour exprimer l’intégration de l’utilisateur en explicitant le permis
et l’interdit.

• des liens de précédence sur les opérations. Relier deux opérations obligatoires par un lien
de précédence permanente implique que l’utilisateur devra impérativement exécuter ces
opérations dans l’ordre donné par le lien. A l’inverse si deux opérations obligatoires ne sont
pas liées par une précédence, cela implique que l’utilisateur choisit l’ordre de déclenchement.
Par ailleurs nous avons vu qu’il est possible de lier des opérations obligatoires avec des
opérations facultatives. Ceci constitue une restriction La méthode Diane+ pour les opérations
facultatives qui ne peuvent alors être déclenchées qu’entre les deux opérations qui l’encadrent.
La présence de liens de précédence est donc synonyme de restriction de la latitude
décisionnelle alors que l’absence de liens implique une large latitude décisionnelle.

• des contraintes qui peuvent s’exprimer sur le nombre de déclenchements autorisés et sur
le nombre de sous-opérations facultatives à exécuter. L’absence de contraintes signifie
que l’utilisateur a un choix total sur ces deux plans, donc forte latitude décisionnelle.
Au contraire la présence de contraintes restreint de manière explicite la latitude décisionnelle.

Diane+ permet donc de spécifier explicitement la latitude décisionnelle maximale dont

dispose l’utilisateur. Ceci nous permet de contrôler de façon sûre le dialogue homme-machine.

6. Architecture logicielle des IHMs:

6.1Principe de base:
Bien que les modèles d’architecture diffèrent, ils répondent tous au même principe de base de la
figure 21 : la distinction entre les services d'une application et les fonctions chargées d'assurer
l'interaction avec l'utilisateur. L'application, appelée aussi Noyau Fonctionnel (NF), regroupe les
tâches du domaine et les opérations qui leur sont applicables. L'interface a la charge de présenter à
l’utilisateur tâches et fonctions et de lui permettre de les manipuler selon un enchaînement défini par
le modèle de tâches (Exemple: Procédure minimale).

29
 Figure 21: Distinction entre le Noyau Fonctionnel et l’interface

Par conséquence, un modèle d'architecture pour systèmes interactifs :

• définit une décomposition modulaire ou stratégie de répartition des services du système
interactif
• préconise la séparation entre les services du noyau fonctionnel et ceux de l'interface.

6.2 Les étapes de développement d'une architecture logicielle

Une architecture désigne une structure du logiciel selon un point de vue. Comme pour tout objet
conçu, plusieurs structures selon des points de vue différents sont possibles. À la Figure 22, nous
distinguons trois étapes principales à partir des requis fonctionnels d'un système interactif :

• Allocation des fonctions aux modules d'un

modèle d'architecture logicielle,
• Allocation des modules aux processus,
• Allocation des processus aux processeurs

Figure 22 : étapes de développement

6.3 Modèles de référence pour les systèmes interactifs

On a trois classes de modèles d'architecture : les modèles qui fournissent des structures
fonctionnelles à gros grain, les modèles multi-agent qui visent une décomposition fonctionnelle plus
fine el les modèles hybrides.

30
 6.3.1 Structures fonctionnelles : Seeheim et Arch

Le Modèle Seeheim :
Le modèle Seeheim est structuré en trois unités fonctionnelles :

– Le Noyau Fonctionnel (NF) regroupe les concepts et fonctions du domaine,

– La Présentation est chargée de rendre perceptible l'état pertinent des concepts du domaine (la
propriété d'observabilité) et d'en permettre la manipulation par l'utilisateur,

– Le Contrôleur de Dialogue (CD) sert de pont d'indirection entre le NF et la Présentation. En

tant qu'intermédiaire, le Contrôleur de Dialogue est responsable de la gestion des relations entre le
NF et la Présentation.

Figure 23 : Le modèle Seeheim

Le Modèle Arch :
Le modèle Arch (UIMS, 1992) s’appuie sur le modèle Seeheim ainsi il utilise les notions de noyau
fonctionnel et de contrôleur de dialogue.

Les pieds de l’arche constituent les composants imposés par la réalité (voir figure 24): le noyau
fonctionnel réalise les différentes tâches du domaine (l'application); le composant d’interaction
physique, en contact direct avec l’utilisateur, est mis en œuvre au moyen des objets d’interaction
d’une facette (boite de dialogue). Le contrôleur de dialogue gère l’enchaînement des tâches ainsi
que les liens entre les objets regroupés dans les deux composants voisins : l'adaptateur de noyau
fonctionnel et le composant d’interaction logique. L’adaptateur de noyau fonctionnel sert, pour
l’essentiel, à ajuster les différences de modélisation des objets conceptuels entre le noyau fonctionnel
et le contrôleur de dialogue.

31
 Figure 24 : Le modèle Arch

Le composant d'interaction logique joue un rôle similaire : il permet au contrôleur de dialogue de

s’affranchir du fonctionnement de la boîte à outils du niveau interaction physique. Le composant
d'interaction logique peut se voir comme une boîte à outils virtuelle qui implémente des objets
d'interaction logique concrétisés par une boîte à outil. La Figure 25 présente un exemple
d'architecture Arch pour un système interactif simple d'interrogation d'une base de données distante :
l'utilisateur spécifie une requête dans un formulaire et obtient les résultats à l'écran sous la forme d'un
tableau.

Figure 25 : Exemple d’application utilisant Arch

6.3.2 Modèles multi-agent

Les modèles multi-agent, comme PAC (Coutaz, 1987) ou MVC (Krasner et Pope, 1988), structurent
un système interactif en un ensemble d'agents spécialisés réactifs. Ces modèles se caractérisent par
une organisation fortement modulaire, des traitements exécutés en parallèle et une communication
par événements (des stimuli).

32
Définitions
Un agent est un système de traitement de l'information : il possède des récepteurs et des émetteurs
pour acquérir et produire des événements ; il dispose d'une mémoire pour mémoriser un état. Il
comprend un processeur spécialisé dans le traitement d'une ou plusieurs classes d'événements. Le
résultat d'un traitement se traduit généralement par un changement d'état de l'agent et par l'émission
de nouveaux événements.

Le modèle multi-agent se caractérise par une organisation fortement modulaire, des traitements
exécutés en parallèle et une communication par événements. Ce modèle abstrait est à rapprocher des
modèles à objets pour lesquels il existe des outils de réalisation.

Le modèle MVC:
Un agent MVC est composé de trois facettes réalisées par des objets (voir figure 26) :

• Le modèle (Model) : Le modèle maintient son état et notifie de ses modifications.

• la vue (View) : La vue écoute les notifications et interroge le modèle pour le représenter
correctement.
• et le contrôleur (Controller) : Le contrôleur écoute l’utilisateur et demande des modifications
au modèle.

Figure 26 : Le modèle MVC

Les communications entre la vue et le contrôleur ne peuvent normalement se faire sans passer par le
modèle qui est garant de la cohérence de l’état de l’agent.

Les limitations de ce modèle comme la gestion de la sélection, le besoin d’une communication

vue/contrôleur pour gérer le feed-back.., etc., sont résolues (dans les modèles postérieurs) par
l’intégration de la vue et le contrôleur au sein d’une même facette (exemple : Java/SWING procède
de cette manière). MVC a été réutilisé dans le domaine des applications Web, mais avec
modification vers MV.

33
Le modèle PAC:
Comme le montre la Figure 10, PAC (Coutaz, 1987) structure récursivement un système sous forme
d'une hiérarchie d'agents. La hiérarchie permet d'exprimer des relations entre agents et reflète un
continuum de niveaux d'abstraction depuis l'application jusqu'aux éléments fins de l'interaction. Un
agent PAC définit une compétence à un niveau d'abstraction donné. C'est un acteur à trois facettes :
la Présentation définit le comportement perceptible de l'agent, l'Abstraction représente son expertise,
et le Contrôle a un double rôle : (1) il sert de lien entre les facettes Présentation et Abstraction de
l'agent et (2) il gère des relations avec d'autres agents PAC de la hiérarchie. Sur la Figure 27,
l'Abstraction du niveau le plus haut correspond à la notion d'Application du modèle Seeheim et le
Contrôle du niveau le plus haut remplit des fonctions similaires au Contrôleur de dialogue:

Figure 27 : Le modèle PAC

La Figure 28 présente un agent PAC élémentaire, feuille de la hiérarchie : la Présentation sait

dessiner un formulaire avec deux boutons et reçoit les événements qui traduisent les actions de
l'utilisateur ; l'Abstraction, avec ses valeurs d'état constitue un modèle de l'état d'une requête ; le
Contrôle effectue le pont entre les deux facettes en gérant la correspondance des phénomènes
abstraits et concrets. Par exemple, lorsque l'utilisateur a saisi au moins les villes de départ et d'arrivée
dans le formulaire, l'Abstraction déclare que la requête est valide et on informe la Présentation via le
Contrôle. Le bouton "Chercher" (Search Information) devient alors actif. À la réception du signal
(émis par la Présentation) d'une pression sur le bouton "Chercher", le Contrôle demande à
l'Abstraction la structure de requête et la fournit à son agent Père, puis demande à ses deux facettes
Abstraction et Présentation de se réinitialiser.

Figure 28 : Un agent gérant un formulaire

34
 6.3.3 Modèle hybride PAC-Amodeus
Le modèle hybride PAC-Amodeus (Nigay, 1994) préconise la décomposition fonctionnelle d'Arch et
intègre les capacités d’affinement et de prise en compte du parallélisme de PAC. La Figure 29 en
présente les composants. Dans ses grandes lignes, PAC-Amodeus reprend les composants du modèle
Arch dont il affine le contrôleur de dialogue, composant principal, en agents PAC.

PAC-Amodeus :
Les composants Le Noyau Fonctionnel (NF) et l'utilisateur sont les deux extrêmes du modèle. À
gauche de la Figure 29, le NF réalise les concepts du domaine en ignorant la façon dont ces concepts
sont rendus perceptibles à l’utilisateur. Les autres composants du système, l’Adaptateur de Noyau
Fonctionnel (ANF), le Contrôleur de Dialogue (CD) et les composants d’Interaction Logique (IL) et
Physique (IP), constituent l’IHM du système. L’utilisateur et le NF produisent et consomment des
informations par l’intermédiaire de l'IHM. Ce fonctionnement symétrique laisse libre le choix du
contrôle de l’interaction en fonction du cas à traiter : contrôle par l'utilisateur ou par le NF. Le NF
échange des concepts du domaine ou objet du domaine avec son voisin immédiat : l’adaptateur de
noyau fonctionnel.

Figure 29 : Le modèle PAC-Amodeus

L'ANF est une interface conçue pour absorber les changements entre ses voisins directs. Comme
toute frontière, il implémente un protocole. Un protocole comprend généralement trois dimensions :
stratégies temporelles, nature des informations échangées, et mécanisme de liaison. Les stratégies
temporelles instaurent par exemple une communication synchrone ou asynchrone.

Le modèle PAC-Amodeus propose un ensemble de règles heuristiques pour guider la structuration en

hiérarchie d’agents PAC.

Règle 1 : Une fenêtre qui sert de support à un espace de travail est modélisée par un agent.

Règle 2 : Les vues multiples d’un même concept sont gérées par un agent “vue multiple” chargé de
maintenir la cohérence entre les vues.

35
 Figure 30 : Motif "Vue multiple d'un même concept", un agent Père gère la cohérence

Règle 3 : Une palette est modélisée par un agent.

Règle 4 : Une barre de menu est modélisée par un agent.

Règle 5 : Une zone d’édition est modélisée par un agent.

Règle 6 : Un concept complexe est modélisé par un agent.

Règle 7 : Si une fenêtre “espace de travail” permet d’ouvrir une autre fenêtre “espace de travail” sur
une autre instance du même concept, ces deux agents sont modélisés comme fils d’un même père.

Règle 8 : Si la nouvelle fenêtre représente plus de détails sur l’un des concepts, l’agent qui modélise
cette fenêtre est fils de l’agent source.

Règle 9 : Si la spécification d’une commande implique des actions distribuées sur plusieurs agents,
ceux-ci doivent être placés sous le contrôle d’un agent qui cimente les actions réparties en une
commande

Figure 31 : Un agent ciment

36
Règle 10 : Un agent PAC et son fils unique peuvent être regroupés en un seul agent.

Règle 11 : Un agent dont le rôle peut être encapsulé par un objet de présentation ou d’interaction
peut être éliminé et apparaître comme un composant de la présentation de son agent père.

7. Les formalismes de validation

Les formalismes de validation permettent de décrire et de vérifier le comportement de l'application
ou parfois uniquement celui de l'interface, ils permettent aussi de représenter la dynamique du
dialogue homme-machine.

7.1Les formalismes à états:

Une application peut être vue comme un ensemble d'états qu'elle est susceptible de prendre
au cours des sessions de travail. Les formalismes basés sur les états permettent de décrire les états et
la façon de passer d'un état à un autre. Ce passage peut être décrit par un langage, une grammaire ou
bien encore un graphe. L'avantage principal des formalismes à états est leur capacité à être validé
formellement.

On peut vérifier par exemple qu'un automate est vivant ou qu'il ne possède pas de puits.

Les états finis

Les états finis constituent un des formalismes les mieux maîtrisés pour les IHM étant donné
leur capacité à être traduits sous forme de grammaires (équivalence automate/grammaire). Un
système basé sur ce formalisme (par exemple Rapid/Use [WASSERMAN 85] [WASSERMAN 86]
ou les Statecharts qui autorisent également le parallélisme [HAREL 88] [HAREL 90] [VAN ZIJL
91]) manipule cinq éléments :

Un ensemble fini d'états, un ensemble fini d'entrées, un ensemble fini de sorties, une fonction qui
permet de passer à l'état suivant en fonction de l'état précédent et de l'entrée, et une fonction de sortie
qui renvoie le résultat en fonction de ces mêmes paramètres, pour représenter plus clairement ces
deux fonctions , on représente la plupart du temps les états finis avec leurs relations sous forme de
diagrammes (Figure 32). Il existe toujours un état initial (représenté sur la figure par l'état 0
doublement cerclé), mais il peut exister plusieurs états finals (ici le 1 et le 4). On remarquera
également qu'un état peut s'appeler lui-même une ou plusieurs fois en fonction de certaines entrées.

37
 Figure 32 : Un exemple de diagramme d’états finis

D'autres formalismes à états : Les grammaires, Les graphes d'enchaînements, Les contraintes, Les
langages visuels…..

7.2 Les formalismes à événements:

Le concept d'événement a complètement révolutionné le monde des IHM. Il a permis à celles-
ci d'être pilotées de plus en plus par l'utilisateur et non plus uniquement par le système. Les
événements permettent, à l'inverse des états, de décrire à quoi l'interface (ou l'application) est
susceptible de réagir. Les états permettent de dire quelles sont les étapes à suivre alors que les
événements permettent de dire comment y arriver.

L'approche événementielle

La programmation par événements est issue de la réflexion des ergonomes sur la

manipulation des programmes. Cette réflexion avait pour but d’obtenir des logiciels qui soient
dirigés par les utilisateurs et non des programmes qui dirigent les utilisateurs. Les actions de
l'utilisateur sur l’application génèrent des stimuli qui entraînent des changements d'état qui peuvent,
à leur tour, générer de nouveaux événements. L'insertion d'un flash disk, une demande de formatage
ou d'ouverture de fichier, une impression, la saisie d'un mot de passe, l'agrandissement d'une fenêtre,
un scrolling, sont des exemples de stimuli. Le système ERS [HILL 87b], par exemple, est basé sur ce
principe.

Les scénarios:
Les scénarios que nous présentons ici sont utilisés dans la méthode Grai [BERARD 90]. Ils
permettent de représenter non seulement les actions de l'utilisateur et celle de la machine, mais
également de dire qui pilote qui et à quelle occasion. Les scénarios se rapprochent en cela de la
méthode Diane+. Nous donnons ci-dessous (figure 33) deux exemples de scénarios. Dans le premier
cas, l’utilisateur agit sur le système à la suite d’un événement (Evt 1) produit par ce dernier. L’action
(A_U 1) de l’utilisateur entraîne une réaction du système (A_M 1).

Dans le même temps, l’utilisateur a eu la possibilité d’agir de nouveau sur le système (A_U
2) ce qui a provoqué une autre réaction du système (A_M 2) ainsi que la production d’un événement
(Evt 2). Dans le second cas, l’utilisateur agit sur le système (A_U 1), ce qui produit un événement

38
qui déclenche une action machine (A_M 1). Celle-ci achevée, l’utilisateur peut de nouveau agir sur
le système afin de produire de nouveau des événements, etc.

Figure 33 : Scénarios avec la méthode Grai

Dialogue modal, c’est-à-dire que l’utilisateur doit attendre que la machine termine le traitement
concernant sa dernière action avant de pouvoir réagir de nouveau.

D'autres formalismes à événements : Les scripts

7.3 Les formalismes hybrides:

Les formalismes hybrides sont des formalismes qui utilisent à la fois les états et les
événements. Certains sont issus de formalismes basés sur les états auxquels on a ajouté la notion
d'événement (par exemple les règles), d'autres ont été entièrement bâtis dans le but d'une utilisation
conjointe des états et des événements (par exemple les langages tels que Esterel [BOUSSINOT 91]).
Leur représentation peut être graphique ou textuelle, mais elle fait toujours ressortir la
correspondance entre les états et les événements.

Les Réseaux de Petri:

Ils sont utilisés principalement pour représenter des traitements séquentiels parfaitement
connus à l'avance. Il existe à l'heure actuelle des systèmes qui utilisent les Réseaux de Petri en
conjugaison avec une approche objet ou événementielle. Ce formalisme représente le dialogue
homme-machine par un ensemble de graphes d'événements.

Chaque élément composite de l'interface (par exemple une fenêtre, mais pas un bouton) est relié à un
de ces graphes. En fait chaque graphe est un Réseau de Petri. La figure 34.a représente un exemple
de fenêtre de saisie de mot de passe associée à une fenêtre d'aide, la figure 34.b représente le réseau
Rdp associé.

39
 Figure 34.a : Une fenêtre de saisie de mot de passe et sa fenêtre d’aide associée

Figure 34.b : Le graphe d’événement associé à la fenêtre de saisie de mot de passe

D'autres formalismes hybrides : Les objets, Les règles.

Références

Loé Sanou, Patrick Girard, Laurent Guittet, (2007) « Validation directe de la conformité d’une
application interactive à son modèle de tâches » Laboratoire d’Informatique Scientifique et
Industrielle (LISI / ENSMA) Téléport 2 – 1, avenue Clément Ader BP 40109 86961, Futuroscope
Chasseneuil, France. DOI: 10.1145/1541436.1541485.

40