Module IHM : Interaction Homme Machine.

Enseignant: M. LABENI
1. Introduction
2. Définitions
2.1 Ergonomie
2.2 Programme ergonomique
2.3 Tâche, tâche élémentaire et décorations
2.4 Le modèle de tâches
2.5 Identification d'une tâche
2.6 Du modèle de tâches à l'IHM
2.7 Conception IHM et génie logiciel
3. Obstacles et risques
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.3 Le formalisme UAN: User Action Notation
5.4 Le formalisme HTA: Hierarchical Task Analysis
5.5 Le formalisme MAD : Méthode analytique de description de tâches.
5.6 La méthode Diane+
6. Architecture logicielle des IHMs
6.1 Principe
6.2 Les étapes de développement
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 la
collaboration entre les équipe partenaires soufre 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 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).
Ces solutions sont intégrées aux processus génie logiciel.

2. Définitions:

2.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.
2.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é.
2.3 Tâche, tâche élémentaire et décorations:
Une tâche consiste en :
• 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.
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).
2.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

2
 comment les activités peuvent être rréalisées
é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 sous-tâches
tâches (avec éventuellement une typologie de tâche)
 des relations d'ordonnancement temporel des sous sous-tâches
tâches (séquence, alternative,
parallélisme, etc.)
 les objets utilisés pour accomplir une tâche ou une action,
 prédire
dire ou expliquer les performances d’un utilisateur dans un environnement donné.
2.5 Identification des tâches
tâches: identifier une tâche consiste à :
 Identifier
dentifier l’objectif que cherche à atteindre l’utilisateur llorsqu’il
orsqu’il se sert du système.
 Identifier leses 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, faireaire rédiger des scénarios par
des utilisateurs
rs 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 1: Scénario d'un utilisateur.

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
2.6 Du modèle de tâches à l'IHM:
Le modèle de tâches représenté par un arbre des 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.

non

Figure 2: De la tâche à l'IHM.

2.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

Comme méthodes de modélisation IHM (permettent d'élaborer le modèle de tâches de notre

IHM) on a : Diane+, les formalismes UAN et HTA.

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

Conception génie  Les différents modules (fonctions, procédures et
logiciel classes)
 Intégration des différents modules
 Implémentation et tests

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

4
3. 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 certains 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 (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).

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

5
Figure 3: Les étapes de modèle en V avec l'intégration de l'ergonomie dans le processus de
développent.
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, à
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é.

6
 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 à leurs 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 via des méthodes aujourd’hui
bien documentées (CTT: ConcurTaskTrees, DIANE+, GTA, GOMS: (Goal, Operator,
Method Selection, MAD, N-MDA (K-MAD en anglais), UAN, et les use case models
d’UML ..). Ces méthodes 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 (validation du produit).

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 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
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.

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à de la simple traduction linguistique, il doit prendre en considération la culture et
les traditions des peuples).

7
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é en termes de facteurs et de critères. Parmi
ces facteurs, nous relevons l’utilisabilité. Cette dernière se mesure au moyen de deux
facteurs: la facilité d'apprentissage (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é: 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é: capacité du système à s'adapter à l'user sans intervention explicite de sa part.
Plasticité: 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é: Capacité pour l'user de réviser un message avant de l’émettre.
Atteignabilité: 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’écran 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:
- découverte de défauts au moment des tests d’acceptation,
- 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

8
 du système et d'augmente la qualité du processus de développement mais exige une
équipe pluridisciplinaire.
Les étapes des méthodes de conception centrées utilisateur sont:
1) Analyser l’activité des utilisateurs
 Nominale
 Exceptionnelle
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
7) Si nécessaire, raffinement de cas d’utilisation.

5.3 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 objets et les actions:
: Bouton de la souris.

9
 ⋀
: En haut.
⋁
: En bas.
[ ]: Contexte d'un objet.
∼: Déplacer le curseur.
: Saisie des caractères (Keyboard).
" ": Commande littérale (ligne de commande).
( ): 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.

Feedback: La réaction de système

_ !: Fichier éclairé (file icon highlights)
_ − !: Fichier ignoré (file icon unhighlights)
!!: Application éclairée différemment (application file highlights differently).
_ ′: Icône sélectionnée.
> ~: La boîte suit le curseur.
_ ≫ ~: Zoom au curseur (resize)

Plus de formalisme: connecteurs logiques:

¥ : Pour tous les objets.
¬ : Non logique.
= : Égalité.
∗ : Différent.
: : séparation entre conditions et actions.

Exemples:
a) Actions utilisateur:

Imagine a supposed description in a user manual for the task of selecting a file icon. (For
purposes of introduction, only the user action portion of task descriptions are described
in this section, this task might be described in prose as:

(1) move the cursor to the file icon;

(2) depress and immediately release the mouse button.
The user action portion of the UAN description for this task is as follows:
(1) ~[ ile_icon]
(2) M ∨∧

The ∼ denotes moving the cursor, in this case into the context of the file icon.
The second line represents depressing ∨ and releasing ∧ the mouse button (M). Even
this simple example illustrates the brevity and readability of UAN.
Let us describe another task, moving a file icon, which can be stated in prose as :
(1) move the cursor to the file icon. Depress and hold down the mouse button.
Depressing the mouse button selects the file, indicated by the highlighting of its icon.
(2) with the button held down, move the cursor. An outline of the icon follows the
cursor as you move it around.

10
 (3) release the mouse button. The display of the icon is now moved to where you
released the button.
The user action portion of the corresponding UAN description is shown below:
(1) ~ [ ile_icon]M ∨
(2) ~ [x, y]∗ ~ [x , y′]
(3) M ∧
Reading this task description, we again note moving the cursor into the context of the
icon and depressing the mouse button. In the second line, ~ [x, y]∗ indicates movement
of the cursor to an arbitrary point x, y on the screen. The * (iterations in regular
expressions) means to perform, zero or more times, the task to which it is attached.
Thus, ~ [x, y]∗ ~ [x , y′] means to move the cursor to a succession of zero or more
arbitrary points about the screen, ending at the point x’, y’. Finally, in the third line
the mouse button is released.

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^

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.4 HTA (Hierarchical Task Analysis)

Le modèle HTA est l’une des premières notations utilisées pour la collecte d’informations
des activités de l’utilisateur. Sa capacité à abstraire est réalisée par la décomposition
hiérarchique des tâches en sous tâches, HTA est une notation qui admet aussi une description
graphique que textuelle de la représentation des informations liées aux activités de
l’utilisateur. En HTA, les instructions que l’on va mentionner (page suivante) sont connues
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 formel, permet d'expliquer les
instructions nécessaires, mais peut rendre difficile l’utilisation d’outils de validation ou de
simulation.

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

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).

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

12
 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 (HTA en représentation textuelle) de l'exemple précédent, on peut noter que, par l’ajout
de colonnes supplémentaires audit tableau, il est facile de montrer autant de propriétés que souhaité.

13
5.5 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 la tâche.
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és
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 4):
 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

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

Figure 4: 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

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

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

Figure 5: Représentation possible de la tâche «En

«Envoyer
voyer courriel».

Une notation alternative pour MAD:

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

5.6 La méthode Diane+

Nous utilisons la méthode Diane+ 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
tel 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.6.1 Concepts fondamentaux de Diane+

5.6.1.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 définit 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 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. Diane ne décrit donc pas formellement les traitements à réaliser
contrairement à l'UAN.

5.6.1.2 Planification hiérarchique

La planification hiérarchique décompose les tâches (buts) en sous-tâches (sous-buts) et en
opérations, 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 encore 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).

17
La planification hiérarchique consiste à établir une sorte de plan d'action pour atteindre un
objectif. Exemple pour la tâche "Enregistrer client":

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%
Planification hiérarchique de la tâche ''Enregistrer un client"

5.6.1.3 Buts, tâches, activités

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. A 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.

18
-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.

-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 minimum 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.

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

Python 3

19
 5.6.1.4 Représentation des opérations
a) Description d’une opération
Une opération est un ensemble de traitements qui permettent de faire 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 (Figure 5.2):

o
f

Le troisiè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 5.4) :

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
5.5) :

Opération
par default

20
Le déclencheur est donc synonyme de boucle sur une opération. La figure 5.6 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

2.5.3. Décomposition et contraintes

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

Sur la figure 5.11, 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
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 5.13, 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”.

21
 Exemples:

On va exécuter une seule

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

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

Exemple:

L’opération “A” de la figure 5.16 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

22
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).

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 (Figure 5.20.a, b et c) donnent les représentations pour le ET,
le OU et le OU EXCLUSIF.

23
 6. Architecture logicielle des IHMs:
6.1 Principe:
Bien que les modèles d’architecture diffèrent, ils répondent tous au même principe de base de Figure
1 : 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).

24
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. A la Figure suivante,
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

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

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

6.3.1 Structures fonctionnelles canoniques : Seeheim et Arch

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

25
Les pieds de l’arche constituent les composants imposés par la réalité : 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. 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 7 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.

26
 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).

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 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. A la Figure 10,
l'Abstraction du niveau le plus haut correspond à la notion d'Application du modèle Seeheim:

27
Et le Contrôle du niveau le plus haut remplit des fonctions similaires au Contrôleur de dialogue:

La Figure 11 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. A 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.

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 13 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 :

28
Les composants Le Noyau Fonctionnel (NF) et l'utilisateur sont les deux extrêmes du modèle. A
gauche de la Figure 13, 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.

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.

7. Les formalismes de validation

7.1 Les 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

29
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 2.15). 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.

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

30
méthode Diane+. Nous donnons ci-dessous 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
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.

Dialogue modal, c’est-à-dire que l’utilisateur doit attendre que la machine termine le traitement
concernant la dernière action de l’utilisateur avant de pouvoir 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 2.18.a représente un
exemple de fenêtre de saisie de mot de passe associée à une fenêtre d'aide, la figure 2.18.b représente
le réseau Rdp associé.

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

32