Visualisation de Graphes

52  Download (0)

Texte intégral

(1)

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

(2)
(3)

Remerciements

Lors d’une r´eunion avec nos tuteurs (Anne-Elisabeth BAERT et Vincent BOUDET), nous avons appris leur d´egout certain pour la section d’un rapport concernant les remerciements. Nous en avons donc d´eduit qu’ils ne la liraient certainement pas et donc nous avons d´ecid´e de ne pas les remercier! Par ailleurs, nous ne remercions pas non plus plus les personnes qui nous ont aid´es directement (Guilhem BARLOY par exemple) ou indirectement (tous les auteurs cit´es dans la Bibliographie page 49 ou dans la Webographie page 50). Notre ingratitude sans bornes touche

´

egalement les quelques personnes, dont nous ne citerons bien ´evidemment pas les noms, ayant test´e notre application, nous ayant permis de la corriger et de l’am´eliorer grandement. Comble de l’´ego¨ısme, nous ne remercions pas non plusnos parents sans qui rien de tout ceci n’aurait ´et´e possible, ni mˆeme nos enseignants qui, depuis l’´ecole maternelle, ne nous ont inculqu´e que des notions qui ont toutes eu leur utilit´e dans ce projet.

Toutefois, nous aimerions dire un grand merci aux personnes qui liront ce rapport et `a la soci´et´e Druide informatique inc. Aux premiers parce qu’il y a de fortes chances que vous soyez l’une des personnes sus-cit´ees ; aux seconds parce que sans vous et votre logiciel (Antidote) les premiers n’auraient surement pas ´et´e bien nombreux.

3 Remerciements

(4)

Avant propos

Le cursus de Master Informatique au sein de l’Universit´e de Montpellier 2 donne une part importante `a l’apprentissage pratique du travail d’un d´eveloppeur au sein d’une entreprise ou d’un laboratoire de recherche. Dans cette optique, il est demand´e aux ´etudiants de participer `a des Travaux d’Etudes et de Recherche en groupes encadr´´´ es. Chaque groupe dispose d’un sujet constituant le projet qu’il devra r´ealiser de l’analyse aux tests en un temps donn´e.

Le projet d´ecrit dans ce document a ´et´e amorc´e par le d´esir de certaines personnes d’avoir dans leur logith`eque une application leur permettant de cr´eer et de manipuler des graphes. Ces personnes ´etant proches du monde de la recherche fondamentale et de l’enseignement ont d´ej`a pu essayer les logiciels existants, mais n’ont pas ´et´e convaincues de leur ad´equation `a leurs besoins. Ils ont donc rassembl´e ces besoins pour en faire un sujet de Travaux d’´Etudes et de Recherche.

Avant propos 4

(5)
(6)

Table des mati` eres

Page de garde 1

Avant propos 3

Table des mati`eres 6

Introduction 9

2 Analyse du projet 11

2.1 Le sujet . . . 11

2.1.1 D´efinition . . . 11

2.1.2 Approfondissement . . . 12

2.2 Choix des outils . . . 13

2.3 Mod`ele MVC . . . 13

2.3.1 Architecture g´en´erale . . . 13

2.3.1.1 Mod`ele . . . 13

2.3.1.2 Vue . . . 14

2.3.1.3 Contrˆoleur . . . 14

2.3.2 Notre impl´ementation . . . 14

2.4 Patrons de conception . . . 15

2.4.1 Singleton . . . 15

2.4.2 Monteur et Fabrique . . . 16

2.4.3 Etat . . . .´ 17

2.4.4 Strategie . . . 18

3 D´eveloppement 19 3.1 Algorithmes de calcul . . . 19

3.1.1 Plus Court Chemin . . . 19

3.1.2 Diam`etre . . . 21

3.2 G´en´eration de graphes . . . 21

3.2.1 Anneau . . . 21

Table des mati`eres 6

(7)

3.2.2 Complet . . . 22

3.2.3 Biparti . . . 23

3.2.4 R´egulier . . . 23

3.2.5 Al´eatoire . . . 23

3.3 Interface . . . 26

3.3.1 Fenˆetres Principales . . . 26

3.3.1.1 La classe Fenˆetre : Fenˆetre 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 El´´ ements 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 Pr´ed´efinies . . . 37

3.3.3.2 Complexes . . . 37

3.3.4 Outils suppl´ementaires . . . 38

3.3.4.1 Gestion du undo /redo . . . 38

3.4 Sauvegarde et chargement . . . 38

3.5 Exportation . . . 38

4 Proc´edure de tests 41 4.1 Tests alpha . . . 41

4.2 Tests bˆeta . . . 41

4.3 Tests d’ergonomie . . . 41

Conclusion 43 Annexes 46 4.4 Diagrammes . . . 46

Table des figures . . . 48

Bibliographie . . . 49

Webographie . . . 50

R´esum´e 52

7 Table des mati`eres

(8)
(9)

Introduction

Certaines personnes ont la volont´e ou la n´ecessit´e de visualiser des structures de donn´ees de type Graphe. Ces donn´ees ont pour la plupart du temps des structures complexes compos´ees de sommets et d’arˆetes, ce qui les rend souvent illisibles ou bien tr`es complexes `a exploiter en fonction de l’importance du nombre de sommets ou d’arˆetes qu’ils contiennent. Ces structures sont tr`es utilis´ees, car elles poss`edent des caract´eristiques sous-jacentes qui leur sont propres, telles que le diam`etre, le plus court chemin ou un arbre couvrant partant d’un sommet. Ces caract´eristiques sont importantes pour les calculs th´eoriques et les r´esultats d´ecoulant de ces Graphes.

Les outils existants ne sont pas non plus toujours adapt´es `a ce dont les utilisateurs ont besoin,

`

a cause de leur interface ou de leurs outils de calcul. Un autre d´efaut principal de ces outils est leur prix trop ´elev´e 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 cr´eation et de visualisation de graphes simple et intuitive `a destination d’un public universitaire.

9 Introduction

(10)
(11)

2 Analyse du projet

Dans tout projet professionnel bien men´e, l’analyse et la conception doivent au moins consom- mer autant de ressources que le d´eveloppement. Nous avons donc r´ealis´e 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 d´evoile les points les plus int´eressants de son analyse.

2.1 Le sujet

2.1.1 D´ efinition

Titre

Visualisation de graphes

R´ esum´ e

Le but du TER est de d´evelopper une application de visualisation 2D de graphes et de leurs propri´et´es.

Parcours

CASAR, DIWEB, GL.

Modules connexes

– Conception et d´eveloppement d’IHM – R´eseaux

– Algo

D´ etail

Pour ´etudier le comportement de syst`emes distribu´es, comme les r´eseaux ad hoc par exemple, une approche consiste `a mod´eliser ces r´eseaux par des graphes et `a utiliser des outils de visualisation pour voir le comportement de ces r´eseaux lorsqu’on leur applique certains algorithmes. Le but du TER sera de d´evelopper une application de visualisation 2D de graphes et de leurs propri´et´es. Cette application prendra en entr´ee des topologies de graphes types ou des graphes ayant des propri´et´es particuli`eres mod´elisant des r´eseaux, le tout dans une interface conviviale. Il faudra que cette ap- plication permette la visualisation d’algorithmes de diffusion dans le graphe ainsi g´en´er´e. De plus,

11 Analyse du projet

(12)

cette application devra pouvoir exporter, dans des formats de type PDF par exemple, les r´esultats graphiques obtenus.

2.1.2 Approfondissement

Nous avons dˆu apporter beaucoup de l´eg`eres modifications `a notre logiciel, afin qu’il soit plus fonctionnel et r´eponde au mieux aux attentes des tuteurs.

Nous avons dˆu tout d’abord penser `a la mani`ere d’ajouter une m´ethode de coloration per- sonnalis´ee des ´el´ements du graphe, qui mˆeme si elle n’est pas essentielle, permet `a l’utilisateur de colorer, s’il le souhaite, des parties importantes du graphe.

Une autre fonctionnalit´e qui nous a ´et´e demand´ee par les tuteurs est la possibilit´e de voir les r´esultats des algorithmes directement sur le graphe. Au d´epart, nous pensions afficher les r´esultats de ces algorithmes directement dans le panneau des informations du graphe. Donc, nous avons modifi´e notre fa¸con d’afficher les algorithmes et avons opt´e pour une coloration bien pr´ecise des nœuds et arˆetes concern´es par l’algorithme s´electionn´e.

Au niveau du d´eveloppement en lui-mˆeme, nous avons dˆu modifier notre premi`ere id´ee de l’architecture de base de notre logiciel et avons pr´ef´er´e l’option du pattern MVC (Mod`ele Vue Contrˆo- leur) qui va nous permettre de diviser soigneusement les diff´erentes parties de l’application. Ainsi, le mod`ele sera pour nous le graphe en lui-mˆeme. La vue nous permettra d’afficher directement le graphe graphique `a l’aide du graphe contenu dans le mod`ele et le contrˆoleur nous permettra de faire la balance entre les deux parties cit´ees pr´ec´edemment. C’est-`a-dire que lorsque l’utilisateur effectuera une modification sur le graphe affich´e `a l’´ecran, celle-ci sera r´epercut´ee au niveau du contrˆoleur, afin de mettre `a jour le mod`ele qui servira surtout pour le calcul d’algorithmes. Ainsi, autant le graphe graphique que le graphe contenu dans le mod`ele seront toujours dans un ´etat similaire.

Concernant la g´en´eration de graphes, nous avons dˆu penser `a un nouveau type de g´en´eration diff´erent des g´en´erations al´eatoires ou en sp´ecifiant le nombre de sommets et d’arˆetes. Ces g´en´erations sont les g´en´erations pour des graphes dits «de voisinage ». Elles sont cr´e´ees en sp´ecifiant le nombre d’arˆetes contenues dans le graphe ainsi que la distance maximale de cr´eation d’une arˆete. C’est-`a-dire qu’une arˆete ne peut ˆetre cr´e´ee entre deux nœuds que si la distance entre ces derniers est inf´erieure ou ´egale `a la distance sp´ecifi´ee avant la g´en´eration.

Enfin, pour l’enregistrement des graphes, pour une future r´eutilisation ou modification, nous avons opt´e pour le format GraphML. Ainsi, le graphe est stock´e sous forme de fichier XML et ce fichier contient tout d’abord tous les nœuds du graphe, avec leurs attributs, tels que leurs coordonn´ees sur x et sur y, et il contient ensuite les arˆetes. Chaque arˆete, dans un fichier au format GraphML, contient les num´eros des deux nœuds ´etant ses extr´emit´es ainsi que d’autres caract´eristiques sp´ecifiques comme le poids de l’arˆete par exemple.

Analyse du projet 12 2.1 Le sujet

(13)

2.2 Choix des outils de d´ eveloppement

Pour la cr´eation de l’application, nous avons fait le choix d’utiliser Java, aussi bien pour l’impl´ementation des algorithmes que pour l’interface graphique. Ce choix est dˆu principalement au fait que Java est un langage purement objet, ce qui nous a facilit´e la tˆache pour la cr´eation de classes. Car le d´ecoupage du logiciel en diff´erents modules est indispensable, d`es lors que le projet devient cons´equent. De plus, un autre avantage du d´eveloppement sous Java, est la possibilit´e d’utiliser l’environnement ´Eclipse pour d´evelopper. Cet environnement nous permet une compilation automatique et ainsi d’´eviter les erreurs successives et parfois difficiles `a trouver.

Un autre point fort de Java est la facilit´e avec laquelle nous pouvons cr´eer des interfaces graphiques. C’est-`a-dire que chaque ´el´ement graphique est bien d´efini dans sa propre classe et contient des m´ethodes qui lui sont propres. Ainsi, leur utilisation est simple et efficace. De plus, nous pouvons ajouter des ´ecouteurs d’´ev´enements, de type action, clavier ou souris, `a n’importe quel ´el´ement. Par la suite, ces ´ecouteurs r´eagissent et peuvent effectuer des op´erations sur d’autres composants ou bien sur le composant lui-mˆeme. Enfin, l’un des gros avantages de java, qui peut ´egalement ˆetre un inconv´enient 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 m´elanger plusieurs types d’instances par exemple, contrairement au langage C++, qui fonctionne quant `a lui `a l’aide de pointeurs ou directement dans la m´emoire.

2.3 Mod` ele MVC

Le Mod`ele-Vue-Controlleur (aussi appel´e 3-tier) est l’un des plus c´el`ebres mod`eles du d´e- veloppement logiciel. Il permet en effet d’organiser chaque partie active d’un logiciel afin de rendre la maintenance de l’ensemble plus ais´ee. Ainsi, une application graphique d´evelopp´ee en le suivant pourra voir son interface ´evoluer ind´ependamment de ses autres parties. C’est donc sans surprise, devant d´evelopper notre projet `a plusieurs, que nous avons choisi ce mod`ele qui nous permettrait de ne pas trop risquer de conflit dans notre code.

2.3.1 Architecture g´ en´ erale

Le mod`ele MVC est divis´e en trois couches ayant des interactions tr`es limit´ees, le Mod`ele, la Vue et le Controlleur (voir Figure 2.1).

2.3.1.1 Mod` ele

Le Mod`ele sert d’interface pour l’acc`es aux donn´ees du logiciel. Ainsi, si celui-ci requiert des informations issues d’une base de donn´ees, extraites depuis un fichier ou mˆeme depuis un flux quelconque. C’est au sein de cette partie que le format des donn´ees est garanti et contrˆol´e autant au moment de la lecture qu’au moment de l’´ecriture.

L’architecture de cette partie est tr`es importante, car c’est souvent `a ce niveau que se si- tuent les manipulations les plus coˆuteuses en ressources. Dans le cadre de grosses applications, il est

2.2 Choix des outils 13 Analyse du projet

(14)

Fig. 2.1 – Sch´ema du mod`ele MVC

souhaitable de pratiquer la mise en cache de certaines informations pour ´eviter 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 syst`eme de fenˆetrage, de boites de dialogues, de formulaires, de boutons... Toutefois, la Vue se contente d’afficher les ´el´ements, elle ne doit donc en aucun cas en g´erer les interactions comme les clics.

La Vue est un ´el´ement important du logiciel, car c’est elle qui va rendre le logiciel attrayant et agr´eable `a utiliser ou pas. L’action d’un graphiste ou d’un ergonome dans le cycle de d´eveloppement ne concerne que la Vue.

2.3.1.3 Contrˆ oleur

Le Contrˆoleur est le ciment de l’application. Il est charg´e d’interpr´eter les requˆetes de l’utili- sateur et de les r´epercuter sur la Vue et le Mod`ele. Si un utilisateur clique sur un bouton de l’interface, la Vue va pr´evenir le contrˆoleur qui va r´eagir en cons´equence.

Une application peut contenir plusieurs Contrˆoleurs g´erant chacun une partie des fonction- nalit´es. Dans ce cas, il y aura g´en´eralement un Contrˆoleur principal qui se chargera de transmettre les requˆetes de l’utilisateur au bon Contrˆoleur secondaire (aussi appel´e Helper).

2.3.2 Notre impl´ ementation

Pour des raisons de choix du langage, de choix d’organisation et de manque de temps global, nous avons d´ecid´e de suivre une variante du mod`ele MVC, le mod`ele M-VC (voir Figure 2.2). Celui-ci correspond `a l’impl´ementation faˆıte par Java Swing, librairie que nous utilisons pour cr´eer l’interface graphique du logiciel. Dans cette variante, la Vue et le Contrˆoleur sont plus li´es que dans le mod`ele standard. Ainsi, il est possible de permettre `a la Vue de proc´eder `a de l´eg`eres op´erations qui auraient

Analyse du projet 14 2.3 Mod`ele MVC

(15)

normalement ´et´e transmises au Contrˆoleur. Le Contrˆoleur quant `a lui n’est plus charg´e de s’occuper que des op´erations lourdes.

Fig. 2.2 – Sch´ema de la variante M-VC mod`ele MVC

2.4 Patrons de conception

La plupart des probl`emes conceptuels qui se posent lors de l’analyse d’un projet logiciel sont des probl`emes r´ecurrents qui ont d´ej`a trouv´e une r´eponse g´en´erique applicable dans presque tous les cas. Ces r´eponses g´en´eriques sont appel´ees Patrons de Conception (Design Patterns en anglais).

Cette section vous pr´esente ceux que nous avons utilis´es ou que nous aurions souhait´e utiliser.

2.4.1 Le patron « Singleton »

Un des patrons de conception les plus c´el`ebres est le Singleton. Il r´epond au probl`eme r´ecur- rent de la cr´eation d’une classe ne pouvant ˆetre instanci´ee qu’une unique fois dans toute l’application.

Cette probl´ematique peut concerner autant un acc`es `a une base de donn´ees que l’on souhaiterait ˆetre unique, que la cr´eation de la fenˆetre principale du logiciel.

Le fait de d´eclarer le constructeur comme n’´etant pas public empˆeche l’instanciation de la classe. Or, la m´ethode statique getInstance, faisant partie de la classe, peut acc´eder au constructeur.

Elle peut donc cr´eer une instance de la classe qu’elle gardera en m´emoire dans un attribut statique de la classe. Ainsi, la classe s’auto instanciera une unique fois puisque la m´ethode statique getInstance retournera l’instance sauvegard´ee dans l’attribut instance. Vous trouverez un court exemple de code source Java illustrant l’impl´ementation de ce patron de conception `a la page 16.

Ce patron nous est utile pour la d´efinition de notre Application, de notre Contrˆoleur principal ainsi que de la fenˆetre principale.

2.4 Patrons de conception 15 Analyse du projet

(16)

1 class monSingleton {

2 protected static monSingleton _instance = null;

3

4 /* Constructeur non public */

5 protected monSingleton() {

6 }

7

8 /* Acc`es `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, tr`es proche dans le concept, car ce sont deux patrons de conception cr´eationnels et que tous deux permettent de cr´eer un ou plusieurs objets sans en connaˆıtre la d´efinition compl`ete.

Fig. 2.3 – Sch´ema du design pattern Fabrique

Le patron Fabrique (i.e. Factory) permet d’abstraire l’instanciation d’une ou de plusieurs classes. De cette mani`ere, on rend l’´evolution de l’application plus ais´ee. En effet, si jamais cette instanciation venait `a changer ou si la classe devait ˆetre modifi´ee par sp´ecialisation alors il suffirait de modifier la m´ethode associ´ee au sein de la Factory pour que tout fonctionne sans probl`eme. 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 pr´eoccuper de la mani`ere dont ils sont construits int´erieurement.

Analyse du projet 16 2.4 Patrons de conception

(17)

Fig. 2.4 – Sch´ema du design pattern Monteur

Cela permet de cr´eer facilement une nouvelle classe ayant un fonctionnement interne diff´erent afin d’am´eliorer les capacit´es du logiciel. La figure 2.4 page 17 illustre le fonctionnement de ce patron.

Notre application utilise le patron « Fabrique» pour la gestion des contrˆoleurs des graphes ouverts par le contrˆoleur de l’application ainsi que pour la classe Graphe qui correspond `a la structure de donn´ees des graphes. Chaque contrˆoleur de graphe quant `a lui impl´emente le patron«Monteur », chaque contrˆoleur se parant d’un objet Graphe (structure de donn´ees) et d’un objet GrapheGraphique (vue).

2.4.3 Le patron « Etat ´ »

Ce patron de conception est utilis´e pour mod´eliser des objets ayant un comportement en fonction de leur ´etat. Il peut avantageusement remplacer les structures de contrˆole « switch » ou« if then else » en d´epla¸cant les actions de l’objet concern´e au sein mˆeme de ses ´etats. La figure 2.5 page 17 illustre le fonctionnement de ce patron.

Fig. 2.5 – Sch´ema du design pattern ´Etat

Ce patron a ´et´e utilis´e au sein de notre projet pour g´erer les ´ev´enements gravitant autour

2.4 Patrons de conception 17 Analyse du projet

(18)

de notre classe GrapheGraphique, charg´ee 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’interchangeabilit´e des algorithmes de traitement des donn´ees. En effet, chaque algorithme est encapsul´e dans un objet propre qui impl´emente une interface d´efinie. Ainsi, l’objet ayant besoin d’appliquer un algorithme peut instancier n’importe lequel des objets impl´ementant l’interface et en ex´ecuter une m´ethode. La figure 2.6 page 18 illustre le fonctionnement de ce patron.

Fig. 2.6 – Sch´ema du design pattern Strat´egie

Notre projet impl´emente ce patron pour la mod´elisation des divers algorithmes de manipula- tion des graphes, mais aussi, de mani`ere plus subtile, au sein mˆeme de notre structure de donn´ees de graphes. De cette mani`ere, il est possible d’ajouter des algorithmes ou de nouveaux types de graphes ais´ement.

Analyse du projet 18 2.4 Patrons de conception

(19)

3 D´ eveloppement

3.1 Algorithmes de calculs appliqu´ es 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’ˆetre efficace en toute circonstance. Pour ce faire, nous n’avons pas utilis´e Dijkstra, car celui-ci limite les graphes aux arˆetes positives. L’algorithme de Ford - Bellman nous a sembl´e le mieux convenir pour ce genre de probl´ematique.

bool´een 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 tr`es lent.

On s´electionne cet algorithme dans le menu (voir Figure 3.1 situ´ee page 20) puis on s´elec- tionne deux points sur le graphe et le r´esultat s’affiche en jaune.

19 D´eveloppement

(20)

Fig. 3.1 – Cheminement dans l’interface pour l’utilisation de l’algorithme du Plus Court Chemin

D´eveloppement 20 3.1 Algorithmes de calcul

(21)

3.1.2 Algorithme « Diam` etre »

Le diam`etre 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 Diam`etre

On constate sur la Figure 3.2 situ´ee page 21) que le parcours de tous les points du graphe est bien le plus long de tous les plus courts chemins. Pour d´etecter cela, il analyse s´equentiellement la distance entre les points.

3.2 G´ en´ eration de graphes

Pour ce projet, nous avons impl´ement´e toute une s´erie de g´en´erateurs de graphe. Ainsi, nous retrouvons des graphes particuliers comme le graphe en anneau, le graphe complet, le graphe biparti et le graphe r´egulier. Il y a aussi trois modes al´eatoires.

3.2.1 Anneau

Le graphe en anneau est un graphe simple. Il s’agit d’un anneau dont chaque nœud a un degr´e de deux. Pour son affichage, nous avons utilis´e des calculs bas´es sur le cercle trigonom´etrique afin d’obtenir un cercle.

Voir l’exemple sur la Figure 3.3 situ´ee page 22

3.2 G´en´eration de graphes 21 D´eveloppement

(22)

Fig. 3.3 – G´en´eration 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 trigonom´etrique.

Voir l’exemple sur la Figure 3.4 situ´ee page 22

Fig. 3.4 – G´en´eration d’un graphe Complet

D´eveloppement 22 3.2 G´en´eration de graphes

(23)

3.2.3 Biparti

Le graphe biparti est un graphe qui est divisible distinctement en deux part. Ainsi, nous affichons les deux parties grˆace au cercle trigonom´etrique aussi. Les arrˆetes quand a elles sont tir´ees al´eatoirement entre les sommets, l’utilisateur d´ecide du nombre de sommets et du nombre d’arˆetes au total.

Voir l’exemple sur la Figure 3.5 situ´ee page 23

Fig. 3.5 – G´en´eration d’un graphe Biparti

3.2.4 R´ egulier

Le graphe r´egulier est un des graphes les plus difficiles `a g´en´erer. Il demande de v´erifier le nombre d’arˆetes pour chaque sommet. On choisit le nombre de sommets et le nombre d’arˆetes sortantes, et le graphe se g´en`ere. Le seul probl`eme r´eside dans le fait que la g´en´eration peut durer tr`es longtemps.

Voir l’exemple sur la Figure 3.6 situ´ee page 24

3.2.5 Al´ eatoire

Les graphes al´eatoires sont quant `a eux de trois sortes diff´erentes. Pour le placement de ceux-ci, les points sont mis au hasard sur toute la zone d’affichage.

Il y a le graphe al´eatoire qui obtient un nombre al´eatoire de nœuds et d’arrˆetes. Voir l’exemple sur la Figure 3.7 situ´ee page 24

Ensuite, il y a le graphe al´eatoire o`u l’on choisit le nombre de sommet et d’arˆetes.

3.2 G´en´eration de graphes 23 D´eveloppement

(24)

Fig. 3.6 – G´en´eration d’un graphe R´egulier

Fig. 3.7 – G´en´eration d’un graphe totalement Al´eatoire

Et pour finir le graphe dit social o`u l’on choisit le nombre de sommets et la distance minimale entre les sommets. On g´en`ere ainsi des liens lorsque les nœuds sont `a une distance inf´erieure `a celle d´efinie. Voir l’exemple sur la Figure 3.8 situ´ee page 25

D´eveloppement 24 3.2 G´en´eration de graphes

(25)

Fig. 3.8 – G´en´eration d’un graphe dit « Social »

3.2 G´en´eration de graphes 25 D´eveloppement

(26)

3.3 Interface

3.3.1 Fenˆ etres Principales

3.3.1.1 La classe Fenˆ etre : Fenˆ etre Principale

Fig. 3.9 – Illustration de la Fenˆetre Principale

Cette classe se divise en trois parties distinctes.

Elle contient tout d’abord un menu permettant d’effectuer des actions pr´ecises sur le graphe visualis´e. Ces actions sont de diff´erents 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 cr´e´e ou bien d’en cr´eer un nouveau. Il y a ´egalement les actions agissant directement sur les graphes telles que la g´en´eration de graphes, la visualisation d’algorithmes ou la modification de pond´erations de certaines ou de toutes les arˆetes. Enfin, il y a ´egalement des fonctions pouvant modifier l’affichage du graphe, telles que l’affichage ou non des ´etiquettes. Il en est de mˆeme pour l’affichage des pond´erations.

La seconde partie de cette classe est la barre d’outils. Elle reprend certaines fonctions conte- nues dans le menu et permet un acc`es rapide et efficace `a ces derni`eres.

La derni`ere et la plus importante partie de cette classe est la barre d’onglets, qui permet l’´edition de plusieurs graphes sur la mˆeme fenˆetre. Chaque onglet est en lui-mˆeme une structure que nous d´ecrirons par la suite. Ces onglets s’ajoutent et se ferment facilement `a l’aide des boutons « nouveau »et « fermer » de la barre d’outils.

D´eveloppement 26 3.3 Interface

(27)

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 ´editeur 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 associ´ees sont essentiellement g´er´ees par les contrˆoleurs de notre logiciel. Lors de la s´election de l’item « nouveau » par exemple, nous

´

ecrivons :

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 ´egalement une partie ´Edition contenant les actions undo /redo(d´efaire , 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 g´er´ees dans des classes sp´ecifiques que nous expliquerons et d´etaillerons par la suite.

Nous avons ´egalement un menu Affichage des items permettant de modifier l’apparence de notre graphe actif en affichant ou non la pond´eration sur les arˆetes du graphe ou bien les ´etiquettes sur les sommets. Ces items sont sous forme de case `a cocher afin de pr´eserver la s´election de l’utili- sateur quelque soit le graphe qu’il ´edite. Pour cela, lorsque l’un (ou les deux) item est s´electionn´e, nous actualisons, pour chaque graphe pr´esent dans les onglets, la valeur d’un bool´een d’affichage permettant d’afficher, ou non, les ´etiquettes ou les pond´erations. Nous expliquerons, plus en d´etail, le fonctionnement de cet affichage dans une section ult´erieure.

Nous en venons maintenant au menu Graphes qui est le plus int´eressant, c’est ici que nous pouvons g´en´erer les diff´erents types de graphes d´etaill´es dans la partie 4.3, ou bien encore appliquer les algorithmes cit´es plus haut comme le plus court chemin et le diam`etre. Il est ´egalement possible dans ce mˆeme menu de configurer la pond´eration des arˆetes de mani`ere totalement libre. L’utilisateur peut choisir de pond´erer toutes les arˆetes d’un mˆeme poids qu’il doit au pr´ealable saisir, ou bien alors de g´en´erer des poids al´eatoires compris entre deux extr´emit´es (minimum et maximum) dont il saisira

´

egalement des valeurs au pr´ealable. Parlons plus en d´etail de la g´en´eration des graphes. Dans le cas de la g´en´eration totalement al´eatoire, l’application ne demande rien `a l’utilisateur, en effet, lorsque l’utilisateur s´electionne ce type de g´en´eration, une fonction Random se charge d’attribuer un nombre al´eatoire d’arˆetes (repr´esent´e par un entier al´eatoire k) et de nœuds (repr´esent´e par un entier al´eatoire j) et fait ensuite appel au contrˆoleur de cette mani`ere :

1 ApplicationControlleur.getInstance().get_graphe_actif().

generationAleatoire(k, j);

3.3 Interface 27 D´eveloppement

(28)

Ainsi, apr`es cet appel, le graphe est automatiquement cr´e´e et affich´e dans un nouvel onglet.

Le sous-menu de g´en´eration al´eatoire poss`ede ´egalement deux items permettant d’effectuer une g´en´eration semi-al´eatoire, c’est-`a-dire que l’utilisateur va devoir rentrer un nombre minimum d’informations afin que la g´en´eration soit possible. Le premier item concerne la g´en´eration al´eatoire.

Apr`es avoir sp´ecifi´e le nombre de nœuds et d’arˆetes que devra contenir le nouveau graphe, le graphe se g´en`erera automatiquement dans une nouvelle fenˆetre moyennant bien sˆur un appel pr´ealable au contrˆoleur.

Le second item de g´en´eration semi-automatique est celui de la g´en´eration par distance. Cette g´en´eration s’effectue apr`es que l’utilisateur ait saisi le nombre de nœuds souhait´e, ainsi que la distance minimale, s´eparant deux nœuds, pour cr´eer une arˆete. C’est-`a-dire que ce type de g´en´eration cr´ee des graphes dits« sociaux »ou seuls les nœuds les plus proches sont reli´es.

Nous pouvons ´egalement g´en´erer des graphes particuliers tels que les graphes en « anneau

», les graphes «bi parti», les graphes «complets »et les graphes«r´eguliers». Pour les graphes en

«anneau », ainsi que les «complets », l’utilisateur n’aura qu’`a saisir le nombre de nœuds souhait´e pour le graphe cr´e´e. Tandis que pour la g´en´eration de graphes « bi parti », ainsi que de graphes « r´eguliers », l’utilisateur devra saisir le nombre de nœuds et d’arˆetes souhait´es.

Toutes ces g´en´erations font appel au contrˆoleur du graphe qui cr´eera un nouveau graphe dans un nouvel onglet.

Parlons maintenant des algorithmes. Pour le diam`etre aussi bien que pour le plus court chemin , nous faisons appel aux fonctions Diam`etre() et PlusCourtChemin() du Controller.

3.3.1.3 La barre d’outils

Dans la barre d’outils, nous retrouvons les actions importantes pr´esentes dans le menu, telles que la cr´eation ou la fermeture d’un onglet. On y trouve ´egalement les actions undo /redo que l’on peut ˆetre amen´e `a utiliser assez fr´equemment. Ce sont des raccourcis pour l’utilisateur, lui ´evitant 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 exerc´ees sur cette derni`ere 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 opt´e pour une encapsulation de plusieurs parties d’´edition.

Donc, chaque onglet est compos´e d’une barre d’outils permettant l’´edition d’un graphe, d’un graphe graphique permettant la visualisation du graphe `a proprement dit, d’un panneau d’informations affichant les informations compl´ementaires concernant le graphe affich´e et enfin un onglet poss`ede

´egalement une barre de statut affichant l’´etat du graphe et les indications d’utilisation.

D´eveloppement 28 3.3 Interface

(29)

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 h´erite de JToolBar, c’est la barre d’outils qui g`ere les diverses possibilit´es de modifications ou d’actions sur les graphes g´en´er´es ou cr´e´es 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 v´erifier qu’il n’a pas fait une fausse manipulation par exemple. De plus, cela a pour effet de placer l’´etat courant du graphe dans une position correcte et donc de rendre la modification s´electionn´ee possible.

Cette barre d’outils est compos´ee de JToggleButton qui sont des boutons `a deux ´etats et permettent d’effectuer un bon feedback vis-`a-vis de l’utilisateur, en montrant bien quelle action est s´electionn´ee, puisque le bouton reste enfonc´e lors de la s´election de la commande. Ceci est un plus visuel, en compl´ement 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 s´election d’´el´ements dans notre cas.

Fig. 3.11 – Vue de la barre d’outils d’´edition du graphe

3.3 Interface 29 D´eveloppement

(30)

3.3.1.4.3 L’affichage du graphe

Chaque onglet contient ´egalement un graphe graphique `a afficher. C’est le centre nerveux de chaque onglet. L’affichage et le dessin du graphique ´etant complexe, nous vous pr´esentons plus bas une partie tr`es d´etaill´ee concernant l’affichage des ´el´ements graphiques tels que les nœuds, les arˆetes 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 chiffr´ee du graphe affich´e `a l’´ecran. Il peut fournir plus d’informations lors de g´en´erations particuli`eres de graphes ou bien lors de l’ex´ecution d’un algorithme.

3.3.1.5.1 Informations communes `a tous les graphes

La principale utilit´e du panneau d’informations est la possibilit´e pour l’utilisateur de voir en direct l’´evolution du nombre de nœuds et d’arˆetes au cours de l’´edition et de la modification du graphe. La mise `a jour se fait de mani`ere automatique, et ce, pour toutes les fonctionnalit´es modifiant la structure du graphe, telles que l’ajout, la suppression ou bien les m´ethodes pour d´efaire ou refaire une action.

3.3.1.5.2 Informations suppl´ementaires et ajout

Selon le type de graphe affich´e ou le type de g´en´eration effectu´ee, nous pouvons ajouter d’autres informations directement visibles par l’utilisateur. Par exemple lors de la g´en´eration de graphes« sociaux» on affiche l’information suppl´ementaire nomm´ee «distance pour arˆete » et qui indique la distance minimale entr´ee par l’utilisateur pour permettre la cr´eation d’une arˆete.

Nous pouvons ´egalement ajouter facilement un ´el´ement d’information au panneau, `a l’aide de la m´ethode d’ajout qui prend en param`etre le nom de la nouvelle information, ainsi que sa valeur.

Comme ceci, nous offrons une plus grande flexibilit´e `a notre panneau d’informations.

A noter ´` egalement que le panneau d’informations peut ˆetre masqu´e par l’utilisateur pour un plus grand confort d’utilisation.

D´eveloppement 30 3.3 Interface

(31)

3.3.2 El´ ´ ements Graphiques

3.3.2.1 La classe NœudGraphique

C’est grˆace `a cette classe que nous d´efinissons et affichons les nœuds sur le graphe graphique.

3.3.2.1.1 Caract´eristiques de base d’un nœud graphique

Chaque nœud graphique h´erite de la classe Ellipse2D.Double. Cette classe permet de dessiner facilement des ellipses, et donc dans le cas qui nous concerne, des cercles.

Les caract´eristiques d’un nœud graphique, sont des coordonn´ees x et y qui permettent un placement efficace sur le graphe et une ´etiquette modifiable afin de rep´erer le nœud dans un grand graphe. `A cette ´etiquette est ´egalement associ´e un attribut entier qui permet l’utilisation du nœud dans la g´en´eration de graphes ou dans les algorithmes.

De plus, les nœuds graphiques poss`edent deux valeurs bool´eennes, qui indiquent si le nœud est s´electionn´e 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 poss`ede une autre valeur bool´eenne qui indique si l’´etiquette li´ee au nœud doit ˆetre affich´ee ou non. Ceci peut permettre `a l’utilisateur de masquer l’´etiquette de tous les nœuds si la visibilit´e sur un gros graphe est amoindrie du fait du nombre important d’´etiquettes affich´ees.

Chaque nœud graphique poss`ede ´egalement deux attributs de couleur. Ceux-ci sont impor- tants du fait que l’utilisateur peut modifier la couleur de chaque ´el´ement comme bon lui semble. Le premier attribut est la couleur de base du nœud, qui n’est pas modifiable, mais c’est grˆace `a cet attribut que l’utilisateur peut r´einitialiser 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 ˆetre modifi´ee par l’utilisateur `a l’aide du bouton situ´e dans la barre d’´edition du graphe.

Enfin, les deux derniers attributs du nœud graphique sont des distances, l’une calcul´ee sur l’axe des x et l’autre calcul´ee sur l’axe de y. Ces distances permettent de m´emoriser l’´ecart du nœud sur x et sur y vis-`a-vis de l’un des ´el´ements d’une s´election que l’on a choisi pour le d´eplacement.

3.3.2.1.2 M´ethode de dessin

La m´ethode de dessin utilise, comme le graphe graphique, la classe graphique Graphics2D.

Cette derni`ere permet de dessiner une forme (Shape) qui aura ´et´e d´efinie auparavant pour le nœud.

Pour d´efinir la forme du nœud, nous utilisons directement la m´ethode : setFrame(x, y, 10, 10); ainsi, les directives de dessin du nœud sont stock´ees directement dans la classe du nœud.

Nous avons donc dans notre application des nœuds graphiques de coordonn´ees variables, mais de diam`etre 10. De plus, la couleur du nœud d´epend plus pr´ecis´ement de la valeur des bool´eens qui leur est associ´ee. C’est-`a-dire qu’un nœud sera color´e en bleu turquoise s’il est s´electionn´e ou en violet s’il appartient `a un parcours sp´ecifique `a un algorithme.

3.3 Interface 31 D´eveloppement

(32)

3.3.2.1.3 Sp´ecificit´es

Le fait que la classe NœudGraphique h´erite de la classe Ellipse2D.Double n’est pas anodin, car cette derni`ere impl´ementant l’interface Shape. De ce fait, notre NœudGraphique a acc`es `a une m´ethode vitale pour les interactions directes entre le graphe graphique et l’utilisateur, la m´ethode contains(Point2D p). Cette m´ethode retourne un bool´een qui indique si le nœud graphique contient, ou non, le point p s´electionn´e sur le graphe. De ce fait, nous avons pu tester directement si le nœud est s´electionn´e par l’utilisateur ou non.

Fig. 3.12 – Exemple de nœud graphique normal, s´electionn´e, dans un parcours

3.3.2.2 La classe AreteGraphique

C’est grˆace `a cette classe que nous d´efinissons et affichons les arˆetes graphiques sur le graphe graphique.

3.3.2.2.1 Caract´eristiques de base d’une arˆete graphique

Tout d’abord, il est important de noter que toute arˆete h´erite de la classe graphique Line2D.Double cette classe nous permet de dessiner facilement des lignes en d´efinissant ais´ement leurs caract´eristiques.

Une arˆete graphique n’est en fait qu’un renvoi `a ses deux extr´emit´es. C’est pour quoi chaque arˆete graphique poss`ede deux attributs de type nœud graphique qui repr´esentent son extr´emit´e et son origine. Ainsi, la d´efinition d’une arˆete est plus facile, car ses extr´emit´es sont obligatoirement des nœuds d´ej`a existants sur le graphe. De plus, chaque arˆete poss`ede un attribut de type entier permettant de lui affecter une pond´eration qui lui est propre. Ceci est utile lors de la cr´eation d’un graphe de coˆuts et pour trouver grˆace `a un algorithme le chemin de poids minimum. `A la cr´eation d’une arˆete, son poids est d´efini `a 1, il ne s’affiche donc pas.

Une arˆete graphique, `a l’instar d’un nœud graphique, poss`ede ´egalement deux bool´eens permettant de d´efinir si elle est s´electionn´ee ou bien contenue dans un parcours algorithmique et donc de lui attribuer une couleur sp´ecifique. Celle-ci sera donc verte si elle est s´electionn´ee et orange lorsqu’elle sera contenue dans un parcours algorithmique. Concernant toujours l’affichage d’une arˆete, nous avons int´egr´e de la mˆeme mani`ere que pour les nœuds graphiques un bool´een permettant de masquer ou non la pond´eration de l’arˆete, ainsi que deux attributs de type couleur, l’un stockant la couleur de base d’une arˆete et l’autre stockant la couleur courante et ´etant celle utilis´ee pour l’affichage sur le graphe.

Enfin, chaque arˆete poss`ede quatre attributs de type entier qui permettent de stocker la distance sur x et sur y de chacune de ses extr´emit´es, par rapport `a un point donn´e. Ces distances fonctionnent de la mˆeme mani`ere que pour un nœud graphique et ne sont uniquement pr´esentes

D´eveloppement 32 3.3 Interface

(33)

que pour conserver la bonne distance entre les ´el´ements et pour laisser donc le graphe dans un ´etat coh´erent avant et apr`es le d´eplacement d’une s´election.

3.3.2.2.2 M´ethode de dessin

Afin de dessiner correctement une arˆete dans le graphe graphique, il faut tout d’abord rep´erer les coordonn´ees de ses extr´emit´es. Celles-ci s’obtiennent facilement `a l’aide des nœuds graphiques stock´es comme origine et extr´emit´e de chaque arˆete. Par la suite, comme chaque arˆete h´erite de la classe Line2D.Double, nous pouvons la param´etrer en utilisant la commande :

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

Ainsi, la ligne est param´etr´ee dans la classe et non lors du dessin, ce qui donne la possibilit´e de la dessiner plusieurs fois et de fa¸con identique.

La seconde ´etape du dessin d’une arˆete est l’affichage de la pond´eration de l’arˆete. Nous avons d´ecid´e que si l’arˆete avait une pond´eration de 1, cette derni`ere n’´etait pas affich´ee. Ensuite, un probl`eme d’affichage est survenu lors du d´eplacement de l’une des extr´emit´es de l’arˆete. Nous avons remarqu´e que selon les coordonn´ees de ses extr´emit´es, le poids s’affichait directement sur l’arˆete, ce qui empˆechait 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’arˆete poss`ede des coordonn´ees sur x et sur y qui diff`erent toutes deux par rapport `a celles de l’extr´emit´e, nous avons fait en sorte que le poids s’affiche au-dessus de l’arˆete. Concernant les lignes, verticales ou horizontales, nous avons opt´e pour d´ecaler la valeur de la pond´eration et ainsi ´eviter tout chevauchement. (cf. Figure 3.13).

Fig. 3.13 – Positionnement de la pond´eration d’une arˆete graphique

Fig. 3.14 – Exemple d’arˆete normale, s´electionn´ee, contenue dans un parcours 3.3.2.2.3 Sp´ecificit´es

Outre le fait de la d´efinition dans la classe, des caract´eristiques de l’arˆete, un autre avantage de l’h´eritage de la classe Line2D.Double est l’h´eritage de la m´ethode contains(Point2D p). Cette derni`ere v´erifie si la forme g´eom´etrique (Shape) poss`ede, ou non, le point p dans son dessin. Le seul

3.3 Interface 33 D´eveloppement

(34)

probl`eme qui est tr`es vite apparu est que la m´ethode contains(Point2D p) de la classe Line2D.Double ne fonctionne pas, car v´erifier si une ligne, qui est uniquement une succession de points, contient un point est difficile. Il nous a fallu donc red´efinir la m´ethode contains(Point2D p) et utiliser une autre m´ethode de la classe Line2D.Double qui est la m´ethode ptSegDist(Point2D p) et qui retourne la distance en pixels, du point p au segment pour lequel est appel´ee 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 d´efini une distance de clic inf´erieure ou ´egale `a 3, afin que la s´election d’une arˆete se fasse ais´ement et que si plusieurs arˆetes sont proches, elles ne soient pas s´electionn´ees toutes les deux en mˆeme temps du fait d’une sensibilit´e trop importante.

3.3.2.3 La classe GrapheGraphique

C’est la classe principale d’affichage du graphe. Elle h´erite de la classe JPanel, qui d´ecrit un panneau. Ce panneau est modifiable et on peut donc dessiner dessus. C’est cette m´ethode que nous allons utiliser pour afficher le graphe.

3.3.2.3.1 El´ements de base

Cette classe contient deux listes, qui sont la liste de nœuds graphiques, ainsi que la liste d’arˆetes graphiques qui vont ˆetre affich´ees `a l’´ecran. La simple modification de ces listes entraine directement une modification de l’affichage du graphe.

De plus, nous avons impl´ement´e notre classe GrapheGraphique sous forme de machine `a ´etats, grˆace au design pattern state. C’est-`a-dire que l’´etat courant du graphe graphique va correspondre

`

a une de ses modifications. Pour cela nous avons d´efini une classe abstraite EtatGraphe qui doit impl´ementer les ´ecouteurs d’´ev´enements souris qui sont MouseListener et MouseMotionListener, qui

´ecoutent respectivement les clics de souris et les mouvements de souris. Pour le moment toutes les m´ethodes issues des ´ecouteurs d’´ev´enements sont vides dans la classe EtatGraphe. Ensuite nous avons dˆu cr´eer une classe par ´etat de modification des graphes. Chacune de ces classes h´erite de la classe EtatGraphe. Ces ´etats ne red´efinissent que les ´ecouteurs d’´ev´enements souris dont ils ont besoin. Et donc, lorsque le graphe graphique sera dans un ´etat qui effectue une tˆache lors d’un relˆachement de bouton souris, une action effective sera effectu´ee sur le graphe. D’autre part, certains modes de modification du graphe doivent utiliser deux ´etats, par exemple la cr´eation d’arˆetes ou bien le d´eplacement de sommets, d’arˆetes ou d’une s´election. Car lors de la cr´eation de la cr´eation d’une arˆete, par exemple, nous commen¸cons par modifier l’´etat de notre machine `a l’aide d’une nouvelle instance de la classe DebutCr´eationArete(GrapheGraphique g), qui permet de s´electionner le nœud d’origine de l’arˆete et, lorsque ce dernier est s´electionn´e, nous modifions l’´etat courant du GrapheGraphique

`

a l’aide d’une nouvelle instance de la classe SuiteCreationArete(GrapheGraphique g), qui permet de

D´eveloppement 34 3.3 Interface

(35)

s´electionner le nœud extr´emit´e de la nouvelle arˆete et de la cr´eer par la suite.

Voir la Figure 4.2 en annexe page 47 repr´esentant le diagramme de classes de la gestion du pattern ´etat pour le graphe graphique.

Liste des diff´erents ´etats possibles du graphe :

– Attente : L’´etat de base ou l’on ne peut pas modifier le graphe.

– ApplicationCouleur : Cet ´etat, lorsqu’il est actif, permet d’appliquer une couleur s´elec- tionn´ee `a n’importe quel ´el´ement du graphe.

– Cr´eationSommet : Cet ´etat permet l’ajout d’un sommet lors d’un clic souris sur le panneau du graphe.

– DebutCreationArete : Permet de passer `a la premi`ere ´etape de la cr´eation d’une arˆete, c’est-`a-dire la s´election de l’origine de cette derni`ere.

– SuiteCreationArete : Permet de s´electionner l’extr´emit´e de la nouvelle arˆete et ainsi de la cr´eer.

– DebutDeplacement : Permet de s´electionner un ´el´ement du graphe que l’on souhaite d´eplacer, cela peut ˆetre un sommet ou une arˆete.

– SuiteDeplacement: Dans cet ´etat, on peut effectuer le d´eplacement effectif de l’´el´ement souhait´e.

– DebutDeplacementSelection : Cet ´etat permet de cliquer sur l’un des ´el´ements de l’ensemble des ´el´ements s´electionn´es.

– SuiteDeplacementSelection : Permet de faire le d´eplacement effectif de toute la s´elec- tion, `a partir de l’´el´ement cliqu´e dans l’´etat « DebutDeplacementSelection ».

– Selection : Cet ´etat permet de s´electionner un ensemble d’´el´ements du graphe en vue d’un d´eplacement ou d’une suppression future.

– SelectionSommetAlgo : Permet de s´electionner deux sommets du graphe afin d’appli- quer un algorithme entre les deux sommets concern´es.

– EtiquetageSommet: Permet de modifier l’´etiquette d’un sommet«cliqu´e»au pr´ealable par l’utilisateur.

– EtiquetageArete : Permet de modifier la pond´eration d’une arˆete apr`es que celle-ci ait

´

et´e «cliqu´ee» par l’utilisateur

3.3 Interface 35 D´eveloppement

(36)

3.3.2.3.2 La m´ethode de dessin du GrapheGraphique

Le graphe graphique ´etant une sp´ecification de JPanel, il poss`ede par h´eritage une m´ethode paintComponent. Cette m´ethode permet de dessiner sur le panneau, grˆace `a des classes graphiques telles que Graphics ou Graphics2D. Dans notre cas, nous avons utilis´e la classe Graphics2D qui offre de plus grandes possibilit´es concernant le dessin. De plus, nous pouvons appliquer des effets concernant le rendu final d’affichage, beaucoup plus cons´equents qu’avec Graphics.

Pour dessiner concr`etement un graphe, dans notre m´ethode 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 m´ethode de dessin en lui sp´ecifiant le contexte graphique du graphe, ainsi le nœud est dessin´e sur le panneau du graphe. Par la suite, nous faisons de mˆeme pour la liste des arˆetes du graphe.

3.3.2.3.3 Ecouteurs d’´ev´enements souris du GrapheGraphique

Le graphe graphique est impl´ement´e de sorte `a ´ecouter les ´ev´enements souris exerc´es sur lui-mˆeme. Ces ´ev´enements sont de deux types : les actions sur les boutons de souris (bouton press´e, bouton relˆach´e) et les mouvements de souris (souris d´eplac´ee avec le bouton press´e).

Comme nous l’avons dit pr´ec´edemment, ces ´ecouteurs ne fonctionnent que si la classe Gra- pheGraphique est dans un ´etat bien pr´ecis. C’est-`a-dire que les m´ethodes d’ajout de sommet ou d’arˆete, les m´ethodes d’´etiquetage de nœuds ou d’arˆetes, celles de s´election ou bien celle d’appli- cation de couleur ne fonctionneront que si la machine est dans l’´etat leur correspondant et qu’un

´ev`enement de type« bouton relˆach´e » (mouseReleased) est exerc´e sur le graphe graphique. Car ces m´ethodes ne sont d´efinies que pour des ´etats du graphe bien pr´ecis.

Les ´etats pour lesquels l’´ev´enement « bouton de souris press´e » (mousePressed) est d´efini, sont principalement li´es au d´ebut de l’un des divers d´eplacements possibles sur le graphe graphique, tels que le d´eplacement de sommets, d’arˆetes ou d’une s´election compl`ete. Lorsque la souris est press´ee sur l’un des ´el´ements et que l’´etat courant du graphe correspond `a un d´eplacement possible, des calculs sont effectu´es selon le type d’´el´ement `a d´eplacer. Ceci permet de garder le graphe dans un ´etat coh´erent et correspondant `a la volont´e de l’utilisateur.

Enfin les ´etats pour lesquels l’´ev´enement « souris d´eplac´ee avec le bouton press´e» (mouse- Dragged) est d´efini, correspondent uniquement `a la suite de l’un des d´eplacements possibles sur le graphe. Apr`es que les calculs aient ´et´e effectu´es lors de l’appui sur le bouton, on actualise la position de l’´el´ement ou de la s´election d´eplac´e, `a l’aide des coordonn´ees du nouveau point o`u se situe le curseur, et des calculs effectu´es dans le mousePressed.

Quel que soit l’´ecouteur utilis´e, nous utilisons les coordonn´ees du point o`u se trouve le curseur pour effectuer nos actions sur le graphe.

D´eveloppement 36 3.3 Interface

(37)

3.3.3 Les boites de dialogues

Dans notre application, l’utilisateur a enti`erement le choix en ce qui concerne les types de graphes qu’il d´esire g´en´erer, et plus particuli`erement sur le nombre de sommets et d’arˆetes ainsi que de leur pond´eration. C’est pour cela que les boites de dialogues sont tr`es utiles ici. Nous avons donc int´egr´e au menu Graphes des boites de dialogues qui permettent `a l’utilisateur d’entrer le nombre de nœuds et d’arˆetes, pour donner ainsi `a notre outil un syst`eme o`u le libre choix de la g´en´eration est possible.

3.3.3.1 Les boites de dialogue pr´ ed´ efinies

Le premier type de boites de dialogue que nous avons utilis´ees sont les boites de dialogue pr´ed´efinies dans Java. Ces boites de dialogue sont d´efinies 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 derni`ere 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 cr´ e´ ees

Pour les demandes de saisies plus complexes et de plus d’une donn´ee, nous avons cr´e´e des boites de dialogues sp´ecifiques. 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 g´en´eralement utilis´ees pour les g´en´erations demandant le nombre de nœuds et le nombre d’arˆetes ou celle demandant le nombre de nœuds et la distance maximale de cr´eation d’une arˆete entre deux nœuds.

Fig. 3.15 – Exemple de boites de dialogue de saisie simple et complexe

3.3 Interface 37 D´eveloppement

(38)

3.3.4 Outils d’´ edition et de modification suppl´ e- mentaires

3.3.4.1 Gestion du undo /redo

Pour se«souvenir»d’une s´equence de transactions, et pouvoir revenir en arri`ere arbitraire- ment loin, on utilise un gestionnaire de transactions(UndoManager). Ainsi dans la classe GrapheGra- phique nous avons d´eclar´e un undoManager qui sera aliment´e lorsqu’une action sur la barre d’outils EditionGraphe sera effectu´ee.

L’alimentation de ce vecteur se fait `a l’aide de la m´ethode addEdit(UndoableEdit Edit) ; de ce fait pour chaque action pouvant ˆetre effectu´ee par l’utilisateur, une classe Edit qui h´erite de AbstractUndoableEdit lui est associ´ee. C’est cette classe qui contient l’action d´efaire et refaire lui correspondant.

Vous trouverez en annexe, `a la page 46, la Figure 4.1 repr´esentant le diagramme des classes associ´ees `a cet outil.

3.4 Sauvegarde et chargement

Pour la sauvegarde, nous avons cherch´e plusieurs structures de fichiers diff´erentes. Ainsi, avons d´ecider d’adopter le format XML et plus pr´ecis´ement le formalisme : graphML.

Nous avons donc trouv´e 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 num´ero, 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 l`a o`u il les a plac´es. Pour les arˆetes, nous sauvegardons le poids, la source et la destination. Vous trouverez un exemple de fichier XML formatt´e par notre application ) la page suivante.

Le chargement quant `a lui ouvre le fichier et assigne les points et les arˆetes dans un nouveau graphe.

3.5 Exportation

L’une des demandes de nos tuteurs ´etant la possibilit´e d’exploiter les graphes cr´e´es par le logiciel, nous avons mis en place la possibilit´e `a l’utilisateur d’exporter son travail afin de l’int´egrer 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 situ´ees page 40

Cette partie de l’application a ´et´e con¸cue pour int´egrer facilement de nouveaux formats d’export comme LATEX ou DOT par exemple. Toutefois, pour des raisons de temps nous n’avons impl´ement´e que l’export en JPG pour le moment.

D´eveloppement 38 3.4 Sauvegarde et chargement

(39)

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

13 <data key="posX">276</data>

14 <data key="posY">83</data>

15 </node>

16 <node id="2">

17 <data key="posX">293</data>

18 <data key="posY">239</data>

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 D´eveloppement

(40)

Fig. 3.16 – Exemple d’export au format JPG

Fig. 3.17 – Autre exemple d’export au format JPG

D´eveloppement 40 3.5 Exportation

(41)

4 Proc´ edure de tests

Troisi`eme et derni`ere partie du d´eveloppement de notre projet, la p´eriode de tests a ´et´e d´ecoup´ee en trois phases. De cette mani`ere, il nous a ´et´e possible de cerner les besoins et les objectifs de chacune de ces trois phases plus simplement que s’il avait ´et´e n´ecessaire de le faire de mani`ere globale. Ce chapitre suit le mˆeme partitionnement que cette ´etape essentielle.

4.1 Tests alpha

Cette premi`ere ´etape des tests s’est d´eroul´ee tout au long de la vie de notre projet. En effet, puisque nous avons adopt´e un d´eveloppement it´eratif, nous avons pu reproduire ces tests pour chaque nouveaut´e int´egr´ee au logiciel, en prenant garde `a conserver une certaine r´etro compatibilit´e. Les tests alpha se sont donc faits enti`erement en interne et nous ont permis de d´ecouvrir et de corriger des bugs au niveau modulaire. Le projet n’ayant couru que sur une quinzaine de semaines, nous n’avons r´ealis´e que trois it´erations et donc trois phases de tests alpha.

4.2 Tests bˆ eta

La seconde ´etape des tests n’a ´et´e r´ealis´ee qu’apr`es l’arrˆet du d´eveloppement de nouvelles fonctionnalit´es et apr`es la derni`ere phase de tests alpha. Elle s’est d´eroul´ee avec un petit groupe de personnes qui ont accept´e d’utiliser l’application comme s’ils ´etaient en situation r´eelle. Aid´es 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’exp´erience a ´et´e fructueuse puisque pas moins de sept vuln´erabilit´es ont ´et´e d´ecouvertes par ce biais.

4.3 Tests d’ergonomie

La derni`ere phase de tests a d´ebut´e apr`es toutes les autres puisqu’il est n´ecessaire 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 demand´e de r´ealiser des tˆaches. L’observateur note le temps que passe le testeur `a tenter d’y parvenir ainsi que l’´etat d’esprit apparent du testeur. Le but est de distinguer les tˆaches qui ne parviennent pas `a ˆetre effectu´ees de mani`ere rapide, efficace et agr´eable.

41 Proc´edure de tests

(42)
(43)

Perspectives et conclusion

Perspectives

Par manque de temps, nous n’avons pas pu impl´ementer toutes les fonctions et outils que nous avions pr´evus.

L’une des fonctionnalit´es qui peut ˆetre int´eressante `a ajouter `a notre application est le copier- coller. C’est-`a-dire que l’utilisateur pourrait s´electionner un ensemble d’´el´ements du graphe et aurait la possibilit´e soit de les dupliquer, soit de les couper, sur le mˆeme graphe ou bien sur le graphe contenu dans un autre onglet.

De plus, pour faciliter la s´election multiple d’´el´ements du graphe, nous aurions pu ajouter un rectangle de s´election, dit aussi « rectangle ´elastique ». Ce rectangle serait apparu directement dans la fenˆetre d’affichage du graphe lors d’un clic souris dans une partie ne contenant pas d’´el´ement.

Sa taille varierait selon le d´eplacement de la souris en maintenant le bouton cliqu´e. Ceci aurait pour effet de s´electionner automatiquement les ´el´ements contenus dans ce rectangle ou bien les ´el´ements

´

etant en partie en contact avec le rectangle. Et finalement, celui-ci disparaitrait d`es que l’utilisateur aurait relˆach´e le bouton souris.

Enfin, nous avions ´eventuellement envisag´e d’externaliser un certain nombre de classes dans des fichiers JAR afin de cr´eer un syst`eme de plug-ins dynamiques. Le d´eveloppement de cette fonc- tionnalit´e a ´et´e abandonn´e 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 cr´eation d’un logiciel de visualisation de graphes requiert une bonne ´etude pr´ealable, afin de r´epondre facilement aux attentes des utilisateurs. C’est pourquoi, pour l’´elaboration de notre projet, il nous a fallu trouver une interface correcte et souple. Apr`es cette ´etape, 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 compr´ehensible par l’utilisateur. Les directives de nos tuteurs nous ont ´egalement beaucoup aid´es, car le monde des graphes est assez vaste et l’on peut vite s’´eloigner du but premier de l’application.

Ce projet nous aura appris comment rassembler, de la mani`ere la plus efficace possible, les algorithmes de graphes qui traitent g´en´eralement des donn´ees difficilement repr´esentables `a l’´ecran,

Perspectives 43 Perspectives et conclusion

(44)

tels que des listes d’adjacence, par exemple, avec des ´el´ements graphiques sens´es repr´esenter les graphes. Il nous aura ´egalement permis de nous familiariser avec les techniques d’IHM permettant de cr´eer une grande interactivit´e au niveau du logiciel.

Grˆace `a ce projet, nous avons pu nous familiariser au travail en groupe et `a la r´epartition des tˆaches entre les membres de ce dernier. Nous avons dˆu beaucoup discuter afin de lier d’une fa¸con correcte et efficace les diff´erents modules du logiciel. Nous avons ´egalement eu l’opportunit´e d’´etudier diff´erents patrons de conception, qui nous ont permis de rendre, au final, notre application plus modulaire.

Au final, ce projet est int´eressant 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

(45)
(46)

Annexes

4.4 Diagrammes

Fig. 4.1 – Diagramme UML des classes utilis´ees pour l’impl´ementation de l’undo/redo

Perspectives et conclusion 46 4.4 Diagrammes

(47)

Fig. 4.2 – Diagramme de classe de gestion du patron de conception Etat

4.4 Diagrammes 47 Perspectives et conclusion

(48)

Table des figures

2.1 Sch´ema du mod`ele MVC . . . 14

2.2 Sch´ema de la variante M-VC mod`ele MVC . . . 15

2.3 Sch´ema du design pattern Fabrique . . . 16

2.4 Sch´ema du design pattern Monteur . . . 17

2.5 Sch´ema du design pattern ´Etat . . . 17

2.6 Sch´ema du design pattern Strat´egie . . . 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 Diam`etre . . . 21

3.3 G´en´eration d’un graphe en Anneau . . . 22

3.4 G´en´eration d’un graphe Complet . . . 22

3.5 G´en´eration d’un graphe Biparti . . . 23

3.6 G´en´eration d’un graphe R´egulier . . . 24

3.7 G´en´eration d’un graphe totalement Al´eatoire . . . 24

3.8 G´en´eration d’un graphe dit «Social » . . . 25

3.9 Illustration de la Fenˆetre 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’´edition du graphe . . . 29

3.12 Exemple de nœud graphique normal, s´electionn´e, dans un parcours . . . 32

3.13 Positionnement de la pond´eration d’une arˆete graphique . . . 33

3.14 Exemple d’arˆete normale, s´electionn´ee, 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 utilis´ees pour l’impl´ementation de l’undo/redo . . . 46

4.2 Diagramme de classe de gestion du patron de conception Etat . . . 47

Annexes 48 Liste des Figures

(49)

Bibliographie

[1] Lacomme, Philippe and Prins, Christian and Sevaux, Marc, Algorithmes de graphes, Eyrolles, seconde ´edition 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, andJ. Vlissides, Design patterns: elements of reusable object-oriented software, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 1995.

Bibliographie 49 Annexes

Figure

Updating...

Références

Sujets connexes :