’administration de EISMO est une application graphique. Elle doit couvrir toutes les couches du serveur, qu’elle doit permettre de démarrer et d’arrêter. Elle intègrera JRacer, de façon à pouvoir utiliser les services de Racer. Ses fonctions seront les suivantes :
Démarrer et arrêter le serveur Racer
Charger des ontologies à partir de fichiers locaux ou distants Démarrer et arrêter le serveur Jonas
Démarrer et arrêter la console d’administration de Jonas Afficher les ontologies ouvertes et les fermer
Saisir les liens entre concepts
Saisir les liens entre concepts et EJB Quitter EISMO
Cette application est créée sous le nom de Serveur_EISMO. Il s’agit d’un projet conçu pour contenir des EJB et pouvoir évoluer vers une application Web. C’est également une application multi threads, les serveurs étant lancés par des threads séparés. De plus, certaines méthodes font appel à des commandes système et utilisent des process pour gérer ces commandes système.
D’une manière générale, les attributs des classes sont privés et les méthodes publiques. Il existe des méthodes permettant d’obtenir la valeur des attributs ou de la modifier.
L’utilisation du multi threads
Pour pouvoir faire une application multi threads, les méthodes devant être appelées par un thread doivent être dans une classe héritant de Thread. Cette classe a alors une structure particulière :
Elle contient obligatoirement une méthode run(), (public void run()). Cette méthode est appelée par la classe utilisatrice, et lance le thread. Elle contient les instructions à exécuter au lancement de la tâche.
La classe utilisatrice doit créer un nouveau thread par un new thread, qui sera du type de la classe contenant la méthode run(). Puis elle lance le thread par la méthode start().
Exemple : la classe Racer hérite de Thread. Elle possède une méthode run() qui permet le démarrage de Racer. Elle est appelée par une méthode de la classe EISMO_Admin de la manière suivante :
Thread racer = new Racer(). Cette commande crée un nouveau thread de type Racer racer.start() Cette commande démarre le thread (appelle la méthode run()).
L
L
Projet EISMO Page 23 sur 50 L’utilisation de process
L’exécution d’une commande système se fait par l’intermédiaire de la commande exec(), à laquelle on passe la commande à exécuter en paramètres.
Exemple : Process p = Runtime.getRuntime ().exec(« racer »).
Lorsque l’on veut arrêter un process, on utilise la commande destroy (exemple p.destroy()).
I.2. L’architecture
Elle contient 1 package nommé administration dans lequel se trouvent les différentes classes nécessaires à l’administration du système, 1 package JRacer contenant les classes utiles à la communication avec Racer. Les fenêtres ne contiennent que les parties graphiques et les appels de méthodes. Toutes les méthodes utilisées dans ces fenêtres sont contenues dans des classes spécifiques.
Le package coreServices est utilisé par l’administrateur, dans certaines opérations telles que la création des liens.
Figure 6 : diagramme de classes simplifié du package administration
Projet EISMO Page 24 sur 50
I.3. Le développement des différentes classes
L’étude menée sur le serveur Racer amène à certaines conventions en matière de programmation :
Un fichier sera associé à une connexion à Racer Un objet RacerClient ne contiendra qu’un seul fichier.
Ces règles sont très importantes, car Racer ne communique avec l’extérieur que par le moyen de l’objet RacerClient, qui est une connexion. Dans le cas ou plusieurs ontologies sont ouvertes par le même objet RacerClient, Racer ne travaillera que sur le dernier fichier ouvert.
a La fenêtre GUI_Admin
C’est la fenêtre principale de l’application. Elle contient la méthode main(). Elle présente à l’utilisateur tous les boutons et affichages nécessaires à l’administration du serveur. Le clic sur un bouton de cette fenêtre appelle une méthode contenue dans la classe EISMO_Admin.
Figure 7 : fenêtre administration
b La classe EISMO_Admin
Cette classe contient pratiquement toutes les méthodes du serveur appelées par GUI_Admin.
Elle permet l’appel des méthodes servant à arrêter et démarrer les 2 serveurs, la gestion de
Projet EISMO Page 25 sur 50 l’ouverture et de la fermeture des fichiers. Elle appelle également les méthodes permettant la saisie des différents liens. Elle a différents attributs, permettant de conserver la liste des ontologies ouvertes et des connexions à Racer associées, ainsi qu’une instance de la classe OntoManager qui permet la saisie des liens.
c La classe RacerConnection
Elle hérite de RacerClient. Elle a en attributs l’adresse du serveur et le port sur lequel se connecter. Elle permet de créer une connexion à Racer, de l’ouvrir et de la fermer.
d La classe Racer
Cette classe hérite de Thread. En effet, Racer est lancé par une commande système en mode DOS et s’arrête dès la fin de la tâche. Il est donc indispensable de recourir à une tâche indépendante qui restera active jusqu’à ce qu’on la tue volontairement.
Sa méthode run () contient le code nécessaire au démarrage de Racer. Elle utilise un process qui permettra d’arrêter le serveur, car l’arrêt du serveur se fait par l’arrêt du thread (lorsque on utilise Racer à partir d’une console DOS, l’arrêt se fait par fermeture de la fenêtre).
e La classe Jonas
Cette classe hérite elle aussi de Thread, comme la classe Racer. Elle permet de démarrer et d’arrêter le serveur JOnAS. Elle utilise deux process : un premier assurant le démarrage de JOnAS, grâce à la commande jonas start, le second s’occupe de l’arrêt avec la commande jonas stop.
f La classe JonasAdmin
Elle hérite elle aussi de Thread. Elle permet de démarrer la console d’administration de JOnAS en utilisant la commande jonasAdmin dans un process. L’arrêt se fait par la commande destroy.
Le démarrage intègre le démarrage d’un navigateur Internet, car cette console se connecte en mode http à Jonas. Il faut lui passer en paramètres l’adresse du serveur (IP ou nom) ainsi que le port.
g La classe Filtre
La fenêtre GUI_Admin offre la possibilité d’ouvrir un fichier (ontologie). Cette ouverture de fichier se fait par l’intermédiaire d’un composant standard Java : JFileChooser.
La classe filtre hérite de FileFilter. Elle contient les 2 méthodes accept() et getDescription().
JFileChooser : Celui-ci permet de chercher dans l’arborescence du disque ou du réseau un fichier à ouvrir. Une possibilité de filtrer les fichiers que l’on affiche existe. Elle fait appelle à une classe qui doit hériter de la classe javax.swing.filechooser.FileFilter. Elle doit impérativement contenir les 2 méthodes accept() et getDescription().
La classe GUI_Admin appelle le constructeur de Filtre pour créer un nouveau filtre, en lui passant en paramètres une description du fichier filtré et l’extension. Par exemple :
Projet EISMO Page 26 sur 50 Filtre filtre_owl = new Filtre(“Fichier OWL”, “ owl”) permettra d’afficher les fichiers avec l’extension owl, et de mettre dans le menu déroulant des choix Fichier OWL.
Cette classe Filtre est instanciée autant de fois que l’on veut sélectionner d’extensions possibles.
h La classe KB_Manager
Cette classe est destinée à gérer l’ouverture et la fermeture des ontologies. Sur demande de la classe EISMO_Admin, elle crée une connexion à Racer (par l’intermédiaire de la classe RacerConnection)
i Les classes TreeEJB et TreeSP
Ces deux classes permettent la saisie des liens entre concepts (TreeSP) ou entre concepts et EJB (TreeEJB). Elles sont réalisées selon le même principe. Elles sont découpées en 3 parties verticales : la partie gauche permettant l’affichage d’un arbre source, la partie droite d’un arbre destination et la partie centrale permettant l’affichage des liens entre ces 2 arbres grâce à des lignes. Ces 2 classes font appel à la classe JTree de Java.
JTree
Cette classe permet de représenter une hiérarchie sous la forme d’un arbre. Elle crée des nœuds, qui peuvent contenir des nœuds ou des éléments. Il existe toujours un nœud racine (root) ayant des enfants. Ex :
Les enfants peuvent avoir ou non des enfants. Un JTree ne contient pas les données, mais en est simplement une représentation.
Projet EISMO Page 27 sur 50
Figure 8 : Fenêtre permettant la saisie des liens entre concepts de 2 ontologies
Pour le stockage des liens, un vecteur contient le nom source (côté gauche de la fenêtre), un second vecteur contient la destination (côté droit de la fenêtre). Ces deux noms occupent les mêmes positions dans leurs vecteurs respectifs.
Un clic sur le bouton "Terminer" de la classe TreeEJB appelle la méthode de la classe EJBManager qui permet de sauvegarder ces liens dans un fichier xml. Cette classe EJBManager fait partie du package coreServices. Pour la classe TreeSP, un clic sur
"Terminer" appelle le constructeur de la classe SemanticMapper, classe du package coreServices. Cet appel s’effectue en passant en paramètres les vecteurs contenant les noms source et destination, ainsi que les noms des deux ontologies concernées.