Author: afages Date: 2010-03-25 19:17:56 +0100 (Thu, 25 Mar 2010) New Revision: 288 Log: Modif soutenance et rapport Modified: trunk/src/site/doc/analyse/analyseBT.rst trunk/src/site/doc/analyse/msm.zargo trunk/src/site/doc/analyse/usecase.rst trunk/src/site/doc/rapport/img/package.png trunk/src/site/doc/rapport/rapport.rst Modified: trunk/src/site/doc/analyse/analyseBT.rst =================================================================== --- trunk/src/site/doc/analyse/analyseBT.rst 2010-03-25 17:56:40 UTC (rev 287) +++ trunk/src/site/doc/analyse/analyseBT.rst 2010-03-25 18:17:56 UTC (rev 288) @@ -1,12 +1,12 @@ *Analyse de BigTable (de google Inc.)* -2.2.1 But de l'analyse +But de l'analyse ~~~~~~~~~~~~~~~~~~~~~~ Permettre la compréhension de Big Table et de ses diverses implémentations ainsi que l'extraction d'interface pour le projet MSM. -2.2.2 Introduction : Qu'est-ce que BigTable ? +Introduction : Qu'est-ce que BigTable ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BigTable est la spécification d'un système de stockage distribué permettant @@ -18,7 +18,7 @@ * Très bonnes performances (temps de réponse...) * Forte disponibilité -2.2.3 Le modèle de données de BigTable +Le modèle de données de BigTable ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Le modèle de données de BigTable se comporte comme un dictionnaire @@ -50,7 +50,7 @@ * <com.google.maps/index.html, contents:, ts1> donne la version la plus récente du contenu. * <com.google.maps/index.html, contents:, ts2> donne une version plus ancienne du contenu. -2.2.4 Stockage +Stockage ~~~~~~~~~~~~~~ BigTable utilise le système de fichier google GFS (Google File System) @@ -59,7 +59,7 @@ Le format de fichier google SSTable est utilisé pour stocker les données internes à BigTable. -2.2.5 API BigTable +API BigTable ~~~~~~~~~~~~~~~~~~ Voici les fonctionnalités prévues par la spécification BigTable : @@ -82,7 +82,7 @@ * Calcul parallèle avec le framework MapReduce. -2.2.6 Source +Source ~~~~~~~~~~~~ Cette analyse est une synthèse des éléments utiles dans le cadre du Modified: trunk/src/site/doc/analyse/msm.zargo =================================================================== (Binary files differ) Modified: trunk/src/site/doc/analyse/usecase.rst =================================================================== --- trunk/src/site/doc/analyse/usecase.rst 2010-03-25 17:56:40 UTC (rev 287) +++ trunk/src/site/doc/analyse/usecase.rst 2010-03-25 18:17:56 UTC (rev 288) @@ -1,4 +1,4 @@ -2.4 Describe Database +Describe Database --------------------- **Use case :** 11.Describe Database. @@ -39,7 +39,7 @@ **Performance :** selon la fréquence d'exécution, doit être très rapide. L'utilisateur doit obtenir la structure de la base immédiatement. -2.5 Describe Table +Describe Table ------------------ **Use case :** 12.Describe Table @@ -83,7 +83,7 @@ **Performance :** selon la fréquence d'exécution, doit être très rapide. L'utilisateur doit obtenir la structure de la table immédiatement. -2.6 View content +View content ---------------- **Use case :** 2.View content. @@ -125,7 +125,7 @@ **Performance :** selon la fréquence d'exécution, doit être très rapide. L'utilisateur doit obtenir les données immédiatement. -2.7 Monitor +Monitor ----------- **Use case :** 3.Monitor. @@ -163,7 +163,7 @@ **Performance :** la qualité du monitoring est tout aussi importante que le temps-réel (actualité des données) de la tâche. -2.8 Import +Import ---------- **Use case :** 4.Import. @@ -208,7 +208,7 @@ **Open issues :** Que faire si erreur lors du traitement du fichier ? => Reporter l'erreur à l'utilisateur. -2.9 Export +Export ---------- **Use case :** 5.Export. @@ -251,7 +251,7 @@ **Open issues :** que faire si erreur lors de transmission des données dans le fichier ? -2.10 Connect +Connect ------------ **Use case :** 6.Connect. @@ -293,7 +293,7 @@ **Performance :** la rapidité d'exécution est primordiale étant donné la fréquence d'exécution. Gestion des erreurs importante. -2.11 Extend +Extend ----------- **Use case :** 7.Extend. Modified: trunk/src/site/doc/rapport/img/package.png =================================================================== (Binary files differ) Modified: trunk/src/site/doc/rapport/rapport.rst =================================================================== --- trunk/src/site/doc/rapport/rapport.rst 2010-03-25 17:56:40 UTC (rev 287) +++ trunk/src/site/doc/rapport/rapport.rst 2010-03-25 18:17:56 UTC (rev 288) @@ -22,45 +22,15 @@ Nous remercions également l'Université de Nantes et l'entreprise Code Lutin pour avoir proposé ce sujet intéressant sur lequel nous avons pu progresser. -Sommaire -======== +.. contents:: Sommaire + :backlinks: entry -1. Spécifications : préliminaires -* 1.1 Le demandeur -* 1.2 La demande -* 1.3 Objectifs -* 1.4 Outils -* 1.5 Chiffrage et organisation -2. Spécifications : analyse -* 2.1 Analyse des technologies -* 2.1.1 Maven -* 2.1.2 Jaxx -* 2.1.3 Jmx -* 2.2 Analyse du domaine -* 2.3 Description des cas d'utilisation -* 2.3.1 Modèle du domaine -* 2.3.2 Architecture globale (Packages) -3. Conception -* 3.1 pluginloader -* 3.2 plugins -* 3.3 ui -* 3.4 Initialisation et lancement de MSM -4. Difficultés rencontrées -5. Conclusion - - -.. sidebar:: Contents - - .. contents:: - .. sectnum:: - - -1. Spécifications : préliminaires +Spécifications : préliminaires ================================= -1.1 Le demandeur +Le demandeur ---------------- Code Lutin, Société de Service en Logiciel Libre @@ -115,7 +85,7 @@ auprès d’un large public de professionnels, particuliers et institutions en France. -1.2 La demande +La demande -------------- Voyons voir ce qui se cache derrière le nom de code MSM @@ -137,14 +107,14 @@ souhaiter utiliser une nouvelle base. Ce qui justifie le fait de concevoir une architecture à plugins. -1.3 Objectifs +Objectifs ------------- * Accroître la productivié des utilisateurs de HBase et autres ; * Permettre une adaptation rapide aux nouvelles bases ; * Fournir un produit fonctionnel, ergonomique et performant. -1.4 Outils +Outils ---------- * Technologies : Java, Maven, Jaxx, JMX. @@ -162,7 +132,7 @@ * Communication : Mailing list de Nuiton pour les développeurs, les utilisateurs et les commits. -1.5 Chiffrage et organisation +Chiffrage et organisation ----------------------------- .. figure:: img/planning.png @@ -187,13 +157,22 @@ Un compte rendu symbolisé par les rectangles noirs en fin de semaine suit chaque réunion. -2. Spécifications : analyse +JTimer est un outil de gestion de planification de tâches crée par Code Lutin. +Voici un extrait, à un instant "t" du projet : + +.. figure:: img/jtimer.png + :width: 100% + :scale: 120% + + Planning prévisionnel + +Spécifications : analyse =========================== -2.1 analyse des technologies +analyse des technologies ---------------------------- -2.1.1 Maven +Maven ~~~~~~~~~~~ Maven est connu d'un bon nombre de développeurs. Il s'agit d'un outil de @@ -204,7 +183,7 @@ Code Lutin dispose de leur propre POM permettant de récupérer les dépendances qui vont suivre. -2.1.2 Jaxx +Jaxx ~~~~~~~~~~ Jaxx est un framework permettant de générer une interface graphique en @@ -224,7 +203,7 @@ Plus de précisions à cette adresse : http://maven-site.nuiton.org/jaxx/index.html -2.1.3 Jmx +Jmx ~~~~~~~~~ Jmx est une API Java permettant de gérer la dynamique d'une @@ -238,12 +217,12 @@ Plus de détails sur le Wiki : http://fr.wikipedia.org/wiki/JMX -2.2 analyse du domaine +analyse du domaine ---------------------- .. include:: ../analyse/analyseBT.rst -2.3 Description des cas d'utilisation +Description des cas d'utilisation ------------------------------------- .. figure:: img/usecase.png @@ -255,7 +234,7 @@ .. include:: ../analyse/usecase.rst -2.12 Modèle du domaine +Modèle du domaine ---------------------- .. figure:: img/domain.png @@ -269,7 +248,11 @@ d'autres. L'application doit permettre de réaliser l'ensemble des fonctionnalités prévues sur cet ensemble de bases de données BigTable. -2.13 Architecture globale (Packages) + +Architecture +============ + +Architecture logique (Packages) ------------------------------------ .. figure:: img/package.png @@ -290,10 +273,40 @@ de l'interface graphique. -3. Conception +Mécanisme de gestion des plugins +-------------------------------- + +La gestion de plugins au sein de MSM s'établit en trois grandes +phases. + +Découverte : + +Le chargeur de plugins scan le dossier plugins à la racine du projet +où se trouve un fichier .properties contenant des références vers les +fichiers JAR de chaque plugin ainsi qu'une information sur leur chargement +ou non. +Il est également possible d'ajouter un plugin en dehors du dossier idoine, +en spécifiant dans le fichier précédent l'endroit où le trouver. +Ceci est idéal lorsque les dépendances Maven ne doivent pas être un obstacle. + +Sélection : + +L'utilisateur, une fois dans l'application, doit cocher/décocher les plugins +qu'il souhaite charger via le menu adéquat. +Cette information est sauvegardée dans le fichier .properties et les plugins +sont chargés au prochain démarrage de l'application. + +Développement : + +Pour développer un nouveau plugin, le développeur crée un JAR contenant les +classes implémentant l'interface Plugin. Le développeur ajoute ensuite un +fichier du nom de l'interface implémentée et contenant le nom de la classe +l'implémentant dans le dossier META-INF/services. + +Conception ============= -3.1 pluginloader +Pluginloader -------------- .. figure:: img/msm.png @@ -316,7 +329,7 @@ Le PluginLoader propose ensuite différents services permettant de récupérer et d'utiliser les différents plugins. -3.2 plugins +Plugins ---------- .. figure:: img/plugin.png @@ -341,8 +354,8 @@ Un développeur voulant rajouter une nouvelle base doit donc implémenter cette interface. -3.3 ui -------- +Intégration +----------- .. figure:: img/ui.png :scale: 400% @@ -371,7 +384,7 @@ flexibilité dans la création de l'interface graphique puisque cela permet un découpage entre les éléments graphique et le style qui leur est attribué. -3.4 Initialisation et lancement de MSM +Initialisation et lancement de MSM -------------------------------------- Au lancement du programme principal, l'instance de MainUI est récupérée, @@ -388,7 +401,7 @@ de faire le lien entre les différents plugins de son PluginLoader et l'interface graphique. -3.5 Captures d'écran +Captures d'écran -------------------- .. figure:: img/screenshot_view_content.png @@ -396,10 +409,7 @@ Visualisation du contenu d'une table -.. Manuel utilisateur TODO -.. Manuel développeur TODO - -4. Difficultés rencontrées +Difficultés rencontrées ========================== Concernant la partie graphique (Jaxx), il a été difficile de comprendre toutes @@ -426,7 +436,49 @@ à accueillir tout type d'implémentation de BigTable tels que les plugins d'exemple créés. -5. Conclusion +MSM à l'heure actuelle +====================== + +Le fonctionnel +-------------- + +L'architecture à plugins est opérationnelle, elle permet de charger un plugin +dynamiquement. + +La création de plugins est guidée par les interfaces monitoring, import, +export, et surtout plugin (obligatoire), mais il est tout à fait possible +de créer son propre plugin puisque l'application leur est visible. + +Finalement, l'interface graphique est complète que ce soit au niveau de +l'internationalisation, l'arbre de navigation ou la visualisation du contenu +d'un modèle de données (colonnes...). + +Évolutions possibles +-------------------- + +Le plugin HBase est à compléter (seules les fonctions de manipulation de +données fonctionnent, un souci réside avec la récupération des tables). + +D'autres bases telles que Cassandra sont potentiellement intéressantes et +MSM le permet. + +Évidemment, les fonctionnalités optionnelles dans l'interface graphique telle +que "préférences" constituent une évolution possible de l'application. + +MSM en quelques chiffres +------------------------ + +- Nombre de lignes de code : 6000 + +- Nombre de classes : 47 + +- Nombre de méthodes : 332 + +- Nombre de "commit" : +270 + +- Litres de café : 10 + +Conclusion ============= Ce projet nous a permis de découvrir de nouvelles technologies telles que Jaxx,