Module : informatique répartie

Prof: Mr. Soufiane Gannouni.

Groupe:

Introduction

Afin de rapprocher les jeunes inscrits aux différents clubs de jeunes, en les aidant à mieux partager leurs centres d’intérêts et ainsi réaliser l’un des buts fondamentaux pour lesquels cette plate-forme a été crée, le MJES (Ministère de la Jeunesse de l'Enfance et du Sport) a décidé d’intégrer à la plate-forme un service de FORUM en ligne. 

Dans ce chapitre on commence par une spécification des besoins de l’application. Ensuite, vient la phase de la conception de l’application dans lequel on justifie le choix de  l’approche adoptée et on présente les différents diagrammes qui se rapportent. Enfin arrive la phase de la réalisation et de l’implémentation de l’application.

1          Spécification des besoins

Le MJES tient, grâce à la base de données du service MAIL, un ensemble de listes de diffusions regroupant l’ensemble des jeunes partagent les mêmes centres d’intérêts. Elle veut grâce à cette liste organiser des Forums de discussions sur la plate-forme.

Le Forum sera formé d’un ensemble de réunions correspondant chacune à l’une des Mailing List. Ces Forums seront créés par l’administrateur du service grâce à un outil conçu à cet effet. Cette approche est due au fait que le MJES veut que l’accès à un Forum soit strictement restreint aux jeunes inscrits dans le Mailing List correspondant. Au thème du sujet à discuter ce service doit remplir les fonctions suivantes : 

·        Création et administration de l’ensemble des Forums

·        Lister l’ensemble des Forums disponibles pour que le jeune puisse en choisir une.

·        Choisir de joindre une liste de discussion.

·        Vérifier les droit d’accès à un Forum grâce à un mot de passe.

·         Envoyer un message à tous les participants d’un Forum.

·        Envoyer un message privé à un participant donné.

·        Recevoir un message.

·        Etre informé de la liste des présents.

·        Etablir un PV à la fin de la réunion.

·        Journaliser l’ensemble des accès aux Forums sous des formats standards. 

2          Conception du service FORUM

Pour la mise en oeuvre de l’application que nous allons développer et dont la spécification à été présentée dans le paragraphe précédent, nous avons vu indispensable l’utilisation d’une méthode de conception, afin de réduire les fautes et les faiblesses qui peuvent apparaître lors de la phase de codage et de test.

2.1        Analyse

Le service FORUM  que nous essayons de réaliser dans cette étape de notre projet est l’un des services fondamentaux pour lequel la plate-forme a été conçue vu les fonctionnalités qu’il offre. Dans cette section, nous présentons une analyse détaillée de nôtre application « FORUM du MJES », son intérêt et les besoins qu’elle doit satisfaire.

2.2        Problématique

Comme n’importe quel portail sur le WEB, celui de la MJES se veut un lieu où les jeunes de tout le pays peuvent s’informer et se partager leurs centres d’intérêts. D’où le besoin de développer une application de FORUM en ligne accessible via le WEB.

Notre travail est de trouver une solution pour la conception et la mise en place de ce service. La recherche d’une solution pour ce genre de services s’impose d’elle même. En effet, la solution doit satisfaire une architecture Client/Serveur avec une intégration totale avec le WEB.

2.3        Besoins fonctionnels  

Le travail se divise globalement en deux parties qui se rencontrent pour l’implémentation du service FORUM du ministère : la première, est la mise en œuvre du serveur forum et l’implémentation des différents services qu’il doit offrir. La deuxième concerne la conception et la mise en place de deux interfaces clientes du service, une pour l’administration des forums et l’autre pour prendre part à une discussion en ligne.

2.3.1       Mise en œuvre du serveur FORUM

Le serveur doit être capable de fournir l’ensemble des services établie au cours de l’étape de la spécification. Le couplage avec une base de données s’impose par nature pour assurer le dynamisme de l’application. D’où la nécessité de voir comment concevoir cette base de données et quelles sont les tables qu’elle doit comprendre ?

La base de données exploitée par un serveur de FORUM, doit comprendre les tables nécessaires pour stoker les informations concernant les conférences et les jeunes autorisés à y accéder. Elle doit aussi permettre de suivre l’état des différents participants et le stockage des messages qui transitent à travers les différentes conférences.

2.3.2       Mise en œuvre de la partie cliente

Cette partie représente l’interface qui sera utilisée par l’utilisateur pour l’accès au service . Suivant le type de service, on distingue deux types d’utilisateurs :

·                    Administrateur : cette personne veille sur la gestion des différentes conférences.

·                    Jeune : cette personne aura le droit d’accéder à une conférence via un login et un mot de passe déterminé d’avance par l’administrateur.

2.4        Choix de l’approche 

            Face à l’absence d’une méthode de conception et de développement standardisé couvrant tout le cycle de fabrication d’un logiciel et garantissant une performance de développement et de maintenance de l’application, nous nous sommes trouvés obligé de choisir une méthodes qui semble être en adéquation avec notre besoin.

Il est clair que la nature modulaire de l’application (Client /Serveur), ainsi que la choix par la suite du langage de programmation justifie très bien le choix d’une approche Orienté Objet. Ainsi UML(Unified Modeling Language) a été notre outil de conception car il possède les avantages suivants :

·        UML représente la méthode de conception commune et unifiée à toutes les autres méthodes de l’approche Orienté Objet ( OMT, OOSE,…) [8]

·        Avec UML, la manipulation des données avec les traitements passe en toute transparence.

·        UML renferme un ensemble des diagrammes simples et faciles à comprendre par les informaticiens et les non informaticiens.

·        L’utilisation de la notation UML permet aux concepteurs de travailler dans un environnement plus évolutifs, notamment avec la possibilité d’interfacer plus facilement les langages évolués tel que JAVA.

·        …..

2.5        L’architecture générale de l’application 

Avant d’entamer directement la conception de l’application, il est indispensable de présenter son architecture globale. Cette architecture va nous aider à étudier la conception de chacun des composants à part et aussi à situer l’environnement global de l’application. La figure 6.1 qui suit présente une telle architecture. 

fig. 6.1  l’architecture globale de l’application 

D’après cette figure, notre application se compose de trois parties de base. La première c’est le serveur du FORUM : « ConfServ ». C’est cette partie qui se charge d’honorer les requêtes clients en toute transparence. La deuxième est la partie cliente de l’application, elle est formé de deux modules de base. Le premier module permet d’administrer le service Forum, le deuxième est celui qui est utilisé par le jeune pour participer à un Forum.

Finalement, on trouve la partie base de donnée sur laquelle sont sauvegardées toutes le informations sur les différents conférences et l’ensemble des participants.

2.6        Conception des différentes composantes

Dans cette partie nous allons essayer d’établir la conception pour chacune des trois composantes : Le serveur FORUM, la partie Cliente, la composante BD.

2.6.1       Le serveur FORUM 

Le serveur du FORUM est dotée des fonctionnalités suivantes : la gestion des salles de discussion (Conférences), la gestion des utilisateurs ( jeunes), la liste des Conférences.

2.6.1.1       Diagramme de cas d’utilisation 

A ce stade de la conception, on va présenter les interactions entre les acteurs et les principaux événements  qui se produisent dans ce module d’application. Dans ce cas il y a deux acteurs : l’application cliente d’administration et celle de communication. Les évènements représentent l’ensemble des services offerts par le serveur.

D’après la spécification de cette partie, les différents cas d’utilisations se présentent de la manière suivante : 

  Le diagramme de cas d’utilisation est le suivant (fig. 6.2)

       fig. 6.2 Diagramme de cas d’utilisation : Serveur du FORUM.

2.6.1.2       diagramme de classe 

Le diagramme de classe est une représentation statique en terme de classe et de relation. Dans cette partie, nous essayerons de présenter le différentes classes dégagées de la spécification, puis l’ensemble des associations entre les classes à identifier.  

Le diagramme des classe est le suivant (fig. 6.3)

fig. 6.3 Diagramme de classe : Serveur du FORUM.

·                     Les classes « ServerInterface » et « ServerImpl » : 

La classe ServerInterface représente une interface pour les méthodes de la classe SeverImpl. Cette dernière représente le noyau de l’application « ConfServ », dans laquelle tous les services offert par l’application seront implémentés.

Cette classe réalise tout ce qui est accès avec la partie base de donnée et se charge de la communication avec les parties clientes. Le diagramme qui suit (fig. 6.4) présente cette classe suivant la conception UML.

fig. 6.4 La classe ServerImpl  

·                     La classe « ConnectionsVector » :

Cette classe va permettre de garder la trace sur le nombre de connectés à chacune des conférences. Cette trace va aider par la suite au nettoyage automatique de la base de donnée.  Le diagramme qui suit (fig. 6.5) présente cette classe suivant la conception UML.

fig. 6.5 La classe ConnectionsVector.  

·                     Les classes « LogConnection » et « LogDeconnection » :

Dans la partie spécification nous avons parlé de la fonctionnalité concernant la journalisation automatique des connexions et des déconnexions. Ce sont ces deux classes qui le permet.

Le diagramme qui suit (fig. 6.6) présente ces deux classes.

fig. 6.6 Les classes « LogConnection » et « LogDeconnection ». 

2.6.2       La partie cliente du FORUM 

Cette partie représente l’interface qui sera utilisée pour accéder aux services offerts par le FORUM. Elle sera formée de deux parties de base. La première permet l’administration de ce service, la deuxième est celle qui est utilisée par le jeune pour participer au FORUM.

2.6.2.1       le diagramme de cas d’utilisation 

Les cas d’utilisation décrivent le comportement de notre application de point de vue utilisateur sous la forme d’actions et de réactions.

 Le diagramme de cas d’utilisation est le suivant (fig. 6.7) 

   fig. 6.7 Diagramme de cas d’utilisation.

Ce diagramme représente les différentes fonctionnalités de l’application du FORUM de la MJES, il montre ainsi les interactions entre les acteurs et les cas d’utilisations.

2.6.2.2       Le diagramme de classe 

Puisque les classes de cette partie représentent des interface graphiques pour l’utilisateur, certains attributs en relation avec l’affichage graphique ne seront pas indiqués. Les deux classes que nous allons présenter n’ont aucune relation entre eux. 

·                     Classe « Admin_Applet » :  Comme son nom l’indique, cette classe est responsable de l’administration du service FORUM. Dans la partie réalisation nous allons voir une représentation graphique de cette classe. 

Le diagramme qui suit (fig. 6.8) présente cette classe suivant la conception UML. 

fig. 6.8 La classe Admin_Applet. 

·                     Classe « Connection_Applet » : C’est cette classe qui sera utilisée par le jeune pour accéder à une conférence et d’y participer.

Le diagramme qui suit (fig. 6.9) présente cette classe suivant la conception UML.

fig. 6.9 La classe Connection_Applet.

2.6.2.3       diagramme de séquence 

Lors de cette partie on va représenter les interactions entre les différents objets constituants le service FORUM. Ces objets sont placés sur la première ligne et pour chaque objet on lui associe une barre verticale en pointillé appelée «ligne de vie»  de l’objet. Le diagramme possède un axe de temps dirigé du haut vers le bas. Les messages sont représentés par des flèches horizontales orientées de l’émetteur vers le destinataire. 

§                    Partie utilisateur :

Seule les jeunes qui sont inscrits dans les maisons de jeunes auront le droit de participer aux conférences en ligne. Le jeune doit saisir son «login» et son «mot de passe» et sélectionner une conférence parmi la liste des conférences en premier lieu. Puis demande d’entrer dans la conférence sélectionnée. Le serveur du FORUM est chargé de vérifier l’appartenance du jeune à la conférence. Si tout va bien, le jeune peut participer à la conférence par envoie et réception des messages. La connexion reste établi jusqu’à la fermeture de la session du jeune.

La fig. 6.10 représente le diagramme de séquence de la partie cliente. 

fig. 6.10 Diagramme de séquence de la partie cliente : cas du jeune

 ·                    Partie administration :

L’administrateur a pour rôle d’ajouter, de supprimer et de modifier des conférences. De même il est chargé d’inscrire les jeunes aux différentes conférences. Il pourra aussi surveiller les états  des conférences en affichant la liste des connectés à un moment donnée. La fig. 6.11 représente le diagramme de séquence de la partie administration.

fig. 6.11 Diagramme de séquence de la partie cliente : partie administration

2.6.3      Description de la BD

L’application du forum conserve l’ensemble des informations sur les conférences et les invités dans une base de données relationnelle conçue pour cet effet.

Avec les fonctionnalités qu’elle devrait accomplir actuellement, notre application n’a besoin que de trois tables dans cette base. Une table Conferences, où elle va sauvegarder la liste de tous les conférences existantes dans le FORUM avec, éventuellement, quelques informations supplémentaires la décrivant pour les jeunes. Une deuxième table Invites, contenant la liste de tous les jeunes autorisés à participer aux différentes conférences, ces informations seront sauvegardées sous forme, d’un identificateur (pseudonyme) pour le jeune, de la conférence accessible par ce dernier ainsi que son mot de passe d’accès. La troisième table messages, renferme tous les messages qui seront échangés par les jeunes à travers les différentes conférences. L’annexe D, contient le modèle relationnelle de cette base.     

3          Réalisation du service FORUM

Après avoir spécifié notre application en détail et après avoir modélisé les différents objets qui se présentent et les différentes relations qui existent entre eux, il est temps de décrire de plus prés comment nous avons procédé pour l’implémentation du service FORUM au sein de la MJES. Nous commencerons par décrire les raisons qui nous ont poussées à choisir la technologie JAVA/RMI  comme mécanisme de base pour la communication Client/Serveur. Par la suite nous allons décrire les outils de travail ainsi que l’environnement de réalisation, pour finir par décrire les problèmes rencontrés et ceux qui restent à résoudre.

3.1        Choix du langage de programmation

Plusieurs raisons nous ont poussées à choisir le langage de programmation JAVA et surtout la technologie RMI pour l’implémentation de ce service. Parmi ces raisons on cite : 

·                    Le service FORUM doit être accessible de n’importe quel poste sur la plate-forme indépendamment de son système d’exploitation (Windows, Linux). Donc la portabilité du langage à utiliser est un besoin fondamentale. C’est ce qui explique le choix du JAVA.

·                    JAVA est réputé pour être le langage de programmation du WEB. Or le service FORUM devrait être accessible sur la portail du ministère.

·                    JAVA possède des mécanismes simples et fiable pour un accès transparent à l’ensemble de la Base de données (JDBC) [4].

·                    L’architecture même de l’application (Client/Serveur) a imposée l’utilisation d’un mécanisme de base facilitant le dialogue entre le Client et le Serveur. Le mécanisme le plus simple et le plus répondu dans JAVA est le RMI (Remote Method Invocation).

3.2        Environnement de réalisation 

3.2.1       Environnement Matériel

Durant ce PFE, on disposait chacun d’un ordinateur dont les caractéristiques sont les suivantes :

3.2.2       Environnement Logiciel

L’ensemble des logiciels utilisés tout au long du développement de notre application est :

3.3        Bilan de la réalisation

A la fin du processus de développement de l’application certaines tâches ont été réalisées :

·                    Le développement du serveur FORUM représenté par les deux classes : « Server_Interface » et « ServerImpl ».

·                    Le développement de certains modules apportant des  fonctionnalités supplémentaires au serveur à savoir :

§                    « ConnectionsVector » : Ce module permet de comptabiliser les accès à l’ensemble des forums. Cette comptabilisation est très utile pour le processus de nettoyage automatique de la base de données.

§                    « LogConnection » et « LogDeconnection » : ces deux modules sont utilisées par le processus de journalisation automatique des connections et des déconnections.

·                    Le développement de deux applettes pour la partie cliente de l’application :

§                    Admin_Applet : cette applette sera utilisée  pour l’administration du service FORUM.

§                    Connection_Applet : cette applette utilisée par le jeune pour participer à une conférence.

L’Annexe D contient une documentation technique sur l’application.

3.4        Problèmes rencontrés 

Le problème majeure rencontré concerne le déploiement de l’application sur la plate-forme. En effet, le service FORUM sera accessible via une page WEB à travers le téléchargement d’une applette sur le poste client, or certaines machines virtuelles au niveau client ont des problèmes à interpréter correctement  l’applette de l’application. Les raisons de ce problème sont les suivants :

·                    L’interface graphique de l’applette utilise certaines classes qui ne sont pas parmi les classes standards de la machine virtuelle du navigateur WEB.

·                    Certaines versions de navigateurs ont des problèmes avec la technologie RMI

Plusieurs solutions ont été apportées à ces problèmes :

·                    Les classes qui manquent au niveau client sont mis dans un package JAR (Java Archive) qui sera téléchargé au moment de l’interprétation de l’applette.

·                    Un patch RMI, qui permet de corriger la machine virtuelle du navigateur, est mis en téléchargement avec l’applette.

3.5        Ergonomie de l’Application

La théorie d’Interface Homme Machine (IHM) s’impose d’elle même dans cette section dans le but de concevoir des  interfaces graphiques interactives et conviviales. Plusieurs règles sont à énumérer, tel que :

·        La disposition : concerne plutôt des éléments de l’écran pour qu’ils soient lisibles et faciles dans la perception. Par exemple  ne pas utiliser des barres déroulant qui peuvent gêner l’utilisateur, les champs obligatoires pour la saisie doivent être déclarés, etc.

·        La couleur :  la couleur est une notion essentielle dans le processus de perception chez l’utilisateur. Nous devons limiter le nombre de couleurs dans un site et utiliser des couleurs à haut contraste.

·        Les messages : les messages dans l’application pour consigner un processus ou signaler une erreur doivent être brefs, constructifs, clairs et simples.

Dans l’Annexe E vous pouvez voir un ensemble d’échantillons de l’interface de notre application.