Etude de la plateforme Eclipse

Transcription

1 Etude de la plateforme Eclipse Travail de Master Johan Vuichard Septembre 2006 Supervisé par : Prof. Dr. Jacques Pasquier-Rocha et Dr. Patrik Fuhrer Groupe Génie Logiciel Groupe Génie Logiciel Département d'informatique Université de Fribourg (Suisse)

2 Lorsque tu ne sais pas où tu vas, regarde d'où tu viens. - Proverbe africain

3 Remerciements Je remercie Prof. Dr. Jacques Pasquier-Rocha et Dr. Patrik Fuhrer pour leur aide et leur soutien tout au long de ce travail de Master. ii

4 Résumé Le premier objectif de ce travail de master est l'étude de la plateforme Eclipse, c'est-à-dire son architecture et le mécanisme de plug-in qui fait d'elle une plateforme de développement extensible. Le second objectif est de créer un premier plug-in assez simple servant d'exemple et de tutoriel. Pour atteindre ce but, nous avons développé un plug-in qui permet d'envoyer et de recevoir des s grâce à l'api JavaMail. De plus, une version rich application de ce plug-in a été construite pour montrer qu'eclipse est aussi une rich client platform. Fort de l'expérience acquise dans la première partie de ce travail, un deuxième plug-in fournissant un outil facilitant l'élaboration et l'exécution de systèmes de simulation discrète basés sur le framework SimJ a été développé. L'architecture de ce plug-in vous est présentée ainsi qu'une conclusion de ce travail de master. Mots clés : Eclipse, plug-in, plateforme de développement, Java, SimJ, JavaMail, , simulation, Simj Plugin, Mailer Plugin, RCP, rich client application iii

5 Table des matières 1. Introduction Motivation et Objectifs Organisation Notations et Conventions Le monde des logiciels open source Bref historique Dénition du logiciel libre Dénition de l'open source Exemples de logiciels open source Conclusion Eclipse Introduction Architecture de la plateforme Platform Runtime Workspace SWT JFace Workbench Team support Help JDT PDE Plug-in Introduction Structure d'un plug-in Extensions et points d'extension Installation et cycle de vie d'un plug-in iv

6 Table des matières v 3.4. Rich Client Application et Rich Client Platform Introduction Structure Conclusion Exemple de Plug-in : Mailer Plugin Introduction Construction du Mailer Plugin Création du Plug-in project Ajout de l'api Javamail et du framework JAF au projet Ajout des extensions Les diérentes fenêtres du Mailer Plugin Le point d'extension du Mailer Plugin Fonctionnement du Mailer Plugin Construction du Mailer : version rich client application Création du Plug-in project Ajout des extensions Amélioration possible Conclusion Le framework SimJ Introduction Ressource Entité Evénement Générateur de nombres aléatoires Horloge et échéancier Utilisation du framework SimJ Conclusion Application nale : Simj Plugin Introduction Structure du plug-in Extensions L'assistant de création de simulation La classe : SimjWizard La classe : RessourceWizardPage La classe : EntityWizardPage La classe : SimulationWizardPage Aide de l'assistant La classe : Factory

7 Table des matières vi 6.7. Fonctionnement Amélioration possible Conclusion Conclusion 68 A. Acronymes 69 B. Licence de la documentation 70 C. Page web du projet 71 D. CD-ROM 73 E. Licence de la plateforme Eclipse 75 Bibliographie 79 Sites Web 80 Index 81

8 Liste des gures 3.1. Architecture d'eclipse Vue du workspace à l'intérieur d'eclipse Vue du workspace à l'extérieur d'eclipse Fonctionnement du Standard Widget Toolkit (SWT) Une fenêtre du Workbench Navigateur d'aide Navigateur d'aide PDE Vue de la deuxième page de l'assistant de création de Plug-in project Vue de la dernière page de l'assistant de création de Plug-in project Vue du PDE Vue du menu pour ajouter une ressource au classpath Vue de l'onglet runtime du PDE Ajout de l'extension org.eclipse.ui.actionsets Ajout d'un actionset Conguration de l'action Assistant de création de classe Java pour notre classe Open Page de préférence du Mailer Plugin Conguration de l'initializer Ajout d'une page de préférences Conguration de la page de préférences Diagramme de classes du Mailer Plugin : première partie Fenêtre principale du Mailer Plugin Fenêtre d'envoi de message Fenêtre : ImageViewer Onglet Extensions Points Assistant de création de point d'extension Assitant de création de schéma vii

9 Liste des gures viii Diagramme de classes complet du Mailer Plugin Arborescence des dossiers Vue d'un Vue de la première page de l'assistant de création de Plug-in project Vue de la deuxième page de l'assistant de création de Plug-in project Vue de la dernière page de l'assistant de création de Plug-in project Vue de la rich client application Diagramme de classes du Framework SimJ et du Supermarche Simulation d'un supermarché Diagramme de classes du Simj Plugin Assistant New Project Page de création des ressources avec la fenêtre d'aide Diagramme de séquence de la méthode createclassentity(string pack, String name) Page de création de projet Page de conguration des paramètres Java Page de création des ressources Page de création d'entité Page de création de la simulation Vue Package Explorer C.1. Site internet ociel du projet D.1. Le CD-ROM de ce project

10 Liste des codes source 1.1. Exemple de code source Exemple de chier manifest.mf Exemple de chier plugin.xml Exemple de chier build.properties Classe qui étend AbstractUIPlugin Exemple de point d'extension tiré du Mailer Plugin Exemple de schéma : button.exsd Fichier plugin.xml d'une application Rich Client Platform (RCP) Classe qui implémente l'interface IPlatformRunnable Classe qui étend WorkbenchAdvisor Classe qui étend WorkbenchWindowAdvisor Classe qui étend ActionBarAdvisor Classe qui étend IPerspectiveFactory Classe Open qui implémente IWorkbenchWindowActionDelegate Page de préférence du Mailer Classe ProcessServiceMembers Interface IFunction Méthode add(ifunction f,string buttontext,string pluginlabel,string pathtext) de la classe Mail_Gui Classe ApplicationActionBarAdvisor Classe Action Fichier root.xhtml Méthode getservicetime(simentity pentity) de la classe Magasin Classe SuperMarche Fichier HelpContexts.xml Méthode createclassentity(string pack, String name) de la classeclasse Factory Fichier modèle entitytp.txt

11 1 Introduction 1.1. Motivation et Objectifs L'objectif principal de ce travail de master est l'étude de la plateforme Eclipse. Celle-ci est avant tout une plateforme de développement extensible. La plateforme Eclipse a été développée de manière à supporter un ensemble d'outils pour le développement d'application dans des environnements diérents (Java, C, etc), à supporter une multitude d'outils pour gérer les nombreux formats de données (HTML, JAVA, XML, PNG, etc), à faciliter l'intégration de diérents outils fournis par divers fournisseurs, à supporter à la fois des environnements graphiques et non graphiques et à être une plateforme utilisable sur un large spectre de systèmes d'exploitation (Windows, Linux, etc). Pour cela Eclipse ore tout un mécanisme de plug-in qui permet de lui intégrer n'importe quel outil et de l'étendre à volonté. De plus, Eclipse est une RCP et de ce fait, elle permet de créer des rich client applications. C'est pourquoi nous allons nous intéresser dans ce rapport à l'architecture d'eclipse qui fait d'elle une plateforme caméléon mais aussi à ce mécanisme de plug-in sans lequel Eclipse ne pourrait exister. Et quelle est la meilleure façon de comprendre le fonctionnement de ce mécanisme de plug-in? Bien sûr, c'est en nous mettant à la pratique. C'est pour cela que dans un premier temps, nous créerons un petit exemple de plug-in permettant l'envoi et la réception d' , mais aussi une version rich client application de ce plug-in pour découvrir Eclipse RCP, et dans un second temps, nous développerons un plug-in plus conséquent fournissant un outil facilitant l'élaboration et l'exécution de systèmes de simulation discrète basés sur le framework SimJ développé par le groupe Génie Logiciel Organisation Ce rapport est divisé en cinq chapitres : Le monde des logiciels open source : Ce chapitre est consacré, comme son nom l'indique, à l'open source ce qui semble inévitable puisque la plateforme Eclipse, elle-même, est open source. Eclipse : Ce chapitre se concentre sur l'architecture d'eclipse qui fait d'elle une plateforme de développement extensible. Exemple de Plug-in : Mailer Plugin. Ce chapitre, lui, se veut plutôt didactique et explique à l'aide d'un exemple concret la création d'un plug-in et d'une application RCP Eclipse de A jusqu'à Z. 2

12 1.3. Notations et Conventions 3 Le framework SimJ : Ce chapitre présente le framework SimJ qui est la base de l'application nale. Application nale : Simj Plugin. Ce chapitre présente le but nal de ce travail de master, c'est-à-dire la création d'un plug-in sur la base du framework SimJ Notations et Conventions Conventions de mise en page : Gras est utilisé pour mettre en évidence des termes. italique est utilisé pour les mots de langue anglaise SansSerif est utilisé pour les adresses internet. Code est utilisé pour toutes références à un code source, c'est-à-dire des constantes, des noms de méthodes, des variables, des noms de classes, et des noms d'interfaces, ou à un nom de chier. Ce rapport est divisé en chapitres. Les chapitres, eux-mêmes, sont divisés en sections. Si nécessaire, les sections sont subdivisées en sous-sections, et ces dernières peuvent contenir plusieurs paragraphes. Les gures (Figures) et les codes source (Listings) sont numérotés à l'intérieur d'un chapitre. Par exemple, une référence à Fig. j du chapitre i sera notée Fig. i.j. Les codes sources sont présentés de la manière suivante : voir Listing 1.1 public class SimjPlugin extends A b s t r a c t U I P l u g i n { private s t a t i c SimjPlugin instance = null ; 5 public SimjPlugin ( ) { 7 instance = this ; 9 } 11 public void s t a r t ( BundleContext context ) throws Exception { super. s t a r t ( context ) ; 13 } Listing 1.1: Exemple de code source

13 2 Le monde des logiciels open source 2.1. Bref historique Dénition du logiciel libre Dénition de l'open source Exemples de logiciels open source Conclusion Bref historique Il existe aujourd'hui deux mouvements principaux qui donnent lieu à deux dénitions : celle du logiciel libre (free software) et celle de l'open source. La première dénition fut énoncée par Richard Matthew Stallmann, fondateur du mouvement pour le logiciel libre. Il créa en 1982 la fondation pour le logiciel libre (en anglais, Free Software Foundation (FSF)). La seconde dénition est donnée par Bruce Perens et Eric S. Raymond qui choisissent un nouveau terme open source pour désigner les logiciels libres, car le terme anglais free software prête à confusion. En eet, le mot free possède plusieurs sens : liberté mais aussi gratuité, et c'est souvent le second sens qui est perçu, à tort, par les utilisateurs. Bruce Perens et Eric S. Raymond fondèrent, en 1998, l'open Source Initiative (OSI) qui délivre désormais le label OSI approved aux licences qui satisfont aux critères dénis dans l'open source Denition. Les deux mouvements sont mutuellement en désaccord sur la dénition de l'autre. Les deux termes sont souvent confondus à tort. Les dénitions du logiciel libre et de l'open source sont énoncées dans les sections suivantes pour permettre de les comparer Dénition du logiciel libre L'expression, logiciel libre, fait référence à la liberté pour les utilisateurs d'exécuter, de copier, de distribuer, d'étudier, de modier et d'améliorer le logiciel. Plus précisément, elle fait référence à quatre types de liberté pour l'utilisateur du logiciel : 1. La liberté d'exécuter le programme, pour tous les usages (liberté 0). 4

14 2.3. Dénition de l'open source 5 2. La liberté d'étudier le fonctionnement du programme, et de l'adapter à vos besoins (liberté 1). Pour ceci l'accès au code source est une condition requise. 3. La liberté de redistribuer des copies, donc d'aider votre voisin, (liberté 2). 4. La liberté d'améliorer le programme et de publier vos améliorations, pour en faire proter toute la communauté (liberté 3). Pour ceci l'accès au code source est une condition requise. La dénition exacte et complète du logiciel libre se trouve sur le site web de la FSF [7] Dénition de l'open source Open source implique plus que la simple mise à disposition du code source. La licence d'un programme open source doit répondre aux critères suivants : 1. Libre redistribution La licence ne doit pas empêcher de vendre ou de donner le logiciel en tant que composant d'une distribution d'un ensemble contenant des programmes de diverses origines. La licence ne doit pas exiger que cette vente soit soumise à l'acquittement de droits d'auteur ou de royalties. 2. Code Source Le programme doit inclure le code source, et la distribution sous forme de code source comme sous forme compilée doit être autorisée. Quand une forme d'un produit n'est pas distribuée avec le code source correspondant, il doit exister un moyen clairement indiqué de télécharger le code source, depuis l'internet, sans frais supplémentaires. Le code source est la forme la plus adéquate pour qu'un programmeur modie le programme. Il n'est pas autorisé de proposer un code source rendu dicile à comprendre. Il n'est pas autorisé de proposer des formes intermédiaires, comme ce qu'engendre un préprocesseur ou un traducteur automatique. 3. Travaux dérivés La licence doit autoriser les modications et les travaux dérivés, et leur distribution sous les mêmes conditions que celles qu'autorise la licence du programme original. 4. Intégrité du code source de l'auteur La licence ne peut restreindre la redistribution du code source sous forme modiée que si elle autorise la distribution de chiers patch aux côtés du code source dans le but de modier le programme au moment de la construction. La licence doit explicitement permettre la distribution de logiciel construit à partir du code source modié. La licence peut exiger que les travaux dérivés portent un nom diérent ou un numéro de version distinct de ceux du logiciel original. 5. Pas de discrimination entre les personnes ou les groupes La licence ne doit opérer aucune discrimination à l'encontre de personnes ou de groupes de personnes. 6. Pas de discrimination entre les domaines d'application La licence ne doit pas limiter le champ d'application du programme. Par exemple, elle ne doit pas interdire l'utilisation du programme pour faire des aaires ou dans le cadre de la recherche génétique.

15 2.4. Exemples de logiciels open source 6 7. Distribution de la licence Les droits attachés au programme doivent s'appliquer à tous ceux à qui le programme est redistribué sans que ces parties ne doivent remplir les conditions d'une licence supplémentaire. 8. La licence ne doit pas être spécique à un produit Les droits attachés au programme ne doivent pas dépendre du fait que le programme fait partie d'une distribution logicielle spécique. Si le programme est extrait de cette distribution et utilisé ou distribué selon les conditions de la licence du programme, toutes les parties auxquelles le programme est redistribué doivent bénécier des droits accordés lorsque le programme est au sein de la distribution originale de logiciels. 9. La licence ne doit pas contaminer d'autres logiciels La licence ne doit pas apposer de restrictions sur d'autres logiciels distribués avec le programme qu'elle couvre. Par exemple, la licence ne doit pas exiger que tous les programmes distribués grâce au même médium soient des logiciels open source. 10. La licence doit être technologiquement neutre Aucune disposition de la licence ne peut aller à l'encontre d'une quelconque technologie ou style d'interface. La dénition exacte et complète de l'open source se trouve sur le site web de l'osi [9] Exemples de logiciels open source Voici quelques exemples de logiciels, car la liste est tellement longue qu'il est impossible de tous les citer sans en oublier un : Le serveur web Apache, le système d'exploitation Linux, le browser Mozilla, la base de données MySQL, le langage Hypertext Preprocessor ( PHP) sont tous des logiciels open source dont les licences sont répertoriées sur le site web de l'osi, ainsi que toutes les licences des autres logiciels qui n'ont pas été cités ci-dessus. Mais, bien sûr il ne faut pas oublier l'exemple, de la plateforme Eclipse, qui est le sujet de ce travail de master, dont la licence se trouve en annexe E Conclusion La diérence entre ces deux dénitions n'est pas très perceptible. En eet, la plupart des logiciels open source sont des logiciels libres et il en va de même pour l'inverse. Une des principales diérences entre la dénition de l'open source et celle des logiciels libres est que celle de l'open source n'utilise pas le terme de free, ainsi elle lève l'ambiguïté du terme free.

16 3 Eclipse 3.1. Introduction Architecture de la plateforme Platform Runtime Workspace SWT JFace Workbench Team support Help JDT PDE Plug-in Introduction Structure d'un plug-in Extensions et points d'extension Installation et cycle de vie d'un plug-in Rich Client Application et Rich Client Platform Introduction Structure Conclusion Introduction IBM, Borland, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft et Webgain lancent, en novembre 2001, la première version de la plateforme Eclipse, comme un projet open source. Depuis le début de l'aventure, le groupe ne cesse de croître pour atteindre plus de 90 membres en juin Voici, quelques autres entreprises qui ont été admises dans le cercle : Sybase, HP, Oracle, Ericsson, Macromedia... Eclipse n'est pas une simple plateforme pour développer des applications en Java, ceci est une de ses nombreuses facettes. Les créateurs d'eclipse ont voulu faire d'elle une plateforme multifonctionnelle. De nos jours, l'utilité d'une telle plateforme est immense, 7

17 3.2. Architecture de la plateforme 8 car si l'on prend l'exemple d'application internet, il nous faut gérer une grande quantité d'outils qui permettent de traiter les diérents chiers utilisés : Hypertext Markup Language (HTML), audio, vidéo, Java... Ainsi Eclipse nous permet de travailler avec une multitude de chiers diérents sans changer d'outils à chaque fois. L'architecture de plugin d'eclipse est comparable à un jeu de construction Lego, elle est aussi transformable que ce dernier. Ainsi nous pouvons ajouter tout simplement une fonctionnalité à la plateforme en posant une brique, ou plus précisément un plug-in. Eclipse est aussi une RCP ce qui permet de l'utiliser pour développer des rich client applications. Mais, nous verrons tout cela plus en détail dans les sections suivantes. Cette possibilité d'étendre la plateforme à volonté et de l'utiliser comme une RCP fait d'eclipse un produit très puissant Architecture de la plateforme Dans ce chapitre nous allons décrire les principaux composants de la plateforme Eclipse, dont voici le schéma. Eclipse est, elle-même, construite sur le principe de plug-in, que ce soit la partie graphique ou le coeur même de la plateforme. Fig. 3.1.: Architecture d'eclipse

18 3.2. Architecture de la plateforme Platform Runtime Le Platform runtime est composé de deux plug-ins, org.eclipse.osgi et org.eclipse.core.runtime (voir gure 3.1), dont tous les autres plug-ins sont dépendants. Il maintient aussi à jour le plug-in registery où sont gardés en mémoire toutes les extensions oertes par les plug-ins et les points d'extension que ceux-ci étendent. Mais la tâche la plus importante qui lui incombe est de lancer la plateforme Eclipse elle-même. Il possède d'autres fonctionnalités comme de gérer le log, le preference store, et le mécanisme des adapters qui permet d'étendre des classes dénies dans Eclipse comme les ressources du workspace. Le runtime est le noyau minimal d'eclipse qui ne devient intéressant qu'une fois que de nouveaux plug-ins lui sont ajoutés pour étendre sa fonctionnalité Workspace Un workspace dans Eclipse fait le lien directement avec le système de chiers. Chaque workspace contient un ou plusieurs projets. Tout projet correspond à un dossier dans le système de chiers et chaque projet peut contenir des sous-dossiers ou des chiers. Les projets, les dossiers et les chiers, dans la terminologie d'eclipse, sont tous regroupés sous le terme de ressources. Les ressources présentent dans le workspace sont accessibles à l'intérieur de la plateforme bien sûr (voir gure 3.2), mais elles le sont aussi pour des outils extérieurs à la plateforme (voir gure 3.3). Les projets, à leur création, reçoivent une nature qui fait en quelque sorte le lien avec un outil présent dans la platforme. Par exemple, si nous créons un projet Java, alors le projet se verra attribuer une nature Java. Le workspace fournit aussi un mécanisme qui permet d'inscrire des annotations dans les ressources, par exemple un message d'erreur d'un compilateur, et un mécanisme qui permet de garder la trace de tous changements des ressources. Pour cela, il sut de s'enregistrer à un ressource change listener pour recevoir toute notication de modications, d'eacements et de créations de ressources. Chaque projet se voit attribuer un incremental project builder. Par exemple, un projet Java est lié à un Java incremental project builder, celui-ci se charge de compiler les chiers sources à chaque fois qu'un utilisateur modie un chier et sauvegarde les changements SWT SWT est une Application Programming Interface (API) graphique inclue dans la plateforme d'eclipse. Elle ore tout un ensemble de boutons, de menus, d'arbres... et elle s'occupe aussi de la gestion des événements. Les créateurs d'eclipse ont voulu écrire une API dont le rendu visuel se rapproche le plus possible des interfaces des systèmes d'exploitation. Pour cela, SWT utilise la Java Native Interface (JNI), qui permet de communiquer avec le système de gestion de fenêtrage du système d'exploitation (voir gure 3.4). C'est grâce à cela que SWT a pu être presque complètement écrit en Java. Les classes SWT ne font donc presque que de transmettre des appels aux systèmes de fenêtre du système d'exploitation.

19 3.2. Architecture de la plateforme 10 Fig. 3.2.: Vue du workspace à l'intérieur d'eclipse Fig. 3.3.: Vue du workspace à l'extérieur d'eclipse JFace JFace est aussi une API graphique, celle-ci est construite à partir de SWT. Alors que SWT a été créée pour être le plus proche du fenêtrage du système d'exploitation, JFace a été, elle, construite pour fournir un support pour les applications de haut niveau et ainsi, elle complète SWT. JFace met à disposition des boîtes de dialogue, des assistants (wizards), etc.

20 3.2. Architecture de la plateforme 11 Fig. 3.4.: Fonctionnement du SWT Workbench Le workbench est l'interface utilisateur d'eclipse, c'est la partie visible d'eclipse (voir gure 3.5). Le workbench est construit directement au-dessus de SWT et de JFace. Le workbench est décomposé en fenêtres, chaque fenêtre ore une ou plusieurs perspectives, mais une seule perspective est visible à la fois. Une perspective contient des éditeurs et des vues (par exemple la vue package explorer ). Les éditeurs permettent de sauvegarder, éditer et ouvrir des objets, tandis que les vues fournissent de l'information à propos d'objets qui sont en train d'être utilisés dans le workbench Team support Eclipse fournit un outil pour travailler avec Concurrent Versions System ( CVS), il n'y a pas besoin d'installer quoi que ce soit. Il sut de se connecter à son serveur CVS. Ensuite, Eclipse fournit toutes les commandes propres à CVS. Les créateurs même d'eclipse utilisent CVS pour le développement d'eclipse Help Eclipse ore un système d'aide très complet sur internet, mais aussi dans la plateforme elle-même. Cette aide se trouve dans le sous-menu Help Contents du menu Help. Elle se présente sous la forme d'un navigateur qui ressemble à un livre (voir gure 3.6). Elle possède non seulement un index, mais aussi un outil de recherche qui tous deux permettent de trouver toutes les informations dont nous avons besoin. Eclipse fournit aussi une aide contextuelle. Celle-ci permet d'obtenir de l'aide sur un élément de plateforme en le sélectionnant et en cliquant sur F1, alors une vue contenant les rubriques d'aide qui concernent notre élément s'ouvre sur la droite de la fenêtre (voir gure 3.7). Bien sûr Eclipse ore la possibilité à l'utilisateur d'étendre ce système d'aide.

21 3.2. Architecture de la plateforme 12 Fig. 3.5.: Une fenêtre du Workbench JDT Java Development Tools (JDT) est comme son nom l'indique un outil qui fournit un Java Integrated Development Environment (IDE). Il permet le développement, le lancement et la correction de code Java. Cet outil possède un éditeur, des vues, un outil de recfactoring, un compilateur Java, un outil de recherche, etc. Grâce à tous ces outils l'utilisateur se voit grandement faciliter la création de projets Java. Cet outil est présent par défaut quand nous installons la version Eclipse Software Development Kit (SDK), mais il est possible d'installer une version très basique d'eclipse sans JDT. Les diérentes versions d'eclipse sont disponibles sur le site d'eclipse [3] PDE Plug-in Development Environment (PDE) est un outil créé pour aider l'utilisateur à développer, tester, corriger et déployer des plug-ins Eclipse. Le PDE fournit une interface graphique qui guide pas à pas l'utilisateur pour créer son propre plug-in (voir gure 3.8).

22 3.2. Architecture de la plateforme 13 Fig. 3.6.: Navigateur d'aide Fig. 3.7.: Navigateur d'aide

23 3.3. Plug-in 14 Fig. 3.8.: PDE 3.3. Plug-in Introduction Les plug-ins, comme nous avons pu le voir dans les chapitres précédents, sont la base d'eclipse. Si un utilisateur veut ajouter son propre outil à la plateforme, il lui sut de créer un plug-in qui étend une des fonctionnalités d'eclipse. Car, presque tous les plug-ins qui forment la plateforme orent des points d'extension où le plug-in de l'utilisateur peut venir se greer. Par exemple, nous pouvons très facilement ajouter un bouton dans la barre d'outils, sa propre vue, ou son propre éditeur etc Structure d'un plug-in Un plug-in est bien évidemment codé en Java. Celui-ci se présente sous la forme d'une archive, Java Archive (JAR), qui contient des chiers Java, des images, d'autres archives, mais surtout un plug-in manifest et parfois un chier Java qui étend la classe AbstractUI- Plugin ou la classe Plugin. Un plug-in manifest se compose de trois chiers : un chier manifest.mf, un chier plugin.xml et un chier build.properties. Le chier manifest.mf (cf. listing 3.1) spécie le nom du plug-in (Bundle-name), la version du plug-in (Bundle-version), le nom de la classe qui s'occupe du cycle de vie du plug-in (Bundle-Activator ), le nom du fournisseur du plugin (Bundle-Vendor ), les dépendances du plug-in aux autres plug-ins (Require-Bundle), etc. Ces informations contenues dans le manifeste permettent au plug-in d'être chargé au lancement de la plateforme.

24 3.3. Plug-in 15 Manifest V e r s i o n : Bundle M a n i f e s t V e r s i o n : 2 Bundle Name: Helloworld Plug i n 4 Bundle SymbolicName: com. example. h e l l o w o r l d ; s i n g l e t o n : = t r u e Bundle V e r s i o n : Bundle A c t i v a t o r : com. example. h e l l o w o r l d. H e l l o w o r l d P l u g i n Bundle Vendor: Hello man 8 Bundle L o c a l i z a t i o n : p l u g i n Require Bundle: org. e c l i p s e. ui, 10 org. e c l i p s e. core. runtime Listing 3.1: Exemple de chier manifest.mf Le chier plugin.xml (cf. listing 3.2), quant à lui, spécie les extensions que le plug-in étend et les points d'extension que d'autres plug-ins pourront à leur tour étendre. Les informations contenues dans ce chier sont utilisées entre autres pour informer les autres plug-ins des extensions disponibles. Dans le listing 3.2, par exemple, nous voyons que le plug-in Helloworld étend le point d'extension, org.eclipse.ui.views (cf. ligne 6). <?xml version= " 1.0 " encoding= "UTF 8"?> 2 <? e c l i p s e version= " 3.0 "?> < p l u g i n > 4 <extension 6 p o i n t = " org. e c l i p s e. u i. views " > <category 8 name= " Hello Category " i d = "com. example. h e l l o w o r l d " > 10 < / category> <view 12 name= " Hello View " icon=" icons / sample. g i f " 14 category= "com. example. h e l l o w o r l d " class="com. example. h e l l o w o r l d. HelloWorldView " 16 i d = "com. example. h e l l o w o r l d. HelloWorldView " > < / view> 18 < / extension> 20 < / p l u g i n > Listing 3.2: Exemple de chier plugin.xml Il est important de savoir qu'avant la version 3.1 d'eclipse, les informations du chier manifest.mf se trouvaient toutes dans l'unique chier plugin.xml. Mais les plug-ins créés avant la version 3.1 restent compatibles avec les versions suivantes. Le chier build.properties garde toutes les informations concernant les chiers, les dossiers, les librairies, etc qui seront insérées dans le chier JAR du plug-in, car ceux-ci lui sont nécessaires pour son fonctionnement. source.. = src / 2 output.. = bin / bin. i n c l u d e s = p l u g i n. xml, \ 4 META INF /, \., \ 6 icons / Listing 3.3: Exemple de chier build.properties La création des plug-ins est grandement facilitée grâce au PDE, dont nous avons déjà parlé à la section Car, celui-ci permet de congurer très facilement, à l'aide d'un assistant (wizard), ces trois chiers. La gure 3.8 montre une vue du PDE. L'interface

25 3.3. Plug-in 16 du PDE est divisée en neuf onglets. L'onglet, Overview, permet d'entrer toutes les informations relatives au plug-in, c'est-à-dire le nom, la version, etc. L'onglet, Dependencies, permet de gérer, comme son nom l'indique, les dépendances du plug-in. Celui du Runtime est utilisé pour indiquer des chemins d'accès à des librairies nécessaires au plug-in, mais aussi pour spécier quels packages seront exposés au client du plug-in. Grâce à l'onglet, Extensions, nous pouvons spécier celles qui sont étendues par celui-ci. L'onglet, Extension Points, permet d'indiquer les points d'extension que le plug-in met à dispositions des autres. L'onglet, Build, est utilisé pour spécier les chiers, les images, les dossiers, les librairies... qui seront insérés dans la JAR quand il sera compilé. Et les trois derniers onglets permettent d'accéder aux chiers, Extensible Markup Language ( XML), directement. Un autre chier très important est le chier Java qui étend la classe AbstractUIPlugin, si nous voulons créer un plug-in avec des interfaces graphiques, ou la classe Plugin dans le cas contraire. Cette classe est appelée Activator, elle gère le cycle de vie du plug-in. Mais, tous les plug-ins n'ont pas besoin de gérer leur cycle de vie. Par exemple, un plug-in qui étend l'aide d'eclipse n'en a pas besoin, car il est juste composé de chiers HTML et XML. La classe, AbstractUIPlugin, utilise le pattern Singleton, car le plug-in doit être unique bien sûr et contient trois méthodes : La méthode start(bundlecontext context) permet, si elle est ré-implémentée, d'entreprendre des actions quand le plug-in est lancé (cf. ligne 25 du listing 3.4). La méthode stop(bundlecontext context) sauve les préférences du plug-in et ferme l'image registry (cf. ligne 32 du listing 3.4). Ce dernier fournit au plug-in un endroit où stocker les images dont il a le plus besoin. Si nous ré-implémentons cette méthode, nous pouvons entreprendre des actions à la fermeture du plug-in. La méthode, ImageDescriptor getimagedescriptor(string path), permet simplement de localiser les images à l'intérieur même du plug-in (cf. ligne 51 du listing 3.4). Le chemin est relatif à la racine du plug-in. Pour plus d'informations, consultez l'api d'eclipse [1]. 1 package com. example. h e l l o w o r l d ; 3 import org. e c l i p s e. u i. p l u g i n. ; import org. e c l i p s e. j f a c e. resource. ImageDescriptor ; 5 import org. osgi. framework. BundleContext ; 7 / The main p l u g i n class to be used i n the desktop. 9 / public class H e l l o w o r l d P l u g i n extends A b s t r a c t U I P l u g i n { 11 / / The shared instance. 13 private s t a t i c H e l l o w o r l d P l u g i n p l u g i n ; 15 / The c o n s t r u c t o r. 17 / public H e l l o w o r l d P l u g i n ( ) { 19 p l u g i n = this ; } 21 / 23 This method i s c a l l e d upon plug i n a c t i v a t i o n / 25 public void s t a r t ( BundleContext context ) throws Exception { super. s t a r t ( context ) ; 27 } 29 / This method i s c a l l e d when the plug i n i s stopped

26 3.3. Plug-in / public void stop ( BundleContext context ) throws Exception { 33 super. stop ( context ) ; p l u g i n = null ; 35 } 37 / Returns the shared instance. 39 / public s t a t i c H e l l o w o r l d P l u g i n g e t D e f a u l t ( ) { 41 return p l u g i n ; } 43 / 45 Returns an image d e s c r i p t o r f o r the image f i l e at the given plug i n r e l a t i v e path. path the path the image d e s c r i p t o r / 51 public s t a t i c ImageDescriptor getimagedescriptor ( S t r i n g path ) { return A b s t r a c t U I P l u g i n. imagedescriptorfromplugin ( "com. example. h e l l o w o r l d ", path ) ; 53 } } Listing 3.4: Classe qui étend AbstractUIPlugin Extensions et points d'extension Un point d'extension est un point d'ancrage qu'ore un plug-in pour étendre ses fonctionnalités. Par exemple, la barre d'outils d'eclipse donne la possibilité de lui ajouter un bouton. Mais le mécanisme de point d'extension n'est pas seulement restreint aux éléments d'interface graphique ceci n'est qu'un exemple parmi tant d'autres. Le plug-in qui ore le point d'extension joue le rôle de coordinateur et de contrôleur du nombre des extensions. Un point d'extension est déclaré en ajoutant un élément extension-point XML au chier plugin.xml (cf. listing 3.5). 1 <?xml version= " 1.0 " encoding= "UTF 8"?> 3 <? e c l i p s e version= " 3.0 "?> < p l u g i n > 5 <extension p o i n t i d = " button " name= " button " schema= " schema / button. exsd " / > <extension 7 p o i n t = " org. e c l i p s e. u i. actionsets " > < actionset 9 i d = " org. vuichard. m a i l e r. actionset1 " l a b e l = " org. vuichard. m a i l e r. actionset1 " 11 v i s i b l e = " t r u e " > < a c t i o n 13 class=" org. vuichard. m a i ler. Open" icon=" icons / E mail. i c o " 15 i d = " org. vuichard. m a i l e r. open " l a b e l = " org. vuichard. m a i ler. open " 17 s t y l e = " push " toolbarpath=" / m a i l e r " / > 19 < / actionset> < / extension> Listing 3.5: Exemple de point d'extension tiré du Mailer Plugin La déclaration d'un tel élément se compose d'un id qui permet d'identier de manière unique un point d'extension, d'un nom et d'un schéma XML (cf. ligne 5 du listing 3.5) qui contient les spécications du point d'extensions (cf. listing 3.6).

27 3.3. Plug-in 18 1 <?xml version= 1.0 encoding= UTF 8?> 3 <! Schema f i l e w r i t t e n by PDE > <schema targetnamespace= " org. vuichard. m ai ler " > 5 < annotation > <appinfo> 7 <meta. schema p l u g i n = " org. vuichard. m ailer " i d = " button " name= " button " / > < / appinfo> 9 <documentation> [ Enter d e s c r i p t i o n of t h i s extension p o i n t. ] 11 < / documentation> < / annotation> 13 <element name= " extension " > 15 <complextype> <sequence> 17 <element r e f = " button " minoccurs= " 1 " maxoccurs= " unbounded " / > < / sequence> 19 < a t t r i b u t e name= " p o i n t " type= " s t r i n g " use= " r equired " > < annotation > 21 <documentation> 23 < / documentation> < / annotation> 25 < / a t t r i b u t e > < a t t r i b u t e name= " i d " type= " s t r i n g " > 27 < annotation > <documentation> 29 < / documentation> 31 < / annotation> < / a t t r i b u t e > 33 < a t t r i b u t e name= "name" type= " s t r i n g " > < annotation > 35 <documentation> 37 < / documentation> <appinfo> 39 <meta. a t t r i b u t e t r a n s l a t a b l e = " t r u e " / > < / appinfo> 41 < / annotation> < / a t t r i b u t e > 43 < / complextype> < / element> 45 <element name= " button " > 47 <complextype> < a t t r i b u t e name= "name" type= " s t r i n g " > Listing 3.6: Exemple de schéma : button.exsd L'extension est presque l'opération inverse du point d'extension, si l'on peut dire. L'utilisateur qui veut étendre les fonctionnalités d'un plug-in doit faire une extension d'un point d'extension. Une extension est déclarée en ajoutant un élément extension XML au chier plugin.xml (cf. listing 3.5). Mais tout ce mécanisme d'extension et de point d'extension est grandement facilité grâce au PDE qui assiste l'utilisateur que ce soit dans la création d'extension ou que ce soit dans la création d'un point d'extension. Le PDE fournit aussi un assistant pour créer les schémas des points d'extension Installation et cycle de vie d'un plug-in Il existe deux manières d'installer un plug-in. La première consiste à prendre l'archive JAR de la placer dans le dossier plugins situé dans le dossier eclipse, lancer sous Windows une invite de commande et taper la commande eclipse -clean depuis le dossier où se situe

28 3.4. Rich Client Application et Rich Client Platform 19 Eclipse. Le deuxième consiste à utiliser l'updater manager d'eclipse. Il permet d'installer et de mettre à jour les plug-ins. En plus, il permet de gérer tous les plug-ins installés, c'est-à-dire qu'on peut activer, désactiver et désinstaller les plug-ins grâce à lui. Un plug-in n'est activé qu'une fois qu'on fait appel à lui, sinon il reste désactivé pour ne pas ralentir les performances d'eclipse. Mais, les informations d'un plug-in sont toujours disponibles, même s'il est désactivé, ceci grâce au plug-ins registery qui maintient à jour les informations des plug-ins installés. Celles-ci viennent du manifest du plug-in dont l'explication a été faite à la section La désactivation des plug-ins ne se fait qu'à la fermeture d'eclipse. Tout ceci s'appelle la règle lazy loading rule. En eet, si nous devions charger tous les plug-ins au démarrage, cela prendrait énormément de temps. Car rien que l'environnement Java et Eclipse représentent soixante plug-ins à eux seuls Rich Client Application et Rich Client Platform Introduction Comme nous l'avons vu dans les sections précédentes, la plateforme Eclipse peut accueillir de nouveaux outils grâce à son mécanisme de plug-ins, mais elle peut aussi servir de RCP pour des rich client applications. Eclipse RCP n'est rien d'autre que la plateforme Eclipse dont on a gardé que les plug-ins de bases pour permettre la construction d'une application cliente, c'est dire le Plateform runtime, JFace, SWT et le Workbench (voir gure 3.1). Les rich client applications utilisent aussi le mécanisme de plug-in. Donc le développement d'une telle application est très proche de celle d'un plug-in comme nous pourrons le voir dans la section suivante Structure Une application RCP est constituée d'un plug-in. Comme nous l'avons vu dans la section 3.3.2, celui-ci est composé d'un Activator, d'un chier build.properties, d'un chier manifest.mf et d'un chier plugin.xml. Ce dernier n'est pas exactement le même que pour un plugin basique, car il doit dénir les deux points d'extension suivants, org.eclipse.core.runtime.applications et org.eclipse.ui.perspectives, qui caractérisent une application RCP (cf. listing 3.7). <?xml version= " 1.0 " encoding= "UTF 8"?> 2 <? e c l i p s e version= " 3.2 "?> < p l u g i n > 4 <extension 6 i d = " a p p l i c a t i o n " p o i n t = " org. e c l i p s e. core. runtime. a p p l i c a t i o n s " > 8 < a p p l i c a t i o n > <run 10 class=" h e l l o w o r l d. A p p l i c a t i o n " > < / run> 12 < / a p p l i c a t i o n > < / extension> 14 <extension p o i n t = " org. e c l i p s e. u i. perspectives " > 16 < perspective name= " Helloworld Perspective " 18 class=" h e l l o w o r l d. Perspective " i d = " HelloWorld. perspective " >

29 3.4. Rich Client Application et Rich Client Platform < / perspective > < / extension> 22 < / p l u g i n > Listing 3.7: Fichier plugin.xml d'une application RCP L'extension, org.eclipse.core.runtime.applications, permet de spécier le nom de l'application principale au runtime d'eclipse. Cette extension doit aussi fournir une classe (cf. ligne 10 du listing 3.7) qui implémente l'interface IPlatformRunnable. Cette classe contrôle tous les aspects de l'exécution de l'application (cf. listing 3.8). La méthode run(object args) de celle-ci crée et lance le workbench de l'application grâce à la méthode createandrunworkbench(display, new ApplicationWorkbenchAdvisor()). 1 package h e l l o w o r l d ; 3 import org. e c l i p s e. core. runtime. IPlatformRunnable ; import org. e c l i p s e. swt. widgets. Display ; 5 import org. e c l i p s e. u i. PlatformUI ; 7 / This class c o n t r o l s a l l aspects of the a p p l i c a t i o n s execution 9 / public class A p p l i c a t i o n implements IPlatformRunnable { 11 / ( non Javadoc ) org. e c l i p s e. core. runtime. IPlatformRunnable #run ( java. lang. Object ) / 15 public Object run ( Object args ) throws Exception { Display d i s p l a y = PlatformUI. createdisplay ( ) ; 17 t r y { i n t returncode = PlatformUI. createandrunworkbench ( display, 19 new ApplicationWorkbenchAdvisor ( ) ) ; i f ( returncode == PlatformUI.RETURN_RESTART) { 21 return IPlatformRunnable. EXIT_RESTART ; } 23 return IPlatformRunnable. EXIT_OK ; } f i n a l l y { 25 d i s p l a y. dispose ( ) ; } 27 } } Listing 3.8: Classe qui implémente l'interface IPlatformRunnable Comme nous pouvons le voir à la ligne 19 du listing 3.8, la méthode, createandrunworkbench(display, new ApplicationWorkbenchAdvisor()), a besoin en argument d'un ApplicationWorkbenchAdvisor. Cette classe (cf. listing 3.9) étend la classe abstraite, WorkbenchAdvisor, permet de gérer le workbench durant le cycle de vie de l'application et fournit la perspective par défaut dont nous parlerons par la suite. package h e l l o w o r l d ; 2 import org. e c l i p s e. u i. a p p l i c a t i o n. IWorkbenchWindowConfigurer ; 4 import org. e c l i p s e. u i. a p p l i c a t i o n. WorkbenchAdvisor ; import org. e c l i p s e. u i. a p p l i c a t i o n. WorkbenchWindowAdvisor ; 6 8 public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor { private s t a t i c f i n a l S t r i n g PERSPECTIVE_ID = " HelloWorld. perspective " ; 10 public WorkbenchWindowAdvisor createworkbenchwindowadvisor ( IWorkbenchWindowConfigurer c o n f i g u r e r ) { 12 return new ApplicationWorkbenchWindowAdvisor ( c o n f i g u r e r ) ; } 14

30 3.4. Rich Client Application et Rich Client Platform 21 public S t r i n g g e t I n i t i a l W i n d o w P e r s p e c t i v e I d ( ) { 16 return PERSPECTIVE_ID ; } 18 } Listing 3.9: Classe qui étend WorkbenchAdvisor La classe, ApplicationWorkbenchAdvisor, permet aussi de créer un WorkbenchWindowAdvisor. Cette classe (cf. listing 3.10) est utilisée pour congurer la status line, la barre d'outils, le titre, la taille de la fenêtre du workbench et pour créer un ActionBarAdvisor. Celui-ci est responsable de tout ce qui constitue une barre d'outils, c'est-à-dire les boutons, les menus, etc. mais aussi des actions correspondantes aux diérents éléments qui composent cette barre (cf. listing 3.11). package h e l l o w o r l d ; 2 import org. e c l i p s e. swt. graphics. Point ; 4 import org. e c l i p s e. u i. a p p l i c a t i o n. ActionBarAdvisor ; import org. e c l i p s e. u i. a p p l i c a t i o n. I A c t i o n B a r C o n f i g u r e r ; 6 import org. e c l i p s e. u i. a p p l i c a t i o n. IWorkbenchWindowConfigurer ; import org. e c l i p s e. u i. a p p l i c a t i o n. WorkbenchWindowAdvisor ; 8 public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor { 10 public ApplicationWorkbenchWindowAdvisor ( IWorkbenchWindowConfigurer c o n f i g u r e r ) { 12 super ( c o n f i g u r e r ) ; } 14 public ActionBarAdvisor createactionbaradvisor ( I A c t i o n B a r C o n f i g u r e r c o n f i g u r e r ) { 16 return new A p p l i c a t i o n A c t i o n B a r A d v i s o r ( c o n f i g u r e r ) ; } 18 public void prewindowopen ( ) { 20 IWorkbenchWindowConfigurer c o n f i g u r e r = getwindowconfigurer ( ) ; c o n f i g u r e r. s e t I n i t i a l S i z e (new Point (400, 300) ) ; 22 c o n f i g u r e r. setshowcoolbar ( false ) ; c o n f i g u r e r. setshowstatusline ( false ) ; 24 c o n f i g u r e r. s e t T i t l e ( " Hello RCP" ) ; } 26 } Listing 3.10: Classe qui étend WorkbenchWindowAdvisor package h e l l o w o r l d ; 2 import org. e c l i p s e. j f a c e. a c t i o n. IMenuManager ; 4 import org. e c l i p s e. u i. IWorkbenchWindow ; import org. e c l i p s e. u i. a p p l i c a t i o n. ActionBarAdvisor ; 6 import org. e c l i p s e. u i. a p p l i c a t i o n. I A c t i o n B a r C o n f i g u r e r ; 8 public class A p p l i c a t i o n A c t i o n B a r A d v i s o r extends ActionBarAdvisor { 10 public A p p l i c a t i o n A c t i o n B a r A d v i s o r ( I A c t i o n B a r C o n f i g u r e r c o n f i g u r e r ) { super ( c o n f i g u r e r ) ; 12 } 14 protected void makeactions ( IWorkbenchWindow window ) { } 16 protected void f i l l M e n u B a r ( IMenuManager menubar ) { 18 } 20 } Listing 3.11: Classe qui étend ActionBarAdvisor L'extension org.eclipse.core.runtime.applications ayant été décrite, nous pouvons passer à la seconde extension, org.eclipse.ui.perspectives (cf. listing 3.7). Celle-ci permet de spécier le

31 3.5. Conclusion 22 nom et la classe de la perspective par défaut. Une perspective est un ensemble de vues, d'éditeurs et de menus. La classe, Perspective (cf. ligne 18 du listing 3.7), qui étend la classe, IPerspectiveFactory, permet d'initialiser la perspective, c'est-à-dire donner le positionnement et la taille des diérentes vues et diérents éditeurs. package h e l l o w o r l d ; 2 import org. e c l i p s e. u i. IPageLayout ; 4 import org. e c l i p s e. u i. I P e r s p e c t i v e F a c t o r y ; 6 public class Perspective implements I P e r s p e c t i v e F a c t o r y { 8 public void c r e a t e I n i t i a l L a y o u t ( IPageLayout l a y o u t ) { } 10 } Listing 3.12: Classe qui étend IPerspectiveFactory 3.5. Conclusion Dans ce chapitre, nous avons découvert le mécanisme de plug-in oert par la plateforme Eclipse qui l'a compose elle-même et qui permet aussi de l'étendre. Pour cela, nous avons vu l'architecture d'eclipse et la structure d'un plug-in. Et, grâce à l'étude de la structure d'une rich client application, nous avons aussi découvert qu'eclipse était une RCP permettant de développer des applications RCP.

32 4 Exemple de Plug-in : Mailer Plugin 4.1. Introduction Construction du Mailer Plugin Création du Plug-in project Ajout de l'api Javamail et du framework JAF au projet Ajout des extensions Les diérentes fenêtres du Mailer Plugin Le point d'extension du Mailer Plugin Fonctionnement du Mailer Plugin Construction du Mailer : version rich client application Création du Plug-in project Ajout des extensions Amélioration possible Conclusion Introduction Ce plug-in a été créé avant tout pour comprendre le mécanisme des plug-ins dans Eclipse et saisir les diérents aspects de la plateforme. Celui-ci a été développé grâce à la version 3.2 d'eclipse. Il permet d'envoyer et de recevoir des s depuis la plateforme Eclipse. Il utilise l'api JavaMail 1.4 qui elle-même a besoin du framework JavaBeans Activation Framework (JAF) pour fonctionner. Cet API de Java gère les communications entre le client et le serveur d' s, mais aussi permet de travailler très facilement avec les messages. Le site internet [2] ore toutes les informations complémentaires sur cette API. Le plug-in consiste en un bouton dans la barre d'outils d'eclipse qui permet l'ouverture de l'application, elle-même, et d'une page dans la boîte de dialogue des préférences d'eclipse qui permet la conguration du plug-in Mailer. Ce sont les deux points d'extension qu'étend le plug-in. Celui-ci permet aussi d'ajouter des boutons à sa propre barre d'outils en orant un point d'extension que d'autres plug-ins peuvent étendre. Dans les sections suivantes, les diérentes étapes de la création du plug-in seront expliquées, mais aussi l'utilisation et la conguration de celui-ci. 23

33 4.2. Construction du Mailer Plugin Construction du Mailer Plugin Création du Plug-in project Pour commencer nous devons créer un Plug-in project, il sut d'aller dans le menu File, de cliquer sur New, puis sur Project... et de choisir Plug-in project. L'assistant pour les Plug-in projects apparaît. Sur la première page de l'assistant, nous complétons le Project name avec le nom du projet qui est org.vuichard.mailer. Nous laissons les autres champs tels quels, car nous voulons garder les dossiers source, src, et output, bin et notre plug-in est prévu pour la version 3.2 d'eclipse. Sur la deuxième page, nous entrons les informations sur le plug-in, c'est-à-dire l'id, la version, le nom, le fournisseur du plug-in, comme sur la gure 4.1, nous donnons un nom à la classe qui contrôlera le cycle de vie de notre plug-in, nous cochons la case, This plug-in will make a contribution to the UI, car cela est notre cas et à la question, Would you like to create a rich client application?, nous cochons la case, No, parce que nous voulons créer un plug-in et non pas une rich client application. Fig. 4.1.: Vue de la deuxième page de l'assistant de création de Plug-in project Ensuite, sur la dernière page (voir gure 4.2), comme nous ne voulons pas utiliser de template, nous décochons la case, Create plug-in using one of the templates. Nous cliquons sur Finish et notre projet apparaît dans la vue, package explorer et l'éditeur du PDE s'ouvre avec les informations que nous avons introduites auparavant (voir gure 4.3).

34 4.2. Construction du Mailer Plugin 25 Fig. 4.2.: Vue de la dernière page de l'assistant de création de Plug-in project Ajout de l'api Javamail et du framework JAF au projet Une fois le projet créé, nous pouvons copier directement l'api et le framework nécessaires au fonctionnement de notre plug-in, mail.jar et activation.jar dans le projet. Une fois, les deux chiers copiés, il faut encore les ajouter au classpath. Pour cela, il sut de cliquer avec le bouton droit de la souris sur le chier JAR, d'aller dans le menu Build Path et de cliquer sur add to Build Path (voir gure 4.4). Bien sûr, il faut répéter l'opération pour les deux chiers. Une fois cette opération terminée, il faut encore aller dans l'onglet Runtime du PDE (voir gure 4.5) et ajouter dans la case Classpath les deux chiers, mais aussi le dossier bin où se trouvent les classes compilées du projet, sinon lors de l'exécution du plug-in les classes ne seront pas trouvées ce qui provoquerait une erreur Ajout des extensions Maintenant, nous pouvons attaquer le vif du sujet, c'est-à-dire, étendre la plateforme Eclipse, car pour l'instant notre plug-in fonctionne, mais ne fait rien d'intéressant. Comme il a été expliqué à la section précédente, nous allons créer la première des deux extensions, le bouton. Tout d'abord, il faut aller sur l'onglet Extension du PDE. Ensuite, il faut

35 4.2. Construction du Mailer Plugin 26 Fig. 4.3.: Vue du PDE cliquer sur ADD et choisir org.eclipse.ui.actionsets dans la liste des extensions (voir gure 4.6). Nous utilisons ce point d'extension, car il permet d'ajouter des menus, des sousmenus et des boutons à la barre d'outils de la fenêtre du Workbench. Les boutons, les menus, etc sont regroupés dans des Action Sets, ainsi l'utilisateur peut limiter l'achage de ces diérents éléments dans le Workbench en allant dans le menu Window et cliquant sur Customize Perspective... Si vous ne trouveriez pas l'extension souhaitée dans la liste, il faut vérier dans l'onglet Dependencies du PDE que vous avez ajouté les plug-ins que vous voulez étendre. Dans notre cas, la dépendance du plug-in que nous voulons étendre a été ajoutée à la création du projet. Toutes les informations à propos des extensions possibles se trouvent dans l'aide d'eclipse [4]. Puis, nous ajoutons un actionset en cliquant avec le bouton droit, nous allons dans le menu New et sélectionnons ActionSet. Nous entrons l'id et le nom de notre actionset et nous mettons visible à true (voir gure 4.7). Cette dernière manipulation a pour eet de rendre le bouton visible dans la barre d'outils. Une fois ceci fait, nous ajoutons une action à notre actionset en cliquant avec le bouton droit sur actionset et en sélectionnant action dans le menu New. Nous congurons notre action en lui donnant un id, un nom, une icône et surtout une classe qui gère l'action du bouton (voir gure 4.8). Cette classe peut être très facilement créée, il sut d'entrer le nom dans le champ class et de cliquer sur class :. Ainsi, un assistant s'ouvre pour nous aider à la création de cette classe (voir gure 4.9).

36 4.2. Construction du Mailer Plugin 27 Fig. 4.4.: Vue du menu pour ajouter une ressource au classpath 2 A ce stade de la création du plug-in, notre bouton apparaît dans la barre d'outils, mais si l'on clique dessus rien ne se passe. Car il faut encore ajouter quelques lignes de code à la classe que nous avons générée juste avant grâce au PDE. Nous ajoutons dans la méthode run(iaction action) de notre classe Open, qui implémente l'interface IWorkbench- WindowActionDelegate, les deux premières lignes (lignes 27-28) qui permettent d'ouvrir la fenêtre principale du mailer, Mail_GUI, dont nous parlerons dans la section suivante package org. vuichard. m a i l e r ; 4 public class Open implements IWorkbenchWindowActionDelegate { 6 / ( non Javadoc ) org. e c l i p s e. u i. IWorkbenchWindowActionDelegate#dispose ( ) / 10 public void dispose ( ) { 12 } 14 / ( non Javadoc org. e c l i p s e. u i. IWorkbenchWindowActionDelegate# i n i t ( org. e c l i p s e. u i. IWorkbenchWindow ) 16 / public void i n i t ( IWorkbenchWindow window ) { }

37 4.2. Construction du Mailer Plugin 28 Fig. 4.5.: Vue de l'onglet runtime du PDE 22 / ( non Javadoc org. e c l i p s e. u i. IActionDelegate #run ( org. e c l i p s e. j f a c e. a c t i o n. I A c t i o n ) 24 / public void run ( I A c t i o n a c t i o n ) { 26 Mail_GUI gui = Mail_GUI. getinstance ( ) ; 28 gui. i n i t ( ) ; 30 t r y { 32 ProcessServiceMembers. process ( gui ) ; } 34 catch ( WorkbenchException e ) { e. p r i ntstacktrace ( ) ; 36 } 38 } 40 / ( non Javadoc ) org. e c l i p s e. u i. IActionDelegate #selectionchanged ( org. e c l i p s e. j f a c e. a c t i o n. I A c t i o n, org. e c l i p s e. j f a c e. viewers. I S e l e c t i o n ) / 44 public void selectionchanged ( I A c t i o n action, I S e l e c t i o n s e l e c t i o n ) { } } Listing 4.1: Classe Open qui implémente IWorkbenchWindowActionDelegate Nous en avons ni avec la première extension, nous pouvons passer à l'extension des préférences d'eclipse. Nous allons ajouter une page aux préférences qui nous permettra de congurer le Mailer pour la connexion au serveur d' donner le nom du serveur

38 4.2. Construction du Mailer Plugin 29 Fig. 4.6.: Ajout de l'extension org.eclipse.ui.actionsets Post Oce Protocol (POP) ou Internet Message Access Protocol (IMAP) et Simple Mail Transfer Protocol (SMTP), l'adresse , le login et le mot de passe de l'utilisateur (voir gure 4.10). Pour étendre les préférences, il faut faire deux extensions : org.eclipse.core.runtime.preferences et org.eclipse.ui.preferencepages. La première permet à la plateforme Eclipse d'initialiser les valeurs par défaut de nos préférences et la deuxième se rapporte à la conception graphique de notre page des préférences. Comme pour la première extension, nous allons sur l'onglet Extension du PDE, cliquons sur ADD et choisissons dans la liste org.eclipse.core.runtime.preferences. Nous faisons de même pour org.eclipse.ui.preferencepages. Nous ajoutons au premier un initializer, en cliquant dessus avec le bouton droit et en allant dans le menu New (voir gure 4.11), et nous donnons un nom de classe à celui-ci, puis nous cliquons sur class : pour la générer.

39 4.2. Construction du Mailer Plugin 30 Fig. 4.7.: Ajout d'un actionset Nous procédons de la même manière pour ajouter une page aux preferencepages (voir gure 4.12). Nous entrons l'id, le nom de la page et nous donnons un nom à la classe qui gérera l'interface graphique de notre page (voir gure 4.13). Cette classe, MailerPreferencePage, étend FieldEditorPreferencePage et implémente IWorkbenchPreferencePage (cf. listing 4.2). 1 package org. vuichard. m a i l e r. preferences ; 3 import org. e c l i p s e. j f a c e. preference. ; 5 import org. e c l i p s e. u i. IWorkbenchPreferencePage ; import org. e c l i p s e. u i. IWorkbench ; 7 import org. vuichard. m a i l e r. M a i l e r P l u g i n ; 9 / This class represents a preference page t h a t 11 i s c o n t r i b u t e d to the Preferences d i a l o g. By subclassing <samp>fieldeditorpreferencepage </ samp>, we 13 can use the f i e l d support b u i l t i n t o JFace t h a t allows us to create a page t h a t i s small and knows how to 15 save, r e s t o r e and apply i t s e l f. <p> 17 This page i s used to modify preferences only. They are stored i n the preference s t o r e t h a t belongs to 19 the main plug i n class. That way, preferences can be accessed d i r e c t l y v i a the preference s t o r e. 21 / 23 public class MailerPreferencePage extends FieldEditorPreferencePage 25 implements IWorkbenchPreferencePage {

40 4.2. Construction du Mailer Plugin 31 Fig. 4.8.: Conguration de l'action 27 public MailerPreferencePage ( ) { super (GRID) ; 29 setpreferencestore ( M a i l e r P l u g i n. g e t D e f a u l t ( ). getpreferencestore ( ) ) ; s e t D e s c r i p t i o n ( " M a i l e r c o n f i g u r a t i o n " ) ; 31 } 33 / Creates the f i e l d e d i t o r s. F i e l d e d i t o r s are a b s t r a c t i o n s of 35 the common GUI blocks needed to manipulate various types of preferences. Each f i e l d e d i t o r knows how to save and 37 r e s t o r e i t s e l f. / 39 public void c r e a t e F i e l d E d i t o r s ( ) { 41 addfield (new S t r i n g F i e l d E d i t o r ( PreferenceConstants. P_ , "&e mail adress : ", g e t F i e l d E d i t o r P a r e n t ( ) ) ) ; 43 addfield (new S t r i n g F i e l d E d i t o r ( PreferenceConstants.P_SMTP, 45 "&SMTP server address : ", g e t F i e l d E d i t o r P a r e n t ( ) ) ) ; 47 addfield (new RadioGroupFieldEditor ( PreferenceConstants. P_CHOICE, 49 "&Select your p r o t o c o l ", 1, 51 new S t r i n g [ ] [ ] { { "&IMAP", " imap " }, { "&POP3", " pop3 " } 53 }, g e t F i e l d E d i t o r P a r e n t ( ) ) ) ; 55 addfield (new S t r i n g F i e l d E d i t o r ( PreferenceConstants.P_POP3, "&Server address : ", g e t F i e l d E d i t o r P a r e n t ( ) ) ) ; 57

41 4.2. Construction du Mailer Plugin 32 Fig. 4.9.: Assistant de création de classe Java pour notre classe Open 59 addfield (new S t r i n g F i e l d E d i t o r ( PreferenceConstants. P_LOGIN, "&User Login : ", g e t F i e l d E d i t o r P a r e n t ( ) ) ) ; 61 S t r i n g F i e l d E d i t o r pass = new S t r i n g F i e l d E d i t o r ( PreferenceConstants.P_PASSWORD, 63 "&Password : ", g e t F i e l d E d i t o r P a r e n t ( ) ) ; pass. gettextcontrol ( g e t F i e l d E d i t o r P a r e n t ( ) ). setechochar ( ) ; 65 addfield ( pass ) ; 67 } 69 / ( non Javadoc org. e c l i p s e. u i. IWorkbenchPreferencePage# i n i t ( org. e c l i p s e. u i. IWorkbench ) 71 / public void i n i t ( IWorkbench workbench ) { 73 } 75 } Listing 4.2: Page de préférence du Mailer

42 4.2. Construction du Mailer Plugin 33 Fig : Page de préférence du Mailer Plugin La méthode createfieldeditors() est la plus importante. C'est elle qui permet de mettre en place les diérents champs de notre page (voir gure 4.13). Il existe plusieurs sortes de champs que nous pouvons ajouter : StringFieldEditor, IntegerFieldEditor, etc. Pour avoir une liste complète des champs possibles, il sut de suivre ce lien de l'aide d'eclipse [8]. L'ajout de champ doit être écrit à la main, car il n'existe pas d'assistant pour nous aider dans cette tâche. Voilà, maintenant les extensions sont terminées, nous pouvons passer à l'application, elle-même, et ses diérentes fenêtres. Nous pouvons voir sur le diagramme de classes (voir gure 4.14) les diérentes classes que nous avons déjà créées jusqu'à présent Les diérentes fenêtres du Mailer Plugin Le Mailer Plug-in est composé de trois fenêtres. La fenêtre principale (voir gure 4.15) permet de consulter les s. Cette fenêtre, Mail_GUI, a été développée à partir de composants SWT (voir section 3.2.3) et est un Shell de SWT. Ce Shell est composé d'un menu (org.eclipse.swt.widgets.menu), d'une barre d'outils (org.eclipse.swt.widgets.toolbar) qui, elle-même, possède plusieurs boutons (org.eclipse.swt.widgets.toolitem), d'un tableau (org.eclipse.swt.widgets.table) et d'un arbre (org.eclipse.swt.widgets.tree). La deuxième fenêtre, Dialsendmail (voir gure 4.16), est une boîte de dialogue qui permet d'envoyer des s. Elle étend org.eclipse.jface.dialogs.dialog qui est un élément de JFace (voir 3.2.4). Cette boite de dialogue réunit plusieurs champs qui permettent de composer

43 4.2. Construction du Mailer Plugin 34 Fig : Conguration de l'initializer et d'envoyer un message : l'adresse du destinataire, le texte du message, la pièce jointe, etc. La dernière fenêtre, ImageViewer (voir gure 4.17), permet de voir les images contenues dans un . Dialsendmail étend javax.swing.jframe. Comme nous pouvons le constater, JFrame est un des éléments de l'api Swing. En eet, il n'est pas obligatoire d'utiliser des composants de JFace ou de SWT pour construire un plug-in. Cet exemple nous permet de voir la diérence entre JFace/SWT et Swing/Abstract Windowing Toolkit (AWT). Cette fenêtre s'ouvre automatiquement pour chaque image contenue dans le message Le point d'extension du Mailer Plugin Le plug-in Mailer doit orir la possibilité d'ajouter un bouton à sa propre barre d'outils. Pour cela, nous allons commencer par déclarer notre point d'extension. Nous allons dans l'onglet Extensions Points et cliquons sur ADD (voir gure 4.18). Un assistant s'ouvre alors (voir gure 4.19) et nous entrons les données relatives à notre point d'extension : l'id, le nom et le nom du schéma. L'assistant de création de schéma s'ouvre (voir gure 4.20), nous cliquons sur New Element pour ajouter un élément button. Puis nous ajoutons les attributs : name qui est le nom du bouton, class qui est la classe qui gère l'action du bouton et path qui est le chemin pour accéder à l'image qui gurera sur le bouton en cliquant sur New Attribut. Nous devons encore modier la grammaire de notre point d'extension, nous cliquons sur extension et en

44 4.2. Construction du Mailer Plugin 35 Fig : Ajout d'une page de préférences suite sur sequence. Nous modions le paramètre, maxoccurs, en le mettant à unbounded (voir gure 4.20). Ainsi, notre plug-in accepte toutes les extensions d'ajout de boutons sans exception. 1 package org. vuichard. m a i l e r. extension ; 3 import org. e c l i p s e. core. runtime. CoreException ; import org. e c l i p s e. core. runtime. IConfigurationElement ; 5 import org. e c l i p s e. core. runtime. IExtension ; import org. e c l i p s e. core. runtime. I E x t e n s i o n P o i n t ; 7 import org. e c l i p s e. core. runtime. I E x t e n s i o n R e g i s t r y ; import org. e c l i p s e. core. runtime. Platform ; 9 import org. e c l i p s e. u i. WorkbenchException ; import org. vuichard. m a i l e r. GUI. Mail_GUI ; 11 public class ProcessServiceMembers { 13 private s t a t i c f i n a l S t r i n g EXTENSION_POINT = " org. vuichard. mailer. button " ; 15 private s t a t i c f i n a l S t r i n g BUTTON_NAME_ATTRIBUTE = "name" ; private s t a t i c f i n a l S t r i n g CLASS_ATTRIBUTE = " class " ; 17 private s t a t i c f i n a l S t r i n g PATH_ATTRIBUTE = " path " ; 19 public s t a t i c void process ( Mail_GUI m ai ler ) throws WorkbenchException { I E x t e n s i o n R e g i s t r y r e g i s t r y = Platform. getextensionregistry ( ) ; 21 I E x t e n s i o n P o i n t extensionpoint = r e g i s t r y. getextensionpoint (EXTENSION_POINT) ; i f ( extensionpoint == null ) { 23 throw new WorkbenchException ( " unable to resolve extension p o i n t : " + EXTENSION_POINT) ; 25 } IConfigurationElement [ ] members = extensionpoint. getconfigurationelements ( ) ; 27 for ( i n t m = 0; m < members. l e n g t h ; m++) { 29 IConfigurationElement member = members [m] ;

45 4.2. Construction du Mailer Plugin 36 Fig : Conguration de la page de préférences 31 IExtension extension = member. getdeclaringextension ( ) ; S t r i n g pluginlabel = extension. getnamespaceidentifier ( ) ; / / getnamespace ( ) ; 33 i f ( pluginlabel == null ) { pluginlabel = " [ unnamed p l u g i n ] " ; 35 } 37 S t r i n g buttontext = member. g e t A t t r i b u t e (BUTTON_NAME_ATTRIBUTE) ; S t r i n g pathtext = member. g e t A t t r i b u t e (PATH_ATTRIBUTE) ; 39 i f ( buttontext == null ) { buttontext = " [ unnamed button ] " ; 41 } 43 I F u n c t i o n proxy = new FunctionProxy (member) ; 45 m a i l e r. add ( proxy, buttontext, pluginlabel, pathtext ) ; } 47 } 49 private s t a t i c class FunctionProxy implements I F u n c t i o n { 51 private I F u n c t i o n delegate = null ; 53 private IConfigurationElement element ; private boolean invoked = false ; public FunctionProxy ( IConfigurationElement element ) { this. element = element ; 59 } 61 public f i n a l void run ( ) {

46 4.2. Construction du Mailer Plugin 37 Fig : Diagramme de classes du Mailer Plugin : première partie 63 t r y { getdelegate ( ) ; 65 } catch ( Exception ex ) { 67 } 69 i f ( delegate == null ) { 71 } delegate. run ( ) ; 73 } 75 private f i n a l I F u n c t i o n getdelegate ( ) throws Exception { 77 i f ( invoked ) { return delegate ; 79 } invoked = true ; 81 t r y { Object c a l l b a c k = element. createexecutableextension ( CLASS_ATTRIBUTE) ; 83 i f (! ( c a l l b a c k instanceof I F u n c t i o n ) ) { S t r i n g message = 85 " c a l l b a c k class " + c a l l b a c k. getclass ( ). getname ( ) 87 + " i s not an I F u n c t i o n " ; System. e r r. p r i n t l n ( message ) ; 89 throw new ClassCastException ( message ) ; }

47 4.2. Construction du Mailer Plugin 38 Fig : Fenêtre principale du Mailer Plugin 91 delegate = ( I F u n c t i o n ) c a l l b a c k ; } 93 catch ( CoreException ex ) { System. e r r. p r i n t l n ( ex. getmessage ( ) ) ; 95 ex. p r i ntstacktrace ( ) ; throw ex ; 97 } catch ( E r r o r e r r ) { 99 System. e r r. p r i n t l n ( e r r. getmessage ( ) ) ; e r r. p r i n t S t acktrace ( ) ; 101 throw e r r ; } 103 return delegate ; } 105 } } Listing 4.3: Classe ProcessServiceMembers Il nous reste à créer la classe ProcessServiceMembers (cf. listing 4.3). La méthode, process(mail_gui mailer), de cette classe permet de trouver tous les plug-ins qui étendent notre point d'extension et pour chaque extension, elle instancie un virtual proxy de la fonction du bouton, dont nous expliquerons l'utilité par après, et elle ajoute un bouton

48 4.2. Construction du Mailer Plugin 39 Fig : Fenêtre d'envoi de message Fig : Fenêtre : ImageViewer grâce à la méthode, add(ifunction f,string buttontext,string pluginlabel,string pathtext) (cf. listing 4.5), de la classe, Mail_Gui. Cette méthode ajoute pour chaque extension un bouton avec le texte donné par l'utilisateur du point d'extension et le listener correspondant. La classe interne, FunctionProxy, se charge d'instancier la classe qui implémente IFunction.

49 4.2. Construction du Mailer Plugin 40 Fig : Onglet Extensions Points 1 package org. vuichard. m a i l e r. extension ; 3 public interface I F u n c t i o n { 5 public void run ( ) ; } Listing 4.4: Interface IFunction Celle-ci a été créée par l'utilisateur du point d'extension et est responsable de l'action du bouton. Nous utilisons la classe, FunctionProxy, pour retarder l'instanciation jusqu'à ce que le bouton soit utilisé évitant ainsi la surcharge de la mémoire avec des objets qui ne sont pas encore utilisés. 1 public void add ( I F u n c t i o n f, S t r i n g b u t t o n t e x t, S t r i n g pluginlabel, S t r i n g pathtext ) { ToolItem Separator7 = new ToolItem ( toolbar, SWT.SEPARATOR) ; 3 ToolItem button = new ToolItem ( toolbar, SWT.PUSH) ; 5 f u n c t i o n = f ; 7 t r y { ImageDescriptor i d = ImageDescriptor. createfromurl (new URL( Platform. getbundle ( pluginlabel ). getentry ( ". / " ), pathtext ) ) ; 9 button. settext ( b u t t o n t e x t ) ; button. setimage ( i d. createimage ( t o o l B a r. getdisplay ( ) ) ) ; } catch ( Exception x ) { x. p rintstacktrace ( ) ; }

50 4.2. Construction du Mailer Plugin 41 Fig : Assistant de création de point d'extension button 15. a d d S e l e c t i o n L i s t e n e r (new org. e c l i p s e. swt. events. S e l e c t i o n L i s t e n e r ( ) { public void widgetselected ( org. e c l i p s e. swt. events. SelectionEvent e ) { 17 f u n c t i o n. run ( ) ; 19 } public void widgetdefaultselected ( 21 org. e c l i p s e. swt. events. SelectionEvent e ) { } } } ) ; Listing 4.5: Méthode add(ifunction f,string buttontext,string pluginlabel,string pathtext) de la classe Mail_Gui Voilà comment cela fonctionne : Au démarrage du plug-in (cf. ligne 32 du listing 4.1), la méthode, process(mail_gui mailer) trouve une extension et ajoute le bouton correspondant à la barre d'outils. Puis lorsque le bouton est pressé (cf. ligne 15 du listing 4.5), le virtual

51 4.3. Fonctionnement du Mailer Plugin 42 proxy de la fonction se charge d'instancier la fonction liée au bouton, si c'est la première pression, et applique la méthode run() qui, par exemple, va ouvrir une boîte de dialogue. Nous pouvons voir sur le diagramme de classes (voir gure 4.21) l'ensemble des classes que nous avons créées. Fig : Assitant de création de schéma 4.3. Fonctionnement du Mailer Plugin Pour commencer, il faut installer le Mailer plug-in (voir section 3.3.4). Une fois l'installation terminée, le Mailer a besoin d'être conguré. Pour cela, il sut d'aller dans le menu Windows d'eclipse et de cliquer sur Preferences. La boîte de dialogue apparaît, il faut choisir la page Mailer Preferences et compléter tous les champs de la page avec ses données personnelles (voir gure 4.10). Maintenant le Mailer Plug-in est prêt à être utilisé. Pour récupérer les s sur le serveur, il faut appuyer sur le bouton Receive de la barre d'outils ou il est aussi possible de cliquer sur le dossier, Inbox, dans l'arborescence des dossiers située à gauche de la fenêtre, Mail_GUI (voir Figure 4.22). Une fois les messages reçus, il sut de sélectionner un message pour le lire (voir gure 4.23). Pour envoyer un , il existe deux possibilités : soit nous pouvons cliquer sur le bouton New Message soit nous pouvons aller dans le menu File et cliquer sur New Message. Alors la fenêtre d'envoi de message (voir gure 4.16) s'ouvre et il sut de la compléter avec les informations nécessaires à l'envoi de l' . Pour supprimer un message, il faut sélectionner celui-ci et appuyer tout simplement sur le bouton Delete dans la barre d'outils. Pour répondre à un message, il faut sélectionner celui-ci et presser sur le bouton Reply. Alors

52 4.3. Fonctionnement du Mailer Plugin 43 Fig : Diagramme de classes complet du Mailer Plugin la même boîte d'envoi que pour l'envoi d' s'ouvre et il sut de la compléter pour répondre à l' . Pour transmettre un message et répondre à tous les expéditeurs, il en va de même que pour répondre à un , la seule diérence c'est qu'il faut cliquer

53 4.4. Construction du Mailer : version rich client application 44 Fig : Arborescence des dossiers sur le bouton Forward pour transmettre et sur le bouton Reply to all pour répondre à tous. L'impression d'un message peut se faire de deux manières : soit en sélectionnant le message et en cliquant sur le bouton Print de la barre d'outils, soit en sélectionnant le message, puis en allant dans le menu File et en appuyant sur Print Construction du Mailer : version rich client application Cette application que nous voulons construire n'est rien d'autre que le Mailer Plugin transformé en une rich client application. Donc dans cette section, nous ne parlerons pas des diérentes fenêtres du Mailer Plugin et de l'ajout de l'api Javamail et du framework JAF, car cela a déjà été expliqué dans la section précédente. Comme nous l'avons vu à la section 3.4, les rich client applications sont basées sur le mécanisme de plug-in. C'est pour cela que la création du MailerRCP est très similaire à celle du Mailer Plugin Création du Plug-in project Pour créer ce Plug-in project, nous procédons de la même manière que pour le Mailer Plugin (cf. section 4.2.1) à quelques diérences près. Tout d'abord, nous complétons les champs de la première page de l'assistant comme sur la gure Sur la seconde page, nous laissons les champs tels quels, mais nous cochons bien évidement la case, Yes, pour

54 4.4. Construction du Mailer : version rich client application 45 Fig : Vue d'un la question, Would you like to create a rich client application? (voir gure 4.25). Nous cliquons sur Next et nous arrivons sur la dernière page de l'assistant (voir gure 4.26). Sur cette page nous cochons la case, Create a plug-in using one of the templates, sélectionnons le template, RCP Application with an intro, pressons sur le bouton Finish et ainsi le projet est créé avec les extensions et les classes nécessaires à une rich client application, comme nous l'avons vu à la sous-section Ajout des extensions Dans la version plug-in du Mailer, l'application était ouverte grâce à un bouton. Mais dans celle-ci, l'application s'ouvre grâce à un menu du workbench (voir gure 4.27). Pour cela, nous devons modier la classe, ApplicationActionBarAdvisor, qui permet de congurer et d'ajouter des menus, des boutons, etc. à la barre d'outils. Cette classe a été générée automatiquement à la création du projet. Tout d'abord, nous créons le menu, File en ajoutant les trois premières lignes à la méthode, fillmenubar(imenumanager menubar) (cf. listing 4.6). Ce menu contiendra le sous-menu, Open Mailer, qui lancera le Mailer.

55 4.4. Construction du Mailer : version rich client application 46 Fig : Vue de la première page de l'assistant de création de Plug-in project 1 package m a i l e r r c p ; 3 import org. e c l i p s e. j f a c e. a c t i o n. GroupMarker ; import org. e c l i p s e. j f a c e. a c t i o n. IMenuManager ; 5 import org. e c l i p s e. j f a c e. a c t i o n. MenuManager ; import org. e c l i p s e. u i. IWorkbenchActionConstants ; 7 import org. e c l i p s e. u i. IWorkbenchWindow ; import org. e c l i p s e. u i. a c t i o n s. ActionFactory ; 9 import org. e c l i p s e. u i. a c t i o n s. ActionFactory. IWorkbenchAction ; import org. e c l i p s e. u i. a p p l i c a t i o n. ActionBarAdvisor ; 11 import org. e c l i p s e. u i. a p p l i c a t i o n. I A c t i o n B a r C o n f i g u r e r ; 13 public class A p p l i c a t i o n A c t i o n B a r A d v i s o r extends ActionBarAdvisor { private IWorkbenchAction p r e f e r e n c e a c t i o n ; 15 private Open openaction ; public A p p l i c a t i o n A c t i o n B a r A d v i s o r ( I A c t i o n B a r C o n f i g u r e r c o n f i g u r e r ) { 17 super ( c o n f i g u r e r ) ; 19 }

56 4.4. Construction du Mailer : version rich client application 47 Fig : Vue de la deuxième page de l'assistant de création de Plug-in project 21 protected void makeactions ( IWorkbenchWindow window ) { p r e f e r e n c e a c t i o n = ActionFactory.PREFERENCES. create ( window ) ; 23 r e g i s t e r ( p r e f e r e n c e a c t i o n ) ; openaction = new Open ( " Open Ma ile r ", window ) ; 25 r e g i s t e r ( openaction ) ; } 27 protected void f i l l M e n u B a r ( IMenuManager menubar ) { 29 MenuManager filemenu = new MenuManager ( "& F i l e ", IWorkbenchActionConstants.M_WINDOW) ; menubar. add ( filemenu ) ; 31 menubar. add (new GroupMarker ( IWorkbenchActionConstants. MB_ADDITIONS) ) ; filemenu. add ( p r e f e r e n c e a c t i o n ) ; 33 filemenu. add ( openaction ) ; } 35 } Listing 4.6: Classe ApplicationActionBarAdvisor

57 4.4. Construction du Mailer : version rich client application 48 Fig : Vue de la dernière page de l'assistant de création de Plug-in project Pour ajouter ce sous-menu, nous devons créer la classe, Open, qui étend la classe abstraite, Action (cf. listing 4.7). Nous ajoutons les deux premières lignes à la méthode, run(), qui permettent d'ouvrir la fenêtre principale, Mail_GUI. Maintenant, nous instancions notre action dans la méthode, makeactions(iworkbenchwindow window), de la classe, ApplicationActionBarAdvisor et nous mettons notre sous-menu en place grâce à la ligne 33 du listing package m a i l e r r c p ; 3 import m a i l e r r c p. ICommandIds ; import org. e c l i p s e. j f a c e. a c t i o n. Action ; 5 import org. e c l i p s e. u i. IWorkbenchWindow ; import m a i l e r r c p. GUI. Mail_GUI ; 7 9 public class Open extends Action { 11 private f i n a l IWorkbenchWindow window ;

58 4.4. Construction du Mailer : version rich client application 49 Fig : Vue de la rich client application 13 Open ( S t r i n g t e x t, IWorkbenchWindow window ) { super ( t e x t ) ; 15 this. window = window ; s e t I d ( ICommandIds.CMD_OPEN_MESSAGE) ; 17 s e t A c t i o n D e f i n i t i o n I d ( ICommandIds.CMD_OPEN_MESSAGE) ; 19 } 21 public void run ( ) { 23 Mail_GUI gui = Mail_GUI. getinstance ( ) ; gui. i n i t ( ) ; 25 } 27 } Listing 4.7: Classe Action Pour l'extension des préférences d'eclipse, nous procédons de la même façon que pour le Mailer Plugin (cf. sous-section 4.2.3). Mais, il faut en plus ajouter le sous-menu, Preferences..., à notre workbench, car il n'est pas présent dans la version de base. Nous ajoutons ce sous-menu de la même manière que le sous-menu, Open Mailer, à l'exception que nous créons l'action du menu avec un ActionFactory (cf. ligne 32 du listing 4.6). Et pour la dernière extension, l'intro de notre workbench, il faut juste modier le chier, root.xhtml (cf. listing 4.8) qui se trouve dans le dossier, content. Car l'extension est prête à être utilisée puisque nous avons choisi un template. 2 <!DOCTYPE html PUBLIC " //W3C/ / DTD XHTML 1.0 T r a n s i t i o n a l / / EN" " h t t p : / / www. w3. org /TR/ xhtml1 /DTD/ xhtml1 t r a n s i t i o n a l. dtd " > 4 <html xmlns= " h t t p : / / www. w3. org /1999/ xhtml " > <head> 6 <meta http equiv= " Content Type " content= " t e x t / html ; charset= u t f 8" / >

59 4.5. Amélioration possible 50 < t i t l e > r o o t. xhtml< / t i t l e > 8 < l i n k r e l = " s t y l e s h e e t " href= " shared. css " type= " t e x t / css " / > < l i n k r e l = " s t y l e s h e e t " href= " r o o t. css " type= " t e x t / css " / > 10 < / head> 12 <body> <h1>bienvenue dans Ma il er < / h1> <h4> A t t e n t i o n < / h4> <p> I l f a u t t o u t d abord c o n f i g u r e r l e s param&#xe8 ; t r e s du Mailer en a l l a n t dans F i l e / Preferences. Sinon l a p p l i c a t i o n ne f o n c t i o n n e r a pas!! < / p> < / body> < / html> Listing 4.8: Fichier root.xhtml 4.5. Amélioration possible Bien que le Mailer Plugin soit déjà très complet, il lui manque peut être un carnet d'adresses. Nous pourrions ajouter un bouton à la barre d'outils ou un sous-menu au menu, File, qui nous permettrait d'ouvrir notre carnet d'adresses. Celui-ci se présenterait sous la forme d'une fenêtre où nous pourrions trouver une liste de nos contacts avec leur nom, leur prénom, leurs adresses , etc. Ainsi nous pourrions très facilement retrouver l'adresse d'un de nos contacts Conclusion Dans ce chapitre, nous avons vu comment construire un plug-in et une application RCP grâce à l'exemple du Mailer. Nous avons appris à créer un projet dans Eclipse, à ajouter des chiers JAR à celui-ci, à écrire les diérentes classes qui permettent de construire un plug-in ou une rich client application et l'utilisation du PDE qui est présent tout au long du développement.

60 5 Le framework SimJ 5.1. Introduction Ressource Entité Evénement Générateur de nombres aléatoires Horloge et échéancier Utilisation du framework SimJ Conclusion Introduction SimJ est un framework développé par le Software Engineering Group du département informatique de l'université de Fribourg. Ce framework programmé en Java permet de faire de la simulation par événements discrets. La simulation par événements discrets permet de modéliser un système à travers le temps. Le système que nous voulons modéliser est caractérisé par un état. Celui-ci doit permettre de décrire complètement ce système qui est composé d'entités et de ressources. Donc cet état est déni par les entités qui sont servies par chacune des ressources ou qui attendent dans la le d'attente de celles-ci. Si nous prenons l'exemple d'un supermarché, l'état de notre système est caractérisé par les clients dans le magasin, les clients qui attendent à la caisse et lles clients qui sont servis à la caisse. Cet état change à chaque fois qu'un événement se produit, par exemple, l'arrivée d'un client dans le magasin. Donc ce qui nous intéresse dans la simulation par événements discrets, c'est l'état de notre système après qu'un événement se produit. Un tel système peut être simulé grâce à : des ressources, des entités, des événements, un générateur de nombres aléatoires, une horloge et un échéancier Ressource Une ressource (par exemple une caisse) peut être modélisée grâce aux caractéristiques suivantes : sa capacité, le nombre de clients qu'elle peut servir en même temps, le nombre de clients en attente et d'autres paramètres comme le nom, le temps de service, etc. Avec 51

61 5.3. Entité 52 les entités, les ressources représentent l'état qui caractérise le système que nous voulons modéliser Entité Une entité ou entité temporaire (p.ex. un client) possède obligatoirement un numéro d'identication unique, mais elle peut avoir d'autres caractéristiques supplémentaires (nombre d'articles dans son panier). Celle-ci peut disparaître du système à tout moment. Une entité peut être liée à une ressource de deux manières : soit elle est en attente devant la ressource (le client attend à la caisse), soit elle est servie par la ressource (le client est servi par la caissière) Evénement Un événement représente un changement d'état du système. Un événement n'a pas de durée et se produit à un moment donné. Un événement peut être par exemple l'arrivée d'un client dans le supermarché, l'arrivée du client à une caisse, etc Générateur de nombres aléatoires Nous avons besoin d'un générateur de nombres aléatoires pour simuler des situations où le hasard est présent dans notre système réel. Par exemple, l'arrivée des clients dans le supermarché ou encore le nombre d'articles qu'un client va acheter Horloge et échéancier Nous avons aussi besoin d'une horloge virtuelle qui nous indique le temps actuel. Le temps saute de l'événement présent à l'événement suivant ce qui modiera l'état de notre système : c'est pour cela que l'on parle de simulation par événements discrets par opposition à la simulation continue. Chaque événement se retrouve agendé dans une liste que l'on appelle échéancier. Chaque événement, qui doit encore se produire, est ordonné par son temps d'exécution dans cet échéancier, que l'on appelle aussi parfois Future Events Chain dans certains ouvrages [Fis01] Utilisation du framework SimJ Pour expliquer l'utilisation du framework SimJ, nous allons utiliser l'exemple d'un supermarché. Tout d'abord, il faut déterminer les entités, les ressources, et les événements qui caractérisent notre système. Nous avons les clients qui sont des entités, le magasin et les caisses qui sont des ressources et comme événements possibles, nous avons la création du client, l'entrée du client, la n des achats, le début de service et la n de service (voir gure 5.2).

62 5.7. Utilisation du framework SimJ 53 Fig. 5.1.: Diagramme de classes du Framework SimJ et du Supermarche Maintenant que nous avons déterminé les caractéristiques, nous pouvons étendre les diérents hot spots. En eet le framework possède cinq points d'ancrage où viennent se greer les simulations que nous voulons créer : 1. la classe SimEntity 2. la classe SimEntityFactory 3. la classe abstraite SimResource 4. la classe SimEventEndService 5. la classe abstraite SimSimulation Dans notre exemple, nous créons la classe, Client, représentant les clients qui sont les entités de notre système. Celle-ci étend la classe, SimEntity. Puisque nous n'utilisons pas la classe, SimEntity, nous devons alors aussi concevoir une classe, ClientFactory, qui étend la classe, SimEntityFactory, qui elle s'occupe de fabriquer nos clients. En eet, il est possible d'utiliser directement la classe, SimEntity, et la classe, SimEntityFactory. Nous devons aussi

63 5.7. Utilisation du framework SimJ 54 Fig. 5.2.: Simulation d'un supermarché créer la classe, Magasin, et la classe, Caisse. Ces deux classes, qui représentent les ressources de notre système, doivent étendre la classe abstraite, SimResource, et surcharger la méthode, getservicetime(simentity pentity) (cf. listing 5.1). Cet méthode donne le temps que la ressource met pour servir une entité, dans notre exemple, le temps que le client passe dans le supermarché ou le temps qu'il passe à la caisse.

64 5.7. Utilisation du framework SimJ 55 1 public double getservicetime ( SimEntity p E n t i t y ) { 3 return uniquerandomizer. uniform ( minachattime, maxachattime ) ; } 1 3 Listing 5.1: Méthode getservicetime(simentity pentity) de la classe Magasin Pour notre ressource, Magasin, nous devons créer un événement, EvenementSortieMagasin, que nous instancions dans la méthode, docreateendserviceevent(simentity pentity, double end- ServiceTime). Dans notre classe, EvenementSortieMagasin, qui doit étendre la classe, SimEventEndService, nous devons compléter la méthode, afterendservice(). Cette méthode permet à la ressource d'indiquer où doit aller l'entité à la n du service. Dans notre cas, le client, une fois ses achats terminés dans le magasin, doit choisir la caisse où il veut se rendre. Et pour nir nous devons créer la classe, SuperMarche, qui étend la classe abstraite, SimSimulation. Cette classe s'occupe de concevoir un unique scheduler et randomizer, d'enregistrer les diérentes ressources et de programmer l'événement nal. package s imj. supermarket ; import s imj. SimSimulation ; 5 / 7 Cette classe implemente un super marche ( resource no. 1) avec 2 c a i s s i e r e s ( ressouce no. 2 et 3) dotees chacune d une f i l e d a t t e n t e et ne changent pas. 9 Les temps de s e r v i c e dependent du nombre d a r t i c l e s achetes. / public class SuperMarche extends SimSimulation { private double tempsmoyenarrivee ; private double tempsachatmin ; private double tempsachatmax ; private double tempsservicemin ; private double tempsservicemax ; private i n t maxnbarticlesofclient ; 25 private SuperMarche ( double ptempsmoyenarrivee, double ptempsachatmin, 27 double ptempsachatmax, double ptempsservicemin, double ptempsservicemax, double pfinaleventtime, 29 i n t pmaxnbarticlesofclient, i n t pscaninterval, boolean pdebug ) { super ( pfinaleventtime, pscaninterval, pdebug ) ; 31 tempsmoyenarrivee = ptempsmoyenarrivee ; tempsachatmin = ptempsachatmin ; 33 tempsachatmax = ptempsachatmax ; tempsservicemin = ptempsservicemin ; 35 tempsservicemax = ptempsservicemax ; maxnbarticlesofclient = pmaxnbarticlesofclient ; 37 } 39 public s t a t i c SimSimulation getinstance ( double ptempsmoyenarrivee, double ptempsachatmin, double ptempsachatmax, 41 double ptempsservicemin, double ptempsservicemax, double pfinaleventtime, i n t pmaxnbarticlesofclient, 43 i n t pscaninterval, boolean pdebug ) { / / i f ( instance == n u l l ) { 45 instance = new SuperMarche ( ptempsmoyenarrivee, ptempsachatmin, ptempsachatmax, ptempsservicemin, ptempsservicemax, 47 pfinaleventtime, pmaxnbarticlesofclient, pscaninterval, pdebug ) ; / / } 49 return instance ; } 51

65 5.8. Conclusion 56 protected void setupsimulation ( ) { 53 / / Parametres des c l i e n t s C l i e n t. s e t M a x A r t i c l e s ( this. maxnbarticlesofclient ) ; 55 } 57 protected void createresources ( ) { / / Creation : Magasin resource no. 1 (1000 = capacite du magasin ) 59 new Magasin (10000, " Magasin ", tempsachatmin, tempsachatmax ) ; / / Creation : Caisse 1 resource no new Caisse ( 1, " Caisse 1 ", tempsservicemin, tempsservicemax ) ; / / Creation : Caisse 2 resource no new Caisse ( 1, " Caisse 2 ", tempsservicemin, tempsservicemax ) ; } 65 protected void createevents ( ) { 67 / / Evenement pour l a premiere a r r i v e e d un c l i e n t new EvenementNouveauClient ( tempsmoyenarrivee, uniquerandomizer 69. expo ( tempsmoyenarrivee ) ) ; } 71 public Magasin getmagasin ( ) { 73 return ( Magasin ) getresource ( 1 ) ; } 75 public Caisse getcaisse1 ( ) { 77 return ( Caisse ) getresource ( 2 ) ; } 79 public Caisse getcaisse2 ( ) { 81 return ( Caisse ) getresource ( 3 ) ; } 83 } Listing 5.2: Classe SuperMarche 5.8. Conclusion Comme nous avons pu le voir tout au long de ce chapitre, la création des classes pour une simulation concrète est assez récurrente. En eet, si nous prenons l'exemple de la création de ressources, nous nous apercevons assez vite que la structure des classes reste la même pour chaque ressource mise à part quelques détails, comme le nom de classe de la ressource et il en va de même pour toutes les autres classes. Donc nous avons avantage à avoir un assistant qui nous aide à générer le squelette du code de chaque classe de notre simulation. C'est l'objet du plug-in qui a été développé dans le cadre de ce travail et qui est décrit dans le chapitre suivant.

66 6 Application nale : Simj Plugin 6.1. Introduction Structure du plug-in Extensions L'assistant de création de simulation La classe : SimjWizard La classe : RessourceWizardPage La classe : EntityWizardPage La classe : SimulationWizardPage Aide de l'assistant La classe : Factory Fonctionnement Amélioration possible Conclusion Introduction Maintenant que nous avons vu en détails la plateforme Eclipse et que nous avons construit l'exemple du Mailer Plugin, nous pouvons passer à l'explication de l'application nale, Simj Plugin. Le Simj Plugin a été développé avec la version 3.2 d'eclipse. Celui-ci a pour objectif l'aide au développement de simulations grâce au framework SimJ dont le fonctionnement a été expliqué dans le chapitre précédent. Simj Plugin ore un assistant qui guide l'utilisateur pas à pas à travers les diérentes étapes de création d'une simulation. Il permet de créer le squelette des diérentes classes qui étendent les hots spots du framework SimJ. L'utilisateur n'a alors plus qu'à compléter les diérents endroits du code qui lui sont clairement indiqués par des commentaires Structure du plug-in Le plug-in Simj se présente sous la forme de trois packages. Le package principal, Simj, contient la classe SimjPlugin qui est l'activator, le package, classfactory, dans lequel est 57

67 6.3. Extensions 58 inclu la classe Factory et le package, wizards, qui réunit la principale classe de l'assistant, SimjWizard, et les diérentes pages de celui-ci : EntityWizardPage, RessourceWizardPage et SimulationWizardPage. Le plug-in possède aussi trois dossiers : un dossier, icons, qui contient toutes les icônes nécessaires à celui-ci, un dossier, template, qui réunit tous les templates nécessaires à la classe Factory contenu dans le package, classfactory, et un dossier, context, qui contient les pages HTML pour l'aide de l'assistant. Le plug-in Simj contient aussi le chier JAR indispensable contenant le framework Simj. Fig. 6.1.: Diagramme de classes du Simj Plugin 6.3. Extensions Simj Plugin utilise deux points d'extension d'eclipse. Le premier, org.eclipse.ui.newwizards, permet d'ajouter à l'assistant New Project d'eclipse, l'assistant pour la création de simu-

68 6.4. L'assistant de création de simulation 59 lation. Une catégorie, Simj, supplémentaire a encore été ajoutée à l'assistant New Project (voir gure 6.2). L'ajout de cette extension nécessite aussi la création de la classe, SimjWizard, qui étend la classe Wizard et qui implémente l'interface INewWizard, nous verrons les détails de cette classe dans la section suivante 6.4. Le deuxième point d'extension, org.eclipse.help.contexts, permet d'ajouter de l'aide à l'assistant. Cette aide se présente sous la forme d'un point d'interrogation au bas de chaque page de l'assistant de création sur lequel on peut cliquer pour obtenir celle-ci, nous pouvons le voir sur la gure 6.2. Fig. 6.2.: Assistant New Project 6.4. L'assistant de création de simulation L'assistant de création de simulation se présente sous la forme de cinq pages. Les deux premières pages sont standards et sont les mêmes que pour n'importe quel autre projet Java. La première permet de donner le nom du projet et son emplacement (voir gure

69 6.4. L'assistant de création de simulation ), le seconde de congurer tous les paramètres Java (voir gure 6.6), la troisième de créer des ressources et les événements qui s'y rattachent (voir gure 6.7), la quatrième de créer les entités (voir gure 6.8) et la dernière de créer la classe principale de la simulation (voir gure 6.9). Nous allons voir les diérentes classes qui composent l'assistant dans les sous-sections suivantes La classe : SimjWizard La classe SimjWizard est la classe principale de l'assistant. Elle gère les diérentes pages de l'assistant. Cette classe est responsable de récupérer les données des ressources, des entités, etc, qui lui sont essentielles pour créer le projet. Car, elle est aussi responsable de la création du projet. Elle crée les classes du squelette qui sont nécessaires à la simulation (voir chapitre 5) avec l'aide de la classe Factory et insère le chier JAR qui contient le framework Simj La classe : RessourceWizardPage Cette classe étend la classe WizardPage, comme toutes les classes suivantes. Elle représente la troisième page de notre assistant (voir gure 6.7). Elle est responsable de récupérer les noms des classes des diérentes ressources et les noms des événements qui leur sont liées (voir section 5.7) et elle transmet ces informations à la classe, SimjWizard, sous la forme de deux Vector Java : un pour les noms de ressources et un pour les noms d'événements. La classe RessourceWizardPage gère aussi la validation des noms des classes. Pour cela, elle utilise le mécanisme de validation du plug-in org.eclipse.jdt.core La classe : EntityWizardPage La classe EntityWizardPage représente la quatrième page de l'assistant (voir gure 6.8). Cette classe récupère le nom de classe de l'entité et le fournit à la classe SimjWizard sous la forme d'un String Java. Elle contrôle la validité du nom de la classe comme pour la classe RessourceWizardPage La classe : SimulationWizardPage La classe SimulationWizardPage est la dernière page de notre assistant (voir gure 6.9). Elle collecte le nom de classe de la simulation, les noms de classe des diérentes ressources qui seront créées dans la classe simulation, les extensions et les capacités des ressources et le nom de classe de l'événement initial qui permettra de créer les entités. Elle transmet à la classe SimjWizard le nom de classe de la simulation sous la forme d'un String, les noms de classe des ressources sous la forme d'un Vector, de même pour les capacités et le nom de classe de l'événement sous la forme d'un String. Elle aussi contrôle la validité du nom de la classe de la simulation comme pour la classe RessourceWizardPage.

70 6.5. Aide de l'assistant Aide de l'assistant Chaque page de l'assistant est doté d'un système d'aide. Comme nous l'avons expliqué dans la section 6.3, il s'agit d'une extension de l'aide d'eclipse. Cette extension se présente sous la forme d'un chier HelpContexts.xml (cf. listing 6.1) et de chiers HTML. Le chier HelpContexts.xml permet la liaison entre le contexte et la page HTML correspondante. 1 <?xml version= " 1.0 " encoding= "UTF 8"?> 3 <contexts > < context i d = " e n t i t y w i z a r d p a g e i d " > 5 < d e s c r i p t i o n >Simj wizard< / d e s c r i p t i o n > < t o p i c h r e f = " context / e n t i t y w i z a r d. html " 7 l a b e l = " E n t i t y wizard page " / > < / context> 9 < context i d = " resourcewizardpageid " > 11 < d e s c r i p t i o n >Simj wizard< / d e s c r i p t i o n > < t o p i c h r e f = " context / resourcewizard. html " 13 l a b e l = " Resource wizard page " / > < / context> 15 < context i d = " simualtionwizardpageid " > 17 < d e s c r i p t i o n >Simj wizard< / d e s c r i p t i o n > < t o p i c h r e f = " context / s i m u l a t i o n w i z a r d. html " 19 l a b e l = " Simulation wizard page " / > < / context> 21 < / contexts> Listing 6.1: Fichier HelpContexts.xml Car, chaque page de l'assistant possède un contexte unique. Quant aux pages HTML, elles fournissent l'aide qui sera achée dans la fenêtre qui s'ouvre à côté de l'assistant (voir gure 6.3) La classe : Factory La classe Factory génère les diérentes classes nécessaires sous forme d'inputstream qu'elle transmet à la classe SimjWizard qui les crée et les place dans le projet. Pour cela, elle utilise des chiers textes modèles qui contiennent la structure générale de chaque classe. Elle copie le chier modèle en remplaçant chaque mot clé avec le mot de substitution. Prenons l'exemple suivant : nous voulons créer une entité qui s'appelle Client. 1 / Returns SimEntity class with the given name and the given package 3 i n an InputStream using a template f i l e ( e n t i t y t p. t x t pack The package where the generated class i s located name The name of the generated an InputStream of generated SimEntity class 7 / public InputStream c r e a t e C l a s s E n t i t y ( S t r i n g pack, S t r i n g name) { 9 S t r i n g contents = " " ; t r y { 11 / on prend l e f i c h i e r template correspondant à l a classe qu on veut créer. 13 / InputStream i n = F i l e L o c a t o r. openstream ( SimjPlugin. g e t D e f a u l t ( ) 15. getbundle ( ), new Path ( " template / e n t i t y t p. t x t " ), false ) ; 17 / et on remplace l e mot c l é ### entityname ### avec l e nom de l a classe. 19 / contents = replace ( in, " ### entityname ### ", name) ;

71 6.6. La classe : Factory 62 Fig. 6.3.: Page de création des ressources avec la fenêtre d'aide 21 } catch ( Exception e ) { e. p r i ntstacktrace ( ) ; } } return new ByteArrayInputStream ( format ( contents ). getbytes ( ) ) ; Listing 6.2: Méthode createclassentity(string pack, String name) de la classeclasse Factory Nous utilisons la méthode, createclassentity(string pack, String name) de la classe Factory (cf. listing 6.2 et voir gure 6.4) qui permet de générer les classes qui étendent la classe SimEntity. Cette méthode va parcourir le chier modèle, entitytp.txt (cf. listing 6.3), en copiant et en remplaçant chaque occurrence du mot clé, ###entityname###, par le nom de classe, c'est-à-dire Client package sim ; p u b l i c class ### entityname ### extends SimEntity { p u b l i c ### entityname ###( i n t pid ) { super ( pid ) ; } } Listing 6.3: Fichier modèle entitytp.txt

72 6.7. Fonctionnement 63 Fig. 6.4.: Diagramme de séquence de la méthode createclassentity(string pack, String name) 6.7. Fonctionnement Pour commencer, il faut aller dans le menu File d'eclipse et cliquer sur Project.... Alors la fenêtre de sélection d'assistant s'ouvre (voir gure 6.2). Il faut choisir l'assistant, Simj wizard, dans le dossier Simj. L'assistant s'ouvre sur la page de création de projet (voir gure 6.5). Nous entrons le nom du projet, Ma_Simulation, et choisissons l'emplacement par défaut. Puis, nous cliquons sur Next pour aller à la page de conguration des paramètres Java (voir gure 6.6). Nous laissons les paramètres tels quels et appuyons sur Next. Nous arrivons sur la page de création des ressources. Sur cette page nous entrons le nom de notre première ressource qui s'appelle Caisse, puis nous cliquons sur ADD pour l'ajouter à la liste. Nous entrons le nom de notre deuxième ressource qui se nomme Magasin et nous cochons la case, Do this resource have EndServiceEvent?, nous entrons le nom de l'événement de n de service de notre ressource qui est EvenementSortieMagasin et pressons sur ADD. Si les noms des diérentes classes sont incorrects, l'assistant envoie un message d'erreur. Il est possible de passer à la page suivante que si au moins une ressource a été ajoutée à la liste, sinon le bouton Next est indisponible. Maintenant, nous passons à la page suivante en appuyant à nouveau sur Next. La page suivante est la page de création d'entité. Sur cette page nous donnons le nom de notre entité, qui est Client. Comme auparavant, l'assistant vérie la validité du nom

73 6.7. Fonctionnement 64 Fig. 6.5.: Page de création de projet de notre classe et en plus contrôle que nous n'avons pas déjà utilisé ce nom à l'étape précédente. Nous pouvons omettre cette étape, si nous voulons utiliser les SimEntity. Nous cliquons sur Next pour passer à la page suivante. Nous arrivons à la dernière page de notre assistant, celle de la création de la simulation. Sur cette page nous tapons le nom de notre simulation qui est Supermarche. Puis entrons le nom, la capacité et l'extension des ressources qui sont utilisées pour la simulation, c'est-à-dire caisse1 avec une capacité de 1 et qui étend Caisse, caisse2 avec une capacité de 1 et qui étend Caisse et magasin avec une capacité de 1000 et qui étend Magasin. Nous ajoutons bien sûr chaque ressource en appuyant sur le bouton ADD. Nous complétons le champ, Event name, avec le nom de l'événement qui va créer nos clients et qui s'appelle EvenementNouveauClient. Comme pour les étapes précédentes, l'assistant vérie la validité du nom des classes et en plus contrôle que nous n'avons pas déjà utilisé les noms des classes aux étapes précédentes. Nous pouvons maintenant presser le bouton Finish, car nous avons rempli toutes les pages de l'assistant. Le projet est alors créé et apparaît dans la vue, Package Explorer, d'eclipse (voir gure 6.10). Ce n'est alors qu'un projet Java classique, avec les diérents squelettes de classes, qui composent notre simulation, et la librairie simj.jar contenant le framework SimJ dans son classpath. A partir de là, le développeur de la simulation travaille sur son projet comme il en a l'habitude en complétant et adaptant le code qui a été généré par le plug-in.

74 6.8. Amélioration possible 65 Fig. 6.6.: Page de conguration des paramètres Java 6.8. Amélioration possible Ce plug-in pourrait être amélioré en orant une interface graphique. Cette interface se présenterait sous la forme d'une vue Eclipse où l'on pourrait par un simple clic ajouter des ressources, ce qui générerait aussi le code pour ces ressources. Celles-ci seraient représentées sous forme graphique dans notre vue, puis nous pourrions tirer des traits entre les ressources qui représenteraient les chemins que pourraient emprunter les entités, ce qui générerait le code des événements, SimEventEndService. De plus, les paramètres de chaque ressource (le nom, la capacité, etc) seraient congurables par un double clic sur celles-ci. Et tout le code de la simulation serait en permanence remis à jour.

75 6.9. Conclusion 66 Fig. 6.7.: Page de création des ressources Fig. 6.8.: Page de création d'entité 6.9. Conclusion Ce chapitre nous a permis de découvrir l'architecture et le fonctionnement du Simj Plugin qui est l'application nale de ce travail de master. Nous avons vu les extensions que ce plug-in étendait et les diérentes classes qui le composent.

76 6.9. Conclusion 67 Fig. 6.9.: Page de création de la simulation Fig : Vue Package Explorer