Chapitre 5 : Réalisation
1.2 Environnement Logiciel
Windows 7 Professionnel, Service Pack 1 comme Système d’exploitation.
PostgreSQL 9 comme système de gestion de base de données relationnel.
Gxt comme framework de développement d'application Internet.
NetBeans 6.9 comme Environnement de développement intégré.
Tomcat 6.0.20 comme Moteur de servlet.
Sybase Power Designer outils de modélisation 1.3 Choix des outils de développement Nous avons déjà les décrit dans le chapitre 2 “Etude de l’art’’.
47
2 Architecture générale de l'application
Dans ce paragraphe, on va détailler l'architecture MVC du framework Gxt et son impact dans le développement de l'application. On finira par donner le diagramme de classe finale adapté au langage de développement choisi J2EE + GWT+GXT.
2.1 Architecture client-serveur GWT:
On commence par présenter le principe de développement de la boite à outil GWT sur laquelle repose le framework GXT.
Le développement GWT couvre deux niveaux:
le développement coté Client : on développe en Java comme si on est en train de développer avec Swing. A la phase de compilation tous ce code Java sera converti en Java Script en tenant compte des différences des browsers. Cette compilation est totalement transparente à l'utilisateur. Elle est réalisée par le fameux compilateur de Google.
développement coté serveur: il repose sur le concept Ajax (JavaScript Et XML Asynchrones)
Le principe client/serveur de GWT repose sur la création de :
Deux interfaces : une synchrone et une asynchrone.
Une classe qui implémente le service
Noter que les liens entre les interfaces synchrones et asynchrones reposent sur des conventions de nommage.
Les interfaces font partis du package client : lors de sa compilation en Javascript GWT saura qu’il faut également générer ce qu’on appelle des stubs : il s’agit de morceau de code qui assure la communication entre un client et un serveur.
Il faut également noter que seule l’interface asynchrone peut être utilisée. L’appel au service ne sera pas bloquant pour le code. Si pour la suite du traitement on a besoin du résultat du traitement réalisé sur le serveur il faudra utiliser une callback.
48
Figure 408 : Architecture client-serveur de l'application
2.2 Le modèle MVC de GXT :
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglaisModel-View-Controller) est une architecture et une méthode de conception qui organise l'interface homme-machine (IHM) d'une application logicielle. Ce paradigme divise l'IHM en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des événements, synchronisation), chacun ayant un rôle précis dans l'interface.
Les composants de Gxt reposent sur le modèle MVC. De plus Gxt offre une implémentation du modèle MVC qui consiste à :
49
Créer une Classe AppEvents contenant les évènements de l'application voulus
Figure 419 : Liste des évènements de l’application
Créer une classe Controller et une classe Vue pour capter l'évènement et effectuer le nécessaire
Figure 20 : Liste des évènements de l’application
Déclarer le contrôleur auprès de contrôleur principal Dispatcher fourni par GXT
Figure 21 : Le contrôleur principal (Dispatcher)
Le dispatcher lance un évènement application (listé dans /client/AppEvents.java) à tous les contrôleurs. Si le contrôleur peut répondre à cet évènement particulier, il le
50
fait. S'il n'est pas concerné il ne fait rien. Lecontrôleurdoit accomplir l'exécution du logique métier ainsi que les MAJ des modèles. Les vues connectées à ces contrôleurs seront rafraichies en accord avec le model mis à jour correspondant.
4 Diagramme de classe final
D’après l'architecture client-serveur présentée et le modèle MVC tout le traitement sera effectué hors les classes du diagramme de classes. En effet les classes de ce diagramme seront les tables de la base de données et les entités beans utilisé par l'application pour le transfert de donnée depuis le serveur vers l'application.
Figure 22 : Les Beans
Ainsi, le diagramme de classe final sera composé du diagramme précédent auquel on ajoute la classe CompteServiceImpl et SlisServiceImpl contenant toutes les méthodes d'ajout, suppression, modification et consultation des Entité de la base de données.
On ajoute aussi toutes les classes responsables de l'interface graphique de l'application.
5 Principales interfaces graphiques
La conception des interfaces de l’application est une étape très importante puisque toutes les interactions avec le cœur de l’application passent à travers ces interfaces, on doit alors guider l’utilisateur avec les messages d’erreurs et de notification si besoin, ainsi présenter un système complet.
Dans cette partie, nous allons présenter quelques interfaces de l’application, répondant aux recommandations ergonomiques de compatibilité, de guidage, de clarté, d’homogénéité et de souplesse. Nous avons choisi l’administrateur comme utilisateur vu qu’il présente à travers ces interactions la majeure partie des principales fonctionnalités de l’application.
51 5.1 Authentification
Figure 2342 : Interface d'authentification
Cette interface permet à l’utilisateur de s’authentifier et de se connecter au serveur de la base de données. L’utilisateur doit entrer son login et son mot de passe pour accéder à l’application. En cas d’erreur un message d’alerte s’affiche :
Figure 2443 : Message d'erreur
5.2
5.2.1 Ajouter un utilisateur
Figure 25 : Interface principale
52
La figure ci-dessus présente le menu principal, l’administrateur peut ajouter un utilisateur en cliquant sur bouton ajout User ; un formulaire comportant plusieurs champs s’affiche pour l’entrée des données. L’application gère le contrôle de saisie ainsi que la sauvegarde dans les bases des données.
Figure 26 : Ajout utilisateur
5.2.2 Consulter les utilisateurs
Le bouton Consulter permet de voir la liste des utilisateurs et leur droit d'accès. On peut sélectionner un utilisateur pour le modifier ou le supprimer.
Figure 2744 : information sur les utilisateurs
53 5.2.3 Les traces utilisateurs
La trace des utilisateurs donne toutes les actions réalisées par l’utilisateur ainsi que les erreurs détectées lors de l’exécution de l’application. Pour ce faire on a recourt à la librairie Log4j et son plugin JDBCAppender qui enregistre directement à la base de données tous les messages d’info et d’erreurs.
Figure 2845 : Trace des utilisateurs
54 5.3 Gestion des comptes Mail
5. 3.1 L’ajout d’un abonné
Après la clique sur le bouton ‘Abonné + ’ un formulaire de saisie s’affiche permettant à l’utilisateur d’entrer les informations d’abonné.
Figure 2946 : Ajout d’un abonné
Un contôle sur les champs est nécessaire pour garantir l’intégrité des données.
Si l’enregistrement réussi un autre formulaire s’affiche à l’utilisateur générant le compte Mail en concaténant le nom et le prénom au domaine adquat selon l’établissemnt de l’abonné.
Figure 30 : formulaire de génération de compte
Si l’utilisateur quitte cette fenêtre sans enregistrer le compte, l’abonné reste à la base de données sans compte.
55
Pour générer le compte ; l’utilisateur sélectionne le bouton recherche Abonné sans compte.
5.3.2 La recherche d’un compte et l’impression
L’utilisateur sélectionne le bouton recherche Abonné comptes réalisés, un nouvel onglet :
Figure 3147 : recherche de compte par l’établissement
En choisissant le bouton Impression cette page s’affiche :
56
Figure 32 : Impression de compte
La génération de fichier PDF et Word est réalisée à travers la bibliothèque JasperReport.
57
5.3.3 Les états d’un compte :
Le compte crée précédemment est en état d’attente de création. Il ne sera exploitable qu’après son validation par le responsable Mail.
Figure 33 : Etats des comptes
La validation des modifications effectuées à un compte est nécessaire pour s’assurer que ces modifications seront répliquées sur le serveur LDAP du serveur Mail de l’INBMI.
D’ailleurs, le responsable Mail possède le bouton de génération CSV à travers lequel il génère un fichier CSV utilisé par le serveur LDAP.
Lorsqu’on sélectionne le bouton ‘En attente de création’ un nouvel onglet affiche les comptes à valider.Avec un clic droit sur le compte , le menu contextuel affiche un bouton pour valider ce compte.
On peut aussi cocher les comptes qu’on veut valider puis on clique sur le bouton ‘valider ’au dessus de la table.
Figure 34 : Validation des comptes
Une fois validé, le compte peut être imprimé et envoyé à son propriétaire.
58 5.4 Gestion des serveurs Slis
On commence par recherche l’établissement. L’affichage avec l’arbre des gouvernorats nous facilite la recherche.
Figure 35 : ajout d’un serveur Slis
Comme dans la figure ce collège ne possède pas d’un serveur Slis enregistré alors que les comptes y existent. Un cli droit puis add Slis nous affiche cette boite de dialogue :
Figure 36 : Ajout d’un Slis
59
Comme déjà dit à l’étude de l’existant qu’un fichier Excel contient la liste des routeurs et serveurs Slis, ce fichier a été importé à la base de données dans une table nommée slis ADSL.
Le problème réside dans l’impossibilité de joindre cette table avec celle des établissements.
C’est pour cette raison l’utilisateur choisit dans la comboBox l’établissement correspondant de la table slisAdsl et tous les informations relatives seront affichées dans le formulaire.
Si l’établissement n’existe pas dans la table slisADSL, on clique sur le bouton New et on
l’ajoute carrément.
Figure 37 : Actions sur Slis
La consultation de logs et l’ajout de comptes Internet directement à Slis nécessite une connexion distante à la base de données Postgres de Slis.
Sachant que le ficher pg-hba.conf qui définit les hôtes autorisés à accéder à la BD nécessite une modification pour ajouter l’@ip de notre serveur. De plus le firewall de slis bloque les connexions entrantes au port 5432 de Postgres de Slis. Il nous faut donc une connexion à travers ssh pour effectuer ces manipulations et cela de manière automatique et transparente à l’utilisateur de l’application.
Heureusement, il existe une librairie nommée Ganymede-ssh2 qui facilite les connexions ssh à travers le langage Java. Ce qui nous a permis d’envoyer les commandes sed pour modifier le fichier pg-hba.conf et la commande iptable avant d’effectuer la connexion à la base postgres de Slis.
Conclusion
A travers ce chapitre, nous avons présenté la réalisation de l’application en justifiant nos choix technologiques, en représentant quelques interfaces graphiques que nous avons jugé les plus importantes et en décrivant brièvement comment nous avons planifié notre projet.
60
Conclusion général
L’objectif de notre projet de fin d’étude était de concevoir et implémenter une application de gestion des comptes mails et Internet des intervenants du ministère d’éducation.
Le point de départ de la réalisation de ce projet était une récolte des informations nécessaires pour dresser un état de l’existant, présenter un aperçu sur la problématique ainsi que
l’architecture utiliser au sein des réseaux des établissements.
Par la suite, nous nous sommes intéressés à l’analyse et la spécification des besoins qui nous a permis de distinguer les différents acteurs interagissant avec l’application visée.
L’objectif de la partie suivante était la conception détaillée, dans laquelle nous avons fixé la structure globale de l’application.
Le dernier volet de notre projet était la partie réalisation qui a été consacrée à la présentation des outils du travail et les interfaces les plus significatives de notre application.
L’apport de ce travail a été d’une importance très considérable, en effet, il nous a permis : de suivre une méthodologie de travail bien étudié, d’approfondir nos connaissances dans le monde de développement des applications et de nous bien nous exercer sur le Framework GWT et Ext.
La réalisation d’un tel projet, nous a permis d’apprendre et de toucher du doigt une partie de divers aspects du métier de développeur et de celui du concepteur.
61
Annexe A : UML
Figure 38: Les différentes vues du langage UML
Diagramme de cas d’utilisation
Figure 39: Les cas d’utilisation
Montre les interactions fonctionnelles entre les acteurs et le système à l’étude
Acteur : rôle joué par un utilisateur humain ou un autre système qui interagit directement avec le système étudié. Un acteur participe à au moins un cas d’utilisation.
Cas d’utilisation(use case) : ensemble de séquences d’actions réalisées par le système produisant un résultat observable intéressant pour un acteur particulier. Collection de scénarios reliés par un objectif utilisateur commun.
62
Association : utilisée dans ce type de diagramme pour relier les acteurs et les cas d’utilisation par une relation qui signifie simplement « participe à ».
Inclusion : le cas d’utilisation de base en incorpore explicitement un autre, de façon obligatoire, à un endroit spécifié dans ses enchaînements.
Extension : le cas d’utilisation de base en incorpore implicitement un autre, de façon optionnelle, à un endroit spécifié indirectement dans celui qui procède à l’extension Généralisation : les cas d’utilisation descendants héritent de la description de leur parent commun. Chacun d’entre eux peut néanmoins comprendre des relations spécifiques supplémentaires avec d’autres acteurs ou cas d’utilisation.
Diagramme de séquence
Montre la séquence verticale des messages passés entre objets au sein d’une interaction
Figure 40: Les diagrammes de séquence
Ligne de vie : représentation de l’existence d’un élément participant dans un diagramme de séquence. Cela peut être un acteur ou le système en modélisation d’exigences, des objets logiciels en conception préliminaire ou conception détaillée.
Message : élément de communication unidirectionnel entre objets qui déclenche une activité dans l’objet destinataire. La réception d’un message provoque un événement dans l’objet récepteur.
La flèche pointillée représente un retour au sens UML. Cela signifie que le message en question est le résultat direct du message précédent.
Spécification d’activation : bande blanche qui représente une période d’activité sur une ligne de vie.
Message synchrone : envoi de message pour lequel l’émetteur se bloque en attente du retour et qui est représenté par une flèche pleine.
Un message asynchrone, au contraire, est représenté par une flèche ouverte.
Occurrence d’interaction : une interaction peut faire référence explicitement à une autre interaction grâce à un cadre avec le mot-clé ref et indiquant le nom de l’autre interaction.
UML 2 a ajouté une nouvelle notation très utile : les cadres d’interaction.
Chaque cadre possède un opérateur et peut être divisé en fragments.
63 Les principaux opérateurs sont :
• loop : boucle. Le fragment peut s’exécuter plusieurs fois, et la condition de garde explicite l’itération.
• opt : optionnel. Le fragment ne s’exécute que si la condition fournie est vraie.
• alt : fragments alternatifs. Seul le fragment possédant la condition vraie s’exécutera.
Diagramme de classes
Montre les briques de base statiques : classes, associations, interfaces, attributs, opérations, généralisations, etc.
Classe: description abstraite d’un ensemble d’objets qui partagent les mêmes propriétés (attributs et associations) et comportements (opérations et états).
Attribut : donnée déclarée au niveau d’une classe, éventuellement typée, à laquelle chacun des objets de cette classe donne une valeur. Un attribut peut posséder une multiplicité et une valeur initiale.
Un attribut dérivé (« / ») est un attribut dont la valeur peut être déduite d’autres informations disponibles dans le modèle.
Opération : élément de comportement des objets, défini de manière globale dans leur classe. Une opération peut déclarer des paramètres (eux-mêmes typés) ainsi qu’un type de retour.
Figure 41: Les associations entre classes
Association : relation sémantique durable entre deux classes, qui décrit un ensemble de liens entre instances. Une association est bidirectionnelle par défaut, sauf si l’on restreint sa navigabilité en ajoutant une flèche.
Rôle : nom donné à une extrémité d’une association ; par extension, manière dont les instances d’une classe voient les instances d’une autre classe au travers d’une association.
Multiplicité : le nombre d’objets (min..max) qui peuvent participer à une relation avec un autre objet dans le cadre d’une association. Multiplicités fréquentes :
• 0..1 = optionnel (mais pas multiple)
• 1 = exactement 1
• 0..* = * = quelconque
• 1..* = au moins 1
64
Annexe B : GWT
L’outil GWT se décompose en deux grandes briques :
Le framework de composants.
Le compilateur Java vers JavaScript :
Toute l’ingéniosité de GWT est d’avoir su construire un compilateur Java vers JavaScript.
Un compilateur intelligent capable d’optimiser et de générer du code tout en respectant les préceptes de base du Web. Toute cette face cachée de GWT est encore très méconnue du grand public, qui, après tout, n’a pas à se soucier des implémentations internes du
compilateur. Et pourtant, les vraies pépites, la vraie beauté de ce framework réside dans cette partie passionnante de GWT. Pour celui qui sait décrypter un minimum les nombreuses subtilités et configurations du compilateur, chaque fonctionnalité est une source d’inspiration unique.
Figure42: Le compilateur GWT
Le compilateur GWT est en perpétuelle évolution car la taille du framework ne cesse
d’augmenter (il suffit d’observer le nombre de nouvelles API). Les utilisateurs n’ont de cesse
65
de réclamer des applications réactives avec des temps de chargement instantanés ; impossible dans ce contexte de s’assoir sur ses lauriers. Plus qu’une nécessité, l’amélioration du
JavaScript généré par le compilateur est devenue pour chaque version une urgence vitale.
Ce chapitre explore les nombreuses facettes du compilateur GWT et aborde la structure des fichiers générés et les différentes optimisations. Un éclairage particulier est apporté au mécanisme permettant d’étendre le processus de génération pour y ajouter des traitements spécifiques.
1) Introduction au compilateur
Le compilateur de GWT est l’essence même du framework. Lorsqu’on sait la richesse des sept mille classes du JDK, on réalise que celui qui ose imaginer un jour que ce langage peut produire du code JavaScript a du génie.
Même s’il est vrai qu’il existe des similitudes entre Java et JavaScript, certaines subtilités peuvent poser problème. Java propose des classes, JavaScript des prototypes de méthodes.
Java dispose d’un mécanisme d’espaces de nommage (les fameux packages), JavaScript non.
Java permet d’effectuer des appels polymorphiques, ils sont plus complexes en JavaScript.
Java est un langage à typage statique, JavaScript un langage à typage dynamique.
Malgré tous ces points, GWT réussit à marier ces deux langages sans briser à aucun moment leur sémantique respective.
Pour le compiler en JavaScript, nous utilisons le script Ant généré par GWT lors de la création du squelette projet. Ce script contient une tâche gwtc à laquelle nous ajoutons les options de compilation suivante –draftCompile et –style PRETTY. La première demande au compilateur de ne pas trop optimiser le script cible. En production, cette option est à proscrire, car elle a tendance à générer un gros fichier.
En revanche, pour des raisons pédagogiques, cela permet d’obtenir une version fidèle du JavaScript avant optimisation.
La seconde option demande à GWT d’afficher un fichier source JavaScript lisible non obfusqué. Cela permet de mieux comprendre le contenu du script.
2) Les étapes du compilateur
Nous allons ici détailler les différentes étapes menant à la génération des artéfacts lors de la compilation d’un programme GWT. L’idée est ici de bien comprendre le processus
d’optimisation et le modèle interne au compilateur.
GWT a besoin du code source Java.
Il y a un débat récurrent au sein des contributeurs GWT qui est celui du modèle de
compilation. À l’origine, le choix a été de s’appuyer sur le code source Java pour générer le JavaScript plutôt que réutiliser le bte code. Nous ne discuterons pas ici de la pertinence de
66
cette décision. Il faut simplement savoir que GWT a besoin du code source car il extrait certaines informations telles que le code JSNI. Une autre raison avancée par les créateurs de GWT est la possibilité d’optimiser à partir d’informations présentes uniquement dans le code source. Si on prend, par exemple, les types génériques (Class<T>), ceux-ci sont réécrits par le compilateur.
Citons maintenant les différentes étapes intervenant lors de la compilation :
Lecture des informations de configuration
Création de l’arbre syntaxique GWT
La génération de code JavaScript et les optimisations
La réduction de code (pruning)
La finalisation de méthodes et de classes
La substitution par appels statiques
La réduction de type
L’élimination de code mort
Figure 4348: Structure de l’arbre AST GWT 3) Accélération des temps de compilation
Vu la complexité des optimisations et le mode de fonctionnement du compilateur, ce n’est pas une surprise si l’une des préoccupations majeures des développeurs GWT concernent les temps de compilation. Avec GWT 2 et la possibilité de tester le code à partir d’un vrai navigateur, cette contrainte ne devrait plus réellement constituer un facteur de blocage. En
Vu la complexité des optimisations et le mode de fonctionnement du compilateur, ce n’est pas une surprise si l’une des préoccupations majeures des développeurs GWT concernent les temps de compilation. Avec GWT 2 et la possibilité de tester le code à partir d’un vrai navigateur, cette contrainte ne devrait plus réellement constituer un facteur de blocage. En