Améliorations possibles de ces structures

Les diérentes structures interactives qui viennent d'être présentées sont très loin d'être optimales. En eet, elles présentent une approche simple de la facette interactive de notre sys-tème d'AG. Cependant, elles n'exploitent que très peu les fonctionnalités disponible, en terme d'utilisation de modules avancés et d'exploitation de la base de données. De très nombreuses améliorations sont donc envisageables pour aller plus loin dans l'exploration des dessins qu'il est possible de produire pour un graphe.

Le problème énoncé plus tôt concernant les scores négatifs serait par exemple très intéressant à traiter. En eet, évaluer négativement tout ou une partie d'un layout signie que tout graphe se rapprochant trop de ce layout n'est pas intéressant. L'AG va donc chercher à produire quelque chose de diérent. Cependant, avec la dénition actuelle du score, cela amène l'AG à être un petit peu trop créatif. En eet, s'il arrive à rendre le layout susamment diérent, cela peut facilement écraser les autres composantes de la somme. Il faudrait donc trouver une déni-tion du score qui permet d'éviter cet eet. Il faudrait aussi équilibrer cet éloignement des layouts mauvais avec le respect de critères esthétiques an d'éviter la production de candidats trop cassés.

Mais il est aussi possible d'aller beaucoup plus loin, en mettant par exemple en place une recherche guidée par la nouveauté. L'objectif de cette dernière serait de trouver des graphes intéressants pour les critères esthétiques, et étant les plus éloignés possible des candidats pro-posés jusque-là. Cela permettrait par exemple d'obtenir une très bonne structure d'initialisation.

Ce type de recherche pourrait aussi être utilisé dans une structure similaire à la deuxième an d'éviter toute convergence de la population autour d'un unique candidat. L'objectif serait donc de trouver de nouveaux candidats qui sont compatibles avec les évaluations de l'utilisateur.

L'utilisation de la base de données pourrait aussi orir de nombreuses possibilités. Par ex-emple, il serait possible de créer une structure d'initialisation s'appuyant massivement sur les génomes enregistrés lors du dessin d'un graphe déjà connu par le système. En utilisant une comparaison des métriques topologiques des graphes (via le contexte), il serait aussi possible de s'inspirer des génomes utilisés sur des graphes similaires. Cela permettrait par exemple de faire des structures extrêmement courtes (une centaine de générations), qui permettrait de fournir à l'utilisateur des idées de dessins pour son graphe très rapidement.

Il pourrait aussi être intéressant de faire intervenir d'autres critères esthétiques, an d'aug-menter le nombre de voies à explorer lors de l'anage d'un layout. De telles structures n'ont pas été présentées ici, car nous avons souhaité limiter au maximum la complexité des structures des exemples. Il a d'ailleurs été relativement dicile de se xer sur certaines structures alors même qu'elles présentaient des lacunes évidentes. Cependant, l'objectif de ce chapitre était plus de fournir une idée des possibilités oertes par notre système plutôt que des structures optimales.

Ces dernières auraient été extrêmement complexes, et de plus, comme nous le verrons dans la conclusion, nous n'avons pas eu susamment de temps à consacrer à la mise au point de telles structures durant la durée de cette thèse.

Figure 4.17 Les layouts produits par la première exécution de la structure interactive d'initialisation

Figure 4.18 Les layouts produits par la deuxième exécution de la structure interactive d'initialisation

Figure 4.19 La structure interactive permettant de prendre en compte les évaluations de l'utilisateur

Figure 4.20 Les layouts obtenus suite à l'exécution de la structure prenant en compte les évaluations utilisateurs

Figure 4.21 Les layouts obtenus après la dernière exécution de la structure d'initialisation

Besoins identiés et solution logicielle

Ce chapitre va être dédié à diérentes besoins, techniques ou en termes de fonctionnalités, rencontrés au cours de cette thèse. Ces besoins ont fortement inuencés certaines décisions au cours de la mise en place du système. Les réponses apportées prennent la forme de modules spéciques ou sont plus diuses au sein de l'ensemble du système. Les parties suivantes abor-deront les 3 besoins principaux. La première concerne la distribution des calculs, la deuxième le paramétrage des algorithmes génétiques, et la dernière l'interaction entre les utilisateurs novices et le système.

5.1 Distribution des calculs

La problématique première de cette thèse consiste à assister un utilisateur novice dans le cadre du dessin de graphe. Cette problématique induit un corollaire immédiat sur la puissance disponible pour réaliser cette tâche sur la machine de l'utilisateur, qui doit être considérée comme faible. Ce corollaire est de plus fortement amplié par l'évolution actuelle des périphériques in-formatiques orientés vers la mobilité et qui de ce fait sont relativement peu puissants.

Cette limite prend encore plus d'importance dans le cadre des problématiques liées à l'intel-ligence articielle. Les méta-heuristiques actuelles sont généralement gourmandes en terme de puissance de calcul, et cela va croissant avec la complexité de l'espace à explorer. Le cas du dessin de graphe pouvant être considéré comme complexe (au moins à la vue de la taille de la communauté scientique se penchant sur ce point), il n'est pas envisageable d'espérer réaliser tous les calculs sur la machine de l'utilisateur nal.

La réponse apportée a été de concevoir un système dans lequel tous les calculs sont exécutés sur des machines distantes dédiées uniquement à cette tâche. Notre architecture se décompose en 4 éléments distincts. La gure 5.1 présente le rôle de chacun et diérentes interactions entre ces entités.

L'idée principale reposant derrière cette structure est qu'il est possible d'avoir une importante puissance de calcul sur des machines dédiées à l'exécution continuelle de l'AG. Le système dans son état actuel permet l'exécution d'une centaine de structures simultanément. Nous n'avons pas eu la possibilité de réaliser des tests à plus grandes échelles, mais il est fort possible qu'une gestion plus ne de la mémoire au sein du serveur soit nécessaire pour cela.

Le programme Genetips, qui repose en grande partie sur la bibliothèque genLib, permet l'exécution de n'importe quelle structure de l'AG, dans le cadre du dessin de graphe. Ce

pro-127

Figure 5.1 Les interactions entre les diérents éléments du système mis en place

gramme est intégralement écrit en C++ an de permettre une exécution la plus ecace possible.

Une parallélisation des calculs au sein du client n'a pas encore été mise en place mais elle serait tout à fait possible puisque l'évaluation de chaque génome est réalisée indépendamment des autres. De manière générale, pour chaque cas d'utilisation, il est toujours possible de paralléliser les calculs réalisés par l'évaluateur.

Le serveur et le moniteur sont tous les deux écrits en java. Ce choix a été dicté par des contraintes de temps et le relâchement de la contrainte sur l'ecacité de calcul, puisque ces deux programmes ne sont nalement pas très gourmands en terme puissance de calcul. En eet, la seule action continue du serveur consiste à enregistrer les données de monitoring, tout le reste ne consiste qu'en actions ponctuelles simples en début ou en n d'exécution. En ce qui concerne le moniteur, ce dernier ne constitue nalement qu'une grande interface graphique permettant d'accéder aux données du serveur. Les diérentes interactions entre le serveur et le moniteur seront plus amplement abordées dans la suite de ce chapitre.

Le module de la base de données est sûrement un des plus simples de cette architecture, dans la mesure où il consiste simplement en une base de données PostGreSQL dans laquelle une base a été créée et est accessible pour un utilisateur distant. Lors du premier lancement d'un programme Genetips sur cette base, toutes les tables nécessaires seront automatiquement créées.

Le dernier module est le plug-in Tulip. L'objectif de ce dernier est de permettre à un util-isateur nal d'interagir simplement avec notre système. Le principe du plug-in consiste donc à pouvoir communiquer avec le serveur, lui fournir un graphe et demander le lancement d'une exécution interactive de l'AG. Ce plug-in n'a pas encore été réellement mis en oeuvre, pour des questions de temps. Toutes les fonctionnalités sont pour l'instant mises en oeuvres dans une section dédiée du moniteur. Cependant, le système de récupération des résultats directement sur

la base de données est déjà utilisé an de se rapprocher du comportement qu'aurait un plug-in directement intégré dans Tulip.

Comme le montre l'image, il est prévu que les utilisateurs naux n'interagissent qu'avec le plug-in Tulip. L'utilisateur qui utilise le moniteur, et qui congure le serveur est quant à lui un utilisateur expert. Il est en eet nécessaire qu'il connaisse très nement notre système ainsi que le domaine du dessin de graphes. En eet, comme nous le verrons dans la dernière partie de ce chapitre, il doit créer les structures que l'AG utilisera pour le mode interactif.

Cette architecture répond de manière satisfaisante au problème de l'absence de puissance de calcul sur la machine exécutant le client nal. De plus, elle permet aussi l'utilisation de manière intensive de l'AG à des ns de recherche pure en permettant l'exécution parallèle d'un grand nombre d'AG et la comparaison des résultats obtenus au cours et à la n de ces exécutions. Cette possibilité est intimement liée à la possibilité de paramétrer nement une structure d'AG, ce qui correspond exactement au besoin traité dans le paragraphe suivant.