Situation:
Dans le cadre du Master 1ère année d'informatique à l'université de Montpellier-II, il nous est demandé de former des groupes de quatre, de choisir un sujet parmi une quarantaine, puis, en quatre mois, de réaliser du mieux possible, ce qui est demandé.
Le travail fourni doit être présenté lors d'une soutenance en juin 2007, le présent rapport est remis le 18 mai 2007, et sera lu par le jury avant la soutenance.
La note obtenue comptera pour 12 ECTS.
Travail demandé :
Réaliser une application qui permet de visionner un 2D et en 3D la résolution d'un système d'inéquations, en utilisant la méthode du simplexe. L'application doit résoudre et donner les étapes intermédiaires de manière lisible.
Nous tenons à remercier notre responsable de TER Monsieur Rodolphe GIROUDEAU, professeur à l’UFR des Sciences de Montpellier, pour l’aide précieuse qu’il nous a apportée tout au long de la réalisation de ce TER.
Remerciements
API : Interface de programmation publique. Bibliothèque de fonctions destinées à être utilisées par les programmeurs dans leurs applications. Ces fonctions facilitent l'écriture des programmes en fournissant des routines (procédures) pour gérer des éléments particuliers (affichage, pilotage de périphériques…).
Clipping
: Le clipping consiste à définir une zone de dessin réduite dans la zone de dessin globale. Les actions des pinceaux sont alors limitées à cette zone, ce qui a pour effet d'accélérer le rendu graphique.
Double buffering : Le double buffering consiste à faire le rendu graphique dans une zone de mémoire, et dans un deuxième temps d'afficher a l'écran l'image complète.
Java : Java est une technologie composée d'un langage de programmation orienté objet et d'un environnement d'exécution. Le concept Java est basé sur le langage Java, la machine virtuelle Java et l'API Java (ces deux derniers composants forment l'environnement d'exécution).
Javadoc : Outil pour la documentation d'API, livré en standard avec le SDK Java. Javadoc utilise des balises au format spécial de commentaire pour générer la documentation des packages, des classes, des méthodes… d'une application, sous forme de pages HTML.
JDK : Java Development Kit. Environnement de développement de Sun permettant de produire du code Java et servant de référence. La version 1.1 est sortie en 1997 et la version 1.8 est prévue.
MVC : Organisation d'une application interactive en trois modules séparés : un pour le modèle de l'application accompagné de sa représentation des données ainsi que la logique du métier, un second pour les vues qui présentent les données à l'utilisateur et recueillent ses entrées, et le troisième pour un contrôleur qui achemine les requêtes et les flux de contrôle.
SDK : Ensemble d’outils et de bibliothèques de routines permettant de développer des programmes pour un environnement particulier.
Simplexe : Algorithme permettant de résoudre les problèmes de programmation linéaire. Cet algorithme a été proposé par Dantzig.
UML : Unified Modeling Language. Langage normalisé par l’OMG début 1997, permettant de décrire une application en fonction des méthodes objets avec lesquelles elle a été construite.
XML : Extensible Markup Language. Langage de balisage extensible, standard du World Wide Web Consortium permettant de créer des langages balisés spécialisés. Il est suffisamment général pour que les langages basés sur XML puissent être utilisés pour décrire toutes sortes de données et de textes. Il s'agit donc partiellement d'un format de données.
1. Introduction... 6
2. Cahier des charges... 7
2.1 Généralités...7
2.2 Emploi du temps...8
2.3 Répartition des tâches...9
3. Matériels et méthodes...10
3.1 Outils de conception... 10
3.2 Outils complémentaires... 11
4. Implémentation de l’algorithme du simplexe...12
4.1 L’algorithme du simplexe... 12
4.2 Le solveur GLPK « GNU LINEAR PROGRAMMING KIT »... 13
4.3 Notre implémentation de l’algorithme du simplexe...14
4.4 Les limites de l’algorithme du simplexe... 15
4.4.1 Description du groupe 1... 15
4.4.2 Description du groupe 2... 16
4.4.3 Description du groupe 3... 17
5. Tracé des courbes... 18
5.1 Principes... 18
5.2 Le reste du développement...18
5.3 Représentation 3D... 19
6. Système de plugins... 20
6.1 Principes... 20
6.2 Les fonctionnalités... 21
Tables des matières
7. Résultats... 22
7.1 Zone de saisie... 23
7.2 Zone de représentation de l’algorithme...24
7.3 Zone des matrices... 25
7.4 La barre d’outils... 28
7.5 Fichier contenant un système... 29
8 Discussion...30
8.1 Objectifs atteints...30
8.2 Appréciation critique de l’application... 30
8.3 Compétences acquises... 31
9. Conclusion...32
10. Annexes : diagrammes UML...33
10.1 UML simplifié de la Zone 3... 33
10.2 UML simplifié de la Zone 2... 34
11. Webographie...35
Dans le cadre de notre première année de Master informatique à l’UFR des Sciences de Montpellier, il nous est demandé de réaliser un Travail d’Enseignement et de Recherche sur une durée de dix-huit semaines. Ce projet a pour but de mettre en œuvre concrètement tous les savoirs théoriques acquis pendant notre formation.
La méthode du simplexe est une méthode très utilisée dans l'industrie afin d'obtenir la solution optimale d'un problème modélisé par un programme linéaire. Le but est de développer une application de visualisation en 2D et 3D de la succession des étapes issues de la méthode du simplexe afin de voir le déplacement sur l'enveloppe convexe des solutions intermédiaires.
Tout d’abord nous abordons les outils et les ressources utilisés, puis l’analyse des données et l’analyse des traitements, des activités à gérer. Ensuite, nous développons les résultats obtenus de notre application. Enfin, nous finissons par une discussion sur tout le travail que nous avons accompli.
1. Introduction
2.1 Généralités
L’objectif de ce projet est de réaliser une application permettant de visualiser la représentation graphique de l’algorithme du simplexe. Cette représentation doit être réalisée en deux dimensions et en trois dimensions. Elle doit résoudre graphiquement, si c’est possible, les inéquations du simplexe et proposer les solutions optimales.
Egalement, cette application doit être multi plates-formes, c’est-à-dire qu’elle doit pouvoir tourner sur n’importe quel système d’exploitation (Windows, Unix et Mac OS) sans avoir à modifier le code.
L’interface prévue pour la visualisation est divisée en trois parties. Elle comprend une zone où l’utilisateur pourra saisir les inéquations et interagir avec les paramètres de calcul, une zone permettant la visualisation des matrices et une zone représentant graphiquement l’algorithme.
Il faut réaliser cette application de telle sorte que son démarrage se fasse en un minimum de temps. De plus, l’interface doit être ergonomique afin qu’une personne non informaticienne puisse s’en servir sans aucune difficulté.
Le code écrit de l’application doit être facile à lire et à comprendre et doit être correctement commenté. En effet, il est prévu que notre application puisse être améliorée et modifiée dans le cadre de futurs projets.
2. Cahier des charges
2.2 Emploi du temps
L'emploi du temps prévu dans le cahier des charges n'a pas été suivi en intégralité. En effet, dès l'abandon du système de plugins, nous avons adopté un développement classique, en utilisant le serveur Subversion de code.google.com.
Voici l'emploi du temps prévu dans le cahier des charges:
Or, pendant les vacances universitaires de Pâques (entre le premier et le 15 avril), nous avons abandonné la partie ''modularité''.
Nous avons donc gardé le coeur applicatif du logiciel et avons créé une nouvelle enveloppe statique, plus simple, et plus rapide en terme de temps de développement.
L'intégration des modules est remplacée par l'intégration des fonctionnalités dans la nouvelle enveloppe. Le reste est inchangé et dans l'ensemble, nous avons pu garantir une cohérence avec l'emploi du temps prévu.
Cependant, il y a eu des inquiétudes. En effet, avec le changement crucial effectif (qui a sans doute sauvé le développement), l'interface utilisateur a été obtenue au dernier moment. Or, s’il y avait eu des incohérences au niveau de la liaison ''coeur-interface'', la phase de test aurait été retardée.
Heureusement tout s'est passé sans problèmes majeurs. Nous pouvons fournir un logiciel, certes incomplet par rapport au cahier des charges initial, mais fonctionnel et visuellement finalisé.
2.3 Répartition des tâches
Notre groupe est composé de quatre étudiants, l'un d'entre nous s'occupe du moteur (génération des matrices, et zone d'affichage), un autre de l'interface utilisateur (les menus, et l'aménagement des zones, le lancement des opérations, ...), le troisième des opérations sur l'environnement extérieur (les fichiers, les exportations, et l'architecture du rapport), enfin le quatrième de l'affichage du résultat sous forme d'équation (et les opérations de zoom).
Durant le premier mois, nous suivons le tableau de répartition des tâches du cahier des charges:
3.1 Outils de conception
Pour la conception de notre application, il nous a été demandé d’utiliser un langage portable pour les différents systèmes d’exploitation. Nous avons eu le choix entre deux langages de programmation : le Java et le Python.
Le Python est un langage interprété. Ses qualités sont la facilité de mise en œuvre et la portabilité des programmes, pouvant la plupart du temps être lancés sans modification sur toute plate-forme où fonctionne l'interpréteur. En revanche, il est plus exigeant en ressources et moins rapide à l’exécution.
Nous avons donc choisi la technologie Java car, multi plates-formes, elle permet une adaptation parfaite à tous les systèmes d’exploitation sur lesquels l’application sera déployée. Nous éviterons ainsi des problèmes de compatibilité non négligeables. En outre, nous avons appris à nous servir de ce langage pendant nos études supérieures, raison suffisante délaisser le Python qui aurait nécessité un temps d’adaptation si nous l’avions choisi.
Les classes Java sont développées avec la plate-forme Eclipse. Cet outil permet un développement facile et rapide grâce notamment à un explorateur de package, une console, une fenêtre de débogage ainsi qu’une barre de repérage interactive des erreurs et des avertissements présents dans un fichier.
Il permet aussi de générer de façon claire une Javadoc, essentielle lors d’un développement dans lequel interviennent plusieurs personnes. En plus du développement Java, Eclipse permet de s’appuyer sur un socle applicatif.
Nous utiliserons la version Java JDK 1.5 et la dernière version Java JDK 1.6 dont les noms de code sont Tiger et Mustang.
3. Matériels et méthodes
3.2 Outils complémentaires
La mise en page et la rédaction de ce rapport ont été réalisées avec deux logiciels de traitement de texte : Word 2003, utilisant comme système d’exploitation la version XP professionnelle de Windows et Open Office 2.0 sur les plates-formes Linux.
Pour que le groupe ait accès à l’application sans être contraint d’envoyer le projet par courriels à chaque mise à jour, nous avons utilisé le logiciel de gestion de version Subversion (SVN en abrégé). De plus, nous avons installé TortoiseSVN qui, à la manière d’un « montage de fichier asynchrone » permet d’accéder et d’effectuer facilement des vérifications, des mises jour et des tests.
TortoiseSVN s’intègre à Eclipse, les packages ayant subi des modifications sont signalés et les actions sont disponibles d’un clic droit sur le projet dans Eclipse.
Certaines icônes ont été créées avec le logiciel libre The Gimp, un excellent éditeur d'images multi plates-formes.
4.1 L’algorithme du simplexe
Cet algorithme, réalisé par George Dantzig, permet de résoudre efficacement les problèmes de programmation linéaire, bien évidemment quand ces derniers admettent une solution. Ainsi, étant donné un ensemble d'inégalités linéaires sur n variables réelles, l'algorithme permet de trouver la solution optimale pour une fonction objective, qui est elle aussi linéaire (l'algorithme fonctionne encore quand la fonction est croissante en chacune de n variables).
On définit le polytope comme l'espace convexe contenant l'ensemble des solutions réalisables, dont les arêtes sont les inéquations de contraintes et les sommets les intersections entre inéquations de contrainte.
Polytope d'un problème de programmation linéaire (source : Wikipedia)
4. Implémentation de l’algorithme du simplexe
L'algorithme, partant d'un point aléatoire du polytope (tous les points du polytope sont réalisables) appelé solution de base réalisable, progresse à chaque itération vers le point optimal en choisissant parmi les voisins du sommet courant un des sommets qui augmente (ou diminue, selon le sens de l'optimisation) la valeur de la fonction objective. Lorsqu’il n’y a plus de voisin vérifiant cette condition, l'algorithme est terminé et l'on a trouvé le point optimal.
Lorsque plusieurs voisins différents optimisent la fonction objective, un choix doit être effectué entre eux et la règle de sélection qui permet de trancher est appelée règle de pivotage. Le choix de cette règle est capital afin d'assurer l'efficacité de l'algorithme.
L'algorithme se termine nécessairement car le nombre de sommets du polytope est fini. Un nombre fini d'inéquations de contraintes implique un nombre fini d'intersections entre ces mêmes inéquations si les inéquations sont distinctes deux à deux. De plus, il n'y a pas de boucle dans le parcours (chaque arête parcourue augmente la fonction objective), et il n'existe pas de maximum local qui ne soit pas un maximal global.
Au final l'algorithme se termine en un sommet du polytope qui constitue le sommet optimal, solution au problème de programmation linéaire. Bien que l'algorithme se termine de façon certaine en un temps fini, certains problèmes peu classiques demanderont un temps exponentiel avant d'être résolus.
4.2 Le solveur GLPK «
GNU LINEAR PROGRAMMING KIT »
Afin de simplifier l'implémentation de l'algorithme du simplexe, nous avons tenté de récupérer une implémentation préexistante, étant donné la difficulté de concevoir une implémentation qui soit complète et qui prenne en compte l'étendue des cas spécifiques liés à la programmation linéaire. Il existe dans ce domaine des exemples simples dans lesquels le problème ne connaît pas de maximum dans l'optimisation pour la simple raison celui-ci n'est pas borné. Une implémentation simple consiste à se « déplacer » sur les points du polytope afin de trouver lequel de ces points optimise le plus la fonction objective. Dans le cas d'un problème non borné, la solution n'est pas un point du polytope mais une zone infinie répondant aux contraintes données. Le solveur GLPK donne l'avantage de savoir détecter ce genre de situation et d'être en mesure d'expliquer les raisons précises en cas d'échec dans la recherche d'une solution optimale.
Ecrit en langage C, ce solveur est extrêmement rapide dans la résolution de problèmes de programmation linéaire, et très performant. En effet, il est capable de résoudre des problèmes comportant plus de 100000 inéquations de contraintes simultanées. Un développeur ayant développé une interface JNI (Java Native Interface) afin d'accéder directement à la librairie native GLPK depuis Java, pourra l’intégrer facilement.
Un détail est cependant gênant : GLPK étant un solveur, il permet bien évidemment de résoudre les problèmes de programmation linéaire, mais un point important est qu'il ne permet pas de récupérer les solutions intermédiaires. L'un des objectifs de notre TER est de permettre la visualisation de ces mêmes étapes intermédiaires et des points associés sur l'enveloppe convexe du polytope. Or, GLPK ne permet pas d'adopter une démarche suffisamment progressiste pouvant être utilisée dans le cadre de ce projet. Nous nous sommes donc mis en quête d’une solution plus adaptée au problème.
Notre connaissance de la programmation linéaire est assez parcellaire et jamais nous n'avons entendu parler de l'algorithme du simplexe avant de commencer le projet. Malgré la documentation fournie par notre tuteur, nous avons recherché des documents afin de comprendre réellement quels sont les problèmes de la programmation linéaire en général et comment l'algorithme du simplexe peut permettre de les résoudre en particulier.
La première difficulté dans ce domaine est d'établir concrètement le lien entre l'aspect géométrique du problème (les inéquations de contraintes et le polytope associé) et la méthode du simplexe qui utilise en interne des matrices afin de représenter ces mêmes inéquations.
Cela nous amène à nous concentrer sur l'aspect géométrique, le plus intuitif mais aussi le moins en phase avec la méthode du simplexe. En résultat une implémentation qui, pour construire le polytope, recherche tout d'abord toutes les intersections possibles entre inéquations de contrainte, puis recherche lequel parmi les sommets du polytope optimise le plus la fonction objective. Cette méthode permet effectivement de résoudre les problèmes de programmation linéaire simples mais ne correspond pas à la méthode du simplexe comme nous allons nous en rendre compte plus tard.
Quelque temps plus tard, nous découvrons un site Internet qui présente de manière simple un tutoriel décrivant en détails les différentes étapes de la méthode associée à l'algorithme du simplexe. Ayant précédemment fait fausse route, nous décidons donc de tenter d'implémenter la technique décrite dans ce tutoriel, que l'on peut trouver à l'adresse suivante :
http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/tutorialsf4/frames4_3.html
L'ensemble des étapes forme un algorithme de résolution par la méthode du simplexe. Nous avons regroupé ces différentes étapes suivant les trois groupes d'étapes suivants :
Groupe 1 :
1-2) Saisie du problème de programmation linéaire sous forme d'inéquations et conversion de l'ensemble des inéquations de départ pour obtenir la matrice augmentée (variables supplémentaires, etc ...).
Groupe 2 :
3) Choix de la colonne du pivot.
4) Choix du pivot dans la colonne du pivot.
5) Nettoyage de la colonne du pivot (à la fin de cette étape, il reste le pivot à sa valeur initiale, toutes les autres valeurs de la colonne sont à 0).
Groupe 3 :
6) Répéter 3-5 jusqu'à ce qu'il n'y ait plus de nombres négatifs dans la dernière ligne (avec l'exception de la colonne réponse).
4.4 Les limites de l’algorithme du simplexe
Cet algorithme a cependant une limite que nous avons découverte un peu plus tard. Il ne traite que les problèmes standards de programmation linéaire avec les propriétés suivantes :
On recherche le maximum (pas le minimum) de la valeur de la fonction objective.
Toutes les variables doivent avoir des valeurs non négatives.
Toutes les inéquations de contraintes sont de la forme Ax+By+Cz+…<=N (et pas >=).
Cependant, ces limitations ne se sont pas révélées insurmontables étant donné que la majorité des problèmes de programmation linéaire sont des problèmes standards. Pour rendre l’algorithme compatible avec toute l'étendue des problèmes de programmation linéaire, une technique est présentée à la page suivante du tutoriel. Pour des raisons de temps, nous avons dû rester sur une implémentation standard. Par la suite, nous décrivons brièvement les étapes décrites dans ce tutoriel, regroupées dans l'implémentation de l'algorithme final.
4.4.1 Description du groupe 1
Ce groupe d'étapes représente en quelque sorte une étape préparatoire à toute étape ultérieure. Partant du système d'inéquations initial, il permet d'obtenir la matrice représentant le système d'inéquations en machine, celui qui sera utilisé par l'algorithme pour résoudre le problème de programmation linéaire à proprement parler.
La première étape du tutoriel, celle qui consiste à convertir le problème de programmation linéaire en un système d’inéquations linéaires, est entièrement laissée à la charge de l'utilisateur.
Celui-ci devra préalablement effectuer lui-même la conversion, c'est-à-dire identifier chaque expression de contrainte dans l'énoncé de son problème puis l'exprimer sous forme d'inéquation de contrainte. Il devra de même identifier les informations relatives à l'expression de la fonction objective afin d'obtenir l'inéquation de la fonction objective à maximiser ou minimiser. Toutes les étapes ultérieures sont prises en charge par le logiciel réalisé.
La deuxième étape du tutoriel consiste à convertir le système d'inéquations obtenu à l'étape précédente (contenant aussi bien les inéquations de contrainte que l'inéquation de la fonction objective, cette dernière étant située sur la dernière ligne du système d'inéquations) de manière à le mettre sous forme de matrice augmentée. Cette étape est relativement simple étant donné qu'il suffit de récupérer les coefficients présents dans les inéquations, et de les recopier dans la matrice augmentée à raison d’une inéquation par ligne. La matrice est ensuite augmentée, ce qui signifie que l'on rajoute des variables supplémentaires à raison d’une variable supplémentaire par inéquation que compte le système d'inéquations initial.
A la fin de cette étape, la matrice augmentée compte autant de lignes que le nombre d'inéquations dans le système d'inéquations initial et autant de colonnes que la somme :
Dimension du système d'inéquations initial + Nombre d'inéquations du système d'inéquations initial + 1
La valeur 1 est liée à la colonne « réponse » contenant la partie droite de chaque inéquation.
4.4.2 Description du groupe 2
Le groupe 2 contient les étapes importantes qui, depuis la matrice augmentée obtenue par le groupe d'étapes précédentes, permettent de progresser jusqu'à l'obtention de la matrice finale procurant le point optimal recherché, si ce dernier existe. La succession d’étapes se produisant pendant ce groupe d'étapes s'appuie largement sur la méthode dite du pivot de Gauss.
La troisième étape du tutoriel constitue la première étape du groupe 2 et consiste à choisir la colonne sur laquelle on va effectuer le pivot. Cette étape est relativement aisée car il suffit de comparer les coefficients de la dernière ligne de la matrice augmentée et de sélectionner celui qui a le coefficient le plus négatif. Si tous les coefficients de la dernière ligne sont positifs ou nuls dès la première itération de cette étape, l'algorithme se termine sur l'obtention de la solution de base réalisable qui est aussi la solution optimale. Dans le cas contraire, l'algorithme se poursuit avec le choix du pivot dans la colonne du pivot.
Le choix du pivot dans la colonne du pivot constitue la quatrième étape du tutoriel. Il s’agit d’une opération simple : pour chaque coefficients strictement positif de la colonne du pivot, il faut calculer un ratio à partir de la formule :
Ratio de la ligne i = Valeur de la colonne « réponse » pour la ligne i / Valeur de la colonne du pivot pour la ligne i.
La ligne de la colonne du pivot qui obtient le plus petit ratio est la ligne du pivot. Ce dernier est donc choisi.
L'étape suivante, la cinquième, consiste à nettoyer la colonne du pivot en utilisant le pivot choisi à l'étape précédente. Pour chaque ligne dont le coefficient est strictement positif dans la colonne du pivot, on utilise une combinaison linéaire afin de la « nettoyer », c'est-à-dire passer tous les coefficients différents du pivot à la valeur 0.
4.4.3 Description du groupe 3
Le groupe 3, contrairement aux autres, ne contient qu'une unique étape. Celle-ci ne fait qu'une seule chose : réitérer les étapes du groupe 2 jusqu'à la fin de l'algorithme, signalée par le fait qu'il n'y a plus de nombres négatifs dans la dernière ligne (avec l'exception de la colonne réponse). A chaque itération effectuée sur le groupe 2, la solution de base réalisable progresse vers l'optimum.
On obtient ainsi un chemin marqué par des points intermédiaires entre la première solution de base réalisable et la solution optimale, si cette dernière existe.
4.5 Réalisation de notre implémentation de l’algorithme du simplexe
Notre implémentation de l'algorithme du simplexe repose directement sur l'implémentation des trois groupes d'étapes que nous venons d'identifier dans la partie précédente. Dans une première version de l'implémentation réalisée, les différentes méthodes ne sont pas génériques mais spécifiques aux problèmes de dimension 2.
Lorsque s'est posée la question de la 3D, nous nous sommes rendu compte que nous allons être amenés à réécrire quasiment le même code deux fois avec seulement quelques différences au niveau de la valeur des variables. C'est ainsi qu'est venue l'idée d'une réécriture générique de l'implémentation de l'algorithme de manière à ce qu'il fonctionne pour n'importe quel problème de programmation linéaire de dimension N. Une classe décrivant les principes d'une inéquation générique est aussi créée.
La réalisation de la classe Simplexe répond à la problématique de créer un framework complet. Celui-ci doit prendre en compte l'intégralité des aspects liés d’une part à la résolution par la méthode du simplexe, d'autre part à la récupération ultérieure des résultats.
Cette classe s'intègre parfaitement dans le code du modèle de la zone 2 de l'interface (architecture MVC). Celle-ci présente les résultats de la résolution du problème linéaire courant par la méthode du simplexe, étape par étape, suivant les 3 groupes d'étapes :
Etape préliminaire G1 : conversion du système d'inéquations initial en une matrice augmentée sur laquelle s'effectuera la résolution.
Etapes intermédiaires G2 : progressions successives vers la solution optimale par choix d'un pivot et pivotage.
Etape finale G3 : obtention de la solution optimale au terme de l'algorithme.
Tout au long de l'exécution, l'algorithme stocke dans diverses collections (au sens ensemble d'objets) les différents résultats intermédiaires tels que la valeur de la ligne et de la colonne du pivot ainsi que l'historique des matrices augmentées successives obtenues à chaque étape. Cet enregistrement se fait en temps réel, ce qui permet d'exécuter l'algorithme une bonne fois pour toutes puis de récupérer après coup les informations utiles. Grâce à ce véritable historique d'exécution, l'interface graphique peut reconstituer sous forme visuelle la succession des étapes qui se sont déroulées.
5.1 Principes
Au bas de l'application, on peut voir en temps réel (pour deux variables) les courbes et les points d'intersection correspondant aux inéquations de la première zone. Pour garantir une (relative) fluidité, nous avons utilisé les techniques de clipping et de double buffering.
Il a fallu représenter trois informations en plus de l'affichage des inéquations :
le sens de l'inégalité de chaque inéquation.
l'échelle des axes (avec un repère sur le quadrillage).
la couleur pour repérer chaque inégalité.
Les deux difficultés principales dans le développement de la zone du bas ont été d'abord les changements de repère, héritage de l'algorithme géométrique : en effet, pour faciliter l'affichage des droites, le plus simple reste de calculer le coefficient directeur (donc de passer de ax1 + bx2 = c à y
= aX+b), puis de trouver un point existant. Cela fait, il faut convertir les coordonnées théoriques de plusieurs points clés dans un repère spécial de Java2D (c'est-à-dire le point (0,0), en haut a gauche).
Enfin, il reste à prendre en compte le facteur de zoom et de déplacement pour un affichage correct.
Ensuite, dans un souci de développement en groupe, nous avons adopté le mode de fonctionnement MVC (Modèle Vue Contrôle) : chaque action, venue de l'extérieur et réalisée sur la zone, doit passer par le modèle du panneau. Chaque action réalisée dans la zone (clic droit puis sélectionner un item, ...) est transmise à l'ensemble des écoutants (listeners) de la zone, répondant aux événements demandés. Enfin, la vue reste dépendante seule du modèle de la zone. Ce modèle a permis de développer une interface modulaire et indépendante.
5.2 Le reste du développement
Pour ce qui est du développement pur, par exemple le choix des images, cela n'a pas posé de problèmes majeurs. Le module IHM (Interface Homme Machine) nous a bien aidé pour répondre aux besoins essentiels de l’application. Les icônes ont étés récupérées sur le site web
« http://tango.freedesktop.org/Tango_Icon_Gallery ». Quelques informations complémentaires ont nécessité une recherche sur la FAQ (Frequently Asked Questions) Java de developpez.com : http://java.developpez.com/faq/gui/
5. Tracé des courbes
5.3 Représentation 3D
La représentation en 3D (c'est-à-dire avec 3 variables) n'a pas pu être terminée à temps. Nous avons cependant cherché les librairies 3D disponibles pour Java, et nous sommes parvenus à quelques conclusions. D'abord il y a deux types de librairies 3D pour Java : les bindings (accès de bas niveau aux ressources des cartes graphiques), et les scénographes (couche plus haute permettant de manipuler des objets plus complexes). Pour plus de détails, voir l'article à l’adresse :
http://info-rital.developpez.com/tutoriel/java/api/3d/
L'article présente des API (librairies) qui n’ont pas toutes la même valeur. Nous avons sélectionné celles qui nous paraissent la plus simple : JME (Java Monkey Engine) [www.jmonkeyengine.com]. Nous l'avons fait tourner sur Windows et Linux sans problème, grâce à la documentation complète et forum actif du site. Attention toutefois, nous avons pu remarquer que les panneaux en 3D ne s'affichent pas correctement dans les JInternalFrame (fenêtres imbriquées de Java-Swing). De plus, on ne peut pas afficher plusieurs panneaux 3D au même moment.
Java Monkey Engine (une API pour faire de la 3D)
6.1 Principes
L'une des premières contraintes de notre tuteur est de réaliser l'application de manière modulaire, or la modularité en Java passe par la « Réflexivité Java ».
En effet, le langage Java permet de charger dynamiquement des classes binaires (c'est-à-dire des fichiers Java compilés en byte-code). Ensuite, il suffit de définir le chemin vers cette classe, et l'application chargera en mémoire les objets contenus. Attention, le chargement de classes Java respecte quelques exigences. On ne peut pas charger une classe si elle rentre en conflit avec une classe déjà chargée. Pour instancier une classe chargée dynamiquement, il faut utiliser java.lang.class.newinstance().
Un système de plugins Java, qui se dit tel, doit posséder quelques propriétés. Les librairies additionnelles doivent être compilées et stockées dans une archive ''*.jar'' autonome, le chargeur doit prendre toutes les archives jar d'un répertoire (et des sous-répertoires) et charger les plugins au démarrage de l'application.
Une fonctionnalité en plus serait d’identifier et de signer chaque plugin (par un numéro de version par exemple) et que l'on puisse accéder, via une connexion Internet, à la dernière version.
Tout cela a été rendu possible par un article de developpez.com à l'adresse
« http://vincentlaine.developpez.com/tutoriel/java/plugins/ ». La difficulté n'est arrivée que plus tard, lorsqu'il a fallu créer des plugins pour l'application du simplexe.
L'article montre comment créer une application et partager certaines propriétés de celle-ci avec des plugins spécialement créés pour. Pour cela, il faut créer des classes de transfert qui contiennent les signatures des méthodes de liaisons entre l'application et les plugins. Ces classes de transfert doivent apparaître au final dans l'application mais pas dans le plugin compilé. C'est pour cela qu'il est difficile de créer des plugins. Il faut connaître les options du logiciel Eclipse pour configurer l'exportation en archive ''*jar''.
Il faut aussi comprendre ce que font les méthodes des classes de transfert, mais le plus difficile reste la phase de test. En effet, les classes chargées dynamiquement se comportent différemment des classes natives en cas de problème, ce qui a eu pour effet de retarder le lancement du système de modularité.
Pour toutes ces raisons, nous avons choisi d'abandonner cette démarche, et de se concentrer sur les fonctionnalités essentielles dans une optique statique, en se répartissant les tâches restantes.
6. Système de plugins
6.2 Les fonctionnalités
Le système de plugins est fonctionnel et a une architecture client/serveur. Il est capable de démarrer le client, de démarrer le serveur, de changer le port d'écoute, d'envoyer des requêtes au serveur. Chaque plugin côté serveur peut identifier si la requête lui est destinée et répondre. Le plugin client qui a envoyé la demande reçoit la réponse et peut alors agir sur les trois zones prédéfinies, ou sur les Toolbars des zones.
L'une des fonctionnalités est aussi la possibilité d'aller chercher sur Internet (pour les plugins coté serveur seulement pour l'instant) la dernière version du plugin en cas de disponibilité, et de l'installer. Il existe un manuel du développeur de plugin pour l'application du simplexe, disponible sur le site du projet à l'adresse suivante : http://simplexe.googlecode.com/svn/trunk/doc/
Cette partie montre les écrans prévus pour l’application. Nous avons créé une interface de telle façon qu’une personne qui ne soit pas habituée à l’informatique puisse ne pas se perdre.
L’interface de notre application possède les trois zones définies dans le cahier des charges. Elle intègre également une barre de menu et une barre d’outils. Elle est basée sur un système d’onglets qui permet d’avoir plusieurs systèmes d’inéquations ouverts.
7. Résultats
7.1 Zone de saisie
Cette zone permet à l’utilisateur de saisir des inéquations en 2D ou en 3D. Pour cela, il choisit les valeurs des deux inconnues (trois pour la 3D)et le signe de l’inéquation (<= ou >=), ainsi que la couleur de la droite de l’inéquation. Lorsqu’on clique sur le bouton « Ajouter », l’inéquation est ajoutée dans le JTabbedPane.
Dans le JTabbedPane, il est possible de modifier la couleur de la droite, d’afficher la droite grâce à la case à cocher « Afficher ». Il est possible de modifier une inéquation en cliquant avec le bouton droit de la souris sur celle-ci, et de la supprimer avec le bouton « Supprimer l’équation surlignée ».
En bas, on saisit la fonction objective avec la valeur « Maximiser » ou « Minimiser » et les deux valeurs des inconnues (trois pour la 3D). Le bouton « Optimiser » lance l’optimisation.
Cette zone permet la visualisation de l’algorithme du simplexe. Il est représenté par des droites de couleurs différentes. Les tirets permettent de représenter le signe de l’inéquation : s’ils sont en dessous de la droite, alors le signe est égal à « <= », sinon à « >= ». La 3D est représentée par des plans.
Il est possible de zoomer et de dézoomer le graphe avec la molette de la souris et d’y afficher des informations en pointant sur « Informations ».
7.3 Zone des matrices
Cette capture représente l’état initial de la résolution avec les différentes inéquations, la fonction objective, la matrice augmentée et la solution optimale.
Les différents boutons permettent de naviguer entre les différentes étapes de la résolution et de lancer la résolution. Le graphe suit l’évolution de la résolution avec un point qui varie à travers les étapes.
Cette capture représente une étape intermédiaire de la résolution.
Nous pouvons voir le calcul des ratios, les pivots ainsi que la nouvelle valeur de la fonction objective.
Cette capture montre l’étape finale de la résolution avec la solution optimale obtenue et la matrice finale.
7.4 La barre d’outils
Nous allons décrire les actions de chaque icône de la barre d’outils.
De gauche à droite :
Création d’un système pour la 2D : item Nouveau 2D
Création d’un système pour la 3D : item Nouveau 3D
Ouverture d’un fichier contenant un système : item Ouvrir
Enregistrement du système dans un fichier : item Enregistrer
Enregistrement avec un nom dans un fichier : item Enregistrer sous
Fermeture du système courant : item Fermer
Exportation au format PDF du graphe et des matrices : item Exporter en PDF
Impression du graphe : item Imprimer
Aide : item Aide
Aller à l’étape précédente (cf. zone 2) : item Etape précédente
Aller à l’étape suivante (cf. zone 2) : item Etape suivante
7.5 Fichier contenant un système
L’application permet de sauvegarder les données du système dans un fichier ainsi que de les charger. Le fichier possède une extension .spx (pour simplexe).
Le fichier contenant les données du système respecte une norme que nous avons définie :
dimension=2 (pour la 2D, 3 pour la 3D) optimisation=2:3.5:MAXIMISER
(les 2 valeurs des inconnues et le type d’optimisation)
Puis il contient la liste des inéquations du système comme ceci :
eq=libelle_de_l’inéquation:4:5:INF_EQ:20:135:34:36 eq=libelle_de_l’inéquation:5:7.5:INF_EQ:15:35:234:3
Chaque inéquation contient un libellé (« defaut » s’il n’existe pas), les valeurs des deux inconnues, le signe, la partie droite et les couleurs en RVB (Rouge Vert Bleu). Les inéquations pour la 3D possèdent une troisième inconnue. Pour le chargement, nous avons utilisé la classe Java StringTokenizer qui permet de récupérer les données en définissant des séparateurs.
8.1 Objectifs atteints
L’objectif prioritaire a été atteint puisque nous avons pu concevoir une application permettant la visualisation graphique de l'algorithme du simplexe.
Il est donc possible de saisir des inéquations dans des champs, de voir les différentes étapes de la résolution du problème et d'afficher le graphe.
De plus, les inéquations peuvent être chargées et sauvegardées, le graphe imprimé et exporté au format PDF.
8.2 Appréciation critique de l’application
Dans le cadre de notre projet, nous avons considéré les parties saisie des inéquations, visualisation du graphe et visualisation des différentes étapes de résolution.
A ce stade de la rédaction du rapport, nous n'avons pu traiter que la visualisation 2D de l'algorithme alors que l'application permet la saisie, la sauvegarde, le chargement et la résolution des inéquations à trois variables. Les packages nécessaires pour la visualisation 3D sont intégrés dans le projet.
Nous avons réalisé une application dans un premier temps basée sur un système de plugins.
Cependant, nous avons dû abandonner ce système car lourd et complexe à mettre en place, il nous a fait perdre un temps considérable.
De même, la sauvegarde et le chargement des fichiers se faisaient à partir de fichiers XML grâce à une API Java. Mais ayant rencontré des problèmes lors de l’implémentation, nous avons opté pour un fichier texte normalisé.
Nous pouvons exporter au format PDF le graphe avec les différentes étapes de résolution grâce à une autre API Java. Celle-ci permet une visualisation du fichier PDF mais les images du fichier obtenu sont coupées sur la droite.
8 Discussion
8.3 Compétences acquises
Ce travail s’est révélé une expérience très enrichissante à différents points de vue :
d’une part avec l'implémentation de l'algorithme du simplexe;
d’autre part avec la réalisation de l'application en Java, langage très utilisé dans la conception d'applications.
Pour finir, nous avons eu besoin d’une réflexion à propos de l’interface entre l’utilisateur et la machine : faire une interface conviviale avec une utilisation facile pour tous les utilisateurs nous a permis de réfléchir à la disposition de chaque composant de l’interface.
Le choix d’étudier la visualisation d'ensemble convexe en 2D et 3D pour la programmation linéaire nous a amené à des phases d’analyse et de création d’une application informatique à but professionnel.
Nous avons rempli les objectifs de base de notre projet. Le système ainsi présenté permet de visualiser en 2D la succession des étapes issues de la méthode du simplexe afin de voir le déplacement sur l'enveloppe convexe des solutions intermédiaires.
. Concevoir une application, tout en respectant les délais fixés, nous a contraint à faire des choix dans les fonctionnalités de l’interface.
Par ailleurs, nous pourrons également y ajouter le système de plugins ainsi qu’une couche réseau permettant de lancer l’application sur un serveur et de récupérer des résultats sur des postes clients.
Le travail en groupe de quatre étudiants nous a appris à travailler en respectant un planning et en suivant une organisation.
Ce projet a répondu au véritable objectif de synthèse, qui est la mise en situation d’un étudiant face à tous les problèmes que soulève la conception d’une application.
9. Conclusion
10.1 UML simplifié de la Zone 3
10. Annexes : diagrammes UML
➢ http://www.developpez.com
➢ http://www.wikipedia.org
➢ http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/tutorialsf4/frames4_3.html
➢ http://gnujpdf.sourceforge.net/
➢ http://www.gnu.org/software/glpk/
➢ http://simplexe.googlecode.com/svn/trunk/doc/
➢ http://www.jmonkeyengine.com
➢ http://tango.freedesktop.org/Tango_Icon_Gallery
