Table des mati`res e

1 Pr´sentation G´n´rale e e e 1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Pr´sentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2 Etat de l’art 2.1 Les ERP . . . . . . . . . . . . . . . . . . 2.1.1 Historique . . . . . . . . . . . . . 2.1.2 D´finition d’un ERP . . . . . . . e 2.1.3 Pour quoi les ERP ? . . . . . . . 2.1.4 Les principaux ´diteurs des ERP e 3 Analyse et sp´cification des besoins e 3.1 Identification des Utilisateurs . . . . 3.2 Les Exigences Sp´cifiques . . . . . . e 3.2.1 Les besoins fonctionnels . . . 3.3 Les exigences non sp´cifiques . . . . e 3.4 Les cas d’utilisation . . . . . . . . . 3.4.1 Les diagrammes de s´quences e 3 3 3 5 5 5 6 6 7 8 8 9 9 10 11 15 18 18 18 23 23 24 25 25 25 25 25 26 26 28 31

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Solutions techniques possibles et choix retenus 4.1 Solutions techniques possibles . . . . . . . . . . . 4.1.1 Technologie de d´veloppement . . . . . . e 4.1.2 Environnement de d´veloppement . . . . e 4.1.3 Gestion de la base de donn´es . . . . . . . e 4.2 Choix retenus . . . . . . . . . . . . . . . . . . . . 5 Conception 5.1 Conception g´n´rale . . . . . . . . . . . . . . . e e 5.1.1 La comptabilit´ analytique : . . . . . . e 5.1.2 La gestion de la base de connaissances : 5.2 Conception d´taill´e . . . . . . . . . . . . . . . e e 5.2.1 Architecture de l’application . . . . . . 5.2.2 Diagrammes de Classes . . . . . . . . . 5.2.3 Diagrammes de s´quences d´taill´s . . . e e e 5.2.4 Conception de la base de donn´es . . . . e i

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6 R´alisation e 6.1 Environnement de travail . . . . . . . . . . . . . . . . . . 6.1.1 Environnement mat´riel . . . . . . . . . . . . . . . e 6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . 6.2 Travail r´alis´ . . . . . . . . . . . . . . . . . . . . . . . . . e e 6.2.1 Page d’authentification des utilisateurs . . . . . . . 6.2.2 Page d’ajout d’un document EXCEL . . . . . . . . 6.2.3 Page de validation d’un documents EXCEL . . . . 6.2.4 Recherche de fiches de proc´dures . . . . . . . . . e 6.2.5 R´sultats de la recherche . . . . . . . . . . . . . . e 6.2.6 Consultation des statistiques . . . . . . . . . . . . 6.2.7 Ajout de nouveaux utilisateurs ou administrateurs 6.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . Netographie A Annexe

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

33 33 33 33 34 34 35 35 36 36 37 37 38 41 43

ii

Table des figures
1.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 A.1 A.2 A.3 A.4 A.5 Feuille d’affectation de temps pass´s . . . . . . . . . . . . . . . . . . . . . . . . . e Cas d’utilisation du directeur . . . . . . . . . . . Cas d’utilisation du comptable . . . . . . . . . . Cas d’utilisation de l’ing´nieur . . . . . . . . . . e Cas d’utilisation du consultant simlpe . . . . . . Cas d’utilisation de l’assistant de service . . . . . Cas d’utilisation du responsable de d´partement e Ajout d’un fichier EXCEL . . . . . . . . . . . . . Consultation des statistiques . . . . . . . . . . . Recherche de proc´dures . . . . . . . . . . . . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 11 12 13 14 14 15 15 16 17 21 22 26 27 28 29 30 31 34 35 35 36 36 37 37 38 43 44 44 45 46

Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de l’application . . . . . . Diagramme de classes de l’application Ajout d’un fichier EXCEL . . . . . . . Consultation des statistique . . . . . . Recherche de proc´dures . . . . . . . . e Conception de la base de donn´es . . . e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Identification des utilisateurs . . . . . . . . . . . Ajout d’un fichier . . . . . . . . . . . . . . . . . . Validation du document EXCEL . . . . . . . . . Recherche de fiche de proc´dure . . . . . . . . . . e R´sultats de la recherche . . . . . . . . . . . . . . e Consultation des statistiques . . . . . . . . . . . Ajout de nouveaux utilisateurs ou administrateur Chronogramme . . . . . . . . . . . . . . . . . . .

Architecture Simple Tiers. . . . . . . . . . . . . . . . . . Architecture Deux Tiers . . . . . . . . . . . . . . . . . . Architecture Trois Tiers . . . . . . . . . . . . . . . . . . Servlet ´tendant la classe javax.servlet.http.HttpServlet e Les pages JSP dans une application J2EE. . . . . . . . .

iii

A.6 Le mod`le MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e

47

iv

Introduction G´n´rale e e D e nos jours, toute entreprise est prˆte ` investir des sommes consid´rables dans l’implantae a e
tion des technologies logicielles afin d’am´liorer ses services, d’accroˆ son agilit´ et sa flexibilit´, e ıtre e e de r´duire les coˆts, d’augmenter la production et de faire face aux d´fis du march´. En effet, e u e e vu la croissance des activit´s au sein des entreprises, la tˆche de g´rer efficacement toutes ces e a e fonctions s’av`re de plus en plus complexe et difficile. e Pour surpasser ces difficult´s, une entreprise doit utiliser des outils optimis´s et adapt´s fae e e cilitant les tˆches et offrant des fonctionnalit´s riches et utiles. Parmi ces outils nous trouvons a e les syst`mes int´gr´s de gestion tel que les ERP(Entrprise Ressources Planning). e e e Les ERP sont des outils de gestion et d’analyse permettant d’optimiser la diffusion des informations en interne, d’am´liorer les processus de gestion et d’automatiser les tˆches ce qui e a augmente ´normement la r´activit´ des entreprises et leurs agilit´s. e e e e C’est dans ce contexte que s’int`gre notre stage d’immersion en entreprise qui a pour obe jectif de concevoir et de r´aliser un ERP permettant d’automatiser les diff´rentes besognes de e e la soci´t´ NETCOM TUNISIE. Cet ERP doit automatiser les diff´rents processus de gestion ` ee e a savoir la gestion des ressources humaines, la gestion de la production, la gestion commerciale et la gestion financi`re. e Le pr´sent rapport synth´tise tout le travail que nous avons effectu´ dans cette perspective. e e e il est organis´ en chapitres comme suit : e – Le premier chapitre donne une pr´sentation g´n´rale du projet : l’organisme d’accueil ainsi e e e que les objectifs ` atteindre. a – Dans le second chapitre, nous proc´dons ` un expos´ de l’´tat de l’art du domaine qui e a e e nous concerne. Nous pr´sentons dans un premier temps le syst`me existant pour d´voiler e e e ses d´faillances et ses limites. Nous pr´sentons ´galement la solution que nous proposons e e e afin de palier aux limites du syst`me actuel. e – Le troisi`me chapitre intitul´”’Analyse et Sp´cification des besoins”’pr´sente les diff´rents e e e e e besoins fonctionnels et non fonctionnels auxquelles doit satisfaire l’application. – Les choix technologiques retenus pour la phase de d´veloppement font l’objet du quatri`me e e chapitre. – Dans le chapitre V nous pr´sentons la conception g´n´rale et la conception d´taill´e du e e e e e

1

syst`me. e – Le dernier chapitre d´crit les tˆches accomplies en titre de r´alisation. e a e Enfin nous donnons une conclusion r´capitulant le travail r´alis´ ainsi que des perspectives e e e futurs.

2

Chapitre 1

Pr´sentation G´n´rale e e e
Introduction
Ce chapitre a pour objectif de situer notre projet dans son contexte g´n´rale ` savoir l’orgae e a nisme d’accueil et le sujet ` traiter. Dans la premi`re section nous donnons une br`ve pr´sentation a e e e de l’organisme d’accueil SATEC International. Dans la deuxi`me section, nous d´crivons le e e sujet ` traiter et les objectifs ` atteindre. a a

1.1

Organisme d’accueil

Activit´s de SATEC e SATEC a ´t´ cr´ee en 1992 et a pu, durant 16 ans, consolider une bonne et solide assise sur le ee e march´ tunisien en tant qu’int´grateur r´seaux et s´curit´ de r´seaux, ind´pendamment de tout e e e e e e e constructeur. SATEC Tunisie, est devenue un pr´curseur et un acteur majeur de l’int´gration e e r´seau en Tunisie. e Quelques dates utiles – 1992 : Cr´ation de SATEC Tunisie. e – 1998 : SATEC Tunisie, meilleur support Nortel : proche Orient/ Afrique du Nord, Cisco Partner. – 1998 : R´alisation du projet de la t´l´ compensation, ISO 9001 version 2000. e ee – 2002 : Sp´cialisation s´curit´ VPN,WiFi de Cisco Systems. e e e – 2004 : Mise en service d’un centre de management de la s´curit´. e e – 2005 : Services manag´s Q.o.S, s´curit´. e e e

1.2

Pr´sentation du sujet e

Dans le syst`me actuel de la soci´t´ NETCOM, chaque service poss`de son propre syst`me e ee e e d’information ce qui a donn´ lieu ` plusieurs probl`mes dont les majeurs sont : e a e – Pour collecter les informations n´cessaires au processus d’administration de l’entreprise, e on constate une lenteur caus´e par la dispersion de diff´rents syst`mes d’informations. e e e

3

– Toute mise ` jour suvenue sur l’un des syst`mes d’informations n’est d´tect´e par les a e e e autres que par voie humaine, en cons´quence elle ne se fait pas en temps r´el et risque de e e transmettre des information erron´es. e Les cons´quences d´sagr´ables d’une telle situation ont oblig´ l’entreprise ` y mettre fin. e e e e a Pour cela, la meilleur solution ´tait d’impl´menter un ERP multifonctions qui vise ` centraliser e e a le syst`me d’information et ` automatiser ses activit´s tout en garantissant une s´curit´ de haut e a e e e niveau.

Fig. 1.1 – Feuille d’affectation de temps pass´s e Notre mission consistait alors ` concevoir et impl´menter cet ERP qui doit comporter les a e quatre module suivants : – – – – Module Module Module Module de de de de gestion gestion gestion gestion de ressources humaines de la production commerciale financi`re e

Notre mission a ´t´ ensuite r´duite ` la r´alisation de deux sous modules : impl´mentation ee e a e e 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’insuffisance du temps consacr´ au stage, et e en second lieu l’urgence de r´aliser ces deux fonctionnalit´s pour le client. e e

Conclusion
Dans ce premier chapitre nous avons pu situer le projet dans son cadre g´n´ral en pr´sentant e e e l’organisme d’accueil et les buts de l’application. Dans le chapitre suivant, nous allons proc´der e a ` une ´tude d´taill´e de l’existant pour d´gager ses limites. e e e e

4

Chapitre 2

Etat de l’art
Introduction
Avant d’entamer l’´laboration de notre application, nous avons jug´ primordial de pr´senter e e e les objectifs d’une telle application ` partir des ´l´ments moteurs par lesquels elle est constitu´e. a ee e

2.1
2.1.1

Les ERP
Historique

Dans les ann´es 60 et 70, les premiers logiciels font leur apparition dans les entreprises. e Il s’agit essentiellement d’applications de comptabilit´ et ´galement de MRP, pour la gestion e e des approvisionnements. Ces logiciels sp´cifiques ne sont pas ” portables ”, c’est ` dire qu’ils e a d´pendent du type d’ordinateur et du syst`me d’exploitation. Dans les ann´es 80 se d´veloppent e e e e des progiciels qu’on personnalise, int´grants la finance, la comptabilit´, la paie et la gestion de e e production assist´e par ordinateur. La tendance ` personnaliser et ` modifier compl`tement le e a a e progiciel de base pour l’entreprise conduit le produit ` ˆtre obsol`te au bout de 5 ` 10 ans. Dans ae e a ces ann´es apparaissent ´galement les premiers MRP II, int´grant la gestion de production et e e e la gestion des approvisionnements. La petite histoire raconte qu’` la fin des ann´es 80, trois a e employ´s d’IBM pressentent un march´ important pour les progiciels int´gr´s, et fondent SAP. e e e e Peu apr`s, SAP R/2 devient la premi`re r´f´rence en mati`re d’ERP, encore fond´e sur une e e ee e e structure informatique centralis´e et une technologie mainframe. e En 1993, SAP R/3 r´alise l’int´gration totale de toutes les composantes d’une entreprise, de e e la finance ` la production, aux ventes et aux ressources humaines... Sa structure informatique a et sa portabilit´ compl`te seront une grande raison de son succ`s. e e e Les ERP sont maintenant pr´sents dans l’industrie et dans la grande distribution, essentiele lement dans les tr`s grandes entreprises. Le march´ des plus petites entreprises, le domaine de e e la finance et le secteur public commencent ` ˆtre touch´s. ae e La conception et le d´veloppement des ERP ont ´t´ rendus possibles par les ´volutions e ee e technologiques : vitesse de calcul, technologies de r´seaux, syst`mes de gestion de bases de e e donn´es, stockage de donn´es... se sont consid´rablement d´velopp´s et am´lior´s. De plus, le e e e e e e e succ`s des ERP a ´t´ favoris´ par la perte de cr´dibilit´ des informaticiens dans les entreprises e ee e e e a ` la fin des ann´es 80 et au d´but des ann´es 90. e e e 5

2.1.2

D´finition d’un ERP e

L’acronyme ERP signifie ” Enterprise Ressource Planning ” traduit en fran¸ais par Progic ciel de Gestion Int´gr´ ou PGI. ERP est le terme le plus couramment utilis´. Emanant d’un e e e concepteur unique, un ERP est un progiciel qui permet de g´rer l’ensemble des processus d’une e entreprise int´grant l’ensemble de ses fonctions comme la gestion des ressources humaines, la gese tion financi`re et comptable, l’aide a la decision, la vente, la distribution, l’approvisionnement, la e production ou encore du e-commerce. Le principe fondateur d’un ERP est de construire des applications informatiques correspondant aux diverses fonctions cit´es pr´c´demment de mani`re e e e e modulaire sachant que ces modules sont ind´pendants entre eux, tout en partageant une base de e donn´es unique et commune au sens logique. L’autre principe qui caract´rise un ERP est l’usage e e de ce qu’on appelle un moteur de workfow et qui permet, lorqu’une donn´e est enregistr´e dans e e le syst`me d’information(SI), de la propager dans les modules qui en ont l’utilit´, selon une proe e grammation pr´d´finie. Ainsi, on peut parler d’ERP lorsqu’on est en pr´sence d’un SI compos´ e e e e de plusieurs applications partageant une seule et mˆme base de donn´s, par le biais d’un syst`me e e e automatis´ pr´d´fini et ´ventuellement param´trable, un moteur de workfow. e e e e e

2.1.3

Pour quoi les ERP ?

Concr`tement, les avantages de la mise en place d’un ERP sont les suivants : e – L’int´grit´ et l’unicit´ du SI, c’est ` dire qu’un ERP permet une logique et une ergonomie e e e a unique ` travers sa base de donn´es, elle aussi unique au sens ” logique ”. Ceci se traduit par a e le fait qu’il peut exister plusieurs bases de donn´es ” physiques ” mais celles-ci respectent e la mˆme structure. En bref, un ERP permet d’´viter la redondance d’information entre e e diff´rents SI de l’entreprise. e – L’utilisateur a la possibilit´ de r´cup´rer des donn´es de mani`re imm´diate, ou encore e e e e e e de les enregistrer. Un avantage important, les mises ` jour dans la base de donn´es sont a e effectu´es en temps r´el et propag´es au modules concern´s. e e e e – Un ERP est un outil multilingue et multidevise, il est donc adapt´ au march´ mondial, en e e particulier aux multinationales. – Pas d’interface entre les modules, il y a synchronisation des traitements et optimisation des processus de gestion. De mˆme, la maintenance corrective est simplifi´e car celle-ci est e e assur´e directement par l’´diteur et non plus par le service informatique de l’entreprise. e e (Celui-ci garde n´anmoins sous sa responsabilit´ la maintenance ´volutive : am´lioration e e e e des fonctionnalit´s, ´volution des r`gles de gestion, etc.). e e e – Un ERP permet de maˆ ıtriser les stocks, ´l´ment important pour la plupart des entreprises ee car les stocks coˆtent chers. u Par cons´quent, les ERP g`rent et prennent en charge plusieurs p´riodes ( pour les exercices e e e comptables par exemple), plusieurs devises, plusieurs langues pour les utilisateurs et clients, plusieurs l´gislations, plusieurs axes d’analyse en informatique d´cisionnelle. Mais l’implantae e 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 offertes par le progiciel par rapport aux fonctions attendues), techniques, contractuels

6

entre l’´diteur et l’entreprise et enfin des risques ´conomiques du fait de l’investissement. e e

2.1.4

Les principaux ´diteurs des ERP e

On distingue deux types d’ERP : les ERP propri´taires, ´dit´s par des soci´t´s, ce qui e e e ee implique l’achat d’une licence, et les ERP open source qui sont ” gratuits ”. Les principaux ERP propri´taires du march´ sont : e e – SAP (leader mondial) – Oracle/Peoplesoft – SAGE ADONIX – Microsoft – SSA Global

Conclusion
Dans ce chapitre nous avons d´finit c’est quoi r´ellement les ERP. Ce chapitre sert donc ` e e a pr´senter th´oriquement notre sujet pour mieux comprendre le syst`me impl´ment´. e e e e e Le chapitre suivant sera consacr´ ` l’´tude des besoins fonctionnels et non fonctionnels auxquels ea e doit r´pondre notre application. e

7

Chapitre 3

Analyse et sp´cification des besoins e
Introduction
La r´ussite de tout projet d´pend de la qualit´ de son d´part. De ce fait, l’´tape de sp´cification e e e e e e constitue la base de d´part de notre travail. En outre, l’ad´quation de toute l’application ` e e a r´aliser, aux besoins des utilisateurs et aux traitements envisag´s au niveau de ses op´rations e e e assurera la r´ussite de l’application et son utilit´ future. Pour assurer ces objectifs, il est essentiel e e que nous parvenions ` une vue claire des diff´rents besoins escompt´s de notre projet. a e e Dans ce chapitre, nous ´tudions dans un premier temps les besoins fonctionnels et non e fonctionnels de notre syst`me, ensuite, une sp´cification formelle des besoins est pr´sent´e par e e e e des diagrammes de cas d’utilisation et de s´quences suivant la mod´lisation UML. e e

3.1

Identification des Utilisateurs

Notre application fournit une interaction avec plusieurs types d’acteurs, ils sont d´finis e comme ´tant des utilisateurs directs du syst`me exploitant le logiciel ` travers ses interfaces. e e a Nous identifions dans le cadre de ce projet six acteurs primaires : – Le directeur qui est l’utilisateur qui a tous les privil`ges au niveau de la comptabilit´ e e analytique et au niveau de la gestion des rˆles des autres acteurs. o – Le comptable qui a un acc`s limit´ au niveau de la comptabilit´ analytique. e e e – L’ing´nieur qui a tout les droits au niveau de la gestion de la base de connaissance. e – Le consultant simple qui a un acc`s limit´ au niveau de la gestion de la base de connaise e sance. – L’assistance du service qui aura l’acc`s pour ajouter ou modifier les documents des e ing´nieurs. e – Les responsables des d´partements qui ont des privil`ges sp´cifiques ` chaque d´partement. e e e a e Pour cela on va sp´cifier ci dessous les besoins que doit fournir le syst`me pour chaque e e cat´gorie d’utilisateurs. e

8

3.2

Les Exigences Sp´cifiques e

L’analyse du sujet, nous a permis de cerner les fonctionnalit´s ` la disposition de l’utilisae a teur.Les besoins ainsi d´gag´s ont ´t´ class´s en fonctionnels et non fonctionnels. e e ee e

3.2.1

Les besoins fonctionnels

– Le Directeur : Le syst`me doit permettre au directeur de : e – S’identifier pour acc´der ` la section de la comptabilit´. e a e – Consulter la liste d´taill´e des affaires et la r´partition des ing´nieurs correspondant par e e e e mois. – Effectuer des recherches selon des diff´rents crit`res : par date, par ing´nieur ou par e e e affaire. – Ajouter une nouvelle affaire si elle n’existe pas d´j`. ea – Visualiser les statistiques et les courbes d’´volution. e – T´l´charger un fichier EXCEL et mettre ` jour la base de donn´es. ee a e – Valider les documents t´l´charg´s. ee e – Saisir les informations du document de l’ing´nieur ` l’aide d’un formulaire. e a – Mettre ` jour les rˆles de chaque profile utilisant le syst`me. a o e – Le Comptable : Le syst`me doit permettre au comptable de : e – Consulter la liste d´taill´e des affaires et la r´partition des ing´nieurs correspondant par e e e e mois. – Effectuer des recherches selon des diff´rents crit`res . e e – S’identifier pour acc´der ` la section de la comptabilit´. e a e – Visualiser les statistiques et les courbes d’´volution. e – L’ing´nieur : Le syst`me doit permettre ` l’ing´nieur de : e e a e – S’identifier pour acc´der ` la section de la gestion de la base de connaissances. e a – Remplir les fiches de proc´dure (description, mot cl´..). e e – Consulter ses fiches de proc´dure remplies auparavant. e – Mettre ` jour une fiche de proc´dure. a e – Le consultant : Le syst`me doit permettre au consultant simple de : e – Rechercher une fiche de proc´dure. e – Consulter les fiches r´sultantes class´es. e e – Imprimer la fiche des proc´dures. e – Le responsable de d´partement : Le syst`me doit permettre au responsable de d´partement e e e de : – S’identifier pour acc´der ` la section de comptabilit´ analytique. e a e – Ajouter et mettre ˆ jour les profiles du d´partement. a e – L’assistance de service : Le syst`me doit permettre ` l’assistance de service de : e a 9

– S’identifier pour acc´der ` la section de comptabilit´ analytique. e a e – Ajouter des documents des ing´nieurs. e – Valider les documents des ing´nieurs. e

3.3

Les exigences non sp´cifiques e

Pour le bon fonctionnement de notre application nous avons d´gag´ les besoins non fonce e tionnels suivants : – la fiabilit´ : le syst`me doit ˆtre disponible ` tout moment pour l’utilisateur, avec un acc`s e e e a e s´curis´ par la d´finition d’un login et d’un mot de passe. e e e – la portabilit´ : le syst`me doit tourner sur plusieurs plates-formes. e e – la convivialit´ : le syst`me doit pr´senter une interface compr´hensible, facile ` manipuler e e e e a ce qui nous permettera d’accroˆ la rentabilit´ et l’efficacit´ de notre syst`me. ıtre e e e

10

3.4

Les cas d’utilisation

L’´tude approfondie des sp´cifications permet de d´gager plusieurs cas d’utilisation. Un cas e e e d’utilisation d´crit une utilisation du syst`me par un acteur particulier.Ce qui revient ` pr´senter e e a e les besois fonctionnels de fa¸on formelle. c 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’ing´nieur e

Fig. 3.3 – Cas d’utilisation de l’ing´nieur e

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 d´partement e

Fig. 3.6 – Cas d’utilisation du responsable de d´partement e

3.4.1

Les diagrammes de s´quences e

les diagrammes de s´quences peuvent servir ` illustrer un cas d’utilisation d´crit pr´c´demment. e a e e e C’est un moyen semi formel de capturer le comportement de tous les objets et acteurs impliqu´s e dans un cas d’utilisation. Dans ce qui suit nous allons pr´senter quelques sc´narios de notre e e applications. Diagramme de s´quence pour l’ajout d’un fichier EXCEL e

Fig. 3.7 – Ajout d’un fichier EXCEL 15

Diagramme de s´quence pour la consultation des statistiques e

Fig. 3.8 – Consultation des statistiques

16

Diagramme de s´quence pour la recherche de proc´dures e e

Fig. 3.9 – Recherche de proc´dures e

Conclusion
Dans ce chapitre, nous venons de pr´senter une analyse globale de l’application tout en e sp´cifiant les besoins fonctionnels et les contraintes que notre travail doit satisfaire et respecter. e La conception et ses d´tails seront d´crits dans le prochain chapitre. e e

17

Chapitre 4

Solutions techniques possibles et choix retenus
Introduction
Ce chapitre aborde une ´tude comparative entre les diff´rentes technologies existantes et e e prouve le choix de l’environnement de d´veloppement ainsi que le syst`me de gestion de la base e e de donn´es. e

4.1
4.1.1

Solutions techniques possibles
Technologie de d´veloppement e

Microsoft .NET Pr´sentation : La plate-forme Microsoft .NET est une solution compl`te pour d´velopper, e e e d´ployer et ex´cuter des application de tous types, y compris des services web. Fond´e sur e e e des standards de l’industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen simple et puissant pour impl´menter la coop´ration des services logiciels entre eux, quelle que e e soit leur localisation, leur impl´m´ntation technique, qu’ils soient internes ou externes, existant e e ou ` inventer. a Les composants de .NET : A travers les diff´rentes annonces de Microsoft depuis son e lancement, les composants de .NET semblent s’organiser de la mani`re suivante : e 1. Pour la couche pr´sentation et logique de pr´sentation : e e – ASP .NET : c’est une nouvelle version d’ASP (Active Server Pages) qui supporte une v´ritable compilation en IL, alors qu’ASP ´tait interpr´t´ auparavant. On peut e e ee ´galement ´crire les pages ASP dans n’importe quel langage disposant d’un compilateur e e IL. – WinForms et WebForms : ils pr´sentent un ensemble de composants graphiques accese sibles dans Visual Studio .NET . 2. Pour la couche logique m´tier et objets interm´diaires : e e

18

– CLR ( Common Language Runtime) : c’est un environnement d’ex´cution commun e qui ex´cute un bytecode ´crit dans un langage interm´diaire (Microsoft intermediate e e e Language) – C# : c’est nouveau langage orient´ objet destin´ ` faciliter la programmation dans .NET, e ea notamment les composants, qui int`gre des ´l´ments de C, C++ et de Java en apportant e ee quelques innovations comme les m´ta-donn´es. e e – Langages quelconques qui peuvent ˆtre compil´s en IL et ex´cut´s par le CLR si un e e e e compilateur IL existe pour ce dernier. – Une grande biblioth`que de composants et d’objets de base accessibles par le CLR, e qui fournissent les fondations pour ´crire rapidement un programme (acc`s r´seau, grae e e phisme, acc`s aux donn´es ). e e – Visual Studio .NET : c’est une r´fonte de l’environnement Visual Studio et de Visual e INterDev permettant aussi bien le d´veloppement d’application et de composant clase sique. – Un support de terminaux mobiles avec une version compacte de l’environnement .NET . 3. Pour la couche de donn´es : e – ADO .NET : c’est une nouvelle g´n´ration de composants d’acc`s aux bases de donn´es e e e e ADO qui utilise XML et SOAP pour l’´change de donn´es. e e Les avantages de .NET : La plate-forme .NET comprend un mod`le de programmation e homog`ne et des outils de d´veloppement multi langages qui acc`l`rent le d´veloppement et e e ee e l’int´gration de Services Web et de tout autre type d’application multi langages et int´grant e e les standards, la plate-forme .NET laisse au d´veloppeur toute libert´ de choisir le langage de e e d´veloppement. D’autre part son support des stabndards et son approche moderne, la platee forme .NET est parfaitement adapt´e ` la construction d’une architecture orient´e services. La e a e plate-forme .NET offre donc plusieurs avantages : – Un d´veloppement sp´cifique grˆce au moteur CLR . e e a – Une structure multi langages et extensible . – Une ex´cution multi plate-forme . e – Une productivit´ comparable ` celle des environnements Client/Serveur comme Powere a Builder ou Delphi . – Un mod`le de programmation simple et coh´rent . e e – Une installation automatis´e des Web Services . e J2EE Pr´sentation : J2EE est logiquement destin´ aux gros syst`mes d’entreprise. Les logiciels e e e employ´s ` ce niveau ne fonctionnent pas sur un simple PC mais requi`re une puissance beaue a e coup plus importante. Pour cette raison, les applications doivent ˆtre constitu´es de plusieurs e e composants pouvant ˆtre d´ploy´s sur des plate-formes multiples afin de disposer de la puissance e e e de calcul n´cessaire. C’est la raison d’ˆtre des applications distribu´es. e e e J2EE est une collection de composants, de conteneurs et de services permettant de cr´er et e de d´ployer des applications distribu´es au sein d’une architecture standardis´e. e e e 19

Les composants de J2EE : J2EE fournit une gamme d’outils et d’API afin de concevoir facilement les diff´rentes couches. e 1. Pour la couche Pr´sentation et logique de pr´sentation : e e – Java Servlet : Une servlet est un programme ´crit en JAVA qui tourne sur la machine e du serveur J2EE. Une servlet est charg´e lorsque le serveur est mis en route ou lorsque e le premier client fait appel aux services de la servlet.Le serveur Web re¸oit une demande c adress´e ` une servlet sous la forme d’une requˆte HTTP. Il transmet la requˆte ` la e a e e a servlet concern´e, puis renvoie la r´ponse fournie par celle du client . La servlet re¸oit e e c ´galement les param`tres de la requˆte envoy´e par le client. Elle peut alors effectuer e e e e toutes les op´rations n´cessaires pour construire la r´ponse avant de renvoyer celle-ci e e e sous forme de code HTML. Une fois charg´e, une servlet reste active dans l’attente de e nouvelles requˆtes. Une servlet doit soit impl´menter l’interface javax.servlet.Servlet ou e e ´tendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet. e – Java Server Pages (JSP) : cette extension permet de valoriser davantage les applications web avec la plate-forme J2EE en permettant le d´veloppement d’applications web bas´es e e sur ce mod`le ; les JSP permettent grˆce au moteur de servlet de produire facilement e a des pages HTML. – Struts : Jakarta Struts est un projet d’Appache software foundation qui a pour but de fournir un cadre standard de d´veloppement web en java respectant le mod`le d’archie e tecture MVC (Model-View-Controller). Il fournit le minimum de r`gles pour construire e des applications web professionnelles. – Java Server Faces (JSF) : Java Server Faces est un framework d’interface utilisateur pour les applications web, bas´ sur les technologies JSP et Servlets. Le but de JSF e est d’accroˆ ıtre la productivit´ des d´veloppeurs dans le d´veloppement des interfaces e e e utilisateur tout en facilitant leur maintenance. JSF permet de r´concilier deux points e de vues diam´tralement oppos´s en fornissant un framework bas´ sur une abstraction e e e compl`te des m´canismes d’internet tout en garantissant une totale maˆ e e ıtrise du cycle de vie du traitement d’une requˆte. JSF permet : e – une s´paration nette entre la couche de pr´sentation et les autres couches. e e – le mapping HTML/Objet. – un mod`le riche de composants graphiques r´utilisables. e e – un mod`le riche de composants graphiques r´utilisables. e e – une gestion de l’´tat de l’interface entre les diff´rentes requˆtes. e e e – une liaison simple entre les actions cˆt´ client de l’utilisateur et le code Java corresoe pondant cˆt´ serveur. oe – la cr´ation de composants customs grˆce ` une API. e a a – le support de diff´rents clients (HTML, WML, XML, ...) grˆce ` la s´paration des e a a e probl´matiques de construction de l’interface et du rendu de cette interface. e

20

Fig. 4.1 – Architecture de JSF – Spring : C’est un framework ayant pour but de rendre facile le d´veloppement des e applications web tout en augmentant la consistance et la productivit´. e 2. Pour la couche logique m´tier et objet interm´diaires : e e – Les EJB : Ce sont des composants Java pour des applications distribu´es multi niveaux. e Cette extension fournit un moyen standard pour d´finir les composants cˆt´ serveur e oe et d´finit une vaste infrastructure d’ex´cution pour l’h´bergement des composants cˆt´ e e e oe serveur. – Les JavaBeans : Selon la sp´cification des Javabeans, une Bean est un composant logiciel e r´utilisable pouvant ˆtre manipul´ visuellement dans un outil de construction (builder e e e tool). 3. Pour la couche de donn´es : e – JDBC Connector : JDBC (l’acronyme de JAVA Data Base Connectivity) est une API JAVA permettant d’acc´der ` es base de donn´es, de fa¸on ind´pendante de la base e a e c e utilis´e, ` partir d’une application JAVA. La proc´dure sera la mˆme quelle que soit la e a e e base de donn´es choisie. JDBC d´finit une API de bas niveau d´sign´e pour supporter les e e e e fonctionnalit´s basiques de SQL ind´pendement de toute impl´mentation SQl sp´cifique. e e e e – 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 donn´es : cr´ation et mise ` jour. IL utilise un langage simple e e a pour l’interrogation de la base de donn´es appel´ HQL (Hibernate Query Language) et e e qui fournit une couche d’abstraction SQL.

21

Fig. 4.2 – Architecture de Hibernate

Les avantages de J2EE : L’approche multi niveaux adopt´e par la plate-forme J2EE offre e plusieurs avantages : – Elle r´duit la compl´xit´ du d´veloppement distribu´ avec une architecture simplifi´e et le e e e e e e partage de la charge de travail. – C’est une solution hautement ´volutive qui permet le d´veloppement des syst`mes satise e e faisant de nombreux besoins rapidement modifiables. – Les nouvelles applications peuvent s’int´grer correctement avec les syst`mes d’informations e e existants. – La s´curit´ est am´lior´e. e e e e – Les d´veloppeurs peuvent choisir parmi une diversit´ d’outils de d´veloppement et de e e e composants pour d´velopper les applications requises. e – L’´quipe de d´veloppement peut s´lectionner les meilleurs solutions pour leurs besoins, e e e sans ˆtre verrouill´e par l’offre du fournisseur unique. e e – Tous les composants sont gratuits. Comparaison entre J2EE et .NET Dans cette section, nous allons d´gager les principales diff´rences entre la technologies J2EE e e de Sun et la technologie .NET de Microsoft. En fait, nous avons limit´ notre ´tude sur ces e e deux technologies car ils sont les plus appr´ci´es au sein des entreprises qui ambitionnent avoir e e des applications robustes, portables, complexes et s´curis´es, d’autant plus qu’elles traitent des e e donn´es confidentielles, et font appels aux technologies les plus modernes. Le tableau suivant e expose les crit`res sur lesquels se basera notre choix technologique. e

22

.NET Langages Services Pr´sentation e Interpr`te e Composants graphiques Acc`s ` la BD e a Technologie C#,multi-langage BCL ASP .NET CLR WinForms, WebForms ADO .NET Produit

J2EE Java Java Core API Servlet, JSP JVM Swing JDBC, Hibernate, iBatis Standard

Tab. 4.1 – Tableau comparatif .NET et J2EE

4.1.2 4.1.3

Environnement de d´veloppement e Gestion de la base de donn´es e

Oracle DataBase Oracle est un SGBDR ´dit´ par la soci´t´ du mˆme nom Oracle Corporation leader mondial e e ee e en base de donn´es.Oracle peut assurer entre autres fonctionnalit´s : e e – La d´finition et la manipulation des donn´es e e – La coh´rence des donn´es. e e – La confidentialit´ des donn´es. e e – L’int´grit´ des donn´es. e e e MySQL MySQL a pour origine l’application mSQL. Cette application permettait de ce connecter ` a des tables en utilisant des routines bas niveau. Cependant, apr`s quelques tests, les d´veloppeurs e e sont arriv´s ` la conclusion que mSQL n’´tait pas assez rapide et flexible pour leurs besoins. Le e a e serveur de bases de donn´es MySQL est tr`s rapide, able et facile ` utiliser. Il dispose aussi de e e a fonctionnalit´s pratiques, d´velopp´es en coop´ration avec les utilisateurs. e e e e Les principales fonctionnalit´s qu’offre MySQL sont : e – Fonctionne sur de nombreuses plate-formes. – Dispose d’API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl. – Compl`tement multi-thread´, grˆce aux threads du noyau. Cela signi e qu’on peut l’utiliser e e a facilement sur un serveur avec plusieurs processeurs. – Tables B-tree tr`s rapide, avec compression d’index. e – Syst`me l’allocation m´moire tr`s rapide, exploitant les threads. e e e – Tables en m´moire, pour r´aliser des tables temporaires. e e – Les fonctions SQL sont impl´ment´es grˆce ` une librairie de classes optimis´es, qui sont e e a a e aussi rapides que possible . PostgreSQL PostgreSQL est un SGBD relationnel objet Open Source impl´ment´ par l’universit´ de Bere e e keley. Les fonctions cl´s du mod`le objet de PostgreSQL sont les classes, l’h´ritage et la surcharge. e e e

23

PostgreSQL est un logiciel ” modulaire ” poss´dant un langage d’´criture de proc´dures similaire e e e a ` celui d’Oracle mais ´galement d’autres interfaces de programmation. Voici les fonctions cl´s e e du mod`le orient´ objet de PostgreSQL : e e – Les classes : Une classe correspond ` un ensemble d’objets poss´dant un identificateur a e unique. – L’h´ritage : La notion d’h´ritage correspond ` une organisation hi´rarchique des tables. e e a e Par exemple, si deux tables se trouvent dans une relation parent/enfant, les informations contenues dans la table parent sont ´galement disponible dans la table enfant. e – La surcharge : On parle de ”surcharge de fonction” lorsqu’une fonction peut ˆtre d´finie e e plusieurs fois avec des param`tres diff´rents. e e

4.2

Choix retenus

La claret´ de l’architecture qu’elle propose ainsi que la multitude des IDE qui peuvent la e supporter et sa gratitude, la technologie J2EE a ´t´ le choix Judicieux pour le d´veloppement de ee e notre application. L’IDE surlequel nous avons choisit de d´velopper notre application est l’IDE e Eclipse. Une base de donn´e MySQL est celle qui va ˆtre impl´menter pour g´rer les donn´es e e e e e n´cessaire ` l’application. e a

Conclusion
Apr`s cette ´tude nous avons d´cid´ de choisir la plate-forme J2EE comme environnement de e e e e d´veloppement (donc Java comme langage de programmation), MySQL pour l’impl´mentation e e de la base de donn´es et hibernate pour la couche persistence de donn´es. Le chapitre suivant e e aborde en d´tail la conception de l’application ` r´aliser. e a e

24

Chapitre 5

Conception
Introduction
Dans ce pr´sent chapitre nous allons entamer une partie cruciale du d´veloppement logiciel e e et qui constitue un pont entre la sp´cification et la r´alisation. Elle comporte la conception de e e l’application ainsi que la conception de la base de donn´es. e

5.1

Conception g´n´rale e e

Le travail ` r´aliser est d´compos´ en deux module ind´pendants ` savoir le module de la a e e e e a comptabilit´ analytique et le module le gestion de la base de connaissances. e

5.1.1

La comptabilit´ analytique : e

Ce module s’int´gre dans la partie de gestion financi`re de l’ERP ` r´aliser. Elle automatise e e a e au premier lieu la tˆche de pointage horaire du personnel de l’entreprise et facilite, en second lieu, a la tˆche du comptable pour la r´alisation des statistiques ´l´mentaires et crois´es et y dessiner a e ee e les diagrammes correspondnat afin de les bien pr´senter au responsable sup´rieur. Ce module, e e a ` part son rˆle pour r´duire les temps de r´alisation des tˆches cit´es, il permet d’´conomiser o e e a e e l’argent puisque l’ˆtre humain n’interviendra pas dans le m´canisme. e e

5.1.2

La gestion de la base de connaissances :

Ce module fait parti de la gestion de la productivit´ de l’entreprise. en effet il sert comme un e puissant outil pour la constitution d’un ensemble de connaissances dans les domaines d’activit´ e de l’entreprise afin de faciliter la r´paration, la mise ` niveau ou l’´limination d’une proc´dure e a e e de travail.

5.2

Conception d´taill´e e e

La conception d´taill´e vise ` transformer le mod`le d’analyse (sp´cification : haut niveau e e a e e d’abstraction) en un mod`le concrˆt, de bas niveau d’abstraction et ` partir duquel le programe e a meur peut directement impl´menter le syst`me. e e

25

5.2.1

Architecture de l’application

La navigation entre les diff´rentes parties de notre application est pr´sent´e par la figure e e e ci-dessous :

Fig. 5.1 – Architecture de l’application

5.2.2

Diagrammes de Classes

Le diagramme de classes permet de d´crire la structure statique du syst`me ` l’aide des e e a classes et des relations.

26

Fig. 5.2 – Diagramme de classes de l’application

27

5.2.3

Diagrammes de s´quences d´taill´s e e e

Diagramme de s´quence pour l’ajout d’un fichier EXCEL e Le diagramme suivant pr´sente comment un ing´nieur peut ajouter un fichier EXCEL pour le e e prendre en compte par l’administration de l’entreprise.

Fig. 5.3 – Ajout d’un fichier EXCEL

28

Diagramme de s´quence pour la consultation des statistiques e

Fig. 5.4 – Consultation des statistique

29

Diagramme de s´quence pour la recherche de proc´dures e e

Fig. 5.5 – Recherche de proc´dures e

30

5.2.4

Conception de la base de donn´es e

Le mod`le relationnel de donn´es est un mod`le de donn´e comme d’autres existants ayant e e e e pour but de d´crire le monde r´el ` partir des informations et des donn´es qu’on peut en extraire e e a e et se diff´rencient par la nature des associations qu’ils permettent de mod´liser. L’objectif essene e tiel du mod`le relationnel ´tait d’accroˆ l’ind´pendance vis-`-vis du niveau de repr´sentation e e ıtre e a e des donn´es. Du point de vue utilisateur, une base de donn´es peut ˆtre consid´r´e comme un e e e ee ensemble de tables manipulables par des langages de haut niveau dont la caract´ristique princie pale est d’ˆtre des langages non proc´duraux. Pour ces raisons nous avons choisi d’utiliser une e e base de donn´es relationnelle. e A ce niveau de cette application et tout en consid´rant les besoins d´j` sp´cifi´s nous avons e ea e e envisag´ un certain nombre de tables pour enregistrer les donn´es n´cessaires pour la gestion du e e e site. Les tables utilis´es et les relations qui les inter-relient sont donn´es par la figure 5.6 e e

Fig. 5.6 – Conception de la base de donn´es e

31

Coclusion
Etant donn´ les besoins des utilisateurs de notre applications, la phase de conception vient e pour permettre la d´termination des diff´rents objets contribuant ` assurer les fonctionnalit´s e e a e souhait´es. Cette phase est une pr´paration ` la phase du codage garantissant une organisation e e a claire et pr´cise ainsi qu’une facilit´ d’impl´mentation des classes invoqu´es, des structures de e e e e donn´es utilis´es et les relations qui existent entre les diff´rentes classes. Nous essayons dans e e e le chapitre r´alisation d’impl´menter les diff´rentes classes et de montrer les fonctionnalit´s e e e e r´alis´es suite ` cette impl´mentation. e e a e

32

Chapitre 6

R´alisation e
Apr`s avoir achev´ l’´tape de conception de l’application, nous entamons dans ce chapitre e e e la phase de r´alisation. Nous allons pr´senter, en premier lieu, l’environnement de travail utilis´ e e e pour le d´veloppement de l’application. Ensuite, nous allons donner un aper¸u sur le travail e c accompli ` travers des capture d’´cran. Enfin, nous montrerons le chronogramme de la r´alisation a e e du projet.

6.1
6.1.1

Environnement de travail
Environnement mat´riel e

Afin de r´aliser ce site web dans les conditions les plus favorables, nous avons mis en dispoe sition un ordinateur ayant la configuration suivante : Processeur : Intel(R) Pentium(R) M 3.2GHz Disque dur : 120Gb RAM :1.256GB

6.1.2
Eclipse

Environnement logiciel

Eclipse est un environnement de d´veloppement int´gr´ (Integrated Development Envie e e ronment) dont le but est de fournir une plate-forme modulaire pour permettre de r´aliser e des d´veloppements informatiques. I.B.M. est ` l’origine du d´veloppement d’Eclipse qui est e a e d’ailleurs toujours le coeur de son outil Websphere Studio Workbench (WSW), lui mˆme ` la e a base de la famille des derniers outils de d´veloppement en Java d’I.B.M. Tout le code d’Eclipse e a ´t´ donn´ ` la communaut´ par I.B.M afin de poursuivre son d´veloppement. ee ea e e Eclipse utilise ´norm´ment le concept de modules nomm´s ”Plug-ins” dans son architecture. e e e D’ailleurs, hormis le noyau de la plate-forme nomm´ ”Runtime”, tout le reste de la plate-forme e est d´velopp´ sous la forme de Plug- ins. Ce concept permet de fournir un m´canisme pour e e e l’extension de la plate-forme et ainsi fournir la possibilit´ ` des tiers de d´velopper des fonctionea e nalit´s qui ne sont pas fournies en standard par Eclipse. e 33

Tomcat : Tomcat est un serveur d’application totalemet ´crit en java. A partir de la version 5.0 il e impl´mentait les sp´cifications 2.4 des JavaServlet et 2.0 des JSP. e e Tomcat a ´t´ d´velopp´ en open source au sein du projet Apache Jakarta, dont le but est de ee e e fournir des solutions serveur bas´es sur la plate-forme Java, de qualit´ identique aux applications e e commerciales.Tomcat est un moteur d’ex´cution pour les servlets et les pages JSP. Il prend en e charge la partie dynamique du site et laisse la partie statique au serveur web.

6.2

Travail r´alis´ e e

A cette ´tape du nous donnons les captures d’´cran relatives aux pages des principales e e fonctions r´alis´es par l’application. e e

6.2.1

Page d’authentification des utilisateurs

Fig. 6.1 – Identification des utilisateurs

34

6.2.2

Page d’ajout d’un document EXCEL

Fig. 6.2 – Ajout d’un fichier

6.2.3

Page de validation d’un documents EXCEL

Fig. 6.3 – Validation du document EXCEL

35

6.2.4

Recherche de fiches de proc´dures e

Fig. 6.4 – Recherche de fiche de proc´dure e

6.2.5

R´sultats de la recherche e

Fig. 6.5 – R´sultats de la recherche e

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 n´cessaire de tracer un diagramme qui d´crit la r´partition temporelle des tˆches du e e e a travail durant deux mois afin de montrer les diff´rentes phases par lesquelles notre projet a pass´. e e – Documentation et ´tudes th´orique : elle consiste ` rechercher une documentation sur le e e a sujet et ` ´tudier les objectifs g´n´raux du stage. ae e e – Sp´cification et analyse de besoins : elle consiste ` ´tudier l’´tat actuel du processus de e ae e travail de l’entreprise ainsi que ses besoins r´els. e – Conception : elle vise ` mod´liser le syst`me selon une vue bien claire. a e e – Impl´mentation : elle s’occupe du d´veloppement du codes des diff´rentes fonctionalit´s e e e e du syst`me comme mod´lis´ dans la conception. e e e – R´daction du rapport : elle collecte toutes les informations n´cessaires et autoris´es ` ˆtre e e e ae publi´es. e Le chronogramme suivant donne la r´partition de ces diff´rentes phases : e e

Fig. 6.8 – Chronogramme

38

Conclusion et perspectives Avant de commencer le stage, nous en attendions essentillement ` trois choses : travailler sur a
un produit d’avenir au moins en tunisie (les ERP), recueillir une exp´rience et des comp´tences e e professionnelles et d´couvrir le fonctionnement des ´quipes de d´veloppement au sein des entree e e prises informatiques. L’objectif de ce stage ´tait de concevoir et de d´velopper deux modules faisant parti d’un e e ERP destin´ ` une entreprise class´e de PME. ea e Il a ´t´ aussi b´n´fique aussi bien sur le plan th´orique que sur le plan pratique. En effet sur ee e e e le plan pratique ce projet nous a donn´ une occasion de d´couvrir le framework JSF pour le e e d´veloppement des applications web, et d’am´liorer nos connaissances sur la gestion des bases e e de donn´es. Sur le plan th´orique il nous a permis une familiarisation avec les notions et les aue e 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 d´veloppement du reste des modules de l’ERP et son int´gration dans e e l’environnement constituons le sujet du projet de fin d’´tudes afin de voir un produit complet e pouvant automatiser plusieurs tˆche dans les petites et moyennes entreprises. a

39

Bibliographie
´ [1] Olivier Debas, Christine Deffaix 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. D´veloppement Web avec J2EE .O’Reilly,2005 e

40

Netographie
[N1] [N2] [N3] [N4] [N2] [N3] http://www.developpez.com http://www.coreservlets.com/JSF-Tutorial/ http://www.jsftoolbox.com/documentation/ http://www.roseindia.net/ http://www.myfacescomponent.com http://www.tomahawkcomponent.com consult´ le 01 juillet 2008 e consult´ le 09 juillet 2008 e consult´ le 10 juillet 2008 e consult´ le 27 juillet 2008 e consult´ le 20 aoˆt 2008 e u consult´ le 21 aoˆt 2008 e u

41

Glossaire
Dans ce glossaire nous citons quelques termes n´cessaires pour la compr´hension du rapport. e e 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´ e PME : Petites et Moyennes Entreprises SI : Syst`me d’Information e SQL : Structured Query Language UML : Unified Modeling Language

42

Annexe A

Les Architectures Logicielles
Architecture Simple tiers
Les applications bureautiques sont con¸ues pour fonctionner sur un ordinateur unique. Toutes c les services fournis par l’application - interface utilisateur, persistance des donn´es (sauvegarde e dans des fichiers propri´taires) et logique de traitement de ces donn´es - r´sident sur la mˆme e e e e machine et sont inclus dans l’application.

Fig. A.1 – Architecture Simple Tiers.

Architecture deux tiers
Selon l’architecture deux tiers les traitements sont r´partis entre le client repr´sent´ par une e e e station de travail utilisateur et le serveur repr´sent´ par un mainframe ou un serveur puissant. e e Le client prend en charge l’ensemble des taches li´es ` la pr´sentation, ` la logique applicative e a e a ainsi qu’une grande partie de la logique m´tier. Quant au serveur, son rˆle est d’h´berger les e o e donn´es du syst`me d’information et de traiter les requˆtes en provenance du client. e e e Un des inconv´nient de l’architecture deux-tiers est que la logique charg´e de la manipulation e e des donn´es et de l’application des r`gles m´tiers aff´rentes est incluse dans l’application ellee e e e mˆme. Cela pose probl`me lorsque plusieurs applications doivent partager l’acc`s ` une base de e e e a donn´es. e

Architecture trois tiers
C’est un mod`le logique d’architecture applicative qui vise ` s´parer tr`s nettement trois e a e e couches logicielles au sein d’un mˆme syst`me. e e

43

Fig. A.2 – Architecture Deux Tiers

Fig. A.3 – Architecture Trois Tiers Selon ce mod`le, toute la logique m´tier est extraite de l’application cliente. Celle-ci n’est e e plus responsable que de la pr´sentation de l’interface ` l’utilisateur et de la communication avec e a le tiers m´dian. Elle n’est plus responsable de l’application des r`gles. Son rˆle est r´duit ` la e e o e a couche pr´sentation. e

La plate forme J2EE
J2EE est l’acronyme de Java 2 Entreprise Edition. Cette ´dition est d´di´e ` la r´alisation e e e a e d’applications pour entreprises. J2EE est bas´ sur J2SE (Java 2 Standard Edition) qui contient e les API de base de Java. Depuis sa version 5, J2EE est renomm´ Java EE (Enterprise Edition). e

Notion de J2EE
J2EE est logiquement destin´ aux gros syst`mes d’entreprise. Les logiciels employ´s ` ce nie e e a veau ne fonctionne pas sur un simple PC mais requi`re une puissance beaucoup plus importante. e Pour cette raison, les applications doivent ˆtre constitu´es de plusieurs composants pouvant ˆtre e e e d´ploy´s sur des plate-formes multiples afin de disposer de la puissance de calcul n´cessaire. e e e C’est la raison d’ˆtre des applications distribu´es. e e J2EE est une collection de composants, de conteneurs et de services permettant de cr´er et e de d´ployer des applications distribu´es au sein d’une architecture standardis´e. e e e

44

Les Conteneurs
Les conteneurs sont les ´l´ments fondamentaux de l’architecture J2EE. Les conteneurs fournis ee par J2EE sont de mˆme type. Ils fournissent une interface parfaitement d´finie ainsi qu’un e e ensemble de services permettant aux d´veloppeurs d’applications de se concentrer sur la logique e m´tier ` mettre en oeuvre pour r´soudre le probl`me qu’ils ont ` traiter, sans qu’ils aient ` e a e e a a se pr´ocuper de toute l’infrastructure interne. Les conteneurs s’occupent de toutes les tˆches e a fastidieuses li´es au d´marrage des services sur le serveur, ` l’activation de la logique applicative, e e a la gestion des protocoles de communication intrins`que ainsi qu’` la lib´ration des ressources e a e utilis´es. e

Les Servlets
Une servlet est un programme ´crit en JAVA qui tourne sur la machine du serveur J2EE. e Une servlet est charg´e lorsque le serveur est mis en route ou lorsque le premier client fait appel e aux services de la servlet.Le serveur Web re¸oit une demande adress´e ` une servlet sous la c e a forme d’une requˆte HTTP. Il transmet la requˆte ` la servlet concern´e, puis renvoie la r´ponse e e a e e fournie par celle du client . La servlet re¸oit ´galement les param`tres de la requˆte envoy´e par le c e e e e client. Elle peut alors effectuer toutes les op´rations n´cessaires pour construire la r´ponse avant e e e de renvoyer celle-ci sous forme de code HTML. Une fois charg´e, une servlet reste active dans e l’attente de nouvelles requˆtes. Une servlet doit soit impl´menter l’interface javax.servlet.Servlet e e ou ´tendre soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet. e

Fig. A.4 – Servlet ´tendant la classe javax.servlet.http.HttpServlet e

Les pages Jsp
Cr´er des servlets consiste ` construire des composants Java capables de produire du code e a HTML. Dans de nombreux cas, cela fonctionne sans probl`me. Toutefois, il n’est pas facile, pour e les personnes charg´es de concevoir l’aspect visuel des pages Web, de manipuler du code Java, e auquel elles n’ont probablement pas ´t´ form´es. C’est la raison d’ˆtre des JavaServer Pages. ee e e Les JSP sont des documents de type texte, contenant du code HTML ainsi que des scriptlets (et/ou des expressions), c’est-`-dire des morceaux de code Java. a

45

Fig. A.5 – Les pages JSP dans une application J2EE.

Les JavaBeans
Selon la sp´cification des Javabeans, une Bean est un composant logiciel r´utilisable pouvant e e ˆtre manipul´ visuellement dans un outil de construction (builder tool). Un composant poss`de : e e e – des propri´t´s persistantes ee – des ´v´nements reconnus e e – des m´thodes de traitement des ´v´nements e e e

Les Serveurs D’application
Le serveur d’application est l’environnement d’ex´cution des applications cˆt´ serveur. Il e oe prend en charge l’ensemble des fonctionnalit´s permettant ` plusieurs utilisateurs d’exploiter e a une mˆme application. Parmi ces fonctionnalit´s nous pouvons citer : e e – Gestion de la session utilisateur : c’est le fait de conserver pour chaque utilisateur un contexte qui lui est propre, et cela se fait g´n´ralement en g´n´rant un identifiant unique e e e e pour chaque client et en le transmettant lors de chaque ´change HTTP. e – Gestion des mont´es en charge et reprise sur incident : afin de g´rer toujours plus d’utie e lisateurs, le serveur d’application doit pouvoir se d´ployer sur plusieurs machines et, e ´ventuellement, offrir des possibilit´s de reprise sur incident. e e – Ouverture sur plusieurs sources de donn´es : pour rendre accessible les donn´es de l’applie e cation, le serveur d’application doit pouvoir acc´der ` de nombreuses sources de donn´es. e a e

Le Modele MVC
Le mod`le MVC (Model View Controler) a ´t´ initialement d´velopp´ pour le langage Smalle ee e e talk dans le but de mieux structurer une application avec une interface graphique. Ce mod`le est un concept d’architecture qui propose une s´paration en trois entit´s des e e e donn´es, des traitements et de l’interface : e

46

Fig. A.6 – Le mod`le MVC. e – Le Mod`le repr´sente les donn´es de l’application g´n´ralement stock´es dans une base de e e e e e e donn´es. e – La Vue correspond ` l’IHM (Interface Homme Machine). a – Le Contrˆleur assure les ´changes entre la vue et le mod`le notamment grˆce ` des como e e a a posants m´tiers. e L’utilisation du mod`le MVC rend un peu plus compliqu´ le d´veloppement de l’application e e e qui le met en oeuvre mais il permet une meilleure structuration de l’application. Le principal d´faut du mod`le MVC est le nombre de servlets ` d´velopper pour une application. Comme e e a e rem`de ` ce probl`me, le mod`le MVC2 s’est impos´. En effet cette version du mod`le propose e a e e e e de n’utiliser qu’une seule servlet comme contrˆleur de tiute l’application. o

47

Sign up to vote on this title
UsefulNot useful