Conception Et Réalisation D'une Application de Gestion Des Comptes Mail Et Internet PDF

Conception et ralisation
dune application de gestion

des comptes mail et internet
Ralis par : Wahid Mejri & Mohamed Slim Arafa
UNIVERSITE VIRTUELLE DE TUNIS
Licence Appliques en Sciences et Techniques de l'Information et de

Communications
Organisme daccueil :INBMI
Encadr par : Awatef Mejri
Anne universitaire 2010-2011
Conception et ralisation dune application de gestion des comptes mail et internet
Remerciement
Il met particulirement agrable avant de prsenter mon travail, dexprimer toute
ma gratitude envers les personnes qui de prs ou de loin mont apport leur
sollicitude.
Jadresse ma profonde reconnaissance au responsable du service messagerie

Edunet Mme Awatef Mejri pour laide, les explications pertinentes et les
conseils prcieux qui ont le grand impact dans la russite du projet ralis.
Je voudrais exprimer, galement, mes vifs gratitudes et remerciements mes

collgues de l INBMI pour leur aide et leurs remarques constructives.
Enfin, ma profonde reconnaissance au directeur gnral de l INBMI Mr

SkanderGhneya, Mr Yanes Ammar chef de service quipement et maintenance
ainsi que tous les membres de ladministration pour leffort et le soin accords afin
de russir notre projet.
Contenu
Chapitre 1 : Prsentation gnrale du projet .........................................................................8
1
Prsentation du projet ...................................................................................................9
Prsentation de l'organisme d'accueil............................................................................9
2.1
Le rle de lINBMI en tant que FSI .....................................................................................9
2.2
Architecture des rseaux des tablissements ..................................................................10
2.3
Architecture de base : les serveurs SLIS ...........................................................................11
2.4
Emplacement dans le rseau ...........................................................................................12
Conclusion ....................................................................................................................13
Chapitre 2 : Etat de lart .......................................................................................................14

Introduction .........................................................................................................................15
1
Etude de lexistant........................................................................................................15
Critiques de lexistant ...................................................................................................15
Prsentation du travail demand .................................................................................16
Model et mthodologie adopts ..................................................................................16
4.1
Model ..............................................................................................................................16
4.2
Mthodologie ..................................................................................................................17
Choix des outils de dveloppement .............................................................................17

5.1NetBeans.................................................................................................................................17
5.2GWT ........................................................................................................................................17
5.3
PostgreSQL ......................................................................................................................18
5.4
GXT ..................................................................................................................................19
5.5
IReport ............................................................................................................................19
Conclusion ....................................................................................................................19
Chapitre 3 : Analyse des besoins et spcification .................................................................20

Introduction .........................................................................................................................21
1
Analyse des besoins .....................................................................................................21

1.1
1.1.1
1.1.2
1.2
Les besoins fonctionnels........................................................................................................... 21

Les besoins non fonctionnels.................................................................................................... 21
Rsultats attendus...........................................................................................................22
Les diagrammes des cas dutilisation ...........................................................................22

2.1
Identification des acteurs ................................................................................................22
2.2
Les diffrents cas dutilisation .........................................................................................23
2.2.1
2.2.2
Les besoins attendus de lapplication ..............................................................................21
Cas dutilisation prliminaire .................................................................................................... 23

Cas dutilisations dtaills ........................................................................................................ 25
Conclusion ....................................................................................................................31
3

Chapitre 4 : Conception ........................................................................................................32
Introduction .........................................................................................................................33
1
Architecture de lapplication ........................................................................................33

1.1
Prsentation de l'architecture 2 niveaux ......................................................................33
1.2
Prsentation de l'architecture 3 niveaux ......................................................................34
1.3
Architecture adopte ......................................................................................................35
Conception dtailles ...................................................................................................35

2.1
2.1.1
2.1.2
Vue statique ....................................................................................................................36

Diagramme des cas dutilisation ............................................................................................... 36
Diagramme de classes .............................................................................................................. 36
.............................................................................................................................................37
2.1.3
Diagramme de dploiement ..................................................................................................... 38
.............................................................................................................................................38
2.1.4
Vue dynamique : Diagramme de squence .....................................................................39
Conclusion ....................................................................................................................44
Chapitre 5 : Ralisation ........................................................................................................45

Introduction .........................................................................................................................46
1
Environnement de dveloppement ..............................................................................46

1.1
Environnement Matriel .................................................................................................46
1.2
Environnement Logiciel ...................................................................................................46
1.3
Choix des outils de dveloppement.................................................................................46
Architecture gnrale de l'application .........................................................................47
Diagramme de classe final ...........................................................................................50
Principales interfaces graphiques ................................................................................50

5.1
Authentification ..............................................................................................................51
5.2 ................................................................................................................................................51
5.2.1
5.2.2
5.2.3
5.3
Ajouter un utilisateur ............................................................................................................... 51

Consulter les utilisateurs .......................................................................................................... 52
Les traces utilisateurs ............................................................................................................... 53
Gestion des comptes Mail ...............................................................................................54
5. 3.1 Lajout dun abonn ................................................................................................................. 54

5.3.2
La recherche dun compte et limpression ................................................................................ 55
5.3.3 Les tats dun compte : ................................................................................................................. 57
5.4 Gestion des serveurs Slis............................................................................................................... 58
Bibliographie : ..............................................................................................................................69
Netographie : ...............................................................................................................................69
Annexe A : UML ...................................................................................................................61

Annexe B : GWT ...................................................................................................................64
Liste des figures

Figure 1: Architecture rseau d'un tablissement ...10
Figure 2: Schma d'un rseau avec passerelle SLIS11
Figure 3: cas d'utilisation prliminaire.23
Figure 4 : Cas dutilisation Sauthentifier 24
Figure 5 : Cas dutilisation Grer droits daccs ..25
Figure 6 : Cas dutilisation Grer les comptes mail 27
Figure 7 : Cas dutilisation gestion des serveurs Slis .29
Figure 8: Architecture 2 niveaux ...33
Figure 9: Architecture 3 niveaux..33
Figure 10 : diagramme de classes.36
Figure 11 : diagramme de dploiement37
Figure 12 : diagramme de squence du cas "authentification".38
Figure 13 : diagramme de squence du cas " Grer les utilisateurs et les droits d'accs "......39
Figure 144 : diagramme de squence du cas " Grer les utilisateurs et les droits d'accs ..40
Figure 155 : Diagramme de squence du cas grer les comptes41
Figure 16 : Diagramme de squence du cas grer les comptes42
Figure 17 : Diagramme de squence du cas grer les serveurs Slis 43
Figure 168 : Architecture client-serveur de l'application47
Figure 179 : Liste des vnements de lapplication...48
Figure 20 : Liste des vnements de lapplication48
Figure 21 : Le contrleur principal (Dispatcher)..49
Figure 22 : Les Beans49
Figure 2318 : Interface d'authentification.50
Figure 2419 : Message d'erreur.50
Figure 25 : Interface principale.50
Figure 26 : Ajout utilisateur..52
Figure 2720 : information sur les utilisateurs...52
Figure 2821 : Trace des utilisateurs.53
Figure 2922 : Ajout dun abonn.54
Figure 30 : formulaire de gnration de compte..54
Figure 3123 : recherche de compte par ltablissement.54
5

Figure 32 : Impression de compte55
Figure 33 : Etats des comptes56
Figure 34 : Validation des comptes..56
Figure 35 : ajout dun serveur Slis.57
Figure 36 : Ajout dun Slis..57
Figure 37 : Actions sur Slis58
Figure 38: Les diffrentes vues du langage UML..61
Figure 39: Les cas dutilisation..61
Figure 40: Les diagrammes de squence62
Figure 41: Les associations entre classes....63
Figure42: Le compilateur GWT.64
Figure 4324: Structure de larbre AST GWT 66
Figure44: Vue gnrale du service RPC.67
Introduction gnrale
Les technologies de linformation et de communication TIC ont t introduites dans le
systme ducatif tunisien afin, dune part, de diffuser la culture numrique auprs des jeunes
de la socit et, dautre part, de faciliter lapprentissage des connaissances par les jeunes
apprenants, en dveloppant des contenus pdagogiques adopts.
La diffusion des TIC dans le systme de lducation a touch toutes les composantes :
infrastructure, quipements, ressources humaines, dveloppement de contenu.
Les efforts ont dbut par lquipement des tablissements ducatifs. Lobjectif poursuivi : en
premier lieu quiper les coles, les collges et les lyces par des laboratoires dinformatique.
En deuxime lieu connecter les tablissements scolaires au service Internet : cette prestation a
t introduite progressivement dans les tablissements, permettant ainsi de couvrir la quasitotalit des rseaux ducatifs.
Autant que lutilisation de lInternet est bien gnralise, autant quelle prsente un risque
potentiel sur lintgrit et la confidentialit de lensemble des donnes ainsi que les ressources
matrielles et logicielles de ltablissement.
Linstitut nationale de bureautique et de micro-informatique(INBMI) est charg de concrtiser
les choix du Ministre de lducation et de la formation dans le domaine des TIC, et afin de
protger les rseaux contre les accs caractres destructifs, cherche contrler les accs
internet partir des serveurs installs dans les tablissements.
Dans ce cadre, il nous a t propos de crer une application web qui permet la gestion des
tablissements et services offerts aux utilisateurs notamment le service mail et laccs internet
personnalis.
Aprs certaines recherches prliminaires et grce des informations collectes nous avons
labor notre vision de lapplication, son architecture, ainsi que les outils et les technologies
utiles. Dans ce contexte, le travail ralis sur cinq chapitres principaux dont on parle : dans le
premier sur lorganisme daccueil, dans le deuxime sur ltat de lart, dans le troisime nous
allons tudier les besoins de la solution adopte et identifier les acteurs ainsi que leurs cas
dutilisations ensuite nous allons entamer la partie conception dtaille et en fin nous allons
prsenter notre environnement de dveloppement permettant de raliser notre application.
Chapitre 1 : Prsentation
gnrale du projet
Prsentation du projet
Le Rseau Educatif Tunisien connecte aujourd'hui l'ensemble des tablissements ducatifs

ainsi que l'ensemble des institutions relevant du Ministre de l'ducation et de la formation
savoir les tablissements ducatifs, les centres de formation professionnelle, les CREFOC,
Les DREF, CENAFFIF.
Vue l'volution des technologies de l'information, l'mergence des services Internet et Intranet
et le nombre assez important des utilisateurs de ces services, la Ministre de l'ducation et de
la formation s'oriente vers la construction et le dveloppement des applications assurant les
besoins de contrle, de scurit et de confidentialit; protgeant les rseaux contre les accs
caractres non ducatifs ou non administratifs ou caractres destructifs.
Dans ce cadre le prsent projet consiste :
Raliser une application Web qui permet de grer les comptes mail et internet des
employs du ministre,
Concevoir et dvelopper un module de centralisation des journaux d'accs Internet
dans l' FSI de l'INBMI et exploitation de ces journaux.
Prsentation de l'organisme d'accueil
L'Institut Nationale de Bureautique et de Micro-informatique
(INBMI) est
l'unique
fournisseur de service Internet pour le domaine de l'ducation et de la formation, contribue au

dveloppement du rseau ducatif national en assurant l'interconnexion des tablissements au
rseau internet, et aux rseaux numriques ducatifs.
L'INBMI permet aux tablissements, aux enseignants et au personnel du ministre de
l'ducation et de la formation de se connecter Internet en utilisant plusieurs types de
connexion offert par loprateur de tlcommunication (RTC mono poste ou rseau, LS,
ADSL) et ce selon leurs demandes ou selon des programmes nationaux de connexions des
tablissements aux rseaux national ducatif.
2.1
Le rle de lINBMI en tant que FSI
L'INBMI fournit une plate-forme pour la messagerie lectronique la disposition des

utilisateurs du rseau ducatif et administratif du ministre.
9

L'INBMI offre un service dhbergement des sites Web.
Un serveur FTP est mis la disposition des utilisateurs et ce pour l'envoi de fichiers.
L'quipe FSI assure le suivi, la fiabilit, la disponibilit et la bonne qualit des services
offerts.
L'quipe FSI est linterlocuteur unique des utilisateurs du rseau ducatif concernant toutes
les questions relatives leur connexion Internet. En particulier, l'quipe FSI gre lattribution
des plages dadresses IP et les noms de domaine ainsi que la gestion des lignes de
tlcommunications.
2.2
Architecture des rseaux des tablissements
Lusage pdagogique dInternet ncessite des connexions de longue dure, voire permanentes,
partir de nombreux postes de travail auxquels accdent des lves, des enseignants et des
cadres administratifs. Cela suppose de mettre en place des dispositifs adapts :
interdire les intrusions
filtrer laccs aux sites sensibles
utiliser au mieux le dbit disponible
Les problmes poss par un usage scolaire, particulirement en connexion permanente sont
les suivants :
Rsoudre les problmes de scurit.
Faciliter laccs aux documents en ligne.
Interdire laccs aux sites dangereux.
Diverses solutions commerciales existent. LINBMI a dcid dadopter une solution

dveloppe dans lacadmie de Grenoble et dploye dans des centaines dtablissement, le
SLIS (serveur Linux pour lInternet scolaire). Il sagit dun logiciel implant sur une machine
interpose entre larrive dInternet dans ltablissement et les machines vers lesquelles elle
va distribuer laccs Internet, de faon scurise.
10
Figure 25: Architecture rseau d'un tablissement
2.3
Architecture de base : les serveurs SLIS
Le serveur SLIS est un serveur logiciel mis en uvre, l'origine, par l'quipe de dveloppeurs
du CARMI de l'acadmie de Grenoble (chef de projet Bruno Breznik). Il fonctionne en
environnement Linux et est distribu sous licence GPL. Install l'entre du rseau d'une
cole, ce serveur joue le rle de connecteur de l'cole l'internet en proposant un
environnement entirement scuris. Le SLIS fournit la scurit, les ressources d'archivage
et la gestion des paramtres personnels de chaque utilisateur du rseau.
Le SLIS propose galement les fonctionnalits de base d'un serveur complet qui lui
permettent d'tre exploit dans un cadre pdagogique.
Le serveur SLIS inclut dans sa configuration de base :
Un serveur de fichiers (Samba),
Un serveur proxy (Squid),
Un serveur web (apache)
Un serveur de bases de donnes (Postgres).
L'architecture actuelle du rseau des tablissements ducatifs rassemble et relie l'ensemble des
SLIS, via Internet, un site central situ dans les locaux de l'INBMI.
Ce serveur central appel SLIM (SLIS Management) a pour rle :
De relayer les informations utiles la mise jour des SLIS des coles (mise jour
logicielle, mise jour de scurit, black-List des sites Internet interdits...). Chaque SLIS est
synchronis avec le SLIS central une fois par jour (synchronisation programme le plus
souvent la nuit).
11

D'agrger des statistiques sur le fonctionnement des SLIS (tableau de bord).
De grer les alertes lors de la dfaillance d'un SLIS du rseau.
De permettre l'administration et la prise de commande distance des SLIS (maintenance).
Le SLIS est entirement administrable distance.
2.4
Emplacement dans le rseau
Figure 26: Schma d'un rseau avec passerelle SLIS
Le SLIS se trouve juste aprs le routeur qui est connect par Internet et toutes les informations
venant ou allant vers Internet doivent passer par lui. Pour cela il est quip de deux cartes
rseaux qui ne possdent pas les mmes plages dadresses.
Une fois que le SLIS est install sur le rseau, tous les postes clients doivent tre reconfigurs
pour que les navigateurs Internet utilisent le SLIS comme passerelle. Cette procdure est trs
rapide et ne doit tre effectue quune seule fois. Par la suite, le SLIS transmettra
automatiquement aux postes tous les changements dans la politique daccs Internet :
services autoriss, sites interdits
12

Cette passerelle est rellement indispensable dans un tablissement scolaire car elle permet de
soulager les professeurs de la lourde tche de surveillance des lves pour quils n'aillent pas
sur des sites "douteux". La protection du rseau apporte par cette solution est galement une
grande aide pour ladministrateur du rseau.
Larchitecture de la solution de messagerie de lINBMI est compose principalement de 3
serveurs :
Serveurs LDAP Master : contenant toutes les informations concernant les comptes
Internet et la messagerie
SMTP-IN: Reoit les emails provenant des utilisateurs, les envoie aux serveurs Mail
Store et assure les services dantispam et dantivirus.
SMTP-OUT : Reoit les emails des clients, les achemine vers les serveurs de
messageries de lATI et assure les services dantispam et dantivirus.
Conclusion
Ce chapitre nous a permis d'introduire notre projet et de prsenter l'organisme d'accueil;

l'tude de ltat et lenvironnement de dveloppement seront dcrites dans le chapitre suivant.
13
Chapitre 2 : Etat de lart
14
Introduction
Ce chapitre prsente un tat des lieux : il sagit dune tude de lexistant suivie de critique
permettant au projet de prsenter une amlioration rsumant lensemble des solutions
retenues.
Etude de lexistant
Ltude de lexistant est une phase importante pour bien comprendre le systme actuel et
dfinir ses objectifs. Le service informatique de lINBMI est responsable de grer les serveurs
Slis, grer les utilisateurs de ce serveurs et de grer les mails et logs des internautes
(enseignant, lve, cadre administratif, etc.).
Ce service utilise linterface dadministration fournit par SLIM pour :
Ajouter un serveur Slis et grer la disquette de configuration
Consulter des informations sur les serveurs
Ainsi que pour consulter les logs des serveurs il est indispensable de tlcharger le fichier log
qui est un fichier texte plat et le visualiser ;
De plus lapplication contenant les comptes mails et internet des utilisateurs nest pas
synchronise avec les serveurs SLIS donc les utilisateurs sont ajout la main.
Critiques de lexistant
Ltude de lexistant nous a permis de dgager un certain nombre de lacunes :

Dune part loutil dadministration fournit par SLIM, bien quil est puissant ne satisfait pas
tous les besoins ncessaires pour la gestion des serveurs Slis. En effet il est utilis juste pour
gnrer la disquette de configuration. Le suivi des adresses IP des tablissements est ralis
sur un fichier Excel puisque SLIS ne gre pas la langue arabe et difficile manipuler.
Dautre part les fichiers logs tlchargs ne sont pas lisibles, un fichier texte plat trop
volumineux et difficile interroger.
De plus si le serveur Slis est afonctionnel et ncessite une mise au point, on risque de perdre
les anciens fichiers logs.
Lapplication de gestion des utilisateurs et comptes mails nest pas optimis pour
synchroniser avec le serveur SLIM et les serveurs SLIS.
15
Prsentation du travail demand
Dans un souci de concevoir une application avec plus de fonctionnalits possibles et dans le
but davoir une interface plus conviviale et plus facile utiliser tout en tant plus efficace,
nous avons conu une application qui regroupe tous les points cits ci-dessus. Le travail
demand se rsume ainsi dans les fonctionnalits suivantes :
Offrir lutilisateur une interface de gestion des abonns et les comptes mails
correspondant
Offrir lutilisateur une interface permettant la gestion des tablissements et des

serveurs Slis.
Donner lutilisateur la possibilit dajouter les comptes Internet directement au

serveur SLIS de ltablissement et consulter lhistorique de navigation des internautes
utilisant un tel serveur.
Permet ladministrateur de contrler les accs chaque module de lapplication.
Model et mthodologie adopts
4.1
Model
UN modle de dveloppement logiciel dsigne toutes les tapes du dveloppement, de sa

conception sa disparition. L'objectif d'un tel dcoupage est de permettre de dfinir des jalons
intermdiaires permettant la validation du dveloppement logiciel, c'est--dire la conformit
du logiciel avec les besoins exprims, et la vrification du processus de dveloppement.
L'origine de ce dcoupage provient du constat que les erreurs ont un cot d'autant plus lev
qu'elles sont dtectes tardivement dans le processus de ralisation. Le cycle de vie permet de
dtecter les erreurs au plus tt et ainsi de matriser la qualit du logiciel, les dlais de sa
ralisation et les cots associs.
ce fait nous adoptons le modle de cycle de vie en V qui part du principe que les
procdures de vrification de la conformit du logiciel aux spcifications doivent tre
labores ds les phases de conception.
L'norme intrt du cycle en V est qu'il est un excellent support la formalisation de notre
relation avec le futur-utilisateur, Il nous oblige rflchir aux diffrents aspects de sa
demande. La phase de spcification nous permet de vrifier quon a bien compris la demande
des utilisateurs, en effet, cest lquipe de gestion des services Internet de lINBMI qui valide
la spcification.
16
4.2
Mthodologie
Le plus grand avantage dune mthode oriente objet est quelle permet de structurer un
systme sans centrer lanalyse uniquement sur les donnes ou uniquement sur les traitements
mais sur les deux la fois. Une telle approche a pour but de modliser les proprits statiques
et dynamiques de lenvironnement du systme. Elle met en correspondance le problme et la
solution, en prservant la structure et le comportement du systme analys.
Ceci, nous a conduit adopter lapproche oriente objet pour modliser notre systme en se
basant sur les diagrammes UML.
Choix des outils de dveloppement
Pour la ralisation de ce projet nous avons choisi de travailler avec :
NetBeans comme IDE ;
PostgreSQL comme SGBD ;
GXT comme Framework cot Web qui bas sur GWT ;
J2EEcomme langage de programmation.
Ireport pour gnration et lexportation au format Word et PDF de rapport
5.1NetBeans
Cest un environnement de dveloppement intgr (EDI) pour Java, plac en open
source par Sun en juin 2000 sous licence CDDL et GPLv2 (Common
Development and
Distribution License). En plus de Java, NetBeans permet galement de supporter diffrents

autres langages, comme Python, C, C++, XML, Ruby, PHP et HTML. Il comprend toutes les
caractristiques d'un IDE moderne (diteur en couleur, projets multi-langage, refactoring,
diteur graphique d'interfaces et de pages Web).
Conu
en
Java,
NetBeans
est
disponible
sous Windows, Linux, Solaris(sur x86 et
SPARC), Mac OS X et Open VMS.
5.2GWT
Abrviation du Google Web Toolkit ; GWT est un ensemble d'outils logiciels dvelopp
par Google, permettant de crer et maintenir des applications web dynamiques mettant en
uvre JavaScript, en utilisant le langage et les outils Java. C'est un Framework libre distribu
selon les termes de la licence Apache 2.0.
17

GWT met l'accent sur des solutions efficaces et rutilisables aux problmes rencontrs
habituellement par le dveloppement AJAX : difficult du dbogage JavaScript, gestion des
appels asynchrones, problmes de compatibilit entre navigateurs, gestion de l'historique et
des favoris, etc.
GWT est articul autour d'un concept original : lors de la phase de dveloppement,
l'application est crite en Java de faon classique, dans un environnement de dveloppement
intgr Java, et peut tre dbogue avec les outils Java habituels. Une fois l'application prte
tre dploye, le compilateur GWT la traduit en pur JavaScript, avec support automatique et
transparent pour les principaux navigateurs (Internet Explorer, Firefox, Mozilla , Safari ,
Opera ).
Le code JavaScript gnr utilise des techniques d'HTML dynamique et de manipulation du
DOM (Document Object Model) pour les aspects dynamiques de l'interface.
Ce principe est rendu possible par les diffrents composants de GWT:
le compilateur Java vers JavaScript
un navigateur spcialement modifi pour permettre l'excution (et le dbogage) de code

Java natif sans ncessiter la compilation JavaScript
une bibliothque d'mulation JRE : il s'agit d'une implmentation en JavaScript d'un sousensemble de la bibliothque de classes Java standard (en particulier quasiment tout le
package java.lang et une partie de java.util)
une bibliothque de composants graphiques contenant des widgets de base permettant la

construction d'une interface graphique
GWT est souvent appel abusivement un Framework, mais n'en est pas vritablement un car il
impose peu de choses au dveloppeur; comme son nom l'indique, il s'agit d'une bote outils
qui offre des solutions permettant de dvelopper plus facilement des solutions web/AJAX de
dernire gnration, en profitant des outils et comptences Java existants, et en faisant
abstraction de la complexit habituellement lie ce genre de technologies.
5.3
PostgreSQL
PostgreSQL est un systme de gestion de base de donnes relationnelle et objet(SGBDRO).

C'est un outil libre disponible selon les termes d'une licence de type BSD.
Ce systme est concurrent d'autres systmes de gestion de base de donnes, qu'ils soient libres
(comme MySQL et Firebird), ou propritaires(comme Oracle, Sybase, DB2et Microsoft SQL
Server).
18
5.4
GXT
Le vrai nom est EXT-GWT; bas sur le Framework GWT, cest une bibliothque dveloppe
par lentreprise ExtJs leadeur du dveloppement des bibliothques JavaScript ; GWT-Ext est
une librairie de composant graphique, elle fait le pont entre GWT et Ext.
On trouve dans GXT un ensemble de widgets permettant de construire une interface
utilisateur avec des outils varis comme les:
1) Panneaux
2) Boutons
3) Cases cocher
4) Tables / Grilles
5) Botes de dialogues
6) Primitive HTML (dont les images et les hyperliens)
7) Menus et barres de menus
8) Fentres dfilantes
9) Onglets
10) Arbres
5.5
IReport
iReport est un outil de conception WYSIWYG (What You See Is What You Get)
exclusivement rserv la cration de fichier de description pour JasperReports.
Il permet donc de produire de manire assez intuitive des fichiers .jrxml (fichiers XML)
exploitables par JasperReports pour gnrer des rapports au sein d'une application Java.
Le format de rapport gnr dpend ensuite de JasperReports et du code utilis
(html, pdf, csv...).
Conclusion
Aprs avoir mis le projet dans son cadre et aprs avoir mis en place une dmarche de
dveloppement qui nous aidera tout au long du projet, nous pouvons ainsi entamer la
prochaine tape c'est--dire dcortiquer le cahier de charges pour analyser les besoins qui sy
trouvent et ainsi les spcifier.
19
Chapitre 3 : Analyse des

besoins et spcification
20
Introduction
Dans ce chapitre, nous prsenterons les objectifs de notre application, ce qui nous amne
identifier les possibilits du systme et les besoins des utilisateurs que nous essayerons de les
projeter dans des diagrammes de cas dutilisations globales et dtaills.
Analyse des besoins
1.1
Les besoins attendus de lapplication
Lapplication envisage satisfaire les besoins fonctionnels qui seront excuts par le systme
et les besoins non fonctionnels qui perfectionnent la qualit logicielle du systme.
1.1.1 Les besoins fonctionnels

Les besoins fonctionnels ou besoin mtiers reprsentent les actions que le systme doit
excuter, il ne devient oprationnel que sil les satisfait.
Cette application doit couvrir principalement les besoins fonctionnels suivants :
Gestion des tablissements et les abonns mail et internet correspondants
Attribution de compte mail et internet aux abonns suivant la catgorie de

labonns
Faire un Workflow de suivi de ltat de cration de compte mail avec la validation

administrative et technique
Gestion des Slis des tablissements et les utilisateurs correspondants
La gestion des logs (mise jour des logs dun serveur) ;
La gestion des droits daccs.
1.1.2 Les besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spcifiquement le comportement du systme
mais plutt identifient des contraintes internes et externes du systme.
Les principaux besoins non fonctionnels de notre application ce rsument dans les points
suivants :
Le code doit tre clair pour permettre des futures volutions ou amliorations ;
Lergonomie : lapplication offre une interface conviviale et facile utiliser ;

La scurit : lapplication doit respecter la confidentialit des donnes ;
Garantir lintgrit et la cohrence des donnes chaque mise jour et
chaque insertion.
21
1.2
Rsultats attendus
Que lapplication se droule convenablement, de conserver ces fonctionnalits dans

lapplication, et damliorer sil est possible les performances du systme ainsi que les bases
des donnes existantes.
Les diagrammes des cas dutilisation
Montre les interactions fonctionnelles entre les acteurs et le systme

ltude
Acteur : rle jou par un utilisateur humain ou un autre systme qui interagit
directement avec le systme tudi. Un acteur participe au moins un cas
dutilisation.
Cas dutilisation (use case) : ensemble de squences dactions ralises par le

systme produisant un rsultat observable intressant pour un acteur particulier.
Collection de scnarios relis par un objectif utilisateur commun.
Association : utilise dans ce type de diagramme pour relier les acteurs et les cas
dutilisation par une relation qui signifie simplement participe .
Inclusion : le cas dutilisation de base en incorpore explicitement un autre, de faon

obligatoire, un endroit spcifi dans ses enchanements.
Extension : le cas dutilisation de base en incorpore implicitement un autre, de faon

optionnelle, un endroit spcifi indirectement dans celui qui procde lextension
Gnralisation : les cas dutilisation descendants hritent de la description de leur

parent commun. Chacun dentre eux peut nanmoins comprendre des relations
spcifiques supplmentaires avec dautres acteurs ou cas dutilisation.
2.1
Identification des acteurs
Un acteur reprsente un rle jou par une personne qui interagit avec le systme.
Par dfinition, les acteurs sont lextrieur du systme .Les acteurs se recrutent parmi les
utilisateurs du systme et aussi parmi les responsables de sa configuration et de sa
maintenance. Do, les acteurs potentiels qui risquent dinteragir avec lapplication sont :
Lutilisateur (Centre rgional) :Cest un utilisateur rgional, il est responsable

dajouter les comptes mails des utilisateurs faisant partie de la direction rgionale. Cet
utilisateur ne consulte que certains types dabonns (enseignants, tuteur, cadre
administratif rgional).Cet utilisateur ne valide pas la cration de comptes.
22
Lutilisateur responsable mail : Celui-ci valide la cration et la modification mail

signal par le centre rgional. Il la le droit de consulter toutes la base de donne mail.
Lutilisateur SLIS : Il ne consulte que les donnes relatives aux adresses IP des
tablissements et les comptes Internet des utilisateurs de cet tablissement.
Le Super-Utilisateur SLIS : Il a le droit de consulter les logs de tous les internautes

des tablissements.
Ladministrateur (admin) :Cest le grant de lapplication, il a une visibilit totale

sur les bases de donnes. Il a pour tches de grer tout le systme. Il spcifie les
utilisateurs et les droit de chaque un
2.2
Les diffrents cas dutilisation
Ltude de cas dutilisation a pour objectif de dterminer ce que chaque utilisateur attend du
systme. La dtermination du besoin est base sur la reprsentation de linteraction entre
lacteur et le systme.
2.2.1 Cas dutilisation prliminaire

Authentification : permet didentifier chaque utilisateur, et de lui donner laccs aux
fonctionnalits propices.
Grer les utilisateurs et les droits daccs : permet ladministrateur dajouter ou
supprimer ou modifier ou consulter un user. De plus chaque utilisateur lui est associ un
droit dans cette application.
Gestion des tablissements : ajout, suppression, modification et consultation
Grer les abonns mail : permet lutilisateur dajouter ou modifier un abonn
fonctionnant dans un tablissement donn.
Gestion des comptes mail et internet : suivi de ltat de cration dun compte. On
identifie dans ce cas 7 tats : En attente (dossier incomplet), valid administrativement en
attente de cration, valid techniquement et cr, en attente de modification, modification
valide, en attente de suppression, suppression valide.
Grer les serveurs Slis : permet ladministrateur dajouter, modifier ou supprimer ou
consulter le serveur SLIS
Grer les utilisateurs dun serveur Slis : permet ladministrateur dajouter, modifier
ou supprimer un utilisateur dun serveur Slis.
23

Consulter les logs dun serveur Slis : permet lutilisateur de consulter et ou imprimer
les logs dun serveur Slis.
Object-Oriented Model
Model: gestion des utilisateurs et droits d'accs
Package:
Diagram: globale
Author: User
Date: 06/06/2011
Version:
Tous les cas

d'utilisation passe
obligatoirement par le
cas authentification
Grer les utilisateurs et les droits daccs
include
Authentification
administrateur
include
L'administrateur peut
attribuer lui mme les
droits d'accs des autres
acteurs
include
Gestion des tablissements
include
include
include
include
include
utilisateur SLIS
Grer les serveurs Slis
include
Super-Utilisateur SLIS
include
Grer les utilisateurs dun serveur Slis
Gestion des comptes mail et internet
Consulter les logs dun serveur Slis
include
include
responsable mail
Grer les abonns mail
Centre rgional
Figure 27: cas d'utilisation prliminaire
24
2.2.2 Cas dutilisations dtaills

On sintresse aux cas dutilisations les plus pertinents.
2.2.2.1
Cas dutilisation Sauthentifier

Model: Authentification
Package:
administrateur
Diagram: authentification
Author: User Date: 06/06/2011
Version:
utilisateur SLIS
control login mot de passe

authentification
responsable mail
include
En cas de succs
chargement des
prvilges
extends
Centre rgional
recuprer les privilges

Figure 28 : Cas dutilisation Sauthentifier
Description textuelle :
Acteurs primaires : Admin, User-SLIS-Super-User-SLIS , responsable mail, centre rgional.
Description : Tous les utilisateurs de lapplication peuvent accder au systme. Cependant,
chacun deux un certain nombre de privilges. Cest pour
cela, quil faut au dbut
sidentifier en donnant son login et son mot de passe et les privilges seront attribus
lutilisateur.
Analyse :
On a choisi de commencer par traiter ce cas dutilisation par ce que cest le cas qui initialise
tous les autres cas dutilisation.
Une ralisation de ce cas dutilisation Sauthentifier se fait comme suit :
Lutilisateur saisie son login et mot de passe sur la page : Authentification
25

Aprs vrification des donnes, le systme slectionne lutilisateur en cours
Une requte de recherche portant le nom de lutilisateur se dclenche dans la base de donnes
afin dafficher le menu gnral. En cas dexistence de lutilisateur, le systme charge les
privilges attribu prcdemment lutilisateur.
2.2.2.2
Cas dutilisation Grer les utilisateurs et les droits daccs

Model: gestion des utilisateurs et droits d'accs
authentification
Package:
Diagram: gestion user et droit d'accs
Author: User
Date: 06/06/2011
include
Version:
Ajout user
Grer les utilisateurs et droits daccs
extends
administrateur
extends
extends
attribuer des droits d'accs
Consulter les utilisateurs

extends
extends
extends
modifier user
supprimer user
Figure 29 : Cas dutilisation Grer droits daccs
Cas dutilisation : Grer les utilisateurs et les droits daccs
Acteurs primaires : Admin.
Description : aprs lauthentification ladministrateur
peut effectuer la saisie et
lenregistrement de nouveaux utilisateurs, la consultation des utilisateurs avec possibilit de

modification, d'attribution de droits d'accs ou de la suppression d'un utilisateur donn.
Analyse :
Une ralisation de ce cas dutilisation se fait comme suit :
26

Ladministrateur peut effectuer la cration d'un utilisateur en lui attribuant les privilges
souhaits.
L'administrateur consulte la liste des utilisateurs, slectionne un utilisateur pour le modifier ou
le supprimer.
On identifie les privilges suivants :
Droit Nomenclature : ajout suppression et modification des gouvernorats et

tablissements
Droit slection abonn : consultation dabonns mail seulement.
Droit MAJ abonn : ajout, suppression et modification de compte mail (avant

validation)
Droit validation technique ; validation dajout, suppression ou modification de

compte mail
Droit gestion des utilisateurs : ajout suppression modification et consultation des

utilisateurs et leurs droits
Droit gestion SLIS : ajout suppression modification, consultation des serveurs

SLIS avec possibilit dajouter les utilisateurs, tlcharger disquette de config,
avoir le mot de passe root pour la connexion ssh ,
Droit gestion des logs : consultation des journaux des internautes
27
2.2.2.3
Cas dutilisation Grer les comptes mail

grer les abonns mails
extends
crer un abonn
include
extends
consulter la liste des abonns

suppression
extends
administrateur
extends
modification
Authentification
include
responsable mail
extends
gnration compte mail
Gestion des comptes mail et internet
Centre rgional
extends
gnration compte Internet
extends
consulter liste des comptes
Model: gestion des comptes mail

Package:
extends
Diagram: gestion de compte

Author: User
Date: 07/06/2011
Version:
suppression d'un compte
extends
extends
impression d'un compte
modification d'un compte
Figure 30 : Cas dutilisation Grer les comptes mail
Cas dutilisation : Grer les comptes et internet
Acteurs primaires : Admin, responsable mail, centre rgional
28

Description : Aprs authentification lutilisateur cre un abonn mail, lui attribue
ltablissement correspondant. Une fois labonn est enregistr, le systme gnre un compte
mail en concatnant le nom et le prnom avec le domaine correspondant ltablissement de
labonn.
On distingue principalement ces domaines :
inbmi.edunet.tn : pour les employs de l'Inbmi
enseignant.edunet.tn : pour les enseignants
instituteur.edunet.tn : pour les tuteurs
atfp.edunet.tn : pour les formateurs de la formation professionnelle
minedu.edunet.tn : pour les employs au ministre
Analyse :
Lutilisateur choisit un tablissement ; cre un abonn, gnre le compte correspondant.
Le compte ainsi cre est ltat en attente de cration.
Le responsable consulte la liste des comptes en attente de cration et valide la cration de ces
comptes pour quils soient oprationnels.
De mme la suppression et la modification de comptes nest valid que par le responsable
mail.
Le centre rgional signale la cration, la modification ou la suppression dun compte mail
sans valider ces actions
29
2.2.2.4
Cas dutilisation Consulter les logs dun serveur Slis

Gestion des tablissements
cration slis
extends
include
extends
Grer les serveurs Slis
modification slis
utilisateur SLIS
extends
include
suppression slis
Grer les utilisateurs dun serveur Slis
administrateur
extends
extends
extends
suppression user
extends
Consulter les logs dun serveur Slis
ajout depuis la liste des users de l'tablissement
Model: gestion des serveurs Slis
Package:
Diagram: gestion des Slis
Author: User
Date: 07/06/2011
Version:
Figure 31 : Cas dutilisation gestion des serveurs Slis
Cas dutilisation : Gestion des serveurs Slis
Acteurs primaires : Admin, Super-user Slis, user Slis
30

Description : aprs laccs lapplication, l'utilisateur slectionne un tablissement et ajoute
un serveur Slis. S'il existe dj il peut le modifier ou le supprimer.
Pour que le personnel de l'tablissement puisse accder Internet, l'utilisateur charge les
comptes des utilisateurs dans le serveur Slis. Il peut ensuite voir les journaux d'accs Internet
de tout l'tablissement ou un utilisateur donn.
Analyse :
Ladministrateur ou lutilisateur choisit un tablissement cre un serveur Slis avec l'adresse ip
adquate puis slectionne les utilisateurs de cet tablissement et les insre dans le serveur Slis.
Le super user Slis peut consulter ou imprimer les logs des internautes utilisant ce serveur.
Conclusion
Ce chapitre a t consacr pour la spcification des besoins fonctionnels et non fonctionnels

du systme rsultant, ce qui correspondait aux diffrentes activits de la premire phase du
cycle de dveloppement du notre systme. Dans le chapitre suivant, nous tudierons la phase
de conception.
31
Chapitre 4 : Conception
32
Introduction
Vu que nous avons achev la premire phase (Dmarrage) du cycle de dveloppement, nous
aborderons dans ce chapitre la deuxime phase (Elaboration) qui se concentre essentiellement
sur la dfinition de larchitecture du systme ainsi que sur lanalyse et la conception des
besoins et des exigences des utilisateurs.
Lactivit danalyse et de conception permet de traduire les besoins fonctionnels et les
contraintes issues du cahier des charges et de la spcification des exigences dans un langage
plus professionnel et comprhensible par tous les individus intervenants dans la ralisation et
lutilisation de lapplication
Architecture de lapplication
Dans les phases prliminaires du dveloppement dune application ou de la refonte dun

systme dinformation, la dfinition de larchitecture technique consiste faire les choix de
technologies et dorganisation de composants logiciels les plus adapts aux besoins et aux
contraintes de lorganisation daccueil.
Ces choix sont ensuite relays au sein de notre projet, guidant la conception et permettant la
transformation dun modle fonctionnel en application performante et robuste.
1.1
Prsentation de l'architecture 2 niveaux
L'architecture deux niveaux (aussi appele architecture 2-tiers, tiers signifiant tages en
anglais) caractrise les systmes clients/serveurs dans lesquels le client demande une
ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel
une autre application afin de fournir le service.
33
Figure 32: Architecture 2 niveaux
1.2
Prsentation de l'architecture 3 niveaux
Dans l'architecture 3 niveaux (appeles architecture 3-tiers), il existe un niveau

intermdiaire, c'est--dire que l'on a gnralement une architecture partage entre:
1. Le client: le demandeur de ressources
2. Le serveur d'application (appel aussi middleware): le serveur charg de fournir la
ressource mais faisant appel un autre serveur
3. Le serveur secondaire (gnralement un serveur de base de donnes), fournissant un
service au premier serveur.
Figure 33: Architecture 3 niveaux
34

Tout systme d'information ncessite la ralisation de trois groupes de fonctions: le stockage
des donnes, la logique applicative et la prsentation. Ces trois parties sont indpendantes les
unes des autres: on peut ainsi vouloir modifier la prsentation sans modifier la logique
applicative. La conception de chaque partie doit galement tre indpendante, toutefois la
conception de la couche la plus basse est utilise dans la couche d'au-dessus. Ainsi la
conception de la logique applicative se base sur le modle de donnes, alors que la conception
de la prsentation dpend de la logique applicative.
1.3
Architecture adopte
Vis--vis lexistant de lINBMI: organisation, comptences, architecture du systme

dinformation, nous avons choisi larchitecture 3 tiers car cest une architecture :
prenne: applicable durant une trs longue priode de temps et accepter des changements
technologiques ou fonctionnels tout en protgeant les investissements raliss.
modulaire: un lment peut tre remplac ou modifi sans devoir changer toute
larchitecture.
ouverte: elle doit permettre de construire ou de modifier une solution partir de composants
provenant de diffrents constructeurs.
Conception dtailles
UML est une approche oriente objet de modlisation qui permet de modliser un problme
dune manire standard.
UML vite de se dfinir comme une mthodologie, comme son nom lindique, cest un
langage visuel qui permet dexprimer la comprhension dun systme : il comporte 9
principaux diagrammes regroups dans deux vues diffrentes:
Vue Statique (cinq diagrammes structurels)
Diagramme de Cas dutilisation.
Diagramme de Classes.
Diagramme dObjets.
Diagramme de Composants.
Diagramme de Dploiement.
Vue Dynamique (quatre diagrammes comportementaux)
Diagramme de Squence.
35
Diagramme dactivits.
Diagramme dtats transitions.
Diagramme de Collaboration.
A cet effet on prsente quelques diagrammes de modlisation, quon a jug les plus
importants pour la comprhension du fonctionnement du systme.
2.1
Vue statique
2.1.1 Diagramme des cas dutilisation

Les diagrammes de cas dutilisation reprsentent toutes les interactions des utilisateurs avec le
systme, comme nous avons dj les dcrit dans le chapitre prcdent Analyse des besoins et
spcification
2.1.2 Diagramme de classes

Le diagramme de classes reprsente les classes constituant le systme et les associations entre
elles.
Les diagrammes de classes expriment de manire gnrale la structure statique dun systme,
en termes de classe et de relations entre ces classes.
De mme quune classe dcrit un ensemble dobjets, une association dcrit un ensemble de
liens ; les objets sont des instances de classes et les liens sont des instances de relations.
36

Compte
-
0..1
IdenUniq
LogiInte
PassInte
AdreMail
PassMail
CodeEtatComp
DateValiAdmi
DateValiTech
smtp
pop
observation
Model: gestion des comptes mail et Internet

:
:
:
:
:
:
:
:
:
:
:
String
String
String
String
String
String
Date
Date
String
String
String
Package:
Nomenclature_Discipline
Diagram: global
Author: User
- CodeDisc : String
- LibeDisc : String
Date: 08/06/2011
Version:
0..1
Abonne
0..*
-
0..1
0..1 0..*
Nomenclature_EtatCompte
- CodeEtatComp : String
- LibeEtatComp : String
IdenUniq
CIN
prenonAr
nomAr
prenomFr
nomFr
CodeDisc
CodeFonc
CodeEtab
CodeTypeEtab
Nomenclature_Fonction
0..*
:
:
:
:
:
:
:
:
:
:
- CodeFonc : String
- LibeFonc : String
String
String
String
String
String
String
String
String
String
String
0..*
0..1
Nomenclature_TypeEtablissement
0..*
- CodeTypeEtab : String
- LibeTypeEtab : String
0..1
0..*
0..1
0..1
Securite_Utilisateur
-
CodUti
PasUti
NomPre
DroiNome
DroiAbonSele
DroiAbonMaj
DroiTraiAdmiComp
DroiTraiTechComp
DroiGestUtil
userSlis
superUserSlis
codetypeetab
codegouv
codeetab
:
:
:
:
:
:
:
:
:
:
:
:
:
:
String
String
String
boolean
boolean
boolean
boolean
boolean
boolean
boolean
boolean
String
String
String
0..*
0..1
0..*
Nomenclature_Etablissement
0..*
0..1
0..*
0..1
Nomenclature_Gouvernorat
0..1 0..*
CodeEtab
CodeTypeEtab
LibeEtab
CodeGouv
CodeDele
CodeDoma
phoneInternet
phone
:
:
:
:
:
:
:
:
String
String
String
String
String
String
String
String
- CodeGouv : String
- LibeGouv : String
0..1
0..1
0..*
0..1
0..*
slisADSL
-
phoneInternet
ip_gateway
gateway_user
gateway_passwd
creation_date
ip_wan
ip_lan
netmask_wan
netmask_lan
install_date
network_name
password_inbmi
password_web
password_db
site_code
codedre
codetypeetab
installer
type
rques
access_squid
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
String
String
String
String
Date
String
String
String
String
Date
String
String
String
String
String
String
String
String
String
String
0..*
0..1
time
elapsed
remotehost
code_status
url
user
nomprenom
site_code
:
:
:
:
:
:
:
:
Date
int
String
String
String
String
String
String
Figure 34 : diagramme de classes
37
Nomenclature_Domaine
- CodeDoma : String
- LibeDoma : String
journaluser
-
log_level
log_location
log_msg
log_time
:
:
:
:
String
String
String
Date

Daprs
ltude
du
systme
existant
et
des
diffrents
diagrammes
de
cas
dutilisation, nous avons pu dgager les principales classes illustres dans la figure cidessus pour avoir une vue plus claire du systme tudi.
A partir de ce diagramme, on dgage les entits de la base de donnes ainsi que les java beans
correspondant dans lapplication dvelopper.
Ce diagramme de classe ne contient pas des mthodes. Ces procdures seront voques aprs
le diagramme de squence.
Le mapping objet relationnel sera dcrit dans la partie ralisation.
2.1.3 Diagramme de dploiement

Le diagramme de dploiement est une vue statique qui sert reprsenter l'utilisation de
l'infrastructure physique par le systme et la manire dont les composants du systme sont
rpartis ainsi que leurs relations entre eux.
Figure 35 : diagramme de dploiement
38
2.1.4 Vue dynamique : Diagramme de squence

Montre la squence verticale des messages passs entre objets au sein dune interaction
Ligne de vie : reprsentation de lexistence dun lment participant dans un diagramme de
squence. Cela peut tre un acteur ou le systme en modlisation dexigences, des objets
logiciels en conception prliminaire ou conception dtaille.
Message : lment de communication unidirectionnel entre objets qui dclenche une activit
dans lobjet destinataire. La rception dun message provoque un vnement dans lobjet
rcepteur. La flche pointille reprsente un retour au sens UML. Cela signifie que le message
en question est le rsultat direct du message prcdent.
Aprs ltude des cas dutilisation, nous avons pu dgager les diagrammes de squences
correspondants dont voici les plus importants :
2.1.4.1
Diagramme de squence du cas authentification
diagramme de squence authentification
Base de donne
serveur d'application
Client
1- saisie login et mp
2- requte d'interrogation la BD
3- vrification de l'existence
alt
chec
login ou mot de passe erron
succs
renvoi d'un objet null
renvoi d'un objet UserApp
Vrification des modules autoriss

Affichage de l'application
Figure 36 : diagramme de squence du cas "authentification"
Lorsque lutilisateur demande laccs lapplication, il doit tout dabord sidentifier par son
login et mot de passe via le serveur dapplication qui prend en charge de vrifier et consulter
39

la base de donnes.
Sil est accept, donc il yaura laccs au systme et aux applications du menu correspondant.
Sinon, le serveur dapplication lui affiche un message derreur afin de rectifier ses donnes.
2.1.4.2
Diagramme de squence du cas Grer les utilisateurs et les droits
d'accs
diagramme de squence gestion des utilisateurs et droit d'accs
Base de donne
administrateur
ListeUser
:Securite_Utilisateur
CompteServiceImpl
saisie de formulaire
crer l'objet securite utilisateur
saveUser
excution SQL
nbr_row_affected
alt
nbr row affected >0
nbr row affected
enregistrement ok
else
echec
Figure 37 : diagramme de squence du cas " Grer les utilisateurs et les droits d'accs"
Lorsque lutilisateur accde lapplication, il peut :

Dune part Saisir les donnes concernant le nouvel utilisateur puis demander lenregistrement
via le serveur dapplication qui prend en charge la vrification du type des donnes et
linsertion dans la base de donnes. Si l'insertion est ralise avec succs un message informe
l'utilisateur que l'enregistrement est ralis avec succs. Si non un message d'erreur sera
affich.
Dautre part consulter la liste des utilisateurs.
40

L'administrateur demande la liste des utilisateurs. Une requte sera passe la base de
donnes puis la classe CompteServiceImpl prpare une liste des objets utilisateurs qui sera
charg par le composant GridUser de la classe ListeUser.
Une fois la lise est affiche, l'utilisateur peut slectionne un utilisateur pour le modifier ou le
supprimer.
La modification gnre la boite de dialogue NewUser avec l'utilisateur slectionn en
paramtre pour lister les informations de l'user slectionn. Une fois les modifications sont
effectues, l'objet utilisateur modifi sera pass pour excuter la requte SQL correspondante
la BD.
De mme pour la suppression.
consulter la liste des utilisateurs
Base de donne
administrateur
ListeUser
newUser
List<Securite_Utilisateur>
demander liste des utilisateurs
:Securite_Utilisateur CompteServiceImpl
getUserApps
Excution SQL
Affichage de la liste
Cration de la liste des utilisateur
slection
modifier user
user
cration de l'objet slectionn
objet slectionn
modifier user
create
modification
create
ModifUser
alt
nbr row affected > 0

Enregistrement ok
nbr row affected
else
excution SQL
nbr row affected
Echec modif
suppression
create
deleteUser
excution SQL
nbr row affected
alt
nbr row affected>0

delete ok
nbr row affected
nbr row affected <=0

echec suppression
Figure 384 : diagramme de squence du cas " Grer les utilisateurs et les droits d'accs "
41
2.1.4.3
Diagramme de squence du cas grer Les comptes mail
gestion des comptes
Base de donne
Acteur mail
ListeAbonneSansCompte
:Abonne
demande de liste d'abonns
NewCompte
:Compte
CompteServiceImpl
getAbonnes
excution SQL
Cration de la liste des abonnes
Affichage
List<Abonne>
slection abonn
cration objet slectionn

objet slectionn
gnrer compte
create
saveCompte
excution SQL
create
compte cr
opt
nbr-row-affected
[nbr-row-affected >0]
Figure 395 : Diagramme de squence du cas grer les comptes
L'utilisateur demande la liste des abonns sans comptes (abonns nouvellement crs) .Une
fois affich, il peut slectionner un abonn pour le modifier, le supprim ou gnrer le compte
correspondant.
Afin dliminer la redondance, le diagramme illustre le cas de gnration de compte
seulement.
Lorsque l'abonn est slectionn, un objet Abonne sera cr et pass en paramtre l'objet
dialogue NewCompte que l'utilisateur utilise pour gnrer les comptes mail et Internet avec
mot de passe alatoire .L'utilisateur enregistre le compte en passant l'objet Compte
nouvellement cre la classe Contrleur CompteServiceImp qui dialogue avec la base de
donnes.
La recherche de compte est effectue ainsi :
Lutilisateur peut effectuer la recherche de comptes soit par tablissement soit travers le
compte lui-mme.
42

Lutilisateur choisi le type dtablissement puis le gouvernorat puis recherche ltablissement
voulu. Le systme lui affiche les comptes de cet tablissement.
Lutilisateur peut aussi rechercher un compte en tapant le nCIN ou une partie de nom et
lance la recherche. Le systme lui retourne alors le compte recherch.
Ensuite, lutilisateur peut slectionner un compte pour le modifier, le supprimer ou
l'imprimer.
recherche_compte
Base de donne
Acteur mail
alt
SearchCompte
InfoCompte
TypeEtab
Gouv
Etab
Compte
CompteServiceImplprintPDF
printWord
recherche par tablissement

slection typeEtab
create
objet slectionn
slection Gouv
create
objet slectionn
Affiche etab
Excution SQL
Affichage
slection Etab
getEtabByTypeAndGouv
Create liste Etab
create
Etab choisi
Affiche Comptes
getComptesByEtab
Excution SQL
Comptes de l'tablissement choisi
Cration liste des comptes
recherche par nom
saisie de text
getAllCompteByNom
Excution SQL
Affichage
create liste de comptes
slection compte
consulter Compte
create
objet slectionn
gnrer PDF
jasperReport
affichage PDF
PDF report
jasperReport
gnrer word
word report
imprimer
affichage Word
Figure 16 : Diagramme de squence du cas grer les comptes
2.1.4.4
Diagramme de squence du cas "Grer les serveurs Slis"
Lutilisateur affiche le tree des tablissements. Il commence par slectionner le

gouvernorat, puis le type dtablissement puis slectionne ltablissement voulu.
Sil trouve un Slis dj enregistr dans cet tablissement il peut alors consulter les
logs ou ajouter les comptes Internet.
43
Sinon, il ajoute un Slis par le dialogue New Slis.

grer les serveurs Slis
Base de donne
Acteur Slis
ManageEtab
NewSlis
ListCompteToAdd
demander le tree des tablissements
ListLogs
Entite
Slis
CompteServiceImpl
getTreeEtab
SlisServiceImpl
excution SQL
create liste des gouvs
Affichage gouvs
BD Slis Distant
List<Entite>
selection gouv et recherche
excution SQL
getTreeEtab( gouv )
Affichage type Etabs
create liste des types Etablissements
List<Entite>
slection type et recherche
excution SQL
getTreeEtab( type,gouv)
create liste des Etablissements
List<Entite>
slection etab et recherche
getTreeEtab(type,gouv,etab)
excution SQL
List<Entite>
Affichage
alt
create liste des comptes, Slis and router
pas de Slis
saisie
create
saveSlis(Slis entite)
select etab and create Slis
create
raifraichissement et Affichage
insertion Sql
List<Entite>
create liste Slis and router
Slis existe
select Slis and consulte Logs
create
getLogsEtab(@ ip Slis)
Affichage
select Slis & add compte Internet
create
connection and excution SQL
Create Liste logs
create Liste Entite

saveComptesInternet(List<Compte>, @ipSlis)
select compte to add
insertion SQL
Rsultat (echec ou sccs)
Figure 17 : Diagramme de squence du cas grer les serveurs Slis
A noter que lutilisateur selon son profil peut slectionner un nud de tree le supprimer ou le
modifier.
Ces actions ne sont pas traites dans le diagramme de squence pour allger le diagramme.
Conclusion
Dans ce chapitre, nous avons conu et document le code que nous devons produire. Dans
cette phase, toutes les questions concernant la manire de raliser le systme dvelopper ont
t lucides. Le produit obtenu est un modle graphique (ensemble de diagrammes) prt
tre cod. Dans le chapitre suivant nous allons tudier en dtails les outils et les langages
utiliss durant la phase de construction.
44
Chapitre 5 : Ralisation
45
Introduction
Aprs avoir achev ltape de conception de lapplication, on va entamer dans ce
chapitre la partie ralisation et implmentation dans laquelle on sassure que le
systme est prt pour tre exploit par les utilisateurs finaux.
A la fin de ce chapitre, les objectifs doivent avoir t atteints et le projet doit tre clos.
Environnement de dveloppement
Pour la ralisation de ce travail, nous avons eu recours aux environnements suivants:
1.1
Environnement Matriel
Pour dvelopper lapplication, nous avons utilis comme environnement matriel deux
ordinateurs FUJUTSU SIEMENS qui possdent comme caractristiques :
1.2
1.3
Un processeur Intel Pentium Core2 Duo, 2.49 GHz.
Une mmoire vive de 2Go.
Un disque dur 250 Go.
Un cran 17 pouces.
Environnement Logiciel
Windows 7 Professionnel, Service Pack 1 comme Systme dexploitation.
PostgreSQL 9 comme systme de gestion de base de donnes relationnel.
Gxt comme framework de dveloppement d'application Internet.
NetBeans 6.9 comme Environnement de dveloppement intgr.
Tomcat 6.0.20 comme Moteur de servlet.
Sybase Power Designer outils de modlisation
Choix des outils de dveloppement
Nous avons dj les dcrit dans le chapitre 2 Etude de lart.
46
Architecture gnrale de l'application
Dans ce paragraphe, on va dtailler l'architecture MVC du framework Gxt et son impact dans
le dveloppement de l'application. On finira par donner le diagramme de classe finale adapt
au langage de dveloppement choisi J2EE + GWT+GXT.
2.1
Architecture client-serveur GWT:
On commence par prsenter le principe de dveloppement de la boite outil GWT sur

laquelle repose le framework GXT.
Le dveloppement GWT couvre deux niveaux:
le dveloppement cot Client : on dveloppe en Java comme si on est en train de
dvelopper avec Swing. A la phase de compilation tous ce code Java sera converti en
Java Script en tenant compte des diffrences des browsers. Cette compilation est
totalement transparente l'utilisateur. Elle est ralise par le fameux compilateur de
Google.
dveloppement cot serveur: il repose sur le concept Ajax (JavaScript Et XML
Asynchrones)
Le principe client/serveur de GWT repose sur la cration de :
Deux interfaces : une synchrone et une asynchrone.

Une classe qui implmente 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
quil faut galement gnrer ce quon appelle des stubs : il sagit de morceau de code qui
assure la communication entre un client et un serveur.
Il faut galement noter que seule linterface asynchrone peut tre utilise. Lappel au service
ne sera pas bloquant pour le code. Si pour la suite du traitement on a besoin du rsultat du
traitement ralis sur le serveur il faudra utiliser une callback.
47
Figure 408 : Architecture client-serveur de l'application
2.2
Le modle MVC de GXT :
Le Modle-Vue-Contrleur (en abrg MVC, de l'anglaisModel-View-Controller) est une

architecture et une mthode de conception qui organise l'interface homme-machine (IHM)
d'une application logicielle. Ce paradigme divise l'IHM en un modle (modle de donnes),
une vue (prsentation, interface utilisateur) et un contrleur (logique de contrle, gestion des
vnements, synchronisation), chacun ayant un rle prcis dans l'interface.
Les composants de Gxt reposent sur le modle MVC. De plus Gxt offre une implmentation
du modle MVC qui consiste :
48
Crer une Classe AppEvents contenant les vnements de l'application voulus
Figure 419 : Liste des vnements de lapplication
Crer une classe Controller et une classe Vue pour capter l'vnement et effectuer le
ncessaire
Figure 20 : Liste des vnements de lapplication
Dclarer le contrleur auprs de contrleur principal Dispatcher fourni par GXT
Figure 21 : Le contrleur principal (Dispatcher)
Le dispatcher lance un vnement application (list dans /client/AppEvents.java)

tous les contrleurs. Si le contrleur peut rpondre cet vnement particulier, il le
49

fait. S'il n'est pas concern il ne fait rien. Lecontrleurdoit accomplir l'excution du
logique mtier ainsi que les MAJ des modles. Les vues connectes ces contrleurs
seront rafraichies en accord avec le model mis jour correspondant.
Diagramme de classe final
Daprs l'architecture client-serveur prsente et le modle 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 donnes et les entits beans utilis par l'application pour le transfert de
donne depuis le serveur vers l'application.
Figure 22 : Les Beans
Ainsi, le diagramme de classe final sera compos du diagramme prcdent auquel on ajoute
la classe CompteServiceImpl et SlisServiceImpl contenant toutes les mthodes d'ajout,
suppression, modification et consultation des Entit de la base de donnes.
On ajoute aussi toutes les classes responsables de l'interface graphique de l'application.
Principales interfaces graphiques
La conception des interfaces de lapplication est une tape trs importante puisque toutes les
interactions avec le cur de lapplication passent travers ces interfaces, on doit alors guider
lutilisateur avec les messages derreurs et de notification si besoin, ainsi prsenter un systme
complet.
Dans cette partie, nous allons prsenter quelques interfaces de lapplication, rpondant aux
recommandations ergonomiques de compatibilit, de guidage, de clart, dhomognit et de
souplesse. Nous avons choisi ladministrateur comme utilisateur vu quil prsente travers
ces interactions la majeure partie des principales fonctionnalits de lapplication.
50
5.1
Authentification
Figure 2342 : Interface d'authentification
Cette interface permet lutilisateur de sauthentifier et de se connecter au serveur de la base

de donnes. Lutilisateur doit entrer son login et son mot de passe pour accder
lapplication. En cas derreur un message dalerte saffiche :
Figure 2443 : Message d'erreur
5.2
5.2.1 Ajouter un utilisateur
Figure 25 : Interface principale
51

La figure ci-dessus prsente le menu principal, ladministrateur peut ajouter un utilisateur en
cliquant sur bouton ajout User
; un formulaire comportant plusieurs champs
saffiche pour lentre des donnes. Lapplication gre le contrle de saisie ainsi que la
sauvegarde dans les bases des donnes.
Figure 26 : Ajout utilisateur
5.2.2 Consulter les utilisateurs

Le bouton Consulter permet de voir la liste des utilisateurs et leur droit d'accs. On peut
slectionner un utilisateur pour le modifier ou le supprimer.
Figure 2744 : information sur les utilisateurs
52
5.2.3 Les traces utilisateurs

La trace des utilisateurs donne toutes les actions ralises par lutilisateur ainsi que les erreurs
dtectes lors de lexcution de lapplication. Pour ce faire on a recourt la librairie Log4j et
son plugin JDBCAppender qui enregistre directement la base de donnes tous les messages
dinfo et derreurs.
Figure 2845 : Trace des utilisateurs
53
5.3
Gestion des comptes Mail

5. 3.1
Lajout dun abonn
Aprs la clique sur le bouton Abonn + un formulaire de saisie saffiche permettant

lutilisateur dentrer les informations dabonn.
Figure 2946 : Ajout dun abonn
Un contle sur les champs est ncessaire pour garantir lintgrit des donnes.
Si lenregistrement russi un autre formulaire saffiche lutilisateur gnrant le compte Mail
en concatnant le nom et le prnom au domaine adquat selon ltablissemnt de labonn.
Figure 30 : formulaire de gnration de compte
Si lutilisateur quitte cette fentre sans enregistrer le compte, labonn reste la base de
donnes sans compte.
54

Pour gnrer le compte ; lutilisateur slectionne le bouton recherche Abonn sans compte.
5.3.2 La recherche dun compte et limpression

Lutilisateur slectionne le bouton recherche Abonn comptes raliss, un nouvel onglet :
Figure 3147 : recherche de compte par ltablissement
En choisissant le bouton Impression cette page saffiche :
55
Figure 32 : Impression de compte
La gnration de fichier PDF et Word est ralise travers la bibliothque JasperReport.
56
5.3.3 Les tats dun compte :

Le compte cre prcdemment est en tat dattente de cration. Il ne sera exploitable quaprs
son validation par le responsable Mail.
Figure 33 : Etats des comptes
La validation des modifications effectues un compte est ncessaire pour sassurer que ces
modifications seront rpliques sur le serveur LDAP du serveur Mail de lINBMI.
Dailleurs, le responsable Mail possde le bouton de gnration CSV travers lequel il gnre
un fichier CSV utilis par le serveur LDAP.
Lorsquon slectionne le bouton En attente de cration 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 quon 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 propritaire.
57
5.4
Gestion des serveurs Slis
On commence par recherche ltablissement. Laffichage avec larbre des gouvernorats nous
facilite la recherche.
Figure 35 : ajout dun serveur Slis
Comme dans la figure ce collge ne possde pas dun serveur Slis enregistr alors que les
comptes y existent. Un cli droit puis add Slis nous affiche cette boite de dialogue :
Figure 36 : Ajout dun Slis
58

Comme dj dit ltude de lexistant quun fichier Excel contient la liste des routeurs et
serveurs Slis, ce fichier a t import la base de donnes dans une table nomme slis ADSL.
Le problme rside dans limpossibilit de joindre cette table avec celle des tablissements.
Cest pour cette raison lutilisateur choisit dans la comboBox ltablissement correspondant
de la table slisAdsl et tous les informations relatives seront affiches dans le formulaire.
Si ltablissement nexiste pas dans la table slisADSL, on clique sur le bouton New et on
lajoute
carrment.
Figure 37 : Actions sur Slis
La consultation de logs et lajout de comptes Internet directement Slis ncessite une

connexion distante la base de donnes Postgres de Slis.
Sachant que le ficher pg-hba.conf qui dfinit les htes autoriss accder la BD ncessite
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 manire automatique et transparente
lutilisateur de lapplication.
Heureusement, il existe une librairie nomme Ganymede-ssh2 qui facilite les connexions ssh
travers le langage Java. Ce qui nous a permis denvoyer les commandes sed pour modifier le
fichier pg-hba.conf et la commande iptable avant deffectuer la connexion la base postgres
de Slis.
Conclusion
A travers ce chapitre, nous avons prsent la ralisation de lapplication en justifiant nos
choix technologiques, en reprsentant quelques interfaces graphiques que nous avons jug les
plus importantes et en dcrivant brivement comment nous avons planifi notre projet.
59
Conclusion gnral
Lobjectif de notre projet de fin dtude tait de concevoir et implmenter une application de
gestion des comptes mails et Internet des intervenants du ministre dducation.
Le point de dpart de la ralisation de ce projet tait une rcolte des informations ncessaires
pour dresser un tat de lexistant, prsenter un aperu sur la problmatique ainsi que
larchitecture utiliser au sein des rseaux des tablissements.
Par la suite, nous nous sommes intresss lanalyse et la spcification des besoins qui nous a
permis de distinguer les diffrents acteurs interagissant avec lapplication vise.
Lobjectif de la partie suivante tait la conception dtaille, dans laquelle nous avons fix la
structure globale de lapplication.
Le dernier volet de notre projet tait la partie ralisation qui a t consacre la prsentation
des outils du travail et les interfaces les plus significatives de notre application.
Lapport de ce travail a t dune importance trs considrable, en effet, il nous a permis : de
suivre une mthodologie de travail bien tudi, dapprofondir nos connaissances dans le
monde de dveloppement des applications et de nous bien nous exercer sur le Framework
GWT et Ext.
La ralisation dun tel projet, nous a permis dapprendre et de toucher du doigt une partie de
divers aspects du mtier de dveloppeur et de celui du concepteur.
60
Annexe A : UML
Figure 38: Les diffrentes vues du langage UML
Diagramme de cas dutilisation
Figure 39: Les cas dutilisation
Montre les interactions fonctionnelles entre les acteurs et le systme ltude

Acteur : rle jou par un utilisateur humain ou un autre systme qui interagit directement
avec le systme tudi. Un acteur participe au moins un cas dutilisation.
Cas dutilisation (use case) : ensemble de squences dactions ralises par le systme
produisant un rsultat observable intressant pour un acteur particulier. Collection de
scnarios relis par un objectif utilisateur commun.
61

Association : utilise dans ce type de diagramme pour relier les acteurs et les cas dutilisation
par une relation qui signifie simplement participe .
Inclusion : le cas dutilisation de base en incorpore explicitement un autre, de faon
obligatoire, un endroit spcifi dans ses enchanements.
Extension : le cas dutilisation de base en incorpore implicitement un autre, de faon
optionnelle, un endroit spcifi indirectement dans celui qui procde lextension
Gnralisation : les cas dutilisation descendants hritent de la description de leur parent
commun. Chacun dentre eux peut nanmoins comprendre des relations spcifiques
supplmentaires avec dautres acteurs ou cas dutilisation.
Diagramme de squence
Montre la squence verticale des messages passs entre objets au sein dune interaction
Figure 40: Les diagrammes de squence
Ligne de vie : reprsentation de lexistence dun lment participant dans un diagramme de

squence. Cela peut tre un acteur ou le systme en modlisation dexigences, des objets
logiciels en conception prliminaire ou conception dtaille.
Message : lment de communication unidirectionnel entre objets qui dclenche une activit
dans lobjet destinataire. La rception dun message provoque un vnement dans lobjet
rcepteur.
La flche pointille reprsente un retour au sens UML. Cela signifie que le message en
question est le rsultat direct du message prcdent.
Spcification dactivation : bande blanche qui reprsente une priode dactivit sur une ligne
de vie.
Message synchrone : envoi de message pour lequel lmetteur se bloque en attente du retour
et qui est reprsent par une flche pleine.
Un message asynchrone, au contraire, est reprsent par une flche ouverte.
Occurrence dinteraction : une interaction peut faire rfrence explicitement une autre
interaction grce un cadre avec le mot-cl ref et indiquant le nom de lautre interaction.
UML 2 a ajout une nouvelle notation trs utile : les cadres dinteraction.
Chaque cadre possde un oprateur et peut tre divis en fragments.
62

Les principaux oprateurs sont :
loop : boucle. Le fragment peut sexcuter plusieurs fois, et la condition
de garde explicite litration.
opt : optionnel. Le fragment ne sexcute que si la condition fournie est vraie.
alt : fragments alternatifs. Seul le fragment possdant la condition vraie sexcutera.
Diagramme de classes
Montre les briques de base statiques : classes, associations, interfaces, attributs, oprations,
gnralisations, etc.
Classe: description abstraite dun ensemble dobjets qui partagent les mmes proprits (attributs et
associations) et comportements (oprations et tats).
Attribut : donne dclare au niveau dune classe, ventuellement type, laquelle chacun des objets
de cette classe donne une valeur. Un attribut peut possder une multiplicit et une valeur initiale.
Un attribut driv ( / ) est un attribut dont la valeur peut tre dduite dautres informations
disponibles dans le modle.
Opration : lment de comportement des objets, dfini de manire globale dans leur classe. Une
opration peut dclarer des paramtres (eux-mmes typs) ainsi quun type de retour.
Figure 41: Les associations entre classes
Association : relation smantique durable entre deux classes, qui dcrit un ensemble de liens entre
instances. Une association est bidirectionnelle par dfaut, sauf si lon restreint sa navigabilit en
ajoutant une flche.
Rle : nom donn une extrmit dune association ; par extension, manire dont les instances dune
classe voient les instances dune autre classe au travers dune association.
Multiplicit : le nombre dobjets (min..max) qui peuvent participer une relation avec un autre objet
dans le cadre dune association. Multiplicits frquentes :
0..1 = optionnel (mais pas multiple)
1 = exactement 1
0..* = * = quelconque
1..* = au moins 1
63
Annexe B : GWT
Loutil GWT se dcompose en deux grandes briques :
Le framework de composants.
Le compilateur Java vers JavaScript :
Toute lingniosit de GWT est davoir su construire un compilateur Java vers JavaScript.
Un compilateur intelligent capable doptimiser et de gnrer du code tout en respectant les
prceptes de base du Web. Toute cette face cache de GWT est encore trs mconnue du
grand public, qui, aprs tout, na pas se soucier des implmentations internes du
compilateur. Et pourtant, les vraies ppites, la vraie beaut de ce framework rside dans cette
partie passionnante de GWT. Pour celui qui sait dcrypter un minimum les nombreuses
subtilits et configurations du compilateur, chaque fonctionnalit est une source dinspiration
unique.
Figure42: Le compilateur GWT
Le compilateur GWT est en perptuelle volution car la taille du framework ne cesse

daugmenter (il suffit dobserver le nombre de nouvelles API). Les utilisateurs nont de cesse
64

de rclamer des applications ractives avec des temps de chargement instantans ; impossible
dans ce contexte de sassoir sur ses lauriers. Plus quune ncessit, lamlioration du
JavaScript gnr 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 gnrs et les diffrentes optimisations. Un clairage particulier est apport au
mcanisme permettant dtendre le processus de gnration pour y ajouter des traitements
spcifiques.
1) Introduction au compilateur
Le compilateur de GWT est lessence mme du framework. Lorsquon sait la richesse des
sept mille classes du JDK, on ralise que celui qui ose imaginer un jour que ce langage peut
produire du code JavaScript a du gnie.
Mme sil est vrai quil existe des similitudes entre Java et JavaScript, certaines subtilits
peuvent poser problme. Java propose des classes, JavaScript des prototypes de mthodes.
Java dispose dun mcanisme despaces de nommage (les fameux packages), JavaScript non.
Java permet deffectuer 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 russit marier ces deux langages sans briser aucun moment
leur smantique respective.
Pour le compiler en JavaScript, nous utilisons le script Ant gnr par GWT lors de la
cration du squelette projet. Ce script contient une tche gwtc laquelle nous ajoutons les
options de compilation suivante draftCompile et style PRETTY. La premire demande au
compilateur de ne pas trop optimiser le script cible. En production, cette option est proscrire,
car elle a tendance gnrer un gros fichier.
En revanche, pour des raisons pdagogiques, cela permet dobtenir une version fidle du
JavaScript avant optimisation.
La seconde option demande GWT dafficher un fichier source JavaScript lisible non
obfusqu. Cela permet de mieux comprendre le contenu du script.
2) Les tapes du compilateur
Nous allons ici dtailler les diffrentes tapes menant la gnration des artfacts lors de la
compilation dun programme GWT. Lide est ici de bien comprendre le processus
doptimisation et le modle interne au compilateur.
GWT a besoin du code source Java.
Il y a un dbat rcurrent au sein des contributeurs GWT qui est celui du modle de
compilation. lorigine, le choix a t de sappuyer sur le code source Java pour gnrer le
JavaScript plutt que rutiliser le bte code. Nous ne discuterons pas ici de la pertinence de
65

cette dcision. Il faut simplement savoir que GWT a besoin du code source car il extrait
certaines informations telles que le code JSNI. Une autre raison avance par les crateurs de
GWT est la possibilit doptimiser partir dinformations prsentes uniquement dans le code
source. Si on prend, par exemple, les types gnriques (Class<T>), ceux-ci sont rcrits par le
compilateur.
Citons maintenant les diffrentes tapes intervenant lors de la compilation :
Lecture des informations de configuration
Cration de larbre syntaxique GWT
La gnration de code JavaScript et les optimisations
La rduction de code (pruning)
La finalisation de mthodes et de classes
La substitution par appels statiques
La rduction de type
Llimination de code mort
Figure 4348: Structure de larbre AST GWT

3) Acclration des temps de compilation
Vu la complexit des optimisations et le mode de fonctionnement du compilateur, ce nest pas

une surprise si lune des proccupations majeures des dveloppeurs GWT concernent les
temps de compilation. Avec GWT 2 et la possibilit de tester le code partir dun vrai
navigateur, cette contrainte ne devrait plus rellement constituer un facteur de blocage. En
effet, dans cette version, la compilation relle nintervient que pour valider dfinitivement le
rendu visuel dune application.
Malgr tout, il existe plusieurs optimisations possibles, dont certaines ont t abordes dans le
chapitre sur la liaison diffre.
66

Voici une liste dactions susceptibles de rduire en moyenne de 50 % le temps de
compilation, voire 800 % dans certains cas :
Rduire le nombre de permutations : GWT est paramtr par dfaut pour gnrer
6 permutations (une par navigateur). Si on sait que seuls IE 7 et Firefox 3seront supports,
il suffit de dfinir la proprit user.agent de la manire suivante dans le fichier de
configuration du module : <set-propertyname="user.agent" value="ie6, gecko" />
Ce paramtrage rduit en moyenne de 50 % les temps de compilation.
Ajouter loption draftCompile lors de la compilation : en phase de dveloppement les

gains peuvent aller de 5 30 % en fonction des scnarios.
Donner une valeur largument localWorkers : GWT 1.5 a introduit la notion de

worker pour la compilation. Pour une machine bi-cur (Dual Core), une valeur
paramtre 2 permet de parallliser la compilation des permutations sur chaque
cur. Le gain est en moyenne de 10 %. Ce chiffre samliore progressivement dans le
cas dune machine 4 curs (Quad Core).
Configurer la JVM avec des paramtres adapts : pour une application moyenne, les
options suivantes permettent dassurer suffisamment de mmoire, une taille de pile
cohrente et un espace de stockage temporaire adapt.
4) Le framework RPC
On dveloppe seulement 3 classes pour les appels distants en utilisant le RPC (remote
procedure calls).
Figure44: Vue gnrale du service RPC
Toute communication avec la couche serveur sopre via le protocole RPC :

Le service sappuie sur lAPI JEE Servlet.
67

Les appels sont asynchrones (classe AsyncCallback).
Le code serveur nest pas converti en JavaScript (Possibilit dutiliser le JDK 1.5 et
toutes les classes du Framework Java).
Les types sont srialiss automatiquement par GWT suivant un format spcifique RPC
5) Les raisons dinvestir dans GWT
En fin nous prsentons nos raisons pour utiliser le GWT :
Marge de progression : Le GWT prsente une marge de progression considrable par

rapport aux autres Framework de mme catgorie.
Productivit
Richesse fonctionnelle (AJAX)
Prennisation des comptences (JAVA)
Extensibilit
Intgration avec lexistant
Standards ouverts (XML, JSON, J2EE)
Open Source
Simplicit.
68
Bibliographie :
[1] Grant SlenderDevelopingwith Ext Gwt 140 pages.
[2] John C. Worsley & Joshua D. Drake PostgreSQL par la pratique628 pages.
[3] Pascale Roques & Franck Valle UML en action, 2me dition402 pages.
Netographie :
[1] http://www.extjs.com
[2] http://fr.wikipedia.org
[3] http://inbmi.edunet.tn
[4] http://code.google.com/intl/fr-FR/webtoolkit/
[5] http://uml.free.fr/
69

Conception Et Réalisation D'une Application de Gestion Des Comptes Mail Et Internet PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Réalisation D'une Application de Gestion Des Comptes Mail Et Internet PDF

Transféré par

Droits d'auteur :

Formats disponibles

Conception et ralisation

dune application de gestion

UNIVERSITE VIRTUELLE DE TUNIS

Licence Appliques en Sciences et Techniques de l'Information et de

Organisme daccueil :INBMI

Encadr par : Awatef Mejri

Anne universitaire 2010-2011

Conception et ralisation dune application de gestion des comptes mail et internet

Conception et ralisation dune application de gestion des comptes mail et internet

Jadresse ma profonde reconnaissance au responsable du service messagerie

Je voudrais exprimer, galement, mes vifs gratitudes et remerciements mes

Enfin, ma profonde reconnaissance au directeur gnral de l INBMI Mr

Conception et ralisation dune application de gestion des comptes mail et internet

Prsentation du projet ...................................................................................................9

Prsentation de l'organisme d'accueil............................................................................9

Le rle de lINBMI en tant que FSI .....................................................................................9

Architecture des rseaux des tablissements ..................................................................10

Architecture de base : les serveurs SLIS ...........................................................................11

Emplacement dans le rseau ...........................................................................................12

Chapitre 2 : Etat de lart .......................................................................................................14

Critiques de lexistant ...................................................................................................15

Prsentation du travail demand .................................................................................16

Model et mthodologie adopts ..................................................................................16

Choix des outils de dveloppement .............................................................................17

Chapitre 3 : Analyse des besoins et spcification .................................................................20

Analyse des besoins .....................................................................................................21

Les besoins fonctionnels........................................................................................................... 21

Les diagrammes des cas dutilisation ...........................................................................22

Identification des acteurs ................................................................................................22

Les diffrents cas dutilisation .........................................................................................23

Les besoins attendus de lapplication ..............................................................................21

Cas dutilisation prliminaire .................................................................................................... 23

Conception et ralisation dune application de gestion des comptes mail et internet

Architecture de lapplication ........................................................................................33

Prsentation de l'architecture 2 niveaux ......................................................................33

Prsentation de l'architecture 3 niveaux ......................................................................34

Architecture adopte ......................................................................................................35

Conception dtailles ...................................................................................................35

Vue statique ....................................................................................................................36

Diagramme de dploiement ..................................................................................................... 38

Vue dynamique : Diagramme de squence .....................................................................39

Chapitre 5 : Ralisation ........................................................................................................45

Environnement de dveloppement ..............................................................................46

Environnement Matriel .................................................................................................46

Environnement Logiciel ...................................................................................................46

Choix des outils de dveloppement.................................................................................46

Architecture gnrale de l'application .........................................................................47

Diagramme de classe final ...........................................................................................50

Principales interfaces graphiques ................................................................................50

Ajouter un utilisateur ............................................................................................................... 51

Gestion des comptes Mail ...............................................................................................54

5. 3.1 Lajout dun abonn ................................................................................................................. 54

Annexe A : UML ...................................................................................................................61

Conception et ralisation dune application de gestion des comptes mail et internet

Liste des figures

Conception et ralisation dune application de gestion des comptes mail et internet

Conception et ralisation dune application de gestion des comptes mail et internet

Conception et ralisation dune application de gestion des comptes mail et internet

Conception et ralisation dune application de gestion des comptes mail et internet

Le Rseau Educatif Tunisien connecte aujourd'hui l'ensemble des tablissements ducatifs

Prsentation de l'organisme d'accueil

L'Institut Nationale de Bureautique et de Micro-informatique

fournisseur de service Internet pour le domaine de l'ducation et de la formation, contribue au