Visualisation de Graphes: Master Informatique Universit e de Montpellier II 2007-2008

Master Informatique
Université de Montpellier II
2007-2008
Rapport de Projet
Visualisation de Graphes
Groupe 10 :
Edouard CUNIBIL
Emilie GENNARI
Benoit LANGE
Vincent MARTINEZ
Encadrants : Anne-Elisabeth BAERT et Vincent BOUDET

Visualisation de Graphes - Rapport de projet
Remerciements
Lors d’une réunion avec nos tuteurs (Anne-Elisabeth BAERT et Vincent BOUDET), nous
avons appris leur dégout certain pour la section d’un rapport concernant les remerciements. Nous
en avons donc déduit qu’ils ne la liraient certainement pas et donc nous avons décidé de ne pas
les remercier ! Par ailleurs, nous ne remercions pas non plus plus les personnes qui nous ont
aidés directement (Guilhem BARLOY par exemple) ou indirectement (tous les auteurs cités dans
la Bibliographie page 49 ou dans la Webographie page 50). Notre ingratitude sans bornes touche
également les quelques personnes, dont nous ne citerons bien évidemment pas les noms, ayant testé
notre application, nous ayant permis de la corriger et de l’améliorer grandement. Comble de l’égoı̈sme,
nous ne remercions pas non plus nos parents sans qui rien de tout ceci n’aurait été possible, ni
même nos enseignants qui, depuis l’école maternelle, ne nous ont inculqué que des notions qui ont
toutes eu leur utilité dans ce projet.
Toutefois, nous aimerions dire un grand merci aux personnes qui liront ce rapport et à la
société Druide informatique inc. Aux premiers parce qu’il y a de fortes chances que vous soyez l’une
des personnes sus-citées ; aux seconds parce que sans vous et votre logiciel (Antidote) les premiers
n’auraient surement pas été bien nombreux.
3 Remerciements
Avant propos
Le cursus de Master Informatique au sein de l’Université de Montpellier 2 donne une part

importante à l’apprentissage pratique du travail d’un développeur au sein d’une entreprise ou d’un
laboratoire de recherche. Dans cette optique, il est demandé aux étudiants de participer à des Travaux
´
d’Études et de Recherche en groupes encadrés. Chaque groupe dispose d’un sujet constituant le projet
qu’il devra réaliser de l’analyse aux tests en un temps donné.
Le projet décrit dans ce document a été amorcé par le désir de certaines personnes d’avoir
dans leur logithèque une application leur permettant de créer et de manipuler des graphes. Ces
personnes étant proches du monde de la recherche fondamentale et de l’enseignement ont déjà pu
essayer les logiciels existants, mais n’ont pas été convaincues de leur adéquation à leurs besoins. Ils
ont donc rassemblé ces besoins pour en faire un sujet de Travaux d’Études et de Recherche.
Avant propos 4
Table des matières
Page de garde 1
Avant propos 3
Table des matières 6
Introduction 9
2 Analyse du projet 11
2.1 Le sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Approfondissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Choix des outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1.2 Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1.3 Contrôleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Notre implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Patrons de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Monteur et Fabrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 État . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Développement 19
3.1 Algorithmes de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Plus Court Chemin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Diamètre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Génération de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Anneau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Table des matières 6

3.2.2 Complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.3 Biparti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 Régulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.5 Aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Fenêtres Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1.1 La classe Fenêtre : Fenêtre Principale . . . . . . . . . . . . . . . . . . 26
3.3.1.2 Le menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1.3 La barre d’outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1.4 La classe OngletsVisualisations : vue des graphes et de leurs Outils . 28
3.3.1.5 La classe PanneauInformations : vue des informations des graphes . . 30
3.3.2 Éléments Graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2.1 La classe NœudGraphique . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2.2 La classe AreteGraphique . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2.3 La classe GrapheGraphique . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.3 Les boites de dialogues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.3.1 Prédéfinies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.3.2 Complexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.4 Outils supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.4.1 Gestion du undo /redo . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Sauvegarde et chargement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Exportation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Procédure de tests 41
4.1 Tests alpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Tests bêta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Tests d’ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conclusion 43
Annexes 46
4.4 Diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Webographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Résumé 52
7 Table des matières

Introduction
Certaines personnes ont la volonté ou la nécessité de visualiser des structures de données

de type Graphe. Ces données ont pour la plupart du temps des structures complexes composées de
sommets et d’arêtes, ce qui les rend souvent illisibles ou bien très complexes à exploiter en fonction de
l’importance du nombre de sommets ou d’arêtes qu’ils contiennent. Ces structures sont très utilisées,
car elles possèdent des caractéristiques sous-jacentes qui leur sont propres, telles que le diamètre, le
plus court chemin ou un arbre couvrant partant d’un sommet. Ces caractéristiques sont importantes
pour les calculs théoriques et les résultats découlant de ces Graphes.
Les outils existants ne sont pas non plus toujours adaptés à ce dont les utilisateurs ont besoin,
à cause de leur interface ou de leurs outils de calcul. Un autre défaut principal de ces outils est leur
prix trop élevé pour que des utilisateurs autres que des entreprises ou des laboratoires de recherche
ne puissent se les procurer.
L’objectif de ce projet est donc de concevoir une application de création et de visualisation
de graphes simple et intuitive à destination d’un public universitaire.
9 Introduction
2 Analyse du projet
Dans tout projet professionnel bien mené, l’analyse et la conception doivent au moins consom-
mer autant de ressources que le développement. Nous avons donc réalisé cette partie en un peu plus
d’un tiers du temps total que nous avions pour terminer le projet. Ce chapitre vous rappelle le sujet
de ce projet et dévoile les points les plus intéressants de son analyse.
2.1 Le sujet
2.1.1 Définition
Titre
Visualisation de graphes
Résumé
Le but du TER est de développer une application de visualisation 2D de graphes et de leurs
propriétés.
Parcours
CASAR, DIWEB, GL.
Modules connexes
– Conception et développement d’IHM
– Réseaux
– Algo
Détail
Pour étudier le comportement de systèmes distribués, comme les réseaux ad hoc par exemple,
une approche consiste à modéliser ces réseaux par des graphes et à utiliser des outils de visualisation
pour voir le comportement de ces réseaux lorsqu’on leur applique certains algorithmes. Le but du
TER sera de développer une application de visualisation 2D de graphes et de leurs propriétés. Cette
application prendra en entrée des topologies de graphes types ou des graphes ayant des propriétés
particulières modélisant des réseaux, le tout dans une interface conviviale. Il faudra que cette ap-
plication permette la visualisation d’algorithmes de diffusion dans le graphe ainsi généré. De plus,
11 Analyse du projet
cette application devra pouvoir exporter, dans des formats de type PDF par exemple, les résultats
graphiques obtenus.
2.1.2 Approfondissement
Nous avons dû apporter beaucoup de légères modifications à notre logiciel, afin qu’il soit
plus fonctionnel et réponde au mieux aux attentes des tuteurs.
Nous avons dû tout d’abord penser à la manière d’ajouter une méthode de coloration per-
sonnalisée des éléments du graphe, qui même si elle n’est pas essentielle, permet à l’utilisateur de
colorer, s’il le souhaite, des parties importantes du graphe.
Une autre fonctionnalité qui nous a été demandée par les tuteurs est la possibilité de voir les
résultats des algorithmes directement sur le graphe. Au départ, nous pensions afficher les résultats de
ces algorithmes directement dans le panneau des informations du graphe. Donc, nous avons modifié
notre façon d’afficher les algorithmes et avons opté pour une coloration bien précise des nœuds et
arêtes concernés par l’algorithme sélectionné.
Au niveau du développement en lui-même, nous avons dû modifier notre première idée de
l’architecture de base de notre logiciel et avons préféré l’option du pattern MVC (Modèle Vue Contrô-
leur) qui va nous permettre de diviser soigneusement les différentes parties de l’application. Ainsi,
le modèle sera pour nous le graphe en lui-même. La vue nous permettra d’afficher directement le
graphe graphique à l’aide du graphe contenu dans le modèle et le contrôleur nous permettra de faire
la balance entre les deux parties citées précédemment. C’est-à-dire que lorsque l’utilisateur effectuera
une modification sur le graphe affiché à l’écran, celle-ci sera répercutée au niveau du contrôleur, afin
de mettre à jour le modèle qui servira surtout pour le calcul d’algorithmes. Ainsi, autant le graphe
graphique que le graphe contenu dans le modèle seront toujours dans un état similaire.
Concernant la génération de graphes, nous avons dû penser à un nouveau type de génération
différent des générations aléatoires ou en spécifiant le nombre de sommets et d’arêtes. Ces générations
sont les générations pour des graphes dits « de voisinage ». Elles sont créées en spécifiant le nombre
d’arêtes contenues dans le graphe ainsi que la distance maximale de création d’une arête. C’est-à-dire
qu’une arête ne peut être créée entre deux nœuds que si la distance entre ces derniers est inférieure
ou égale à la distance spécifiée avant la génération.
Enfin, pour l’enregistrement des graphes, pour une future réutilisation ou modification, nous
avons opté pour le format GraphML. Ainsi, le graphe est stocké sous forme de fichier XML et ce fichier
contient tout d’abord tous les nœuds du graphe, avec leurs attributs, tels que leurs coordonnées sur x
et sur y, et il contient ensuite les arêtes. Chaque arête, dans un fichier au format GraphML, contient
les numéros des deux nœuds étant ses extrémités ainsi que d’autres caractéristiques spécifiques comme
le poids de l’arête par exemple.
Analyse du projet 12 2.1 Le sujet

2.2 Choix des outils de développement

Pour la création de l’application, nous avons fait le choix d’utiliser Java, aussi bien pour
l’implémentation des algorithmes que pour l’interface graphique. Ce choix est dû principalement
au fait que Java est un langage purement objet, ce qui nous a facilité la tâche pour la création
de classes. Car le découpage du logiciel en différents modules est indispensable, dès lors que le
projet devient conséquent. De plus, un autre avantage du développement sous Java, est la possibilité
d’utiliser l’environnement Éclipse pour développer. Cet environnement nous permet une compilation
automatique et ainsi d’éviter les erreurs successives et parfois difficiles à trouver.
Un autre point fort de Java est la facilité avec laquelle nous pouvons créer des interfaces
graphiques. C’est-à-dire que chaque élément graphique est bien défini dans sa propre classe et contient
des méthodes qui lui sont propres. Ainsi, leur utilisation est simple et efficace. De plus, nous pouvons
ajouter des écouteurs d’événements, de type action, clavier ou souris, à n’importe quel élément. Par
la suite, ces écouteurs réagissent et peuvent effectuer des opérations sur d’autres composants ou
bien sur le composant lui-même. Enfin, l’un des gros avantages de java, qui peut également être un
inconvénient si on l’utilise mal, est le fait qu’il ne fonctionne uniquement que sous forme de pointeurs.
Donc, il n’y a pas de risque de mélanger plusieurs types d’instances par exemple, contrairement au
langage C++, qui fonctionne quant à lui à l’aide de pointeurs ou directement dans la mémoire.
2.3 Modèle MVC

Le Modèle-Vue-Controlleur (aussi appelé 3-tier) est l’un des plus célèbres modèles du dé-
veloppement logiciel. Il permet en effet d’organiser chaque partie active d’un logiciel afin de rendre
la maintenance de l’ensemble plus aisée. Ainsi, une application graphique développée en le suivant
pourra voir son interface évoluer indépendamment de ses autres parties. C’est donc sans surprise,
devant développer notre projet à plusieurs, que nous avons choisi ce modèle qui nous permettrait de
ne pas trop risquer de conflit dans notre code.
2.3.1 Architecture générale

Le modèle MVC est divisé en trois couches ayant des interactions très limitées, le Modèle,
la Vue et le Controlleur (voir Figure 2.1).
2.3.1.1 Modèle
Le Modèle sert d’interface pour l’accès aux données du logiciel. Ainsi, si celui-ci requiert
des informations issues d’une base de données, extraites depuis un fichier ou même depuis un flux
quelconque. C’est au sein de cette partie que le format des données est garanti et contrôlé autant au
moment de la lecture qu’au moment de l’écriture.
L’architecture de cette partie est très importante, car c’est souvent à ce niveau que se si-
tuent les manipulations les plus coûteuses en ressources. Dans le cadre de grosses applications, il est
2.2 Choix des outils 13 Analyse du projet

Fig. 2.1 – Schéma du modèle MVC
souhaitable de pratiquer la mise en cache de certaines informations pour éviter de perdre trop de
temps dans leur recherche.
2.3.1.2 Vue
La Vue est l’interface entre l’utilisateur et le logiciel. Elle comprend tout le système de
fenêtrage, de boites de dialogues, de formulaires, de boutons... Toutefois, la Vue se contente d’afficher
les éléments, elle ne doit donc en aucun cas en gérer les interactions comme les clics.
La Vue est un élément important du logiciel, car c’est elle qui va rendre le logiciel attrayant et
agréable à utiliser ou pas. L’action d’un graphiste ou d’un ergonome dans le cycle de développement
ne concerne que la Vue.
2.3.1.3 Contrôleur
Le Contrôleur est le ciment de l’application. Il est chargé d’interpréter les requêtes de l’utili-
sateur et de les répercuter sur la Vue et le Modèle. Si un utilisateur clique sur un bouton de l’interface,
la Vue va prévenir le contrôleur qui va réagir en conséquence.
Une application peut contenir plusieurs Contrôleurs gérant chacun une partie des fonction-
nalités. Dans ce cas, il y aura généralement un Contrôleur principal qui se chargera de transmettre
les requêtes de l’utilisateur au bon Contrôleur secondaire (aussi appelé Helper).
2.3.2 Notre implémentation

Pour des raisons de choix du langage, de choix d’organisation et de manque de temps global,
nous avons décidé de suivre une variante du modèle MVC, le modèle M-VC (voir Figure 2.2). Celui-ci
correspond à l’implémentation faı̂te par Java Swing, librairie que nous utilisons pour créer l’interface
graphique du logiciel. Dans cette variante, la Vue et le Contrôleur sont plus liés que dans le modèle
standard. Ainsi, il est possible de permettre à la Vue de procéder à de légères opérations qui auraient
Analyse du projet 14 2.3 Modèle MVC

normalement été transmises au Contrôleur. Le Contrôleur quant à lui n’est plus chargé de s’occuper
que des opérations lourdes.
Fig. 2.2 – Schéma de la variante M-VC modèle MVC
2.4 Patrons de conception

La plupart des problèmes conceptuels qui se posent lors de l’analyse d’un projet logiciel sont
des problèmes récurrents qui ont déjà trouvé une réponse générique applicable dans presque tous
les cas. Ces réponses génériques sont appelées Patrons de Conception (Design Patterns en anglais).
Cette section vous présente ceux que nous avons utilisés ou que nous aurions souhaité utiliser.
2.4.1 Le patron « Singleton »

Un des patrons de conception les plus célèbres est le Singleton. Il répond au problème récur-
rent de la création d’une classe ne pouvant être instanciée qu’une unique fois dans toute l’application.
Cette problématique peut concerner autant un accès à une base de données que l’on souhaiterait être
unique, que la création de la fenêtre principale du logiciel.
Le fait de déclarer le constructeur comme n’étant pas public empêche l’instanciation de la
classe. Or, la méthode statique getInstance, faisant partie de la classe, peut accéder au constructeur.
Elle peut donc créer une instance de la classe qu’elle gardera en mémoire dans un attribut statique de
la classe. Ainsi, la classe s’auto instanciera une unique fois puisque la méthode statique getInstance
retournera l’instance sauvegardée dans l’attribut instance. Vous trouverez un court exemple de code
source Java illustrant l’implémentation de ce patron de conception à la page 16.
Ce patron nous est utile pour la définition de notre Application, de notre Contrôleur principal
ainsi que de la fenêtre principale.
2.4 Patrons de conception 15 Analyse du projet


1 class monSingleton {
2 protected static monSingleton _instance = null;
3
4 /* Constructeur non public */

5 protected monSingleton() {
6 }
7
8 /* Accès à l’instance */
9 public static monSingleton getInstance() {
10 if (monSingleton._instance == null) {
11 monSingleton._instance = new monSingleton();
12 }
13 return monSingleton._instance;
14 }
15 }

2.4.2 Les patrons « Monteur » et « Fabrique »

Ces deux patrons, très proche dans le concept, car ce sont deux patrons de conception
créationnels et que tous deux permettent de créer un ou plusieurs objets sans en connaı̂tre la définition
complète.
Fig. 2.3 – Schéma du design pattern Fabrique
Le patron Fabrique (i.e. Factory) permet d’abstraire l’instanciation d’une ou de plusieurs

classes. De cette manière, on rend l’évolution de l’application plus aisée. En effet, si jamais cette
instanciation venait à changer ou si la classe devait être modifiée par spécialisation alors il suffirait
de modifier la méthode associée au sein de la Factory pour que tout fonctionne sans problème. La
figure 2.3 page 16 illustre le fonctionnement de ce patron.
Le patron Monteur (i.e. Builder ) quant à lui permet de manipuler des objets complexes
de type semblable sans avoir à se préoccuper de la manière dont ils sont construits intérieurement.
Analyse du projet 16 2.4 Patrons de conception

Fig. 2.4 – Schéma du design pattern Monteur
Cela permet de créer facilement une nouvelle classe ayant un fonctionnement interne différent afin
d’améliorer les capacités du logiciel. La figure 2.4 page 17 illustre le fonctionnement de ce patron.
Notre application utilise le patron « Fabrique » pour la gestion des contrôleurs des graphes
ouverts par le contrôleur de l’application ainsi que pour la classe Graphe qui correspond à la structure
de données des graphes. Chaque contrôleur de graphe quant à lui implémente le patron « Monteur »,
chaque contrôleur se parant d’un objet Graphe (structure de données) et d’un objet GrapheGraphique
(vue).
2.4.3 Le patron « État »

Ce patron de conception est utilisé pour modéliser des objets ayant un comportement en
fonction de leur état. Il peut avantageusement remplacer les structures de contrôle « switch » ou «
if then else » en déplaçant les actions de l’objet concerné au sein même de ses états. La figure 2.5
page 17 illustre le fonctionnement de ce patron.
Fig. 2.5 – Schéma du design pattern État
Ce patron a été utilisé au sein de notre projet pour gérer les événements gravitant autour
2.4 Patrons de conception 17 Analyse du projet

de notre classe GrapheGraphique, chargée de l’affichage d’un graphe.
2.4.4 Le patron « Strategie »

L’objectif de ce patron de conception est de permettre l’externalisation et l’interchangeabilité
des algorithmes de traitement des données. En effet, chaque algorithme est encapsulé dans un objet
propre qui implémente une interface définie. Ainsi, l’objet ayant besoin d’appliquer un algorithme
peut instancier n’importe lequel des objets implémentant l’interface et en exécuter une méthode. La
figure 2.6 page 18 illustre le fonctionnement de ce patron.
Fig. 2.6 – Schéma du design pattern Stratégie
Notre projet implémente ce patron pour la modélisation des divers algorithmes de manipula-
tion des graphes, mais aussi, de manière plus subtile, au sein même de notre structure de données de
graphes. De cette manière, il est possible d’ajouter des algorithmes ou de nouveaux types de graphes
aisément.
Analyse du projet 18 2.4 Patrons de conception

3 Développement
3.1 Algorithmes de calculs appliqués aux graphes

3.1.1 Algorithme du « Plus court Chemin »
L’algorithme du plus court chemin est un des algorithmes que nous utilisons le plus. Ainsi,
celui-ci se devait d’être efficace en toute circonstance. Pour ce faire, nous n’avons pas utilisé Dijkstra,
car celui-ci limite les graphes aux arêtes positives. L’algorithme de Ford - Bellman nous a semblé le
mieux convenir pour ce genre de problématique.
booléen Bellman Ford(G, s):

1 // les poids de tous les sommets sont mis à +infini
2 // le poids du sommet initial à 0
3 initialisation(G, s)
4
5 pour i=1 jusqu’à Nombre de sommets -1 faire

6 | pour chaque arc (u, v) du graphe faire
7 | | paux := poids(u) + poids(arc(u, v));
8 | | si paux < poids(v) alors
9 | | | pred(v) := u;
10 | | | poids(v) := paux;
11 pour chaque arc (u, v) du graphe faire
12 | si poids(u) + poids(arc(u, v)) <poids(v) alors
13 | | retourner faux
14 retourner vrai

Cet algorithme est en O(n3 ) ce qui signifie que l’algorithme est très lent.
On sélectionne cet algorithme dans le menu (voir Figure 3.1 située page 20) puis on sélec-
tionne deux points sur le graphe et le résultat s’affiche en jaune.
19 Développement
Fig. 3.1 – Cheminement dans l’interface pour l’utilisation de l’algorithme du Plus Court Chemin
Développement 20 3.1 Algorithmes de calcul

3.1.2 Algorithme « Diamètre »

Le diamètre consiste à tester tous les plus courts chemins du graphe et afficher le plus long
de tous les plus courts chemins. Il utilise ainsi l’algorithme du plus court chemin vu au dessus.
Fig. 3.2 – Cheminement dans l’interface pour l’utilisation de l’algorithme du Diamètre
On constate sur la Figure 3.2 située page 21) que le parcours de tous les points du graphe
est bien le plus long de tous les plus courts chemins. Pour détecter cela, il analyse séquentiellement
la distance entre les points.
3.2 Génération de graphes

Pour ce projet, nous avons implémenté toute une série de générateurs de graphe. Ainsi, nous
retrouvons des graphes particuliers comme le graphe en anneau, le graphe complet, le graphe biparti
et le graphe régulier. Il y a aussi trois modes aléatoires.
3.2.1 Anneau
Le graphe en anneau est un graphe simple. Il s’agit d’un anneau dont chaque nœud a un
degré de deux. Pour son affichage, nous avons utilisé des calculs basés sur le cercle trigonométrique
afin d’obtenir un cercle.
Voir l’exemple sur la Figure 3.3 située page 22
3.2 Génération de graphes 21 Développement

Fig. 3.3 – Génération d’un graphe en Anneau
3.2.2 Complet
Le graphe complet est comme son nom l’indique un graphe dont chaque sommet relie chaque
autre sommet. Pour sont dessin aussi, nous utilisons le cercle trigonométrique.
Fig. 3.4 – Génération d’un graphe Complet
Développement 22 3.2 Génération de graphes

3.2.3 Biparti
Le graphe biparti est un graphe qui est divisible distinctement en deux part. Ainsi, nous
affichons les deux parties grâce au cercle trigonométrique aussi. Les arrêtes quand a elles sont tirées
aléatoirement entre les sommets, l’utilisateur décide du nombre de sommets et du nombre d’arêtes
au total.
Fig. 3.5 – Génération d’un graphe Biparti
3.2.4 Régulier
Le graphe régulier est un des graphes les plus difficiles à générer. Il demande de vérifier
le nombre d’arêtes pour chaque sommet. On choisit le nombre de sommets et le nombre d’arêtes
sortantes, et le graphe se génère. Le seul problème réside dans le fait que la génération peut durer
très longtemps.
3.2.5 Aléatoire
Les graphes aléatoires sont quant à eux de trois sortes différentes. Pour le placement de
ceux-ci, les points sont mis au hasard sur toute la zone d’affichage.
Il y a le graphe aléatoire qui obtient un nombre aléatoire de nœuds et d’arrêtes. Voir l’exemple
sur la Figure 3.7 située page 24
Ensuite, il y a le graphe aléatoire où l’on choisit le nombre de sommet et d’arêtes.

Fig. 3.6 – Génération d’un graphe Régulier
Fig. 3.7 – Génération d’un graphe totalement Aléatoire
Et pour finir le graphe dit social où l’on choisit le nombre de sommets et la distance minimale
entre les sommets. On génère ainsi des liens lorsque les nœuds sont à une distance inférieure à celle
définie. Voir l’exemple sur la Figure 3.8 située page 25
Développement 24 3.2 Génération de graphes

Fig. 3.8 – Génération d’un graphe dit « Social »

3.3 Interface
3.3.1 Fenêtres Principales
3.3.1.1 La classe Fenêtre : Fenêtre Principale
Fig. 3.9 – Illustration de la Fenêtre Principale
Cette classe se divise en trois parties distinctes.

Elle contient tout d’abord un menu permettant d’effectuer des actions précises sur le graphe
visualisé. Ces actions sont de différents types. Tout d’abord les actions de base, telles que « nouveau
», « enregistrer » ou bien « exporter » par exemple, qui permettent à l’utilisateur de garder une
trace du graphe créé ou bien d’en créer un nouveau. Il y a également les actions agissant directement
sur les graphes telles que la génération de graphes, la visualisation d’algorithmes ou la modification
de pondérations de certaines ou de toutes les arêtes. Enfin, il y a également des fonctions pouvant
modifier l’affichage du graphe, telles que l’affichage ou non des étiquettes. Il en est de même pour
l’affichage des pondérations.
La seconde partie de cette classe est la barre d’outils. Elle reprend certaines fonctions conte-
nues dans le menu et permet un accès rapide et efficace à ces dernières.
La dernière et la plus importante partie de cette classe est la barre d’onglets, qui permet
l’édition de plusieurs graphes sur la même fenêtre. Chaque onglet est en lui-même une structure que
nous décrirons par la suite. Ces onglets s’ajoutent et se ferment facilement à l’aide des boutons «
nouveau » et « fermer » de la barre d’outils.
Développement 26 3.3 Interface

3.3.1.2 Le menu
La barre de menu de notre application comporte dans un premier temps , les actions «
basiques » que l’on peut retrouver dans un éditeur de texte par exemple .
En effet dans le menu Fichier nous retrouvons les items « nouveau », « ouvrir », « enregistrer
», « exporter », ou bien « quitter ». Les actions qui leur sont associées sont essentiellement gérées
par les contrôleurs de notre logiciel. Lors de la sélection de l’item « nouveau » par exemple, nous
écrivons :

1 if (e.getSource() == nouveau) {
2 try {
3 ApplicationControlleur.getInstance().nouveau_graphe();
4 } catch (ControlleurException e1) {
5 e1.printStackTrace();
6 }
7 }

La barre de menu contient également une partie Édition contenant les actions undo
/redo(défaire , refaire) permettant à l’utilisateur de revenir sur n’importe quelle action qu’il vient
d’effectuer. Les actions correspondant à ces deux items sont gérées dans des classes spécifiques que
nous expliquerons et détaillerons par la suite.
Nous avons également un menu Affichage des items permettant de modifier l’apparence de
notre graphe actif en affichant ou non la pondération sur les arêtes du graphe ou bien les étiquettes
sur les sommets. Ces items sont sous forme de case à cocher afin de préserver la sélection de l’utili-
sateur quelque soit le graphe qu’il édite. Pour cela, lorsque l’un (ou les deux) item est sélectionné,
nous actualisons, pour chaque graphe présent dans les onglets, la valeur d’un booléen d’affichage
permettant d’afficher, ou non, les étiquettes ou les pondérations. Nous expliquerons, plus en détail,
le fonctionnement de cet affichage dans une section ultérieure.
Nous en venons maintenant au menu Graphes qui est le plus intéressant, c’est ici que nous
pouvons générer les différents types de graphes détaillés dans la partie 4.3, ou bien encore appliquer
les algorithmes cités plus haut comme le plus court chemin et le diamètre. Il est également possible
dans ce même menu de configurer la pondération des arêtes de manière totalement libre. L’utilisateur
peut choisir de pondérer toutes les arêtes d’un même poids qu’il doit au préalable saisir, ou bien alors
de générer des poids aléatoires compris entre deux extrémités (minimum et maximum) dont il saisira
également des valeurs au préalable. Parlons plus en détail de la génération des graphes. Dans le cas
de la génération totalement aléatoire, l’application ne demande rien à l’utilisateur, en effet, lorsque
l’utilisateur sélectionne ce type de génération, une fonction Random se charge d’attribuer un nombre
aléatoire d’arêtes (représenté par un entier aléatoire k) et de nœuds (représenté par un entier aléatoire
j) et fait ensuite appel au contrôleur de cette manière :

1 ApplicationControlleur.getInstance().get_graphe_actif().
generationAleatoire(k, j);

3.3 Interface 27 Développement

Ainsi, après cet appel, le graphe est automatiquement créé et affiché dans un nouvel onglet.
Le sous-menu de génération aléatoire possède également deux items permettant d’effectuer
une génération semi-aléatoire, c’est-à-dire que l’utilisateur va devoir rentrer un nombre minimum
d’informations afin que la génération soit possible. Le premier item concerne la génération aléatoire.
Après avoir spécifié le nombre de nœuds et d’arêtes que devra contenir le nouveau graphe, le graphe
se génèrera automatiquement dans une nouvelle fenêtre moyennant bien sûr un appel préalable au
contrôleur.
Le second item de génération semi-automatique est celui de la génération par distance. Cette
génération s’effectue après que l’utilisateur ait saisi le nombre de nœuds souhaité, ainsi que la distance
minimale, séparant deux nœuds, pour créer une arête. C’est-à-dire que ce type de génération crée
des graphes dits « sociaux » ou seuls les nœuds les plus proches sont reliés.
Nous pouvons également générer des graphes particuliers tels que les graphes en « anneau
», les graphes « bi parti », les graphes « complets » et les graphes « réguliers ». Pour les graphes en
« anneau », ainsi que les « complets », l’utilisateur n’aura qu’à saisir le nombre de nœuds souhaité
pour le graphe créé. Tandis que pour la génération de graphes « bi parti », ainsi que de graphes «
réguliers », l’utilisateur devra saisir le nombre de nœuds et d’arêtes souhaités.
Toutes ces générations font appel au contrôleur du graphe qui créera un nouveau graphe
dans un nouvel onglet.
Parlons maintenant des algorithmes. Pour le diamètre aussi bien que pour le plus court
chemin , nous faisons appel aux fonctions Diamètre() et PlusCourtChemin() du Controller.
3.3.1.3 La barre d’outils

Dans la barre d’outils, nous retrouvons les actions importantes présentes dans le menu, telles
que la création ou la fermeture d’un onglet. On y trouve également les actions undo /redo que l’on
peut être amené à utiliser assez fréquemment. Ce sont des raccourcis pour l’utilisateur, lui évitant
ainsi de parcourir les menus pour effectuer des actions courantes de l’application.
Cette barre d’outils est commune à tous les graphes, donc à chaque changement d’onglet, les
actions exercées sur cette dernière ne concerneront que le graphe actif.
3.3.1.4 La classe OngletsVisualisations : vue des graphes et de

leurs Outils
3.3.1.4.1 Structure de base
Pour les onglets, nous avons opté pour une encapsulation de plusieurs parties d’édition.
Donc, chaque onglet est composé d’une barre d’outils permettant l’édition d’un graphe, d’un graphe
graphique permettant la visualisation du graphe à proprement dit, d’un panneau d’informations
affichant les informations complémentaires concernant le graphe affiché et enfin un onglet possède
également une barre de statut affichant l’état du graphe et les indications d’utilisation.

Fig. 3.10 – Vue de la barre d’onglets et de tous ses composants.
3.3.1.4.2 La classe EditionGraphe : actions sur les graphes

Cette classe hérite de JToolBar, c’est la barre d’outils qui gère les diverses possibilités de
modifications ou d’actions sur les graphes générés ou créés manuellement.
À chaque clic sur l’un des boutons de la barre d’outils, la barre de statut se met automati-
quement à jour, permettant ainsi à l’utilisateur de vérifier qu’il n’a pas fait une fausse manipulation
par exemple. De plus, cela a pour effet de placer l’état courant du graphe dans une position correcte
et donc de rendre la modification sélectionnée possible.
Cette barre d’outils est composée de JToggleButton qui sont des boutons à deux états et
permettent d’effectuer un bon feedback vis-à-vis de l’utilisateur, en montrant bien quelle action est
sélectionnée, puisque le bouton reste enfoncé lors de la sélection de la commande. Ceci est un plus
visuel, en complément de la barre de statut. Seul le bouton de suppression n’est qu’un bouton simple
(JButton), vu que l’action de suppression ne concerne uniquement qu’une sélection d’éléments dans
notre cas.
Fig. 3.11 – Vue de la barre d’outils d’édition du graphe

3.3.1.4.3 L’affichage du graphe

Chaque onglet contient également un graphe graphique à afficher. C’est le centre nerveux de
chaque onglet. L’affichage et le dessin du graphique étant complexe, nous vous présentons plus bas
une partie très détaillée concernant l’affichage des éléments graphiques tels que les nœuds, les arêtes
ou les graphes.
3.3.1.5 La classe PanneauInformations : vue des informations

des graphes
Le panneau de vue des informations du graphe permet de fournir à l’utilisateur une vision
chiffrée du graphe affiché à l’écran. Il peut fournir plus d’informations lors de générations particulières
de graphes ou bien lors de l’exécution d’un algorithme.
3.3.1.5.1 Informations communes à tous les graphes

La principale utilité du panneau d’informations est la possibilité pour l’utilisateur de voir
en direct l’évolution du nombre de nœuds et d’arêtes au cours de l’édition et de la modification du
graphe. La mise à jour se fait de manière automatique, et ce, pour toutes les fonctionnalités modifiant
la structure du graphe, telles que l’ajout, la suppression ou bien les méthodes pour défaire ou refaire
une action.
3.3.1.5.2 Informations supplémentaires et ajout

Selon le type de graphe affiché ou le type de génération effectuée, nous pouvons ajouter
d’autres informations directement visibles par l’utilisateur. Par exemple lors de la génération de
graphes « sociaux » on affiche l’information supplémentaire nommée « distance pour arête » et qui
indique la distance minimale entrée par l’utilisateur pour permettre la création d’une arête.
Nous pouvons également ajouter facilement un élément d’information au panneau, à l’aide
de la méthode d’ajout qui prend en paramètre le nom de la nouvelle information, ainsi que sa valeur.
Comme ceci, nous offrons une plus grande flexibilité à notre panneau d’informations.
À noter également que le panneau d’informations peut être masqué par l’utilisateur pour un
plus grand confort d’utilisation.

3.3.2 Éléments Graphiques
3.3.2.1 La classe NœudGraphique

C’est grâce à cette classe que nous définissons et affichons les nœuds sur le graphe graphique.
3.3.2.1.1 Caractéristiques de base d’un nœud graphique

Chaque nœud graphique hérite de la classe Ellipse2D.Double. Cette classe permet de dessiner
facilement des ellipses, et donc dans le cas qui nous concerne, des cercles.
Les caractéristiques d’un nœud graphique, sont des coordonnées x et y qui permettent un
placement efficace sur le graphe et une étiquette modifiable afin de repérer le nœud dans un grand
graphe. À cette étiquette est également associé un attribut entier qui permet l’utilisation du nœud
dans la génération de graphes ou dans les algorithmes.
De plus, les nœuds graphiques possèdent deux valeurs booléennes, qui indiquent si le nœud
est sélectionné ou s’il fait partie d’un parcours algorithmique et qui ne servent uniquement que pour le
dessin du nœud. De plus, chaque nœud possède une autre valeur booléenne qui indique si l’étiquette
liée au nœud doit être affichée ou non. Ceci peut permettre à l’utilisateur de masquer l’étiquette
de tous les nœuds si la visibilité sur un gros graphe est amoindrie du fait du nombre important
d’étiquettes affichées.
Chaque nœud graphique possède également deux attributs de couleur. Ceux-ci sont impor-
tants du fait que l’utilisateur peut modifier la couleur de chaque élément comme bon lui semble. Le
premier attribut est la couleur de base du nœud, qui n’est pas modifiable, mais c’est grâce à cet
attribut que l’utilisateur peut réinitialiser la couleur du nœud. Le second attribut de type couleur
est la couleur actuelle du nœud, c’est elle qui sert à l’affichage du nœud. Celle-ci peut être modifiée
par l’utilisateur à l’aide du bouton situé dans la barre d’édition du graphe.
Enfin, les deux derniers attributs du nœud graphique sont des distances, l’une calculée sur
l’axe des x et l’autre calculée sur l’axe de y. Ces distances permettent de mémoriser l’écart du nœud
sur x et sur y vis-à-vis de l’un des éléments d’une sélection que l’on a choisi pour le déplacement.
3.3.2.1.2 Méthode de dessin

La méthode de dessin utilise, comme le graphe graphique, la classe graphique Graphics2D.
Cette dernière permet de dessiner une forme (Shape) qui aura été définie auparavant pour le nœud.
Pour définir la forme du nœud, nous utilisons directement la méthode : setFrame(x, y, 10, 10); ainsi,
les directives de dessin du nœud sont stockées directement dans la classe du nœud.
Nous avons donc dans notre application des nœuds graphiques de coordonnées variables,
mais de diamètre 10. De plus, la couleur du nœud dépend plus précisément de la valeur des booléens
qui leur est associée. C’est-à-dire qu’un nœud sera coloré en bleu turquoise s’il est sélectionné ou en
violet s’il appartient à un parcours spécifique à un algorithme.

3.3.2.1.3 Spécificités
Le fait que la classe NœudGraphique hérite de la classe Ellipse2D.Double n’est pas anodin,
car cette dernière implémentant l’interface Shape. De ce fait, notre NœudGraphique a accès à une
méthode vitale pour les interactions directes entre le graphe graphique et l’utilisateur, la méthode
contains(Point2D p). Cette méthode retourne un booléen qui indique si le nœud graphique contient,
ou non, le point p sélectionné sur le graphe. De ce fait, nous avons pu tester directement si le nœud
est sélectionné par l’utilisateur ou non.
Fig. 3.12 – Exemple de nœud graphique normal, sélectionné, dans un parcours
3.3.2.2 La classe AreteGraphique

C’est grâce à cette classe que nous définissons et affichons les arêtes graphiques sur le graphe
graphique.
3.3.2.2.1 Caractéristiques de base d’une arête graphique

Tout d’abord, il est important de noter que toute arête hérite de la classe graphique
Line2D.Double cette classe nous permet de dessiner facilement des lignes en définissant aisément
leurs caractéristiques.
Une arête graphique n’est en fait qu’un renvoi à ses deux extrémités. C’est pour quoi chaque
arête graphique possède deux attributs de type nœud graphique qui représentent son extrémité et
son origine. Ainsi, la définition d’une arête est plus facile, car ses extrémités sont obligatoirement
des nœuds déjà existants sur le graphe. De plus, chaque arête possède un attribut de type entier
permettant de lui affecter une pondération qui lui est propre. Ceci est utile lors de la création d’un
graphe de coûts et pour trouver grâce à un algorithme le chemin de poids minimum. À la création
d’une arête, son poids est défini à 1, il ne s’affiche donc pas.
Une arête graphique, à l’instar d’un nœud graphique, possède également deux booléens
permettant de définir si elle est sélectionnée ou bien contenue dans un parcours algorithmique et
donc de lui attribuer une couleur spécifique. Celle-ci sera donc verte si elle est sélectionnée et orange
lorsqu’elle sera contenue dans un parcours algorithmique. Concernant toujours l’affichage d’une arête,
nous avons intégré de la même manière que pour les nœuds graphiques un booléen permettant de
masquer ou non la pondération de l’arête, ainsi que deux attributs de type couleur, l’un stockant
la couleur de base d’une arête et l’autre stockant la couleur courante et étant celle utilisée pour
l’affichage sur le graphe.
Enfin, chaque arête possède quatre attributs de type entier qui permettent de stocker la
distance sur x et sur y de chacune de ses extrémités, par rapport à un point donné. Ces distances
fonctionnent de la même manière que pour un nœud graphique et ne sont uniquement présentes

que pour conserver la bonne distance entre les éléments et pour laisser donc le graphe dans un état
cohérent avant et après le déplacement d’une sélection.
3.3.2.2.2 Méthode de dessin

Afin de dessiner correctement une arête dans le graphe graphique, il faut tout d’abord repérer
les coordonnées de ses extrémités. Celles-ci s’obtiennent facilement à l’aide des nœuds graphiques
stockés comme origine et extrémité de chaque arête. Par la suite, comme chaque arête hérite de la
classe Line2D.Double, nous pouvons la paramétrer en utilisant la commande :

1 setLine(origine.getX()+5, origine.getY()+5, extremite.getX()+5,
extremite.getY()+5);

Ainsi, la ligne est paramétrée dans la classe et non lors du dessin, ce qui donne la possibilité
de la dessiner plusieurs fois et de façon identique.
La seconde étape du dessin d’une arête est l’affichage de la pondération de l’arête. Nous
avons décidé que si l’arête avait une pondération de 1, cette dernière n’était pas affichée. Ensuite, un
problème d’affichage est survenu lors du déplacement de l’une des extrémités de l’arête. Nous avons
remarqué que selon les coordonnées de ses extrémités, le poids s’affichait directement sur l’arête, ce
qui empêchait donc une lecture claire du poids. Il nous a fallu donc calculer le placement du poids
selon son orientation. Par exemple, lorsque l’origine de l’arête possède des coordonnées sur x et sur
y qui diffèrent toutes deux par rapport à celles de l’extrémité, nous avons fait en sorte que le poids
s’affiche au-dessus de l’arête. Concernant les lignes, verticales ou horizontales, nous avons opté pour
décaler la valeur de la pondération et ainsi éviter tout chevauchement. (cf. Figure 3.13).
Fig. 3.13 – Positionnement de la pondération d’une arête graphique
Fig. 3.14 – Exemple d’arête normale, sélectionnée, contenue dans un parcours
3.3.2.2.3 Spécificités
Outre le fait de la définition dans la classe, des caractéristiques de l’arête, un autre avantage
de l’héritage de la classe Line2D.Double est l’héritage de la méthode contains(Point2D p). Cette
dernière vérifie si la forme géométrique (Shape) possède, ou non, le point p dans son dessin. Le seul

problème qui est très vite apparu est que la méthode contains(Point2D p) de la classe Line2D.Double
ne fonctionne pas, car vérifier si une ligne, qui est uniquement une succession de points, contient un
point est difficile. Il nous a fallu donc redéfinir la méthode contains(Point2D p) et utiliser une autre
méthode de la classe Line2D.Double qui est la méthode ptSegDist(Point2D p) et qui retourne la
distance en pixels, du point p au segment pour lequel est appelée la fonction.
La nouvelle fonction contains(Point2D p) de la classe AreteGraphique devient :

1 public boolean contains(Point2D p)
2 {
3 return(this.ptSegDist(p) <= 3.0);
4 }

Nous avons défini une distance de clic inférieure ou égale à 3, afin que la sélection d’une arête
se fasse aisément et que si plusieurs arêtes sont proches, elles ne soient pas sélectionnées toutes les
deux en même temps du fait d’une sensibilité trop importante.
3.3.2.3 La classe GrapheGraphique

C’est la classe principale d’affichage du graphe. Elle hérite de la classe JPanel, qui décrit un
panneau. Ce panneau est modifiable et on peut donc dessiner dessus. C’est cette méthode que nous
allons utiliser pour afficher le graphe.
3.3.2.3.1 Eléments de base

Cette classe contient deux listes, qui sont la liste de nœuds graphiques, ainsi que la liste
d’arêtes graphiques qui vont être affichées à l’écran. La simple modification de ces listes entraine
directement une modification de l’affichage du graphe.
De plus, nous avons implémenté notre classe GrapheGraphique sous forme de machine à états,
grâce au design pattern state. C’est-à-dire que l’état courant du graphe graphique va correspondre
à une de ses modifications. Pour cela nous avons défini une classe abstraite EtatGraphe qui doit
implémenter les écouteurs d’événements souris qui sont MouseListener et MouseMotionListener, qui
écoutent respectivement les clics de souris et les mouvements de souris. Pour le moment toutes les
méthodes issues des écouteurs d’événements sont vides dans la classe EtatGraphe. Ensuite nous avons
dû créer une classe par état de modification des graphes. Chacune de ces classes hérite de la classe
EtatGraphe. Ces états ne redéfinissent que les écouteurs d’événements souris dont ils ont besoin. Et
donc, lorsque le graphe graphique sera dans un état qui effectue une tâche lors d’un relâchement
de bouton souris, une action effective sera effectuée sur le graphe. D’autre part, certains modes
de modification du graphe doivent utiliser deux états, par exemple la création d’arêtes ou bien le
déplacement de sommets, d’arêtes ou d’une sélection. Car lors de la création de la création d’une arête,
par exemple, nous commençons par modifier l’état de notre machine à l’aide d’une nouvelle instance
de la classe DebutCréationArete(GrapheGraphique g), qui permet de sélectionner le nœud d’origine
de l’arête et, lorsque ce dernier est sélectionné, nous modifions l’état courant du GrapheGraphique
à l’aide d’une nouvelle instance de la classe SuiteCreationArete(GrapheGraphique g), qui permet de

sélectionner le nœud extrémité de la nouvelle arête et de la créer par la suite.

Voir la Figure 4.2 en annexe page 47 représentant le diagramme de classes de la gestion du
pattern état pour le graphe graphique.
Liste des différents états possibles du graphe :

– Attente : L’état de base ou l’on ne peut pas modifier le graphe.
– ApplicationCouleur : Cet état, lorsqu’il est actif, permet d’appliquer une couleur sélec-
tionnée à n’importe quel élément du graphe.
– CréationSommet : Cet état permet l’ajout d’un sommet lors d’un clic souris sur le
panneau du graphe.
– DebutCreationArete : Permet de passer à la première étape de la création d’une arête,
c’est-à-dire la sélection de l’origine de cette dernière.
– SuiteCreationArete : Permet de sélectionner l’extrémité de la nouvelle arête et ainsi de
la créer.
– DebutDeplacement : Permet de sélectionner un élément du graphe que l’on souhaite
déplacer, cela peut être un sommet ou une arête.
– SuiteDeplacement : Dans cet état, on peut effectuer le déplacement effectif de l’élément
souhaité.
– DebutDeplacementSelection : Cet état permet de cliquer sur l’un des éléments de
l’ensemble des éléments sélectionnés.
– SuiteDeplacementSelection : Permet de faire le déplacement effectif de toute la sélec-
tion, à partir de l’élément cliqué dans l’état « DebutDeplacementSelection ».
– Selection : Cet état permet de sélectionner un ensemble d’éléments du graphe en vue
d’un déplacement ou d’une suppression future.
– SelectionSommetAlgo : Permet de sélectionner deux sommets du graphe afin d’appli-
quer un algorithme entre les deux sommets concernés.
– EtiquetageSommet : Permet de modifier l’étiquette d’un sommet « cliqué » au préalable
par l’utilisateur.
– EtiquetageArete : Permet de modifier la pondération d’une arête après que celle-ci ait
été « cliquée » par l’utilisateur

3.3.2.3.2 La méthode de dessin du GrapheGraphique

Le graphe graphique étant une spécification de JPanel, il possède par héritage une méthode
paintComponent. Cette méthode permet de dessiner sur le panneau, grâce à des classes graphiques
telles que Graphics ou Graphics2D. Dans notre cas, nous avons utilisé la classe Graphics2D qui
offre de plus grandes possibilités concernant le dessin. De plus, nous pouvons appliquer des effets
concernant le rendu final d’affichage, beaucoup plus conséquents qu’avec Graphics.
Pour dessiner concrètement un graphe, dans notre méthode paintComponent, nous parcou-
rons dans un premier temps la liste contenant tous les nœuds. C’est à dire, que nous appelons pour
chacun d’eux leur méthode de dessin en lui spécifiant le contexte graphique du graphe, ainsi le nœud
est dessiné sur le panneau du graphe. Par la suite, nous faisons de même pour la liste des arêtes du
graphe.
3.3.2.3.3 Ecouteurs d’événements souris du GrapheGraphique

Le graphe graphique est implémenté de sorte à écouter les événements souris exercés sur
lui-même. Ces événements sont de deux types : les actions sur les boutons de souris (bouton pressé,
bouton relâché) et les mouvements de souris (souris déplacée avec le bouton pressé).
Comme nous l’avons dit précédemment, ces écouteurs ne fonctionnent que si la classe Gra-
pheGraphique est dans un état bien précis. C’est-à-dire que les méthodes d’ajout de sommet ou
d’arête, les méthodes d’étiquetage de nœuds ou d’arêtes, celles de sélection ou bien celle d’appli-
cation de couleur ne fonctionneront que si la machine est dans l’état leur correspondant et qu’un
évènement de type « bouton relâché » (mouseReleased) est exercé sur le graphe graphique. Car ces
méthodes ne sont définies que pour des états du graphe bien précis.
Les états pour lesquels l’événement « bouton de souris pressé » (mousePressed) est défini,
sont principalement liés au début de l’un des divers déplacements possibles sur le graphe graphique,
tels que le déplacement de sommets, d’arêtes ou d’une sélection complète. Lorsque la souris est
pressée sur l’un des éléments et que l’état courant du graphe correspond à un déplacement possible,
des calculs sont effectués selon le type d’élément à déplacer. Ceci permet de garder le graphe dans
un état cohérent et correspondant à la volonté de l’utilisateur.
Enfin les états pour lesquels l’événement « souris déplacée avec le bouton pressé» (mouse-
Dragged) est défini, correspondent uniquement à la suite de l’un des déplacements possibles sur le
graphe. Après que les calculs aient été effectués lors de l’appui sur le bouton, on actualise la position
de l’élément ou de la sélection déplacé, à l’aide des coordonnées du nouveau point où se situe le
curseur, et des calculs effectués dans le mousePressed.
Quel que soit l’écouteur utilisé, nous utilisons les coordonnées du point où se trouve le curseur
pour effectuer nos actions sur le graphe.

3.3.3 Les boites de dialogues

Dans notre application, l’utilisateur a entièrement le choix en ce qui concerne les types de
graphes qu’il désire générer, et plus particulièrement sur le nombre de sommets et d’arêtes ainsi que
de leur pondération. C’est pour cela que les boites de dialogues sont très utiles ici. Nous avons donc
intégré au menu Graphes des boites de dialogues qui permettent à l’utilisateur d’entrer le nombre de
nœuds et d’arêtes, pour donner ainsi à notre outil un système où le libre choix de la génération est
possible.
3.3.3.1 Les boites de dialogue prédéfinies

Le premier type de boites de dialogue que nous avons utilisées sont les boites de dialogue
prédéfinies dans Java. Ces boites de dialogue sont définies par la classe JOptionPane et leur appel se
fait ainsi : JOptionPane.showInputDialog ou JOptionPane.showConfirmDialog
Ces deux appels affichent respectivement une boite de dialogue de saisie et une boite de
dialogue permettant de confirmer ou d’annuler la dernière action de l’utilisateur. Elles sont utiles lors
de la demande de saisie simple à un utilisateur.
3.3.3.2 Les boites de dialogue complexes créées

Pour les demandes de saisies plus complexes et de plus d’une donnée, nous avons créé des
boites de dialogues spécifiques. Elles contiennent deux champs de texte permettant la saisie multiple et
deux boutons pour valider ou annuler l’action. Ces boites de dialogue sont plus généralement utilisées
pour les générations demandant le nombre de nœuds et le nombre d’arêtes ou celle demandant le
nombre de nœuds et la distance maximale de création d’une arête entre deux nœuds.
Fig. 3.15 – Exemple de boites de dialogue de saisie simple et complexe

3.3.4 Outils d’édition et de modification supplé-

mentaires
3.3.4.1 Gestion du undo /redo
Pour se « souvenir » d’une séquence de transactions, et pouvoir revenir en arrière arbitraire-
ment loin, on utilise un gestionnaire de transactions(UndoManager). Ainsi dans la classe GrapheGra-
phique nous avons déclaré un undoManager qui sera alimenté lorsqu’une action sur la barre d’outils
EditionGraphe sera effectuée.
L’alimentation de ce vecteur se fait à l’aide de la méthode addEdit(UndoableEdit Edit) ;
de ce fait pour chaque action pouvant être effectuée par l’utilisateur, une classe Edit qui hérite de
AbstractUndoableEdit lui est associée. C’est cette classe qui contient l’action défaire et refaire lui
correspondant.
Vous trouverez en annexe, à la page 46, la Figure 4.1 représentant le diagramme des classes
associées à cet outil.
3.4 Sauvegarde et chargement

Pour la sauvegarde, nous avons cherché plusieurs structures de fichiers différentes. Ainsi,
avons décider d’adopter le format XML et plus précisément le formalisme : graphML.
Nous avons donc trouvé toutes les informations relatives à ce format à l’adresse suivante :
http://graphml.graphdrawing.org/primer/graphml-primer.html
Pour notre application, nous sauvegardons 3 informations par nœud : leur numéro, leur x
et leur y. Nous sauvegardons ceci, car nous ne voulions pas perdre la configuration des nœuds faite
par l’utilisateur. Il retrouvera donc toujours ces nœuds là où il les a placés. Pour les arêtes, nous
sauvegardons le poids, la source et la destination. Vous trouverez un exemple de fichier XML formatté
par notre application ) la page suivante.
Le chargement quant à lui ouvre le fichier et assigne les points et les arêtes dans un nouveau
graphe.
3.5 Exportation
L’une des demandes de nos tuteurs étant la possibilité d’exploiter les graphes créés par le
logiciel, nous avons mis en place la possibilité à l’utilisateur d’exporter son travail afin de l’intégrer
dans d’autres supports comme des sites web ou des rapports par exemple. Ainsi, on peut obtenir une
image de notre travail au format JPG comme vous pouvez le voir sur la Figure 3.16 ou la Figure 3.17
situées page 40
Cette partie de l’application a été conçue pour intégrer facilement de nouveaux formats
d’export comme LATEX ou DOT par exemple. Toutefois, pour des raisons de temps nous n’avons
implémenté que l’export en JPG pour le moment.
Développement 38 3.4 Sauvegarde et chargement


1 <graph>
2 <options />
3 <graphml>
4 <key id="posX" for="node" attr.name="x" attr.type="int" />
5 <key id="posY" for="node" attr.name="y" attr.type="int" />
6 <key id="weight" for="edge" attr.name="weight" attr.type="int" />
7 <graph id="1.xml">
8 <node id="0">
9 <data key="posX">162</data>
10 <data key="posY">122</data>
11 </node>
12 <node id="1">
15 </node>
16 <node id="2">
19 </node>
20 <edge source="0" target="2">
21 <data key="weight">1</data>
22 </edge>
23 <edge source="1" target="2">
24 <data key="weight">10</data>
25 </edge>
26 </graph>
27 </graphml>
28 </graph>

3.5 Exportation 39 Développement

Fig. 3.16 – Exemple d’export au format JPG
Fig. 3.17 – Autre exemple d’export au format JPG
Développement 40 3.5 Exportation

4 Procédure de tests
Troisième et dernière partie du développement de notre projet, la période de tests a été

découpée en trois phases. De cette manière, il nous a été possible de cerner les besoins et les objectifs
de chacune de ces trois phases plus simplement que s’il avait été nécessaire de le faire de manière
globale. Ce chapitre suit le même partitionnement que cette étape essentielle.
4.1 Tests alpha

Cette première étape des tests s’est déroulée tout au long de la vie de notre projet. En effet,
puisque nous avons adopté un développement itératif, nous avons pu reproduire ces tests pour chaque
nouveauté intégrée au logiciel, en prenant garde à conserver une certaine rétro compatibilité. Les tests
alpha se sont donc faits entièrement en interne et nous ont permis de découvrir et de corriger des
bugs au niveau modulaire. Le projet n’ayant couru que sur une quinzaine de semaines, nous n’avons
réalisé que trois itérations et donc trois phases de tests alpha.
4.2 Tests bêta

La seconde étape des tests n’a été réalisée qu’après l’arrêt du développement de nouvelles
fonctionnalités et après la dernière phase de tests alpha. Elle s’est déroulée avec un petit groupe de
personnes qui ont accepté d’utiliser l’application comme s’ils étaient en situation réelle. Aidés par un
rapide manuel d’utilisation leur permettant une prise en main plus rapide, ils ont eu pour instruction
de torturer l’application pour essayer d’en trouver les failles. L’expérience a été fructueuse puisque
pas moins de sept vulnérabilités ont été découvertes par ce biais.
4.3 Tests d’ergonomie

La dernière phase de tests a débuté après toutes les autres puisqu’il est nécessaire qu’aucun
bug ne vienne la perturber. Son principe est de confronter des personnes issues de la population cible
avec le logiciel sous la surveillance d’un observateur. Le testeur est mis face au logiciel qu’il ne connaı̂t
pas et il lui est demandé de réaliser des tâches. L’observateur note le temps que passe le testeur à
tenter d’y parvenir ainsi que l’état d’esprit apparent du testeur. Le but est de distinguer les tâches
qui ne parviennent pas à être effectuées de manière rapide, efficace et agréable.
41 Procédure de tests
Perspectives et conclusion
Perspectives
Par manque de temps, nous n’avons pas pu implémenter toutes les fonctions et outils que
nous avions prévus.
L’une des fonctionnalités qui peut être intéressante à ajouter à notre application est le copier-
coller. C’est-à-dire que l’utilisateur pourrait sélectionner un ensemble d’éléments du graphe et aurait
la possibilité soit de les dupliquer, soit de les couper, sur le même graphe ou bien sur le graphe
contenu dans un autre onglet.
De plus, pour faciliter la sélection multiple d’éléments du graphe, nous aurions pu ajouter
un rectangle de sélection, dit aussi « rectangle élastique ». Ce rectangle serait apparu directement
dans la fenêtre d’affichage du graphe lors d’un clic souris dans une partie ne contenant pas d’élément.
Sa taille varierait selon le déplacement de la souris en maintenant le bouton cliqué. Ceci aurait pour
effet de sélectionner automatiquement les éléments contenus dans ce rectangle ou bien les éléments
étant en partie en contact avec le rectangle. Et finalement, celui-ci disparaitrait dès que l’utilisateur
aurait relâché le bouton souris.
Enfin, nous avions éventuellement envisagé d’externaliser un certain nombre de classes dans
des fichiers JAR afin de créer un système de plug-ins dynamiques. Le développement de cette fonc-
tionnalité a été abandonné au profit des tests et corrections de notre version actuelle. Toutefois, notre
architecture permettrait de l’ajouter par la suite sans trop de peine.
Conclusion
La création d’un logiciel de visualisation de graphes requiert une bonne étude préalable,
afin de répondre facilement aux attentes des utilisateurs. C’est pourquoi, pour l’élaboration de notre
projet, il nous a fallu trouver une interface correcte et souple. Après cette étape, nous avons du
faire appel à nos connaissances en algorithmique de graphes ainsi qu’en IHM et de les combiner
pour obtenir un programme simple d’utilisation et directement compréhensible par l’utilisateur. Les
directives de nos tuteurs nous ont également beaucoup aidés, car le monde des graphes est assez vaste
et l’on peut vite s’éloigner du but premier de l’application.
Ce projet nous aura appris comment rassembler, de la manière la plus efficace possible, les
algorithmes de graphes qui traitent généralement des données difficilement représentables à l’écran,
Perspectives 43 Perspectives et conclusion

tels que des listes d’adjacence, par exemple, avec des éléments graphiques sensés représenter les
graphes. Il nous aura également permis de nous familiariser avec les techniques d’IHM permettant
de créer une grande interactivité au niveau du logiciel.
Grâce à ce projet, nous avons pu nous familiariser au travail en groupe et à la répartition
des tâches entre les membres de ce dernier. Nous avons dû beaucoup discuter afin de lier d’une
façon correcte et efficace les différents modules du logiciel. Nous avons également eu l’opportunité
d’étudier différents patrons de conception, qui nous ont permis de rendre, au final, notre application
plus modulaire.
Au final, ce projet est intéressant en tous points, car il nous a permis de mettre en jeu
beaucoup de nos connaissances en informatique et de prendre notre connaissance de notre niveau
d’interaction avec les autres membres du groupe.
Perspectives et conclusion 44 Conclusion

Annexes
4.4 Diagrammes
Fig. 4.1 – Diagramme UML des classes utilisées pour l’implémentation de l’undo/redo
Perspectives et conclusion 46 4.4 Diagrammes

Fig. 4.2 – Diagramme de classe de gestion du patron de conception Etat
4.4 Diagrammes 47 Perspectives et conclusion

Table des figures

2.1 Schéma du modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Schéma de la variante M-VC modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Schéma du design pattern Fabrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Schéma du design pattern Monteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Schéma du design pattern État . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Schéma du design pattern Stratégie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Cheminement dans l’interface pour l’utilisation de l’algorithme du Plus Court Chemin 20
3.2 Cheminement dans l’interface pour l’utilisation de l’algorithme du Diamètre . . . . . 21
3.3 Génération d’un graphe en Anneau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Génération d’un graphe Complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Génération d’un graphe Biparti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Génération d’un graphe Régulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Génération d’un graphe totalement Aléatoire . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Génération d’un graphe dit « Social » . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9 Illustration de la Fenêtre Principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.10 Vue de la barre d’onglets et de tous ses composants. . . . . . . . . . . . . . . . . . . . 29
3.11 Vue de la barre d’outils d’édition du graphe . . . . . . . . . . . . . . . . . . . . . . . 29
3.12 Exemple de nœud graphique normal, sélectionné, dans un parcours . . . . . . . . . . 32
3.13 Positionnement de la pondération d’une arête graphique . . . . . . . . . . . . . . . . 33
3.14 Exemple d’arête normale, sélectionnée, contenue dans un parcours . . . . . . . . . . . 33
3.15 Exemple de boites de dialogue de saisie simple et complexe . . . . . . . . . . . . . . . 37
3.16 Exemple d’export au format JPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.17 Autre exemple d’export au format JPG . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Diagramme UML des classes utilisées pour l’implémentation de l’undo/redo . . . . . . 46

4.2 Diagramme de classe de gestion du patron de conception Etat . . . . . . . . . . . . . 47
Annexes 48 Liste des Figures

Bibliographie
[1] Lacomme, Philippe and Prins, Christian and Sevaux, Marc, Algorithmes de graphes,
Eyrolles, seconde édition edition, 2003.
[2] J. Nogier, Ergonomie du logiciel et design web, Dunod, 2003.
[3] E. Puybaret, Les Cahiers du programmeur Swing, Eyrolles, 2006.
[4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: elements of reusable
object-oriented software, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA,
1995.
Bibliographie 49 Annexes
Webographie
[5] Supinfo, Java & Solaris par le Laboratoire SUPINFO des technologies Sun, http://www.
labo-sun.com/.
[6] G. Picard, Design Patterns - Outils pour la Gestion de Projets, 2007, http://www.emse.fr/
~vercouter/cours/ogp/DesignPatternsISI.pdf.
[7] S. Microsystems, Java 2 Platform SE 5.0, http://java.sun.com/j2se/1.5.0/docs/api/.
[8] T. G. Team, The GraphML File Format, http://graphml.graphdrawing.org/.
[9] L. tuteurs informatique de l’ENS, Le Hublot, http://www.tuteurs.ens.fr/docs/

hublot/.
[10] N. Seriot, Quickies > LaTeX > Graphes, http://quickies.seriot.ch/index.php?p=

default&cat=4.
[11] V. Lainé, Création d’un système de plugins en java, http://vincentlaine.developpez.com/

tutoriel/java/plugins/.
[12] J. Mark, famfamfam.com: Silk icons - That’s your lot, http://www.famfamfam.com/archive/

silk-icons-thats-your-lot/.
Annexes 50 Webographie
Résumé
Dans le cadre du Master d’Informatique de l’Université de Montpellier 2 il est obligatoire

de réaliser un Travail d’Étude et de Recherche. Celui-ci est mené par un petit groupe d’étudiants
bénéficiant d’un sujet proposé par un ou plusieurs tuteurs.
Le projet, dont ce document est le rapport, consiste en la réalisation, de la conception aux

tests, d’un logiciel de création et de visualisation de graphes. Il a été réalisé par quatre étudiants
de première année de Master Informatique durant le second semestre de l’année universitaire 2007 -
2008.
Vous trouverez donc dans ce document :

– une description du sujet étoffé des demandes directes des tuteurs ;
– un dossier d’analyse contenant des précisions sur un certain nombre de patrons de concep-
tion ;
– des détails sur les points essentiels du développement de l’application ;
– des informations sur les méthodes de test et de correction des bugs
Mots-clef : graphe, visualisation, IHM

Visualisation de Graphes: Master Informatique Universit e de Montpellier II 2007-2008

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Visualisation de Graphes: Master Informatique Universit e de Montpellier II 2007-2008

Transféré par

Droits d'auteur :

Formats disponibles

Master Informatique

Encadrants : Anne-Elisabeth BAERT et Vincent BOUDET

Le cursus de Master Informatique au sein de l’Université de Montpellier 2 donne une part

Table des matières

Table des matières 6

Table des matières 6

7 Table des matières

Certaines personnes ont la volonté ou la nécessité de visualiser des structures de données

Analyse du projet 12 2.1 Le sujet

2.2 Choix des outils de développement

2.3 Modèle MVC

2.3.1 Architecture générale

2.2 Choix des outils 13 Analyse du projet

Fig. 2.1 – Schéma du modèle MVC

2.3.2 Notre implémentation

Analyse du projet 14 2.3 Modèle MVC

Fig. 2.2 – Schéma de la variante M-VC modèle MVC

2.4 Patrons de conception

2.4.1 Le patron « Singleton »

2.4 Patrons de conception 15 Analyse du projet

4 /* Constructeur non public */

2.4.2 Les patrons « Monteur » et « Fabrique »

Fig. 2.3 – Schéma du design pattern Fabrique

Le patron Fabrique (i.e. Factory) permet d’abstraire l’instanciation d’une ou de plusieurs

Analyse du projet 16 2.4 Patrons de conception

Fig. 2.4 – Schéma du design pattern Monteur

2.4.3 Le patron « État »

Fig. 2.5 – Schéma du design pattern État

2.4 Patrons de conception 17 Analyse du projet

de notre classe GrapheGraphique, chargée de l’affichage d’un graphe.

2.4.4 Le patron « Strategie »

Fig. 2.6 – Schéma du design pattern Stratégie

Analyse du projet 18 2.4 Patrons de conception

3.1 Algorithmes de calculs appliqués aux graphes

5 pour i=1 jusqu’à Nombre de sommets -1 faire

Développement 20 3.1 Algorithmes de calcul

3.1.2 Algorithme « Diamètre »

Fig. 3.2 – Cheminement dans l’interface pour l’utilisation de l’algorithme du Diamètre

3.2 Génération de graphes

3.2 Génération de graphes 21 Développement

Fig. 3.3 – Génération d’un graphe en Anneau

Fig. 3.4 – Génération d’un graphe Complet

Développement 22 3.2 Génération de graphes

Fig. 3.5 – Génération d’un graphe Biparti

3.2 Génération de graphes 23 Développement

Fig. 3.6 – Génération d’un graphe Régulier

Fig. 3.7 – Génération d’un graphe totalement Aléatoire

Développement 24 3.2 Génération de graphes

Fig. 3.8 – Génération d’un graphe dit « Social »

3.2 Génération de graphes 25 Développement

3.3.1 Fenêtres Principales

3.3.1.1 La classe Fenêtre : Fenêtre Principale

Fig. 3.9 – Illustration de la Fenêtre Principale

Cette classe se divise en trois parties distinctes.

Développement 26 3.3 Interface

3.3 Interface 27 Développement

3.3.1.3 La barre d’outils

3.3.1.4 La classe OngletsVisualisations : vue des graphes et de

Développement 28 3.3 Interface

Fig. 3.10 – Vue de la barre d’onglets et de tous ses composants.

3.3.1.4.2 La classe EditionGraphe : actions sur les graphes

Fig. 3.11 – Vue de la barre d’outils d’édition du graphe

3.3 Interface 29 Développement