Vous êtes sur la page 1sur 51

Table des matieres

1 Presentation Generale 3
1.1 Organisme d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Presentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Etat de l'art 5

2.1 Les ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5


2.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 De nition d'un ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Pour quoi les ERP ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Les principaux editeurs des ERP . . . . . . . . . . . . . . . . . . . . . . . 7
3 Analyse et speci cation des besoins 8

3.1 Identi cation des Utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8


3.2 Les Exigences Speci ques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Les exigences non speci ques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Les cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 Les diagrammes de sequences . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Solutions techniques possibles et choix retenus 18

4.1 Solutions techniques possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


4.1.1 Technologie de developpement . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Environnement de developpement . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3 Gestion de la base de donnees . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Choix retenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Conception 25

5.1 Conception generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


5.1.1 La comptabilite analytique : . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.2 La gestion de la base de connaissances : . . . . . . . . . . . . . . . . . . . 25
5.2 Conception detaillee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 Architecture de l'application . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 Diagrammes de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3 Diagrammes de sequences detailles . . . . . . . . . . . . . . . . . . . . . . 28
5.2.4 Conception de la base de donnees . . . . . . . . . . . . . . . . . . . . . . . 31

i
6 Realisation 33
6.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Travail realis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1 Page d'authenti cation des utilisateurs . . . . . . . . . . . . . . . . . . . . 34
6.2.2 Page d'ajout d'un document EXCEL . . . . . . . . . . . . . . . . . . . . . 35
6.2.3 Page de validation d'un documents EXCEL . . . . . . . . . . . . . . . . . 35
6.2.4 Recherche de ches de procedures . . . . . . . . . . . . . . . . . . . . . . 36
6.2.5 Resultats de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.6 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.7 Ajout de nouveaux utilisateurs ou administrateurs . . . . . . . . . . . . . 37
6.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Netographie 41

A Annexe 43

ii
Table des gures

1.1 Feuille d'a ectation de temps passes . . . . . . . . . . . . . . . . . . . . . . . . . 4


3.1 Cas d'utilisation du directeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Cas d'utilisation du comptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


3.3 Cas d'utilisation de l'ingenieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Cas d'utilisation du consultant simlpe . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Cas d'utilisation de l'assistant de service . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Cas d'utilisation du responsable de departement . . . . . . . . . . . . . . . . . . 15
3.7 Ajout d'un chier EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 Recherche de procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Architecture de Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22


5.1 Architecture de l'application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Diagramme de classes de l'application . . . . . . . . . . . . . . . . . . . . . . . . 27


5.3 Ajout d'un chier EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Consultation des statistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Recherche de procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6 Conception de la base de donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1 Identi cation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 Ajout d'un chier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


6.3 Validation du document EXCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Recherche de che de procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.5 Resultats de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.6 Consultation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.7 Ajout de nouveaux utilisateurs ou administrateur . . . . . . . . . . . . . . . . . . 37
6.8 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1 Architecture Simple Tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.2 Architecture Deux Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


A.3 Architecture Trois Tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.4 Servlet etendant la classe javax.servlet.http.HttpServlet . . . . . . . . . . . . . . 45
A.5 Les pages JSP dans une application J2EE. . . . . . . . . . . . . . . . . . . . . . . 46

iii
A.6 Le modele MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

iv
Introduction Generale

De nos jours, toute entreprise est pr^ete a investir des sommes considerables dans l'implanta-
tion des technologies logicielles a n d'ameliorer ses services, d'accro^tre son agilite et sa
exibilite, de reduire les co^uts, d'augmenter la production et de faire face aux de s du marche. En
e et, vu la croissance des activites au sein des entreprises, la t^ache de gerer e cacement toutes
ces fonctions s'avere de plus en plus complexe et di cile.

Pour surpasser ces di cultes, une entreprise doit utiliser des outils optimises et adaptes
fa-cilitant les t^aches et o rant des fonctionnalites riches et utiles. Parmi ces outils nous
trouvons les systemes integres de gestion tel que les ERP(Entrprise Ressources Planning).

Les ERP sont des outils de gestion et d'analyse permettant d'optimiser la di usion des in-
formations en interne, d'ameliorer les processus de gestion et d'automatiser les t^aches ce
qui augmente enormement la reactivit des entreprises et leurs agilites.

C'est dans ce contexte que s'integre notre stage d'immersion en entreprise qui a pour ob-
jectif de concevoir et de realiser un ERP permettant d'automatiser les di erentes besognes
de la societ NETCOM TUNISIE. Cet ERP doit automatiser les di erents processus de gestion
a savoir la gestion des ressources humaines, la gestion de la production, la gestion
commerciale et la gestion nanciere.

Le present rapport synthetise tout le travail que nous avons e ectu dans cette perspective.
il est organise en chapitres comme suit :
{ Le premier chapitre donne une presentation generale du projet : l'organisme d'accueil
ainsi que les objectifs a atteindre.
{ Dans le second chapitre, nous procedons a un expos de l'etat de l'art du domaine qui
nous concerne. Nous presentons dans un premier temps le systeme existant pour
devoiler ses defaillances et ses limites. Nous presentons egalement la solution que
nous proposons a n de palier aux limites du systeme actuel.
{ Le troisieme chapitre intitule"'Analyse et Speci cation des besoins"'presente les di
erents besoins fonctionnels et non fonctionnels auxquelles doit satisfaire l'application.
{ Les choix technologiques retenus pour la phase de developpement font l'objet du
quatrieme chapitre.
{ Dans le chapitre V nous presentons la conception generale et la conception detaillee du

1
systeme.
{ Le dernier chapitre decrit les t^aches accomplies en titre de realisation.

En n nous donnons une conclusion recapitulant le travail realis ainsi que des
perspectives futurs.

2
Chapitre 1

Presentation Generale

Introduction
Ce chapitre a pour objectif de situer notre projet dans son contexte generale a savoir
l'orga-nisme d'accueil et le sujet a traiter. Dans la premiere section nous donnons une breve
presentation de l'organisme d'accueil SATEC International. Dans la deuxieme section, nous
decrivons le sujet a traiter et les objectifs a atteindre.

1.1 Organisme d'accueil


Activites de SATEC

SATEC a ete creee en 1992 et a pu, durant 16 ans, consolider une bonne et solide
assise sur le marche tunisien en tant qu'integrateur reseaux et securit de reseaux,
independamment de tout constructeur. SATEC Tunisie, est devenue un precurseur et un
acteur majeur de l'integration reseau en Tunisie.

Quelques dates utiles

{ 1992 : Creation de SATEC Tunisie.


{ 1998 : SATEC Tunisie, meilleur support Nortel : proche Orient/ Afrique du Nord, Cisco
Partner.
{ 1998 : Realisation du projet de la tel compensation, ISO 9001 version 2000.
{ 2002 : Specialisation securit VPN,WiFi de Cisco Systems.
{ 2004 : Mise en service d'un centre de management de la securit .
{ 2005 : Services manages Q.o.S, securit .

1.2 Presentation du sujet


Dans le systeme actuel de la societ NETCOM, chaque service possede son propre
systeme d'information ce qui a donne lieu a plusieurs problemes dont les majeurs sont :
{ Pour collecter les informations necessaires au processus d'administration de l'entreprise, on
constate une lenteur causee par la dispersion de di erents systemes d'informations.

3
{ Toute mise a jour suvenue sur l'un des systemes d'informations n'est detectee par les autres
que par voie humaine, en consequence elle ne se fait pas en temps reel et risque de
transmettre des information erronees.
Les consequences desagreables d'une telle situation ont oblige l'entreprise a y mettre n.
Pour cela, la meilleur solution etait d'implementer un ERP multifonctions qui vise a
centraliser le systeme d'information et a automatiser ses activites tout en garantissant une
securit de haut niveau.

Fig. 1.1 { Feuille d'a ectation de temps passes

Notre mission consistait alors a concevoir et implementer cet ERP qui doit comporter les
quatre module suivants :

{ Module de gestion de ressources humaines


{ Module de gestion de la production
{ Module de gestion commerciale
{ Module de gestion nanciere

Notre mission a et ensuite reduite a la realisation de deux sous modules : implementation


du sous module d'analyse analytique et celui de la gestion de la base de connaissance. Et
cela vu, en premier lieu, l'envergure du projet initial et l'insu sance du temps consacre au
stage, et en second lieu l'urgence de realiser ces deux fonctionnalites pour le client.

Conclusion
Dans ce premier chapitre nous avons pu situer le projet dans son cadre general en
presentant l'organisme d'accueil et les buts de l'application. Dans le chapitre suivant, nous
allons proceder a une etude detaillee de l'existant pour degager ses limites.

4
Chapitre 2

Etat de l'art

Introduction
Avant d'entamer l'elaboration de notre application, nous avons juge primordial de presenter
les objectifs d'une telle application a partir des elements moteurs par lesquels elle est constituee.

2.1 Les ERP


2.1.1 Historique
Dans les annees 60 et 70, les premiers logiciels font leur apparition dans les entreprises. Il
s'agit essentiellement d'applications de comptabilite et egalement de MRP, pour la gestion des
approvisionnements. Ces logiciels speci ques ne sont pas " portables ", c'est a dire qu'ils
dependent du type d'ordinateur et du systeme d'exploitation. Dans les annees 80 se developpent
des progiciels qu'on personnalise, integrants la nance, la comptabilite, la paie et la gestion de
production assistee par ordinateur. La tendance a personnaliser et a modi er completement le
progiciel de base pour l'entreprise conduit le produit a ^etre obsolete au bout de 5 a 10 ans. Dans
ces annees apparaissent egalement les premiers MRP II, integrant la gestion de production et la
gestion des approvisionnements. La petite histoire raconte qu'a la n des annees 80, trois
employes d'IBM pressentent un marche important pour les progiciels integres, et fondent SAP.
Peu apres, SAP R/2 devient la premiere reference en matiere d'ERP, encore fondee sur une
structure informatique centralisee et une technologie mainframe.
En 1993, SAP R/3 realise l'integration totale de toutes les composantes d'une entreprise,
de la nance a la production, aux ventes et aux ressources humaines... Sa structure
informatique et sa portabilite complete seront une grande raison de son succes.
Les ERP sont maintenant presents dans l'industrie et dans la grande distribution,
essentiel-lement dans les tres grandes entreprises. Le marche des plus petites entreprises,
le domaine de la nance et le secteur public commencent a ^etre touches.
La conception et le developpement des ERP ont et rendus possibles par les evolutions
technologiques : vitesse de calcul, technologies de reseaux, systemes de gestion de bases
de donnees, stockage de donnees... se sont considerablement developpes et ameliores. De
plus, le succes des ERP a et favorise par la perte de credibilit des informaticiens dans les
entreprises a la n des annees 80 et au debut des annees 90.

5
2.1.2 De nition d'un ERP
L'acronyme ERP signi e " Enterprise Ressource Planning " traduit en francais par Progi-ciel
de Gestion Integr ou PGI. ERP est le terme le plus couramment utilise. Emanant d'un concepteur
unique, un ERP est un progiciel qui permet de gerer l'ensemble des processus d'une entreprise
integrant l'ensemble de ses fonctions comme la gestion des ressources humaines, la ges-tion
nanciere et comptable, l'aide a la decision, la vente, la distribution, l'approvisionnement, la
production ou encore du e-commerce. Le principe fondateur d'un ERP est de construire des ap-
plications informatiques correspondant aux diverses fonctions citees precedemment de maniere
modulaire sachant que ces modules sont independants entre eux, tout en partageant une base
de donnees unique et commune au sens logique. L'autre principe qui caracterise un ERP est
l'usage de ce qu'on appelle un moteur de workfow et qui permet, lorqu'une donnee est
enregistree dans le systeme d'information(SI), de la propager dans les modules qui en ont l'utilite,
selon une pro-grammation prede nie. Ainsi, on peut parler d'ERP lorsqu'on est en presence d'un
SI compose de plusieurs applications partageant une seule et m^eme base de donnes, par le
biais d'un systeme automatise prede ni et eventuellement parametrable, un moteur de workfow.

2.1.3 Pour quoi les ERP ?


Concretement, les avantages de la mise en place d'un ERP sont les suivants :
{ L'integrit et l'unicite du SI, c'est a dire qu'un ERP permet une logique et une ergonomie
unique a travers sa base de donnees, elle aussi unique au sens " logique ". Ceci se
traduit par le fait qu'il peut exister plusieurs bases de donnees " physiques " mais
celles-ci respectent la m^eme structure. En bref, un ERP permet d'eviter la redondance
d'information entre di erents SI de l'entreprise.
{ L'utilisateur a la possibilite de recuperer des donnees de maniere immediate, ou encore
de les enregistrer. Un avantage important, les mises a jour dans la base de donnees
sont e ectuees en temps reel et propagees au modules concernes.
{ Un ERP est un outil multilingue et multidevise, il est donc adapte au marche mondial, en
particulier aux multinationales.
{ Pas d'interface entre les modules, il y a synchronisation des traitements et optimisation
des processus de gestion. De m^eme, la maintenance corrective est simpli ee car
celle-ci est assuree directement par l'editeur et non plus par le service informatique de
l'entreprise. (Celui-ci garde neanmoins sous sa responsabilit la maintenance evolutive :
amelioration des fonctionnalites, evolution des regles de gestion, etc.).
{ Un ERP permet de ma^triser les stocks, element important pour la plupart des
entreprises car les stocks co^utent chers.

Par consequent, les ERP gerent et prennent en charge plusieurs periodes ( pour les exercices
comptables par exemple), plusieurs devises, plusieurs langues pour les utilisateurs et clients,
plusieurs legislations, plusieurs axes d'analyse en informatique decisionnelle. Mais l'implanta-tion
comporte plusieurs risques : des risques organisationnels (le progiciel et l'organisation de l'entreprise
doivent cohabiter), de mise en oeuvre (au niveau formation utilisateur), fonctionnels (fonctions o ertes
par le progiciel par rapport aux fonctions attendues), techniques, contractuels

6
entre l'editeur et l'entreprise et en n des risques economiques du fait de l'investissement.

2.1.4 Les principaux editeurs des ERP


On distingue deux types d'ERP : les ERP proprietaires, edites par des societes, ce qui
implique l'achat d'une licence, et les ERP open source qui sont " gratuits ". Les principaux
ERP proprietaires du marche sont :
{ SAP (leader mondial)
{ Oracle/Peoplesoft
{ SAGE ADONIX {
Microsoft
{ SSA Global

Conclusion
Dans ce chapitre nous avons de nit c'est quoi reellement les ERP. Ce chapitre sert donc
a presenter theoriquement notre sujet pour mieux comprendre le systeme implement .
Le chapitre suivant sera consacre a l'etude des besoins fonctionnels et non fonctionnels
auxquels doit repondre notre application.

7
Chapitre 3

Analyse et speci cation des besoins

Introduction
La reussite de tout projet depend de la qualite de son depart. De ce fait, l'etape de speci
cation constitue la base de depart de notre travail. En outre, l'adequation de toute l'application a
realiser, aux besoins des utilisateurs et aux traitements envisages au niveau de ses operations
assurera la reussite de l'application et son utilite future. Pour assurer ces objectifs, il est essentiel
que nous parvenions a une vue claire des di erents besoins escomptes de notre projet.
Dans ce chapitre, nous etudions dans un premier temps les besoins fonctionnels et non
fonctionnels de notre systeme, ensuite, une speci cation formelle des besoins est presentee
par des diagrammes de cas d'utilisation et de sequences suivant la modelisation UML.

3.1 Identi cation des Utilisateurs


Notre application fournit une interaction avec plusieurs types d'acteurs, ils sont de nis
comme etant des utilisateurs directs du systeme exploitant le logiciel a travers ses
interfaces. Nous identi ons dans le cadre de ce projet six acteurs primaires :
{ Le directeur qui est l'utilisateur qui a tous les privileges au niveau de la comptabilite
analytique et au niveau de la gestion des r^oles des autres acteurs.
{ Le comptable qui a un acces limite au niveau de la comptabilite analytique.
{ L'ingenieur qui a tout les droits au niveau de la gestion de la base de connaissance.
{ Le consultant simple qui a un acces limite au niveau de la gestion de la base de
connais-sance.
{ L'assistance du service qui aura l'acces pour ajouter ou modi er les documents des
ingenieurs.
{ Les responsables des departements qui ont des privileges speci ques a chaque departement.

Pour cela on va speci er ci dessous les besoins que doit fournir le systeme pour
chaque categorie d'utilisateurs.

8
3.2 Les Exigences Speci ques
L'analyse du sujet, nous a permis de cerner les fonctionnalites a la disposition de l'utilisa-
teur.Les besoins ainsi degages ont et classes en fonctionnels et non fonctionnels.

3.2.1 Les besoins fonctionnels


{ Le Directeur : Le systeme doit permettre au directeur de :
{ S'identi er pour acceder a la section de la comptabilite.
{ Consulter la liste detaillee des a aires et la repartition des ingenieurs correspondant
par mois.
{ E ectuer des recherches selon des di erents criteres : par date, par ingenieur ou par a
aire.
{ Ajouter une nouvelle a aire si elle n'existe pas deja.
{ Visualiser les statistiques et les courbes d'evolution.
{ Telecharger un chier EXCEL et mettre a jour la base de donnees.
{ Valider les documents telecharges.
{ Saisir les informations du document de l'ingenieur a l'aide d'un formulaire.
{ Mettre a jour les r^oles de chaque pro le utilisant le systeme.

{ Le Comptable : Le systeme doit permettre au comptable de :


{ Consulter la liste detaillee des a aires et la repartition des ingenieurs correspondant
par mois.
{ E ectuer des recherches selon des di erents criteres .
{ S'identi er pour acceder a la section de la comptabilite.
{ Visualiser les statistiques et les courbes d'evolution.

{ L'ingenieur : Le systeme doit permettre a l'ingenieur de :


{ S'identi er pour acceder a la section de la gestion de la base de
connaissances. { Remplir les ches de procedure (description, mot cle..).
{ Consulter ses ches de procedure remplies
auparavant. { Mettre a jour une che de procedure.

{ Le consultant : Le systeme doit permettre au consultant simple de :


{ Rechercher une che de procedure.
{ Consulter les ches resultantes classees.
{ Imprimer la che des procedures.

{ Le responsable de departement : Le systeme doit permettre au responsable de


departement de :
{ S'identi er pour acceder a la section de comptabilite analytique.
{ Ajouter et mettre a^ jour les pro les du departement.

{ L'assistance de service : Le systeme doit permettre a l'assistance de service de :

9
{ S'identi er pour acceder a la section de comptabilite analytique.
{ Ajouter des documents des ingenieurs.
{ Valider les documents des ingenieurs.

3.3 Les exigences non speci ques


Pour le bon fonctionnement de notre application nous avons degag les besoins non fonc-
tionnels suivants :
{ la abilite : le systeme doit ^etre disponible a tout moment pour l'utilisateur, avec un
acces securis par la de nition d'un login et d'un mot de passe.
{ la portabilite : le systeme doit tourner sur plusieurs plates-formes.
{ la convivialite : le systeme doit presenter une interface comprehensible, facile a
manipuler ce qui nous permettera d'accro^tre la rentabilit et l'e cacit de notre systeme.

10
3.4 Les cas d'utilisation
L'etude approfondie des speci cations permet de degager plusieurs cas d'utilisation. Un
cas d'utilisation decrit une utilisation du systeme par un acteur particulier.Ce qui revient a
presenter les besois fonctionnels de facon formelle.
Cas d'utilisation du directeur :

Fig. 3.1 { Cas d'utilisation du directeur

11
Cas d'utilisation du comptable :

Fig. 3.2 { Cas d'utilisation du comptable

12
Cas d'utilisation de l'ingenieur

Fig. 3.3 { Cas d'utilisation de l'ingenieur

13
Cas d'utilisation du consultant simple :

Fig. 3.4 { Cas d'utilisation du consultant simlpe

Cas d'utilisation de l'assistance de service :

Fig. 3.5 { Cas d'utilisation de l'assistant de service

14
Cas d'utilisation du responsable de departement

Fig. 3.6 { Cas d'utilisation du responsable de departement

3.4.1 Les diagrammes de sequences


les diagrammes de sequences peuvent servir a illustrer un cas d'utilisation decrit
precedemment. C'est un moyen semi formel de capturer le comportement de tous les objets et
acteurs impliques dans un cas d'utilisation. Dans ce qui suit nous allons presenter quelques
scenarios de notre applications.

Diagramme de sequence pour l'ajout d'un chier EXCEL

Fig. 3.7 { Ajout d'un chier EXCEL

15
Diagramme de sequence pour la consultation des statistiques

Fig. 3.8 { Consultation des statistiques

16
Diagramme de sequence pour la recherche de procedures

Fig. 3.9 { Recherche de procedures

Conclusion
Dans ce chapitre, nous venons de presenter une analyse globale de l'application tout en
speci ant les besoins fonctionnels et les contraintes que notre travail doit satisfaire et
respecter. La conception et ses details seront decrits dans le prochain chapitre.

17
Chapitre 4

Solutions techniques possibles et


choix retenus

Introduction
Ce chapitre aborde une etude comparative entre les di erentes technologies existantes et
prouve le choix de l'environnement de developpement ainsi que le systeme de gestion de la
base de donnees.

4.1 Solutions techniques possibles


4.1.1 Technologie de developpement
Microsoft .NET

Presentation : La plate-forme Microsoft .NET est une solution complete pour developper,
deployer et executer des application de tous types, y compris des services web. Fondee sur
des standards de l'industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen
simple et puissant pour implementer la cooperation des services logiciels entre eux, quelle
que soit leur localisation, leur implementation technique, qu'ils soient internes ou externes,
existant ou a inventer.

Les composants de .NET : A travers les di erentes annonces de Microsoft depuis son
lancement, les composants de .NET semblent s'organiser de la maniere suivante :
1. Pour la couche presentation et logique de presentation :
{ ASP .NET : c'est une nouvelle version d'ASP (Active Server Pages) qui supporte une
veritable compilation en IL, alors qu'ASP etait interpret auparavant. On peut
egalement ecrire les pages ASP dans n'importe quel langage disposant d'un
compilateur IL.
{ WinForms et WebForms : ils presentent un ensemble de composants graphiques
acces-sibles dans Visual Studio .NET .
2. Pour la couche logique metier et objets intermediaires :

18
{ CLR ( Common Language Runtime) : c'est un environnement d'execution commun
qui execute un bytecode ecrit dans un langage intermediaire (Microsoft intermediate
Language)
{ C# : c'est nouveau langage orient objet destin a faciliter la programmation dans .NET,
notamment les composants, qui integre des elements de C, C++ et de Java en
apportant quelques innovations comme les meta-donnees.
{ Langages quelconques qui peuvent ^etre compiles en IL et executes par le CLR si un
compilateur IL existe pour ce dernier.
{ Une grande bibliotheque de composants et d'objets de base accessibles par le CLR,
qui fournissent les fondations pour ecrire rapidement un programme (acces reseau,
gra-phisme, acces aux donnees ).
{ Visual Studio .NET : c'est une refonte de l'environnement Visual Studio et de Visual
INterDev permettant aussi bien le developpement d'application et de composant
clas-sique.
{ Un support de terminaux mobiles avec une version compacte de l'environnement .NET
.
3. Pour la couche de donnees :
{ ADO .NET : c'est une nouvelle generation de composants d'acces aux bases de
donnees ADO qui utilise XML et SOAP pour l'echange de donnees.

Les avantages de .NET : La plate-forme .NET comprend un modele de programmation


homogene et des outils de developpement multi langages qui accelerent le developpement
et l'integration de Services Web et de tout autre type d'application multi langages et integrant
les standards, la plate-forme .NET laisse au developpeur toute libert de choisir le langage de
developpement. D'autre part son support des stabndards et son approche moderne, la plate-
forme .NET est parfaitement adaptee a la construction d'une architecture orientee services.
La plate-forme .NET o re donc plusieurs avantages :
{ Un developpement speci que gr^ace au moteur CLR
. { Une structure multi langages et extensible .
{ Une execution multi plate-forme .
{ Une productivite comparable a celle des environnements Client/Serveur comme Power-
Builder ou Delphi .
{ Un modele de programmation simple et coherent .
{ Une installation automatisee des Web Services .

J2EE

Presentation : J2EE est logiquement destin aux gros systemes d'entreprise. Les logiciels
employes a ce niveau ne fonctionnent pas sur un simple PC mais requiere une puissance
beau-coup plus importante. Pour cette raison, les applications doivent ^etre constituees de
plusieurs composants pouvant ^etre deployes sur des plate-formes multiples a n de disposer
de la puissance de calcul necessaire. C'est la raison d'^etre des applications distribuees.
J2EE est une collection de composants, de conteneurs et de services permettant de
creer et de deployer des applications distribuees au sein d'une architecture standardisee.

19
Les composants de J2EE : J2EE fournit une gamme d'outils et d'API a n de concevoir
facilement les di erentes couches.
1. Pour la couche Presentation et logique de presentation :
{ Java Servlet : Une servlet est un programme ecrit en JAVA qui tourne sur la machine du
serveur J2EE. Une servlet est chargee lorsque le serveur est mis en route ou lorsque le
premier client fait appel aux services de la servlet.Le serveur Web recoit une demande
adressee a une servlet sous la forme d'une requ^ete HTTP. Il transmet la requ^ete a la
servlet concernee, puis renvoie la reponse fournie par celle du client . La servlet recoit
egalement les parametres de la requ^ete envoyee par le client. Elle peut alors e ectuer
toutes les operations necessaires pour construire la reponse avant de renvoyer celle-ci
sous forme de code HTML. Une fois chargee, une servlet reste active dans l'attente de
nouvelles requ^etes. Une servlet doit soit implementer l'interface javax.servlet.Servlet ou
etendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet.
{ Java Server Pages (JSP) : cette extension permet de valoriser davantage les
applications web avec la plate-forme J2EE en permettant le developpement
d'applications web basees sur ce modele ; les JSP permettent gr^ace au moteur de
servlet de produire facilement des pages HTML.
{ Struts : Jakarta Struts est un projet d'Appache software foundation qui a pour but de
fournir un cadre standard de developpement web en java respectant le modele
d'archi-tecture MVC (Model-View-Controller). Il fournit le minimum de regles pour
construire des applications web professionnelles.
{ Java Server Faces (JSF) : Java Server Faces est un framework d'interface utilisateur
pour les applications web, base sur les technologies JSP et Servlets. Le but de JSF
est d'accro^tre la productivite des developpeurs dans le developpement des
interfaces utilisateur tout en facilitant leur maintenance. JSF permet de reconcilier
deux points de vues diametralement opposes en fornissant un framework base sur
une abstraction complete des mecanismes d'internet tout en garantissant une totale
ma^trise du cycle de vie du traitement d'une requ^ete. JSF permet :
{ une separation nette entre la couche de presentation et les autres
couches. { le mapping HTML/Objet.
{ un modele riche de composants graphiques reutilisables. {
un modele riche de composants graphiques reutilisables.
{ une gestion de l'etat de l'interface entre les di erentes requ^etes.
{ une liaison simple entre les actions c^ote client de l'utilisateur et le code Java
corres-pondant c^ote serveur.
{ la creation de composants customs gr^ace a une API.
{ le support de di erents clients (HTML, WML, XML, ...) gr^ace a la separation des
problematiques de construction de l'interface et du rendu de cette interface.

20
Fig. 4.1 { Architecture de JSF

{ Spring : C'est un framework ayant pour but de rendre facile le developpement des
applications web tout en augmentant la consistance et la productivite.
2. Pour la couche logique metier et objet intermediaires :
{ Les EJB : Ce sont des composants Java pour des applications distribuees multi
niveaux. Cette extension fournit un moyen standard pour de nir les composants c^ote
serveur et de nit une vaste infrastructure d'execution pour l'hebergement des
composants c^ote serveur.
{ Les JavaBeans : Selon la speci cation des Javabeans, une Bean est un composant
logiciel reutilisable pouvant ^etre manipule visuellement dans un outil de construction
(builder tool).
3. Pour la couche de donnees :
{ JDBC Connector : JDBC (l'acronyme de JAVA Data Base Connectivity) est une API JAVA
permettant d'acceder a es base de donnees, de facon independante de la base utilisee,
a partir d'une application JAVA. La procedure sera la m^eme quelle que soit la base de
donnees choisie. JDBC de nit une API de bas niveau designee pour supporter les
fonctionnalites basiques de SQL independement de toute implementation SQl speci que.
{ Hibernate : c'est un framework qui donne une solution pour le mapping
objet/relationnel et la gestion de la couche de persistence. Hibernate permet la
gestion automatique de la structure de la base de donnees : creation et mise a jour.
IL utilise un langage simple pour l'interrogation de la base de donnees appel HQL
(Hibernate Query Language) et qui fournit une couche d'abstraction SQL.

21
Fig. 4.2 { Architecture de Hibernate

Les avantages de J2EE : L'approche multi niveaux adoptee par la plate-forme J2EE o re
plusieurs avantages :
{ Elle reduit la complexit du developpement distribue avec une architecture simpli ee et le
partage de la charge de travail.
{ C'est une solution hautement evolutive qui permet le developpement des systemes
satis-faisant de nombreux besoins rapidement modi ables.
{ Les nouvelles applications peuvent s'integrer correctement avec les systemes
d'informations existants.
{ La securit est amelioree.
{ Les developpeurs peuvent choisir parmi une diversit d'outils de developpement et de
composants pour developper les applications requises.
{ L'equipe de developpement peut selectionner les meilleurs solutions pour leurs besoins,
sans ^etre verrouillee par l'o re du fournisseur unique.
{ Tous les composants sont gratuits.

Comparaison entre J2EE et .NET

Dans cette section, nous allons degager les principales di erences entre la technologies J2EE
de Sun et la technologie .NET de Microsoft. En fait, nous avons limite notre etude sur ces deux
technologies car ils sont les plus appreciees au sein des entreprises qui ambitionnent avoir des
applications robustes, portables, complexes et securisees, d'autant plus qu'elles traitent des
donnees con dentielles, et font appels aux technologies les plus modernes. Le tableau suivant
expose les criteres sur lesquels se basera notre choix technologique.

22
.NET J2EE
Langages C#,multi-langage Java
Services BCL Java Core API
Presentation ASP .NET Servlet, JSP
Interprete CLR JVM
Composants graphiques WinForms, WebForms Swing
Acces a la BD ADO .NET JDBC, Hibernate, iBatis
Technologie Produit Standard

Tab. 4.1 { Tableau comparatif .NET et J2EE

4.1.2 Environnement de developpement


4.1.3 Gestion de la base de donnees
Oracle DataBase

Oracle est un SGBDR edit par la societ du m^eme nom Oracle Corporation leader
mondial en base de donnees.Oracle peut assurer entre autres fonctionnalites :
{ La de nition et la manipulation des donnees
{ La coherence des donnees.
{ La con dentialit des donnees. {
L'integrit des donnees.

MySQL

MySQL a pour origine l'application mSQL. Cette application permettait de ce connecter a des
tables en utilisant des routines bas niveau. Cependant, apres quelques tests, les developpeurs
sont arrives a la conclusion que mSQL n'etait pas assez rapide et exible pour leurs besoins. Le
serveur de bases de donnees MySQL est tres rapide, able et facile a utiliser. Il dispose aussi de
fonctionnalites pratiques, developpees en cooperation avec les utilisateurs.
Les principales fonctionnalites qu'o re MySQL sont :
{ Fonctionne sur de nombreuses plate-formes.
{ Dispose d'API pour C, C++, Ei el, Java, Perl, PHP, Python, Ruby et Tcl.
{ Completement multi-threade, gr^ace aux threads du noyau. Cela signi e qu'on peut
l'utiliser facilement sur un serveur avec plusieurs processeurs.
{ Tables B-tree tres rapide, avec compression d'index.
{ Systeme l'allocation memoire tres rapide, exploitant les threads.
{ Tables en memoire, pour realiser des tables temporaires.
{ Les fonctions SQL sont implementees gr^ace a une librairie de classes optimisees, qui
sont aussi rapides que possible .

PostgreSQL

PostgreSQL est un SGBD relationnel objet Open Source implement par l'universit de Ber-keley.
Les fonctions cles du modele objet de PostgreSQL sont les classes, l'heritage et la surcharge.

23
PostgreSQL est un logiciel " modulaire " possedant un langage d'ecriture de procedures
similaire a celui d'Oracle mais egalement d'autres interfaces de programmation. Voici les
fonctions cles du modele orient objet de PostgreSQL :
{ Les classes : Une classe correspond a un ensemble d'objets possedant un identi cateur
unique.
{ L'heritage : La notion d'heritage correspond a une organisation hierarchique des tables. Par
exemple, si deux tables se trouvent dans une relation parent/enfant, les informations
contenues dans la table parent sont egalement disponible dans la table enfant.
{ La surcharge : On parle de "surcharge de fonction" lorsqu'une fonction peut ^etre de nie
plusieurs fois avec des parametres di erents.

4.2 Choix retenus


La claret de l'architecture qu'elle propose ainsi que la multitude des IDE qui peuvent la
supporter et sa gratitude, la technologie J2EE a et le choix Judicieux pour le developpement
de notre application. L'IDE surlequel nous avons choisit de developper notre application est
l'IDE Eclipse. Une base de donnee MySQL est celle qui va ^etre implementer pour gerer les
donnees necessaire a l'application.

Conclusion
Apres cette etude nous avons decid de choisir la plate-forme J2EE comme
environnement de developpement (donc Java comme langage de programmation), MySQL
pour l'implementation de la base de donnees et hibernate pour la couche persistence de
donnees. Le chapitre suivant aborde en detail la conception de l'application a realiser.

24
Chapitre 5

Conception

Introduction
Dans ce present chapitre nous allons entamer une partie cruciale du developpement
logiciel et qui constitue un pont entre la speci cation et la realisation. Elle comporte la
conception de l'application ainsi que la conception de la base de donnees.

5.1 Conception generale


Le travail a realiser est decompos en deux module independants a savoir le module de la
comptabilite analytique et le module le gestion de la base de connaissances.

5.1.1 La comptabilite analytique :


Ce module s'integre dans la partie de gestion nanciere de l'ERP a realiser. Elle automatise au
premier lieu la t^ache de pointage horaire du personnel de l'entreprise et facilite, en second lieu,
la t^ache du comptable pour la realisation des statistiques elementaires et croisees et y dessiner
les diagrammes correspondnat a n de les bien presenter au responsable superieur. Ce module, a
part son r^ole pour reduire les temps de realisation des t^aches citees, il permet d'economiser
l'argent puisque l'^etre humain n'interviendra pas dans le mecanisme.

5.1.2 La gestion de la base de connaissances :


Ce module fait parti de la gestion de la productivite de l'entreprise. en e et il sert comme
un puissant outil pour la constitution d'un ensemble de connaissances dans les domaines
d'activite de l'entreprise a n de faciliter la reparation, la mise a niveau ou l'elimination d'une
procedure de travail.

5.2 Conception detaillee


La conception detaillee vise a transformer le modele d'analyse (speci cation : haut niveau
d'abstraction) en un modele concr^et, de bas niveau d'abstraction et a partir duquel le
program-meur peut directement implementer le systeme.

25
5.2.1 Architecture de l'application
La navigation entre les di erentes parties de notre application est presentee par la gure
ci-dessous :

Fig. 5.1 { Architecture de l'application

5.2.2 Diagrammes de Classes


Le diagramme de classes permet de decrire la structure statique du systeme a l'aide des
classes et des relations.

26
Fig. 5.2 { Diagramme de classes de l'application

27
5.2.3 Diagrammes de sequences detailles
Diagramme de sequence pour l'ajout d'un chier EXCEL
Le diagramme suivant presente comment un ingenieur peut ajouter un chier EXCEL pour le
prendre en compte par l'administration de l'entreprise.

Fig. 5.3 { Ajout d'un chier EXCEL

28
Diagramme de sequence pour la consultation des statistiques

Fig. 5.4 { Consultation des statistique

29
Diagramme de sequence pour la recherche de procedures

Fig. 5.5 { Recherche de procedures

30
5.2.4 Conception de la base de donnees
Le modele relationnel de donnees est un modele de donnee comme d'autres existants
ayant pour but de decrire le monde reel a partir des informations et des donnees qu'on peut
en extraire et se di erencient par la nature des associations qu'ils permettent de modeliser.
L'objectif essen-tiel du modele relationnel etait d'accro^tre l'independance vis-a-vis du niveau
de representation des donnees. Du point de vue utilisateur, une base de donnees peut ^etre
consideree comme un ensemble de tables manipulables par des langages de haut niveau
dont la caracteristique princi-pale est d'^etre des langages non proceduraux. Pour ces
raisons nous avons choisi d'utiliser une base de donnees relationnelle.
A ce niveau de cette application et tout en considerant les besoins deja speci es nous avons
envisag un certain nombre de tables pour enregistrer les donnees necessaires pour la gestion du
site. Les tables utilisees et les relations qui les inter-relient sont donnees par la gure 5.6

Fig. 5.6 { Conception de la base de donnees

31
Coclusion
Etant donne les besoins des utilisateurs de notre applications, la phase de conception
vient pour permettre la determination des di erents objets contribuant a assurer les
fonctionnalites souhaitees. Cette phase est une preparation a la phase du codage
garantissant une organisation claire et precise ainsi qu'une facilite d'implementation des
classes invoquees, des structures de donnees utilisees et les relations qui existent entre les
di erentes classes. Nous essayons dans le chapitre realisation d'implementer les di erentes
classes et de montrer les fonctionnalites realisees suite a cette implementation.

32
Chapitre 6

Realisation

Apres avoir achev l'etape de conception de l'application, nous entamons dans ce chapitre
la phase de realisation. Nous allons presenter, en premier lieu, l'environnement de travail
utilise pour le developpement de l'application. Ensuite, nous allons donner un apercu sur le
travail accompli a travers des capture d'ecran. En n, nous montrerons le chronogramme de la
realisation du projet.

6.1 Environnement de travail


6.1.1 Environnement materiel
A n de realiser ce site web dans les conditions les plus favorables, nous avons mis en
dispo-sition un ordinateur ayant la con guration suivante :

Processeur : Intel(R) Pentium(R) M 3.2GHz


Disque dur : 120Gb
RAM :1.256GB

6.1.2 Environnement logiciel


Eclipse

Eclipse est un environnement de developpement integr (Integrated Development Envi-


ronment) dont le but est de fournir une plate-forme modulaire pour permettre de realiser des
developpements informatiques. I.B.M. est a l'origine du developpement d'Eclipse qui est
d'ailleurs toujours le coeur de son outil Websphere Studio Workbench (WSW), lui m^eme a
la base de la famille des derniers outils de developpement en Java d'I.B.M. Tout le code
d'Eclipse a et donne a la communaute par I.B.M a n de poursuivre son developpement.
Eclipse utilise enormement le concept de modules nommes "Plug-ins" dans son
architecture. D'ailleurs, hormis le noyau de la plate-forme nomme "Runtime", tout le reste de
la plate-forme est developp sous la forme de Plug- ins. Ce concept permet de fournir un
mecanisme pour l'extension de la plate-forme et ainsi fournir la possibilite a des tiers de
developper des fonction-nalites qui ne sont pas fournies en standard par Eclipse.

33
Tomcat :

Tomcat est un serveur d'application totalemet ecrit en java. A partir de la version 5.0 il
implementait les speci cations 2.4 des JavaServlet et 2.0 des JSP.
Tomcat a et developp en open source au sein du projet Apache Jakarta, dont le but est de fournir
des solutions serveur basees sur la plate-forme Java, de qualite identique aux applications
commerciales.Tomcat est un moteur d'execution pour les servlets et les pages JSP. Il prend en
charge la partie dynamique du site et laisse la partie statique au serveur web.

6.2 Travail realis


A cette etape du nous donnons les captures d'ecran relatives aux pages des principales
fonctions realisees par l'application.

6.2.1 Page d'authenti cation des utilisateurs

Fig. 6.1 { Identi cation des utilisateurs

34
6.2.2 Page d'ajout d'un document EXCEL

Fig. 6.2 { Ajout d'un chier

6.2.3 Page de validation d'un documents EXCEL

Fig. 6.3 { Validation du document EXCEL

35
6.2.4 Recherche de ches de procedures

Fig. 6.4 { Recherche de che de procedure

6.2.5 Resultats de la recherche

Fig. 6.5 { Resultats de la recherche

36
6.2.6 Consultation des statistiques

Fig. 6.6 { Consultation des statistiques

6.2.7 Ajout de nouveaux utilisateurs ou administrateurs

Fig. 6.7 { Ajout de nouveaux utilisateurs ou administrateur

37
6.3 Chronogramme
Il est necessaire de tracer un diagramme qui decrit la repartition temporelle des t^aches du
travail durant deux mois a n de montrer les di erentes phases par lesquelles notre projet a passe.
{ Documentation et etudes theorique : elle consiste a rechercher une documentation sur
le sujet et a etudier les objectifs generaux du stage.
{ Speci cation et analyse de besoins : elle consiste a etudier l'etat actuel du processus de
travail de l'entreprise ainsi que ses besoins reels.
{ Conception : elle vise a modeliser le systeme selon une vue bien claire.
{ Implementation : elle s'occupe du developpement du codes des di erentes fonctionalites
du systeme comme modelis dans la conception.
{ Redaction du rapport : elle collecte toutes les informations necessaires et autorisees a
^etre publiees.
Le chronogramme suivant donne la repartition de ces di erentes phases :

Fig. 6.8 { Chronogramme

38
Conclusion et perspectives

Avant de commencer le stage, nous en attendions essentillement a trois choses : travailler sur
un produit d'avenir au moins en tunisie (les ERP), recueillir une experience et des competences
professionnelles et decouvrir le fonctionnement des equipes de developpement au sein des
entre-prises informatiques.

L'objectif de ce stage etait de concevoir et de developper deux modules faisant parti d'un
ERP destin a une entreprise classee de PME.

Il a et aussi bene que aussi bien sur le plan theorique que sur le plan pratique. En e et sur le
plan pratique ce projet nous a donne une occasion de decouvrir le framework JSF pour le
developpement des applications web, et d'ameliorer nos connaissances sur la gestion des bases
de donnees. Sur le plan theorique il nous a permis une familiarisation avec les notions et les au-
tomatismes de la programmation des applications Web avec l'IDE Eclipse suivant l'architecture
MVC2 ainsi que les techniques de manipulation de la couche de persistence avec Hibernate.

En perspectives, le developpement du reste des modules de l'ERP et son integration dans


l'environnement constituons le sujet du projet de n d'etudes a n de voir un produit complet
pouvant automatiser plusieurs t^ache dans les petites et moyennes entreprises.

39
Bibliographie

[1] Olivier Debas, Christine De aix Remy Applications Web Java Servlets et JSP,2004

[2] David GearyCore, Cay Horstmann JavaServer Faces, Second Edition,2007

[3] Giulio zambon Begining JSP, JSF and Tomcat web devloppement.Apress 2007

[4] Eric Sarrion. Developpement Web avec J2EE .O'Reilly,2005

40
Netographie

[N1] http://www.developpez.com consulte le 01 juillet 2008


[N2] http://www.coreservlets.com/JSF-Tutorial/ consulte le 09 juillet 2008
[N3] http://www.jsftoolbox.com/documentation/ consulte le 10 juillet 2008
[N4] http://www.roseindia.net/ consulte le 27 juillet 2008
[N2] http://www.myfacescomponent.com consulte le 20 ao^ut 2008
[N3] http://www.tomahawkcomponent.com consulte le 21 ao^ut 2008

41
Glossaire

Dans ce glossaire nous citons quelques termes necessaires pour la comprehension du


rapport. ASP : Active Server Pages
CLR : Common Language Runtime
EJB : Entreprise JavaBean
ERP : Entreprise Ressource Planning
HQL : Hibernate Query Language
HTTP : Hyper Text Transfer Protocol
IDE : Integrated Development Environment
JDBC : Java Data Base Connectivity
JSF : Java Server Faces
JSP : Java Server Pages
MVC : Model-View-Controller
PGI : Progiciel de Gestion Integr
PME : Petites et Moyennes Entreprises
SI : Systeme d'Information
SQL : Structured Query Language
UML : Uni ed Modeling Language

42
Annexe A

Les Architectures Logicielles


Architecture Simple tiers
Les applications bureautiques sont concues pour fonctionner sur un ordinateur unique.
Toutes les services fournis par l'application - interface utilisateur, persistance des donnees
(sauvegarde dans des chiers proprietaires) et logique de traitement de ces donnees -
resident sur la m^eme machine et sont inclus dans l'application.

Fig. A.1 { Architecture Simple Tiers.

Architecture deux tiers


Selon l'architecture deux tiers les traitements sont repartis entre le client represent par une
station de travail utilisateur et le serveur represent par un mainframe ou un serveur puissant. Le
client prend en charge l'ensemble des taches liees a la presentation, a la logique applicative ainsi
qu'une grande partie de la logique metier. Quant au serveur, son r^ole est d'heberger les
donnees du systeme d'information et de traiter les requ^etes en provenance du client.
Un des inconvenient de l'architecture deux-tiers est que la logique chargee de la
manipulation des donnees et de l'application des regles metiers a erentes est incluse dans
l'application elle-m^eme. Cela pose probleme lorsque plusieurs applications doivent partager
l'acces a une base de donnees.

Architecture trois tiers


C'est un modele logique d'architecture applicative qui vise a separer tres nettement trois
couches logicielles au sein d'un m^eme systeme.

43
Fig. A.2 { Architecture Deux Tiers

Fig. A.3 { Architecture Trois Tiers

Selon ce modele, toute la logique metier est extraite de l'application cliente. Celle-ci n'est
plus responsable que de la presentation de l'interface a l'utilisateur et de la communication
avec le tiers median. Elle n'est plus responsable de l'application des regles. Son r^ole est
reduit a la couche presentation.

La plate forme J2EE


J2EE est l'acronyme de Java 2 Entreprise Edition. Cette edition est dediee a la realisation
d'applications pour entreprises. J2EE est base sur J2SE (Java 2 Standard Edition) qui contient
les API de base de Java. Depuis sa version 5, J2EE est renomm Java EE (Enterprise Edition).

Notion de J2EE
J2EE est logiquement destin aux gros systemes d'entreprise. Les logiciels employes a ce
ni-veau ne fonctionne pas sur un simple PC mais requiere une puissance beaucoup plus
importante. Pour cette raison, les applications doivent ^etre constituees de plusieurs
composants pouvant ^etre deployes sur des plate-formes multiples a n de disposer de la
puissance de calcul necessaire. C'est la raison d'^etre des applications distribuees.
J2EE est une collection de composants, de conteneurs et de services permettant de
creer et de deployer des applications distribuees au sein d'une architecture standardisee.

44
Les Conteneurs
Les conteneurs sont les elements fondamentaux de l'architecture J2EE. Les conteneurs
fournis par J2EE sont de m^eme type. Ils fournissent une interface parfaitement de nie ainsi
qu'un ensemble de services permettant aux developpeurs d'applications de se concentrer
sur la logique metier a mettre en oeuvre pour resoudre le probleme qu'ils ont a traiter, sans
qu'ils aient a se preocuper de toute l'infrastructure interne. Les conteneurs s'occupent de
toutes les t^aches fastidieuses liees au demarrage des services sur le serveur, a l'activation
de la logique applicative, la gestion des protocoles de communication intrinseque ainsi qu'a
la liberation des ressources utilisees.

Les Servlets
Une servlet est un programme ecrit en JAVA qui tourne sur la machine du serveur J2EE. Une
servlet est chargee lorsque le serveur est mis en route ou lorsque le premier client fait appel aux
services de la servlet.Le serveur Web recoit une demande adressee a une servlet sous la forme d'une
requ^ete HTTP. Il transmet la requ^ete a la servlet concernee, puis renvoie la reponse fournie par
celle du client . La servlet recoit egalement les parametres de la requ^ete envoyee par le client. Elle
peut alors e ectuer toutes les operations necessaires pour construire la reponse avant de renvoyer
celle-ci sous forme de code HTML. Une fois chargee, une servlet reste active dans l'attente de
nouvelles requ^etes. Une servlet doit soit implementer l'interface javax.servlet.Servlet ou etendre soit
la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet.

Fig. A.4 { Servlet etendant la classe javax.servlet.http.HttpServlet

Les pages Jsp


Creer des servlets consiste a construire des composants Java capables de produire du code
HTML. Dans de nombreux cas, cela fonctionne sans probleme. Toutefois, il n'est pas facile, pour
les personnes chargees de concevoir l'aspect visuel des pages Web, de manipuler du code Java,
auquel elles n'ont probablement pas et formees. C'est la raison d'^etre des JavaServer Pages.
Les JSP sont des documents de type texte, contenant du code HTML ainsi que des scriptlets
(et/ou des expressions), c'est-a-dire des morceaux de code Java.

45
Fig. A.5 { Les pages JSP dans une application J2EE.

Les JavaBeans
Selon la speci cation des Javabeans, une Bean est un composant logiciel reutilisable pouvant
^etre manipule visuellement dans un outil de construction (builder tool). Un composant possede :
{ des proprietes persistantes
{ des evenements reconnus
{ des methodes de traitement des evenements

Les Serveurs D'application


Le serveur d'application est l'environnement d'execution des applications c^ote serveur. Il
prend en charge l'ensemble des fonctionnalites permettant a plusieurs utilisateurs d'exploiter
une m^eme application. Parmi ces fonctionnalites nous pouvons citer :
{ Gestion de la session utilisateur : c'est le fait de conserver pour chaque utilisateur un
contexte qui lui est propre, et cela se fait generalement en generant un identi ant
unique pour chaque client et en le transmettant lors de chaque echange HTTP.
{ Gestion des montees en charge et reprise sur incident : a n de gerer toujours plus d'uti-
lisateurs, le serveur d'application doit pouvoir se deployer sur plusieurs machines et,
eventuellement, o rir des possibilites de reprise sur incident.
{ Ouverture sur plusieurs sources de donnees : pour rendre accessible les donnees de l'appli-
cation, le serveur d'application doit pouvoir acceder a de nombreuses sources de donnees.

Le Modele MVC
Le modele MVC (Model View Controler) a et initialement developp pour le langage Small-
talk dans le but de mieux structurer une application avec une interface graphique.
Ce modele est un concept d'architecture qui propose une separation en trois entites des
donnees, des traitements et de l'interface :

46
Fig. A.6 { Le modele MVC.

{ Le Modele represente les donnees de l'application generalement stockees dans une


base de donnees.
{ La Vue correspond a l'IHM (Interface Homme Machine).
{ Le Contr^oleur assure les echanges entre la vue et le modele notamment gr^ace a des
com-posants metiers.
L'utilisation du modele MVC rend un peu plus complique le developpement de l'application
qui le met en oeuvre mais il permet une meilleure structuration de l'application. Le principal
defaut du modele MVC est le nombre de servlets a developper pour une application. Comme
remede a ce probleme, le modele MVC2 s'est impose. En e et cette version du modele
propose de n'utiliser qu'une seule servlet comme contr^oleur de tiute l'application.

47