Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes

Mmoire de Projet de Stage de 2me Anne

Sujet

Conception et ralisation dune application de gestion des interventions et du parc informatique

Soutenu par : Kaoutar SALHI Taha MHAND

Sous la direction de : Mme. Majda HASSANI M. Abdeslam OUBLAID

Anne Universitaire 2009-2010

Remerciement
Il tait agrable de nous acquitter dune dette de reconnaissance envers tous ceux, dont la contribution au cours de ce projet, a favoris son aboutissement. Ainsi, nous tenons remercier tout le personnel de Cooper Pharma et plus prcisment : Nos encadrants Mr OUBLAID Abdeslam et Mme HASSANI Majda qui nous ont t dun grand apport quant llaboration du projet et dont la cordialit, le soutien et lesprit ouvert nous ont permis damliorer nos comptences. Que le corps professoral et administratif de lENSIAS trouve ici nos vifs remerciements. Nous remercions enfin toute personne qui a contribue de prs ou de loin llaboration de ce rapport.

Liste des abrviations

Liste des abrviations Abrviation AJAX HTML IDE J2EE JDBC JSP MVC PDF SDK SGBD SQL UML URL XML Designation Asynchronous Java And Xml HyperText Markup Language Integrated Development Environment Java 2 Entreprise Edition Java Data Base Connectivity Java Server Pages Modle Vue Contrleur Portable Document Format Sun Developpement Kit Systme de Gestion des Bases de Donnes Structured Query Language Unified Modeling Language Uniform Resource Locator eXtensible Markup Language

Liste des figures

Liste des figures

Figure 1 Activit de l'industrie ................................................................................................. 10 Figure 2 Activit de rpartition ................................................................................................ 10 Figure 3 Activit de Service ..................................................................................................... 11 Figure 4 Historique de Cooper Pharma .................................................................................... 11 Figure 5 Communisation facile entre la base de donnes et l'utilisateur ................................. 12 Figure 6 Diagramme de Cas d'utilisation ................................................................................ 18 Figure 8 : Diagramme de squence d'authentification ............................................................. 20 Figure 9 Diagramme de squence d'ajout d'une demande d'intervention ................................ 21 Figure 10 Diagramme de squence de l'ajout d'un quipement ............................................... 22 Figure 12 Diagramme de classes .............................................................................................. 25 Figure 13 Diagramme des classes relatif la gestion des interventions .................................. 26 Figure 14 Diagramme des classes relatif la gestion des quipements ................................... 27 Figure 15 Diagramme de classe relatif au pattern DAO .......................................................... 28 Figure 16 Modle conceptuel de donnes ............................................................................... 29 Figure 17 Architecture MVC 2 ................................................................................................ 33 Figure 18 Fonctionnement de Struts2 ...................................................................................... 35 Figure 19 Architecture logicielle du systme ........................................................................... 37 Figure 20 La page d'authentification ........................................................................................ 40 Figure 21 Page d'ajout d'une intervention ................................................................................ 41 Figure 22 La Page de recherche des interventions .................................................................. 42 Figure 23 La page de traitement des interventions .................................................................. 43 Figure 24 La page d'ajout d'un quipement (informations communes) ................................... 44 Figure 25 Informations sur un matriel selon la catgorie Poste ....................................... 44 Figure 26 La page d'affectation ............................................................................................... 45 Figure 27 La page de dsaffectation ........................................................................................ 46 Figure 28La page de l'historique des affectations .................................................................... 46 Figure 29 Exemple d'un fichier web.xml ................................................................................. 53 Figure 30 L'architecture d'un projet Struts 2 ............................................................................ 54 Figure 31 Exemple d'un fichier struts.xml .............................................................................. 54

Liste des tableaux

Liste des tableaux

Tableau 1Les acteurs du systme ............................................................................................. 17 Tableau 2 Les cas d'utilisation ................................................................................................. 18 Tableau 3 Les classes du systme ............................................................................................ 24 Tableau 4 Rles et relations de la couche prsentation ............................................................ 38 Tableau 5 Rles et relations de la couche application.............................................................. 38 Tableau 6 Rles et relations de la couche service .................................................................... 39 Tableau 7 Rles et relations de la couche DAO ....................................................................... 39

Table des matires

Table des matires

LISTE DES FIGURES ................................................................................................................ 4 LISTE DES TABLEAUX ............................................................................................................. 5 INTRODUCTION GENERALE ................................................................................................ 8 CHAPITRE 1 .............................................................................................................................. 9 I. CONTEXTE GENERALE DU PROJET ......................................................................... 10 1.1 PRESENTATION DE LORGANISME DACCUEIL ............................................................ 10 1.1.1 Prsentation ............................................................................................. 10 1.1.2 Activits .................................................................................................... 10 1.1.3 Historique ................................................................................................. 11 1.2 PRESENTATION DU PROJET ........................................................................................ 12 1.2.1 Description du besoin............................................................................... 12 1.2.2 Objectifs ................................................................................................... 12 1.2.3 Contraintes ............................................................................................... 13 CHAPITRE 2 ............................................................................................................................ 15 II. ANALYSE ET CONCEPTION ....................................................................................... 16 2.1. DESCRIPTION DES FONCTIONNALITES ......................................................................... 16 2.1.1 Description des modules ................................................................................. 16 2.1.1.1 Module de gestion des interventions ........................................................ 16 2.1.1.2 Module de gestion du parc informatique ................................................. 16 2.1.2 Identification des acteurs ......................................................................... 16 2.2. MODELISATION UML ................................................................................................. 17 2.2.1 Choix dUML................................................................................................... 17 2.2.2 Cas dutilisation .............................................................................................. 17 2.2.3 Diagramme de squence ................................................................................. 19 2.2.4 Diagramme de classe ...................................................................................... 23 2.3. CONCEPTION DE LA BASE DE DONNEES ....................................................................... 28 2.3.1 Modle conceptuel de donnes ........................................................................ 28 CHAPITRE 3 ............................................................................................................................ 31 III. REALISATION ET MISE EN UVRE ......................................................................... 32 3.1. ENVIRONNEMENT DE DEVELOPPEMENT ............................................................. 32 3.1.1. La plateforme J2EE .................................................................................. 32 3.1.2. Larchitecture MVC II .............................................................................. 33 3.2 OUTIL DE DEVELOPPEMENT ......................................................................................... 34 3.2.1. Environnement de dveloppement intgr : Eclipse ..................................... 34 6

Table des matires

3.2.2 Systme de gestion de bases de donnes : Microsoft SQL Server ................. 34 3.2.3 Le serveur dapplication JBOSS ................................................................... 34 3.2.4 Le Framework Struts 2 ................................................................................... 34 3.2.5 Les Java Server Pages.................................................................................... 36 3.2.6 Java script ...................................................................................................... 36 3.2.7 Les bibliothques des balises ......................................................................... 36 3.2.8 Les expressions langages ................................................................................ 36 3.3 ARCHITECTURE LOGICIELLE DU SYSTEME.................................................................... 37 3.4 PRESENTATION DES INTERFACES ................................................................................. 40 ANNEXES ................................................................................................................................. 50 ANNEXE A : CONFIGURATION DUN PROJET STRUTS2 ............................................. 51

Introduction gnrale

Introduction gnrale
Dans le monde daujourdhui qui est de plus en plus rgi par les lois de linformatisation et les nouvelles technologies de linformation vu sa performance et son efficacit, les entreprises et les socits marocaines ont opt pour une stratgie dinformatisation afin de profiter de ces technologies de linformation ainsi que de mettre jour les services prsents et effectuer un profit maximum.

En vertu de cette stratgie, Cooper Pharma intgre des applications informatiques et met en place un systme dinformation qui permet lanalyse et la diffusion de linformation utile pour ces besoins, dans le but de faciliter le droulement du travail au sein de cette dernire. Cest dans ce cadre que sinscrit notre stage de fin danne qui cible concevoir et dvelopper une application web pour la gestion des interventions et du parc informatique. Le prsent rapport dcrit lessentiel du travail ralis lors de ce projet. Il comporte trois chapitres. Le premier dfinit le contexte gnral du projet, savoir, la prsentation de lorganisme daccueil, une dfinition du travail et des outils collaboratifs, ainsi que la prsentation du projet. Le deuxime chapitre dcrit lanalyse et la conception du futur systme. Quant au troisime et dernier chapitre, il prsente une description dtaille de la phase de la mise en uvre du projet.

Chapitre 1

Contexte gnral du projet

Chapitre 1
Contexte gnral du projet
Ce chapitre dcrit lenvironnement dans lequel le projet a t initi et ce afin davoir une meilleure comprhension de ce dernier. La premire section sera ddie lorganisme daccueil, savoir Cooper Pharma. Ensuite, nous allons dfinir lobjectif du projet travers le besoin les objectifs et les contraintes

Chapitre 1

Contexte gnral du projet

I. Contexte Gnrale du projet

1.1 Prsentation de lorganisme daccueil
1.1.1 Prsentation

Cooper Pharma est une socit marocaine de coopration pharmaceutique qui fabrique un grand nombre de produits: 200 spcialits sous 250 prsentations aussi bien pour sa gamme propre que pour le compte des commettants qui ne cessent de lui renouveler leur confiance et leur fidlit. Ses produits sont fabriqus dans ses diffrents sites et plusieurs des produits fabriqus par Cooper Pharma sont leaders au niveau national. 1.1.2 Activits

Lactivit de Cooper Pharma est unique puisquelle a intgr trs tt dans son histoire plusieurs volets, savoir, lindustrie et la rpartition. Industrie

Aujourdhui lactivit industrielle reprsente la part la plus importante du chiffre daffaires de Cooper Pharma et se dcline en 6 ples :

Figure 1 Activit de l'industrie

Rpartition

Figure 2 Activit de rpartition

Cooper Pharma est le premier grossiste rpartiteur au Maroc renforc par ses sept filiales de rpartition dissmines travers le territoire du Royaume. 10

Chapitre 1

Contexte gnral du projet

Services

Figure 3 Activit de Service

Paralllement ses deux activits majeures, Cooper Pharma dveloppe un ple participations, industrie & services dans des secteurs tels que les biotechnologies, l'informatique et les mdias.

1.1.3

Historique

La cration de Cooper Pharma a pass par les tapes illustres dans la figure suivante :

Figure 4 Historique de Cooper Pharma

11

Chapitre 1

Contexte gnral du projet

1.2 Prsentation du projet

1.2.1 Description du besoin

Les informations de COOPER Pharma concernant les interventions et le parc informatique sont archives sur papier ce qui augmente la possibilit de les perdre, en plus cette faons de gestion augmente le temps de la recherche. Pour viter ces dfauts, COOPER Pharma nous a affect ce stage qui a pour but linformatisation du systme de gestion des interventions et du parc informatique. Lapplication dvelopper fonctionnalits suivantes : Gestion des interventions (ajout, suppression, modification) Gestion du parc informatique (ajout, affectation, dsaffectation, consultation) A ces fonctionnalits sajoute la ncessit de rpondre un certain nombre dobjectifs et contraintes en termes de scurit, de disponibilit et de maintenance. 1.2.2 Objectifs devrait offrir les

Raliser une application web qui rend transparent pour lutilisateur la gestion de la BDD. Cette interface devra tre la plus simple et intuitive possible de faon ne ncessiter aucun apprentissage particulier. Aussi la maintenance et la mise jour de cette interface devront tre faciles ds lors quon possde les fichiers sources.

Figure 5 Communisation facile entre la base de donnes et l'utilisateur

12

Chapitre 1

Contexte gnral du projet

1.2.3

Contraintes

Vu son but, lapplication doit tre constitue dune base de donnes fiable et cohrente, et dune interface facile manipuler. En effet toutes les informations sur les matriels, les fournisseurs, employs, les sites..etc. doivent tre dans une base de donnes. Pour ces raisons, lapplication raliser doit respecter des contraintes de plusieurs ordres : Du point de vue fonctionnel : -- Sauvegarde de lhistorique de toutes les dsaffectation) -- Mise jour des informations -- Recherche rapide des informations -- Respect de certaines rgles de gestion savoir : Un intervenant na le droit qu lajout dune intervention, seul ladministrateur peut effectuer les oprations de modification ou de suppression. Un intervenant ne peut consulter que les interventions concernant son matriel. Une intervention a quatre tats possibles: Envoy, En cours, Traite, Rejete Une intervention ne peut tre envoye si le matriel concerne une autre intervention en cours ou envoye. Du point de vue interface homme machine : -- Interface claire, rationnelle, scurise. oprations effectues (affectation,

13

Chapitre 1

Contexte gnral du projet

Conclusion Ce chapitre a permis de mieux dfinir le primtre du projet. Nous avons pu connaitre lorganisme daccueil. Ensuite, nous sommes passs la prsentation du projet travers la description du besoin et la dfinition des rgles de gestion. Le chapitre suivant est consacr lanalyse et la conception du projet.

14

Chapitre 2
Analyse et conception
Ce chapitre dcrit lessentiel du travail effectu durant lanalyse et la conception du projet. Nous dcrivons laspect fonctionnel travers les diagrammes de cas dutilisations et des squences. Puis, nous terminons le chapitre par les diffrents diagrammes de classes qui dcrivent la structure interne du systme.

15

Chapitre 2

Analyse et conception

II.

Analyse et conception
2.1. Description des fonctionnalits
2.1.1 Description des modules

Nous avons choisi darticuler larchitecture fonctionnelle sur deux modules : Gestion des interventions Gestion du parc informatique 2.1.1.1 Module de gestion des interventions En cas de panne du matriel, tout utilisateur peut envoyer une demande dintervention ladministrateur qui fait partie du service informatique .Lenregistrement dune demande est conditionne par la satisfaction des rgles de gestion cites prcdemment. Lintervenant traite la demande et enregistre la rponse dans la BDD. 2.1.1.2 Module de gestion du parc informatique Les quipements au sein de lentreprise sont de diffrentes catgories (poste, imprimante, logiciel, tlphone). Ladministrateur va pouvoir : ajouter un matriel au stock en spcifiant les caractristiques de lquipement selon son catgorie Affecter un quipement un ou plusieurs utilisateurs. Consultation du stock

2.1.2 Identification des acteurs

Nous avons pu identifier deux acteurs potentiels de lapplication savoir ladministrateur et lutilisateur normal. Le tableau suivant illustre le rle de chaque un deux :

ActeurIII.
Administrateur

Rle
-Traitement des interventions. -Modification et consultation des interventions. -Gestion des quipements.

16

Chapitre 2

Analyse et conception

Utilisateur normal

-Etablissement des demandes dinterventions. -Consultation des interventions envoyes.

Tableau 1Les acteurs du systme

2.2. Modlisation UML

2.2.1 Choix dUML
UML (en anglais Unified Modeling Language ou langage de modlisation unifi ) est un langage de modlisation graphique base de pictogrammes. Il est apparu dans le monde du gnie logiciel, dans le cadre de la conception oriente objet . Couramment utilis dans les projets logiciels, il peut tre appliqu toutes sortes de systmes ne se limitant pas au domaine informatique. UML possde plusieurs facettes. C'est la fois une norme et un langage de modlisation objet. Cest une norme car UML offre la possibilit de s'exprimer clairement : en reprsentant des concepts abstraits et en limitant les ambiguts (parler un langage commun, au vocabulaire prcis, indpendant des langages orients objet). Cest galement un langage graphique qui sappuie sur la technologie objet et les concepts quelle vhicule. Il peut donc tre utilis dans diffrentes mthodes. Enfin, cest un support de communication, il constitue une base de discussion entre tous les acteurs dun projet.

2.2.2 Cas dutilisation

Les cas d'utilisation permettent de reprsenter le fonctionnement du systme vis--vis de l'utilisateur : c'est donc une vue du systme dans son environnement extrieur. En se basant sur les fonctionnalits que devra assurer notre application, nous avons pu dgager les diffrents scnarii, et ainsi identifier les cas dutilisation suivants :

Cas dutilisation Ajoute dune demande dintervention et consultation

Acteurs Utilisateur normal

Scnario du cas
-Soumettre une demande -Consulter ses interventions envoyes -Modifier

Traiter une demande dintervention

17

Administrateur

Chapitre 2

Analyse et conception

Gestion du parc informatique

Administrateur

une demande -Rpondre une demande -Ajouter un matriel au stock

-Modifier un matriel -Affecter un matriel un utilisateur Authentification

Sauthentifier

Tableau 2 Les cas d'utilisation

Nous avons donc abouti au diagramme de cas dutilisation suivant :

Figure 6 Diagramme de Cas d'utilisation

Gestion du parc informatique : Ladministrateur se charge de grer le parc informatique. Aprs lauthentification ladministrateur choisit loption ajouter un matriel et accde au 18

Chapitre 2

Analyse et conception

formulaire dajout pour saisir les informations ncessaire et les enregistrer dans la BDD. Il gre aussi les affectations du matriel aux utilisateurs au sein de lentreprise. Traitement des interventions : Ladministrateur se charge de traiter les interventions demandes par lutilisateur en changeant leur statut Envoye par En cours , Traite ou Refuse .Ladministrateur peut ventuellement faire des oprations de modification ou de suppression. Ajout dune demande dintervention et consultation: Un utilisateur normal peut accder au formulaire dajout dune intervention aprs lopration de lauthentification. Il peut aussi consulter lhistorique de ses demandes dintervention sans avoir le droit de les modifier.

2.2.3 Diagramme de squence

Les diagrammes de squence sont des diagrammes dinteractions qui permettent de modliser les scnarii. Ils ont pour objectif de mieux reprsenter les interactions entre les objets de notre projet selon un point de vue temporel. Ainsi, nous prsentons titre indicatif trois exemples de diagrammes de squence dcrivant quelques scnarii dutilisation. Authentification Le premier diagramme de squence illustr dans la figure ci-dessous correspond au scnario commun tous les utilisateurs. En effet, chaque utilisateur normal peut accder lapplication sans avoir besoin dun mot de passe. Or un administrateur, aprs la slection de son nom dans la liste des utilisateurs doit saisir un mot de passe pour avoir accs toutes les fonctionnalits de lapplication.

19

Chapitre 2

Analyse et conception

Figure 7 : Diagramme de squence d'authentification

Lorsquun utilisateur accde lapplication, Il choisit lutilisateur et le dpartement travers les listes droulantes. Sil sagit dun utilisateur normal il peut entrer immdiatement aprs son choix pour accder un menu qui dpende de ses rles chargs lors de la connexion. Sinon (administrateur) un mot de passe sera requis.

20

Chapitre 2

Analyse et conception

Ajout dune demande dintervention Le diagramme ci-dessous illustre le scnario du cas dutilisation ajouter une demande dintervention .

Figure 8 Diagramme de squence d'ajout d'une demande d'intervention

Pour ajouter une demande dintervention, lutilisateur choisit la catgorie de lquipement avant de slectionner son libell puis il remplit le reste du formulaire. Une fois la validation est effectue lopration sera russie.

21

Chapitre 2

Analyse et conception

Ajout dun quipement Le diagramme ci-dessous illustre le scnario du cas dutilisation ajouter un quipement.

Figure 9 Diagramme de squence de l'ajout d'un quipement

Pour ajouter un matriel au parc, ladministrateur remplit les informations communes tout quipement puis il slectionne la catgorie (poste, logiciel, imprimante, tlphone)pour saisir les informations particulires. Une fois les informations sont valides lopration sera effectue avec succs. 22

Chapitre 2

Analyse et conception

2.2.4 Diagramme de classe

Dans ce paragraphe, nous allons dcouvrir les principales classes auxquelles a abouti lanalyse des donnes. Compte tenu des spcifications tablies dans les chapitres prcdents et la ralisation du dictionnaire des donnes, notre diagramme de classes est constitu des classes listes dans le tableau 2 suivant: Name Action Action model Affectation Affectation model Affectation service Application action Autorisation Connect DAO Dpartement Dpartement model Equipement Equipement sevice Historique Affectation Historique affectation model Imprimante Imprimante model Intervention Intervention model Intervention service Logiciel Logiciel model Marque Menu Commentaire Bean des proprits des actions dun utilisateur. Manipulation de la base de donnes Classe des proprits des affectations Manipulation de la base de donnes Grer laction daffectation Contient les champs saisis dans la jsp avec les setters et getters ainsi que les mthodes d'action qui vont traiter tous les formulaires Class des pro Bean de gestion de connexion la base de donnes Classe gnrique de gestion des donnes Bean des proprieties du dpartment dun utilisateur Manipulation de la base de donnes Bean des proprieties des equipements Grer les actions relatives aux quipements Bean des proprieties de lhistorique des affectations Manipulation de la base de donnes

Bean des proprieties des imprimantes Manipulation de la base de donnes Bean des proprieties des interventions Manipulation de la base de donnes Grer les actions relatives aux interventions Bean des proprieties des logiciels Manipulation de la base de donnes Bean des proprieties des marques dun quipement Bean des proprieties des menu 23

Chapitre 2

Analyse et conception

Menu model Modle Poste Poste model Profil Profil Model Telephone model Tlphone Utilisateur Utilisateur model Utilisateur service

Manipulation de la base de donnes Bean des proprieties dun modle dun quipement Bean des proprieties dun poste Manipulation de la base de donnes Bean des proprieties des profils des utilisateurs Manipulation de la base de donnes Manipulation de la base de donnes Bean des proprieties des tlphones Bean des proprieties des utilisateurs Manipulation de la base de donnes Grer les actions relatives aux utilisateurs
Tableau 3 Les classes du systme

Le schma suivant reprsente le diagramme de classes :

24

Chapitre 2

Analyse et conception

Figure 10 Diagramme de classes

25

Chapitre 2

Analyse et conception

Pour garantir plus de visibilit et de clart dans les diagrammes, nous ne prsentons pas toutes les classes dans la mme figure. Le schma de la figure suivante illustre le diagramme de classes concernant la gestion des interventions.

Figure 11 Diagramme des classes relatif la gestion des interventions

La classe intervention a deux types dassociation avec un utilisateur car un utilisateur peut soit envoyer une ou plusieurs interventions (metteur) ou traiter une intervention (rparateur)

26

Chapitre 2

Analyse et conception

Le schma de la figure suivante concerne la gestion des quipements

Figure 12 Diagramme des classes relatif la gestion des quipements

27

Chapitre 2

Analyse et conception

La classe Equipement est une

classe gnrique qui contient toutes les

informations communes aux diffrents matriels de lentreprise. De cette classe hrite les classes Poste , Imprimante , Logiciel et Tlphone . La figure suivante est le diagramme de classe relatif au patern DAO :

Figure 13 Diagramme de classe relatif au pattern DAO

La classe gnrique DAO utilise la classe Connect qui se charge de la gestion de la connexion la base de donnes. Ce pattern permet en gnral de garantir laccs la base de donnes.

2.3. Conception de la base de donnes 2.3.1 Modle conceptuel de donnes

A partir du modle notre diagramme de qui est notre diagramme de classe nous avons pu aboutir ce diagramme conceptuel de donnes 28

Chapitre 2

Analyse et conception

Figure 14 Modle conceptuel de donnes

29

Chapitre 2

Analyse et conception

Conclusion Ce chapitre rsume le travail effectu lors des tapes danalyse et de conception de la solution mise en place. Dabord, Nous avons commenc par prsenter les acteurs du systme en dcrivant leurs rles et leurs principales tches. Ensuite, nous avons dcri les diffrentes fonctionnalits du systme avant de passer aux diffrents diagrammes dUML pour mieux comprendre les fonctionnalits offertes et mieux reprsenter la communication entre les diffrents objets du projet. Le chapitre suivant dcrira la phase de ralisation et la mise en uvre du projet.

30

Chapitre 3
Ralisation et mise en uvre
Ce chapitre concerne limplmentation du la solution. La premire et la deuxime section sont consacres la description de lenvironnement ainsi que les outils de dveloppement utiliss. Nous dcrivons, par la suite, larchitecture technique de lapplication avant de terminer par la prsentation de quelques interfaces dutilisation.

31

Chapitre 3

Ralisation et Mise en uvre

III.

Ralisation et mise en uvre 3.1. Environnement de dveloppement

3.1.1. La plateforme J2EE Llaboration de notre application sappuie sur la plateforme J2EE (Java 2 Enterprise

Edition) qui est une norme propose par la socit Sun, porte par un consortium de socits internationales, visant dfinir un standard de dveloppement d'applications d'entreprises multi-niveaux, bases sur des composants. On parle gnralement de plate-forme J2EE pour dsigner l'ensemble constitu des services (API) offerts et de l'infrastructure d'excution. J2EE comprend notamment : Les spcifications du serveur d'application, c'est--dire de l'environnement d'excution : J2EE dfinit finement les rles et les interfaces pour les applications ainsi que l'environnement dans lequel elles seront excutes. Ces recommandations permettent ainsi des entreprises tierces de dvelopper des serveurs d'application conformes aux spcifications ainsi dfinies, sans avoir redvelopper les principaux services. Des services, au travers d'API, c'est--dire des extensions Java indpendantes permettant d'offrir en standard un certain nombre de fonctionnalits. Sun fournit une implmentation minimale de ces API appele J2EE SDK (J2EE Software Development Kit). Dans la mesure o J2EE s'appuie entirement sur le langage Java, il bnficie des avantages et inconvnients de ce langage, en particulier une bonne portabilit et une maintenabilit du code. Ce choix est justifi par plusieurs facteurs savoir : La maturit et la richesse de cette technologie ; La possibilit de la rutilisation des diffrents composants qui en font partie ; La sparation forte quoffre la plupart des frameworks relevant de cette architecture ; 32

Chapitre 3

Ralisation et Mise en uvre

3.1.2. Larchitecture MVC II La plateforme adapte pour le dveloppement de ce projet est la plateforme J2EE. Celle-ci offre une panoplie doutils et de frameworks permettant la mise en place dune architecture fiable et volutive. Le modle le mieux adapt ce type de projet est le modle MVC II: la nouvelle version simplifie du MVC (Modle - Vue Contrleur). En effet, Le modle MVC cherche sparer les couches prsentation, traitement et accs aux donnes, ce qui assure la clart de larchitecture et simplifie la tche du dveloppeur responsable de la maintenance et de lamlioration du projet. Toutefois MVC peut se rvler lourd mettre en place. Ceci cause de la multitude de contrleurs implmenter. Dans MVC II, il n'existe plus qu'un seul et unique contrleur rceptionnant toutes les requtes clientes. Le contrleur unique devient le point dentre exclusif de lapplication. Il devient alors trs ais de centraliser la gestion des accs, des droits, des statistiques ou de toute autre fonctionnalit transverse. Les diffrentes interactions entre les modle, les vue et le contrleur sont rsumes par le schma de la figure suivante :

Figure 15 Architecture MVC 2

33

Chapitre 3

Ralisation et Mise en uvre

3.2 Outil de dveloppement

3.2.1. Environnement de dveloppement intgr : Eclipse Eclipse est un environnement de dveloppement intgr libre extensible, universel et polyvalent, permettant de crer des projets de dveloppement mettant en uvre n'importe quel langage de programmation. Eclipse IDE est principalement crit en Java ( l'aide de la bibliothque graphique SWT, d'IBM), et ce langage, grce des bibliothques spcifiques, est galement utilis pour crire des extensions. La spcificit d'Eclipse IDE vient du fait de son architecture totalement dveloppe autour de la notion de plugin (en conformit avec la norme OSGi) : toutes les fonctionnalits de cet atelier logiciel sont dveloppes en tant que plug-in. 3.2.2 Systme de gestion de bases de donnes : Microsoft SQL Server SQL Server est un systme de gestion de base de donnes (SGBD) dvelopp et commercialis par Microsoft. . Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, au mme titre que Oracle ou MySQL. 3.2.3 Le serveur dapplication JBOSS Jboss est un serveur d'applications J2EE Libre entirement crit en Java, publi sous licence GNU LGPL. Parce que le logiciel est crit en Java, JBoss Application Server peut tre utilis sur tout systme d'exploitation fournissant une machine virtuelle Java (JVM). 3.2.4 Le Framework Struts 2 Struts 2 est un Framework de dveloppement dapplications Web en Java permettant de respecter le modle darchitecture MVC II. Il repose sur une dclaration de l'architecture sous forme de fichiers XML ou avec des annotations Java localises dans les fichiers des classes d'actions. Struts 2 est un framework orient actions. Les actions sont dcomposes en trois rles. Premirement, les actions jouent le rle le plus important du framework en encapsulant le traitement et le travail raliser par le service. Deuximement, les actions permettent de manipuler automatiquement les donnes des requtes lors des transferts. Troisimement, le framework dtermine quel rsultat doit tre retourn et la vue afficher en rponse un traitement. Les actions Struts 2 implmentent des objets JavaBeans (classes Java simples) pour chaque groupe de donnes envoyes dans la requte. Chaque paramtre de la requte est dclar dans la classe d'action avec un nom identique pour raliser 34

Chapitre 3

Ralisation et Mise en uvre

automatiquement le mapping des valeurs. La finalit d'une action tant de retourner une chane de caractres permettant de slectionner le rsultat afficher. Pour rsumer, Struts2 permet un dveloppement plus rapide, plus souple et rsout plusieurs problmes de conception en fournissant les services suivants : Un systme volu de gestion du routage ou navigation Un systme de validation de formulaires et d'entres, simple mettre en oeuvre Un systme puissant de plug-ins ou d'extensions (pour les graphiques, sources de donnes...) La gestion de l'internationalisation pour le dveloppement de sites multilingues Le support de la technologie Ajax Un outil de dbogage en standard Une bibliothque puissante de balises Le fonctionnement de Struts 2 est rsum dans le schma de la figure suivante :

Figure 16 Fonctionnement de Struts2

35

Chapitre 3

Ralisation et Mise en uvre

3.2.5 Les Java Server Pages Les JSP (Java Server Pages) sont une technologie Java qui permettent la gnration de pages web dynamiques. La technologie JSP permet de sparer la prsentation sous forme de code HTML et les traitements sous formes de classes Java dfinissant un bean ou une servlet. Ceci est d'autant plus facile que les JSP dfinissent une syntaxe particulire permettant d'appeler un bean et d'insrer le rsultat de son traitement dans la page HTML dynamiquement. 3.2.6 Java script JavaScript est un langage objet : chaque objet possde des mthodes (ou fonctions), des proprits et des objets. Dans une page Web, l'objet le plus lev dans la hirarchie est la fentre du navigateur : window. Cet objet window contient entre autres l'objet document qui lui-mme contient tous les objets contenus dans la page Web (paragraphes, formulaires, etc...). En plus de ces objets, il existe des objets crs par l'utilisateur.

Les mthodes sont des fonctions qui permettent d'agir sur certaines proprits de l'objet, les proprits contiennent les paramtres d'un objet. 3.2.7 Les bibliothques des balises Ils servent rpondre des besoins particuliers pour nos applications. De mme, lorsquun programmeur a conu une bibliothque de balises, les dveloppeurs peuvent ensuite sen servir dans leurs pages JSP sans connatre le dtail de leur implmentation. Ces balises dynamiques sutilisent de la mme manire que les balises HTML, le partage des tches entre programmeurs et concepteurs de linterface devient beaucoup plus clair. Linterface SimpleTag et la classe SimpleTagSupport permettent dimplmenter tous les gestionnaires de balises JSP 2.0, avec ou sans itration et valuation du corps. Pour utiliser une action personnalise, il suffit de crer une classe qui tend la classe de base SimpleTagSupport et redfinir les mthodes ncessaires pour produire le comportement souhait. 3.2.8 Les expressions langages Expression Language permet d'accder facilement aux donnes stockes dans l'application des composants JavaBeans. La raison de leur utilisation est que linterface

36

Chapitre 3

Ralisation et Mise en uvre

SimpleTag de la version 2.0 des JSP ne permet plus dexploiter du code JSP dans le corps des balises personnalises.

3.3 Architecture logicielle du systme

Parmi les diffrentes faons de structurer une architecture, la mieux comprise et matrise en informatique est lapproche par couches. Une couche (Layer en anglais) est une division logique, horizontale dun systme qui fournit une abstraction particulire du systme aux couches suprieures. Chaque couche possde des rles spcifiques. Dans une structuration par couches, les couches infrieures prennent en charge des rles qui offrent un fonctionnement de base pour les couches suprieures, permettant par la suite dabstraire limplmentation de ces services basiques. Ainsi, nous avons adopt un dcoupage en 5 couches. Une telle architecture permet galement dobtenir un bon niveau de rutilisation, travers lutilisation des solutions aux problmes ayant un fonctionnement similaire. Cette exploitation est prise en compte pour chaque couche de larchitecture. La figure suivante rsume le dcoupage adopt :

Figure 17 Architecture logicielle du systme

37

Chapitre 3

Ralisation et Mise en uvre

Couche prsentation

Cette couche contient les composants qui doivent interagir avec l'utilisateur de l'application, comme les pages Web, les formulaires, ainsi que tout ce qui rgit le comportement de l'interface utilisateur comme les validators. Affichage des pages Web Rles Gestion de l'interaction avec l'utilisateur Validation syntaxique Demandes de contenu la couche Application pour affichage / dition Relations Ordres de traitement la couche Application pour cration / mise jour / suppression
Tableau 4 Rles et relations de la couche prsentation

Couche Application :

Son principal but est de fournir des services spcifiques la couche Prsentation. Ces services correspondent aux rgles du mtier dfinies lors de la phase danalyse. Elle prend en charge les aspects de contrle des cas d'utilisation. La communication avec la couche suprieure se fait travers les managed-beans. Services spcifiques au domaine Rle s Contrle des cas d'utilisation Gestion de la scurit Relat ions Accs aux entits mtier de la couche service pour implmenter les services.
Tableau 5 Rles et relations de la couche application

Couche Service :

La couche service reoit les requtes de la couche application et traite le logique mtier contenu dans ces requtes. Cest un package qui comporte les classes charges, dune 38

Chapitre 3

Ralisation et Mise en uvre

part, de garantir la validation smantique de l'information mtier, et dautre part, de grer linteraction avec la base de donnes. La communication avec la couche Application se fait travers les interfaces services. Le Tableau suivant rsume les rles et les relations de la couche Service : Comportement mtier Rles Validation smantique Echange de l'tat des composants entits mtier avec la couche DAO.
Tableau 6 Rles et relations de la couche service

Relations

Couche DAO

Cette couche est certainement l'une des plus importantes, cest ici o se trouve les fonctionnalits de base qui permettent de crer, rechercher, modifier et supprimer les entits mtier dans le respect des proprits transactionnelles. Cest galement dans cette couche que les mcanismes de conversion objet/relationnel peuvent en partie prendre place. Le suivant rsume les rles et les relations de la couche DAO : Rle s Rela tions service.
Tableau 7 Rles et relations de la couche DAO

tableau

Services basiques de Cration / Lecture / Mise jour / Suppression Conversion Objet/Relationnel Echange de l'tat des composants entits mtier avec la couche

Couche Stockage

Cette couche est responsable du stockage physique de donnes. Elle assure le support transactionnel. En ce qui concerne notre systme, cette couche se basera sur le modle relationnel. La base de donnes est gnre partir dun script SQL.

39

Chapitre 3

Ralisation et Mise en uvre

3.4 Prsentation des interfaces

Lobjectif de ce paragraphe est de donner un aperu de linterface homme/machine de lapplication. La page dauthentification :

Figure 18 La page d'authentification

La page daccs lapplication demande lutilisateur de choisir le dpartement tout dabord pour slectionner ensuite sans nom en utilisant la technologie Ajax. Sil sagit dun utilisateur normal la connexion va se produire sans une demande de saisi du mot de passe. Dans le cas o lutilisateur est un administrateur qui fait partie du dpartement SI, un champ obligatoire va paraitre pour saisir le mot de passe. Cette page a pour but dveiller la curiosit de lutilisateur dcouvrir lensemble des fonctionnalits offertes. Si lutilisateur demande la connexion sans avoir choisi son nom ou saisie un mot de passe non valide, un message derreur en informe lutilisateur. Cette page permet laccs la page daccueil qui propose des fonctionnalits diffrentes dpendamment du rle de lutilisateur.

40

Chapitre 3

Ralisation et Mise en uvre

La page dajout dune demande dintervention:

Figure 19 Page d'ajout d'une intervention

Linterface dajout dune demande dintervention est trs simplifie pour que lutilisateur puisse remplir une demande dans un temps rduit. Il ne remplit que la catgorie pour choisir selon cette dernire (en utilisant la technologie Ajax) que les quipements qui leur est affect, il saisit ensuite le besoin pour lequel lintervention est envoye. En cas o aucun quipement nest slectionn ou lquipement choisit est dj en cours dintervention un message derreur sera affich.

41

Chapitre 3

Ralisation et Mise en uvre

Consultation des interventions

Figure 20 La Page de recherche des interventions

Cette page permet la recherche des interventions selon plusieurs critres comme le montre la figure. Une fois les critres sont saisies la liste des interventions saffiche. Cette liste dpend de lutilisateur authentifi. En effet, sil sagit dun utilisateur normal, il ne peut consulter que les interventions sur son matriel et il ne peut rien modifier alors que ladministrateur peut voir et modifier toutes les interventions. Dans le cas o il veut traiter une intervention il clique sur le numro de la ligne concerne dans le tableau pour se dplacer vers la page suivante :

42

Chapitre 3

Ralisation et Mise en uvre

Figure 21 La page de traitement des interventions

Cette page permet ladministrateur seulement de traiter lintervention en saisissant son commentaire la dure de la ralisation et le statut. Le nom de lintervenant ne sera pas saisit mais il sera rcupr de la session.

43

Chapitre 3

Ralisation et Mise en uvre

La page dajout dun matriel:

Figure 22 La page d'ajout d'un quipement (informations communes)

Cette page permet lutilisateur de saisir les informations communes tous les quipements. En choisissant la catgorie une nouvelle partie dans la page apparait pour saisir les informations qui concernent la catgorie choisie. Voici lexemple de la catgorie Poste :

Figure 23 Informations sur un matriel selon la catgorie Poste

44

Chapitre 3

Ralisation et Mise en uvre

La page daffectation:

Figure 24 La page d'affectation

Cette interface permet lutilisateur dajouter plusieurs affectations la fois en cliquant sur le bouton plus cot de chaque ligne. Lopration ajoute dans la table affectation lutilisateur et lquipement slectionne et dans la table historique_affectation lutilisateur, lquipement, le responsable de lopration qui se rcupre de la session et la date du systme comme date de modification.

45

Chapitre 3

Ralisation et Mise en uvre

La page de dsaffectation:

Figure 25 La page de dsaffectation

Dans la page de la dsaffectation lutilisateur peut effectuer une recherche selon lutilisateur ou lquipement pour voir la liste des affectations dans la page suivante dans laquelle il peut slectionner les affectations quil veut supprimer travers les cases cocher. La page de lhistorique des affectations:

Figure 26La page de l'historique des affectations

46

Chapitre 3

Ralisation et Mise en uvre

Conclusion Ce chapitre a dcrit la dernire tape du dveloppement qui est celle de la ralisation et la mise en uvre du projet. Nous avons pu voir les exigences techniques du systme avant de prsenter lenvironnement et les outils choisis. Ensuite, nous avons pu dcrire larchitecture technique de lapplication en prsentant le modle en couches. Et pour finir, nous avons donn un aperu de lapplication ralise.

47

Conclusion

Conclusion
Notre mission a consist en la conception et la ralisation dune application de gestion des interventions et des matriels informatiques. Lapplication ralise sera utilise par les employs de Cooper Pharma, elle leur donnera la possibilit de grer les interventions et les quipements dune faon plus pratique et plus facile que la gestion manuelle. La ralisation de ce projet a suivi plusieurs tapes. Nous avons commenc par dfinir les besoins et rdiger le cahier des charges. Lors de la phase de la conception, nous avons prsent les diffrents diagrammes UML pour mieux comprendre la communication entre les diffrents objets du projet. Enfin, nous avons mis en uvre notre solution. Mais malgr leffort fourni, ce travail doit tre complt afin daboutir une application acheve qui permet de gnrer les tats de sorties sous forme de fichiers PDF ou Excel pour limpression ou une rutilisation possible. Notre stage fut loccasion de sinitier de nouvelles technologies tout en dcouvrant lenvironnement de Copper Pharma. Enfin, cette exprience a aiguis nos capacits danalyse et de synthse et a surtout fortifi notre motivation, notre dtermination et notre ambition.

48

Bibliographie

Bibliographie
[Brown et al, 08] Donald Brown, Chad Michael Davis et Scott Stanlick, Struts 2 in Action, Greenwich (Connecticut), Manning Publications Co., 2008, 424 p. [Eclipse] Eclipse-jee-gelileo [Logiciel], v3.5, http://www.epclipse.org/, Disponible sur: http://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/galileor, 29 septembre 2010 [Jboss] JBoss Application Server [Logiciel], v4.2.3, http://www.jboss.org, disponible sur: http://www.jboss.org/jbossas/downloads/, 29 septembre 2010 [Lafosse, 09a] Jrme Lafosse, Java EE Guide de dveloppement d'applications web en java, Paris, ENI Editions, 2009, 507p. [Lafosse, 09b] Jrme Lafosse, Struts 2 Le framework de dveloppement d'applications Java EE, Paris, ENI Editions, 2009, 342 p. [Roughley, 07] Ian Roughley, Practical Apache Struts2 Web 2.0 Projects, New York City, Apress, 2007, 362 p. [UML2] UML 2.1.2, http://www.uml.org/, [En ligne] sur :

http://www.omg.org/spec/UML/2.1.2/, 29 septembre 2010 [wwwCCM] la prsentation de java entreprise edition, [En ligne], Disponible sur: http://www.commentcamarche.net/contents/j2ee/j2ee-intro.php3, 29 septembre 2010 [wwwDEV] Portails de dveloppeurs, [En ligne], Disponible sur:

http://www.developpez.com, 29 septembre 2010 [wwwRoseIndia] Struts 2 Tutorial,Struts2 Examples,Apache Struts 2 Tutorials - Free Java Programming Tutorials, [En ligne], Disponible sur:

http://www.roseindia.net/struts/struts2/, 29 septembre 2010 [wwwOlivier-guillou] Struts 2 Tutorial, [En ligne], Disponible sur: http://www.olivier-guillou.fr/oneandcie/tutoriel-pour-bien-commencer-avec-struts-2 , 29 septembre 2010 49

Annexes

Annexes

50

Annexe A : Configuration dun projet Struts2

Annexe A : Configuration dun projet Struts2

51

Annexe A : Configuration dun projet Struts2

Introduction [wwwOlivier-guillou] Struts 2 est un framework de dveloppement. Il comprend un ensemble de bibliothques qui facilitent le dveloppement des interfaces web. Struts2 est un framework orient action architectur en xml. Ses Actions permettent daccder aux diffrents Services tel le Model et dterminent ce que la Vue doit afficher aprs leur traitement (traitement des actions par struts.xml). Les actions struts 2 implmentent des objets java appels Beans pour chaque donne envoye via les formulaires. Struts repose sur un modle de conception dis MVC 2 (Modle Vue Contrleur). Ce framework fournit un certain nombre de services tels le dbogage, les validateurs de formulaire, la gestion de la navigation ou encore la gestion de linternationalisation. Les rgles et convention de dveloppement en J2EE et Struts 2 Rgle 1 : Ne pas utiliser de java dans la vue. Rgle 2 : Utiliser de prfrence les taglib de struts 2 <s:/> Rgle 3 : Utiliser les validateur du framework et sa logique. Le descripteur de dploiement web.xml Cest le fichier central dun projet JEE. Il contient les paramtres et caractristiques de lapplication. Il doit tre prsent dans le dossier webContent/WEB-INF (webContent tant le rpertoire root de lapplication). Voici ses principales caractristiques : Voici un fichier type web.xml pour struts2.

52

Annexe A : Configuration dun projet Struts2

Figure 27 Exemple d'un fichier web.xml

Le contrleur strust.xml Le fichier Struts.xml, hrite dun fichier plus important : struts-default.xml qui dfinit un ensemble de mcanismes par dfaut. Je ne prsenterais pour le moment que le fichier struts.xml que vous devez placer la racine de votre rpertoire scr , racine de votre rpertoire de classes. Ce fichier sert principalement au routage de vos actions et la navigation.

53

Annexe A : Configuration dun projet Struts2

Figure 28 L'architecture d'un projet Struts 2

Voici son contenu :

Figure 29 Exemple d'un fichier struts.xml

54