intÉgration et exploitation d’outils de …niveau de compréhension de l’humain dans de telles...
TRANSCRIPT
OLIVIER TYE GINGRAS
INTÉGRATION ET EXPLOITATION D’OUTILS DE
VISUALISATION Compréhension de situations complexes
Mémoire présenté
à la Faculté des études supérieures de l’Université Laval
dans le cadre du programme de maîtrise en génie électrique
pour l’obtention du grade de Maître ès sciences (M. Sc.)
DÉPARTEMENT DE GÉNIE ÉLECTRIQUE ET DE GÉNIE INFORMATIQUE
FACULTÉ DES SCIENCES ET GÉNIE
UNIVERSITÉ LAVAL
QUÉBEC
2011
© Olivier Tye Gingras, 2011
Résumé
La compréhension de situations complexes s’avère de plus en plus nécessaire, notamment
dans les domaines militaires. En réponse à cette demande, le projet IMAGE, en cours à
Recherche et Développement pour la Défense Canada – Valcartier, vise à développer un
environnement interactif offrant des outils logiciels aidant à augmenter la vitesse et le
niveau de compréhension de l’humain dans de telles situations. Il regroupe quatre grands
modules : Scénarisation, Simulation, Exploration et Représentation. Le projet présenté
dans ce mémoire a trait au développement d’un prototype pour la partie Exploration, qui
regroupe principalement des outils de visualisation. Cette plateforme servira à des
expérimentations en psychologie cognitive visant à mesurer l’augmentation de la
compréhension offerte par ces outils.
L’humain étant au centre de l’environnement développé, certaines théories qui lui sont
reliées, touchant notamment la psychologie cognitive, les interfaces personne-machine ainsi
que la visualisation d’information, sont d’abord présentées. Une revue de diverses
plateformes logicielles existantes, susceptibles d’offrir des fonctionnalités intéressantes
pour l’implémentation, est également effectuée. Suite à une évaluation plus approfondie des
outils retenus ainsi que plusieurs tests avec ces derniers, une première problématique, ayant
trait au transfert de multiples flots de données XML partant du module Simulation vers le
module Exploration, est alors abordée; la création de l’application ImageDataServer
s’ensuit, faisant usage du framework ACE pour la gestion de multiples connexions et le
traitement de données en parallèle. Suite à cette réalisation, des premiers jets de
représentations visuelles, basés sur un scénario tactique de convoi militaire, sont
développés à partir des données de simulation de ce scénario transférées vers Eye-Sys, une
application de visualisation générique. Une scène 3D montrant l’évolution spatiale et
temporelle ainsi que les interactions entre les agents de la simulation, véhicules militaires,
explosifs et insurgés, y est mise en action grâce à des données provenant d’une base de
données MySQL. La vue est également synchronisée à une application de simulation
interactive, Multichronia, servant de point de contrôle principal pour l’utilisateur. Une
évaluation des performances du système et une discussion sur divers aspects de
développement complètent ce mémoire.
À mes parents, qui depuis toujours m’appuient dans mes projets,
À mon amour Émilie, ma grande complice et mon soutien moral,
À tous mes collègues, en particulier à Frédéric et François,
merci pour votre support spécial.
Table des matières
Résumé ..................................................................................................................................... i Table des matières ................................................................................................................ iii Liste des figures ...................................................................................................................... v
1 Introduction ..................................................................................................................... 7 1.1 Contexte général ..................................................................................................... 7 1.2 Projet IMAGE ......................................................................................................... 8
1.2.1 Description et objectifs ....................................................................................... 8 1.2.2 Défis et préoccupations ..................................................................................... 10
1.2.3 Identification des besoins .................................................................................. 11
1.2.4 Élaboration de scénarios ................................................................................... 13 1.2.5 Expérimentations avec utilisateurs ................................................................... 15
2 État de l’art .................................................................................................................... 17 2.1 Connaissance ........................................................................................................ 17
2.1.1 Aspects théoriques ............................................................................................ 17 2.1.2 Cognition humaine ............................................................................................ 18
2.1.3 Compréhension ................................................................................................. 22 2.2 Complexité ............................................................................................................ 24
2.2.1 Définition : complexe versus compliqué ........................................................... 24 2.2.2 Caractéristiques de la complexité ..................................................................... 25
2.3 Ingénierie des systèmes ........................................................................................ 27
2.3.1 Profil des utilisateurs ........................................................................................ 28
2.3.2 Systèmes cognitifs ............................................................................................ 29 2.4 Exploration ............................................................................................................ 33
2.4.1 Visualisation d’information .............................................................................. 34
2.4.2 Techniques de visualisation .............................................................................. 35 2.4.3 Considérations de design .................................................................................. 44
3 Module Exploration ...................................................................................................... 46 3.1 Plateformes logicielles .......................................................................................... 46
3.1.1 ACE .................................................................................................................. 46
3.1.2 MySQL ............................................................................................................. 48 3.1.3 Tableau Software .............................................................................................. 51 3.1.4 Eye-Sys ............................................................................................................. 53
3.1.5 Multichronia ...................................................................................................... 56 3.2 Explorations préliminaires .................................................................................... 57
3.2.1 Simulation et transfert de données .................................................................... 57 3.2.2 Application Eye-Sys .......................................................................................... 59 3.2.3 ACE .................................................................................................................. 65 3.2.4 Application Tableau Desktop ........................................................................... 67
3.3 Tests et prototypes – Traitement des données ...................................................... 67
3.3.1 Plug-ins Eye-Sys ............................................................................................... 68 3.3.2 Prototypes COM / C++ ..................................................................................... 69
3.4 Application ImageDataServer .............................................................................. 70 3.4.1 Gestion des connexions .................................................................................... 71 3.4.2 Traitement des données XML ........................................................................... 73
iv
3.4.3 Connexion et interactions COM avec Eye-Sys ................................................. 75 3.5 Tests et prototypes – Visualisation ....................................................................... 77
3.5.1 Plug-in « History Concatenator » ..................................................................... 77 3.5.2 Scène tactique 3D ............................................................................................. 78
3.6 Migration vers la base de données MySQL .......................................................... 80 3.6.1 Mode de connexion à la base de données ......................................................... 81 3.6.2 Modifications logicielles ................................................................................... 83
3.7 Vue tactique .......................................................................................................... 85 3.7.1 Éléments visuels de la vue 3D principale ......................................................... 85 3.7.2 Panneaux informatifs et interface de contrôle .................................................. 89 3.7.3 Graphique d’évolution ...................................................................................... 91 3.7.4 Vue « Distribution des simulations » ................................................................ 93
3.7.5 Exploration tactique finale ................................................................................ 94 3.7.6 Vue tactique allégée (groupe contrôle) ............................................................. 95
3.8 Synchronisation avec Multichronia ...................................................................... 96
3.8.1 Protocole de communication ............................................................................ 97
3.8.2 Plug-in « Driver Regulator » ............................................................................ 98 3.9 Amélioration des performances avec MySQL ...................................................... 99
3.9.1 Plug-in « MySQL Database » ......................................................................... 100 3.10 Système de « logs » ............................................................................................ 101
4 Évaluation ................................................................................................................... 104
4.1 Test du système intégré ....................................................................................... 104 4.1.1 Exemple d’utilisation ...................................................................................... 104
4.1.2 Débogage du scénario ..................................................................................... 106 4.2 Discussions ......................................................................................................... 107
4.2.1 Améliorations possibles et recommandations ................................................. 107 4.2.2 Plateforme Eye-Sys ......................................................................................... 112
5 Conclusion .................................................................................................................. 115 6 Bibliographie .............................................................................................................. 118 Annexe A : Schéma de la base de données du projet IMAGE ........................................... 119
Liste des figures
Figure 1-1 : Diagramme conceptuel du projet IMAGE .......................................................... 9 Figure 1-2 : Environnement virtuel immersif CAVE ........................................................... 13 Figure 1-3 : Vues 2D du simulateur Pythagoras pour scénarios « pucerons » et « convoi » 14
Figure 2-1 : Modèle du système cognitif .............................................................................. 18 Figure 2-2 : Patrons visuels .................................................................................................. 19 Figure 2-3 : Performance d’une tâche en fonction de l’allocation en ressources ................. 20 Figure 2-4 : Principe de la triade .......................................................................................... 30 Figure 2-5 : Google Earth, représentation de trajets aériens et de densité de population ..... 36
Figure 2-6 : Représentations hyperbolique et radiale ........................................................... 37
Figure 2-7 : Représentation circulaire imbriquée ................................................................. 37 Figure 2-8 : TreeMap (SequoiaView) ................................................................................... 38
Figure 2-9 : Empreinte littéraire de la Bible ......................................................................... 38 Figure 2-10 : Exemples de représentations sémantiques ...................................................... 39 Figure 2-11 : Vues globale et rapprochée d'une représentation de données par densité ...... 40 Figure 2-12 : Diagramme « rivière » .................................................................................... 40
Figure 2-13 : Représentation circulaire ................................................................................ 40 Figure 2-14 : Visualisation à 2 dimensions temporelles ....................................................... 41
Figure 2-15 : Ligne du temps ................................................................................................ 42 Figure 2-16 : Mur en perspective .......................................................................................... 42 Figure 2-17 : Exploration tabulaire avec loupe sur les données ........................................... 43
Figure 2-18 : Effet de distorsion ........................................................................................... 43
Figure 2-19 : Effet de flou .................................................................................................... 43 Figure 2-20 : Coordonnées parallèles ................................................................................... 44 Figure 3-1 : Logo ACE ......................................................................................................... 46
Figure 3-2 : Structure du framework ACE ........................................................................... 48 Figure 3-3 : Logo MySQL .................................................................................................... 48
Figure 3-4 : Logo MySQL++ ............................................................................................... 49 Figure 3-5 : Hiérarchie de la classe mysqlpp::Connection ................................................... 50 Figure 3-6 : Logo Tableau .................................................................................................... 51
Figure 3-7 : Saisies d'écran de Tableau Desktop .................................................................. 52 Figure 3-8 : Interface principale de Tableau Desktop .......................................................... 53 Figure 3-9 : Logo Eye-Sys .................................................................................................... 53
Figure 3-10 : Interface principale de Eye-Sys ...................................................................... 55 Figure 3-11 : Saisie d'écran commentée de Multichronia .................................................... 56
Figure 3-12 : Extrait d'un document XML de données de simulation .................................. 58 Figure 3-13 : Schéma conceptuel de Multichronia ............................................................... 59 Figure 3-14 : Exemples d’une scène de convoi .................................................................... 61 Figure 3-15 : Fenêtre de conception de la scène de convoi .................................................. 61 Figure 3-16 : Exemple d'une vue analytique ........................................................................ 61
Figure 3-17 : Hiérarchie partielle des classes d'interfaces COM Eye-Sys ........................... 62 Figure 3-18 : Fenêtre d'édition du plug-in Script .................................................................. 64 Figure 3-19 : Hiérarchie partielle des classes du SDK Eye-Sys ........................................... 65 Figure 3-20 : Patron de design Reactor dans le contexte serveur/client ACE ...................... 66 Figure 3-21 : Diagramme d'héritage de la classe ACE_Svc_Handler .................................. 67
vi
Figure 3-22 : Extrait d'un programme test COM en C++ ..................................................... 70 Figure 3-23 : Diagramme de classes – partie Connexion ..................................................... 71
Figure 3-24 : Diagramme séquentiel – Démarrage ............................................................... 72 Figure 3-25 : Diagramme séquentiel – Connexion et réception de messages ...................... 73 Figure 3-26 : Diagramme de classes – partie Traitement ..................................................... 74 Figure 3-27 : Diagramme de classes – partie Eye-Sys / COM .............................................. 76 Figure 3-28 : Propriétés du « History Concatenator » et historiques de données ................. 78
Figure 3-29 : Saisie d'écran de la vue tactique préliminaire ................................................. 79 Figure 3-30 : Configuration du plug-in « Database » ........................................................... 82 Figure 3-31 : Schéma partiel de la base de données IMAGE - Données tactiques .............. 83 Figure 3-32 : Modèles 3D des agents de la simulation ......................................................... 86 Figure 3-33 : Éléments visuels de la vue 3D principale ....................................................... 87
Figure 3-34 : Icônes d'état des lanceurs de RPG .................................................................. 87 Figure 3-35 : Fenêtre de conception – LAV ......................................................................... 88 Figure 3-36 : Fenêtre de conception – IED ........................................................................... 89
Figure 3-37 : Fenêtre de conception – RPG ......................................................................... 89
Figure 3-38 : Panneaux informatifs et de contrôle ............................................................... 90 Figure 3-39 : Panneaux d’informations de type « Data Gadget » ........................................ 91
Figure 3-40 : Graphique d'évolution ..................................................................................... 92 Figure 3-41 : Fenêtre de conception - Graphique d'évolution .............................................. 93 Figure 3-42 : Vue « Distribution des simulations » .............................................................. 93
Figure 3-43 : Agencement final de la vue tactique ............................................................... 95 Figure 3-44 : Vue tactique allégée ........................................................................................ 96
Figure 3-45 : Exemple type de messages envoyés par Multichronia ................................... 97 Figure 3-46 : Fenêtres de propriétés - Plug-ins « Driver » et « Driver Regulator » ............. 99
Figure 3-47 : Fenêtre de propriétés du plug-in "MySQL Database" .................................. 100 Figure 3-48 : Exemple de contenu de la table « ExplorationTacticalLog » ....................... 101
Figure 3-49 : Fenêtre de conception – Scripts Tableau et logs ........................................... 102 Figure 3-50 : Fenêtres de conception et de propriétés – Log des sélections ...................... 102 Figure 4-1 : Saisie d'écran du système intégré .................................................................... 105
Figure 4-2 : Organisation structurelle actuelle des objets Eye-Sys pour la visualisation ... 109 Figure 4-3 : Organisation structurelle alternative pour le système de visualisation ........... 110
1 Introduction
1.1 Contexte général
De plus en plus d’organisations, civiles et militaires, de même que des chercheurs et
scientifiques, doivent faire face à des situations ou des problèmes qualifiés de complexes.
Ces situations sont caractérisées par des non-linéarités, des interactions, des hiérarchies, des
boucles de rétroaction, des comportements émergents, etc. Les éléments composant une
situation complexe sont souvent combinés les uns aux autres et font en sorte que l’humain,
dû à ses capacités d’analyse limitées, a beaucoup de difficulté à comprendre les
mécanismes qui gèrent ces situations. La gestion de la sécurité et des unités d’intervention
lors de grands événements comme les jeux olympiques ou la planification d’un budget
national de relance en temps de crise économique comptent parmi les exemples de telles
situations auxquelles doivent faire face les gouvernements. La planification militaire, autant
aux niveaux stratégique, tactique qu’opérationnel, comporte également plusieurs éléments
de complexité. Dans les domaines scientifiques, on peut penser à l’étude de la propagation
d’une maladie dans une population. L’étude des changements climatiques est également un
problème complexe colossal sur lequel il est pratiquement impossible de faire des
prédictions précises à cause du manque de compréhension et de l’ignorance d’innombrables
interrelations qu’il comporte.
Un autre problème largement répandu est la difficulté à manipuler de très grandes quantités
de données, souvent en raison de lacunes liées aux systèmes servant à les gérer. On peut
penser par exemple à la recherche sur Internet où les limites des systèmes actuels font en
sorte que certaines informations importantes ou utiles restent cachées sous une montagne
de données redondantes ou non-pertinentes. L’extraction de connaissances de haut niveau à
partir de très larges bases de données peut également être un défi de taille. Heureusement,
certains logiciels apportant des solutions intéressantes à ce problème commencent à voir le
jour. Dans ces derniers cas le simple accès à l’information n’est pas un problème mais ce
n’est pas suffisant; il faut pouvoir la discriminer selon des critères de qualité, de type de
données et de domaine d’application notamment.
8
Face à ces problèmes, le besoin de développer de nouveaux outils d’aide à la
compréhension et à la décision se fait sentir, notamment dans le domaine militaire où les
situations complexes sont nombreuses et variées.
1.2 Projet IMAGE
En réponse au type de problème décrit précédemment, IMAGE, un projet visant à créer un
environnement dynamique et interactif offrant des outils génériques pour augmenter la
compréhension de situations complexes variées, a été initié. IMAGE est un fonds
d’investissement technologique (FIT) alloué à la section Système de Systèmes (SdS) au
centre de Recherche et Développement pour la Défense Canada – Valcartier (RDDC-
Valcartier) (Lizotte, et al. 2008).
1.2.1 Description et objectifs
Le diagramme de la Figure 1-1 montre les concepts faisant partie du projet IMAGE et les
liens qui les unissent. Au centre du schéma, on retrouve des preneurs de décision,
commandants ou gestionnaires de projets qui doivent faire face à une situation complexe
quelconque, ainsi que des experts de divers domaines d’étude : scientifiques, ingénieurs,
stratèges, historiens, psychologues, etc. Les outils proposés par IMAGE s’adressent
principalement à ces personnes dans le cadre de divers types de situations comme la
planification, le support ou l’entraînement.
Au départ, la représentation mentale de la situation complexe est floue et peu ou pas
organisée. À l’extérieur du noyau, on retrouve les quatre grandes étapes de la démarche que
suivront les experts, chacune supportée par des outils proposés par IMAGE :
Scénarisation : Il s’agit de l’étape de départ où, à partir de connaissances que l’on
possède et d’hypothèses sur les liens unissant les entités, agents et composants
faisant partie de la situation complexe, on définit un scénario, typiquement basé sur
des modèles mathématiques que l’on pourra simuler et voir évoluer dans le temps à
la prochaine étape. Suite aux analyses qui seront faites aux étapes suivantes du
premier cycle d’analyse, le modèle défini initialement est sujet à subir des
changements lors des cycles ultérieurs.
9
Simulation : Une fois les modèles définis, ils sont exécutés dans un simulateur en
ayant comme objectif de reproduire une version synthétique dynamique de la
situation complexe. On vise principalement à faire ressortir des comportements
émergents et des interactions entre les modèles qui sont difficiles ou impossibles à
prévoir lorsque étudiés individuellement ou en mode statique. Il existe plusieurs
techniques de simulation présentées dans la littérature : data mining, data farming,
computational steering, simulation cloning, etc. L’approche retenue pour IMAGE
est interactive, c’est-à-dire que l’utilisateur a la possibilité de lancer plusieurs
Figure 1-1 : Diagramme conceptuel du projet IMAGE
(Mokhtari, et al. 2007)
10
simulations sur demande, de les interrompre et de les ré-exécuter. Il peut donc
observer l’évolution de la simulation en cours d’exécution et a également la liberté
de modifier la valeur de certains paramètres du modèle ou du scénario s’il le désire.
Exploration : De grandes quantités de données sont générées par les simulations à
l’étape précédente, et l’Exploration en permet une analyse en profondeur. La
principale fonction de cette partie est de convertir les données en une ou plusieurs
représentations visuelles, permettant d’exploiter les capacités du système perceptuel
de l’humain. Pour cela, diverses techniques de visualisation scientifique et de
visualisation d’information peuvent être utilisées en fonction des types de données à
analyser. Les développements du présent projet étant au cœur de cette partie, nous y
reviendrons plus en détails dans les sections ultérieures.
Représentation : C’est à l’étape de Représentation que l’utilisateur formalise sa
compréhension du modèle étudié et exprime sous forme visuelle le modèle mental
de la situation complexe qu’il s’est forgé lors de son analyse à l’aide des outils de
Simulation et d’Exploration. Cette représentation, typiquement sous forme de
graphe conceptuel, a pour but de l’aider à synthétiser ses idées et aussi de les
partager avec ses collaborateurs. La qualité du modèle obtenu ainsi que le niveau de
confiance envers celui-ci amèneront souvent l’utilisateur à raffiner le ou les modèles
définis à l’étape de Scénarisation.
Le tout se veut un processus itératif où, peu à peu, la représentation mentale des utilisateurs
se précise, passant d’idées floues à des concepts bien définis, d’incompréhension à de
nouvelles connaissances émergentes. Le but est à la fois d’augmenter le niveau de
compréhension et d’accélérer le processus d’analyse grâce à des technologies innovatrices.
Comme illustré sur le schéma, les outils sont liés et participent à un seul et même
processus. Cette synergie entre les composants est primordiale pour l’atteinte des objectifs
visés par le projet.
1.2.2 Défis et préoccupations
Au commencement du projet, quoique la description du projet et de ses objectifs était assez
bien définie, plusieurs préoccupations liées au niveau de connaissance et à l’état de l’art
11
dans des domaines relatifs au projet ont été soulevées. Il a été déterminé qu’une bonne
connaissance des outils et technologies déjà existants et disponibles concernant les grands
modules d’IMAGE (Simulation, Exploration, Représentation) s’avérait nécessaire avant de
s’immiscer trop en avant dans le développement. En effet, dans le contexte d’un projet
ambitieux, avant-gardiste, multidisciplinaire mais aux ressources de développement
limitées tel qu’IMAGE, exploiter au maximum la technologie actuelle afin de minimiser
l’effort de développement s’avère primordial. En contrepartie, un défi de taille est à prévoir
au niveau de l’intégration de modules qui, étant définis pour fonctionner de manière
indépendante a priori, devront faire partie du processus d’IMAGE.
L’aspect multidisciplinaire d’IMAGE amène un autre défi important : la coordination de la
compréhension des objectifs du projet et de sa terminologie entre les membres de l’équipe
provenant de différentes disciplines (informatique et génie, mathématiques, psychologie) et
des utilisateurs civils et militaires. Les principes de base du projet IMAGE peuvent être
difficiles à expliquer, à saisir, et être la source de confusion dans l’équipe. De plus, des
termes utilisés dans différents domaines d’étude qui ont potentiellement des significations
différentes doivent correspondre aux mêmes concepts lorsqu’utilisés dans le vocabulaire
d’IMAGE.
D’autres lacunes ont été identifiées comme devant être comblées pour certains membres de
l’équipe, notamment en ce qui concerne les connaissances en psychologie cognitive, la
définition des besoins et le développement d’un scénario.
1.2.3 Identification des besoins
Pour chacune des grandes parties du projet, une liste de besoins a été dressée. Comme de
nombreux éléments ont été mentionnés pour chacune de ces parties, nous nous
concentrerons ici sur ceux du module Exploration dont les développements font l’objet du
présent document.
D’abord, les besoins relatifs aux objectifs du projet stipulent que l’exploration doit
présenter des paradigmes de visualisation qui correspondent au scénario, aux capacités
cognitives de l’utilisateur ainsi qu’aux besoins des expérimentations avec les utilisateurs
(décrits plus en détails à la section 1.2.5).
12
Au niveau de l’architecture, l’intégration et l’exploitation de plusieurs outils de
visualisation sont au cœur des priorités, augmentant ainsi le nombre de possibilités offertes
à l’utilisateur pour l’analyse. Ces outils devront recevoir et manipuler des données
provenant de la simulation et fournir des options d’aide à l’utilisateur. Les actions
effectuées, c’est-à-dire toutes les créations, modifications et manipulations dans les vues
d’exploration devront être enregistrées dans le but de conserver la trace du cheminement
emprunté par l’utilisateur dans sa démarche. Ces données serviront principalement à
l’interprétation de résultats d’expérimentations, mais seront, comme dans la plupart des
applications logicielles, une fonctionnalité indispensable du produit final pour la
sauvegarde de l’état de projet, permettant l’interruption et la reprise d’une session de travail
ou le partage des résultats avec d’autres utilisateurs.
Un dernier objectif architectural majeur poursuivi par IMAGE est d’intégrer les
technologies développées dans un environnement virtuel immersif de type CAVE (CAVE
Automated Virtual Environment). Ce système consiste à immerger l’utilisateur en le
plaçant à l’intérieur d’un espace de forme cubique entouré de trois murs et d’un plancher
servant de surfaces de projection (voir Figure 1-2). La stéréoscopie et le repérage de la
personne en « off-axis », qui sont utilisés dans l’environnement afin d’ajuster le point de
vue en 3D, contribuent également à augmenter le sentiment de présence et le degré
d’immersion. Une augmentation de la compréhension avec ces technologies novatrices par
rapport aux outils de bureau traditionnels est attendue.
Finalement, des besoins relatifs aux utilisateurs ont également été soulevés : la création de
vues sur demande, la manipulation, la comparaison et l’exploration de données ainsi que la
possibilité de prendre des notes, des saisies d’écran et d’archiver du contenu. Cependant, la
synchronisation des actions avec les autres modules a été identifiée comme étant
primordiale dans cette catégorie. Par exemple, la sélection d’un élément dans le module
Simulation (comme un nœud représentant une branche de simulation) doit se refléter dans
les vues de l’Exploration par un paradigme visuel quelconque appliqué aux données
concernées qui les met en évidence ou vice-versa.
13
1.2.4 Élaboration de scénarios
L’élaboration d’un ou de plusieurs scénarios pour la première version d’IMAGE a été
identifiée comme une tâche de premier plan et à juste titre; les premiers développements du
module Exploration doivent se baser sur les caractéristiques et les données du scénario afin
de bien y être adaptés.
Pour les premières itérations de développement, quelques possibilités ont été identifiées et
deux ont été retenues pour la première version d’IMAGE. Un premier scénario simulant
l’évolution d’une maladie causée par des pucerons se propageant dans une population
d’arbres servira d’outil de familiarisation pour les utilisateurs lors des expérimentations.
Afin de mieux répondre aux besoins du client principal du projet, les Forces armées
canadiennes, dans le contexte du déploiement militaire en Afghanistan, un deuxième
scénario plus approprié a été choisi. Il s’agit d’une situation où un convoi militaire,
composé de véhicules blindés légers (LAV), doit parcourir un tronçon de route sur lequel il
Figure 1-2 : Environnement virtuel immersif CAVE
(Laboratoire d'immersion virtuelle, RDDC Valcartier 2006)
14
peut être attaqué soit par des engins explosifs improvisés (IED) placés sous la chaussée,
soit par des opérateurs de lance-grenades (RPG). Le niveau de défense des véhicules est
assuré pour ces deux types d’attaque par une quantité variable d’armures sous-plancher et
latérale respectivement, en fonction d’un nombre variable d’attaques possibles d’IED et de
RPG. La quantité d’armure influence la vitesse du convoi, ce qui se répercute sur la
possibilité de détecter et de désarmer un IED et sur l’efficacité des attaques des tireurs de
RPG. Ces scénarios sont mis en action par le simulateur Pythagoras et les simulations
contrôlées de manière interactive à l’aide du logiciel Multichronia, développé dans le cadre
du projet de recherche de doctorat de François Rioux (Rioux, 2009).
Le scénario de convoi militaire comporte deux volets : tactique et stratégique (ou
procédural). Dans le premier volet, le problème à résoudre est axé sur l’action immédiate
sur le terrain et la principale préoccupation de tous les jours des soldats, c’est-à-dire de
maximiser le transfert d’un chargement du point A au point B tout en minimisant les pertes.
L’analyse vise donc à trouver la meilleure combinaison d’armures possible permettant
d’atteindre cet objectif. Pour la partie stratégique, le problème se situe à un niveau de
planification plus élevé. On observe l’évolution dans le temps de plusieurs paramètres
comme le renseignement (quantité d’information obtenue de la population locale),
Figure 1-3 : Vues 2D du simulateur Pythagoras pour scénarios « pucerons » et « convoi »
(Bernier et Rioux 2008)
15
l’allégeance (la confiance de cette population envers les militaires) et le support aux bleus
(nos propres forces), où chaque pas de temps représente les résultats d’une simulation de
déplacement de convoi; lors de ces simulations, les paramètres sont contrôlés par un
algorithme d’adaptation qui priorise soit la vie des membres du convoi ou la quantité de
cargo (plus d’armure peut favoriser la vie mais diminue le cargo disponible). L’analyste
peut faire varier la quantité de cargo transporté et le type de priorité selon un ou plusieurs
critères d’optimisation visés.
1.2.5 Expérimentations avec utilisateurs
L’augmentation du niveau de compréhension de l’utilisateur face à une situation complexe
est l’un des principaux enjeux du projet IMAGE. À cet égard, la démonstration d’un tel
accomplissement doit pouvoir être faite à l’aide d’observations et de mesures appropriées
lors d’expérimentations avec des utilisateurs. Ce type d’évaluation relevant du domaine de
la psychologie cognitive, une équipe de chercheurs possédant une expertise en la matière
collabore activement au projet.
Il n’est pas nécessairement évident de prendre de telles mesures contrairement à d’autres
types d’expérimentations dans le domaine des sciences où l’on peut mesurer directement
une ou des variables dans un environnement contrôlé. Ici, le gain à mesurer est au niveau de
la compréhension humaine; cela peut cependant être évalué indirectement par plusieurs
moyens comme l’analyse de prise de décisions, le suivi des actions et des événements lors
de l’expérimentation et l’évaluation de la performance pour une tâche donnée. Une
attention particulière aux conditions d’expérimentation doit être portée afin d’éviter le plus
possible les biais dans les mesures.
Les expérimentations seront réalisées à l’aide de trois groupes de personnes jouant le rôle
d’analyste utilisateur d’IMAGE qui doit comprendre une situation complexe. Le premier
est le groupe « IMAGE Desktop », pour lequel est proposée une suite d’outils dont
Multichronia pour la partie Simulation, ainsi que Eye-Sys et Tableau pour l’Exploration
(décrits dans des sections ultérieures), utilisés dans un environnement de bureau multi-
écran afin de favoriser la synergie entre les sous-systèmes. Le deuxième groupe, « IMAGE
CAVE », utilise la même suite d’outils mais adaptée à l’environnement virtuel de type
16
CAVE. Finalement, le « groupe contrôle » présente une version simplifiée de Multichronia
et de la vue Eye-Sys, dans laquelle les interactions et la visualisation avancées sont retirées,
tout en conservant un minimum de fonctionnalités nécessaires à l’exécution de la tâche. Les
utilisateurs ont cependant accès à des outils de bureautique standards tels Microsoft Word
et Excel. La comparaison des résultats des sessions d’expérimentations avec ces différents
groupes d’utilisateurs permettra d’évaluer les bénéfices en termes de la compréhension du
scénario offerts par les outils d’IMAGE ainsi que du potentiel des technologies immersives
en cette matière (Lafond, Gagnon et Tremblay 2009).
Ce mémoire fait état des développements réalisés dans le cadre du projet IMAGE décrit
précédemment, principalement au niveau du design de la visualisation dans la partie
Exploration, pour le volet tactique du scénario de convoi militaire.
17
2 État de l’art
Comme nous l’avons mentionné dans l’introduction, IMAGE, dans son ensemble, couvre
une grande variété de domaines d’étude et un grand éventail de connaissances. Des
informations provenant notamment de recherches personnelles, de cours ainsi que de
l’expertise des membres de l’équipe du projet sont regroupées dans ce chapitre, touchant
divers sujets comme la connaissance, la complexité, la conception de systèmes, la
visualisation scientifique et la visualisation d’information. Plusieurs aspects de la
psychologie cognitive liés à ces domaines y sont également abordés.
2.1 Connaissance
2.1.1 Aspects théoriques
La connaissance est un phénomène complexe et difficilement définissable. Elle peut être
considérée comme un mélange de données, d’expérience et d’information contextuelle qui
s’incorpore dans les normes d’une société. Il peut aussi s’agir d’intégration d’expérience.
Les points de vue sur la question peuvent être très différents dépendamment du domaine
d’étude (psychologie, langues, science, philosophie, religion, etc.). On peut toutefois la
définir d’une manière très générale comme étant une organisation dynamique de la
mémoire.
Il est possible de classifier la connaissance de diverses manières. L’une d’elles, plutôt
générale et intuitive, consiste à la séparer en trois catégories : le quoi, qui représente des
connaissances déclaratives ou des faits; le pourquoi, la raison des choses; le comment, la
connaissance procédurale ou habileté acquise par expérience (Judelman 2004).
D’un point de vue plus formel, on peut considérer les connaissances comme pouvant se
manifester sous deux formes : explicite ou déclarative, facilement descriptible et
transmissible entre individus, et implicite ou procédurale, qui est surtout inconsciente et
difficile à articuler et transmettre. Elles peuvent de plus être classées selon les types
suivants : la connaissance perceptuelle, qui a trait à l’état des choses et de l’environnement,
la connaissance structurelle, qui se rapporte aux aspects dynamiques et aux relations entre
18
les variables, et la connaissance stratégique, l’influence que l’on porte sur un système afin
d’obtenir l’effet désiré. Ces derniers trois concepts peuvent s’apparenter intuitivement aux
catégories du quoi, du pourquoi et du comment, énoncées plus tôt.
Les connaissances structurelles d’un système impliquent ses composantes, les
caractéristiques comportementales de ces dernières, leurs connexions ainsi que les
comportements du système entier. L’acquisition ou l’apprentissage de ce type de
connaissances est le résultat d’un processus d’énonciation d’hypothèses combiné à une
évaluation (Funke, 1991). Ceci est nécessaire au processus de raisonnement pour
l’application de solutions au système en question. Un intérêt particulier est porté à ces
concepts en raison de l’un des objectifs du projet IMAGE consistant à favoriser la
découverte et l’explicitation des relations entre les composants d’un système complexe.
2.1.2 Cognition humaine
L’humain étant au cœur du processus d’acquisition de connaissances, l’identification des
principaux aspects de son système cognitif et de certaines de leurs caractéristiques
importantes s’avère pertinente. Le schéma de la Figure 2-1, élaboré d’après le modèle
d’Atkinson-Shiffrin, résume les concepts abordés dans cette section.
Figure 2-1 : Modèle du système cognitif
d’après (Atkinson et Shiffrin 1968)
19
2.1.2.1 Système perceptuel
Le système perceptuel (ou visuel) humain est sans doute le plus utilisé et le plus puissant de
son registre sensoriel, et il lui confère un avantage certain par rapport à la machine, à
l’inverse d’autres facultés telles que la rapidité de calcul. Il lui permet de détecter
facilement et rapidement des patrons visuels dans les images, les formes ou les
représentations de données qu’il regarde et analyse. La théorie de la Gestalt (Judelman
2004), stipulant qu’il se forme un équilibre entre les processus d’isolation et de
regroupement spatial des formes en entités conceptuellement cohérentes, vient expliquer en
grande partie ce phénomène. La similarité de couleur ou de taille, la proximité, la continuité
et la symétrie de composants d’un patron visuel font en sorte qu’on les considère comme un
tout et non pas comme une partie (illustrés à la Figure 2-2). Le contexte joue également un
grand rôle à ce titre sans lequel une situation ne peut prendre de véritable sens (Ware 2000).
D’autres facteurs relevant de la physiologie caractérisent le système de vision humain.
L’acuité visuelle, entre autres, fait que seule la vision fovéale, une petite zone au centre de
l’image perçue, a une résolution nette et optimale. La vision périphérique est donc moins
précise mais, en contrepartie, très efficace pour la détection de mouvement. Également, la
disparité binoculaire confère une fonctionnalité très importante au système perceptuel : la
vision 3D et la perception de la profondeur.
2.1.2.2 Attention et charge mentale
L’attention est le processus par lequel l’humain consacre et oriente ses ressources mentales
à l’exécution d’une ou plusieurs tâches données. L’attention peut être sélective, c’est-à-dire
consacrée à une seule tâche ou source d’information en éliminant les autres qui sont non-
pertinentes, ou partagée, étant alors divisée entre plusieurs tâches ou sources traitées
Figure 2-2 : Patrons visuels
d’après (Tufte 1990)
20
simultanément. À l’exécution d’une tâche particulière est associée une certaine demande en
ressources attentionnelles, et un opérateur qui l’exécute utilise une partie de sa capacité ou
de son expertise pour l’atteinte d’un certain niveau de performance. La charge mentale est
l’effort requis pour traiter cette tâche et est évaluable comme une fonction des demandes en
ressources et de la capacité de l’opérateur. À ce titre, un opérateur expérimenté a besoin de
moins de ressources pour l’atteinte d’un niveau de performance donné, sa charge mentale
de travail est donc plus légère. Lorsque deux tâches sont exécutées en même temps et
qu’elles demandent toutes les ressources disponibles, il y a division des ressources entre ces
tâches, ce qui résulte en une diminution d’allocation pour chacune (Johnson et Proctor
2003).
Ces concepts sont souvent étudiés à l’aide de la fonction performance-ressources (FPR),
dont un exemple est illustré à la Figure 2-3. Dans ce graphique, on peut voir que la tâche B
est plus facile que la tâche A puisqu’elle requiert moins de ressources de la part d’un
utilisateur pour l’atteinte d’un niveau de performance équivalent. Le plateau de la fonction
B indique que l’utilisateur est limité en termes de données ou que la tâche comporte un
niveau de complexité élevé, ce qui résulte en un plafonnement de la performance même
lorsque les ressources allouées augmentent (Wickens et Hollands 2000).
2.1.2.3 Mémoire
On sépare la mémoire en deux parties qui jouent des rôles bien différents. D’abord, la
mémoire à court terme ou mémoire de travail contient de façon temporaire l’information
d’une tâche en cours de traitement. Elle possède les caractéristiques suivantes :
Figure 2-3 : Performance d’une tâche en fonction de l’allocation en ressources
d’après (Wickens et Hollands 2000)
21
Capacité limitée (typiquement 7 ± 2 items) mais un temps d’accès court (Miller
1956);
Durée limitée (volatile) et taux d’oubli sensible à la complexité de la tâche, à la
quantité d’information et aux distractions (Hitch 1987);
Retient davantage les éléments initiaux et finaux d’une série d’items.
Étant donné ces caractéristiques et la quantité d’informations qu’elle reçoit (environ
100 000 fois plus qu’elle ne peut en traiter), la mémoire à court terme est souvent le goulot
d’étranglement du système cognitif.
La mémoire à long terme, quant à elle, contient de l’information permanente qui a été
assimilée suite à un processus d’apprentissage. Elle est caractérisée de la manière suivante :
Capacité et durée illimitées mais temps d’accès plus long que la mémoire à court
terme;
Information stockée de façon complexe, dynamique et en constante réorganisation
(réseaux sémantiques);
Effort requis pour traiter, organiser et enregistrer l’information ainsi que pour
l’extraire par la suite. L’intensité de l’effort varie selon le niveau d’expertise et la
fréquence d’utilisation.
2.1.2.4 Cognition externe
Pour palier à ses limites cognitives, notamment celles de la mémoire à court terme,
l’humain a recours à des objets et des représentations externes qu’il manipule en vue
d’accomplir des tâches complexes, principe que l’on nomme cognition externe. Des
artéfacts physiques comme du simple papier et un crayon, en passant par la calculatrice
jusqu’à l’ordinateur, lui permettent d’augmenter ses capacités cognitives. On considère
également le langage, l’arithmétique et autres formalismes logiques comme des artéfacts
mentaux.
22
Considérant tous ces faits sur la cognition, il conviendra d’en tenir compte lors de la
conception de systèmes d’information centrés sur l’humain.
2.1.3 Compréhension
2.1.3.1 Définitions
Comme pour la connaissance, la compréhension peut se définir de plusieurs manières
dépendant du point de vue. Purement et simplement, on peut dire que la compréhension est
de la connaissance assimilée. Elle implique la découverte de certaines relations logiques
autour d’un concept concernant sa nature même. Plus formellement, la compréhension peut
être définie comme un processus psychologique relié à une entité physique ou abstraite
(une personne, une situation, un message) sur laquelle on peut poser une réflexion et
utiliser des concepts permettant d’interagir avec elle. C’est le fait d’être conscient qu’il
existe des interrelations entre les informations et de pouvoir mettre la connaissance en
pratique.
En considérant ces liens entre concepts comme unité de base de la compréhension, on peut
lui appliquer l’échelle suivante où chaque échelon correspond à un niveau de
compréhension plus approfondi que le précédent (Funke, 1993) :
Relationnel : Existence ou non-existence d’une relation ou d’un lien quelconque
entre des concepts;
Signe : Identification de la ou des directions de ce lien;
Numérique : évaluation quantitative où l’on peut mettre un certain poids sur son
intensité ou son importance.
L’échelle de classification des niveaux de compréhension présentée ci-après se base plutôt
sur les étapes progressives d’une démarche d’analyse que l’on peut faire sur des
connaissances à propos d’une situation (Levels of Understanding 2009):
Littéral : Se limite simplement à l’information connue, aux faits et à la description
des facteurs impliqués dans la situation analysée;
23
Latéral : Mise en contexte des faits (histoire, politique, géographie); comparaison
avec d’autres situations du même type et analyse de ses effets; mise en relation des
parties impliquées;
Critique : Réflexion sur ce qui se produit réellement, ainsi que sur les origines et les
causes de la situation, ce qu’elle implique;
Spéculatif : Hypothèses sur ce qui se produira dans l’avenir et sur les effets
possibles de certains changements éventuellement apportés, qui pourraient empirer,
améliorer ou même résoudre le problème.
En psychologie, on définit le « sensemaking » comme un processus de prise de conscience
d’une situation et de sa compréhension de manière à pouvoir agir de manière informée et
selon des principes définis (Alberts et Hayes 2006).
2.1.3.2 Modèle mental
Un modèle mental est un ensemble de mécanismes par lequel les humains peuvent décrire
la forme et l’utilité d’un système, expliquer son fonctionnement ainsi que ses états
observés, pour ensuite pouvoir prédire ses états futurs. C’est un outil interne dynamique,
relativement durable et accessible mais limité, qui permet de percevoir, simplifier et mettre
en contexte des problèmes complexes (Rouse et Morris 1986). Comme tout modèle, il
s’agit d’une représentation imparfaite ou incomplète de la réalité qui se limite à une portion
de cette dernière (Doyle et Ford 1998).
Il s’agit cependant d’un outil utile mais seulement observable de manière indirecte. Il peut
être inféré par l’observation de comportements, d’actions, ou de verbalisations de la
personne sous forme d’interviews ou questionnaires. Il peut également être explicité par
l’utilisateur lui-même à l’aide de diagrammes, schémas heuristiques ou cartes conceptuelles
(mind map).
2.1.3.3 Heuristiques
Les heuristiques sont des raccourcis mentaux permettant d’arriver rapidement à un
jugement ou une prise de décision satisfaisante. Elles permettent de diminuer le temps et
l’effort requis pour l’exécution d’une tâche ainsi que le traitement d’une plus grande
24
quantité d’information dans des contextes complexes. Quoiqu’utiles et souvent essentielles
dans des situations où s’exerce une certaine pression temporelle, l’utilisateur doit s’en
méfier car cela peut mener à de mauvais jugements et être la source d’erreurs. Dans des cas
où l’on désire mesurer le niveau de compréhension, il faut aussi s’en méfier car elles
peuvent mener à de bonnes performances de la part d’un utilisateur sans que ce dernier ait
une véritable compréhension du système (Jobidon 2008).
2.2 Complexité
Alors que la complexité a toujours fait partie des activités humaines, son niveau a
considérablement augmenté suite aux avancées majeures qu’ont connus de nombreux
domaines dont les technologies de l’information. La rapidité avec laquelle ces avancées se
produisent est également une conséquence des nouvelles interactions qui se sont créées
entre des domaines de recherche à l’origine indépendants; ces nouveaux liens de plus en
plus nombreux contribuent également à l’augmentation du niveau de complexité (Poussart
2006).
Les systèmes complexes englobent une grande variété de situations pour lesquelles il n’y a
pas vraiment de théorie unifiée; chaque domaine approche la complexité selon ses besoins,
et c’est ce que nous tenterons de faire le mieux possible dans ce mémoire.
L’incapacité de bien interagir avec une situation complexe mène souvent à une perte de
contrôle ou à des prises de décision non-optimales, d’où l’intérêt grandissant de trouver des
moyens pour améliorer la compréhension et l’interaction avec ce type de situation.
2.2.1 Définition : complexe versus compliqué
D’abord, il est impératif de faire la distinction entre une situation qui est complexe ou qui
ne l’est pas. Les auteurs (Kurtz et Snowden 2003) proposent la classification suivante :
Situation simple (connue) : les patrons qui régissent la situation sont connus et les
relations de cause à effet sont perceptibles et prédictibles;
Situation compliquée : les relations sont non-linéaires, impliquent des variables
intermédiaires ou font intervenir de très grandes quantités de données. Les patrons
25
qui régissent la situation peuvent être découverts par inférence et une analyse
approfondie;
Situation complexe : Les relations ne sont cohérentes qu’après une analyse
rétrospective de la situation et ne se répètent pas au cours du temps.
Situation chaotique ou aléatoire : Il n’y a pas de relations ou de patrons perceptibles
dans les données.
Certaines situations, en apparence compliquées, sont difficiles à analyser en raison du très
grand nombre d’éléments qui les composent; ce peut n’être cependant qu’une question de
temps pour que la situation vienne à portée de compréhension, grâce à de nouvelles
théories, à des modèles ou ressources de calcul disponibles. Dans de tels cas, le principe de
réductionnisme, c’est-à-dire la segmentation du système complet en composantes
individuelles et leur isolation à la manière de « boîtes noires », peut être appliqué. Ainsi, le
comportement du système entier peut être prédit de manière fiable et précise (Poussart
2006).
Une situation dite complexe, selon notre définition, ne peut être analysée selon cette
méthode. Les composantes individuelles, s’il est possible de les identifier, ne peuvent pas
prédire correctement le comportement du système entier à cause d’autres phénomènes et
interactions qui interviennent. Ces caractéristiques, propres aux situations complexes, sont
décrites dans la section qui suit.
2.2.2 Caractéristiques de la complexité
La complexité peut se manifester sous de nombreuses formes et dans une très grande
variété de contextes, comme en témoignent les caractéristiques suivantes (Hübler 2005),
(Poussart 2006) :
Boucles de rétroaction et patrons de comportement non-linéaires : Les composants
d’un système complexe comportent des liens circulaires et entrelacés, des fonctions
de croissance ou de décroissance exponentielles, des oscillations, des délais, ainsi
que des combinaisons multiples de ces derniers éléments, rendant impossible
l’analyse linéaire de cause à effet. Souvent, les valeurs quantitatives de ces
26
comportements ne sont pas tangibles, c’est-à-dire que l’on ne peut pas les mesurer à
l’aide d’instruments. Les systèmes complexes relevant des domaines symbolique et
social en sont des exemples;
Récursivité : Un système complexe, vu à l’échelle macroscopique, peut être
composé de nombreux sous-systèmes qui sont également complexes à une échelle
microscopique (un organisme vivant, par exemple);
Sensibilité aux conditions initiales : Un très léger changement au niveau des
conditions initiales peut engendrer de grandes variations dans le comportement
futur du système, le rendant tout à fait imprévisible;
Frontières floues : La frontière entre le fonctionnement interne du système
complexe et son interaction avec l’extérieur n’est pas claire et précise, mais plutôt
arbitraire. La segmentation du système interne en plusieurs entités pose un
problème de même nature;
Compréhension – complexité et observateur : La complexité sera perçue
différemment tout dépendant de l’échelle de temps ou d’espace de laquelle elle est
observée. Également, l’observateur, en fonction de son expérience et de son
domaine d’étude, amène une dimension très subjective à l’évaluation d’une
situation complexe, que l’on ne retrouve pas dans les démarches réductionnistes;
Système en évolution : Les actions posées sur un système complexe influencent non
seulement ses entités mais aussi l’ensemble des connexions qui les unissent. Ce
dynamisme fait en sorte que la nature même du système complexe évolue avec le
temps; l’application d’une quelconque forme de contrôle sur cette évolution est
donc un défi de taille;
Lien traditionnel de cause à effet perturbé : À cause des nombreuses interactions
imprévisibles entre les agents, il est pratiquement impossible d’isoler
individuellement les causes et leurs effets;
27
Opacité : Il est difficile ou impossible de mesurer certaines données ou relations
entre ces dernières et d’observer les effets des interactions avec le système. Certains
paramètres restent cachés ou sont plus ou moins pertinents, ce qui brouille le
portrait d’analyse;
Pas de contrôle centralisé : En général, les systèmes complexes n’obéissent pas à
une entité maîtresse qui dirige toutes les opérations. Quoique cela puisse être un
avantage du point de vue de la robustesse puisqu’il n’y a pas d’élément critique
pouvant causer une défaillance majeure, cela peut être une source d’instabilité à
cause d’une plus grande sensibilité aux perturbations légères.
Lorsque l’on recherche des aspects plus déterminants, communs à tous les systèmes
complexes, ce sont les deux caractéristiques suivantes qui se distinguent :
Auto-organisation : C’est un processus dynamique par lequel le système complexe
peut s’adapter et maintenir sa structure sans intervention extérieure;
Émergence : On considère qu’il y a émergence lorsque des patrons, des structures,
des comportements ou d’autres propriétés cohérentes de haut-niveau apparaissent
suite aux interactions de bas-niveau entre les composants du système.
2.3 Ingénierie des systèmes
Dans cette section sont regroupés des aspects théoriques et des recommandations en ce qui
a trait à la conception de systèmes contrôlés par des utilisateurs humains. À ce titre, les
aspects cognitifs y prennent une place importante. On présente en premier lieu un portrait
des utilisateurs de systèmes d’information, des points de vue général et spécifique aux
experts, dans un contexte de design d’interfaces. Par la suite, une liste de besoins auxquels
un système centré sur l’humain devrait répondre est dressée. Finalement, divers principes
de design concernant les interfaces personne-machine ainsi que des recommandations
visant à réduire la charge mentale sont présentés.
28
2.3.1 Profil des utilisateurs
2.3.1.1 Considérations générales
Le succès de développement d’une interface pour un système est souvent difficile à
atteindre pour de multiples raisons, notamment à cause d’une incompréhension entre
concepteurs et utilisateurs en ce qui a trait aux besoins, aux spécifications fonctionnelles du
système et aux possibilités technologiques. En général, on peut difficilement se fier aux
futurs utilisateurs concernant la conception, l’optimisation et la prévision de contraintes à
venir. Ils pensent en termes de logique d’utilisation alors que les concepteurs pensent en
termes de logique de fonctionnement. Cependant, les utilisateurs peuvent faire preuve de
créativité, d’imagination et de jugement.
2.3.1.2 Experts
Quoique les informations précédentes amènent certains faits généraux sur de potentiels
utilisateurs, il importe de mentionner que le système d’aide à la compréhension développé
sera également utilisé par des gens possédant une expertise dans un domaine donné qui sont
confrontés à des situations complexes et savent les gérer, ou du moins y faire face, en
fonction de cette expertise.
Ces experts se distinguent d’abord par des traits psychologiques forts comme une confiance
en soi élevée, un bon sens des responsabilités ainsi qu’une grande aisance pour la
communication à l’usage formel de vocabulaire spécialisé. Ils ont également des
compétences pour prendre des décisions difficiles en situation de stress; ils ont des
aptitudes à déceler les cas d’exception en plus de savoir délibérer de façon naturelle sur un
plan d’action. Ils sont également habiles à utiliser des stratégies décisionnelles en suivant
des processus rigoureux, en sachant décomposer les problèmes complexes et en anticipant
des décisions d’action, tout en gardant une bonne vue d’ensemble du problème.
Les experts, malgré leurs nombreuses qualités, sont avant tout des humains et ils sont
assujettis à certaines limitations cognitives, notamment au niveau de la charge mentale.
Leur expérience et leurs solides connaissances peuvent leur jouer des tours en ce qui a trait
aux heuristiques, comme appuyer une décision sur des signes contradictoires
(représentativité), simplifier à l’excès une situation problématique (disponibilité) et résister
29
aux changements (ancrage). Des études ont enregistré des baisses de performance dans
l’exécution de tâches comportant les caractéristiques suivantes : stimuli dynamiques vs
statiques, décisions sur des comportements vs des choses, tâches uniques vs répétitives, etc.
(Shanteau 1992). En ce qui a trait aux phénomènes complexes, il a été souvent observé que
les gens éprouvent des difficultés à traiter un système impliquant des relations entre plus de
4 variables, de prédire des comportements et de porter des jugements adéquats, même s’il
s’agit d’évaluateurs expérimentés et que toute la structure et les paramètres du système sont
connus.
2.3.2 Systèmes cognitifs
Les théories présentées dans cette section s’apparentent au domaine de la macrocognition,
qui délaisse l’étude approfondie de composantes élémentaires de la cognition humaine pour
s’intéresser aux systèmes dans leur globalité et ce qui touche de plus près des tâches de la
vie réelle. Le principe du « cognitive fit », qui consiste à présenter l’information de manière
conforme au type de traitement que l’humain doit en faire, résume bien l’objectif recherché
par ces théories (Hollnagel et Woods 1983).
2.3.2.1 Triade
Il s’agit d’un modèle stipulant que la performance atteinte avec un système dépend de trois
éléments interconnectés : le monde externe ou le domaine, les agents humains et artificiels
qui y interagissent et les artéfacts ou représentations externes. Le monde englobe des
caractéristiques qui influencent la charge cognitive requise à l’exécution de la tâche et qui
peuvent être de nature complexe. Le nombre d’éléments à contrôler, les embûches à éviter,
les risques, la dynamique et le couplage entre les éléments sont des facteurs appartenant à
cette partie. Les facteurs relatifs aux agents regroupent les aspects cognitifs humains et les
communications avec les agents artificiels. Les artéfacts touchent les modes de
représentation de l’information provenant du monde (Woods et Roth 1988).
30
2.3.2.2 Besoins de support fondamentaux
Un système cognitif devrait répondre aux cinq besoins suivants correspondant à des
fonctions cognitives spécifiques qui y sont associées (Christoffersen et Woods 2002):
Observabilité : Surveillance adéquate de la situation. Doit être efficace en termes de
détection de changements (« change blindness »);
Dirigeabilité : Concerne la planification et la coordination. Doit permettre
d’entreprendre, d’interrompre et de reprendre des tâches concurrentes de façon
dynamique selon les priorités;
Attention dirigée : Contrôle de l’attention et de la direction vers laquelle elle est
portée. C’est une fonction importante pour les tâches où l’utilisateur doit par
exemple choisir une cible à l’intérieur d’un court laps de temps. Doit éviter les
sources de distractions (auditives notamment);
Résilience : Doit être adaptable et résistant aux perturbations;
Monde Agents
Artéfacts
Stratégies
Dem
andes
Repré
senta
tions
Discipline
d’application
Figure 2-4 : Principe de la triade
(d’après Woods & Roth, 1988)
31
Travail d’équipe : Supporte une certaine dimension sociale qui facilite le partage et
la communication de l’information. La capacité cognitive d’une équipe est en
général plus élevée que la somme des capacités individuelles de ses membres.
2.3.2.3 Principes HCI
Les principes HCI (Human-Computer Interfaces ou Interfaces Personne-Machine) ont pour
objectif de guider la conception de la meilleure interface possible pour un système en
fonction des contraintes de tâches et de la classe d’utilisateurs, et peuvent s’appliquer à une
large sphère de domaines (Tremblay, Lafond et Gagnon 2008).
« Affordance » (ou potentialité): Utilisation d’éléments visuels clairs et selon les
attentes de l’utilisateur;
Structure : Regroupement spatial des items suivant leur similarité ou le type de
fonctionnalité;
Consistance : L’apparence, la position et le comportement des éléments sont faciles
à apprendre et à retenir;
Tolérance aux fautes : Permet de revenir facilement en arrière en cas d’erreur ou
avertit l’utilisateur de manière élégante lorsque cela est impossible. Implante des
mécanismes qui préviennent et empêchent les occurrences d’erreurs;
Facilité de navigation : Utilise des métaphores de contrôles adaptées, permet à
l’utilisateur de prendre des raccourcis et de créer ses propres patrons.
2.3.2.4 Réduction de la charge mentale
Comme il a été mentionné dans une section précédente, la charge mentale est l’effort requis
pour l’exécution d’une tâche, ce qui demande à l’utilisateur une certaine quantité de
ressources qui sont limitées. Il peut donc devenir rapidement surchargé à cause de
limitations au niveau de la mémoire de travail notamment. Un mauvais design d’interface
ou une mauvaise utilisation de la technologie peuvent augmenter inutilement la charge
mentale, diminuant ainsi les ressources disponibles pour l’exécution de la tâche principale.
Dans les cas où ces tâches visent la compréhension de situations complexes, il est impératif
32
de ne pas surcharger mentalement l’utilisateur. On présente donc ici une série de
recommandations concernant le design d’interface visant à minimiser cette
charge (Shneiderman 1998):
1. Privilégier la clarté visuelle : La théorie sur le système visuel nous a appris les
tendances de l’humain à regrouper visuellement les éléments. Il peut donc être
avantageux de tirer parti de cela en regroupant ensemble les éléments (chunking). Il
faut également éviter les écarts informationnels : une plus grande quantité de
données affichées n’équivaut pas nécessairement à une plus grande quantité
d’informations assimilées.
2. Prévoir des valeurs par défaut et permettre l’annulation et le rétablissement
d’actions de l’utilisateur (fonctions « undo » et « redo ») : Ceci s’inscrit dans les
politiques de réduction et de tolérance aux erreurs et concerne principalement les
interfaces où l’on doit entrer des données, mais peut inclure toute manipulation
modifiant l’état du système.
3. Soulager la mémoire à court terme : Lorsque l’utilisateur doit suivre une certaine
procédure et surtout s’il n’est pas familier avec cette dernière, il convient de l’inciter
le plus simplement possible à entrer un choix ou une commande lorsque nécessaire
afin de limiter l’effort pour se souvenir ou deviner ce qu’il doit faire.
4. Fournir de la rétroaction visuelle : Il est important de fournir des informations sur
l’état du système afin que l’utilisateur ne soit pas perdu : repères de navigation, type
d’action en cours, autres actions possibles, messages informatifs pendant le
traitement de données, etc.
5. Privilégier la reconnaissance ou la reconstruction plutôt que le rappel : La
reconnaissance exploite des métaphores souvent apparentées au monde réel et se
fait rapidement; la reconstruction fait appel à un certain encodage de l’information;
le rappel implique la récupération d’informations apprises par cœur. Il est plus
facile pour l’humain de se rappeler de la signification des choses plutôt que sa
représentation exacte (pour les acronymes, par exemple).
33
6. Offrir la possibilité de raccourcis : Leur utilisation peut devenir rapidement
automatique avec la fréquence d’utilisation et permet donc d’augmenter l’efficacité.
Évidemment, la conformité aux standards de l’industrie est, dans la mesure du
possible, à privilégier.
7. Privilégier une syntaxe de type objet-action : Comme pour l’approche de
développement orienté objet, il est souvent plus naturel d’offrir des interactions et
des choix associés à un objet alors qu’il est pratiquement inutile de connaître les
actions invalides sur ce dernier (comme les options grisées dans les menus).
8. Utiliser des métaphores du monde réel : Pour les métaphores, quoiqu’elles facilitent
les analogies et le transfert de connaissances, une certaine prudence doit être
exercée dans leur utilisation et une validation auprès de vrais utilisateurs est
encouragée pour s’assurer qu’elles sont correctement interprétées.
9. Privilégier la découverte progressive des fonctions offertes : Il s’agit principalement
de ne montrer à l’utilisateur que ce qui est utile lorsqu’il le souhaite, surtout s’il est
un novice, ce qui lui donne un meilleur sentiment de contrôle. Ceci peut se réaliser
en offrant des listes d’options simples et avancées.
2.4 Exploration
L’un des principaux problèmes auquel les gens de plusieurs disciplines font face est la
croissance et la complexification de l’espace d’information. De plus, la plupart des
systèmes actuels ne sont pas correctement optimisés pour le transfert, l’organisation et la
navigation à travers cette information. Or, on voudrait pouvoir aller explorer au cœur de ces
données et y découvrir des relations, des patrons, en somme des connaissances
approfondies et de haut niveau. Ce genre de tâche étant souvent difficile à réaliser
automatiquement à l’aide d’ordinateurs, il faut se tourner vers les capacités d’analyse de
l’humain. Comme il a déjà été mentionné plus tôt, ce dernier excelle au niveau de la
perception et de l’analyse de données visuelles. Le but de l’exploration est de favoriser une
meilleure compréhension à l’aide de représentations visuelles adaptées au contexte et aux
données.
34
2.4.1 Visualisation d’information
2.4.1.1 Définitions et origines
La visualisation d’information peut être définie comme étant la réduction et la traduction
d’interrelations sémantiques et topologiques de l’espace de connaissances en une
cartographie visuelle interactive tirant avantage des facultés visuelles humaines (Judelman
2004). Il s’agit d’une combinaison entre une représentation visuelle et une interface
utilisateur permettant de manipuler et d’explorer des centaines, voire jusqu’à des millions
d’éléments. Les concepts qui peuvent être représentés sont variés (prix, niveau de stress,
données médicales, taux d’échanges entre organisations, résultats sportifs, etc.) et leurs
représentations visuelles très différentes selon le type de données et l’objectif visé. C’est
d’ailleurs une discipline issue de différents domaines d’étude :
Graphisme;
Statistiques, au niveau de l’analyse de données multidimensionnelles ou à plusieurs
variables;
Visualisation scientifique, qui consiste à reproduire visuellement en 3 dimensions
des phénomènes physiques ou biologiques, notamment en médecine. Les avantages
de ces méthodes sont d’étudier des phénomènes difficiles ou impossibles à observer
à l’état réel, d’améliorer le transfert d’informations disponibles par des
représentations visuelles améliorées par rapport à la réalité, et aussi de remplacer
des expériences coûteuses ou impossibles à réaliser par des simulations visuelles
interactives;
Interfaces personne-machine;
« Data mining », discipline qui étudie la découverte de connaissances par méthodes
mathématiques à des fins de visualisation et d’amplification de la cognition.
2.4.1.2 Objectifs et défis
Pour permettre une compréhension approfondie, une visualisation doit favoriser la
reconnaissance efficace et rapide de patrons dans les données et la révélation de relations a
priori invisibles. Elle devrait en outre suivre les principes suivants :
Agrégation : Regrouper, simplifier et organiser les informations selon leur
apparence, leur forme ou leur structure relationnelle;
35
Abstraction : Permettre l’omission sélective de données en fonction de leur nombre,
de leur ordre de grandeur et de leur pertinence, selon le contexte.
Hiérarchie : Permettre de passer d’un niveau d’abstraction à l’autre à l’aide de
zoom sur les données.
Appréhension : la structure et le contenu de la visualisation sont perçus et compris
efficacement et correctement.
Congruence : la structure et le contenu de la visualisation correspondent à la tâche
et à la représentation mentale que l’on doit s’en faire (Tversky 2009).
Cependant, comme nous l’avons déjà mentionné, il existe certaines limitations techniques
quand à la quantité de données à gérer et leur accessibilité, mais aussi en ce qui a trait au
développement de théories générales permettant la classification et la standardisation des
types de données, ce qui pourrait s’avérer nécessaire pour la réalisation de systèmes
génériques. L’exploration de données dans des espaces à plusieurs dimensions, la mise à
l’échelle et l’étiquetage posent également difficulté. La personnalisation des interfaces
selon les préférences des utilisateurs, le support du travail collaboratif ainsi que des
méthodologies d’évaluation comptent également parmi les défis à relever (Judelman 2004).
2.4.2 Techniques de visualisation
Cette section se veut un résumé d’état de l’art de techniques de visualisation développées
pour des applications variées et divers types de données, et se termine avec quelques
observations et recommandations de la littérature sur les interfaces 3D et immersives.
2.4.2.1 Représentations géographiques
Des développements récents dans les applications de visualisation géographique ont rendu
une immense quantité de données cartographiques accessibles au grand public, notamment
par le biais d’interfaces web. On pense ici à Google Maps et Google Earth (Figure 2-5), qui
offrent des représentations 2D et 3D interactives de la carte du monde. À l’aide d’outils de
navigation (widgets et souris), l’utilisateur peut parcourir toutes les zones géographiques du
monde à diverses échelles de rapprochement, les plus élevées ne montrant que les
informations de haut niveau comme les frontières politiques internationales, et les plus
36
rapprochées détaillant les limites municipales et les réseaux routiers de manière plus ou
moins détaillée selon l’échelle. Des vues par photos aériennes et satellites à résolution
variable sont également disponibles, et il existe une panoplie d’applications connexes
(mapplets) et d’extensions au format KML (Keyhole Markup Language) offrant toutes
sortes de fonctionnalités de visualisation que l’utilisateur peut en tout temps activer ou
désactiver, comme le positionnement GPS, les mesures de distance et d’altitude, la
météorologie et les marées, la consommation d’énergie, les trajets aériens, etc. Ces
fonctionnalités suivent un principe très répandu en visualisation d’information : Vue
d’ensemble Zoom et filtre Détails à la demande.
2.4.2.2 Structure, topologie, hiérarchie
Dans cette section, les méthodes de visualisation présentées se concentrent sur les objets et
leurs relations spatiales ou hiérarchiques. C’est pourquoi on y retrouve principalement des
représentations sous forme d’arbres ou de graphes. En plus des représentations
d’arborescences traditionnelles 2D, certaines techniques utilisant le 3D et la géométrie
hyperbolique reconfigurable en temps réel ont été développées afin de maximiser l’espace
utilisé et la quantité de données représentable dans un espace restreint, en ne mettant au
premier plan que l’information demandée par l’utilisateur (Figure 2-6). Le même principe
est également utilisé pour des représentations radiales ou circulaires imbriquées (Figure
2-7).
Figure 2-5 : Google Earth, représentation de trajets aériens et de densité de population
(Google 2009)
37
Une autre manière ingénieuse de représenter des données hiérarchiques sur un plan 2D est
de diviser cet espace en secteurs où chacun d’eux représente une branche de l’arbre, et sur
lequel on applique un code de couleur qui peut représenter une quantité, une densité ou un
type de données (technique du TreeMap, Figure 2-8). Dans la même lignée de
représentation visuelle cartographique, mais plus inusitée, une représentation de
l’empreinte littéraire de la Bible a été réalisée où chaque rectangle, représentant l’un de ses
livres, est teinté selon un code de couleur exprimant la longueur des phrases. Il est donc
possible d’un seul coup d’œil d’analyser grossièrement le style littéraire utilisé dans
différents livres (Figure 2-9).
Figure 2-7 : Représentation circulaire imbriquée
(Fractal:Edge 2009)
Figure 2-6 : Représentations hyperbolique et radiale
(CAIDA 2007)
38
2.4.2.3 Relations sémantiques
Exploitant aussi des représentations cartographiques, les techniques de visualisation de
relations sémantiques font ressortir les ressemblances et différences entre les éléments d’un
ensemble de données. La plupart des systèmes implémentant ce type de visualisation sont
des logiciels de recherche de documents ou de pages web permettant de regrouper
visuellement les résultats par mots-clés ou quelque autre critère. Les techniques utilisées
permettent de représenter les relations entre plusieurs critères à la fois en jouant sur les
formes et l’affichage de liens (Figure 2-10).
Figure 2-9 : Empreinte littéraire de la Bible
(Keim et Oelke 2007)
Figure 2-8 : TreeMap (SequoiaView)
(TU/e 2009)
39
2.4.2.4 Données temporelles
Le paramètre temps est souvent une variable particulière qui est déterminante dans la
manière de visualiser le problème auquel elle se rapporte, d’où l’intérêt de mentionner des
techniques de visualisation qui lui sont spécifiques.
Les graphiques 2D traditionnels sont évidemment très répandus pour voir l’évolution d’une
ou plusieurs variables par rapport au temps, mais certaines techniques permettent
d’améliorer le rendu graphique et l’exploration des données lorsqu’elles sont très
nombreuses. L’exemple de la Figure 2-11 montre une représentation de la densité des
données par rapport au temps, par l’intensité de la couleur, plutôt que chacun des points.
Ceci permet de garder l’intérêt d’une vue globale sur les données qui autrement deviendrait
inutilisable à cause de l’occultation ou du manque de résolution.
Figure 2-10 : Exemples de représentations sémantiques
(Aduna 2007), (Netzpannung 2007)
40
Une autre manière d’exprimer la densité en fonction du temps est celle du diagramme
« rivière » (Figure 2-12), où la quantité de données en rapport à des catégories données à un
instant donné est représentée par l’épaisseur de traces de couleur. Il est donc possible de
voir rapidement des tendances générales ou spécifiques quand à l’ampleur des données. Le
second exemple, à la Figure 2-13, montre un diagramme formé de cercles concentriques où
sont représentés divers types d’événements d’alertes de sécurité, du plus récent au plus
ancien partant de l’intérieur du cercle.
Il est également possible d’aller plus en détail dans l’exploration temporelle en y consacrant
plus d’une dimension. La Figure 2-14 montre un exemple où les variables X et Y sont
dédiées respectivement à la journée et à l’heure d’observation des données, permettant de
Figure 2-13 : Représentation circulaire
(Foresti, et al. 2006)
Figure 2-12 : Diagramme « rivière »
(ThemeRiver 2009)
Figure 2-11 : Vues globale et rapprochée d'une représentation de données par densité
(Jerding et Stasko 1998)
41
voir des tendances au fil des jours et d’identifier rapidement les heures de pointe de
consommation d’énergie.
Pour représenter des événements ou d’autres données non numériques, des diagrammes de
type Gantt ou « ligne du temps » sont préférables, et une utilisation judicieuse du 3D
permet de maximiser la quantité d’information affichée dans l’espace disponible. Le
premier exemple en Figure 2-15 en fait usage pour représenter de nombreuses images
associées à une position spécifique sur un plan 2D, mais en utilisant la 3D pour les projeter
constamment vers la caméra. Le second exemple utilise l’effet de perspective pour
visualiser une plus grande partie de la ligne du temps tout en gardant les données d’intérêt
pleinement visibles au centre (Figure 2-16).
Figure 2-14 : Visualisation à 2 dimensions temporelles
(van Wijk et van Selow 1999)
42
2.4.2.5 Focalisation et contexte
On entend par focalisation et contexte (focus + context) les méthodes qui adaptent la
visualisation de manière à mettre en évidence ou afficher en détails seulement une partie
des données disponibles selon les désirs de l’utilisateur. Ceci est réalisé à l’aide de diverses
techniques permettant de comprimer et d’étendre l’espace d’affichage. La représentation de
données tabulaires de la Figure 2-17 permet l’exploration d’un grand nombre de données
numériques grâce à un système d’histogrammes et seule une zone particulière permet de
représenter les valeurs numériques précises, un peu à la manière d’une loupe. Le même
genre de résultat est obtenu pour un menu de sélection à la Figure 2-18, mais en utilisant
une méthode de distorsion. Enfin, l’usage d’effets de flou peut également être très utile
pour mettre l’accent sur des éléments ou des zones d’affichage spécifiques, comme le
montre la Figure 2-19.
Figure 2-16 : Mur en perspective
(Daassi 2003)
Figure 2-15 : Ligne du temps
(Kullberg 1995)
43
Figure 2-19 : Effet de flou
(Kosara, et al. 2002)
Figure 2-18 : Effet de distorsion
(Bederson 2000)
Figure 2-17 : Exploration tabulaire avec loupe sur les données
(Rao et Card 1994)
44
2.4.2.6 Espaces à plusieurs dimensions
Il est relativement aisé de représenter des fonctions de trois variables dans un espace à trois
dimensions; il est également possible de dépasser ce nombre en utilisant d’autres repères
visuels comme la couleur, la forme ou la grosseur des points. Mais lorsque le nombre de
variables est beaucoup plus grand, d’autres méthodes peuvent être nécessaires pour faire
une première analyse permettant d’identifier autour de quels paramètres et de quelles
valeurs de ces derniers on retrouve des patrons, des tendances ou tout autre phénomène
d’intérêt. La technique des coordonnées parallèles vient en réponse à ce problème. Elle
permet de représenter des ensembles discrets de données à n dimensions, où n axes
verticaux représentant chacun des paramètres du problème sont disposés parallèlement
entre eux, et pour chaque donnée multidimensionnelle, une ligne brisée parcourt ces axes
suivant les valeurs correspondantes. Des techniques de brushing, qui sont des méthodes de
sélection de données spécialisées à ce type de graphique, permettent d’isoler des sous-
ensembles de données et de détecter des corrélations.
2.4.3 Considérations de design
Certaines considérations supplémentaires ont été soulevées dans la littérature concernant le
design de systèmes visuels et de leurs interfaces, notamment l’importance de s’approprier
certaines connaissances en psychologie cognitive, ce qui a été démontré dans les sections
précédentes. Le domaine des arts visuels peut également être une source d’inspiration pour
le design de représentations graphiques. Également, l’inclusion de techniques de calcul
Figure 2-20 : Coordonnées parallèles
(Hauser, Ledermann et Doleisch 2002)
45
permettant de faire un prétraitement des données, basées sur des théories mathématiques, de
l’intelligence artificielle ou autres, n’est pas à exclure si on a affaire à de larges espaces de
paramètres ou d’immenses quantités de données, au point où la limite de « bande
passante » vers le cerveau serait atteinte.
46
3 Module Exploration
Ce chapitre fait état de la démarche effectuée dans le développement de la première version
du module Exploration du projet IMAGE. On débute par la présentation des plateformes
logicielles retenues pour les développements ainsi qu’un compte rendu des premières
phases de test et de prototypage avec celles-ci. L’implémentation d’une solution pour le
transfert et le traitement de données de simulation XML est par la suite présentée.
Finalement, les paradigmes de visualisation développés pour le volet tactique du scénario
du projet IMAGE ainsi que les mécanismes de gestion de données et de synchronisation
nécessaires sont expliqués.
3.1 Plateformes logicielles
Comme nous l’avons mentionné dans l’introduction, l’utilisation de technologies déjà
disponibles est de mise afin de limiter les efforts de développement. À cet égard, diverses
plateformes logicielles ayant un potentiel intéressant pour répondre à nos besoins ont été
étudiées et utilisées au cours du projet. Cette section présente une description sommaire des
fonctionnalités et caractéristiques générales de chacune de ces plateformes; des détails plus
techniques et spécifiques aux développements seront présentés dans les sections suivantes.
3.1.1 ACE
ACE (Adaptative Communication Environment) est
un framework C++ open-source orienté objet
implémentant plusieurs patrons de base utilisés dans
les processus de communication pour des tâches telles
que la gestion, le routage et la distribution
d’événements et de signaux, les communications
interprocessus, la gestion de mémoire partagée, la
gestion dynamique de services distribués et la
synchronisation. Il vise à simplifier le développement d’applications haute-performance et
temps-réel requérant l’exécution de ces types de tâches, et il supporte une grande variété de
systèmes d’exploitation dont Windows et plusieurs distributions de Linux, ainsi que de
Figure 3-1 : Logo ACE
47
nombreux compilateurs. C’est un framework ayant plusieurs qualités logicielles comme la
portabilité, la flexibilité, l’extensibilité, la réutilisabilité et la modularité (Schmidt 2009).
3.1.1.1 Composantes logicielles
Comme on peut l’observer sur la Figure 3-2, ACE se divise en plusieurs couches
d’abstraction :
ACE OS Adaptation Layer, qui se situe directement au-dessus de l’API C du
système d’exploitation et qui isole les autres composants de tout ce qui est
spécifique à la plateforme;
C++ Wrappers, qui encapsulent plusieurs aspects de bas niveau et facilitent le
développement en offrant la possibilité d’hériter et d’instancier de nombreuses
classes.
Frameworks, offrant des possibilités supplémentaires pour la programmation haut-
niveau de services et d’applications réseau en utilisant des « templates » C++ ainsi
que des patrons de conception tels que Abstract Factory, Strategy et Service
Configurator.
48
ACE inclut également d’autres librairies de services distribués de haut niveau et une
implémentation de CORBA (ACE TAO).
3.1.1.2 ACEXML
Il s’agit d’un composant connexe de ACE basé sur la norme SAX 2.0 (Simple API for
XML) permettant d’intégrer des fonctionnalités de filtrage XML à diverses applications. Il
ne supporte pas entièrement pour l’instant toutes les fonctionnalités requises spécifiées par
la norme XML mais des développements à cet égard sont envisagés dans le futur.
3.1.2 MySQL
MySQL est l’un des systèmes de gestion de bases de
données les plus populaires au monde, utilisé autant par le
grand public que par les professionnels, et en particulier les
applications Web dont celles de grandes entreprises telles
que Google, Yahoo, Wikipedia et YouTube. C’est un serveur de BD relationnelles SQL
Figure 3-2 : Structure du framework ACE
(Schmidt 2009)
Figure 3-3 : Logo MySQL
49
multiutilisateur et multitraitement, axé sur la performance élevée en lecture, la fiabilité et la
robustesse. Il est supporté par une très grande variété de systèmes d’exploitation et de
langages de programmation, mais surtout utilisé conjointement avec Linux, Apache et PHP;
les initiales des noms de ces plateformes, incluant MySQL, se sont d’ailleurs vues
regroupées pour former l’acronyme « LAMP », les désignant comme un ensemble de
logiciels libres permettant de mettre en place des serveurs Web. La popularité de MySQL
vient d’ailleurs en partie du fait qu’elle permet à de nombreuses entreprises de diminuer
significativement leurs coûts en licences, en équipements informatiques, en administration,
en entretien et en support technique.
MySQL doit être utilisé conjointement avec un moteur de BD, pouvant en gérer plusieurs
au sein d’une même base dans des tables différentes, ce qui permet une certaine
optimisation selon l’utilisation. Le moteur de base est MyISAM, il est simple à utiliser mais
il ne supporte pas les transactions ni les clés étrangères, qui sont des mécanismes
nécessaires au maintien de l’intégrité de la BD. Une alternative, qui est souvent adoptée par
défaut, est le moteur InnoDB qui supporte ces mécanismes d’intégrité mais implique
également des fichiers plus volumineux (Sun Microsystems 2009), (MySQL 2009).
3.1.2.1 MySQL Connector/ODBC
Il existe une série de modules nommés Connectors supportés par MySQL permettant à
diverses plateformes comme Java et .NET de s’y connecter et d’y interagir. MySQL
Connector/ODBC permet de le faire par le standard de l’industrie Open DataBase
Connectivity. Certaines applications commerciales offrant des fonctionnalités d’importation
à partir de BDs utilisant ce standard nécessitent que ce module soit installé afin que
MySQL leur soit accessible.
3.1.2.2 MySQL++
Il s’agit d’une librairie de classes C++ qui
encapsulent l’API C de MySQL. Elle se base sur les
principes de fonctionnement de la STL (Standard
Template Library) dans le but de rendre les fonctions
de manipulation de données similaires à celles des
Figure 3-4 : Logo MySQL++
50
structures STL (std::vector, std::string, etc.). Des fonctionnalités facilitant certaines tâches
MySQL fréquentes et répétitives sont également implémentées.
Sa structure relativement simple permet son intégration et son utilisation faciles et rapides.
Il y a 4 types d’objets principaux : connexion, requête, résultats et exceptions; à chacun de
ces types est associée une hiérarchie de classes dérivées spécialisées. Un objet de type
connexion ou de l’une de ses spécialisations (montrées dans le diagramme de classes de la
Figure 3-5) doit d’abord être instancié. Il permet d’ouvrir la communication avec la BD par
l’appel d’une fonction à laquelle il faut spécifier les paramètres du serveur MySQL à
contacter (adresse, port, etc.). L’objet connexion permet également de créer des instances
de requêtes lorsqu’une commande textuelle SQL lui est fournie par la fonction appropriée.
D’une instance de requête, on peut finalement obtenir un ensemble de résultats dont on
peut parcourir le contenu à la manière d’un std::vector.
Quelques fonctionnalités avancées sont également disponibles comme les Structures SQL
Spécialisées (SSQLS) permettant de créer des structures de données ou classes qui
correspondent aux tables de la BD. Le principe de base est d’avoir une variable membre par
champ de la table en question, mais aussi de fournir d’autres méthodes et opérateurs
facilitant leur manipulation. Il est également possible de mettre en place des patrons de
requêtes un peu à la manière de la fonction printf en C, où l’on définit des emplacements
temporaires pour des noms de champs pouvant être modifiés plus tard.
Il existe une branche de projet ayant divergé de MySQL++, nommée MySQL C++ API,
principalement à cause d’idéologies de design différentes. Selon l’auteur de cette branche,
Figure 3-5 : Hiérarchie de la classe mysqlpp::Connection
(MySQL++ 2009)
51
les efforts agressifs et prématurés d’optimisation, le grand nombre de possibilités pour faire
les mêmes tâches au lieu de clairement définir une interface et l’utilisation de macros
obscurcissent le design et ne sont pas convenables pour une librairie C++ (MySQL C++
API 2009).
3.1.3 Tableau Software
Il s’agit d’une suite de logiciels permettant
l’analyse visuelle de données en 2 dimensions.
Quoique ciblant principalement une utilisation dans
le monde des affaires, il est possible d’y importer
n’importe quel type de données provenant de feuilles de travail Excel ou de BDs, pour
ensuite les représenter par des graphiques, histogrammes et nuages de points entre autres
(Tableau Software 2009).
Les atouts par excellence de Tableau Desktop, l’application d’analyse principale de la suite
dont des saisies d’écran sont présentées à la Figure 3-7, se situent au niveau de son
interface utilisateur conviviale ainsi que de sa facilité d’apprentissage et d’utilisation. Parmi
les fonctionnalités offertes par le logiciel, on retrouve la technique du glisser-déposer (ou
« drag and drop »), très intuitive et accessible à presque tous les éléments de l’interface.
Les ensembles de données de diverses grandeurs sont pris en charge automatiquement,
rapidement affichés selon une ou plusieurs dimensions et représentés à l’aide de techniques
visuelles comme la couleur, la forme ou la grosseur des points. Les techniques de zoom et
filtre, de regroupements de paramètres et de calcul de sommes ou de moyennes sur le vif
s’ajoutent aux possibilités d’analyse. Des fonctionnalités de publication et de partage de
données sont également disponibles via une application connexe, Tableau Server,
permettant entre autres de mettre des graphiques interactifs sur le web.
Figure 3-6 : Logo Tableau
52
La Figure 3-8 montre une saisie d’écran commentée de l’interface principale de Tableau
Desktop. À gauche, une fenêtre d’exploration montre une liste des données disponibles
ayant été préalablement chargées, d’où il est possible de faire du glisser-déposer vers les
autres parties de l’interface; les zones des variables ligne et colonne permettent de
déterminer quelles variables seront représentées selon les axes horizontaux et verticaux. On
peut choisir entre plusieurs types de graphiques 2D dont histogrammes, lignes, cercles,
points, etc. Il est possible de filtrer, c’est-à-dire d’enlever certaines données d’un ensemble
particulier de la représentation visuelle en glissant la variable concernée dans la case
Figure 3-7 : Saisies d'écran de Tableau Desktop
(Tableau Software 2009)
53
« filtre » et en configurant son contenu. Le même principe permet d’appliquer un marquage
de couleur ou de grosseur pour une variable en la
plaçant dans le champ correspondant.
3.1.4 Eye-Sys
Eye-Sys est une application de visualisation dont le
but est de regrouper des données provenant d’une
grande variété de sources et d’offrir d’énormes
possibilités de visualisations contrôlées par ces données. À l’origine, elle a été développée
et financée en collaboration avec le Département de la Défense Américaine et d’autres
organisations de recherche. Il s’agit donc d’une plateforme générique et flexible pouvant
être exploitée par une grande variété de domaines scientifiques ou autres.
Le principe de base est d’ajouter au système diverses composantes offrant chacune des
fonctionnalités différentes et de créer des liens de données entre ces dernières. Il y a quatre
Figure 3-8 : Interface principale de Tableau Desktop
Figure 3-9 : Logo Eye-Sys
Explorateur de données
Variables lignes/colonnes
Zone d’affichage
Filtres et marquage
54
familles d’objets disponibles, référés dans Eye-Sys en tant que plug-ins, chacune offrant
une catégorie de fonctionnalités :
Input (entrée de données) : Cette catégorie englobe les importations de données de
tous genres (fichiers texte, BDs, connexion à d’autres applications, dispositifs de
contrôle);
Manipulator (manipulation et calculs) : Ce type d’objet permet la modification de
données déjà importées, typiquement par des calculs mathématiques;
Display Object (objet de rendu graphique) : Tout objet responsable du rendu d’une
composante individuelle de visualisation. Parmi ceux-ci, on compte par exemple
des primitives 3D comme des cubes, sphères ou cylindres, mais aussi des textures et
modèles 3D;
Display System (système de rendu graphique) : Il sert de gestionnaire pour le rendu
de données ou d’objets et prend en charge les fenêtres d’affichage et les interactions
utilisateur via clavier et souris.
Il existe également un objet unique de type Driver permettant de générer des visualisations
dynamiques en faisant varier dans le temps les valeurs contenues dans des vecteurs de
données. Ceci permet par exemple de créer une animation en utilisant des vecteurs de
positions branchés sur les propriétés de translation X, Y et Z d’un objet de rendu.
La Figure 3-10 montre une saisie d’écran de l’interface principale de Eye-Sys. Celle-ci
comporte une fenêtre montrant la liste de tous les objets (plug-ins) disponibles, une sortie
de type « console » pour les messages système, une fenêtre de conception dans laquelle on
peut faire du cliquer-glisser à partir de la librairie d’objets et créer des liens de données, un
éditeur de propriétés permettant de modifier les attributs d’un objet sélectionné, ainsi
qu’une ou plusieurs fenêtres de rendu qui peuvent être 2D comme pour des graphiques
(Plotter) ou panneaux de contrôles (Control Panel), ou 3D pour les systèmes d’arbres de
rendu (Scene Graph Renderer).
55
En complément à ces fonctionnalités, Eye-Sys offre aux utilisateurs la possibilité
d’automatiser ou de personnaliser des comportements grâce à un engin de script ainsi qu’un
SDK pour la programmation C++ ou .NET de plug-ins, ce qui permet aux développeurs de
créer de nouveaux modules sur mesure. De plus, des interfaces COM associées à plusieurs
classes de fonctionnalités permettent à des programmes externes de se connecter sur ces
objets et de contrôler Eye-Sys. Ce dernier offre une grande flexibilité pour son intégration
dans une chaîne d’outils déjà existants. Toutes ces possibilités, offrant généricité et
extensibilité, ont joué un rôle crucial dans l’adoption de Eye-Sys comme outil de
visualisation principal du projet. Ils seront donc expliqués et développés plus en détails
dans la section 3.2.2.
Figure 3-10 : Interface principale de Eye-Sys
(IDV, Inc. 2009)
56
3.1.5 Multichronia
Il s’agit d’un cadre conceptuel de simulation interactive où l’utilisateur est au centre du
modèle d’exploration. Il implémente une interface graphique pour la représentation d’un
espace de simulation appelé arbre multichronique. Ce dernier permet à l’utilisateur de créer
et d’interagir dynamiquement avec de multiples branches de simulation en parallèle. Il offre
d’intéressantes possibilités pour l’analyse et la comparaison de diverses simulations grâce à
des métaphores de navigation et des modes d’interaction innovateurs.
Chaque branche de simulation est représentée par un nœud dans l’arbre multichronique. Le
nœud d’une branche peut être à tout moment sélectionné et déplacé le long de la ligne du
temps. À n’importe quel instant de la simulation, il est possible d’interrompre l’exécution,
de changer la valeur d’un ou de plusieurs paramètres, de créer une nouvelle branche avec
ces modifications et de poursuivre l’exécution de la simulation par la suite, permettant
d’observer les impacts occasionnés par les variations de valeurs de paramètres. Il est
également possible de visualiser d’autres métriques de performance servant à comparer les
résultats, et ce, en cours de simulation.
Figure 3-11 : Saisie d'écran commentée de Multichronia
(Rioux, Bernier et Laurendeau, 2008)
57
L’avantage d’utiliser ce genre de méthode interactive est l’apport de l’expertise et de
l’intuition de l’humain, venant en complément aux méthodes formelles comme le Data
Farming. Multichronia, développé et implémenté dans le cadre du projet de doctorat de
François Rioux (Rioux, 2009), sera utilisé comme outil de contrôle principal dans la
première version de l’outil IMAGE.
3.2 Explorations préliminaires
Au tout début du projet IMAGE, les objectifs globaux étaient relativement bien définis; la
manière de les atteindre l’était cependant beaucoup moins, notamment en ce qui a trait au
module Exploration, ne connaissant que peu ou pas la nature du scénario adopté et les
données à visualiser. Les travaux en Simulation, étant ceux qui étaient les plus avancés, ont
constitué un point de départ intéressant contribuant à diriger les efforts de recherche pour la
partie Exploration.
Comme nous l’avons présenté dans l’introduction, les grandes parties du projet sont liées
entre elles par des liens conceptuels. Cependant, entre Simulation et Exploration, il doit
exister un véritable lien physique de transfert de données. Également, afin de minimiser les
efforts de développement, une évaluation en profondeur des plateformes choisies devait
être faite afin de prendre connaissance de toutes leurs possibilités au niveau de la
visualisation et d’évaluer leur niveau de flexibilité en termes d’intégration avec d’autres
modules. Ces aspects ont mené à l’identification de diverses problématiques et
préoccupations ainsi qu’à des solutions possibles. Les résultats de ces recherches
préliminaires sont présentés dans les sections qui suivent.
3.2.1 Simulation et transfert de données
Afin d’être flexible au maximum en termes de scénarios de simulation, de simulateur et de
types de données à traiter, Multichronia offre un pipe-line de données entièrement
configurable en XML pour les paramètres en entrée, les données intermédiaires traitées par
le simulateur, les métriques et les résultats en sortie. Il fait usage de schémas XML qui sont
des fichiers modèles décrivant la structure arborescente et les types des données de
simulation. Un exemple de document partiel contenant des données de simulation est
présenté à la Figure 3-12.
58
Un nœud principal identifie le type de données ainsi que le nom de la branche de
simulation qui lui est associé. Par la suite, pour chacune des itérations de la simulation, la
liste des variables, métriques et paramètres est donnée de manière hiérarchique selon le
standard XML.
Figure 3-12 : Extrait d'un document XML de données de simulation
59
L’une des premières problématiques à être abordée est le transfert efficace des données du
module Simulation vers le module Exploration. En effet, à chacune des branches de l’arbre
multichronique correspond un flux unique de données brutes en format XML qui est
envoyé dans le pipe-line de données et qui est également sauvegardé sur disque dans un
fichier (Figure 3-13). Ce flux peut être partiel dans les cas où l’on effectue une création de
branche suite à la modification d’un ou de plusieurs paramètres à un instant t différent de
zéro, sur le nœud d’une branche de simulation déjà existante. Il est également possible de
créer et d’exécuter plusieurs simulations simultanément. Quoiqu’incluse dans le schéma
conceptuel, dans le cadre du projet IMAGE, l’exploration de l’espace visuel par le rendu
graphique n’est pas implémentée et n’est pas gérée directement par Multichronia; les
données doivent donc être transférées à l’externe. Pour ce transfert, Multichronia offre,
grâce à un module de gestion des flots de données, un système de connexion par
client/serveur socket TCP où à chaque flux de données correspond une connexion distincte,
ce qui facilite la gestion des données lors de transferts multiples.
3.2.2 Application Eye-Sys
Le rendu graphique de Eye-Sys est entièrement réalisé avec OpenGL. Cependant, il ne
s’agit pas d’un engin de simulation ou de rendu graphique de type « jeu », et il n’y a donc
pas de support pour les phénomènes physiques comme la gravité ou la gestion de collisions.
Figure 3-13 : Schéma conceptuel de Multichronia
(Rioux, Bernier et Laurendeau 2008)
60
Toutes les données relatives aux mouvements et aux comportements visuels doivent avoir
été générées au préalable et importées dans Eye-Sys. Cependant, ce dernier offre une
multitude de possibilités pour faire cette importation, pour des manipulations et des calculs
en temps réel sur les données d’entrée fournies; à la limite, il est possible de générer des
ensembles de données manuellement (voir la section 3.2.2.3 sur les scripts).
Les fonctionnalités disponibles sont encapsulées dans divers modules appelés plug-ins
(comme décrit précédemment à la section 0) et l’interaction avec ces derniers se fait par le
biais de propriétés. Celles-ci peuvent être de plusieurs types, s’apparentant à ceux des
langages de programmation : entier, réel, booléen, chaîne de caractères, pointeur d’objet,
etc. Les transferts de données entre les plug-ins se font grâce à des liens unidirectionnels
entre les propriétés, créés et modifiés via la fenêtre d’édition de l’interface (sandbox). Les
valeurs de ces propriétés, numériques ou autres, sont automatiquement transférées de la
propriété source vers la propriété cible et l’état du plug-in cible mis à jour par le framework
si nécessaire.
3.2.2.1 Création de visualisations 2D et 3D
L’intérêt principal d’utiliser Eye-Sys est de pouvoir créer des vues facilement. Des
ébauches de visualisations ont été réalisées lors des premières étapes d’exploration visant
principalement à démontrer les possibilités de la plateforme et pour donner un aperçu du
type de représentations qu’il est possible d’obtenir. Ces résultats sont présentés sur les
figures 3-14 à 3-16.
Sur le thème du convoi militaire, une scène statique faisant l’usage de modèles 3D de
véhicules militaires et de bâtiments, ainsi que de textures désertiques, a été créée (Figure
3-14). Des plug-ins prenant en charge les textures et les modèles au format 3D Studio Max
(3DS) permettent de charger instantanément toutes sortes de modèles dans une scène de
rendu. La Figure 3-15 montre une partie de la fenêtre de conception de cette scène; on y
remarque la présence de plusieurs objets de rendu pour les véhicules et les éléments de la
carte miniature (boîtes bleues), les systèmes de rendu permettant de les afficher (boîtes
roses) ainsi que les liens nécessaires.
61
Une autre saisie d’écran, à la Figure 3-16, montre certaines possibilités pour la
représentation et l’analyse de données ainsi que pour l’organisation spatiale des éléments
graphiques dans une même fenêtre d’affichage. Les classiques graphiques 2D,
histogrammes et « pie charts » sont déjà implémentés dans des plug-ins directement
Figure 3-16 : Exemple d'une vue analytique
Figure 3-15 : Fenêtre de conception de la scène de
convoi
Figure 3-14 : Exemples d’une scène de convoi
62
utilisables. Des fonctionnalités pour la représentation de réseaux sociaux sont également
disponibles.
3.2.2.2 Interfaces COM
COM (Component Object Model) est un composant logiciel créé par Microsoft, descendant
des anciennes technologies OLE (Object Linking and Embedding) développées dans les
années 90, permettant à des programmes d’échanger des données. C’est un standard
indépendant de la plateforme qui est principalement utilisé dans Windows; les composants
ActiveX que l’on retrouve dans plusieurs applications web font usage de cette technologie
(Object Linking and Embedding 2009). Grâce à ce standard, il est possible pour un
programme (le serveur COM) de rendre disponible certaines de ses fonctionnalités à
d’autres programmes (les clients) qui peuvent s’y connecter. Eye-Sys utilise cette stratégie
pour permettre à des applications externes de contrôler la majeure partie de ses
fonctionnalités. Le processus de connexion est simple et direct lorsqu’effectué par le biais
d’applications .NET, en C# ou Visual Basic; il est également possible de le faire en C++
mais cela requiert une procédure un peu plus complexe et, d’une manière générale, plus
verbeuse en terme de code.
Le diagramme de classes de la Figure 3-17 montre une partie des interfaces disponibles. On
retrouve notamment des interfaces pour les classes Plugin et PropertyContainer qui
Figure 3-17 : Hiérarchie partielle des classes d'interfaces COM Eye-Sys
(IDV, Inc. 2009)
63
contiennent la plupart des fonctions permettant d’interagir avec toute instance de plug-in
Eye-Sys, principalement pour la modification de valeurs de propriétés ou la création de
liens de données. Des fonctions spécifiques aux objets et aux systèmes de rendu sont
également disponibles via leurs interfaces spécialisées respectives.
L’inconvénient principal de cette méthode d’interaction est le coût en performance et le
délai de traitement dans les cas de requêtes nombreuses à l’intérieur d’un court laps de
temps. Afin de palier au problème pour le transfert de données, des fonctions permettant de
transférer de nombreuses données à la fois sous forme de vecteurs sont disponibles; pour le
reste, une optimisation ou un filtrage doivent être faits lorsque possible car les requêtes
COM étant bloquantes du côté client, cela peut mener à des délais indésirables et à un
engorgement de la liste d’attente des requêtes.
3.2.2.3 Scripts
Un interpréteur JavaScript permet aux utilisateurs de programmer toutes sortes de
comportements sur mesure. Il supporte l’utilisation des fonctions et structures de données
définies par le standard tels tableaux, chaînes de caractères et fonctions mathématiques. Des
commandes vers les composants Eye-Sys peuvent être réalisées d’une manière semblable à
ce qu’un programme externe pourrait faire puisque les fonctions accessibles sont les mêmes
que celles exposées par les interfaces COM. Toutes les fonctionnalités de ces dernières sont
donc disponibles au niveau des scripts mais sont également soumises aux mêmes
limitations, notamment au niveau de la performance. Les scripts peuvent être utilisés un
peu à la manière de macros, programmés et exécutés par l’utilisateur dans une fenêtre
dédiée de l’interface principale; ils peuvent également être utilisés dans un plug-in de type
Manipulateur et se comporter comme tel, l’exécution se faisant alors en fonction des
changements de propriétés et des mises à jour requises. Un exemple de fenêtre d’édition de
script pour un plug-in est montré à la Figure 3-18.
64
3.2.2.4 SDK et développement de plug-ins
Comme il a été mentionné précédemment, il est possible de créer de nouveaux plug-ins
grâce à un SDK, en complément à l’application principale. Il permet aux programmeurs de
créer de nouveaux modules semblables à ceux fournis avec l’application. La plateforme de
développement présentement supportée est Visual Studio 2005, et un générateur
automatique de projets C++ ou .NET (C# notamment) est disponible avec l’installation du
SDK pour simplifier la création et la configuration des projets. Ceci permet de créer des
plug-ins dérivant de l’un des quatre types principaux : Input, Manipulator, Display Object
ou Display System. Pour une performance optimale, le langage C++ est recommandé.
Lorsque le projet est compilé, un fichier d’extension .eye, qui est en réalité une librairie
dynamique de type DLL, est créé et peut être chargé par Eye-Sys au démarrage. Le
débogage à l’exécution avec Visual Studio est supporté par la compilation en mode debug
et à condition qu’Eye-Sys démarre en même temps que le débogueur; seul le code du plug-
Figure 3-18 : Fenêtre d'édition du plug-in Script
65
in est alors disponible pour l’utilisation de points d’arrêts et l’observation de variables, le
reste de l’application restant fermé.
Peu importe le type, la création de plug-ins requiert de remplir les tâches de programmation
suivantes : entrée du nom du plug-in, création de propriétés et de leurs attributs dans le
constructeur, dont les types énumérés et les limites de valeurs numériques; implémentation
de la fonction Calculate( ) où les fonctionnalités principales du plug-in sont implantées ou
exécutées par l’appel d’autres fonctions lorsque nécessaire. Pour les objets de rendu, les
fonctions Draw2D et/ou Draw3D doivent également être implémentées, où le code
OpenGL nécessaire au rendu de l’objet est inséré.
3.2.3 ACE
Comme mentionné à la section 0, le framework ACE offre plusieurs modules génériques
facilitant la création d’applications performantes requérant communications, gestion
d’événements et multitraitement. Son utilisation est donc toute indiquée pour
l’implémentation d’une application répondant aux besoins de gestion de multiples
connexions socket simultanées et de filtrage de flots XML, requis pour le transfert de
données de Simulation vers Exploration.
Figure 3-19 : Hiérarchie partielle des classes du SDK Eye-Sys
(IDV, Inc. 2009)
66
D’abord, pour la gestion de connexions socket côté serveur, le design pattern Reactor est
utilisé. Il consiste à traiter de manière concurrente des requêtes de service provenant d’une
ou plusieurs sources vers un handler correspondant. L’objet ACE_Reactor est responsable
de recevoir les événements et de les distribuer aux gestionnaires appropriés qui sont
enregistrés; dans l’exemple de la Figure 3-20, les requêtes de connexion sont envoyées à
l’objet ACE_Acceptor qui se charge de créer un ACE_Svc_Handler. Ce dernier
s’enregistre alors auprès du ACE_Reactor qui va par la suite lui transmettre les
événements de réception de données.
Pour ce qui est de l’aspect multitraitement, les gestionnaires d’événements mentionnés
précédemment peuvent hériter de la classe ACE_Task implémentant tous les aspects
nécessaires à la création de threads de manière tout à fait indépendante de la plateforme. Il
est donc possible de créer un gestionnaire d’application pouvant exécuter un service dans
un thread indépendant, qui attend la présence de messages dans une file d’attente venant du
ACE_Reactor. Ceci permet de libérer le thread d’exécution de ce dernier ainsi que de
maximiser avantageusement la capacité de traitement dans les cas où plusieurs
Server
ACE_Reactor
ACE_Acceptor ACE_Svc_Handler
register()
handle_input()
get_handle()
create new Handler()
register()
handle_input()
get_handle()
connection request data connection
Client
Figure 3-20 : Patron de design Reactor dans le contexte serveur/client ACE
d’après (Online ACE Tutorials 2009)
67
ACE_Svc_Handlers reçoivent du travail et que les ressources de calcul sont grandes,
notamment sur des machines à multiples cœurs d’exécution.
3.2.4 Application Tableau Desktop
La première application officiellement retenue pour le module Exploration et incluse dans
le devis des expérimentations en psychologie cognitive est Tableau Desktop, qui grâce à sa
grande convivialité en termes d’interface utilisateur, sa flexibilité quant aux représentations
de données et aussi sa disponibilité immédiate sur le marché, s’est taillée une place de
choix dans la boîte à outils du projet.
Cependant, Tableau n’offre pas autant de flexibilité qu’Eye-Sys en termes d’importation de
données, d’automatisation, de contrôle externe et d’extensibilité pour l’implémentation de
fonctionnalités sur mesure. Compte tenu des besoins du projet, la mise en place d’une BD
s’est avérée nécessaire pour que l’information requise soit aisément accessible dans
Tableau (plus de détails sur cette partie ainsi que sur l’intégration avec les autres outils
seront présentés à la section 3.6).
3.3 Tests et prototypes – Traitement des données
Comme mentionné plus tôt, la première problématique abordée fut le transfert de données
entre les modules Simulation et Exploration. Les possibilités au niveau du SDK de Eye-Sys
Figure 3-21 : Diagramme d'héritage de la classe ACE_Svc_Handler
(ACE Documentation 5.6.0 2007)
68
étant très prometteuses, les premiers tests mettent en œuvre des fonctionnalités
implémentées directement dans des plug-ins. Par la suite, une étape de familiarisation avec
le COM en C++ ainsi qu’avec les structures de données qui permettent d’interagir avec les
fonctions de ces types d’interfaces ont permis d’évaluer les possibilités en cette matière.
3.3.1 Plug-ins Eye-Sys
Le premier prototype développé consiste à filtrer un flot de données de simulation XML
provenant d’un fichier. Le SDK de Eye-Sys offre des classes de base dans son framework
permettant de charger des fichiers et de filtrer du XML, ce qui facilite la tâche et évite le
besoin d’inclure d’autres librairies. Par la suite, le problème des communications a été
abordé. La plateforme de simulation Multichronia utilisant un serveur socket, un plug-in de
client pouvant s’y connecter a été implémenté et testé avec succès.
Quoique les résultats obtenus soient relativement satisfaisants, certains problèmes
communs à ces implémentations se posent, découlant principalement du fait que la
réception et le filtrage de données se trouvent directement dans l’outil de visualisation.
Dans l’éventualité où d’autres plateformes seraient utilisées, suivant cette approche, le
traitement de données devrait être ré-implémenté et ré-exécuté dans chacune des nouvelles
applications, ce qui est loin d’être optimal en termes de temps de développement et de
performance. Également, du fait qu’Eye-Sys fonctionne principalement dans un seul thread
d’exécution, lui imposer du travail de traitement relativement lourd et long à réaliser vient
interférer avec les performances de rendu et peut même faire figer l’interface pendant
plusieurs secondes, ce qui est à proscrire.
Les possibilités du framework ACE pour les communications et le multitraitement étant
intéressantes pour venir pallier à ces problèmes, son intégration dans un projet de plug-in
Eye-Sys a été testée et complétée malgré quelques problèmes de compilation et de
chargement dynamique de librairies. La connexion socket et la réception des données y sont
réalisées dans un thread indépendant, évitant ainsi d’accaparer le processus principal de
Eye-Sys.
Cependant, bien que très flexible en termes d’affichage et de rendu graphique, l’engin Eye-
Sys n’offre que des possibilités plutôt limitées pour les interactions avec les objets, du
69
moins ceux qui sont inclus avec l’application standard. De plus, l’une des limitations
majeures à l’égard du SDK est l’absence des en-têtes contenant le code des interfaces de
ces objets, ce qui rend impossible l’héritage direct à partir d’un objet déjà existant pour lui
ajouter des fonctionnalités ou modifier son comportement.
Pour tenter de contourner le problème, un prototype d’objet de rendu ayant pour but de
s’attacher à un autre objet et d’interagir à sa place a été testé, offrant par exemple la
possibilité de mettre en place un menu contextuel sur mesure remplaçant celui d’origine.
Cela peut fonctionner mais certaines difficultés se posent concernant la sélection des objets
qui est souvent ambigüe.
3.3.2 Prototypes COM / C++
Les interfaces COM pour l’automatisation de tâches dans Eye-Sys constituent un outil de
choix pour les communications et l’intégration avec les autres outils d’IMAGE. Quoique
les possibilités offertes par les langages .NET comme le C# étaient alléchantes pour leur
facilité d’utilisation, pour des raisons de performance et de compatibilité avec d’autres
plateformes existantes dont ACE, le C++ a été préféré.
Comme il a déjà été cité, l’utilisation du COM en C++ Windows n’est pas triviale, que ce
soit pour la connexion COM, les structures de données, la gestion et la vérification des
pointeurs. Typiquement, une fonction COM C++ prend en paramètres des pointeurs de
VARIANT, une structure générique pouvant représenter n’importe quel type de données
(booléen, entier, chaîne de caractères, tableaux, etc.), et retourne un HRESULT qui est un
code d’erreur. Des classes d’encapsulation provenant de la librairie ATL (Active Template
Library) facilitant la manipulation des VARIANTs sont disponibles. Elles permettent de
gérer la création, la destruction et la copie entre différentes structures. Afin d’obtenir un
pointeur vers un objet COM de manière sûre, il faut exécuter une recherche par nom,
vérifier la validité du pointeur générique retourné, faire une requête d’interface vers le type
requis (à la manière d’un « cast » dynamique) et vérifier à nouveau la validité du pointeur
spécifique. Un programme effectuant une simple connexion COM et exécutant une série de
commandes en « batch » a été développé pour tester ces fonctionnalités. Un extrait du code
source de ce programme est montré à la Figure 3-22.
70
Figure 3-22 : Extrait d'un programme test COM en C++
Suite à tous ces tests, il a été conclu que, compte tenu des besoins du projet, il était
préférable de traiter l’information XML à l’extérieur de Eye-Sys, pour lui envoyer par la
suite les vecteurs de données déjà traités via la connexion COM. À ce stade, une première
version d’une application C++ dédiée à ces tâches, ImageDataServer, a donc été
développée.
3.4 Application ImageDataServer
L’application ImageDataServer sert de lien de communication et de transfert de données
entre Simulation (Multichronia) et Exploration (Eye-Sys). Elle exécute trois types de tâches
principales : la gestion des connexions socket, le traitement des données de simulation
// Get the Class ID for the EyeSysGlobalScript interface
OLECHAR wEyeSysProgID[256];
mbstowcs(wEyeSysProgID, "eyesys.EyeSysGlobalScript", 256);
CLSID clsid;
HRESULT hr = CLSIDFromProgID(wEyeSysProgID, &clsid);
if (FAILED(hr))
{
printf("Error getting ProgID\n", hr);
return -1;
}
// create instance of the Eye-Sys interface class
IEyeSysGlobalScript* pEyeSys = NULL;
hr = CoCreateInstance(clsid, 0, CLSCTX_ALL, __uuidof(IEyeSysGlobalScript), (void**)&pEyeSys);
if (FAILED(hr))
{
printf("Error connecting to the Eye-Sys COM \n", hr);
return -1;
}
// Interface pointers for working
IDispatch* pDispatch = NULL;
IPropertyContainer *pContainer = NULL;
IEyeCommonProperty *pProperty = NULL;
// Display System and basic rendering
pEyeSys->CreateNamedObject(CComBSTR("Scene Graph Renderer"), CComBSTR("SceneGraph"), &pDispatch);
IDisplaySystem* pSceneGraph = NULL;
hr = pDispatch->QueryInterface(__uuidof(IDisplaySystem), (void**)&pSceneGraph);
if (FAILED(hr))
{
printf("Error querying interface [IDisplaySystem] for \"Scene Graph Renderer\": 0x%0x\n", hr);
return -1;
}
// Create Box1
pEyeSys->CreateNamedObject(CComBSTR("Box"), CComBSTR("Box1"), &pDispatch);
IDisplayObject* pBox1;
hr = pDispatch->QueryInterface(__uuidof(IDisplayObject), (void**)&pBox1);
if (FAILED(hr))
{
printf("Error querying interface [IDisplayObject] for \"Box1\": 0x%0x\n", hr);
return -1;
}
// Add Box1 to scene graph
pSceneGraph->AddObject(pBox1);
71
XML et l’interaction COM avec Eye-Sys. Pour chacune de ces parties, un diagramme de
classes montrant les fonctionnalités pertinentes est présenté et expliqué dans les prochaines
sections.
3.4.1 Gestion des connexions
Les classes relatives à la gestion des connexions sont montrées dans le diagramme de la
Figure 3-23. Comme on peut le constater, plusieurs de ces classes héritent ou utilisent des
éléments du framework ACE, illustrés par des boîtes grises sur le schéma.
Au démarrage du programme, une instance de chacun des objets suivants, ReactorTask et
SocketAcceptor, est créée et leur fonction open( ) est appelée pour l’initialisation (voir le
diagramme séquentiel de la Figure 3-24). Le thread principal de l’application passe ensuite
en mode d’attente de commandes de l’utilisateur. Les fonctionnalités de traitement utile
+open() : int
+close() : int
+handle_input() : int
ACE_Acceptor
+instance() : ACE_Reactor
+handle_events() : int
-reactor_ : ACE_Reactor
ACE_Reactor
+open() : int
+close() : int
+svc() : int
+putq() : int
+getq() : int
ACE_Task
+open() : int
+close() : int
+svc() : int
ACE_Svc_Handler
+enqueue_tail() : int
+dequeue_tail() : int
ACE_Message_Queue
+open() : int
+close() : int
+svc() : int
SocketHandler
+open() : int
+close() : int
SocketAcceptor+open() : int
+close() : int
+svc() : int
ReactorTask
1«uses»
+duplicate() : ACE_Message_Block
+release() : ACE_Message_Block
+rd_ptr() : char*
+wr_ptr() : char*
ACE_Message_Block
+startDocument() : void
+endDocument() : void
+startElement() : void
+endElement() : void
+characters() : void
+error() : void
+fatalError() : void
+warning() : void
-m_pWorkingDataBlock : SimDataBlock*
ACEXML_DefaultHandler
1
«uses»
+ClearBlockData() : void
+IsCompleted() : bool
+GetSimDataType() : int
+m_strStreamName
+m_strParentStreamName
+m_iIteration
+m_vSimVariables
+m_vSimAgents
-m_bIsCompleted
-m_eSimDataType
SimDataBlock
1
0..*
Figure 3-23 : Diagramme de classes – partie Connexion
72
s’exécutant automatiquement dans d’autres threads, nouvellement initialisés selon les
besoins, ce mode est surtout utilisé pour les tests et le débogage. Au cours du processus
d’initialisation de la fonction open( ), ReactorTask fait une requête pour obtenir un
pointeur vers l’unique instance (singleton) du ACE_Reactor. Par la suite, comme il dérive
de ACE_Task, il démarre l’exécution d’un thread indépendant qui consiste en une simple
boucle infinie bloquante, en attente d’événements à traiter venant du ACE_Reactor. Pour
sa part, le SocketAcceptor s’enregistre auprès du ACE_Reactor, qui lui est fourni par un
paramètre de la fonction open( ), et attend les connexions. Lorsque cela se produit, le
ACE_Reactor qui reçoit l’événement appelle la fonction handle_input( ) du
SocketAcceptor, qui se charge de créer le SocketHandler et de l’initialiser (voir
diagramme séquentiel de la Figure 3-25). Ce dernier, dérivant de ACE_Svc_Handler, est
une classe de traitement spécialisé pour les connexions socket. Dans sa fonction open()
s’effectuent l’enregistrement auprès du ACE_Reactor, l’identification de l’adresse du
client et l’activation d’un thread local. C’est dans ce thread que seront dorénavant traitées
les requêtes de réception de données et l’exécution du filtrage XML. Au premier paquet
reçu, on vérifie le type de données entrantes et on crée la spécialisation appropriée du
ImageDataServer ReactorTask EyeSysManager SocketAcceptor
open()
ACE_Reactor: instance()
this: activate()
open()
CreateInstance(&pEyeSysApp)
this: activate()
register_handler()
open(addr, pReactor, pEyeSysManager)
Figure
3-24 : Diagramme séquentiel – Démarrage
73
ACEXML_DefaultHandler (ce processus est détaillé à la prochaine section). Les
messages suivants sont directement envoyés à ce module de filtrage XML qui fait le travail
et retourne un SimDataBlock avec toutes les données filtrées, principalement sous forme
de vecteurs STL.
3.4.2 Traitement des données XML
Le traitement XML du ImageDataServer est implémenté à partir de classes du module
ACEXML, comme on peut le constater sur la Figure 3-26. Le module
ACEXML_DefaultHandler implémente des interfaces dont les diverses fonctions seront
ReactorTask SocketAcceptor
activate()
ACE_Reactor
handle_events()
handle_input()
SocketHandler
<<create>>
open(pReactor)
register_handler(this)
handle_events()
handle_input(msg)
putq(msg)
Événement
Connexion
Événement
1er Message
ACEXML_Handler
<<create>>
get_addr()
Figure
3-25 : Diagramme séquentiel – Connexion et réception de messages
74
+startDocument() : void
+endDocument() : void
+startElement() : void
+endElement() : void
+characters() : void
ACEXML_ContentHandler
+error() : void
+fatalError() : void
+warning() : void
ACEXML_ErrorHandler
+eSimulationLog = 0
+eSimulation
+eMetrics
+eMetric
+eParameters
+eParameter
+eSimulatedAgentList
+eSimulatedAgent
+eLastLoc
+eNowAt
+eNewBehaviorName
+eRed
+eGreen
+eBlue
+eTimeStep
+eOther
«enumeration»
XMLTacticalDataNodeNames
+eSimulationLog = 0
+eStrategicConvoy
+eMetrics
+eMetric
+eParameters
+eParameter
+eIteration
+eOther
«enumeration»
XMLStrategicDataNodeNames
1
1
+ClearVariableData() : void
+m_strVariableName : string
+m_eCategory : int
+m_eDataType : int
-m_strValue : string
SimVariable
+ClearAgentData() : void
+m_strAgentName : string
+m_eCategory : int
+m_strID : string
+m_iPositionX : int
+m_iPositionY : int
+m_iLastPositionX : int
+m_iLastPositionY : int
+m_strBehavior : string
+m_iRed : int
+m_iGreen : int
+m_iBlue : int
+m_vAgentVariables : vector
SimAgent
+duplicate() : ACE_Message_Block
+release() : ACE_Message_Block
+rd_ptr() : char*
+wr_ptr() : char*
ACE_Message_Block
+ClearBlockData() : void
+IsCompleted() : bool
+GetSimDataType() : int
+m_strStreamName
+m_strParentStreamName
+m_iIteration
+m_vSimVariables
+m_vSimAgents
-m_bIsCompleted
-m_eSimDataType
SimDataBlock
+startDocument() : void
+endDocument() : void
+startElement() : void
+endElement() : void
+characters() : void
+error() : void
+fatalError() : void
+warning() : void
-m_pWorkingDataBlock : SimDataBlock*
ACEXML_DefaultHandler
+startDocument() : void
+endDocument() : void
+startElement() : void
+endElement() : void
+characters() : void
+error() : void
+fatalError() : void
+warning() : void
-m_pWorkingDataBlock : SimDataBlock*
XMLStrategicDataHandler
+startDocument() : void
+endDocument() : void
+startElement() : void
+endElement() : void
+characters() : void
+error() : void
+fatalError() : void
+warning() : void
-m_pWorkingDataBlock : SimDataBlock*
XMLTacticalDataHandler
1 1
0..*
«uses» «uses»
Figure 3-26 : Diagramme de classes – partie Traitement
75
appelées selon les événements de filtrage, comme par exemple les débuts et fins de
document XML, les débuts et fins d’éléments (« tags » XML), les caractères, les espaces
blancs et les erreurs rencontrées, tel que dicté par la norme SAX. Dans le cas présent, du
ACEXML_DefaultHandler dérivent deux spécialisations, XMLTacticalDataHandler et
XMLStrategicDataHandler, traitant chacune leur type de données de simulation et étant
responsables de remplir les structures SimVariables et SimDataBlocks à mesure que les
données sont analysées. Pour faciliter la compréhension et la manipulation du code, on
utilise des types énumérés qui listent les noms des paramètres XML rencontrés dans leurs
données de simulation.
3.4.3 Connexion et interactions COM avec Eye-Sys
La dernière partie du ImageDataServer est consacrée à la connexion COM, aux transferts
de données et aux interactions avec Eye-Sys. Comme on peut le remarquer sur le
diagramme de la Figure 3-27, la plupart des classes développées dérivent de ACE_Task, ce
qui permet à ces modules d’exécuter des tâches qui leur sont spécifiques dans un thread qui
leur est propre.
EyeSysInteractor sert de base pour les classes requérant une interaction avec Eye-Sys; il
possède d’ailleurs un pointeur statique vers l’unique interface IEyeSysGlobalScript, qui
est le point d’entrée de la connexion COM. Il a également accès à d’autres interfaces vers
divers types d’objets Eye-Sys (montrés en bleu sur le schéma). Pour faciliter les requêtes
COM, une série de fonctions encapsulant les fastidieuses procédures C++ relatives aux
créations, requêtes et vérifications d’objets sont implémentées et accessibles à toute la
hiérarchie. Pour diminuer encore davantage le code de vérification, on utilise la classe
HResultExcept qui gère de manière intrinsèque, via un opérateur d’assignation acceptant
un HRESULT, les erreurs retournées par les fonctions COM. Lorsqu’une fonction retourne
un code d’erreur non nul que l’on assigne à une instance de cette classe plutôt qu’à un
simple HRESULT, une exception est lancée. Le traitement de cette exception est cependant
laissé au soin de l’appelant.
EyeSysSimDataHandler et ses dérivées sont responsables de traiter les SimDataBlocks
pour les convertir en EyeSysSimRunDataBlocks, des structures spécialisées contenant les
76
données de simulation sous forme de vecteurs de type SAFEARRAY, type supporté par les
fonctions COM exposées par Eye-Sys. Ces traitements sont exécutés dans des threads
indépendants appartenant à ces modules pour favoriser le calcul en parallèle.
EyeSysView et ses dérivées sont responsables de gérer les vues; dans ce cas-ci, deux
spécialisations existent, une pour chaque contexte de simulation. Ces modules ne
nécessitent pas de thread dédié car la quantité de travail est minime, d’autant plus que
l’interface COM Eye-Sys ne peut pas traiter des demandes en parallèle. On retrouve dans
+open() : int
+close() : int
+svc() : int
+putq() : int
+getq() : int
ACE_Task
+InitializeComponents()
+CreateDisplayObject()
+CreatePropertyContainer()
+GetDisplayObject()
+GetPropertyContainer()
+CreateProperty()
+GetProperty()
+ConnectProperties()
-m_pEyeSysApp : IEyeSysGlobalScript*
EyeSysInteractor
+GetParent() : HRESULT
+GetChild() : HRESULT
+CanDraw2D() : HRESULT
+CanDraw3D() : HRESULT
«interface»
IDisplayObject
+ActivateWindow() : HRESULT
+ZoomAll() : HRESULT
+AddObject() : HRESULT
+RemoveObject() : HRESULT
«interface»
IDisplaySystem
+CreateProperty() : HRESULT
+GetProperties() : HRESULT
+DeleteProperty() : HRESULT
«interface»
IPropertyContainer
+GetName() : HRESULT
+Value() : VARIANT
+History() : SAFEARRAY
+AppendHistory() : HRESULT
«interface»
IEyeCommonProperty
+eEyeSysUndefined = -1
+eEyeSysPropertyContainer
+eEyeSysSceneGraphRenderer
+eEyeSysCompositeDisplaySystem
+eEyeSysMultiDisplaySystem
+eEyeSysCamera
+eEyeSysFocalPoint
+eEyeSysGriddedSurface
+eEyeSysHistoryConcatenator
+eEyeSys3DModel
+eEyeSysSphere
+eEyeSysCone
+eEyeSysNullObject
«enumeration»
EEyeSysObjectType
+HandleSimDataBlock() : int
+AddBranchedData() : int
+ProcessSimDataBlock() : int
EyeSysSimDataHandler
+ProcessSimVariable() : int
+ProcessIntValue() : int
+ProcessDoubleValue() : int
+ProcessStringValue() : int
EyeSysStrategicDataHandler
+ProcessSimVariable() : int
+ProcessSimAgent() : int
EyeSysTacticalDataHandler
+SetupConvoyData()
+SetupConvoyAgents()
+SetupDataDriver()
-m_vDisplaySystem
GeospatialConvoyView
+ProcessSimRunDataBlock()
EyeSysView
-m_mapEyeSysSimDataHandlers
-m_mapEyeSysSimRunDataBlocks
-m_pGriddedSurfaceMoeView
-m_pGeospatialConvoyView
EyeSysManager
+GetStreamName()
+GetSimDataType()
+GetNbTimeSteps()
+ClearBlockData()
-m_mapVariantParameters
-m_mapVariantMetrics
-m_mapConvoyVehicles
-m_mapIEDs
-m_mapRPGs
-m_mapOthers
#m_strStreamName
#m_eSimDataType
EyeSysSimRunDataBlock
+ClearAgentData()
+AssignDataRange()
+GetNbTimeSteps()
+IsAgentActive()
+m_saPositionX
+m_saPositionY
+m_saBehavior
-m_bIsAgentActive
EyeSysSimRunAgent
-m_vDisplaySystem
GriddedSurfaceMoeView
1
1
1
0..*
«uses»
«uses»
«uses»
«uses» «uses»
+CreateObject() : HRESULT
+FindObject() : HRESULT
+GetAllObjects() : HRESULT
+TestConnection() : HRESULT
+ImportEspFile() : HRESULT
+GetSelectedObjects() : HRESULT
+RedrawAllDisplaySystems() : HRESULT
«interface»
IEyeSysGlobalScript
1
+operator=() : HResultExcept
HResultExcept«uses»
Figure 3-27 : Diagramme de classes – partie Eye-Sys / COM
77
ces classes des fonctions permettant la création automatique des instances de plug-ins Eye-
Sys requis pour leurs vues respectives ainsi que pour le transfert de données vers ces
dernières.
EyeSysManager exécute un thread indépendant qui gère toutes les requêtes entrantes
relatives aux interactions avec Eye-Sys : réception des SimDataBlocks provenant du
SocketHandler et leur routage vers les modules de traitement Eye-Sys, ainsi que
l’exécution des commandes d’interaction provenant du module de Simulation.
3.5 Tests et prototypes – Visualisation
Des données de simulation étant maintenant disponibles dans Eye-Sys, une première phase
de développements en visualisation a été entamée.
3.5.1 Plug-in « History Concatenator »
N’étant pas relié directement à la visualisation, ce prototype a été développé suite à un
besoin d’adapter des vecteurs de données de simulation passées à un plug-in Eye-Sys de
rendu de surface 3D pour une vue préliminaire. Il est ainsi nommé en raison du format
requis par le plug-in de surface; alors que les données arrivent dans des vecteurs séparés
pour chacune des branches de simulation, il est requis que toutes les données en Z soient
fournies dans un seul vecteur. Le plug-in exécute donc une concaténation des vecteurs de
données qui lui sont fournis en entrée. Cette procédure a permis de maîtriser davantage le
développement avec le SDK ainsi que l’utilisation efficace des historiques de propriétés
Eye-Sys.
La Figure 3-28 montre la fenêtre de propriétés d’un « History Concatenator » et un tableau
partiel des données d’historique qu’il contient. Les propriétés sont regroupées par
catégorie : entrée (Input History), sortie (Output History) et statistiques. Les entrées sont les
vecteurs à concaténer et sont définies comme des propriétés multiples (appelées
« Multiproperties » dans Eye-Sys), ce qui permet que leur nombre soit variable et
configurable dans l’interface utilisateur ou par fonctions COM. Les propriétés en sortie sont
fixes et calculées par le plug-in, soient les index de longueur et de largeur ainsi que le
vecteur concaténé; elles se branchent directement sur les entrées appropriées du plug-in de
78
surface. Les statistiques, tenant lieu de rétroaction informative seulement, rapportent les
longueurs des vecteurs traités. Dans le cas illustré, nous avons trois branches de simulation
ayant chacune 101 données, ce qui donne un vecteur concaténé de 303 éléments prenant
des valeurs entre 0 et 10. On peut également observer que les valeurs de la colonne
« Output History:Values » correspondent à celles des « Input Histories », mises à la suite
ligne par ligne.
3.5.2 Scène tactique 3D
Pour le scénario tactique, c’est une représentation de l’environnement physique et des
agents de simulation dans une scène de rendu 3D qui a été retenue comme première
visualisation principale. Une saisie d’écran de cette vue dans ses premières versions de
conception est montrée à la Figure 3-29.
Les objets de base visibles dans cette scène sont créés à partir de plug-ins Eye-Sys déjà
existants. On y retrouve une scène 3D principale observable par caméra mobile, ainsi
qu’une mini-carte dans le coin inférieur gauche où la caméra est fixe et orthogonale au plan
XY. Ceci est réalisé grâce à deux « Scene Graph Renderers », utilisant chacun leur caméra,
qui sont branchés dans un plug-in de type « Multi-Display » permettant l’agencement de
plusieurs systèmes de rendu dans une même fenêtre maîtresse. Le sol est formé par un plan
Figure 3-28 : Propriétés du « History Concatenator » et historiques de données
79
2D prenant en charge les textures, et une image de sable lui a été assignée pour donner un
effet désertique. Le même principe est utilisé pour la route, formée de plusieurs plans
rectangulaires, sans texture toutefois. Les véhicules sont représentés à l’aide d’un plug-in
de type « 3D Model » prenant en charge un modèle de LAV III (Light Armoured Vehicle)
des Forces canadiennes, en format 3DS; le même procédé est utilisé pour les bâtiments dont
la position est fixée selon les spécifications du scénario. La vue étant en cours de
développement, les positions des explosifs et des lanceurs de grenades ne sont tenues que
par des sphères et des cônes. Ils sont cependant identifiés par leur nom grâce à un plug-in
de type « Callout » affichant une fenêtre de texte mobile qui leur est attachée. La flexibilité
du pipe-line de données Eye-Sys permet de représenter les éléments visuels de manière
Figure 3-29 : Saisie d'écran de la vue tactique préliminaire
80
identique ou différente dans plus d’une vue : par exemple, des modèles de bâtiments et plan
texturé dans la vue principale versus des plans non-texturés dans la mini carte. Finalement,
une ébauche d’effet de particules visant à illustrer une explosion est visible sur l’un des
explosifs.
Lorsqu’une nouvelle branche de simulation est créée, les données sont traitées par le
ImageDataServer et les objets graphiques nécessaires à la visualisation de la branche en
question sont créés dynamiquement. Ceci implique les modèles 3D des véhicules (au
nombre de 10 par branche), des explosifs (entre 0 et 5) et des lanceurs de grenades (entre 0
et 5). Les éléments de base du scénario qui ne changent pas en fonction de la branche de
simulation, c’est-à-dire le sol, la route et les bâtiments, sont sauvegardés dans un fichier de
projet Eye-Sys, instanciés une seule fois au démarrage et utilisés pour toutes les vues,
branchés simultanément dans plusieurs systèmes de rendu différents si nécessaire.
3.6 Migration vers la base de données MySQL
Cette étape déterminante pour la suite du projet est due à plusieurs changements dans le
mode de fonctionnement des outils de l’Exploration et de l’interaction avec la Simulation,
et les choix de design retenus ont grandement influencé les développements subséquents.
Les modifications concernant l’utilisation d’une base de données MySQL ainsi que les
adaptations logicielles nécessaires pour l’automatisation des vues Eye-Sys sont expliquées
dans les prochaines sous-sections.
Comme il a été mentionné plus tôt, une BD MySQL avait été mise en place et était utilisée
par le module de Simulation qui y inscrivait toutes les données relatives au scénario, dans le
but de les rendre disponibles pour l’application Tableau. Cependant, des besoins
grandissants en termes d’échanges de données entre les grands modules du projet ont
favorisé la centralisation de toute l’information dans la BD MySQL. À partir de ce
moment, toutes les branches de simulation tactique possibles du scénario de convoi (au
nombre de 726) sont pré-simulées par une application automatique qui gère le simulateur
Pythagoras, qui était jusqu’à maintenant contrôlé en temps réel par Multichronia. Cette
application se charge de peupler la BD avec les résultats XML de toutes les branches de
simulation, mais effectue également un travail d’analyse supplémentaire dans le but
81
d’extraire d’autres informations à partir de ces données brutes, non-explicites ou non-
disponibles dans le XML, mais nécessaires pour l’analyse et les objectifs de compréhension
du scénario. Tout ceci vise principalement à accélérer et faciliter le fonctionnement du
système. Un schéma de la structure de cette BD est inclus à l’annexe A.
3.6.1 Mode de connexion à la base de données
En réponse aux changements décrits plus haut, pour la partie Exploration, la tâche
principale à réaliser est de modifier le mode de transfert et de traitement de données XML
venant directement de la simulation pour plutôt aller chercher les données requises dans la
BD lorsque nécessaire. Il faut donc que les données de la BD soient transférées dans Eye-
Sys; les deux solutions suivantes ont été envisagées.
3.6.1.1 Plug-in « Database » Eye-Sys
Il existe un plug-in déjà implémenté dans Eye-Sys permettant l’accès à de nombreux types
de sources de données. Il permet de se connecter sur plusieurs types de fournisseurs
Microsoft OLE DB, un API générique pour la connexion à des types d’archives de données
très variées. Cependant, il n’existe pas de fournisseur permettant de se connecter
directement sur MySQL. Cela doit être fait par le biais d’un connecteur ODBC pour
MySQL installé et configuré au préalable. Lorsque c’est fait, il est possible d’extraire des
données en entrant textuellement une requête SQL dans la propriété du plug-in prévue à
cette fin. Les résultats sont placés dans des historiques de propriétés portant le nom des
champs correspondants de la table. Il est également possible d’enregistrer de nouvelles
données avec des instructions d’insertion. La Figure 3-30 montre un exemple de fenêtre de
configuration et de propriétés pour le plug-in « Database ».
Quoique cette configuration ne soit pas tout à fait triviale à réaliser, une fois mise en place,
elle constitue à prime abord une méthode de choix, ceci étant dû à la facilité avec laquelle il
est possible d’aller chercher des données ainsi que leur disponibilité immédiate pour la
visualisation dans Eye-Sys.
82
3.6.1.2 Connexion vers MySQL via un API C++
La seconde option consiste plutôt à exécuter les requêtes MySQL dans un programme C++
externe à Eye-Sys, typiquement à l’aide d’une connexion TCP ou d’un « pipe » de données.
Les essais effectués pour cette avenue ont consisté à intégrer l’API MySQL++ à
l’application ImageDataServer et à tester les fonctionnalités en créant une connexion et une
requête de données. Cette tâche a été réalisée assez aisément; il est en effet possible de
récupérer des données en quelques lignes de code seulement. Il reste toutefois nécessaire de
traiter et de formater les résultats obtenus dans des vecteurs de données supportés par les
fonctions COM de Eye-Sys, pour pouvoir les transférer par la suite.
Dû à des contraintes temporelles importantes au niveau des échéanciers du projet, c’est la
première méthode utilisant le plug-in Eye-Sys, pour laquelle une preuve de concept a été
réalisée rapidement, qui a été retenue.
Figure 3-30 : Configuration du plug-in « Database »
83
3.6.2 Modifications logicielles
3.6.2.1 Importation de données MySQL via script Eye-Sys
Toutes les données étant maintenant directement accessibles dans Eye-Sys par le plug-in de
BD, il faut trouver un moyen de récupérer ce qui est nécessaire selon les besoins, c’est-à-
dire les données pertinentes aux branches de simulation demandées par l’utilisateur. Pour la
visualisation tactique, nous avons besoin d’attributs relatifs aux agents du scénario, LAVs,
IEDs et RPGs, comme leur position XY et leur état d’action courant, qui peuvent varier à
chaque pas de temps.
Afin de pouvoir exploiter efficacement les possibilités de rendu graphique et l’engin
d’animation de Eye-Sys, les données doivent être regroupées en vecteurs et assignées à un
historique de propriétés où chaque élément correspond à un pas de temps. Cependant, dû à
la structure adoptée par la BD, il est impossible de récupérer en une seule requête les
données d’une table pour tous les pas de temps relatifs à une branche en particulier. Une
solution simple mais coûteuse en temps est d’effectuer une boucle de traitement et d’aller
chercher les données requises pour chaque pas de temps, de les accumuler dans des
vecteurs et de les assigner à des historiques de propriétés lorsque terminé. Les objets scripts
Eye-Sys étant flexibles et offrant beaucoup de possibilités, c’est cette solution qui a été
retenue pour l’implémentation du code nécessaire à ce traitement, d’autant plus que le
Javascript offre également une syntaxe beaucoup plus simple d’utilisation que le C++ pour
les interactions avec Eye-Sys. Un script dédié a donc été implémenté pour l’importation de
données, automatisant les requêtes SQL et l’extraction des résultats à l’aide d’un plug-in
Figure 3-31 : Schéma partiel de la base de données IMAGE - Données tactiques
84
« Database » de Eye-Sys. Lorsqu’exécuté, le script fournit un conteneur de propriétés avec
toutes les données de simulation relatives à une branche, formatées correctement.
3.6.2.2 Création automatique d’objets et synchronisation
Peu importe la méthode d’accès aux données qui est utilisée, dans le nouveau contexte
d’opération, la vocation du ImageDataServer est forcément changée car ce dernier n’a plus
à traiter des flots de données XML; sa tâche s’en trouve donc largement allégée.
Cependant, afin de maintenir une synchronisation efficace entre Simulation et Exploration,
le lien par connexion socket entre ces modules est conservé pour l’échange de messages
concernant les événements et les actions de l’utilisateur provenant de Multichronia. Un
protocole très simple et extensible utilisant des éléments XML a été mis en place afin de
communiquer des informations comme le contexte de simulation, le nom des branches, leur
état et leur position. Cependant, les informations transmises par ce biais sont restreintes et
puisque les données de simulation ne passent plus par le ImageDataServer, certaines
informations requises pour la création des objets ne sont plus disponibles. Ici encore, la
solution la plus facile est d’effectuer la création des objets lors de la déclaration de
nouvelles branches dans un script Eye-Sys où toutes les données sont facilement
accessibles, plutôt qu’en C++.
Le désavantage d’utiliser des objets scripts pour effectuer ce genre de tâches est la difficulté
à contrôler leur exécution et à les synchroniser lorsque plusieurs d’entre eux doivent
effectuer des tâches de manière consécutive; l’importation des données suivie de la création
des objets en est un exemple. Les objets scripts se comportent comme des plug-ins
ordinaires et leur exécution est gérée automatiquement par le framework Eye-Sys, ce que
l’on ne désire pas ici. On peut cependant contrôler l’exécution en créant une propriété
servant de variable de contrôle, comme une valeur booléenne, dont on peut changer la
valeur manuellement ou par commande COM. On vérifie son état au début du script et s’il
est à « vrai », l’exécution se poursuit normalement et on termine en réinitialisant l’état de la
variable à « faux »; dans le cas contraire, on termine immédiatement.
Pour ce qui est de la synchronisation, le déclenchement de l’exécution d’un script à partir
d’un autre ne garantit pas un traitement séquentiel correct. Une solution possible est de
signaler la fin d’un script dans une propriété observable de l’extérieur et de démarrer le
85
script suivant lorsque requis. Cependant, un autre détail doit être pris en compte dans la
commande de déclenchement; même si on assigne une nouvelle valeur à une propriété d’un
script, ce dernier ne s’exécutera pas nécessairement immédiatement si le framework Eye-
Sys ne détecte pas que des résultats de sa part sont requis à ce moment; cela se produit
généralement lorsqu’il n’y a aucune de ses propriétés qui est connectée à un autre objet.
Dans ce cas, il faut donc, immédiatement après avoir assigné la propriété, faire une autre
commande sur l’objet tel qu’une requête de propriété ou sa sélection pour déclencher
l’exécution.
3.7 Vue tactique
Cette section traite des développements et améliorations apportées à la vue tactique
proprement dite, tirant parti des données nouvellement disponibles.
3.7.1 Éléments visuels de la vue 3D principale
3.7.1.1 Modèles 3D
Une illustration des modèles 3D utilisés pour représenter les agents du scénario dans la
visualisation tactique est montrée à la Figure 3-32. Le premier est un véhicule blindé léger
(LAV), le second, un engin explosif improvisé (IED), et le dernier, un lanceur de grenades
(RPG). Ils proviennent d’une librairie de modèles militaires ayant été convertis au format
3DS pour être compatibles avec le plug-in Eye-Sys.
Lors de la création d’une branche de simulation, les instances requises de ces modèles sont
créées selon les paramètres de la branche de simulation demandée. Quoique les LAVs
soient toujours au nombre de 10, le scénario est défini tel que le nombre des IEDs et des
RPGs varie entre 0 et 5, la somme totale de leurs unités combinées pour une branche étant
toujours de 5. L’emplacement de ces unités sur le terrain est déterminé par des données de
position venant de la simulation. En réalité, seuls les LAVs se déplacent au cours du temps,
les positions des IEDs et RPGs étant statiques et possédant des positions précises,
également définies par le scénario.
86
3.7.1.2 Actions et états
Comme nous l’avons décrit dans l’introduction, le scénario met en scène un convoi
militaire pouvant subir des dommages causés par des engins explosifs et être attaqué par
des lanceurs de grenades. Ces attaques ainsi que leurs conséquences doivent être clairement
représentées dans la visualisation 3D, autant que possible selon les données de simulation
disponibles. Une saisie d’écran de la vue tactique en action est présentée à la Figure 3-33.
D’abord, les LAVs peuvent détecter la présence d’ennemis. Lorsqu’un lanceur de RPG
entre dans le champ de vision d’un LAV, il est repéré et cela est représenté par une flèche
jaune pointant sur l’ennemi en question, qui reste visible jusqu’à ce que ce dernier soit
éliminé. Le moment de la détection est influencé par la distance qui sépare le LAV de
l’ennemi et l’obstruction causée par la présence de bâtiments. Ensuite, un LAV peut
attaquer l’ennemi détecté et l’éliminer; cette action est représentée par un ruban animé de
couleur bleue. Alors que plusieurs véhicules peuvent détecter un même opposant, un seul
d’entre eux entreprend une action d’attaque (comme on peut l’observer sur la figure). Le
scénario est défini tel que les LAVs ont une efficacité de tir de 100% en tout temps,
éliminant d’un seul coup tous les ennemis qu’ils attaquent. Ils peuvent en contrepartie être
endommagés par les attaques ennemies. Lorsque cela se produit, leur couleur change selon
une gradation passant du vert au jaune puis au rouge, en fonction de leur intégrité (ou
quantité de vie restante); les teintes du vert au jaune indiquent une intégrité de 99% à 50%,
et du jaune au rouge de 49% à 0%. Lorsque l’intégrité du véhicule atteint 0, il cesse
d’avancer et est accompagné d’un effet de fumée.
Figure 3-32 : Modèles 3D des agents de la simulation
(Laboratoire d'immersion virtuelle, RDDC Valcartier 2006)
87
Les RPGs quant à eux passent à l’attaque aussitôt qu’un LAV entre dans leur ligne de mire;
la détection et l’attaque ne sont pas différenciées et un ruban animé de couleur rouge,
semblable à celui utilisé pour les LAVs, est utilisé. Étant toujours éliminés d’un seul coup,
ils n’ont pas besoin d’une échelle d’intégrité; ils peuvent prendre 3 états distincts : en
recherche de cible, en attaque ou éliminé. Alors que l’attaque est montrée par la présence
du ruban rouge, les deux autres états sont indiqués par des icônes 2D placés au-dessus du
modèle 3D, tel qu’illustré à la Figure 3-34.
Figure 3-34 : Icônes d'état des lanceurs de RPG
Figure 3-33 : Éléments visuels de la vue 3D principale
88
Les IEDs peuvent prendre, selon les circonstances, les états suivants : armé, représenté par
la couleur normale du modèle; en désamorçage, par une teinte de rouge clignotant;
désamorcé, par une teinte de vert; explosé, par un effet d’explosion avec fumée.
3.7.1.3 Implémentation
Les fonctionnalités décrites ci-haut sont réalisées grâce aux agencements d’objets Eye-Sys
présentés aux figures 3-35 à 3-37. Pour chaque agent de chaque branche de simulation, un
ensemble de ces objets est instancié, regroupant tout ce qui est nécessaire aux
fonctionnalités visuelles individuelles de chacun; en plus du modèle 3D, on retrouve les
plug-ins servant aux flèches de détection, aux rubans d’attaque et aux effets de fumée. La
gestion des éléments visuels, c’est-à-dire quand et comment ils doivent être affichés, est
gérée principalement par des scripts qui observent constamment l’état des agents au pas de
temps courant et qui activent les éléments visuels appropriés. Par exemple, lorsque le script
de gestion d’état détecte que l’intégrité du véhicule atteint 0, il fait apparaître l’effet de
fumée. Un conteneur et un script de génération de données sont également présents pour
calculer et sauvegarder des valeurs complémentaires nécessaires à la visualisation, qui ne
sont pas dans la BD. Par exemple, des données dictant le comportement visuel des rubans
d’attaque, qui n’ont rien à voir avec les données de simulation, doivent être générées par un
script qui détecte les pas de temps où les attaques se produisent et qui crée un nouveau
vecteur de données dictant le comportement du tracé de l’arc.
Figure 3-35 : Fenêtre de conception – LAV
89
D’autres ajouts et corrections de données se sont avérés nécessaires, notamment en ce qui
concerne la position XY des véhicules. En effet, à cause du manque de contrôle sur le
comportement des véhicules dans le simulateur, ces derniers adoptaient des mouvements
erratiques en début de parcours, non typiques de véhicules en mouvement dans une
direction donnée. Un filtrage systématique est donc effectué sur toutes les données de
position de véhicules pour les premières itérations de simulation. Également, aucune
donnée n’était disponible concernant l’orientation des véhicules, les agents n’étant simulés
qu’à titre de pastilles en mouvement sans direction; un angle associé à chaque pas de temps
est donc évalué durant ce processus de calcul, se basant sur les positions aux pas de temps
précédent et suivant.
3.7.2 Panneaux informatifs et interface de contrôle
Ces éléments font partie de la couche d’informations superposée à la visualisation 3D,
affichant des informations pertinentes à la branche de simulation présentement visualisée
(voir la Figure 3-38). Ceci est réalisé à l’aide d’un plug-in de type « Multi-Display »
regroupant des « Control Panels », qui sont des systèmes de rendu exclusivement 2D dans
lesquels sont branchés des éléments textuels. Les valeurs numériques des éléments qui y
sont affichés sont mises à jour automatiquement par le script de démarrage à la création
d’une nouvelle branche. Le panneau Configuration énumère les paramètres de la branche
Figure 3-37 : Fenêtre de conception – RPG
Figure 3-36 : Fenêtre de conception – IED
90
de simulation, c’est-à-dire les quantités d’armures latérale et sous-plancher, ainsi que le
nombre d’IEDs et de RPGs. Le cargo est une valeur définie par le scénario qui est
simplement fonction des quantités d’armure; plus il y a d’armure, moins il y a de cargo
transporté et vice-versa. Le panneau Performance affiche les résultats finaux des
principales mesures de performance associées à la branche courante. Dans le coin supérieur
droit est affiché le nom de la branche, tel que défini dans Multichronia. Directement en
dessous, le panneau Exploration branches(s) permet d’ouvrir l’application Tableau
Desktop avec les données de simulation relatives à la branche courante ou à toutes les
branches explorées jusqu’à maintenant, en cliquant sur le bouton approprié. Le panneau
Suppression branche(s) fonctionne de la même manière pour supprimer une ou des
branches. Un bouton Sélection branche permet de montrer ou de cacher un autre panneau
de sélection de type « bouton radio » permettant de passer d’une visualisation de branche à
une autre; en effet, à cause d’une certaine surcharge liée à l’ouverture de multiples fenêtres
de rendu dans Eye-Sys, il a été choisi de ne permettre la visualisation que d’une seule
branche à la fois.
Un autre type de panneau d’information est utilisé pour les agents de simulation, affichant
des données numériques sur ces derniers. La Figure 3-39 montre un exemple de fenêtre de
données pour chaque type d’agent. Les éléments textuels représentent les valeurs de
variables au pas de temps courant, et les petits graphiques en arrière plan montrent
l’historique de leurs 50 dernières valeurs. Ces panneaux d’information, visibles seulement
pour les agents sélectionnés dans la vue, sont réalisés à l’aide d’un plug-in Eye-Sys de type
Figure 3-38 : Panneaux informatifs et de contrôle
91
« Data Gadget », qui se comporte de la même manière qu’un « Callout » dans la vue 3D.
On peut d’ailleurs remarquer les instances de ces objets dans les fenêtres de conception des
agents, aux figures 3-35 à 3-37.
3.7.3 Graphique d’évolution
Alors que le panneau Performance présente les valeurs finales des mesures d’intégrité, de
cargo et de ponctualité pour une branche de simulation donnée, le graphique présenté à la
Figure 3-40 montre plutôt l’évolution des valeurs intermédiaires de la vitesse, de l’intégrité
et de la quantité de cargo (sur l’axe des Y) en fonction du pas de temps de la simulation
(sur l’axe des X). Ces valeurs n’étant pas préalablement calculées et stockées dans la BD,
elles sont entièrement générées dans un script à partir des données reçues, suivant les
formules mathématiques correspondantes spécifiées par le scénario. Les temps
correspondant aux pertes de véhicules, c’est-à-dire lorsque ces derniers atteignent une
valeur d’intégrité nulle et cessent d’avancer, sont également détectés lors de ce processus
de calcul et représentés par un astérisque sur le graphique.
Figure 3-39 : Panneaux d’informations de type « Data Gadget »
92
Au bas du graphique se trouve une barre d’état montrant l’activité courante du convoi
militaire. Cet état varie selon les événements rencontrés par ce dernier; lorsqu’il subit une
attaque par un RPG, il se met en mode Combat et ralentit; lorsqu’il détecte un IED sur la
chaussée, il se met en mode Désamorçage et arrête complètement pendant quelques pas de
temps. Le reste du temps, il avance à sa vitesse de croisière en mode Déplacement. Ces
états sont montrés par des bandes de couleur oranges et violettes en plus d’être explicités
par un élément textuel à droite. Une barre verticale indique le pas de temps courant et se
déplace automatiquement avec l’animation de la scène.
Avec ces informations, il est facile de voir la correspondance entre les ralentissements et les
états du convoi, ainsi que les pertes de véhicules et donc de cargo.
3.7.3.1 Implémentation
Le graphique d’évolution et la barre d’état utilisent des plug-ins de type « Plotter ».
Cependant, leurs fonctionnalités sont plutôt limitées; pour les autres éléments graphiques
comme les astérisques et les éléments textuels, des « Scene Graph Renderers » dont
l’arrière-plan est transparent sont superposés aux graphiques, avec des caméras
judicieusement positionnées de manière à ce que les systèmes de coordonnées des deux
fenêtres soient parfaitement superposés et à la même échelle. Ceci permet entre autres
d’assigner directement aux symboles d’astérisque la position XY correspondant au pas de
temps et à la valeur d’intégrité requises pour qu’ils se positionnent et se mettent à l’échelle
correctement sur le graphique. La plupart des objets de conception de la Figure 3-41, les
« Manipulators » notamment, servent à mettre en place ce stratagème de telle sorte que les
Figure 3-40 : Graphique d'évolution
93
échelles restent cohérentes en tout temps en s’adaptant automatiquement à la grandeur de la
fenêtre principale.
3.7.4 Vue « Distribution des simulations »
Cette vue est rendue possible grâce à un plug-in Eye-Sys développé à l’interne pour le volet
stratégique de l’analyse du scénario, mais dont l’utilité s’étend avantageusement à l’analyse
tactique. Un exemple est montré à la Figure 3-42.
Figure 3-42 : Vue « Distribution des simulations »
Figure 3-41 : Fenêtre de conception – Graphique d'évolution
94
Il s’agit d’un graphique à trois dimensions dans lequel les données sont représentées sous
forme de sphères colorées. Dans le cas tactique, à chaque axe correspond un paramètre de
configuration d’une branche de simulation : blindage latéral, blindage sous-plancher et
nombre d’explosifs (le nombre de roquettes est en tout temps complémentaire pour obtenir
5 ennemis au total). Toutes les combinaisons de paramètres de simulation possibles peuvent
donc être représentées dans ce graphique.
Dans le cadre des expérimentations, un certain nombre de branches par défaut sont visibles
à tous les utilisateurs au début de leur session d’analyse et déjà disponibles dans les outils
d’IMAGE; ces branches sont représentées par des sphères grises. Comme nous l’avons
mentionné précédemment, la création de nouvelles branches de simulation est entièrement
gérée à l’aide de Multichronia. Son interface graphique permet à l’utilisateur de maintenir
plusieurs arbres multichroniques simultanément pendant une session d’analyse et de les
explorer en alternance à l’aide d’un mécanisme d’onglets. Il n’y a qu’un seul onglet, et
donc un seul arbre multichronique, qui soit visible en tout temps. Quoique toutes les
branches créées, tous onglets confondus, soient présentées sur le graphique de la
distribution des simulations, les sphères correspondant aux branches de l’onglet
présentement sélectionné dans Multichronia sont visibles en turquoise et celles des autres
onglets, en bleu foncé. La branche de la visualisation courante dans la vue Eye-Sys est
identifiée par un objet de type « callout ».
L’utilité de ce graphe réside surtout dans le fait de voir rapidement les régions de l’espace
de simulation ayant été plus ou moins explorées jusqu’à maintenant, pouvant guider
l’utilisateur dans la poursuite de son analyse.
3.7.5 Exploration tactique finale
La vue tactique finale, incluant tous les éléments décrits précédemment en tenant compte de
la rétroaction des intervenants du projet, est montrée à la Figure 3-43. Les panneaux
informatifs y sont agencés de manière à maximiser l’espace utilisé tout en ayant un souci
d’esthétisme et de clarté visuelle. Certains panneaux ont été abandonnés, notamment ceux
servant à sélectionner et à supprimer les branches car dans la version finale, ces interactions
sont entièrement exécutées dans l’explorateur de simulations Multichronia et synchronisées
95
avec Eye-Sys (mécanismes décrits plus en détails à la section 3.8). Un petit panneau a
cependant été ajouté en bas à droite, permettant à l’utilisateur de choisir entre deux types de
prise de vue grâce à des caméras préconfigurées, la première offrant une navigation libre et
l’autre étant fixe mais suivant le déplacement du convoi en tout temps. Un autre bouton
permettant de montrer ou cacher la vue Distribution des simulations a également été ajouté.
3.7.6 Vue tactique allégée (groupe contrôle)
Une version allégée de la vue tactique a également été mise en place pour les besoins de
l’expérimentation. Elle sera utilisée par le groupe contrôle pour lequel les fonctionnalités
sont réduites, servant de point de comparaison avec les versions « IMAGE Desktop » et
« IMAGE CAVE ».
La vue tactique allégée, montrée à la Figure 3-44, fonctionne de la même manière que la
vue régulière sauf qu’il n’y a qu’une seule caméra dont l’orientation est fixée en position
orthogonale au plan XY de la scène. Les modèles 3D des RPGs et IEDs sont également
remplacés par de simples icônes 2D, et les textures du sol sont enlevées pour des raisons
Figure 3-43 : Agencement final de la vue tactique
96
d’esthétisme et de clarté visuelle. Les diagrammes d’analyse, graphiques et vue de la
distribution des simulations, sont enlevés et seuls les panneaux Configuration, Performance
et le nom de la branche courante restent visibles.
3.8 Synchronisation avec Multichronia
Il importe de rappeler que la synchronisation entre les divers outils a été identifiée comme
étant l’un des besoins primordiaux du projet IMAGE. C’est pourquoi un effort soutenu en
ce sens a été fourni par les développeurs des différents modules. Comme nous l’avons
décrit à la section 3.6, le passage de toute l’information relative aux simulations vers une
BD centrale a été une étape déterminante de cet accomplissement. Cependant, au niveau
des actions de l’utilisateur et de la cohérence entre les éléments visuels pendant
l’expérimentation, des mécanismes plus adaptés, plus efficaces et plus rapides sont
nécessaires. Voilà donc l’intérêt de conserver et d’exploiter le lien de connexion socket
existant entre Simulation et Exploration, via le ImageDataServer. Comme nous l’avons
mentionné plus tôt, ce lien sert d’intermédiaire à un protocole de communication simple
que nous décrivons dans la section qui suit.
Figure 3-44 : Vue tactique allégée
97
3.8.1 Protocole de communication
Dans la version tactique finale servant aux expérimentations, toutes les interactions
relatives au contrôle des branches de simulation sont reléguées à l’application
Multichronia. Cependant, les actions comme la création, la destruction, la sélection et le
déplacement temporel des nœuds de simulation doivent avoir des répercussions sur la vue
tactique de l’Exploration. La création doit déclencher le processus de requêtes à la BD et
l’instanciation des objets; la destruction doit les supprimer; la sélection doit faire apparaître
la fenêtre de visualisation appropriée; le déplacement temporel d’un nœud, exécuté
manuellement par l’utilisateur ou automatiquement par le simulateur, doit faire bouger et
positionner le convoi de la vue tactique au pas de temps spécifié. Un échantillon
représentatif de messages utilisés dans ce processus de synchronisation est présenté à la
Figure 3-45.
Toutes les informations sont transmises via des éléments XML. Le nom de l’élément
indique le contexte de simulation, soit « tacticalConvoy » ou « strategicalConvoy » selon le
cas. Le type de message et d’autres informations pertinentes sont donnés par des attributs
Figure 3-45 : Exemple type de messages envoyés par Multichronia
98
de l’élément XML. L’attribut « name » indique le nom de la branche de simulation
concernée et « status », son état courant. Ce dernier paramètre indique généralement qu’une
interaction de l’utilisateur, comme l’ajout, la suppression ou la sélection de branche, a été
exécutée. Dans le cas d’un « update », le pas de temps courant et la vitesse de simulation
sont également fournis dans des attributs appropriés. Un message contenant l’attribut
« treeName » indique qu’un onglet a été sélectionné dans Multichronia; chaque onglet
représentant un arbre multichronique indépendant, toutes les branches qu’il contient sont
énumérées dans des sous-éléments du message racine (comme aux lignes 11 à 14 de la
Figure 3-45).
3.8.2 Plug-in « Driver Regulator »
Nous avons présenté sommairement à la section 0 le plug-in « Driver » de Eye-Sys, qui
permet de créer des animations en faisant varier les valeurs contenues dans les historiques
de propriétés des objets sur lequel il est branché. Avant la fusion totale des interactions
entre Simulation et Exploration, le contrôle de l’animation était fait dans Eye-Sys à partir
d’une fenêtre de contrôle spécifique au « Driver »; cette dernière offre des fonctionnalités
typiques telles jouer, pause, avancer et reculer. Le mode d’animation de données peut être
contrôlé de plusieurs manières : par pourcentage, par valeur ou simplement par une horloge
en temps réel. Pour notre visualisation, nous utilisons le mode par valeur où ces dernières
s’étendent sur le temps complet de la simulation la plus longue (typiquement de 0 à 300 pas
de temps). La vitesse de rendu est contrôlable par le pas de calcul (ou « step », différent du
pas de temps), c’est-à-dire l’incrément ajouté à la valeur de temps courant à chaque trame
(ou « frame ») de rendu graphique. Cela veut donc dire que la vitesse réelle dépend du pas
de calcul et de la vitesse de rendu graphique, et donc du matériel et de la complexité de la
scène. Or, nous voulons synchroniser la vitesse réelle de l’animation Eye-Sys à celle
donnée par Multichronia. Une tentative de solution a été élaborée avec le plug-in « Driver
Regulator », dont on peut voir les propriétés à la Figure 3-46.
99
Il s’agit d’un plug-in de type « Manipulator » conçu pour fonctionner exclusivement avec
l’objet « Driver ». Le principe général est d’ajuster en temps réel le pas de calcul (« step »)
du « Driver » de manière à ce que la valeur de temps courant soit le plus près possible de
celle spécifiée par Multichronia. Ce dernier envoie périodiquement des messages de type
« update » dont les valeurs de temps sont communiquées au plug-in par commande COM
via le ImageDataServer. La vitesse du simulateur est alors évaluée et comparée à celle de
l’engin d’animation de Eye-Sys et le pas de calcul ajusté en conséquence, augmentant
lorsqu’Eye-Sys est en retard ou diminuant lorsqu’il est en avance, jusqu’à ce qu’il soit à
l’intérieur d’une zone satisfaisante. Quoique simpliste, cette approche s’avère assez stable
pour les besoins du système.
3.9 Amélioration des performances avec MySQL
Comme nous l’avons expliqué plus tôt, toutes les données de simulation nécessaires à la
visualisation sont acquises via un script dans Eye-Sys, qui utilise un plug-in de type
« Database » pour faire les requêtes à la BD MySQL. Cependant, la procédure de
récupération de données pour une seule branche est relativement longue, soit d’environ 15
secondes avec les ordinateurs actuels. Ce problème ayant été observé pendant les
développements et soulevé lors d’évaluations préliminaires, des solutions visant à accélérer
la procédure ont été étudiées. Une source de ralentissement soupçonnée de jouer un rôle
important dans ce problème est le plug-in « Database » de Eye-Sys qui, à chaque requête,
ouvre une connexion à la BD, exécute la requête et ferme la connexion. Dans un contexte
Figure 3-46 : Fenêtres de propriétés - Plug-ins « Driver » et « Driver Regulator »
100
où les requêtes sont effectuées par centaines, cela est loin d’être optimal. Ceci crée
d’ailleurs un problème au niveau serveur MySQL qui cesse d’accepter les connexions après
en avoir reçu un certain nombre dans un court laps de temps, faisant échouer le processus
de création de branche.
3.9.1 Plug-in « MySQL Database »
Une solution à ce problème relativement facile à réaliser est de remplacer le plug-in de BD
de Eye-Sys. Pour cela, un plug-in Eye-Sys de type « Input » a donc été implémenté en
fonction des besoins du projet, à l’aide de la librairie MySQL++. Cependant, afin de limiter
les changements aux composants déjà développés, une interface et un mode de
fonctionnement semblables à l’ancien plug-in ont été adoptés, de telle sorte qu’il n’y ait
qu’un seul objet à remplacer et que les modifications au code soient réduites au minimum.
La Figure 3-47 montre la fenêtre des propriétés du plug-in « MySQL Database ». De
manière analogue à l’ancien plug-in Eye-Sys, une section de propriétés est dédiée à la
configuration de la connexion; elle peut être de type TCP ou « Named Pipe », un mode de
connexion local propre à Windows, et les traditionnels paramètres de connexion et
d’identification de l’utilisateur sont également configurables via diverses propriétés. La
différence majeure avec l’ancien plug-in est la possibilité de créer une connexion directe et
persistante à la BD, qui ne se réinitialise pas à chaque requête.
Figure 3-47 : Fenêtre de propriétés du plug-in "MySQL Database"
101
Avec ce nouveau plug-in, une amélioration notable de la vitesse d’accès a été remarquée,
retranchant 4 à 5 secondes au temps de création d’une branche.
3.10 Système de « logs »
La motivation principale derrière cette catégorie de fonctionnalités est de conserver la trace
des actions exécutées par un utilisateur lors d’une session avec IMAGE, pour des fins
d’analyse. En effet, les expérimentations en psychologie cognitive requièrent
l’enregistrement de données concernant les interactions des utilisateurs comme l’heure
d’exécution d’une action, le type d’action et l’application qui est utilisée. L’analyse de ces
informations permet entre autres de suivre la démarche d’analyse des utilisateurs et de
déterminer quels outils y ont joué un rôle prépondérant. Cette rétroaction pourra également
donner des indications intéressantes quant à la pertinence et à l’apport des outils proposés
pour l’augmentation de la compréhension.
Pour la visualisation tactique dans sa version finale, les actions suivantes doivent être
enregistrées : la sélection et désélection des LAVs, IEDs et RPGs, les changements de prise
de vue (clics sur les boutons de caméra), l’ouverture de Tableau Desktop pour l’exploration
de données (clics sur les boutons du panneau Exploration), et l’ouverture et fermeture de la
vue de distribution des simulations (clics sur le bouton qui y est associé). Les informations
sont bien sûr inscrites dans une table de la BD, dont un exemple de contenu avec les
champs appropriés est montré à la Figure 3-48.
Figure 3-48 : Exemple de contenu de la table « ExplorationTacticalLog »
102
Les clics de bouton sont très faciles à retracer à l’aide des scripts Eye-Sys; il suffit que le
script soit directement lié à l’objet de bouton, de telle sorte que l’exécution se produise
seulement lorsque le bouton est pressé. Dans l’exemple de la Figure 3-49, le code servant à
enregistrer les informations est intégré au script d’exécution de l’application Tableau
Desktop. Un objet « MySQL Database » est branché aux scripts et sert d’interface vers la
BD dans laquelle les informations sont enregistrées par des instructions SQL d’insertion.
Pour les sélections, le mécanisme est un peu plus complexe. En effet, il est impossible
d’être automatiquement informé de la sélection d’un objet par une propriété pouvant
déclencher un script; il faut donc surveiller constamment l’état de sélection des objets de la
scène et vérifier s’ils correspondent aux catégories que l’on désire retracer. La Figure 3-50
donne un aperçu des objets Eye-Sys nécessaires à cette fonctionnalité.
Le script « TacticalSelLogger » contient les instructions nécessaires à l’enregistrement des
événements de sélection. Il a accès à une liste des objets présentement sélectionnés parmi
tous ceux qui sont instanciés, grâce à une fonction COM exposée par l’application
principale. Il fait ensuite une vérification des noms de ces objets et s’ils correspondent à un
LAV, un IED ou un RPG, ils sont enregistrés dans la table MySQL. Un mécanisme
automatique doit cependant forcer cette procédure à être constamment ré-exécutée car elle
Figure 3-50 : Fenêtres de conception et de propriétés – Log des sélections
Figure 3-49 : Fenêtre de conception - Scripts Tableau et logs
103
ne peut être déclenchée par un événement régulier. C’est l’utilité du plug-in
« ScriptAutoRefresh », qui a été développé auparavant dans le cadre d’autres essais. Sa
seule fonctionnalité est de forcer l’exécution périodique des scripts qui lui sont connectés,
via une liste extensible de pointeurs d’objets de type « Multiproperty ». Ceci est facilement
implémenté à l’aide d’une minuterie disponible dans le SDK de Eye-Sys. Afin de donner
plus de flexibilité au plug-in, une propriété permettant de régler la fréquence de
rafraîchissement lui a été ajoutée. Selon nos tests avec le système, un taux de
rafraîchissement de 3 ou 4 fois par seconde s’avère suffisant, réduisant ainsi au minimum
l’utilisation du processeur et du thread principal de Eye-Sys, ne causant donc aucune
pénalité de performance perceptible.
104
4 Évaluation
Dans cette partie, nous commençons par revenir brièvement sur le fonctionnement du
système intégré en commentant un exemple d’utilisation. Par la suite, nous prenons du
recul par rapport au projet en discutant de certains aspects des développements réalisés et
en proposant certaines recommandations. Nous terminons en faisant un retour sur
l’utilisation de Eye-Sys, notre plateforme de développement principale.
4.1 Test du système intégré
4.1.1 Exemple d’utilisation
Les composants de la version « Desktop » d’IMAGE sont désormais très liés dans leur
mode de fonctionnement. Cette section montre un aperçu de l’utilisation du système intégré
dans son ensemble, mettant en contexte les fonctionnalités que nous avons implémentées et
décrites dans le chapitre précédent.
Dû à l’utilisation simultanée de plus d’un logiciel, il est préférable de travailler avec une
configuration à plusieurs écrans; les devis d’expérimentations en psychologie cognitive
sont d’ailleurs conçus pour des ordinateurs de bureau utilisant un affichage à trois écrans
pour les diverses applications de la suite d’outils. Les machines utilisées pour les
développements et les expérimentations sont identiques et possèdent les configurations
matérielle et logicielle suivantes :
Processeur Dual Core AMD Opteron version 275 à 2.2 GHz
2 Go de mémoire vive DDR2 à 667 Mhz
2 cartes graphiques nVidia Quadro FX 4500 avec 1 Go de mémoire vive DDR3
Microsoft Windows XP Professional SP3
Une saisie de deux écrans affichant simultanément Multichronia, l’explorateur de
simulations, et Eye-Sys, l’outil de visualisation, est présentée à la Figure 4-1.
105
À
l’aide d’une petite application connexe servant de gestionnaire d’expérimentation, l’outil
Eye-Sys est démarré avec le ImageDataServer, suivi de Multichronia qui au démarrage
tente de s’y connecter par liaison socket TCP. Si cette opération réussit, il va transférer par
la suite tous les messages correspondant aux événements de navigation pour la
synchronisation (comme expliqué à la section 3.8.1).
La création d’une vue se fait dans Multichronia par la sélection du nœud racine et l’entrée
de la commande correspondante du menu de souris associé. Une boîte de dialogue s’ouvre
alors, permettant la sélection des valeurs désirées pour les paramètres de simulation.
Lorsque c’est fait, un nouveau nœud apparaît dans l’arbre multichronique et un message
d’attente est affiché du côté de Eye-Sys pendant le processus de récupération de données et
de création d’objets. Une fois la branche créée, son nœud correspondant peut être déplacé le
long de la ligne de temps et sa position temporelle est constamment mise à jour dans la
visualisation, presque instantanément. Un double clic sur le nœud active la fonction
« play » qui démarre l’animation automatique de la simulation. Lorsque plusieurs branches
sont créées, c’est par la sélection d’un nœud dans Multichronia, par simple clic, que la
visualisation correspondante est assignée à la fenêtre principale de Eye-Sys.
Les branches créées sont automatiquement sauvegardées par Multichronia et restaurées lors
de l’ouverture de la session suivante. Les messages correspondants sont envoyés à la
visualisation à ce moment, déclenchant le processus automatique de récupération de
données pour toutes les branches nécessaires.
Figure 4-1 : Saisie d'écran du système intégré
106
4.1.1.1 Performance
La réponse du système est généralement très bonne et relativement stable : les messages de
synchronisation sont acheminés vers la visualisation en moins d’une demi seconde; le
rendu 3D est également fluide et constant car la complexité de la scène ne varie que très
peu.
Le temps de création d’une branche est cependant relativement long, soit de 12 à 15
secondes en moyenne et ayant légèrement tendance à augmenter lorsque le nombre de
branches instanciées devient grand. Cela ne pose pas de problème majeur pour le cours
normal d’une session d’expérimentation. Toutefois, à cause du délai inhérent au processus,
la restauration d’une session peut prendre plusieurs minutes, tout dépendant du nombre de
branches à récupérer.
Également, un phénomène que nous avons observé, qui est partiellement hors de notre
contrôle, est l’augmentation constante de l’utilisation de mémoire de Eye-Sys au fil du
temps. Celle-ci ne cesse de croître, même lorsque des objets sont supprimés. Des problèmes
de performance peuvent alors être observés, souvent après la création d’une vingtaine de
branches. Une fuite de mémoire dans Eye-Sys au niveau de la création et de la suppression
des objets est probablement la cause de ce problème normalement banal et sans
conséquences, mais ici amplifié par nos procédures de création et de destruction d’objets en
masse et sur une longue période.
4.1.2 Débogage du scénario
Nous avons mentionné à la section 3.6 que les données de simulation étaient générées par
une application responsable d’analyser le contenu XML provenant du simulateur pour
toutes les branches possibles et de remplir la base de données. Cependant, certains cas
spéciaux faisaient en sorte qu’il y avait quelques failles dans les algorithmes d’analyse de
cette application, créant des inconsistances dans les données et par le fait même dans la
visualisation. Grâce aux éléments visuels fournis par la vue tactique, plusieurs problèmes
dans diverses branches ont pu être identifiés tels des dommages aux véhicules mal
comptabilisés, des fausses attaques, des attaques manquantes ou mal documentées dans les
données, des véhicules restant dans un état bloqué avant la fin de la simulation, et même
107
des valeurs finales de mesures de performance erronées. Un autre problème relatif aux
spécifications du scénario faisait également en sorte que les attaques d’IED déclenchaient
un état de combat dans le convoi dans certaines branches et pas dans d’autres, alors qu’elles
n’auraient jamais dû en provoquer. Ceci a pu être identifié grâce à la vue du graphique
d’évolution et la barre d’état.
4.2 Discussions
4.2.1 Améliorations possibles et recommandations
4.2.1.1 Accès à la base de données
Même si certaines améliorations ont pu être apportées pour diminuer le temps d’accès à la
base de données, le délai reste cependant élevé et peut devenir dérangeant pour l’utilisateur.
Le système fonctionne jusqu’à maintenant avec une BD locale et les pertes de temps
relatives à la connexion MySQL ont été somme toute éliminées par le remplacement du
plug-in « Database » de Eye-Sys, mais le gain de vitesse global est moins grand que prévu;
ces délais significatifs proviennent donc d’autres sources. Le fait que tout le code soit
exécuté sous forme de script, un langage interprété, est probablement l’une des causes de
ralentissement. L’utilisation de fonctions COM comporte également un coût en
performance et comme ces dernières sont exploitées par l’engin de scripts, cela peut donc
ajouter une pénalité supplémentaire. Finalement, une autre cause de lenteur est sans doute
le fait de devoir effectuer une boucle de plusieurs centaines d’itérations pour obtenir toutes
les données de chaque branche.
Devant ces faits, il devient évident que pour obtenir des gains de performance
supplémentaires, il faut revoir complètement le mode d’acquisition des données. D’abord,
le traitement de données de masse au sein même du système de visualisation est inadéquat
puisque cela accapare toutes ses ressources de calcul et bloque complètement le
rafraîchissement graphique pendant plusieurs secondes. De plus, advenant le cas où une
autre plateforme utilisant les mêmes données serait introduite dans la suite d’outils, soit
tous les accès de données et leur formatage sont à refaire, soit il faut exporter les données
de la première application vers la nouvelle, imposant de nouveau une charge de travail
supplémentaire à la visualisation. La meilleure solution serait d’exécuter tout le travail
108
relatif au traitement de données dans une application externe, jouant le rôle de point central
de distribution. Le choix de design concernant les accès à la BD décrit à la section 3.6.1
pourrait donc être remis en question; alors que le premier choix s’avérait avantageux à
court terme, c’est la seconde option qui aurait probablement été préférable à long terme.
Également, la structure de la BD et la manière d’interagir avec cette dernière mériteraient
probablement d’être revues; la structure élaborée au départ par les développeurs de la partie
Simulation n’a pas nécessairement été conçue en tenant compte des besoins des autres
modules, dont l’Exploration. Le problème d’extraction de données décrit à la section
3.6.2.1 pourrait probablement être réglé en découplant les paramètres d’identifiants de
branche et de temps dans deux entrées distinctes des tables concernées, réduisant les
centaines de requêtes à une seule. Même si cela paraît simple, le contexte de
développement et un manque de connaissances et d’expérience de notre part avec les bases
de données ont fait en sorte que cette option n’avait pas été envisagée au départ.
4.2.1.2 Mode de création et de suppression de branches
Comme nous l’avons décrit à la section 3.7.1, le système de visualisation est implanté de
telle sorte qu’à chaque nouvelle branche qui est créée, une nouvelle série d’objets est
instanciée. Cette approche avait été adoptée pour des raisons pratiques pendant le
développement. En effet, il est plus efficace, en termes de rapidité et de risque d’erreurs, de
faire des modifications à un seul groupe d’objets à partir duquel on peut créer
dynamiquement de multiples instances que de faire plusieurs fois les mêmes modifications
à répétition sur plusieurs instances statiques des mêmes types objets. Également, cette
méthode a l’avantage que les conteneurs de données et leurs liaisons avec les propriétés des
objets n’ont jamais à être changés. Un schéma structurel montrant l’organisation des objets
Eye-Sys est montré à la Figure 4-2.
Comme on peut le constater, il y a un ensemble complet d’objets pour chacune des
branches de simulation, dont le contenu est lié à un arbre de rendu (Scene Graph Renderer).
Ces ensembles sont tous branchés à un objet agissant à la manière d’un multiplexeur, qui
permet de sélectionner l’un d’entre eux à la fois via une propriété énumérée, et dont la
109
sortie est branchée à la fenêtre de visualisation. Les liens en gras montrent qu’une
importante quantité de données circule via de nombreux liens entre les modules concernés.
Cette approche résulte en un très grand nombre d’objets instanciés dans la fenêtre de
conception. Quoique cela ne pose pas de problème a priori puisque cette fenêtre est fermée
pendant la session d’analyse, il semble que certaines pénalités en performance et de
l’instabilité y soient associées dans certains cas, comme nous l’avons mentionné à la
section précédente. Il n’est d’ailleurs pas optimal de garder de nombreuses instances
d’objets graphiques qui sont en tous points identiques mis à part leur position et leur état
d’affichage.
Une alternative à la structure actuelle serait de n’avoir qu’une seule instance des objets de
visualisation et de ne dupliquer que les conteneurs de données. Un diagramme théorique
présenté à la Figure 4-3, semblable au précédent, montre une structure possible pour cette
approche.
Branche 1
Données LAV
Graphiques
IED
RPG
Fenêtre de
visualisation
Branche 2
Données LAV
Graphiques
IED
RPG
Branche n
Données LAV
Graphiques
IED
RPG
Multiplexeur
...
Arbre de
rendu
Arbre de
rendu
Arbre de
rendu
(x 10)
(x 10)
(x 10)
(x 5)
(x 5)
(x 5)
Figure 4-2 : Organisation structurelle actuelle des objets Eye-Sys pour la visualisation
110
On peut effectivement constater qu’un seul groupe d’objets de visualisation serait alors
présent, ce qui forcerait à déplacer le multiplexeur entre les conteneurs de données et les
autres objets. Sa tâche de multiplexage s’en trouverait cependant énormément complexifiée
car il devrait maintenant gérer toutes les connexions de données partant des conteneurs vers
les objets, contrairement au modèle actuel où il n’y a qu’un seul lien à changer.
Il est difficile d’évaluer si le gain en performance de ce mode de fonctionnement pourrait
justifier les efforts de développement requis pour sa réalisation. Pour cette raison, cette
option a été écartée. Advenant le cas où les problèmes de stabilité qui ont été rencontrés en
seraient venus à compromettre le bon fonctionnement du système, les changements auraient
peut-être été nécessaires afin de limiter les créations et destructions en masse, en apparence
à l’origine de ces problèmes.
4.2.1.3 Visualisation, rendu graphique et interaction
Une autre possibilité n’ayant été que très peu explorée est celle de développer un nouveau
plug-in de système de rendu pour Eye-Sys. Cette option avait été écartée au départ en
raison de l’apparente complexité de la tâche. En effet, ceci implique, pour un système
d’arbre de rendu par exemple, de réécrire entièrement le code nécessaire au contrôle du
rendu graphique et de ré-implémenter plusieurs fonctions responsables de gérer les
Branche 1
Données
LAV
Graphiques
IED
RPG
Fenêtre de
visualisationMultiplexeur
Branche 2
Données
...
Branche n
Données
(x 10)Arbre de
rendu
(x 5)
Figure 4-3 : Organisation structurelle alternative pour le système de visualisation
111
événements de clavier et souris, les modes de navigation et le zoom, la sélection des objets
dans la fenêtre, etc. Cependant, cela laisse beaucoup plus de latitude et de possibilités pour
l’implémentation de fonctionnalités sur mesure, notamment en termes d’interaction, ce qui
nous a manqué à maintes reprises. Advenant le cas où des développements supplémentaires
avec Eye-Sys seraient envisagés dans ce projet ou dans un autre contexte, l’exploration de
cette avenue serait fortement souhaitable, voire même indispensable.
Pour ce qui est de la visualisation, certaines améliorations relativement peu difficiles à
implémenter auraient pu être faites, notamment pour les panneaux d’information. Alors
qu’ils n’affichent présentement que des valeurs numériques, une représentation sous forme
d’histogramme pour les mesures de performance, par exemple, donnerait un meilleur
aperçu visuel des valeurs représentées; ceci aurait pour effet de diminuer la charge mentale
de l’utilisateur qui n’aurait pas nécessairement besoin de lire les valeurs numériques et de
les interpréter, augmentant ainsi l’efficacité de tâches comme l’identification de la
meilleure branche pour l’une ou l’autre des mesures de performance.
Une meilleure diversité d’outils et plus de flexibilité dans la manière de les utiliser et de les
agencer seraient également souhaitables. La disposition actuelle de la fenêtre de
visualisation a été travaillée et approuvée rigoureusement pour être conforme aux exigences
des expérimentations en psychologie cognitive. Les aspects fonctionnels du système, tels
communications, synchronisation et « logs », ont également requis beaucoup d’efforts de
développement, laissant moins de temps pour le design de fonctionnalités visuelles.
Cependant, il pourrait être intéressant de creuser davantage les possibilités en termes de
visualisation d’analyse, telle la vue de distribution des simulations qui a déjà été intégrée;
une version améliorée du plug-in de graphique 3D a d’ailleurs été développée pour une vue
d’analyse dans le contexte stratégique du scénario, qui permet de comparer les valeurs de 5
paramètres à la fois, exploitant la forme et la couleur des points.
Pour ce qui est de la synchronisation du rendu de l’animation Eye-Sys avec le logiciel de
simulation, quoiqu’offrant une performance satisfaisante dans des conditions prédéfinies
comme celles des expérimentations, le plug-in de régulation devient souvent instable
lorsque l’on modifie la vitesse de rendu désirée trop loin des valeurs par défaut.
Présentement, nous obtenons un compromis entre le synchronisme parfait des positions
112
temporelles et une certaine fluidité d’animation; en effet, nous aurions pu nous contenter
d’affecter les valeurs des positions aux conteneurs de données sans utiliser l’engin
d’animation de Eye-Sys, mais nous privant de la fluidité offerte par son système
d’interpolation linéaire, résultant en un mouvement constamment saccadé. Cependant,
suivant la même technique présentement utilisée, il serait possible de raffiner
l’implémentation avec un meilleur type d’asservissement utilisant par exemple un
correcteur proportionnel intégral (PI), si l’utilité et le besoin s’en faisaient sentir. Toutefois,
dans tous les cas, ce genre de manœuvre reste un tour de force peu élégant pour faire
fonctionner ensemble des plateformes indépendantes n’étant pas prévues pour ce genre de
synchronisme.
4.2.2 Plateforme Eye-Sys
Cet outil ayant été au cœur de la majeure partie des développements de notre projet, il
convient d’y revenir et de faire un bilan de l’utilisation approfondie que nous en avons
faite.
La facilité de créer rapidement des scènes de rendu 3D animées de toutes sortes par la
connexion de modules indépendants est sans doute l’attrait le plus marquant que procure
l’application Eye-Sys, un fait qui depuis le début a joué en sa faveur, surtout dans un
contexte où les objectifs étaient plus ou moins précis. Les nombreuses possibilités pour
l’importation de données et l’ajout de fonctionnalités avec le SDK étaient également toutes
indiquées pour répondre à de nouveaux besoins éventuels. Cela étant dit, lorsque l’on
parvient à l’étape de raffinement et des détails visuels, les plug-ins fournis avec
l’application manquent souvent de flexibilité, notamment en ce qui a trait aux graphiques
2D et aux panneaux d’information et de contrôle. Plusieurs de ces objets n’ont pas
nécessairement été pensés en vue du genre d’utilisation que nous aurions désiré en faire;
par exemple, certaines fonctionnalités permettant de modifier le type de tracé du « Plotter »
sont cachées dans le plug-in, c’est-à-dire non exposées via des propriétés régulières, et il est
donc impossible de les modifier automatiquement à l’aide de scripts ou par interaction
COM. À cet égard, il est regrettable de ne pas pouvoir créer de nouveaux plug-ins, par
mécanisme d’héritage, à partir de ceux qui existent déjà et qui pourraient conserver la
113
majeure partie de leurs fonctionnalités, tout en permettant d’en ajouter ou d’en modifier
selon nos propres besoins.
Alors que les scripts ne semblaient pas particulièrement attrayants au départ en contraste
des fonctions COM et du SDK, ils ont finalement été utilisés à très grande échelle dans le
projet, principalement à cause de l’énorme flexibilité qu’ils procurent. Ils ont notamment
accès à pratiquement toutes les fonctionnalités du programme ainsi qu’à tous les objets
instanciés et leurs propriétés, en plus de pouvoir en créer d’autres. La syntaxe est également
plus simple et plus rapide à s’approprier que le C++. Cependant, en plus des pénalités de
performance dont nous avons déjà parlé, un des désavantages de cette méthode est
l’impossibilité de déboguer en cours d’exécution. Seul un message vague avertissant que le
script a échoué est montré lorsque cela se produit, mais on peut cependant inclure des
sorties texte à la console pour observer des états de variables. Quoique cela soit souvent
suffisant, lorsque les scripts atteignent plusieurs centaines de lignes de code comme dans la
routine de création de vue tactique, de meilleurs outils de débogage seraient souhaitables.
Finalement, le fait que l’application soit complètement fermée pose toutes sortes de
limitations quant au fonctionnement global du système. Nous avons déjà parlé du manque
de contrôle sur les objets de scripts, pour lesquels nous aurions voulu une meilleure
transparence quant à leur comportement et à leur interaction avec les autres éléments du
programme; ces problèmes ont heureusement pu être judicieusement résolus grâce aux
mécanismes de contrôle que nous avons mis en place. Toutefois, la conséquence la plus
ennuyeuse du fait de n’avoir aucun accès au code est d’être à la merci des bogues de
l’application. À maintes reprises, des problèmes étranges, étant parfois même fatals pour
l’application principale, ont été observés et nous ont empêchés de réaliser certaines
opérations nécessaires, notamment concernant des fonctions de suppression d’objets via
fonctions COM. Certains autres problèmes mineurs, comme dans certaines fonctions de
gestion d’ouverture et de fermeture de fenêtres de rendu, ont rendu difficile
l’automatisation complète du système pour l’expérimentation et les différents scénarios.
Probablement dû au modèle d’affaires et au marché cible strictement commercial visé par
Eye-Sys, il n’y a pas vraiment (encore) d’ouverture vers une communauté d’utilisateurs
partageant leurs expériences de développements entre eux et les plug-ins qu’ils ont eux-
114
mêmes développé, même avec la présence d’un forum de discussion officiel. Ce dernier est
cependant un excellent outil pour le support en ligne, régulièrement consulté et maintenu
par les développeurs de Eye-Sys eux-mêmes, qui répondent généralement très bien aux
questions des utilisateurs. Le type d’interaction y reste toutefois très individuel et il n’y a
pratiquement pas d’échange entre les utilisateurs eux-mêmes.
115
5 Conclusion
Les objectifs que nous avons décrits au départ quant à la réalisation d’un système
permettant d’aider à la compréhension de situations complexes étaient de taille. Dans un
contexte initial peu balisé, les premières étapes ont consisté en une familiarisation dans le
domaine de la visualisation en général, de la psychologie cognitive et des interfaces
personne-machine. Beaucoup de liens existent entre ces domaines d’étude, ce que l’on ne
suspecterait pas nécessairement à première vue. Une certaine sensibilisation face aux
aspects relatifs à l’humain pour le développement de systèmes numériques a aussi été
développée; pour un projet tel qu’IMAGE où l’utilisateur humain est au centre de toute
interaction, il s’agit d’un point important à considérer.
La première phase de développement logiciel a surtout touché les aspects techniques de la
gestion de plusieurs flots de données XML en parallèle, motivée par le besoin de rendre
disponibles des données de simulation vers le module Exploration. Cette approche a été
remplacée par la BD par la suite, mis à part le transfert de messages pour la
synchronisation. Cependant, il pourrait être envisagé de reprendre et raffiner ce mode de
fonctionnement dans des versions ultérieures du projet ou dans d’autres contextes
semblables où des données fraîchement simulées doivent être passées très rapidement entre
divers modules. Alors que présentement, la BD suffit amplement aux besoins car toutes les
données sont pré-simulées, il suffirait d’un scénario avec quelques paramètres
supplémentaires ou de plus grands intervalles de valeurs pour que cette approche avec pré-
simulation complète soit impensable à cause du trop grand nombre de branches possibles;
cela augmente encore si on inclut les possibilités de créer des sous-branches via une
exploration interactive. De plus, une gestion encore plus efficace des données, permettant
par exemple le transfert et le rendu de données au fur et à mesure qu’elles sont disponibles,
serait probablement nécessaire afin d’éviter de trop grandes latences lors des créations de
branches. Une approche hybride combinant un traitement temps-réel et une BD pourrait
être envisagée.
C’est au cours des étapes suivantes que le travail principal sur la visualisation a été réalisé.
Alors que nous avons eu affaire à un scénario militaire tactique, ce sont les aspects
116
géospatiaux, près des préoccupations réelles sur le terrain, qui se sont retrouvés au premier
plan. Les éléments visuels qui ont été développés expriment, en fonction du temps et de
l’espace, les événements d’attaques, d’explosions, de pertes de véhicules, etc.; ils facilitent
l’analyse de premier niveau des événements du scénario et de leurs causes directes. Pour
une analyse plus approfondie nécessitant la comparaison de plusieurs branches et la
découverte de tendances, l’outil Tableau est disponible, offrant plusieurs possibilités de
représentations en 2D pour toutes les données de la simulation. Il pourrait être intéressant
d’ajouter des outils d’analyse en 3D avec Eye-Sys pour ces mêmes données.
Certaines théories en interfaces personne-machine et en psychologie cognitive affirment
que la cohérence est une caractéristique essentielle d’un système convivial et efficace, ce
qui justifie les efforts qui ont été déployés pour la synchronisation entre les outils. Tous les
éléments d’interaction relatifs aux branches de simulation ont donc été regroupés dans
l’application de simulation afin de limiter les redondances inutiles et les possibilités de
confusion.
Pour les premières phases d’expérimentations en psychologie, la version « Desktop » sera
utilisée. Cependant, un des objectifs du projet IMAGE que nous avons brièvement
mentionné dans l’introduction est l’intégration des outils de visualisation dans un
environnement virtuel de type CAVE. Ceci n’a pas pu être réalisé pour la vue tactique,
principalement à cause d’un problème de rendu de textures avec Eye-Sys lorsque combiné
avec l’utilisation des technologies de « tracking » et de stéréoscopie. Toutefois, des
développements ont été réalisés à ce jour pour la partie stratégique du scénario avec des
vues 3D analytiques pleinement fonctionnelles, en vue d’une session d’expérimentations
avec utilisateurs dans le CAVE. La configuration utilisée inclut un TabletPC pour la
navigation avec Multichronia, l’explorateur de simulations, ainsi qu’une projection des
vues analytiques à l’intérieur du CAVE. Des résultats sont attendus suite aux diverses
sessions d’expérimentation pour les versions « Desktop » et « CAVE », qui donneront des
mesures permettant d’évaluer les bénéfices apportés au niveau de la compréhension.
La première version du projet IMAGE étant dédiée à une étude préliminaire sur
l’augmentation de la compréhension, les développements sont entièrement adaptés aux
expérimentations prévues à cet effet et ne sont pratiquement pas génériques. Ceci étant dit,
117
il ne s’agit que d’une première étape dans un processus de recherche d’envergure; une
deuxième version du projet IMAGE, conçue entièrement pour le CAVE et ses technologies
immersives, est en cours de développement. Contrairement à la version précédente, aucune
limitation reliée à des contraintes d’expérimentations ne sera présente, laissant toute la
place au potentiel des technologies disponibles et beaucoup plus de flexibilité pour le
design.
118
6 Bibliographie ACE Documentation 5.6.0. Septembre 2007.
http://www.dre.vanderbilt.edu/Doxygen/5.6/html/ace/index.html.
Aduna. AutoFocus. Août 2007. http://www.aduna-
software.com/technologies/autofocus/overview.view.
Alberts, David S., et Richard E. Hayes. «Understanding Command and Control.» DoD Command
and Control Research Program, 2006.
Atkinson, Richard, et Richard Shiffrin. «Human memory: A proposed system and its control
processes.» Dans The Psychology of Learning and Motivation: Advances in Research and Theory,
89-195. New York: Academic Press, 1968.
Bederson, Benjamin B. «Fisheye Menus.» Human-Computer Interaction Lab, 2000.
Bernier, François, et François Rioux. Convoy Scenario for Complexity Study. RDDC Valcartier,
2008.
CAIDA. Walrus - Graph Visualization Tool. Août 2007.
http://www.caida.org/tools/visualization/walrus/.
Christoffersen, Klaus, et David D. Woods. «How to Make Automated Systems Team Players.»
Institute for Ergonomics. Ohio State University, 2002.
Component Object Model. Avril 2009. http://fr.wikipedia.org/wiki/ActiveX.
Daassi, Chaouki. Techniques d’interaction avec un espace de données. Université Joseph Fourier
Grenoble I: Thèse de doctorat, 2003.
Doyle, James K., et David N. Ford. «Mental Models Concepts.» System Dynamics Review, Report
no. 6, 7 Janvier 1998.
Foresti, Stefano, James Agutter, Yarden Livnat, Shaun Moon, et Robert Erbacher. «Visual
Correlarion of Network Alerts.» IEEE Computer Graphics and Applications, Mars-Avril 2006: 48-
59.
Fractal:Edge. Fractal:Edge. Mai 2009. http://www.fractaledge.com/.
Funke, Joachim. «Microworlds based on linear equation systems: a new approach to complex
problem solving and experimental results.» Advances in psychology, vol. 101, 1993: 313-330.
Funke, Joachim. «Solving Complex Problems: Exploration and Control of Complex Systems.»
Dans Complex Problem Solving - Principles and Mechanisms, de Joachim Funke, 185-216.
Lawrence Erlbaum Associates, 1991.
119
Google. «Google Earth 5.0.» 29 Janvier 2009.
Hauser, Helwig, Florian Ledermann, et Helmut Doleisch. «Angular Brushing of Extended Parallel
Coordinates.» VRVis Research Center in Vienna, 2002.
Hitch, Graham J. «Applying cognitive psychology to user-interface design .» New York, NY, USA:
John Wiley & Sons, Inc., 1987. 119-134.
Hollnagel, Erik, et David W. Woods. «Cognitive systems engineering: new wine in new bottles.»
International Journal of Man-Machine Studies, Vol. 18, Issue 6, Juin 1983: 583-600.
Hübler, Alfred W. «The Simply Complex - Predicting complex systems with a holistic approach:
The throughput criterion.» Complexity, Vol. 10, Issue 3, 9 Février 2005: 11-16.
IDV, Inc. 2009. http://www.eye-sys.com/.
IDV, Inc. Eye-Sys SDK Programmers Manual. 2009.
IDV, Inc. Eye-Sys SDK Reference. 2009.
Jerding, Dean F., et John T. Stasko. «The Information Mural: A Technique for Displaying and
Navigating Large Information Spaces.» IEEE Transactions on Visualization and Computer
Graphics, Vol. 4, No. 3, Juillet-Septembre 1998: 257-271.
Jobidon, Marie-Ève. «Prise de décision en situation complexe.» Présentation du cours "Psychologie
cognitive appliquée" (PSY-66636). RDDC Toronto, 4 Février 2008.
Johnson, Addie, et Robert W. Proctor. Attention - Theory and Practice. SAGE, 2003.
Judelman, Greg. «Knowledge Visualization - Problems and Principles for Mapping the Knowledge
Space.» University of Lübeck: Mémoire de maîtrise, 2004.
Keim, Daniel A., et Daniela Oelke. «Literature Fingerprinting: A New Method for Visual Literary
Analysis.» University of Konstanz, 2007.
Kosara, Robert, Silvia Miksch, Helwig Hauser, Johann Schrammel, Verena Giller, et Manfred
Tscheligi. «Useful Properties of Semantic Depth of Field for Better F+C Visualization.» Joint
EUROGRAPHICS - IEEE TCVG Symposium on Visualization. The Eurographics Association,
2002.
Kullberg, Robin L. Dynamic Timelines - Visualizing Historical Information in Three Dimensions.
Massachusetts Institute of Technology: Mémoire de maîtrise, 1995.
Kurtz, Cynthia F., et David J. Snowden. «The new dynamics of strategy: Sense-making in a
complex and complicated world.» IBM Systems Journal, Vol. 42, no 3, 2003: 462-483.
«Laboratoire d'immersion virtuelle, RDDC Valcartier.» RDDC Valcartier, 2006.
Lafond, Daniel, Jean-François Gagnon, et Sébastien Tremblay. «IMAGE - An Interactive
Computer-Aided Cognition Capability for C4ISR Complexity Discovery.» Report on the Cognitive
Foundations and Experimental Design. École de psychologie, Université Laval, 2009.
120
«Levels of Understanding.» University of South Australia. Mai 2009.
www.unisa.edu.au/easdeanteaching/tlgrants/Levels%20of%20Understanding.doc.
Lizotte, Michel, Denis Poussart, François Bernier, Marielle Mokhtari, Éric Boivin, et Michel
Ducharme. «IMAGE: Simulation for Understanding Complex Situations and Increasing Future
Force Agility.» Proc. of Army Science Conference 2008. Orlando (FL), USA: SL 2008-468, 2008.
Miller, George A. «The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity
for Processing Information.» Psychological Review. 1956. 81-97.
Mokhtari, Marielle, Michel Ducharme, Éric Boivin, François Bernier, et Denis Poussart. IMAGE -
An Interactive Computer Aided Cognition Capability for C4ISR Complexity Discovery - A Human
Assistant to Understand Complex C4ISR Situations. Sommaire exécutif, RDDC Valcartier: SL
2007-479, Avril 2007.
MySQL. Avril 2009. http://fr.wikipedia.org/wiki/MySQL.
MySQL C++ API. 2009. http://mysqlcppapi.sourceforge.net/.
MySQL++. 2009. http://tangentsoft.net/mysql++/.
Netzpannung. The Semantic Map Interface. Août 2007.
http://netzspannung.org/about/tools/semantic-map/?lang=en.
Object Linking and Embedding. Avril 2009.
http://en.wikipedia.org/wiki/Object_Linking_and_Embedding.
Online ACE Tutorials. 2009. http://www.huihoo.org/ace_tao/ACE-5.2+TAO-
1.2/ACE_wrappers/docs/tutorials/online-tutorials.html.
Poussart, Denis. «Complexity : An Overview of its Nature, Manifestations, and Links to S&T
Convergence, with Comments on its Relevance to Canadian Defence.» Rapport de contrat, RDDC
Valcartier, 2006.
Rao, Ramana, et Stuart K. Card. «The Table Lens: Merging Graphical and Symbolic
Representations in an Interactive Focus+Context Visualization for Tabular Information.» Xerox
Palo Alto Research Center, 1994.
Rioux, François. «Conception et mise en oeuvre de Multichronia, un cadre conceptuel de simulation
visuelle interactive.» Thèse de doctorat, Département de génie électrique et de génie informatique,
Université Laval, 2009.
Rioux, François, François Bernier, et Denis Laurendeau. «Multichronia – a Generic Parameter,
Simulation, Data, and Visual Space Exploration Framework.» Interservice/Industry Training,
Simulation, and Education Conference (I/ITSEC). 2008.
Rouse, William B., et Nancy M. Morris. «Understanding and Enhancing User Acceptance of
Computer Technology.» Systems, Man and Cybernetics, IEEE Transactions, Novembre 1986: 965-
973.
121
Schmidt, Douglas C. The ADAPTATIVE Communication Environment. 2009.
http://www.cs.wustl.edu/~schmidt/ACE.html.
Shanteau, James. «Competence in experts: The role of task characteristics.» Organizational
Behavior and Human Decision Processes, Volume 53, Issue 2, Novembre 1992: 252-266.
Shneiderman, Ben. Designing the User Interface : Strategies for Effective Human-Computer
Interaction. 3e édition, Addison Wesley, 1998.
Sun Microsystems. MySQL. 2009. http://www.mysql.com/.
Tableau Software. Tableau Software - Visual Analysis and Data Visualization. 2009.
http://www.tableausoftware.com/.
ThemeRiver. ThemeRiver. Mai 2009. http://infoviz.pnl.gov/research_themeriver.stm.
Tremblay, Sébastien, Daniel Lafond, et Jean-François Gagnon. «HCI principles for Visualisation
Simulation and Representation.» Présentation : Workshop 5 on Experimentation I. Université
Laval, 26 Mars 2008.
TU/e. University of Technology Eindhoven. Mai 2009.
http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview/.
Tufte, Edward R. Envisioning Information. Chesire, Connecticut: Graphics Press, 1990.
Tversky, Barbara. «What Makes Visualizations Effective?» Stanford University:
http://visual.nlm.nih.gov/evc/meetings/vrc2004/position_papers/tversky.pdf, 2009.
van Wijk, Jarke J., et Edward R. van Selow. «Cluster and Calendar based Visualization of Time
Series Data.» IEEE Symposium on Information Visualization. San Francisco, 1999.
Ware, Colin. «Information Visualization: Perception for Design.» San Diego, CA: Academic, 2000.
Wickens, Christopher D., et Justin G. Hollands. Engineering Psychology and Human Performance.
Prentice Hall, 2000.
Woods, David, et Emilie Roth. «Cognitive Engineering: Human Problem Solving with Tools.»
Human Factors 30. 1988. 415-430.
