Rapport De Stage Réalisation D'un Erp

Table des mati` eres 1 Pr´ esentation G´ en´ erale 1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Pr´esentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3

2 Etat de l’art 2.1 Les ERP . . . . . . . . . . . . . . . . . . 2.1.1 Historique . . . . . . . . . . . . . 2.1.2 D´efinition d’un ERP . . . . . . . 2.1.3 Pour quoi les ERP ? . . . . . . . 2.1.4 Les principaux ´editeurs des ERP

. . . . .

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

3 Analyse et sp´ ecification des besoins 3.1 Identification des Utilisateurs . . . . 3.2 Les Exigences Sp´ecifiques . . . . . . 3.2.1 Les besoins fonctionnels . . . 3.3 Les exigences non sp´ecifiques . . . . 3.4 Les cas d’utilisation . . . . . . . . . 3.4.1 Les diagrammes de s´equences

. . . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . .

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

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . .

. . . . .

. . . . . . . .

6 R´ ealisation 6.1 Environnement de travail . . . . . . . . . . . . . . . . . . 6.1.1 Environnement mat´eriel . . . . . . . . . . . . . . . 6.1.2 Environnement logiciel . . . . . . . . . . . . . . . . 6.2 Travail r´ealis´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´edures . . . . . . . . . 6.2.5 R´esultats de la recherche . . . . . . . . . . . . . . 6.2.6 Consultation des statistiques . . . . . . . . . . . . 6.2.7 Ajout de nouveaux utilisateurs ou administrateurs 6.3 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

33 33 33 33 34 34 35 35 36 36 37 37 38

Netographie

41

A Annexe

43

ii

Table des figures 1.1

Feuille d’affectation de temps pass´es . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Cas d’utilisation du directeur . . . . . . . . . . . Cas d’utilisation du comptable . . . . . . . . . . Cas d’utilisation de l’ing´enieur . . . . . . . . . . Cas d’utilisation du consultant simlpe . . . . . . Cas d’utilisation de l’assistant de service . . . . . Cas d’utilisation du responsable de d´epartement Ajout d’un fichier EXCEL . . . . . . . . . . . . . Consultation des statistiques . . . . . . . . . . . Recherche de proc´edures . . . . . . . . . . . . . .

. . . . . . . . .

11 12 13 14 14 15 15 16 17

4.1 4.2

Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture de Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22

5.1 5.2 5.3 5.4 5.5 5.6

Architecture de l’application . . . . . . Diagramme de classes de l’application Ajout d’un fichier EXCEL . . . . . . . Consultation des statistique . . . . . . Recherche de proc´edures . . . . . . . . Conception de la base de donn´ees . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

26 27 28 29 30 31

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8

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

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

34 35 35 36 36 37 37 38

A.1 A.2 A.3 A.4 A.5

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

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

43 44 44 45 46

iii

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

4

A.6 Le mod`ele MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

47

Introduction G´ en´ erale D e nos jours, toute entreprise est prˆete `a investir des sommes consid´erables dans l’implantation des technologies logicielles afin d’am´eliorer ses services, d’accroˆıtre son agilit´e et sa flexibilit´e, de r´eduire les coˆ uts, d’augmenter la production et de faire face aux d´efis du march´e. En effet, vu la croissance des activit´es au sein des entreprises, la tˆache de g´erer efficacement toutes ces fonctions s’av`ere de plus en plus complexe et difficile. Pour surpasser ces difficult´es, une entreprise doit utiliser des outils optimis´es et adapt´es facilitant les tˆ aches et offrant des fonctionnalit´es riches et utiles. Parmi ces outils nous trouvons les syst`emes int´egr´es de gestion tel que les ERP(Entrprise Ressources Planning). Les ERP sont des outils de gestion et d’analyse permettant d’optimiser la diffusion des informations en interne, d’am´eliorer les processus de gestion et d’automatiser les tˆaches ce qui augmente ´enormement la r´eactivit´e des entreprises et leurs agilit´es. C’est dans ce contexte que s’int`egre notre stage d’immersion en entreprise qui a pour objectif de concevoir et de r´ealiser un ERP permettant d’automatiser les diff´erentes besognes de la soci´et´e NETCOM TUNISIE. Cet ERP doit automatiser les diff´erents processus de gestion ` a savoir la gestion des ressources humaines, la gestion de la production, la gestion commerciale et la gestion financi`ere. Le pr´esent rapport synth´etise tout le travail que nous avons effectu´e dans cette perspective. il est organis´e en chapitres comme suit : – Le premier chapitre donne une pr´esentation g´en´erale du projet : l’organisme d’accueil ainsi que les objectifs ` a atteindre. – Dans le second chapitre, nous proc´edons `a un expos´e de l’´etat de l’art du domaine qui nous concerne. Nous pr´esentons dans un premier temps le syst`eme existant pour d´evoiler ses d´efaillances et ses limites. Nous pr´esentons ´egalement la solution que nous proposons afin de palier aux limites du syst`eme actuel. – Le troisi`eme chapitre intitul´e”’Analyse et Sp´ecification des besoins”’pr´esente les diff´erents besoins fonctionnels et non fonctionnels auxquelles doit satisfaire l’application. – Les choix technologiques retenus pour la phase de d´eveloppement font l’objet du quatri`eme chapitre. – Dans le chapitre V nous pr´esentons la conception g´en´erale et la conception d´etaill´ee du

1

syst`eme. – Le dernier chapitre d´ecrit les tˆ aches accomplies en titre de r´ealisation. Enfin nous donnons une conclusion r´ecapitulant le travail r´ealis´e ainsi que des perspectives futurs.

2

Chapitre 1

Pr´ esentation G´ en´ erale Introduction Ce chapitre a pour objectif de situer notre projet dans son contexte g´en´erale `a savoir l’organisme d’accueil et le sujet ` a traiter. Dans la premi`ere section nous donnons une br`eve pr´esentation de l’organisme d’accueil SATEC International. Dans la deuxi`eme section, nous d´ecrivons le sujet `a traiter et les objectifs ` a atteindre.

1.1

Organisme d’accueil

Activit´ es de SATEC SATEC a ´et´e cr´eee en 1992 et a pu, durant 16 ans, consolider une bonne et solide assise sur le march´e tunisien en tant qu’int´egrateur r´eseaux et s´ecurit´e de r´eseaux, ind´ependamment de tout constructeur. SATEC Tunisie, est devenue un pr´ecurseur et un acteur majeur de l’int´egration r´eseau en Tunisie. Quelques dates utiles – 1992 : Cr´eation de SATEC Tunisie. – 1998 : SATEC Tunisie, meilleur support Nortel : proche Orient/ Afrique du Nord, Cisco Partner. – 1998 : R´ealisation du projet de la t´el´e compensation, ISO 9001 version 2000. – 2002 : Sp´ecialisation s´ecurit´e VPN,WiFi de Cisco Systems. – 2004 : Mise en service d’un centre de management de la s´ecurit´e. – 2005 : Services manag´es Q.o.S, s´ecurit´e.

1.2

Pr´ esentation du sujet

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

3

– Toute mise ` a jour suvenue sur l’un des syst`emes d’informations n’est d´etect´ee par les autres que par voie humaine, en cons´equence elle ne se fait pas en temps r´eel et risque de transmettre des information erron´ees. Les cons´equences d´esagr´eables d’une telle situation ont oblig´e l’entreprise `a y mettre fin. Pour cela, la meilleur solution ´etait d’impl´ementer un ERP multifonctions qui vise `a centraliser le syst`eme d’information et ` a automatiser ses activit´es tout en garantissant une s´ecurit´e de haut niveau.

Fig. 1.1 – Feuille d’affectation de temps pass´es Notre mission consistait alors ` a concevoir et impl´ementer cet ERP qui doit comporter les quatre module suivants : – – – –

Module Module Module Module

de de de de

gestion gestion gestion gestion

de ressources humaines de la production commerciale financi`ere

Notre mission a ´et´e ensuite r´eduite `a la r´ealisation de deux sous modules : impl´ementation 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´e au stage, et en second lieu l’urgence de r´ealiser ces deux fonctionnalit´es pour le client.

Conclusion Dans ce premier chapitre nous avons pu situer le projet dans son cadre g´en´eral en pr´esentant l’organisme d’accueil et les buts de l’application. Dans le chapitre suivant, nous allons proc´eder `a une ´etude d´etaill´ee de l’existant pour d´egager ses limites.

4

Chapitre 2

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

2.1 2.1.1

Les ERP Historique

Dans les ann´ees 60 et 70, les premiers logiciels font leur apparition dans les entreprises. Il s’agit essentiellement d’applications de comptabilit´e et ´egalement de MRP, pour la gestion des approvisionnements. Ces logiciels sp´ecifiques ne sont pas ” portables ”, c’est `a dire qu’ils d´ependent du type d’ordinateur et du syst`eme d’exploitation. Dans les ann´ees 80 se d´eveloppent des progiciels qu’on personnalise, int´egrants la finance, la comptabilit´e, la paie et la gestion de production assist´ee par ordinateur. La tendance `a personnaliser et `a modifier compl`etement le progiciel de base pour l’entreprise conduit le produit `a ˆetre obsol`ete au bout de 5 `a 10 ans. Dans ces ann´ees apparaissent ´egalement les premiers MRP II, int´egrant la gestion de production et la gestion des approvisionnements. La petite histoire raconte qu’`a la fin des ann´ees 80, trois employ´es d’IBM pressentent un march´e important pour les progiciels int´egr´es, et fondent SAP. Peu apr`es, SAP R/2 devient la premi`ere r´ef´erence en mati`ere d’ERP, encore fond´ee sur une structure informatique centralis´ee et une technologie mainframe. En 1993, SAP R/3 r´ealise l’int´egration totale de toutes les composantes d’une entreprise, de la finance `a la production, aux ventes et aux ressources humaines... Sa structure informatique et sa portabilit´e compl`ete seront une grande raison de son succ`es. Les ERP sont maintenant pr´esents dans l’industrie et dans la grande distribution, essentiellement dans les tr`es grandes entreprises. Le march´e des plus petites entreprises, le domaine de la finance et le secteur public commencent `a ˆetre touch´es. La conception et le d´eveloppement des ERP ont ´et´e rendus possibles par les ´evolutions technologiques : vitesse de calcul, technologies de r´eseaux, syst`emes de gestion de bases de donn´ees, stockage de donn´ees... se sont consid´erablement d´evelopp´es et am´elior´es. De plus, le succ`es des ERP a ´et´e favoris´e par la perte de cr´edibilit´e des informaticiens dans les entreprises `a la fin des ann´ees 80 et au d´ebut des ann´ees 90. 5

2.1.2

D´ efinition d’un ERP

L’acronyme ERP signifie ” Enterprise Ressource Planning ” traduit en fran¸cais par Progiciel de Gestion Int´egr´e ou PGI. ERP est le terme le plus couramment utilis´e. Emanant d’un concepteur unique, un ERP est un progiciel qui permet de g´erer l’ensemble des processus d’une entreprise int´egrant l’ensemble de ses fonctions comme la gestion des ressources humaines, la gestion financi`ere 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 applications informatiques correspondant aux diverses fonctions cit´ees pr´ec´edemment de mani`ere modulaire sachant que ces modules sont ind´ependants entre eux, tout en partageant une base de donn´ees unique et commune au sens logique. L’autre principe qui caract´erise un ERP est l’usage de ce qu’on appelle un moteur de workfow et qui permet, lorqu’une donn´ee est enregistr´ee dans le syst`eme d’information(SI), de la propager dans les modules qui en ont l’utilit´e, selon une programmation pr´ed´efinie. Ainsi, on peut parler d’ERP lorsqu’on est en pr´esence d’un SI compos´e de plusieurs applications partageant une seule et mˆeme base de donn´es, par le biais d’un syst`eme automatis´e pr´ed´efini et ´eventuellement param´etrable, un moteur de workfow.

2.1.3

Pour quoi les ERP ?

Concr`etement, les avantages de la mise en place d’un ERP sont les suivants : – L’int´egrit´e et l’unicit´e du SI, c’est `a dire qu’un ERP permet une logique et une ergonomie unique ` a travers sa base de donn´ees, elle aussi unique au sens ” logique ”. Ceci se traduit par le fait qu’il peut exister plusieurs bases de donn´ees ” physiques ” mais celles-ci respectent la mˆeme structure. En bref, un ERP permet d’´eviter la redondance d’information entre diff´erents SI de l’entreprise. – L’utilisateur a la possibilit´e de r´ecup´erer des donn´ees de mani`ere imm´ediate, ou encore de les enregistrer. Un avantage important, les mises `a jour dans la base de donn´ees sont effectu´ees en temps r´eel et propag´ees au modules concern´es. – Un ERP est un outil multilingue et multidevise, il est donc adapt´e au march´e 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 simplifi´ee car celle-ci est assur´ee directement par l’´editeur et non plus par le service informatique de l’entreprise. (Celui-ci garde n´eanmoins sous sa responsabilit´e la maintenance ´evolutive : am´elioration des fonctionnalit´es, ´evolution des r`egles de gestion, etc.). – Un ERP permet de maˆıtriser les stocks, ´el´ement important pour la plupart des entreprises car les stocks coˆ utent chers. Par cons´equent, les ERP g`erent et prennent en charge plusieurs p´eriodes ( pour les exercices comptables par exemple), plusieurs devises, plusieurs langues pour les utilisateurs et clients, plusieurs l´egislations, plusieurs axes d’analyse en informatique d´ecisionnelle. Mais l’implantation 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’´editeur et l’entreprise et enfin des risques ´economiques du fait de l’investissement.

2.1.4

Les principaux ´ editeurs des ERP

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

Conclusion Dans ce chapitre nous avons d´efinit c’est quoi r´eellement les ERP. Ce chapitre sert donc ` a pr´esenter th´eoriquement notre sujet pour mieux comprendre le syst`eme impl´ement´e. Le chapitre suivant sera consacr´e ` a l’´etude des besoins fonctionnels et non fonctionnels auxquels doit r´epondre notre application.

7

Chapitre 3

Analyse et sp´ ecification des besoins Introduction La r´eussite de tout projet d´epend de la qualit´e de son d´epart. De ce fait, l’´etape de sp´ecification constitue la base de d´epart de notre travail. En outre, l’ad´equation de toute l’application ` a r´ealiser, aux besoins des utilisateurs et aux traitements envisag´es au niveau de ses op´erations assurera la r´eussite de l’application et son utilit´e future. Pour assurer ces objectifs, il est essentiel que nous parvenions ` a une vue claire des diff´erents besoins escompt´es de notre projet. Dans ce chapitre, nous ´etudions dans un premier temps les besoins fonctionnels et non fonctionnels de notre syst`eme, ensuite, une sp´ecification formelle des besoins est pr´esent´ee par des diagrammes de cas d’utilisation et de s´equences suivant la mod´elisation UML.

3.1

Identification des Utilisateurs

Notre application fournit une interaction avec plusieurs types d’acteurs, ils sont d´efinis comme ´etant des utilisateurs directs du syst`eme exploitant le logiciel `a travers ses interfaces. Nous identifions dans le cadre de ce projet six acteurs primaires : – Le directeur qui est l’utilisateur qui a tous les privil`eges au niveau de la comptabilit´e analytique et au niveau de la gestion des rˆoles des autres acteurs. – Le comptable qui a un acc`es limit´e au niveau de la comptabilit´e analytique. – L’ing´ enieur qui a tout les droits au niveau de la gestion de la base de connaissance. – Le consultant simple qui a un acc`es limit´e au niveau de la gestion de la base de connaissance. – L’assistance du service qui aura l’acc`es pour ajouter ou modifier les documents des ing´enieurs. – Les responsables des d´ epartements qui ont des privil`eges sp´ecifiques `a chaque d´epartement. Pour cela on va sp´ecifier ci dessous les besoins que doit fournir le syst`eme pour chaque cat´egorie d’utilisateurs.

8

3.2

Les Exigences Sp´ ecifiques

L’analyse du sujet, nous a permis de cerner les fonctionnalit´es `a la disposition de l’utilisateur.Les besoins ainsi d´egag´es ont ´et´e class´es en fonctionnels et non fonctionnels.

3.2.1

Les besoins fonctionnels

– Le Directeur : Le syst`eme doit permettre au directeur de : – S’identifier pour acc´eder ` a la section de la comptabilit´e. – Consulter la liste d´etaill´ee des affaires et la r´epartition des ing´enieurs correspondant par mois. – Effectuer des recherches selon des diff´erents crit`eres : par date, par ing´enieur ou par affaire. – Ajouter une nouvelle affaire si elle n’existe pas d´ej`a. – Visualiser les statistiques et les courbes d’´evolution. – T´el´echarger un fichier EXCEL et mettre `a jour la base de donn´ees. – Valider les documents t´el´echarg´es. – Saisir les informations du document de l’ing´enieur `a l’aide d’un formulaire. – Mettre ` a jour les rˆ oles de chaque profile utilisant le syst`eme. – Le Comptable : Le syst`eme doit permettre au comptable de : – Consulter la liste d´etaill´ee des affaires et la r´epartition des ing´enieurs correspondant par mois. – Effectuer des recherches selon des diff´erents crit`eres . – S’identifier pour acc´eder ` a la section de la comptabilit´e. – Visualiser les statistiques et les courbes d’´evolution. – L’ing´ enieur : Le syst`eme doit permettre `a l’ing´enieur de : – S’identifier pour acc´eder ` a la section de la gestion de la base de connaissances. – Remplir les fiches de proc´edure (description, mot cl´e..). – Consulter ses fiches de proc´edure remplies auparavant. – Mettre ` a jour une fiche de proc´edure. – Le consultant : Le syst`eme doit permettre au consultant simple de : – Rechercher une fiche de proc´edure. – Consulter les fiches r´esultantes class´ees. – Imprimer la fiche des proc´edures. – Le responsable de d´ epartement : Le syst`eme doit permettre au responsable de d´epartement de : – S’identifier pour acc´eder ` a la section de comptabilit´e analytique. – Ajouter et mettre ˆ a jour les profiles du d´epartement. – L’assistance de service : Le syst`eme doit permettre `a l’assistance de service de : 9

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

3.3

Les exigences non sp´ ecifiques

Pour le bon fonctionnement de notre application nous avons d´egag´e les besoins non fonctionnels suivants : – la fiabilit´e : le syst`eme doit ˆetre disponible `a tout moment pour l’utilisateur, avec un acc`es s´ecuris´e par la d´efinition d’un login et d’un mot de passe. – la portabilit´e : le syst`eme doit tourner sur plusieurs plates-formes. – la convivialit´e : le syst`eme doit pr´esenter une interface compr´ehensible, facile `a manipuler ce qui nous permettera d’accroˆıtre la rentabilit´e et l’efficacit´e de notre syst`eme.

10

3.4

Les cas d’utilisation

L’´etude approfondie des sp´ecifications permet de d´egager plusieurs cas d’utilisation. Un cas d’utilisation d´ecrit une utilisation du syst`eme par un acteur particulier.Ce qui revient `a pr´esenter les besois fonctionnels de fa¸con 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’ing´ enieur

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

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´ epartement

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

3.4.1

Les diagrammes de s´ equences

les diagrammes de s´equences peuvent servir `a illustrer un cas d’utilisation d´ecrit pr´ec´edemment. C’est un moyen semi formel de capturer le comportement de tous les objets et acteurs impliqu´es dans un cas d’utilisation. Dans ce qui suit nous allons pr´esenter quelques sc´enarios de notre applications. Diagramme de s´ equence pour l’ajout d’un fichier EXCEL

Fig. 3.7 – Ajout d’un fichier EXCEL 15

Diagramme de s´ equence pour la consultation des statistiques

Fig. 3.8 – Consultation des statistiques

16

Diagramme de s´ equence pour la recherche de proc´ edures

Fig. 3.9 – Recherche de proc´edures

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

17

Chapitre 4

Solutions techniques possibles et choix retenus Introduction Ce chapitre aborde une ´etude comparative entre les diff´erentes technologies existantes et prouve le choix de l’environnement de d´eveloppement ainsi que le syst`eme de gestion de la base de donn´ees.

4.1

Solutions techniques possibles

4.1.1

Technologie de d´ eveloppement

Microsoft .NET Pr´ esentation : La plate-forme Microsoft .NET est une solution compl`ete pour d´evelopper, d´eployer et ex´ecuter des application de tous types, y compris des services web. Fond´ee sur des standards de l’industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen simple et puissant pour impl´ementer la coop´eration des services logiciels entre eux, quelle que soit leur localisation, leur impl´em´entation technique, qu’ils soient internes ou externes, existant ou `a inventer. Les composants de .NET : A travers les diff´erentes annonces de Microsoft depuis son lancement, les composants de .NET semblent s’organiser de la mani`ere suivante : 1. Pour la couche pr´esentation et logique de pr´esentation : – ASP .NET : c’est une nouvelle version d’ASP (Active Server Pages) qui supporte une v´eritable compilation en IL, alors qu’ASP ´etait interpr´et´e auparavant. On peut ´egalement ´ecrire les pages ASP dans n’importe quel langage disposant d’un compilateur IL. – WinForms et WebForms : ils pr´esentent un ensemble de composants graphiques accessibles dans Visual Studio .NET . 2. Pour la couche logique m´etier et objets interm´ediaires :

18

– CLR ( Common Language Runtime) : c’est un environnement d’ex´ecution commun qui ex´ecute un bytecode ´ecrit dans un langage interm´ediaire (Microsoft intermediate Language) – C# : c’est nouveau langage orient´e objet destin´e `a faciliter la programmation dans .NET, notamment les composants, qui int`egre des ´el´ements de C, C++ et de Java en apportant quelques innovations comme les m´eta-donn´ees. – Langages quelconques qui peuvent ˆetre compil´es en IL et ex´ecut´es par le CLR si un compilateur IL existe pour ce dernier. – Une grande biblioth`eque de composants et d’objets de base accessibles par le CLR, qui fournissent les fondations pour ´ecrire rapidement un programme (acc`es r´eseau, graphisme, acc`es aux donn´ees ). – Visual Studio .NET : c’est une r´efonte de l’environnement Visual Studio et de Visual INterDev permettant aussi bien le d´eveloppement d’application et de composant classique. – Un support de terminaux mobiles avec une version compacte de l’environnement .NET . 3. Pour la couche de donn´ees : – ADO .NET : c’est une nouvelle g´en´eration de composants d’acc`es aux bases de donn´ees ADO qui utilise XML et SOAP pour l’´echange de donn´ees. Les avantages de .NET : La plate-forme .NET comprend un mod`ele de programmation homog`ene et des outils de d´eveloppement multi langages qui acc`el`erent le d´eveloppement et l’int´egration de Services Web et de tout autre type d’application multi langages et int´egrant les standards, la plate-forme .NET laisse au d´eveloppeur toute libert´e de choisir le langage de d´eveloppement. D’autre part son support des stabndards et son approche moderne, la plateforme .NET est parfaitement adapt´ee ` a la construction d’une architecture orient´ee services. La plate-forme .NET offre donc plusieurs avantages : – Un d´eveloppement sp´ecifique grˆ ace au moteur CLR . – Une structure multi langages et extensible . – Une ex´ecution multi plate-forme . – Une productivit´e comparable ` a celle des environnements Client/Serveur comme PowerBuilder ou Delphi . – Un mod`ele de programmation simple et coh´erent . – Une installation automatis´ee des Web Services . J2EE Pr´ esentation : J2EE est logiquement destin´e aux gros syst`emes d’entreprise. Les logiciels employ´es `a ce niveau ne fonctionnent pas sur un simple PC mais requi`ere une puissance beaucoup plus importante. Pour cette raison, les applications doivent ˆetre constitu´ees de plusieurs composants pouvant ˆetre d´eploy´es sur des plate-formes multiples afin de disposer de la puissance de calcul n´ecessaire. C’est la raison d’ˆetre des applications distribu´ees. J2EE est une collection de composants, de conteneurs et de services permettant de cr´eer et de d´eployer des applications distribu´ees au sein d’une architecture standardis´ee. 19

Les composants de J2EE : J2EE fournit une gamme d’outils et d’API afin de concevoir facilement les diff´erentes couches. 1. Pour la couche Pr´esentation et logique de pr´esentation : – Java Servlet : Une servlet est un programme ´ecrit en JAVA qui tourne sur la machine du serveur J2EE. Une servlet est charg´ee lorsque le serveur est mis en route ou lorsque le premier client fait appel aux services de la servlet.Le serveur Web re¸coit une demande adress´ee ` a une servlet sous la forme d’une requˆete HTTP. Il transmet la requˆete `a la servlet concern´ee, puis renvoie la r´eponse fournie par celle du client . La servlet re¸coit ´egalement les param`etres de la requˆete envoy´ee par le client. Elle peut alors effectuer toutes les op´erations n´ecessaires pour construire la r´eponse avant de renvoyer celle-ci sous forme de code HTML. Une fois charg´ee, une servlet reste active dans l’attente de nouvelles requˆetes. Une servlet doit soit impl´ementer 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 d´eveloppement d’applications web bas´ees sur ce mod`ele ; 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 d´eveloppement web en java respectant le mod`ele d’architecture MVC (Model-View-Controller). Il fournit le minimum de r`egles pour construire des applications web professionnelles. – Java Server Faces (JSF) : Java Server Faces est un framework d’interface utilisateur pour les applications web, bas´e sur les technologies JSP et Servlets. Le but de JSF est d’accroˆıtre la productivit´e des d´eveloppeurs dans le d´eveloppement des interfaces utilisateur tout en facilitant leur maintenance. JSF permet de r´econcilier deux points de vues diam´etralement oppos´es en fornissant un framework bas´e sur une abstraction compl`ete des m´ecanismes d’internet tout en garantissant une totale maˆıtrise du cycle de vie du traitement d’une requˆete. JSF permet : – une s´eparation nette entre la couche de pr´esentation et les autres couches. – le mapping HTML/Objet. – un mod`ele riche de composants graphiques r´eutilisables. – un mod`ele riche de composants graphiques r´eutilisables. – une gestion de l’´etat de l’interface entre les diff´erentes requˆetes. – une liaison simple entre les actions cˆot´e client de l’utilisateur et le code Java correspondant cˆ ot´e serveur. – la cr´eation de composants customs grˆace `a une API. – le support de diff´erents clients (HTML, WML, XML, ...) grˆace `a la s´eparation des probl´ematiques 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 d´eveloppement des applications web tout en augmentant la consistance et la productivit´e. 2. Pour la couche logique m´etier et objet interm´ediaires : – Les EJB : Ce sont des composants Java pour des applications distribu´ees multi niveaux. Cette extension fournit un moyen standard pour d´efinir les composants cˆot´e serveur et d´efinit une vaste infrastructure d’ex´ecution pour l’h´ebergement des composants cˆot´e serveur. – Les JavaBeans : Selon la sp´ecification des Javabeans, une Bean est un composant logiciel r´eutilisable pouvant ˆetre manipul´e visuellement dans un outil de construction (builder tool). 3. Pour la couche de donn´ees : – JDBC Connector : JDBC (l’acronyme de JAVA Data Base Connectivity) est une API JAVA permettant d’acc´eder ` a es base de donn´ees, de fa¸con ind´ependante de la base utilis´ee, ` a partir d’une application JAVA. La proc´edure sera la mˆeme quelle que soit la base de donn´ees choisie. JDBC d´efinit une API de bas niveau d´esign´ee pour supporter les fonctionnalit´es basiques de SQL ind´ependement de toute impl´ementation SQl sp´ecifique. – 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´ees : cr´eation et mise `a jour. IL utilise un langage simple pour l’interrogation de la base de donn´ees appel´e 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 adopt´ee par la plate-forme J2EE offre plusieurs avantages : – Elle r´eduit la compl´exit´e du d´eveloppement distribu´e avec une architecture simplifi´ee et le partage de la charge de travail. – C’est une solution hautement ´evolutive qui permet le d´eveloppement des syst`emes satisfaisant de nombreux besoins rapidement modifiables. – Les nouvelles applications peuvent s’int´egrer correctement avec les syst`emes d’informations existants. – La s´ecurit´e est am´elior´ee. – Les d´eveloppeurs peuvent choisir parmi une diversit´e d’outils de d´eveloppement et de composants pour d´evelopper les applications requises. – L’´equipe de d´eveloppement peut s´electionner les meilleurs solutions pour leurs besoins, sans ˆetre verrouill´ee par l’offre du fournisseur unique. – Tous les composants sont gratuits. Comparaison entre J2EE et .NET Dans cette section, nous allons d´egager les principales diff´erences entre la technologies J2EE de Sun et la technologie .NET de Microsoft. En fait, nous avons limit´e notre ´etude sur ces deux technologies car ils sont les plus appr´eci´ees au sein des entreprises qui ambitionnent avoir des applications robustes, portables, complexes et s´ecuris´ees, d’autant plus qu’elles traitent des donn´ees confidentielles, et font appels aux technologies les plus modernes. Le tableau suivant expose les crit`eres sur lesquels se basera notre choix technologique.

22

.NET

J2EE

Langages

C#,multi-langage

Java

Services

BCL

Java Core API

Pr´ esentation

ASP .NET

Servlet, JSP

Interpr` ete

CLR

JVM

Composants graphiques

WinForms, WebForms

Swing

Acc` es ` a la BD

ADO .NET

JDBC, Hibernate, iBatis

Technologie

Produit

Standard

Tab. 4.1 – Tableau comparatif .NET et J2EE

4.1.2

Environnement de d´ eveloppement

4.1.3

Gestion de la base de donn´ ees

Oracle DataBase Oracle est un SGBDR ´edit´e par la soci´et´e du mˆeme nom Oracle Corporation leader mondial en base de donn´ees.Oracle peut assurer entre autres fonctionnalit´es : – La d´efinition et la manipulation des donn´ees – La coh´erence des donn´ees. – La confidentialit´e des donn´ees. – L’int´egrit´e des donn´ees. 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`es quelques tests, les d´eveloppeurs sont arriv´es ` a la conclusion que mSQL n’´etait pas assez rapide et flexible pour leurs besoins. Le serveur de bases de donn´ees MySQL est tr`es rapide, able et facile `a utiliser. Il dispose aussi de fonctionnalit´es pratiques, d´evelopp´ees en coop´eration avec les utilisateurs. Les principales fonctionnalit´es qu’offre MySQL sont : – Fonctionne sur de nombreuses plate-formes. – Dispose d’API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl. – Compl`etement multi-thread´e, grˆ ace aux threads du noyau. Cela signi e qu’on peut l’utiliser facilement sur un serveur avec plusieurs processeurs. – Tables B-tree tr`es rapide, avec compression d’index. – Syst`eme l’allocation m´emoire tr`es rapide, exploitant les threads. – Tables en m´emoire, pour r´ealiser des tables temporaires. – Les fonctions SQL sont impl´ement´ees grˆace `a une librairie de classes optimis´ees, qui sont aussi rapides que possible . PostgreSQL PostgreSQL est un SGBD relationnel objet Open Source impl´ement´e par l’universit´e de Berkeley. Les fonctions cl´es du mod`ele objet de PostgreSQL sont les classes, l’h´eritage et la surcharge.

23

PostgreSQL est un logiciel ” modulaire ” poss´edant un langage d’´ecriture de proc´edures similaire `a celui d’Oracle mais ´egalement d’autres interfaces de programmation. Voici les fonctions cl´es du mod`ele orient´e objet de PostgreSQL : – Les classes : Une classe correspond `a un ensemble d’objets poss´edant un identificateur unique. – L’h´eritage : La notion d’h´eritage correspond `a une organisation hi´erarchique 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 d´efinie plusieurs fois avec des param`etres diff´erents.

4.2

Choix retenus

La claret´e de l’architecture qu’elle propose ainsi que la multitude des IDE qui peuvent la supporter et sa gratitude, la technologie J2EE a ´et´e le choix Judicieux pour le d´eveloppement de notre application. L’IDE surlequel nous avons choisit de d´evelopper notre application est l’IDE Eclipse. Une base de donn´ee MySQL est celle qui va ˆetre impl´ementer pour g´erer les donn´ees n´ecessaire `a l’application.

Conclusion Apr`es cette ´etude nous avons d´ecid´e de choisir la plate-forme J2EE comme environnement de d´eveloppement (donc Java comme langage de programmation), MySQL pour l’impl´ementation de la base de donn´ees et hibernate pour la couche persistence de donn´ees. Le chapitre suivant aborde en d´etail la conception de l’application `a r´ealiser.

24

Chapitre 5

Conception Introduction Dans ce pr´esent chapitre nous allons entamer une partie cruciale du d´eveloppement logiciel et qui constitue un pont entre la sp´ecification et la r´ealisation. Elle comporte la conception de l’application ainsi que la conception de la base de donn´ees.

5.1

Conception g´ en´ erale

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

5.1.1

La comptabilit´ e analytique :

Ce module s’int´egre dans la partie de gestion financi`ere de l’ERP `a r´ealiser. 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 r´ealisation des statistiques ´el´ementaires et crois´ees et y dessiner les diagrammes correspondnat afin de les bien pr´esenter au responsable sup´erieur. Ce module, `a part son rˆ ole pour r´eduire les temps de r´ealisation des tˆaches cit´ees, il permet d’´economiser l’argent puisque l’ˆetre humain n’interviendra pas dans le m´ecanisme.

5.1.2

La gestion de la base de connaissances :

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

5.2

Conception d´ etaill´ ee

La conception d´etaill´ee vise ` a transformer le mod`ele d’analyse (sp´ecification : haut niveau d’abstraction) en un mod`ele concrˆet, de bas niveau d’abstraction et `a partir duquel le programmeur peut directement impl´ementer le syst`eme.

25

5.2.1

Architecture de l’application

La navigation entre les diff´erentes parties de notre application est pr´esent´ee par la figure ci-dessous :

Fig. 5.1 – Architecture de l’application

5.2.2

Diagrammes de Classes

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

26

Fig. 5.2 – Diagramme de classes de l’application

27

5.2.3

Diagrammes de s´ equences d´ etaill´ es

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

Fig. 5.3 – Ajout d’un fichier EXCEL

28

Diagramme de s´ equence pour la consultation des statistiques

Fig. 5.4 – Consultation des statistique

29

Diagramme de s´ equence pour la recherche de proc´ edures

Fig. 5.5 – Recherche de proc´edures

30

5.2.4

Conception de la base de donn´ ees

Le mod`ele relationnel de donn´ees est un mod`ele de donn´ee comme d’autres existants ayant pour but de d´ecrire le monde r´eel ` a partir des informations et des donn´ees qu’on peut en extraire et se diff´erencient par la nature des associations qu’ils permettent de mod´eliser. L’objectif essentiel du mod`ele relationnel ´etait d’accroˆıtre l’ind´ependance vis-`a-vis du niveau de repr´esentation des donn´ees. Du point de vue utilisateur, une base de donn´ees peut ˆetre consid´er´ee comme un ensemble de tables manipulables par des langages de haut niveau dont la caract´eristique principale est d’ˆetre des langages non proc´eduraux. Pour ces raisons nous avons choisi d’utiliser une base de donn´ees relationnelle. A ce niveau de cette application et tout en consid´erant les besoins d´ej`a sp´ecifi´es nous avons envisag´e un certain nombre de tables pour enregistrer les donn´ees n´ecessaires pour la gestion du site. Les tables utilis´ees et les relations qui les inter-relient sont donn´ees par la figure 5.6

Fig. 5.6 – Conception de la base de donn´ees

31

Coclusion Etant donn´e les besoins des utilisateurs de notre applications, la phase de conception vient pour permettre la d´etermination des diff´erents objets contribuant `a assurer les fonctionnalit´es souhait´ees. Cette phase est une pr´eparation `a la phase du codage garantissant une organisation claire et pr´ecise ainsi qu’une facilit´e d’impl´ementation des classes invoqu´ees, des structures de donn´ees utilis´ees et les relations qui existent entre les diff´erentes classes. Nous essayons dans le chapitre r´ealisation d’impl´ementer les diff´erentes classes et de montrer les fonctionnalit´es r´ealis´ees suite ` a cette impl´ementation.

32

Chapitre 6

R´ ealisation Apr`es avoir achev´e l’´etape de conception de l’application, nous entamons dans ce chapitre la phase de r´ealisation. Nous allons pr´esenter, en premier lieu, l’environnement de travail utilis´e pour le d´eveloppement de l’application. Ensuite, nous allons donner un aper¸cu sur le travail accompli `a travers des capture d’´ecran. Enfin, nous montrerons le chronogramme de la r´ealisation du projet.

6.1

Environnement de travail

6.1.1

Environnement mat´ eriel

Afin de r´ealiser ce site web dans les conditions les plus favorables, nous avons mis en disposition un ordinateur ayant la configuration 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 d´eveloppement int´egr´e (Integrated Development Environment) dont le but est de fournir une plate-forme modulaire pour permettre de r´ealiser des d´eveloppements informatiques. I.B.M. est `a l’origine du d´eveloppement 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 d´eveloppement en Java d’I.B.M. Tout le code d’Eclipse a ´et´e donn´e ` a la communaut´e par I.B.M afin de poursuivre son d´eveloppement. Eclipse utilise ´enorm´ement le concept de modules nomm´es ”Plug-ins” dans son architecture. D’ailleurs, hormis le noyau de la plate-forme nomm´e ”Runtime”, tout le reste de la plate-forme est d´evelopp´e sous la forme de Plug- ins. Ce concept permet de fournir un m´ecanisme pour l’extension de la plate-forme et ainsi fournir la possibilit´e `a des tiers de d´evelopper des fonctionnalit´es 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 impl´ementait les sp´ecifications 2.4 des JavaServlet et 2.0 des JSP. Tomcat a ´et´e d´evelopp´e en open source au sein du projet Apache Jakarta, dont le but est de fournir des solutions serveur bas´ees sur la plate-forme Java, de qualit´e identique aux applications commerciales.Tomcat est un moteur d’ex´ecution 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 r´ ealis´ e

A cette ´etape du nous donnons les captures d’´ecran relatives aux pages des principales fonctions r´ealis´ees par l’application.

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´ edures

Fig. 6.4 – Recherche de fiche de proc´edure

6.2.5

R´ esultats de la recherche

Fig. 6.5 – R´esultats 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 n´ecessaire de tracer un diagramme qui d´ecrit la r´epartition temporelle des tˆaches du travail durant deux mois afin de montrer les diff´erentes phases par lesquelles notre projet a pass´e. – Documentation et ´etudes th´eorique : elle consiste `a rechercher une documentation sur le sujet et ` a ´etudier les objectifs g´en´eraux du stage. – Sp´ecification et analyse de besoins : elle consiste `a ´etudier l’´etat actuel du processus de travail de l’entreprise ainsi que ses besoins r´eels. – Conception : elle vise ` a mod´eliser le syst`eme selon une vue bien claire. – Impl´ementation : elle s’occupe du d´eveloppement du codes des diff´erentes fonctionalit´es du syst`eme comme mod´elis´e dans la conception. – R´edaction du rapport : elle collecte toutes les informations n´ecessaires et autoris´ees `a ˆetre publi´ees. Le chronogramme suivant donne la r´epartition de ces diff´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 exp´erience et des comp´etences professionnelles et d´ecouvrir le fonctionnement des ´equipes de d´eveloppement au sein des entreprises informatiques. L’objectif de ce stage ´etait de concevoir et de d´evelopper deux modules faisant parti d’un ERP destin´e ` a une entreprise class´ee de PME. Il a ´et´e aussi b´en´efique aussi bien sur le plan th´eorique que sur le plan pratique. En effet sur le plan pratique ce projet nous a donn´e une occasion de d´ecouvrir le framework JSF pour le d´eveloppement des applications web, et d’am´eliorer nos connaissances sur la gestion des bases de donn´ees. Sur le plan th´eorique il nous a permis une familiarisation avec les notions et les automatismes 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´eveloppement du reste des modules de l’ERP et son int´egration dans l’environnement constituons le sujet du projet de fin d’´etudes afin de voir un produit complet pouvant automatiser plusieurs tˆ ache dans les petites et moyennes entreprises.

39

Bibliographie ´my Applications Web Java Servlets et JSP,2004 [1] Olivier Debas, Christine Deffaix Re [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´eveloppement Web avec J2EE .O’Reilly,2005

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

41

consult´e le 01 juillet 2008 consult´e le 09 juillet 2008 consult´e le 10 juillet 2008 consult´e le 27 juillet 2008 consult´e le 20 aoˆ ut 2008 consult´e le 21 aoˆ ut 2008

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

42

Annexe A

Les Architectures Logicielles Architecture Simple tiers Les applications bureautiques sont con¸cues pour fonctionner sur un ordinateur unique. Toutes les services fournis par l’application - interface utilisateur, persistance des donn´ees (sauvegarde dans des fichiers propri´etaires) et logique de traitement de ces donn´ees - r´esident 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 r´epartis entre le client repr´esent´e par une station de travail utilisateur et le serveur repr´esent´e par un mainframe ou un serveur puissant. Le client prend en charge l’ensemble des taches li´ees `a la pr´esentation, `a la logique applicative ainsi qu’une grande partie de la logique m´etier. Quant au serveur, son rˆole est d’h´eberger les donn´ees du syst`eme d’information et de traiter les requˆetes en provenance du client. Un des inconv´enient de l’architecture deux-tiers est que la logique charg´ee de la manipulation des donn´ees et de l’application des r`egles m´etiers aff´erentes est incluse dans l’application ellemˆeme. Cela pose probl`eme lorsque plusieurs applications doivent partager l’acc`es `a une base de donn´ees.

Architecture trois tiers C’est un mod`ele logique d’architecture applicative qui vise `a s´eparer tr`es nettement trois couches logicielles au sein d’un mˆeme syst`eme.

43

Fig. A.2 – Architecture Deux Tiers

Fig. A.3 – Architecture Trois Tiers Selon ce mod`ele, toute la logique m´etier est extraite de l’application cliente. Celle-ci n’est plus responsable que de la pr´esentation de l’interface `a l’utilisateur et de la communication avec le tiers m´edian. Elle n’est plus responsable de l’application des r`egles. Son rˆole est r´eduit `a la couche pr´esentation.

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

Notion de J2EE J2EE est logiquement destin´e aux gros syst`emes d’entreprise. Les logiciels employ´es `a ce niveau ne fonctionne pas sur un simple PC mais requi`ere une puissance beaucoup plus importante. Pour cette raison, les applications doivent ˆetre constitu´ees de plusieurs composants pouvant ˆetre d´eploy´es sur des plate-formes multiples afin de disposer de la puissance de calcul n´ecessaire. C’est la raison d’ˆetre des applications distribu´ees. J2EE est une collection de composants, de conteneurs et de services permettant de cr´eer et de d´eployer des applications distribu´ees au sein d’une architecture standardis´ee.

44

Les Conteneurs Les conteneurs sont les ´el´ements fondamentaux de l’architecture J2EE. Les conteneurs fournis par J2EE sont de mˆeme type. Ils fournissent une interface parfaitement d´efinie ainsi qu’un ensemble de services permettant aux d´eveloppeurs d’applications de se concentrer sur la logique m´etier `a mettre en oeuvre pour r´esoudre le probl`eme qu’ils ont `a traiter, sans qu’ils aient ` a se pr´eocuper de toute l’infrastructure interne. Les conteneurs s’occupent de toutes les tˆaches fastidieuses li´ees au d´emarrage des services sur le serveur, `a l’activation de la logique applicative, la gestion des protocoles de communication intrins`eque ainsi qu’`a la lib´eration des ressources utilis´ees.

Les Servlets Une servlet est un programme ´ecrit en JAVA qui tourne sur la machine du serveur J2EE. Une servlet est charg´ee lorsque le serveur est mis en route ou lorsque le premier client fait appel aux services de la servlet.Le serveur Web re¸coit une demande adress´ee `a une servlet sous la forme d’une requˆete HTTP. Il transmet la requˆete `a la servlet concern´ee, puis renvoie la r´eponse fournie par celle du client . La servlet re¸coit ´egalement les param`etres de la requˆete envoy´ee par le client. Elle peut alors effectuer toutes les op´erations n´ecessaires pour construire la r´eponse avant de renvoyer celle-ci sous forme de code HTML. Une fois charg´ee, une servlet reste active dans l’attente de nouvelles requˆetes. Une servlet doit soit impl´ementer 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 Cr´eer des servlets consiste ` a construire des composants Java capables de produire du code HTML. Dans de nombreux cas, cela fonctionne sans probl`eme. Toutefois, il n’est pas facile, pour les personnes charg´ees de concevoir l’aspect visuel des pages Web, de manipuler du code Java, auquel elles n’ont probablement pas ´et´e form´ees. 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 sp´ecification des Javabeans, une Bean est un composant logiciel r´eutilisable pouvant ˆetre manipul´e visuellement dans un outil de construction (builder tool). Un composant poss`ede : – des propri´et´es persistantes – des ´ev´enements reconnus – des m´ethodes de traitement des ´ev´enements

Les Serveurs D’application Le serveur d’application est l’environnement d’ex´ecution des applications cˆot´e serveur. Il prend en charge l’ensemble des fonctionnalit´es permettant `a plusieurs utilisateurs d’exploiter une mˆeme application. Parmi ces fonctionnalit´es 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 g´en´eralement en g´en´erant un identifiant unique pour chaque client et en le transmettant lors de chaque ´echange HTTP. – Gestion des mont´ees en charge et reprise sur incident : afin de g´erer toujours plus d’utilisateurs, le serveur d’application doit pouvoir se d´eployer sur plusieurs machines et, ´eventuellement, offrir des possibilit´es de reprise sur incident. – Ouverture sur plusieurs sources de donn´ees : pour rendre accessible les donn´ees de l’application, le serveur d’application doit pouvoir acc´eder `a de nombreuses sources de donn´ees.

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

46

Fig. A.6 – Le mod`ele MVC. – Le Mod`ele repr´esente les donn´ees de l’application g´en´eralement stock´ees dans une base de donn´ees. – La Vue correspond ` a l’IHM (Interface Homme Machine). – Le Contrˆ oleur assure les ´echanges entre la vue et le mod`ele notamment grˆace `a des composants m´etiers. L’utilisation du mod`ele MVC rend un peu plus compliqu´e le d´eveloppement de l’application qui le met en oeuvre mais il permet une meilleure structuration de l’application. Le principal d´efaut du mod`ele MVC est le nombre de servlets `a d´evelopper pour une application. Comme rem`ede `a ce probl`eme, le mod`ele MVC2 s’est impos´e. En effet cette version du mod`ele propose de n’utiliser qu’une seule servlet comme contrˆoleur de tiute l’application.

47