Vous êtes sur la page 1sur 121

Royaume du Maroc Universit Mohammed V - Souissi cole Nationale Suprieure dInformatique et dAnalyse des Systmes - ENSIAS

Mmoire de Projet de Fin dtudes


Pour lObtention du Titre dIngnieur dtat en Informatique
Option : Gnie Logiciel

Sujet

Conception et ralisation dun serveur de change de devises en libre service pour Wincor Nixdorf

Soutenu par : Najib SAFIR

Sous la direction de : M. Ahmed ETTALBI M. Khalid SAADAOUI

Anne universitaire 2004 2005

Ddicace
A mes trs chers parents;
Les mots ne peuvent exprimer ma gratitude envers tout ce que vous avez fait pour moi.

A ma sur et mes frres


Ilham, Nabil et Rda

A toute ma famille A ma chre amie Amina

A mes chres surs et mes frres de lENSIAS A tous mes amis de Mekns
Pour tous le soutient que vous mavez offert, je vous dis Merci

A tous ceux qui maiment


Je ddie ce travail Najib

Remerciements

ProChangeServer@WINCOR-NIXDORF

Remerciements
Il mest agrable dexprimer ma reconnaissance auprs de toutes les personnes, dont lintervention au cours de ce projet, a favoris son aboutissement. Je tiens exprimer ma gratitude M. Khalid SAADAOUI, mon encadrant WINCOR-NIXDORF, pour ses directives prcieuses et ses conseils pertinents qui mont appuy considrablement dans ma dmarche. Mes remerciements les plus sincres M. Ahmed ETTALBI, mon encadrant lENSIAS, pour les conseils quil a prodigu, son judicieux encadrement, ainsi que pour son assistance dans la rdaction du rapport. Je tiens aussi remercier tous les membres du jury qui mont fait lhonneur daccepter de juger mon travail. Je saisis aussi loccasion pour remercier M. AbdelIlah YASSIR Directeur Marketing Produits qui na mnag ni son temps ni son nergie pour aider laborer ce travail. De plus, jexprime ma profonde gratitude et je tiens remercier, tout le personnel de WINCOR-NIXDORF pour leur soutien et pour leur gnrosit considrable quant loffre de linformation. Je profite de loccasion pour remercier le cadre professoral de lENSIAS, pour la formation prodigieuse quils mont prodigue. Que tous ceux qui mont aid, de prs ou de loin, trouvent ici lexpression de mes sentiments les meilleurs.

SAFIR

-1-

ENSIAS 2004/2005

Abstract

ProChangeServer@WINCOR-NIXDORF

Abstract
This document is produced during my end-study project within WINCORNIXDORF Corporation. As objective, I had to conceive and develop software that exchanges currencies in self-service. The ProChangeServer must be able to carry out all transactions data from remote Automatic Teller Machines and integrate them into the bank daily accountant. As a consequence, the data will be organized and structured. So it can be used later easily. Furthermore, the software offers an administration console to manage all resources. To that purpose, I take advantage of Y life cycle (2TUP) and I used the UML language for the system modelling. The software is a Web technologies based solution. In fact, I used several Frameworks under the J2EE platform: Struts for Web Presentation, Hibernate for Object/Relational mapping, JasperReports for Report, Log4j for logging and JAAS API for security. The software stands on JBoss Application Server and uses Oracle 9i relational Database. In this document, I will explain more in detail each step I passed in order to accomplish that work.

SAFIR

-2-

ENSIAS 2004/2005

Rsum

ProChangeServer@WINCOR-NIXDORF

Rsum
Ce rapport est le fruit du travail que jai ralis dans le cadre de mon projet de fin dtude au sein de la socit WINCOR-NIXDORF. Ce projet avait pour objectif de concevoir et de dvelopper une solution de change de devises en libre service. Le projet ProChangeServer doit permettre la rcupration des donnes des transactions effectues quotidiennement par les Guichets Automatiques Bancaires pour les intgrer dans lcriture comptable de la banque. La solution apporte permettra lorganisation de ces donnes pour une meilleure exploitation. De plus, elle permet la supervision de ces guichets. Lapplication offre aussi une console dadministration pour grer ses ressources. Pour le dveloppement du projet, jai suivi le cycle de dveloppement en Y (2TUP). Pour la modlisation du systme, jai utilis le langage UML. La ralisation du projet est base sur les nouvelles technologies du Web. En effet, jai eu recours plusieurs Frameworks traitant plusieurs aspects du dveloppement sous la plate-forme J2EE. Jai donc utilis le Framework Struts pour la prsentation Web, le Framework Hibernate pour le mapping objet/relationnel, le Framework JasperReports pour lditions des rapports, le Framework Log4j pour la journalisation et lAPI JAAS pour la scurit. Le systme tourne sur le serveur dapplication JBoss AS et utilise le systme de gestion de base de donnes relationnelle ORACLE 9i. Le prsent rapport permet de prsenter les diffrentes tapes par lesquelles je suis pass afin de raliser le travail qui ma t confi.

SAFIR

-3-

ENSIAS 2004/2005

Liste des abrviations

ProChangeServer@WINCOR-NIXDORF

Liste des abrviations


Abrviation 2TUP AO API ATM BMP CMP CORBA EJB GAB GPL IDE IHM J2EE JAAS JDBC JNDI JSP LGPL MAD MVC OMG PAQ RUP SGBDR SWT UML URL WSW XML Designation 2 Track Unified Process Aspect Orientation Application Programming Interface Automatic Teller Machine Bean Managed Persistence Container Managed Persistence Common Object Request Broker Architecture Entreprise Java Bean Guichet Automatique Bancaire General Public License Integrated Development System Interface Homme Machine Java Second Enterprise Edition Java Authentication and Authorization Services Java Database Connectivity Java Naming and Directory Interface Java Server Pages Lesser General Public License MAroc Dirham Model View Controller Object Management Group Plan Assurance Qualit Rational Unified Process Systme de Gestion de Base de Donnes Relationnelles Standard Widget Toolkit Unified Modeling Language Uniform Resource Locator Websphere Studio Workbench eXtensible Markup Language

SAFIR

-4-

ENSIAS 2004/2005

Liste des figures

ProChangeServer@WINCOR-NIXDORF

Liste des figures


Figure 1 : organigramme de WINCOR-NIXDORF Maroc........................................................... 12 Figure 2 : canaux de distribution libre-service. ............................................................................. 13 Figure 3 : offre de solutions compltes. .......................................................................................... 14 Figure 4 : fonctions remplies par le ple service. .......................................................................... 15 Figure 5 : tude comparative des cycles de dveloppement. ...................................................... 33 Figure 6 : planning prvisionnel. .................................................................................................... 34 Figure 7 : diagramme de cas dutilisation associ lacteur dcideur. ...................................... 37 Figure 8 : diagramme de cas dutilisation associ lacteur banquier....................................... 38 Figure 9 : diagramme de cas dutilisation associ lacteur chef banquier. ............................. 39 Figure 10 : diagramme de cas dutilisation associ lacteur administrateur. ......................... 40 Figure 11 : diagramme de cas dutilisation associ lacteur guichetier. .................................. 40 Figure 12 : description textuelle du cas dutilisation mise jour du taux de change. ............. 42 Figure 13 : diagramme de squence du cas dutilisation mise jour des taux de change. ..... 43 Figure 14 : maquette du systme ProChangeServer. ................................................................... 44 Figure 15 : diagramme de squence de collecte des transactions dun GAB. ........................... 48 Figure 16 : diagramme de squence de remonte de la balance globale au serveur central de la banque. ............................................................................................................................................ 49 Figure 17 : partie du diagramme de classe associe aux transactions. ...................................... 50 Figure 18 : diagramme de package du modle danalyse. .......................................................... 51 Figure 19 : diagramme tat/transition de lobjet BalanceGAB . ............................................ 55 Figure 20 : architecture J2EE. ........................................................................................................... 59 Figure 21 : objectifs techniques de larchitecture logicielle du ProChangeServer. .................. 62 Figure 22 : objectifs techniques de larchitecture logicielle du ProChangeServer. .................. 63 Figure 23 : architecture de ProChangeServer en couches. .......................................................... 64 Figure 24 : modle MVC. .................................................................................................................. 68 Figure 25 : diagramme de collaboration relatif la collecte de transaction dun GAB. .......... 74 Figure 26 : partie du diagramme de collaboration devant tre factorise. ................................ 77 Figure 27 : factorisation du traitement en BalanceStatus . ...................................................... 78 Figure 28 : Pattern pour ladaptation de lapplication selon les paramtres de lutilisateur. . 79 Figure 29 : Pattern de manipulation de la date travers un calendrier. ................................... 80 Figure 30 : Pattern de gestion dynamique des donnes dans la page Web. ............................. 81 Figure 31 : Pattern ldition de la balance. ..................................................................................... 82 Figure 32 : Pattern dautomatisation de la collecte des balances GABs..................................... 83 Figure 33 : diagramme de package final de conception. .............................................................. 84 Figure 34 : les principaux serveurs dapplication utilisant la plate forme J2EE. ...................... 90 Figure 35 : tendance des utilisateurs du JBoss AS. ....................................................................... 91 Figure 36 : comparaison entre les IDEs de dveloppement. ....................................................... 93 Figure 37 : cran pour invoquer le statu de la balance. ................................................................ 94 Figure 38 : mappage des objets dans struts-config.xml . ........................................................ 95 Figure 39 : rcupration des informations partir de B_statusForm .................................... 95 Figure 40 : validation syntaxique des donnes. ............................................................................ 96 Figure 41 : journalisation de ltat du systme. ............................................................................. 96 Figure 42 : authentification de lutilisateur. ................................................................................... 97 Figure 43 : menu relatif ladministrateur. ................................................................................... 97 Figure 44 : cran de gestion des taux de change. .......................................................................... 98 Figure 45 : calendrier pour slectionner la date. ........................................................................... 99 Figure 46 : dition de lactivit de change.................................................................................... 100 SAFIR -5ENSIAS 2004/2005

Table des matires

ProChangeServer@WINCOR-NIXDORF

Table des matires


Remerciements ............................................................................................................ 1 Abstract......................................................................................................................... 2 Rsum ......................................................................................................................... 3 Liste des abrviations ................................................................................................. 4 Liste des figures ........................................................................................................... 5 Table des matires ....................................................................................................... 6 Introduction ................................................................................................................. 8 Chapitre 1 : Contexte gnral du projet ................................................................. 10
1. Prsentation de lorganisme daccueil ......................................................................... 11
1.1. Mission de WINCOR-NIXDORF.......................................................................................... 11 1.2. Structures et organisation de WINCOR-NIXDORF Maroc .............................................. 12

2. Prsentation du sujet ...................................................................................................... 15


2.1. Contexte du projet .................................................................................................................. 15 2.2. Objectifs du projet .................................................................................................................. 17

Chapitre 2 : tude du projet .................................................................................... 20


1. Caractristiques gnrales de ProChangeServer ....................................................... 21 2. Fonctions principales de ProChangeServer................................................................ 21
2.1 Gestion des balances des GABs ............................................................................................. 21 2.2. Prparation de la balance des GABs .................................................................................... 23 2.3. Gestion des taux de change................................................................................................... 24 2.4. Gestion des paramtres des GABs ....................................................................................... 25 2.5. Paramtres gnraux.............................................................................................................. 25

3. Fonctions optionnelles de ProChangeServer ............................................................... 29


3.1. Purge de la base de donnes ................................................................................................. 29 3.2. Purge des fichiers ................................................................................................................... 29 3.3. Traitement des rclamations ................................................................................................. 29 3.4. Univers ditions ...................................................................................................................... 30

4. Objectifs en terme de qualit .......................................................................................... 30 5. Dossier de pilotage ........................................................................................................... 31


5.1. Plan assurance qualit............................................................................................................ 31 5.2. Cycle de dveloppement ....................................................................................................... 31 5.3. Planning ................................................................................................................................... 33

Chapitre 3 : tude fonctionnelle du projet ............................................................ 35


1. Capture des besoins fonctionnels ................................................................................ 36
1.1. Services attendus de ProChangeServer ............................................................................... 36 1.2. Maquette du systme ............................................................................................................. 43

2. Analyse ............................................................................................................................ 44
2.1. Composition interne du systme ......................................................................................... 45 2.2. Construction du modle danalyse ...................................................................................... 51 2.3. Analyse du comportement des entits dgages ............................................................... 54

Chapitre 4 : tude technique du projet .................................................................. 57


1. Technologie J2EE ............................................................................................................ 58
1.1. Architecture J2EE.................................................................................................................... 59 1.2. Composants de base de J2EE ................................................................................................ 60 SAFIR -6ENSIAS 2004/2005

Table des matires

ProChangeServer@WINCOR-NIXDORF

2. Architecture logicielle du systme ............................................................................... 61


2.1. Exigences de ProChangeServer ............................................................................................ 62 2.2. Architecture logicielle de ProChangeServer ....................................................................... 63

3. Notion de Framework ................................................................................................... 66 4. Frameworks utiliss ....................................................................................................... 67


4.1. Framework Struts ................................................................................................................... 67 4.2. Framework Hibernate ............................................................................................................ 69 4.3. Framework Log4j.................................................................................................................... 70 4.4. Framework JasperReports ..................................................................................................... 71 4.5. API JAAS ................................................................................................................................. 71

Chapitre 5 : Conception du projet .......................................................................... 73


1. Reprise des scnarios ..................................................................................................... 74 2. Factorisation des traitements ........................................................................................ 76 3. Solutions adoptes ......................................................................................................... 78
3.1. Multi langage et messages .................................................................................................... 78 3.2. Saisie de la date ....................................................................................................................... 79 3.3. Affichage dynamique............................................................................................................. 80 3.4. Edition dynamique ................................................................................................................. 81 3.5. Tache planifie ........................................................................................................................ 83

4. Modle final de conception ........................................................................................... 83

Chapitre 6 : Ralisation ............................................................................................ 86


1. Outils utiliss .................................................................................................................. 87
1.1. SGBD Oracle ............................................................................................................................ 87 1.2. Serveur dapplication JBoss................................................................................................... 88 1.3. IDE Eclipse .............................................................................................................................. 91

2. Reprise des scnarios ..................................................................................................... 93 3. Interfaces de lapplication ............................................................................................. 96


3.1. Authentification ...................................................................................................................... 97 3.2. Menu ........................................................................................................................................ 97 3.3. Menu Taux de change ...................................................................................................... 98 3.4. Gestion de la date ................................................................................................................... 98 3.5. Edition des rapports ............................................................................................................... 99

Conclusion................................................................................................................ 101 Bibliographie............................................................................................................ 103 Annexe 1 : Cycle de dveloppement en Y ........................................................... 105 Annexe 2 : Plan Assurance Qualit ...................................................................... 109

SAFIR

-7-

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Introduction
Les socits de service en informatique sont les premiers acteurs du dveloppement dans le secteur des technologies de linformation. Ils se trouvent dans un contexte concurrentiel qui les pousse amliorer la qualit du service offert la commande des clients, pour pouvoir simposer dans le march. Dans cette perspective, le modle mtier libre service offre aux utilisateurs la possibilit dinteragir directement avec les systmes centraux et les bases de donnes darrire-plan de lentreprise. Parmi les solutions dactualit, qui profitent de ce modle, le change automatique des valeurs des devises trangres en valeur quivalente en devise locale. Habituellement, la procdure de change est effectue manuellement. De ce fait, elle prsente quelques dfauts, par exemple le banquier peut se tromper quand il compte de largent, aussi lchange nest disponible que lors des heures de travail des fonctionnaires des banques. De plus, les htels et les sites touristiques, qui sont les endroits concerns par la solution, sont loigns du centre de la ville, donc loin des services de base que peuvent en bnficier entre autre le change des devises trangres. Pour combler le manque observ, la socit WINCOR-NIXDORF a dcid de lancer un projet visant la ralisation dune solution de change de devises en libre service. Ce nouveau produit peut tre utilis 24h sur 24, sans arrt. De ce fait, les transactions de change peuvent tre effectues pendant la nuit et mme pendant les jours fris. Du point de vue commercial, il faut prendre linitiative et saisir cette opportunit pour devancer les concurrents en saisissant les nouvelles solutions exprimes sur le march ; le potentiel est prouv par lintrt conomique exprim par les grandes banques. Les objectifs de cette solution sont appels ProChange. La partie guichet automatique est appele ProChangeATM, elle est dveloppe part. Quant la partie Serveur qui fait lobjet de mon stage de fin dtude, elle sappelle ProChangeServer.

SAFIR

-8-

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Dans le premier chapitre de ce rapport, je vais prsenter le contexte gnral du projet. La prsentation dtaille du projet fera lobjet du deuxime chapitre. Alors que le troisime chapitre est consacr ltude fonctionnelle du projet et le quatrime ltude technique. Dans le cinquime chapitre, je vais dtailler la conception du projet. Quant au dernier chapitre, il sera rserv la phase de ralisation. En conclusion, je vais reprendre le travail ralis et je vais exposer les perspectives envisages. A la fin du rapport, je vais prsenter en complment les diffrentes annexes traitant le cycle de dveloppement Y et le plan assurance qualit.

SAFIR

-9-

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Chapitre 1 : Contexte gnral du projet

Dans ce chapitre, je vais prsenter une fiche descriptive de lentreprise au sein de laquelle jai pass mon projet de fin dtude. Je vais prsenter, aussi, le contexte du projet confi et ses objectifs atteindre.

SAFIR

- 10 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

1. Prsentation de lorganisme daccueil


1.1. Mission de WINCOR-NIXDORF
WINCOR-NIXDORF est une multinationale allemande qui est une socit de services et dingnierie industrielle et informatique. Son domaine dactivit est focalis essentiellement sur les secteurs de la Banque, de la distribution, de la Poste et des grands comptes [wwwWINCOR]. Son activit de veille technologique, renforce par les retours dexprience, a permis WINCOR-NIXDORF de rester en permanence lavant-garde des technologies industrielles et informatiques. Elle cultive son savoir-faire pour proposer ses clients les meilleures solutions adaptes leurs besoins et leurs environnements de travail. De ce fait, la vocation premire de WINCOR-NIXDORF est de servir les intrts, immdiats et futurs, de tous les clients, en leurs fournissant les informations, les avis et les services dont ils peuvent en avoir besoin. Ceci peut tre rsum comme suit: anticiper les ncessits et les besoins du client en lui proposant des solutions adquates son mtier. accompagner lacqureur dans son processus damlioration pour raffiner ses exigences fonctionnelles et dgager, de ce fait, le choix optimum. concevoir et dvelopper les applications spcifiques. dployer la solution chez le client en formant les utilisateurs, en les assistant et en fournissant lexpertise requise travers un support technique adquat. assurer la maintenance des solutions dployes en tant attentifs aux remarques et aux rclamations du client. Grce son expertise reconnue autour des leaders technologiques mondiaux (Oracle, Microsoft, etc.) et sa renomme auprs de grands comptes nationaux (banques, postes, administrations publiques, etc.), WINCOR-NIXDORF est devenue
SAFIR - 11 ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

un partenaire de choix pour le dveloppement de solutions spcifiques et les solutions base du libre service.

1.2. Structures et organisation de WINCOR-NIXDORF Maroc


WINCOR-NIXDORF Maroc est organise selon lorganigramme suivant :

WINCOR-NIXDORF Maroc

Division Banking

Division Retail

Division Service

Division Solutions

Division Finance

Division Juridique

Division Logistique

Figure 1 : organigramme de WINCOR-NIXDORF Maroc.

Cependant, les divisions centrales sont en nombre de trois. Elles sont dcrites comme suit : ple Banking et Retail. ple Distribution. ple Service. Dans ce qui suit, je vais prsenter ces trois divisions : ple Banking et Retail.

SAFIR

- 12 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Ce ple a pour mission de fournir les outils et les solutions relatives aux besoins spcifiques de chaque banque ou poste. Grce une conception intgre des services, elle garantit une valeur ajoute sensible, une efficacit remarquable et un srieux engagement. Les produits quoffre WINCOR-NIXDORF dans ce domaine sont prsents dans le schma des canaux de distribution libre-service suivant :

Figure 2 : canaux de distribution libre-service.

ple Distribution Ce ple a pour mission dlargir le domaine dactivit de la socit. Dans cet esprit, le march de distribution est aliment par les nouveaux usages du marketing que les entreprises peuvent en bnficier. Parmi ces usages : dvelopper de nouveaux canaux pour les distributeurs par la construction de produits permettant dlargir leurs cibles actuelles des clients. diversifier la nature des clients en exploitant les opportunits offertes dans les domaines tels que la loterie, lhtellerie, etc.

SAFIR

- 13 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Le schma suivant prsente loffre de solutions compltes :

Figure 3 : offre de solutions compltes.

ple Service Les professionnels de Wincor-Nixdorf offrent leurs comptences dans des domaines prcis, de la formation la maintenance, de lintgration au dveloppement dapplications spcifiques. Le tableau suivant rsume les fonctions remplies par ce ple :

SAFIR

- 14 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

Call Center National Rception de tous les appels provenant du Maroc. filtrage des appels. Centre de Dispatching qualification et diagnostic techniques des appels. affectation des techniciens. suivi de la rsolution des pannes. assistance tlphonique aux utilisateurs. Help Desk National assistance tlphonique aux techniciens sur site. Stock des pices Maintenance prventive gestion des stocks de pices de rechange. gestion des plannings de maintenance prventive avec le client. rparation des matriels ne pouvant tre rpars sur site. Centre de rparation analyse individualise des pices frquemment en panne. proposition de solutions techniques.
Figure 4 : fonctions remplies par le ple service.

2. Prsentation du sujet
Le projet consiste en la conception et la ralisation dun serveur de change de devises en libre service ProChangeServer pour la socit de service WINCORNIXDORF. Dans ce qui suit, je vais situer le contexte de ce projet et en taler les objectifs.

2.1. Contexte du projet


Le modle mtier libre service offre aux utilisateurs la possibilit dinteragir directement avec les systmes centraux et les bases de donnes darrire-plan de lentreprise. Parmi les solutions dactualit, qui profitent de ce modle, le change
SAFIR - 15 ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

automatique des valeurs des devises trangres en valeur quivalente en devise locale. Quelle est lutilit du change ? Notre pays se voit sensibilis de limportance du domaine touristique pour son dveloppement socio-conomique. Les touristes sont de nationalits varies, donc utilisent des devises autres que notre devise locale ; le Dirham. A cet gard, lun des services fondamentaux quon doit fournir tant doffrir la possibilit aux touristes dutiliser la monnaie locale. Pourquoi automatiser cette procdure ? Habituellement, la procdure de change est effectue manuellement. Ce qui prsente quelques dfauts. Les aspects du problme peuvent tre rsums comme suit : le service de change nest disponible que lors des heures de travail des fonctionnaires des banques qui ont la possibilit deffectuer de telles transactions (9h-12h et 14h- 17h). le banquier peut se tromper quand il compte de largent. lchange manuel est un travail rptitif sans valeur ajoute pour le banquier. Une approche plus avise serait de se servir des ressources humaines dans des travaux acqurants plus de rflexion. les htels et les sites touristiques, qui sont les endroits concerns par la solution, sont loigns du centre de la ville, donc loin des services de base que peuvent en bnficier entre autre le change des devises trangres. En tenant compte des inconvnients de la procdure manuelle ainsi dgags, lautomatisation des transactions de change offre plusieurs avantages : la solution peut tre utilise 24h sur 24, sans arrt. Il suffit dalimenter le guichet par des billets suffisants. la flexibilit, en dehors du temps de travail habituel, est assure, ainsi les transactions de change peuvent tre effectues pendant la nuit comme pendant les jours fris.
SAFIR - 16 ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

lintgration au systme existant est prise en considration par lutilisation des GABs qui effectuent les transactions de retrait ordinaires ; cette amlioration est prvue par ladoption dune nouvelle gnration de guichets. Ils devront permettre de rendre la monnaie en pice jusquau 5 centimes prs. la sret des billets contenus dans les guichets automatiques est garantie par le fait que les GABs sont blinds, donc les billets sont chargs dans un coffre fort. le champ, vis par lapplication, peut tre largi pour atteindre dautres places aussi importantes telles que les aroports et les supermarchs. Du point de vue commercial, il faut prendre linitiative et saisir cette opportunit pour devancer les concurrents en saisissant les nouvelles solutions exprimes sur le march, car ce nouveau march suscite un intrt conomique exprim par les grandes banques et les grandes structures commerciales. Aussi, il y a largissement du domaine dactivit de lentreprise pour atteindre le march international, ainsi lexploitation de la solution peut tre bnfique pour dautres pays qui expriment les mmes besoins expliqus auparavant. Cette solution est dploye en intranet. Elle va donc permettre un gain norme de temps de traitement et une facilit notable pour le change de devise. Les objectifs de cette solution sont appels ProChange. La partie guichet automatique, appele ProChangeATM, est dveloppe en Pologne. Quant la partie Serveur, appele ProChangeServer, est prsente dans le paragraphe qui suit. Lintgration de ces deux parties, en un produit, a eu besoin de plusieurs itrations pour laboutissement du ProChange dans sa version fonctionnelle et exploitable.

2.2. Objectifs du projet


Le projet ProChangeServer a pour objectif de rcuprer les donnes des transactions effectues quotidiennement pour les intgrer dans lcriture comptable de la banque ou linstitution financire en question. Pour aboutir ce rsultat, la ralisation est apprhende par laccomplissement des points suivants :

SAFIR

- 17 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

distribuer les paramtres des GABs pour assurer leurs fonctionnements normaux. Ces paramtres sont regroups selon des types fonctionnels et denvironnement : timeout, messages, contenu du reu, priodicit des balances, etc. distribuer les taux de changes aux GABs chaque fois quune mise jour est effectue. La variation du taux de change est contrle, puisque la validation de la nouvelle valeur doit tre accorde un utilisateur privilgi. collecter les donnes quotidiennes des transactions de change qui sont parpilles sur plusieurs guichets automatiques. Ces donnes contiennent diffrents types dinformations ; comme le montant en Dirham (ou en devise trangre) dune transaction donne ou bien les informations sur les coupures1 utilises. consolider ces donnes, reues sous format texte, sous une interface unique dans une base de donnes permettant par la suite dextraire les renseignements et des indicateurs pertinents au suivi et au monitoring. anticiper les anomalies qui peuvent survenir et prvoir les traitements adquats relatifs chacun des cas ; ces problmes sont dorigine rseau en gnral. grer toutes les ressources de lapplication en permettant lajout, la mise jours et la suppression ; grer les GABs, les devises, les utilisateurs, les profiles, les messages, le multi langage et les paramtres gnraux du serveur ProChangeServer. assurer un service ddition afin de pouvoir grer les rapports et les statistiques relatifs aux principales informations utilises par la banque dans son fonctionnement. De plus, permettre lexportation des donnes sous formats standards tels que les fichiers PDF, HTML, EXCEL et XML. protger le systme par un mcanisme de scurit flexible permettant daccder aux fonctionnalits du systme selon le profil de lutilisateur avec diffrents niveaux de granularit.

Coupure : une portion dargent reprsente par une seule unit. Le Dirham marocain a les coupures en billets de 200, 100, 50 et 20. Aussi, il a les coupures en pices de 10, 5, 2, 1, 0.5, 0.2, 0.1 et 0.05.
1

SAFIR

- 18 -

ENSIAS 2004/2005

Chapitre 1 : Contexte gnral du projet

ProChangeServer@WINCOR-NIXDORF

doter ProChangeServer dun dispositif de journalisation afin de pouvoir retrouver la trace du droulement de lexcution du systme. En plus, ProChangeServer doit tre facilement exploitable, fiable et extensible, ainsi il doit contenir aussi : un guide utilisateur pour expliquer aux utilisateurs comment utiliser et configurer le systme. un guide dveloppeur qui explique larchitecture du systme pour permettre aux dveloppeurs dtendre le systme si le besoin est exprim. Conclusion Dans ce chapitre, jai prsent la socit WINCOR-NIXDORF chez laquelle jai pass le stage de fin dtude. Jai aussi prsent le contexte dans lequel sinscrit le projet ProChangeServer. Dans le chapitre suivant, je vais aborder en dtail ltude du projet o je vais dgager les fonctionnalits du systme et prsenter le dossier de pilotage.

SAFIR

- 19 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Chapitre 2 : tude du projet

Dans ce chapitre, je vais prsenter le projet en dtail afin den taler les fonctionnalits et den estimer lenvergure. Ensuite, je vais dvoiler le dossier pilotage du projet en question pour atteindre les objectifs fixs.

SAFIR

- 20 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

1. Caractristiques gnrales de ProChangeServer


Lorganisation, dune banque, a un grand impact sur la manire dont les donnes, concernant ses activits, sont traites. Et comme lorganisation diffre, la solution ProChangeServer est destine pour tre exploit par nimporte quelle banque. Pour cela, elle doit supporter tout type dorganisation. Compte tenu de la diffrence entre les systmes dinformation des banques, ProChangeServer doit offrir la possibilit dtre dploy sur diffrents systmes dexploitation (Windows, Linux) et de supporter diffrents SGBDR (Oracle, SQL Server et autres). De ce fait, il serait plus flexible pour lutilisateur final. Les systmes dinformations bancaires deviennent de plus en plus complexes et exigeants, donc pour pouvoir intgrer ProChangeServer dans le systme dinformation de la banque, il doit tre paramtrable et extensible. De nos jours, les architectures logiciels et les outils (de modlisation et de dveloppement) sont de plus en plus nombreux. Ce qui signifie que la mise en uvre de ProChangeServer doit tenir compte de ces variantes afin dassurer un meilleur fonctionnement. Et bien sur cela nest possible quen prenant compte des considrations relatives la fiabilit des outils et leurs compatibilits dans llaboration de lenvironnement technique cibl par les banques.

2. Fonctions principales de ProChangeServer


2.1 Gestion des balances des GABs
La balance de change est lensemble dinformations relatives chaque GAB effectuant des oprations de change. Ces donnes sont remontes au serveur quotidiennement et sont subdivises en 5 volets qui sont : rcapitulatif de la journe. liste des transactions.

SAFIR

- 21 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

dtail des transactions par devise. dtail des transactions par les coupures de la devise trangre. dtail des transactions par les coupures MAD (billets et pices). La gestion des balances des GABs englobe la circonspection des cinq sections suivantes :
Section 1 : Collecte des balances

Automatiquement et une heure paramtre, les balances disponibles sont assembles. A ce moment, pour chaque GAB, deux cas se prsentent : soit il a transmis sa balance soit il ne la pas encore envoy ( cause dun problme rseau par exemple). Pour les GABs ayant transmis leurs transactions quotidiennes, ProChangeServer rcupre ces donnes et passe leurs traitements. Pour les GABs nayant pas transmis leurs transactions quotidiennes, ProChangeServer attend une priode dtermine puis recommence la procdure de rcupration pour les GABs restants.
Section 2 : Traitement des balances

A cette tape, le serveur vrifie la conformit des donnes au format de transmission permit et examine leurs valeurs smantiques. Ceci tant examin pour chaque GAB. L encore, deux cas se prsentent ; une balance est soit dclare valide soit elle est dite invalide. Si une balance est juge valide, elle est insre dans la base de donnes. En mme temps, il y a prparation de lenvironnement pour les balances prochaines. Si une balance est non certifie, elle est dclare rejete et il y a appel de la section suivante.
Section 3 : Gestion des balances rejetes et non envoyes

Pour chaque GAB nayant pas transmis sa balance, soit elle tait mal reue soit elle tait tmoigne non valide, ladministrateur systme ou le superviseur des GABs

SAFIR

- 22 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

doit intervenir pour rcuprer cette balance. Dans ce cas, la balance peut tre rcuprable dans le mme processus normal ou elle peut ne pas ltre. Pour la balance rcuprable, le processus de collecte est relanc manuellement. Cependant, si la configuration de la collecte est automatique, le processus se lance une heure paramtre aprs rsolution des problmes survenus2. Lintgration dans la base de donnes est aussitt effectue. Pour les balances irrcuprables3, le systme permet la saisie manuelle de toutes les transactions de change.
Section 4 : Saisie des balances irrcuprables

Sil nest pas possible de rcuprer la balance dun GAB donn, ProChangeServer permet la saisie manuelle de toutes les transactions de change effectues par ce GAB. Afin de prvoir ce cas, chaque GAB est dot dun systme de trace reprsent par un journal des transactions. Celui-ci est un dispositif similaire la quittance reue par le client. Pour raliser cette fonctionnalit, ProChangeServer offre une interface de saisie pour le gestionnaire du GAB. Ce dernier doit dabord ouvrir une priode de saisie, puis saisir partir du journal les transactions effectues. Une fois la saisie termine, le gestionnaire doit clturer cette priode. Aprs ladite clture, ladministrateur systme doit valider cette saisie pour relancer le processus dintgration de ces donnes.

2.2. Prparation de la balance des GABs


La balance de change est le rcapitulatif dinformations relatives tous les GABs effectuant les oprations de change pendant une priode bien explicite. Elle est calcule pour faire le point sur les activits effectues. Une telle synthse est envoye au serveur central de la banque soit automatiquement soit manuellement selon les objectifs de ladministration.

2 3

Problme rseau en gnral. Crash du disque dur en gnral.

SAFIR

- 23 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

La priodicit de la balance globale peut concider avec celle de la balance des GABs, mais peut dpendre de la clture des critures comptables de la banque. Dans ce dernier cas, la synthse tient compte des jours fris et des week-ends donc il sagit de grer un calendrier dynamique. La balance globale est aussi paramtrable dans la mesure o elle peut tre gnre par institution ou produite par agence, etc. La structure de la balance globale est constitue par le chiffre daffaire quotidien en dirham ralis ainsi que le total des commissions en profit. Elle contient, aussi, le montant total acquis par devise trangre. Pour les balances GABs non envoyes temps, le systme ProChangeServer permet soit de les intgrer dans la balance en cours soit de les envoyer comme des balances complmentaires celles envoyes incompltes.

2.3. Gestion des taux de change


La gestion des taux de change inclut la prise en charge de leurs valeurs et de leurs dures de validit. Si une mise jour est ncessaire, les nouvelles valeurs peuvent tre modifies de deux faons diffrentes : saisie manuelle par un utilisateur habilit le faire. chargement partir dun serveur ddi. Auquel cas, il faut utiliser un mcanisme scuris. Si la banque opte pour une mise jour manuelle des taux de change, le responsable charg de cette mission devra crer une nouvelle configuration contenant les dernires valeurs des taux de change utilises. Si cette personne dcide dapporter des modifications aux taux de change, cette nouvelle configuration sera affecte tous les GABs. La distribution des taux de change est contrle par un mcanisme dautorisation. Si une nouvelle mise jour est effectue par un utilisateur, il introduit une variation relative aux taux de change. Ainsi si cette variation dpasse un seuil qui lui est accord, le systme refuse de tenir compte de ces nouvelles modifications.

SAFIR

- 24 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Si les nouveaux taux de change sont rcuprs partir dun serveur tiers, la cration de la configuration ainsi que sa distribution seront semblables celles relatives la mthode manuelle. Le mcanisme de validation est aussi appliqu en affectant un profil au serveur des taux de change. Le systme doit sauvegarder les valeurs des taux de change dans la base de donnes permettant, ainsi, leurs consultations pour une analyse a posteriori.

2.4. Gestion des paramtres des GABs


Lors de son fonctionnement, le GAB doit prendre en considration les diffrents types de paramtres relatifs lenvironnement dexcution (timeout, messages, contenu du reu, priodicit des balances, etc.). Ces paramtres sont regroups en configurations et cest le systme qui se charge de les fournir aux GABs dclars actifs. Ainsi, toute cration dune nouvelle configuration doit suivre une procdure bien dfinie. Celle-ci est semblable la procdure applique aux taux de change explique dans la partie gestion des taux de change . Compte tenu de la multitude des paramtres grer, le mcanisme de chargement dune nouvelle configuration doit tre organis. Ces paramtres sont donc classs par catgories fonctionnelles (paramtres systme, paramtres dinitialisation, paramtres de fonctionnement, timeout, etc.) pour faciliter leur gestion. Dans cette vision, chaque paramtre est associ une catgorie. Ladministration de cette catgorie est affecte un groupe dutilisateurs. Par consquent, un utilisateur peut agir sur une catgorie particulire de paramtres sans avoir accs une deuxime catgorie.

2.5. Paramtres gnraux


Hirarchie des GABs

Lhirarchie dun GAB reprsente son niveau dappartenance dans lchelle de la banque. Cependant, le degr hirarchique dun GAB peut diffrer dune banque
SAFIR - 25 ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

une autre. Pour englober diffrents types de hirarchie, le systme propose lhirarchie suivante : Mandataire Institution Agence GAB Le mandataire englobe des institutions ; chacune de celles-ci organise ses agences et chaque agence gre un ou plusieurs GABs. Par exemple, le mandataire ATTIJARIWAFA est constitu de deux institutions : BCM et WAFA Banque o chacune delles ayant des agences rparties dans diffrentes villes. Dautre part, ce modle permet de rpondre la tendance des banques pour la fusion. Un mandataire est responsable de plusieurs banques. Par exemple, le groupe Banque Populaire supervise des banques localises au niveau de chaque rgion. Cellesci, contrlent leurs agences de faon autonome. Gnralement, le systme permet de grer lhirarchie dune banque en sadaptant au modle de son arborescence. Gestion des GABs ProChangeServer permet de grer tous les GABs offrants le service de change dune banque donne, ainsi il reconnat chaque GAB par son numro, lagence qui il appartient et ladresse o il est localis. De plus, on indique, le nombre de cassettes quil contient, lexistence ou non du coins dispenser4 , son statut et la version du GAB install : Standard ou Advanced . Une machine Standard ne contient pas de coins dispenser . Une machine Advanced contient le coins dispenser . Deux cas se prsentent, soit la version du GAB prend en compte lutilisation du coins dispenser , soit elle ne le permet pas.
4

Le coins dispenser est un supplment qui contient les pices de monnaies.

SAFIR

- 26 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Quant au statut du GAB, on indique trois tats : activ ou dsactiv ou supprim. Initialement, il est dclar comme dsactiv et il sera activ lorsquil est oprationnel. Ceci tant pour faciliter la gestion. Gestion des devises ProChangeServer gre toutes les devises permises circuler dans le territoire marocain. Chaque devise est caractrise par son code ISO, son nom, son unit et son statut qui peut prendre ltat activ ou non activ. Lactivation dune devise est conditionne par le nombre maximal de devises supportes par le GAB et par la liste des devises pouvant tre change au Maroc selon les notifications dictes par BANK AL MAGHRIB cet gard. Finalement, il faut noter que lactivation de la devise sera manuelle et sera contrle par une personne responsable. Gestion des profils et des utilisateurs Puisque diffrents intervenants utilisent ProChangeServer, leur administration est assure. En effet, chaque utilisateur a son login, son mot de passe, son nom, la date dbut validit, la date fin validit, activ ou pas et le profil associ. Ainsi, la gestion des profils consiste grer par profil son nom et ses droits. ProChangeServer permet dajouter un nouvel utilisateur. Une fois intgr, il lui serait donc possible de modifier ses caractres, son profil et dautres paramtres. De plus, le cas de suppression est accept. Toutefois, il faut lutiliser selon les rgles de gestion appliques en vigueur. Il est possible, entre autre, de permettre une personne physique plusieurs rles dans le systme. La gestion des droits, dans ce cas, doit prendre en compte la confrontation des accs. Par exemple : accs refus pour un objet + accs accept pour cet objet = accs refus pour cet objet.

SAFIR

- 27 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Gestion des messages et le multi langage Le caractre dinternationalisation est pris en compte pour chaque utilisateur. Ceci tant gr au niveau de chaque menu et au niveau de chaque fentre grce linterface de lapplication qui sadapte selon la langue slectionne par lutilisateur. Afin de permettre un modle gnrique dinterface, une fentre donne peut tre prsente pour tous les utilisateurs dun profil. Ce qui va les distinguer cest lactivation ou la dsactivation dun menu ou dun bouton ou dun autre composant de linterface. Dautre part, le systme intgre laffichage des messages daccompagnement de lutilisateur dune manire proche sa comprhension ; il sagit du retour dinformations des vnements dclanchs soit par lutilisateur soit par le systme. De plus, le systme reporte les changements dtats relatifs lobjet manipul ; assurant de ce fait, la validation de lopration effectue ou du renvoi dune notification expliquant la cause et la nature de lerreur. Gestion des paramtres ProChangeServer Le fonctionnement du Serveur est rgit par la consultation dune multitude de variables de configuration. Celles-ci sont trs utiles pour ladministration du systme (chemin des fichiers de la balance, chemin du fichier taux, chemin du fichier paramtre, priodicit du lancement du processus de collecte des balances, dure du processus de collecte, etc.). Comme les paramtres administrer sont nombreux, ces paramtres sont classs par catgories fonctionnelles : des paramtres systme, des paramtres de disponibilit, des paramtres de scurit et des paramtres de performance. Rapports et consultations Pour permettre la consultation des donnes des transactions effectues, lapplication permettra de gnrer des rapports relatifs aux principales informations utilises par la banque. Pour la gnration et lexploitation de ces ditions, lutilisateur ne sera

SAFIR

- 28 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

pas perdu par la multitude de leurs menus. Ainsi, un modle gnrique sera exploit par toutes les requtes de consultation. Pour enrichir lutilisation des consultations, lapplication permettra de les sauvegarder dans des fichiers sous une multitude de format : XML, HTML, PDF et EXCEL. Ldition permet de publier diffrents tats et rapports concernant lactivit de change sur lensemble des GABs : informations sur la transaction. informations sur les transactions par rapport une devise ou par coupure. informations sur la balance quotidienne ou la balance globale.

3. Fonctions optionnelles de ProChangeServer


3.1. Purge de la base de donnes
La purge de la base de donnes permet de supprimer les anciennes transactions pour augmenter les performances du SGBD. Les donnes supprimes seront archives et il est possible de les restaurer pour des fins de consultation ou de diagnostique. Cette fonction est trs importante vu le volume des transactions de change qui seront effectues.

3.2. Purge des fichiers


Compte tenu du volume des fichiers balance des GABs chaque anne qui est denviron 9 Go (365 jours, 100 GABs, 500 transactions/jour et 500 octets /transaction/GAB), il serait judicieux darchiver les balances sur des supports autre que le disque dur pour augmenter ainsi la performance.

3.3. Traitement des rclamations


Afin dintgrer les remarques et les critiques des utilisateurs des GABs, le systme propose un volet rclamation. Celui-ci doit tre pris en considration comme un attribut de lentit transaction pour optimiser le temps de calcul lors du traitement

SAFIR

- 29 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

des rclamations. Sans ce traitement, la jointure pour inclure les rclamations mises dgradera normment la performance de la base de donnes.

3.4. Univers ditions


Pour permettre aux dcideurs une vue globale et dtaille du systme dinformation gr par ProChangeServer, il serait judicieux doffrir un univers ddition plus professionnel. Pour cette fin, il y a des logiciels avancs qui peuvent rpondre aux attentes dsires. Loutil Business Object , entre autres, permet lutilisateur de gnrer des modles dtats personnaliss et avancs. Le rle de la solution offerte est de crer lenvironnement de base afin de faciliter lexploitation des donnes par ces outils ddis.

4. Objectifs en terme de qualit


Dans les paragraphes prcdents, jai dtaill les exigences fonctionnelles du futur systme ProChangeServer. Dans ce qui suit, je vais prsenter les objectifs du projet en terme de qualit. Le cahier de charge constitue un conducteur majeur qui guide laccomplissement du projet. Cependant, tout dveloppement logiciel doit rpondre aux besoins implicites du projet. Parmi ces contraintes, il y a les facteurs de qualit suivants : disponibilit : le systme doit tre en permanence la disposition de ses utilisateurs. fiabilit : le systme doit excuter les fonctions attendues avec la prcision requise (taux de dfaillance minimal). volutivit : il doit tre possible dtendre le systme. rutilisation : il doit avoir la possibilit de rutiliser certains modules du systme. indpendance de loutil : surtout pour les services techniques, il doit tre possible de changer loutil utilis sans beaucoup trop de changements effectuer.

SAFIR

- 30 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

5. Dossier de pilotage
Le dossier de pilotage est un guide qui rassemble un ensemble de volets permettant datteindre les objectifs fixs pour le projet sous la contrainte du dlai fournit, la dmarche suivie et la conduite de projet. Dans cette vision, je prsente le plan dassurance qualit, le planning du projet et le cycle de dveloppement suivi. Ils seront dtaills dans les trois parties suivantes.

5.1. Plan assurance qualit


Dans le but dobtenir un logiciel satisfaisant les besoins fonctionnels, techniques et qualit, un plan dassurance qualit est ralis. Ce plan contient toutes les orientations suivies et appliques. La description totale du PAQ est prsente dans lannexe 2.

5.2. Cycle de dveloppement


Le processus de dveloppement adopt est le processus en Y ou Two Track Unified Process (2TUP) [wwwCLUBJAVA]. Ce processus itratif et incrmental, drive du Unified Process , mais il consacre plus dimportance pour les aspects techniques auxquels il rserve toute une branche de son cycle. Cet intrt a pour but de rduire le risque technologique. Y ne se contente pas des risques technologiques, mais il assure aussi une gestion des risques de toute nature. Pour plus de dtail concernant le cycle en Y se reporter lannexe 1. Le choix du cycle en Y est justifi par ses proprits confirmes et par le besoin exprim par ProChangeServer en terme de fonctionnalits et des technologies utiliser. Nanmoins, une tude comparative entre le cycle en Y et dautres cycles de dveloppement simpose afin den choisir celui qui est le plus adapt. Ltude a prouv la puissance du cycle en Y et elle a dmontr quil est appropri au projet. Cette comparaison porte sur trois processus de dveloppements les plus populaires et les plus utiliss :

SAFIR

- 31 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

le processus RUP (Rational Unified Process). le cycle en V. le cycle en Y. La figure5 suivante est un rcapitulatif de ltude comparative ralise

[wwwIMPROVE] [wwwPSTMARTIN]. Les aspects critiques, du projet tudi, mritent dtre rsolus avec plus de souplesse. Parmi ces points, la multitude des fonctionnalits exprimes, lutilisation des plus nouvelles technologies, le respect du temps rserv llaboration du projet, etc. Pour viter cette immensit des risques, je me suis concentr sur llaboration dune premire version du projet nayant que les fonctionnalits principales. Ensuite, jajoutais les fonctions les plus indispensables au fur et mesure. Ceci tant tabli par une mthode itrative et incrmentale. Pour esquiver les risques des nouveauts technologiques, jexplorais les solutions offertes pour sy adapter et pour surpasser les surprises qui peuvent en survenir. Le modle dimplmentation donc tire de grands profits des solutions offertes par les technologies tudies. Daprs le la figure 5, seul Y propose un intrt vif pour la gestion de la complexit technique. Les deux autres ny attachent pas grande attention. En effet, RUP propose plutt un cadre complet pour la conduite de projet, mais nattache pas trop dimportance pour le dveloppement lui-mme. Le cycle en V quant lui, permet de matriser le dveloppement travers les vrifications la fin des phases, mais il noffre toujours pas de gestion de la complexit technique. Il savre donc incontestablement que cest effectivement 2TUP qui est le plus appropri au projet tudi.

SAFIR

- 32 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Processus

Description RUP est la fois une

Avantages Propose des modles

Inconvnients -Coteux personnaliser -Trs ax processus, au dtriment du dveloppement : peu de place pour le code et la technologie

RUP

mthodologie de conduite et de de documents, et des dveloppement de projets et un canevas pour des outil prt lemploi Chaque phase en amont de la production du logiciel prpare projets types Prparation des phases de vrification au moment de lAnalyse et de la Conception Fait une large place la technologie et la gestion du risque

-Obligation de dfinir la totalit des besoins au dpart -Validation fonctionnelle tardive

la phase correspondante de vrification en aval de la production du logiciel

Ne propose pas de documents types

2TUP

Sarticule autour de larchitecture

Figure 5 : tude comparative des cycles de dveloppement.

5.3. Planning
Ds la premire runion avec lencadrant WINCOR-NIXDORF, nous avions labor un planning prvisionnel (la figure 6 suivante) que nous avons ajust par la suite au fur et mesure de lavancement du projet. Les tches inscrites dans ce planning correspondent aux phases caractrisant le cycle du dveloppement Y.

SAFIR

- 33 -

ENSIAS 2004/2005

Chapitre 2 : tude du projet

ProChangeServer@WINCOR-NIXDORF

Id 1 2 2.1 2.2 3 3.1 3.2 4 5

Tche Etude prliminaire Etude Fonctionnelle Capture des besoins fonctionnels Analyse Etude technique Architecture logicielle et outils Dveloppement des Frameworks techniques Conception Codage et test

Date de dbut 21/02/2005 28/02/2005 28/02/2005 07/03/2005 21/03/2005 21/03/2005 28/03/2005 11/04/2005 02/05/2005

Date de fin 25/02/2005 18/03/2005 04/03/2005 18/03/2005 08/04/2005 25/03/2005 08/04/2005 29/04/2005 01/07/2005

Dure 5j 15 j 5j 10 j 15 j 5j 10 j 15 j 45 j 95j

Total

Figure 6 : planning prvisionnel.

Conclusion
Dans ce chapitre, jai dtaill les exigences fonctionnelles et techniques de la solution ProChangeServer. Puis, jai tal les objectifs en terme de qualit de cette solution. Ensuite, jai prsent le dossier de pilotage. Dans le chapitre suivant, je vais aborder en dtail ltude fonctionnelle du projet o je vais prsenter la phase de capture des besoins fonctionnels et celle danalyse.

SAFIR

- 34 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Chapitre 3 : tude fonctionnelle du projet

Dans ce chapitre, je vais prsenter la phase de capture des besoins fonctionnels o jai modlis le systme du point de vue usager/systme. Elles sont raffines par les diagrammes de cas dutilisation et par la maquette IHM. Je vais exhiber aussi la phase danalyse o jai dtaill le modle danalyse construit.

SAFIR

- 35 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

1. Capture des besoins fonctionnels


Lors de cette phase, je vais dterminer lensemble des services offerts par le systme ProChangeServer, travers lnumration et la description textuelle de lensemble des cas dutilisation inspects du systme. Par ailleurs, je vais dvoiler la maquette interface Homme/Machine adopte par le systme.

1.1. Services attendus de ProChangeServer


Dans ce paragraphe, je vais dgager lensemble des cas dutilisation du systme. Ce seront toutes les manipulations que les diffrents utilisateurs effectuent en interagissant avec le systme. Afin dy parachever, je vais suivre la dmarche suivante : dfinir les acteurs du systme. lister les cas dutilisation. donner une description textuelle des scnarios. construire les diagrammes de squence associs aux scnarios. Les acteurs principaux du systme sont les personnes qui utilisent les fonctions principales du systme [MULLERGAERTNER00]. Dans le cas de ProChangeServer, ce sont les acteurs : dcideur, banquier et chef banquier. Les acteurs secondaires du systme sont les personnes qui effectuent des tches administratives ou de maintenance sur le systme [MULLERGAERTNER00]. Ce seront les acteurs : administrateur et guichetier. Afin deffectuer linventaire des divers cas dutilisation du systme, il suffit de recenser les attentes et les opportunits offertes chacun des utilisateurs dgags auparavant. Lacteur dcideur va utiliser le systme pour consulter ltat davancement des balances quotidiennes et de la balance globale gnre. De plus, il peut consulter les statistiques sur toutes les activits excutes. Il doit donc sauthentifier pour accomplir les tches qui lui sont permises. Le diagramme de cas dutilisation du systme associs lacteur dcideur est nonc dans la figure suivante :

SAFIR

- 36 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 7 : diagramme de cas dutilisation associ lacteur dcideur.

Lacteur banquier va utiliser le systme plus frquemment. Il va soccuper de la collecte des balances rcupres partir des diffrents GABs. De plus, il va intervenir si lun des GABs actifs a envoy une balance non valide ( cause des problmes rseaux par exemple). Quant les balances GABs sont acceptes, il archive les fichiers reus. Par contre, si elles sont errones, il va signaler le problme et va contacter le guichetier pour recommencer le transfert des donnes. Par ailleurs, le banquier va mettre jour les taux de change et va saisir les paramtres relatifs aux balances des GABs et de la balance globale. Il doit donc, lui aussi, sauthentifier pour accomplir les tches qui lui sont permises. Le diagramme de cas dutilisation du systme associ lacteur banquier est expos dans la figure suivante :

SAFIR

- 37 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 8 : diagramme de cas dutilisation associ lacteur banquier.

Le rle de lacteur chef banquier inclut les rles de lacteur banquier et lacteur dcideur. Aprs la collection des balances des GABs par le banquier, il va clturer la journe. Par la suite, il gnre la balance globale pour le serveur central de la banque afin deffectuer les critures comptables relatives au module change de devises . En plus, il a la possibilit de valider le taux de change saisit par le banquier. Par consquent, ces nouveaux taux de change sont distribus aux GABs comme une mise jour. Aussi, il valide les paramtres de la balance des GABs et la balance globale, saisit par le banquier. Ainsi, il peut adapter le systme aux critures comptables de la banque. Le diagramme de cas dutilisation du systme associ lacteur chef banquier est prsent dans la figure suivante :

SAFIR

- 38 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 9 : diagramme de cas dutilisation associ lacteur chef banquier.

Lacteur administrateur gre les ressources de lapplication telles que les institutions dune banque, ses agences, ses GABs, les devises, etc. De plus, il rgit les paramtres de fonctionnement relatifs aux GABs et au fonctionnement du serveur. Encore, il alimente la base de donnes par les donnes essentielles que les autres utilisateurs nont pas le droit de les manipuler. Cependant, il a une vision totale de lexcution de lapplication par la consultation des vnements enregistrs. Par ailleurs, il dfinit la scurit du systme en attribuant des rles et des privilges aux autres utilisateurs. Il doit donc sauthentifier pour accomplir les tches qui lui sont permises. Le diagramme de cas dutilisation suivant rsume les interactions avec le systme associes lacteur administrateur :

SAFIR

- 39 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 10 : diagramme de cas dutilisation associ lacteur administrateur.

Lacteur guichetier qui sera charg dutiliser le systme pour saisir la balance du GAB qui na pas t rcupr de faon automatique ( cause dun crash disque par exemple). Il doit, comme pour les autres acteurs, lui aussi sauthentifier pour accomplir les tches qui lui sont agres. Le diagramme de cas dutilisation du systme associ lacteur guichetier est prsent dans la figure suivante :

Figure 11 : diagramme de cas dutilisation associ lacteur guichetier.

SAFIR

- 40 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Les diffrents cas dutilisation sont ainsi prsents. Je vais commencer, maintenant, les raffiner et en dgager plus de dtail afin davoir plus de visibilit utilisateur/systme. Ltape analyse sera par la suite plus claire et facile manuvrer. Au cours de linteraction avec le systme, un cas dutilisation ncessite des conditions et doit aboutir une finalit bien dtermine. De ce fait, il suit un scnario particulier et dclenche une exception sil est hors contexte dfini par les rgles de gestion. Lexemple du tableau suivant montre cette description textuelle pour le cas dutilisation mise jour des taux de change [ROQUESVALLEE01] :

SAFIR

- 41 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Acteur Primaire But Pr conditions Dclencheur Scnario principal

Banquier. - reflter les taux de change rels approuvs par BANK AL MAGHRIB. - authentification du banquier auprs du ProChangeServer. - aprs une priode dtermine5. - le banquier demande lajout de nouveaux taux. - ProChangeServer cre une nouvelle configuration contenant les dernires valeurs des taux de change. - le banquier modifie les informations relatives au nouveau jalon. - ProChangeServer vrifie la variation relative chaque devise. Deux cas se prsentent. Si accept [A1], sinon [E1].

Scnarios alternatifs

A1 : - ProChangeServer cre une nouvelle configuration et effectue la mise jour. - ProChangeServer vrifie le droit de distribution. Deux cas se prsentent. Dans laffirmatif [A2]. Dans la ngation [E2]. A2 : - la configuration est distribue. - une confirmation est retourne au banquier.

Scnarios dexception

E1 : ProChangeServer signale au banquier que la mise jour nest pas effectue. E2 : la distribution doit tre effectue par le chef banquier.

Rgles de gestion - chaque mise jour doit passer par la cration dune nouvelle configuration. Figure 12 : description textuelle du cas dutilisation mise jour du taux de change.

La distribution textuelle, ainsi exprime, reprsente toutes les informations du cas dutilisation dtaill. Cependant, lenchanement nest pas mis en relief. Cest pourquoi, il serait judicieux de complter cette description textuelle par le diagramme de squence relatif au cas dutilisation tudi.

Actuellement, les taux de change sont mis jour chaque semaine.

SAFIR

- 42 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Le diagramme de squence, adjoint au cas dutilisation de mise jour des taux de change, est le suivant :

Figure 13 : diagramme de squence du cas dutilisation mise jour des taux de change.

1.2. Maquette du systme


Dans le but de valider les besoins fonctionnels tels quils sont recenss et davoir une ide sur lIHM du projet ProChangeServer, jai propos une maquette html pour le systme. En effet, il est toujours plus simple de vrifier les besoins sur des crans que sur du texte. La figure suivante reprsente lcran relatif la gestion des taux de change :

SAFIR

- 43 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 14 : maquette du systme ProChangeServer.

A la fin de cette phase de capture des besoins fonctionnels, jai rdig un ensemble de livrables : les diagrammes de cas dutilisation. un document regroupant la description textuelle de lensemble des cas dutilisation. la maquette HTML pour le systme.

2. Analyse
La phase danalyse comprend les activits qui permettent daboutir au modle danalyse du systme en partant des cas dutilisation et des besoins fonctionnels [JIMCONALLEN00]. Ce modle danalyse est constitu par les classes et les collaborations de classes qui traduisent les comportements dynamiques, dtaills
SAFIR - 44 ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

dans les cas dutilisation et les besoins. Ces classes reprsentent laspect mtier de lapplication. En effet, lanalyse se concentre sur le fonctionnel en ignorant les contraintes techniques qui seront tudies dans la partie technique. Aussi, lessentiel dans cette phase est de sassurer que tous les besoins fonctionnels sont raliss dans la modlisation du systme. Pour prsenter le travail effectu dans cette phase, jai tout dabord dtaill les diagrammes de squence labors qui ont permis de dgager la composition interne du systme en terme dobjet. Par la suite, je vais prsenter le modle danalyse construit et sa dcomposition en paquetages. Finalement, je vais tudier le comportement des entits manes travers les diagrammes dtat/transition.

2.1. Composition interne du systme


Tout logiciel est considr comme un systme o interagissent des dobjets entre eux afin daccomplir une finalit. Dans ce sens, le but de cette activit est dexplorer cette composition interne en terme dobjet. Le mcanisme de UML qui permet dexprimer cette dynamique et cette collaboration est le diagramme dinteraction. Le diagramme de squence est un diagramme dinteraction qui traduit le flot du scnario dun cas dutilisation et cela en terme de classes qui doivent tre implmente. Dans cet esprit, pour dgager les objets composants larchitecture tudie, jai labor les diagrammes de squence associs aux cas dutilisation dgags dans la phase prcdente. Pour prsenter le travail ralis dans ce sens, jai choisi de dcrire deux diagrammes de squence qui concernent : la collecte des transactions dun GAB. la remonte de la balance globale au serveur central de la banque. La collecte des transactions du GAB nest intgre dans le systme que si tous les dtails, qui lui sont relatifs, sont valids. Ces dtails constituent la balance du GAB

SAFIR

- 45 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

effectuant des oprations de change. Elle est remonte au serveur quotidiennement et automatiquement. Par ailleurs, elle est structure et dcoupe en 5 parties complmentaires: rcapitulatif de la journe. liste des transactions. dtail des transactions par devise. dtail des transactions par les coupures de la devise trangre. dtail des transactions par les coupures MAD (billets et pices). Au fur et mesure de son rcupration, une balance peut avoir plusieurs tats : valide ou rejete ou rcupre. Quand la collecte de tous les GABs est effectue, le systme renvoie la balance globale la banque centrale. Celle-ci permet de faire le point sur les activits effectues pendant une priode dfinie. Ainsi, elle sera envoye vers le serveur central de la banque soit automatiquement, soit manuellement. La priodicit de la balance globale peut concider avec celle des GABs, mais peut dpendre de la clture comptable de la banque, donc il faut tenir compte des jours fris et des week-ends. Si la banque opte pour une clture comptable, le systme gre un calendrier des journes. Lanalyse prend en compte tout ceci, afin de construire une architecture qui permet de raliser les fonctionnalits requises. Dans ce qui suit, je vais prsenter les diagrammes de squence correspondants aux cas dutilisation la collecte des transactions dun GAB et la remonte de la balance globale au serveur central de la banque . Ensuite, je vais dgager la partie du modle danalyse qui correspond ces diagrammes. Le premier diagramme est associ au cas dutilisation collecte des transactions dun GAB . Je rappelle que ce scnario se dclenche automatiquement. Il est

SAFIR

- 46 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

prsent dans la figure 15. Sur ce diagramme, jai relev une suite dchanges de messages qui sont comme suit : une heure paramtre, une tche planifie se dclenche pour crer une nouvelle transaction. la transaction fait appel aux paramtres de rcupration en utilisant lobjet utility. Quand ces paramtres sont disponibles, ils sont renvoys lobjet transaction en question. la transaction valide les donnes extraites du fichier envoy par le GAB. Si le format des donnes dans ce fichier est conforme, le message de validit est renvoy lobjet transaction. La transaction retourne lobjet tche sa validit. Lobjet tche ajoute la transaction courante aux donnes rcupres partir du GAB.

SAFIR

- 47 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 15 : diagramme de squence de collecte des transactions dun GAB.

Le deuxime diagramme de squence propos, correspond au cas dutilisation remonte de la balance globale au serveur central de la banque.

SAFIR

- 48 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 16 : diagramme de squence de remonte de la balance globale au serveur central de la banque.

Ce diagramme illustre la remonte de la balance globale au serveur central de la banque. Il contient la squence suivante de messages : le banquier consulte une forme rserve la balance globale. Celle-ci charge les paramtres relatifs la balance globale. la forme incite le banquier slectionner la balance dsire.

SAFIR

- 49 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

le banquier slectionne la date de la balance et le type de balance gnrale dsire. Puis, il valide son choix. La forme rcupre ces paramtres et les remet lobjet balance globale. Celuici retrouve les donnes voulues. Ensuite, il remet le rsultat une forme dfinie qui laffiche au banquier. De plus, les donnes rcupres sont sauvegardes dans un fichier. le banquier envoie la balance globale, ainsi gnre, la banque centrale. A partir de ces deux diagrammes de squence et partir des besoins exprims dans le cahier des charges, la partie du diagramme de classe associe aux transactions est prsente dans la figure 17 :

Figure 17 : partie du diagramme de classe associe aux transactions.

SAFIR

- 50 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

2.2. Construction du modle danalyse


A partir des diagrammes de squence et des besoins fonctionnels, le modle danalyse est ainsi dgag. En fait, ce modle est bti partir des besoins et raffin par les collaborations tires des diagrammes de squence. Afin de simplifier lanalyse du systme, une hirarchie en paquetages UML savre la plus approprie et la plus parlante. Ce dcoupage permet une meilleure reprsentation des parties de lapplication puisquil est plus rduit et plus clair en explication. La figure 18 suivante prsente les principaux packages du systme tudi :

Figure 18 : diagramme de package du modle danalyse.

Comme les packages sont nombreux et pour faciliter le suivi du document, je vais dcrire brivement les packages analyss. Le package BalanceGAB inclut les trois packages : package Collecte , package Traitement et package Gestion . Ils sont dcrits comme suit :

SAFIR

- 51 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Package Collecte Ce package contient les classes qui permettent de raliser les collaborations de collecte. Jai prsent la collecte de transaction dans le diagramme de squence (figure 15). Cependant, il y a quatre autres schmas similaires la collecte de transaction qui sont : collecte du dtail des transactions dun GAB. collecte du dtail des transactions dun GAB par coupure trangre. collecte du dtail des transactions dun GAB par la coupure locale. collecte du rsum de la journe de tous les GABs. Package traitement Les classes de ce package rassemblent les donnes des GABs ayant envoy leurs balances quotidiennes, dautres sont dveloppes pour vrifier la conformit des donnes au format suivi et pour examiner leurs valeurs smantiques. Si cest valid, des classes de sauvegarde sont ainsi appeles ; par linsertion dans la base de donnes et la sauvegarde des donnes initialement rcupres partir des GABs. De plus, il y a prparation de lenvironnement pour la prochaine rception. Si les donnes reues ne sont pas conformes, des classes pour traitement des anomalies sont ainsi appeles. Ces classes ont pour tches : traitement des balances rejetes. traitement des balances non envoyes. traitement des balances rcupres. traitement des balances non rcupres. Package Gestion Pour chaque GAB nayant pas transmis sa balance ou elle est mal reue, ladministrateur systme ou le superviseur des GABs doit essayer de rcuprer cette

SAFIR

- 52 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

balance. Dans le cas ou ce nest pas possible de rcuprer la balance dun GAB donn cause dun crash disque, des classes de gestion sont appeles pour permettre de saisir manuellement toutes les transactions de change effectues par le GAB en dfaut. Package BalanceGlobale Ce package permet de remonter une balance globale pour une banque donne comme il permet de la scinder par institution ou par agence. De plus, il informe le serveur central de la banque du chiffre daffaire en dirham ralis ainsi que le total des commissions. Il remonte aussi par devise le montant total encaiss. Ce package se base essentiellement sur le package BalanceGAB . Package Edition Ce package permet la consultation des donnes des transactions effectues. En effet, il va gnrer des rapports relatifs aux principales informations utilises par la banque. Un prototype gnrique sera exploit par toutes les requtes ddition. Pour enrichir lutilisation de ldition, ce package offre la possibilit de sauvegarde des donnes dans des fichiers sous une multitude de format : XML, HTML, PDF et EXCEL. Package Parametrage Ce package permet ladaptation de lapplication selon lenvironnement dexcution dfinit par un utilisateur privilgi. De plus cette fonctionnalit offre une grande souplesse dans la phase de dploiement et permet la slection des services optionnels de lapplication et la gestion de ses ressources. Package Change Ce package englobe les fonctionnalits ncessaires pour la gestion des taux de change, leur rcupration et leur distribution.

SAFIR

- 53 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Package InterfaceUtilisateur Ce package englobe les fonctionnalits ncessaires pour la gestion de linterface des utilisateurs.

2.3. Analyse du comportement des entits dgages


Dans le but danalyser le comportement des classes du modle tudi, susceptibles davoir un comportement dynamique riche, ou davoir plusieurs tats, des diagrammes dtat/transition sont ainsi construit. Un diagramme dtat/transition spcifie la squence dtats quun objet peut avoir durant sa vie en rponse aux vnements qui lui adviennent, ainsi que les ractions correspondantes [ROQUESVALLEE01]. Toutes les classes du modle danalyse ne requirent pas ncessairement un diagramme dtat/transition. Il sagit donc de trouver celles qui ont un comportement dynamique complexe ncessitant une description pousse. Dans cette analyse, plusieurs classes requirent un diagramme dtat/transition. Toutefois, je ne vais prsenter quun seul concernant la BalanceGAB . Daprs ltude du cahier des charges, jai pu laborer le diagramme dtat/transition suivant :

SAFIR

- 54 -

ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

Figure 19 : diagramme tat/transition de lobjet BalanceGAB .

Dans cette figure, une BalanceGAB tant dclare pour chaque GAB actif dans une journe. A la fin de la journe, le processus de collecte se dclenche et agit sur lobjet BalanceGAB . Si la balance est valide, elle est positionne pour tre traite . Sinon, elle est mise non accepte . De plus, si elle est non reue pendant un temps dfini, elle est positionne comme telle. Cependant, elle est connue non rcupre si un message venant du guichetier le confirmant ainsi. Dans ltat non reu, si elle est valide, elle est dclare traite . Sinon, elle est non accepte ou non rcupre. Dans ltat non accept, un compteur est incrment chaque fois que la balance reue est errone. Or, si elle dpasse un nombre paramtr ou un message le confirmant, elle sera dfinit comme tant non rcupre. Finalement, si elle est valide, elle est dclare traite . Conclusion Dans ce chapitre, jai dtaill ltude fonctionnelle du projet. Elle est compose de deux phases : la capture des besoins fonctionnels et lanalyse. La phase de capture des besoins, consistait en la modlisation des utilisations du systme et la
SAFIR - 55 ENSIAS 2004/2005

Chapitre 3 : tude fonctionnelle du projet

ProChangeServer@WINCOR-NIXDORF

description textuelle de ces utilisations. La phase danalyse avait pour objectif la modlisation du systme par une collaboration dobjets qui permet de raliser les fonctionnalits attendues du systme. Dans le chapitre suivant, je vais prsenter ltude technique qui met en relief larchitecture logicielle mise en place et les diffrentes solutions technologiques adoptes pour construire le modle final de conception.

SAFIR

- 56 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Chapitre 4 : tude technique du projet

Dans ce chapitre, je vais prsenter la technologie J2EE adopte pour ProChangeServer. De plus, je vais expliquer larchitecture logicielle caractrisant lapplication. Frameworks dveloppement. Ensuite, Open je vais exposer pour les le Source choisi

SAFIR

- 57 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

1. Technologie J2EE
La technologie Java 2 Entreprise Edition (J2EE) dfinit la norme de dveloppement des applications dentreprise distribues et multi tiers. Elle permet de simplifier les applications dentreprise en se basant sur des composants modulaires normaliss. Ceci tant, en fournissant un ensemble complet de services et en grant automatiquement un grand nombre de dtails sur le comportement des applications. J2EE est compose de plusieurs technologies qui sont regroupes en trois catgories : composant, service et communication [wwwJAVASUN]. Technologies de type composant Les technologies de type composant sont utilises par les dveloppeurs afin de crer des composants logiciels dune application dentreprise notamment linterface utilisateur et la logique mtier. Elles permettent de dvelopper des modules rutilisables qui peuvent tre intgrs dans dautres applications. De plus, elles sont supportes par les services dinfrastructures de la plate-forme J2EE qui simplifie le dveloppement des applications. Elles permettent, aussi, dadapter les composants aux besoins des ressources de lenvironnement dans lequel ils sont dploys [wwwJAVASUN]. Technologies de type service Etant donn que la plupart des applications dentreprise ont besoin daccder aux systmes dinformation dentreprise, la plate-forme J2EE offre un ensemble de services tels que laccs aux bases de donnes (JDBC), le service de dsignation (JNDI), les transactions et les services de Messagerie. Technologies de type communication La plate-forme J2EE fournit un ensemble de technologies, permettant la communication entre clients et serveurs et entre les objets qui collaborent dans les diffrents serveurs. Comme lexemple des connecteurs aux systmes dinformation existants et linvocation des mthodes distantes travers le standard OMG-CORBA.

SAFIR

- 58 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

1.1. Architecture J2EE


Cest une architecture soutenue par SUN MICROSYSTEMS qui dfinit et fournit le modle de programmation multi tiers bas sur larchitecture des composants. Avec ce modle, des applications lgres peuvent interagir facilement avec le systme dinformation et les composants implantant la logique dentreprise sur des serveurs dapplications. Larchitecture J2EE consiste en trois parties : components : les composants qui prennent en charge la prsentation et la logique mtier. containers : fournit un contexte aux composants. Connectors: fournit laccs aux sources de donnes de lentreprise. Cet environnement supporte trois types de composants dapplications, dont les dfinitions seront prsentes par la suite : applets. servlets (incluant JSP). Enterprise JavaBeans (EJB). La figure 20 illustre les trois parties constituant larchitecture J2EE. Le noyau de serveur J2EE Server Core est un environnement de serveur dapplication qui fournit les services de gestion de ressources et de transactions [wwwTHOMAS].

Figure 20 : architecture J2EE.

SAFIR

- 59 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

1.2. Composants de base de J2EE


Comme cest mentionn, larchitecture J2EE est compose de plusieurs technologies qui sont regroupes en trois catgories : composant, service et communication. Dtaillons ces composants de base de J2EE.

Entreprise Java Beans


Cest un modle de composant logiciel rutilisable spcifi par SUN

MICROSYSTEMS en collaboration avec des industriels. Il est destin au dveloppement et au dploiement dapplications tablies en fonction du modle multi tiers. Il permet aux concepteurs dapplications de bnficier des avantages de Java et notamment de lindpendance vis vis de la plate forme. Lide est de programmer une seule fois de petits composants logiciels, de les utiliser et les rutiliser nimporte o [wwwREDBOOKIBM]. La spcification des EJB dfinit deux types de composants : les Session Beans, qui ne vivent que le temps de leurs activits et qui sont en permanence en interaction avec lutilisateur. Par contre, les Entity Beans, sont persistants et reprsentent des donnes issues dune base de donnes. Les Session Beans sont de deux types : Stateless Session Beans: sont des objets qui se comportent comme des composants serveurs et excutent des actions distance. Ces objets ne gardent aucune notion dtat entre deux invocations [PATZER00]. Ils reoivent des requtes provenant de diffrents clients et lordre des requtes ninflue pas sur leur excution. Statefull Session Beans: reprennent les fonctionnalits dinvocation distance des Stateless Session Beans, mais ajoutent la capacit de conserver un tat propre chaque client, dune invocation une autre. Les Entity Beans sont de deux types : Container Managed Persistance (CMP) : la persistance de lobjet est gre automatiquement par le serveur.

SAFIR

- 60 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Bean Managed Persistance (BMP) : la persistance de lobjet est gre manuellement par le bean lui-mme. Ce deuxime type des Entity Beans demande un grand effort du dveloppement de la part du programmeur vu quil doit contrler la persistance de lobjet [wwwREDBOOKIBM].

Servlets
Une Servlet Java est un programme Java qui se branche sur un serveur Web. Il est possible dtendre un serveur Web pour quil hberge des Servlets par le biais dun moteur de Servlets. La technologie des Servlets savre en fait plus adapte rpondre aux requtes de lutilisateur en invoquant des mthodes sur des EJB, puis en redirigeant la requte HTTP vers des pages HTML ou JSP qui afficheront le rsultat de la requte. Les Servlets sont donc utilises principalement comme un centre daiguillage qui interprte et dirige le flot de requtes de lutilisateur vers les composants EJB et renvoie lutilisateur les pages Web adquates [IBMBOOK].

Java Server Pages


Les JSP permettent de sparer efficacement le codage HTML de la logique applicative des pages Web. Ils sont utiliss pour accder des composants rutilisables, tels que des Servlets, des JavaBeans et des applications compatibles avec le langage Java [IBMBOOK]. Aprs cette prsentation de la plate-forme J2EE, je vais prsenter larchitecture logicielle du systme tudi, ainsi que les contraintes quelle subit, en passant par une dfinition de la notion darchitecture logicielle.

2. Architecture logicielle du systme


Une architecture logicielle exprime un schma dorganisation structurel fondamental pour les systmes logiciels. Elle fournit un jeu de sous-systmes prdfinis, spcifie leurs responsabilits, et elle inclut les rles et les instructions gnrales pour organiser les relations entre eux [wwwASTONS]. Ainsi, sans une bonne architecture, un systme dinformation est difficile comprendre, prdire, grer et optimiser. Les buts dune architecture sont :

SAFIR

- 61 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

la comprhension du systme tudi en dfinissant ses limites. la gestion de la croissance du systme.

2.1. Exigences de ProChangeServer


Larchitecture logicielle de ProChangeServer rpond un certain nombre de buts et contraintes en terme de scurit, de disponibilit et de maintenance. Le choix dune architecture logicielle constitue une tape technologique primordiale. En effet, il faut dfinir les grands objectifs techniques de la future architecture, cest--dire de bien prendre en compte lensemble des forces qui vont sexercer sur le futur systme ainsi que la puissance de chacune dentre elles [wwwASTONA]. La figure suivante prsente les objectifs techniques de larchitecture logicielle du ProChangeServer :

Figure 21 : objectifs techniques de larchitecture logicielle du ProChangeServer.

SAFIR

- 62 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Le tableau suivant fournit plus de dtail concernant les objectifs techniques du ProChangeServer:
Objectif Disponibilit Description Il doit tre en permanence la disposition de ses utilisateurs. ProChangeServer doit assurer un systme de scurit Scurit flexible permettant daccder aux fonctionnalits du systme selon les droits de lutilisateur, en plus de la gestion des autorisations et des authentifications. Evolutivit Il doit permettre dtendre le systme.

Rutilisation

ProChangeServer inclure la possibilit de rutiliser les modules du systme.

Figure 22 : objectifs techniques de larchitecture logicielle du ProChangeServer.

2.2. Architecture logicielle de ProChangeServer


Parmi les diffrentes faons de structurer une architecture, la mieux comprise et matrise en informatique est lapproche par couches [wwwASTONA]. Une couche (Layer en anglais) est une division logique, horizontale dun systme qui fournit une abstraction particulire du systme aux couches suprieures [wwwASTONS]. Chaque couche possde des responsabilits 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, jai adopt un dcoupage en couches. Une telle architecture permet galement dobtenir un niveau pouss de rutilisation en adoptant les solutions trouves aux problmes ayant un fonctionnement similaire. Cette exploitation est prise en compte pour chaque couche de larchitecture. La figure 23 suivante rsume le dcoupage adopt :

SAFIR

- 63 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Figure 23 : architecture de ProChangeServer en couches.

Couche Prsentation Cette couche est adopte principalement pour grer laspect visuel des applications et pour grer les interactions avec les utilisateurs. Charge de dessiner les fentres et les autres composants graphiques, elle intercepte les vnements et appelle la couche Application. De plus, elle vrifie les autorisations des utilisateurs auprs du service de scurit. Les rles de la couche Prsentation sont comme suit : gestion du domaine de lcran. affichage des pages Web. gestion de linteraction avec lutilisateur. validation syntaxique. La couche Prsentation tablit deux relations avec la couche Application : demandes de contenu la couche Application pour affichage et dition. ordres de traitement la couche Application pour cration, mise jour, suppression, etc.

SAFIR

- 64 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Couche Application Son but principal 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 dutilisation. Cest concrtement dans cette couche que lon voit les cas dutilisation issus de la partie analyse. Les rles de la couche Application sont les suivants : services spcifiques au domaine. services externes. contrle des cas dutilisation. Couche Domaine Cette couche est concentre sur le mtier de lapplication, cest--dire les rgles mtiers, smantiques et logiques. Cest lespace o rside le modle du domaine. Sa charge principale consiste garantir la validation smantique de linformation mtier. Les rles de la couche Domaine sont rsums ainsi : comportement mtier. validation smantique. Elle change ltat des composants entits mtiers avec la couche Persistance. Couche Persistance Cette couche est certainement lune des plus importantes. Cest ici que lon trouve les fonctionnalits de base qui permettent de crer, rechercher et supprimer des entits mtier dans le respect des proprits transactionnelles. Cest galement dans cette couche que les mcanismes de conversion objet/relationnel peuvent prendre place. Le rle de la couche Persistance est dfini comme suit : assurer les services basiques de cration, lecture, mise jour et suppression. permettre la conversion Objet/Relationnel.

SAFIR

- 65 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Ainsi, larchitecture choisie est base sur la logique des couches. Chaque couche fournit aux autres couches des services et utilise les services des autres. Dans ce qui suit, je vais prsenter les Frameworks utiliss au cours du dveloppement.

3. Notion de Framework
Un Framework capitalise lexpertise ncessaire en matire de programmation pour rsoudre une certaine classe de problme. Les programmeurs rutilisent les Frameworks pour profiter de cette expertise sans avoir rsoudre le problme. Un Framework aide les dveloppeurs fournir des solutions pour un problme et mieux les maintenir. Il fournit une infrastructure bien conue et bien pense. Ainsi, lorsque des nouvelles parties sont cres, elles peuvent tre ajoutes avec un impact minimal sur les autres parties du Framework. Un Framework sert, non seulement, raliser une application plus rapidement, mais permet dobtenir des applications de structures semblables. Ceci permet de simplifier considrablement leur maintenance [GHJV95]. Un Framework possde les caractristiques suivantes : un Framework est compos de multiple classes ou composants chacun deux propose une abstraction dun concept particulier. le Framework dfinit comment ces abstractions collaborent ensemble pour rsoudre un problme. Un bon Framework doit fournir un comportement gnrique qui peut tre utilis par plusieurs types dapplications. La notion de Framework est gnralement lie lOpen Source. En effet, cest un logiciel livr avec son code source et offre un droit dutilisation, de copie et de modification. Les produits Open Source sont rgis par des licences. La plus clbre entre elles est la GPL (General Public License) de la fondation GNU [wwwFSF]. Le choix dutiliser les Frameworks Open Source est justifi par plusieurs raisons : La premire est sans doute financire, les Frameworks Open Source sont gratuits. La deuxime est technique ; le code source des Frameworks et des logiciels Open

SAFIR

- 66 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Source tant disponible : un dveloppeur peut comprendre le fonctionnement des Frameworks pour corriger ses bugs ou encore procder des volutions. Le fait quun Framework soit Open Source ne signifie pas quil soit de mauvaise qualit, au contraire beaucoup de meneurs des projets Open Source sont des personnes trs comptentes qui sinvestissent par dfi technique et pour la reconnaissance de leurs pairs. Dautres arguments plus marketing laissent entendre que les Frameworks Open Source sont plus stables et que le respect des standards et la qualit du support sont meilleurs. Ces avantages ont cependant un prix, la documentation associe aux projets Open Source est souvent trs succincte, donc lors du choix dune solution Open Source il faut tenir compte des critres suivants: niveau dintgration des standards. maturit. facilit dutilisation. documentation.

4. Frameworks utiliss
Lutilisation des Frameworks est indispensable pour le dveloppement russi dun logiciel. Par la suite, je vais prsenter les diffrents Frameworks Open Source utiliss [JIMCONALLEN00].

4.1. Framework Struts


Les applications Web sont devenues de plus en plus courantes dans les entreprises. Nanmoins, leur dveloppement reste une pratique difficile ds que le projet devient un peu ambitieux. Le modle MVC permet de sparer au maximum les modules (IHM et mtier) afin de faciliter la maintenance des applications. Le paradigme MVC est un schma de programmation qui propose lorganisation de lapplication en 3 parties :

SAFIR

- 67 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

le modle qui contient la logique et ltat de lapplication. la vue qui reprsente linterface utilisateur. le contrleur qui gre la synchronisation entre la vue et le modle. Le contrleur ragit aux actions de lutilisateur en effectuant les actions ncessaires sur le modle et surveille les modifications du modle et informe la vue des mises jour ncessaires.

Figure 24 : modle MVC.

La figure 24 dcrit le traitement dune requte par le modle MVC : 1. lutilisateur manipule linterface homme/machine. Un vnement est envoy. Cet vnement est rcupr par le contrleur. 2. le contrleur effectue laction demande par lutilisateur en appelant les mthodes ncessaires sur le modle. 3. le contrleur informe la vue dun changement dtat du modle. 4. la vue interroge le modle afin de connatre son tat. 5. lutilisateur voit le rsultat de son action. Une telle sparation favorise le dveloppement et la maintenance des applications :

SAFIR

- 68 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

le

modle

tant

spar

des

autres

composants,

il

est

dvelopp

indpendamment. le modle nest pas li une interface, il peut donc tre rutilis. diminution de la duplication du code. centralisation du contrle. augmentation de la maintenance du code. Struts est un projet Open Source dvelopp par la communaut Apache. Il a dbut en mai 2000 sous la direction de Craig Mc Clanahan, qui participe galement au dveloppement du serveur Tomcat. Struts est un projet trs actif qui fournit le Framework MVC comprenant les composants suivants : un contrleur facilement configurable permettant dassocier des actions (mthode dun objet Java) des requtes http (Servlet). des librairies de tags spcifiques pour crer facilement une vue (JSP). des utilitaires permettant de remplir automatiquement des champs et dinternationaliser les applications. la validation syntaxique des donnes et la gestion des callbacks des pages Web.

4.2. Framework Hibernate


Si le modle objet offre des capacits de modlisation et dabstraction avances, il ne couvre pas la persistance des objets. Ainsi, la persistance nest pas gre automatiquement dans le modle objet. Par contraste, dans le modle relationnel, les donnes sont persistantes : une fois que la structure du schma relationnel est dfinie, les donnes qui y sont ajoutes restent accessibles durablement, tant quelles ne sont pas explicitement supprimes. La

SAFIR

- 69 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

dure de vie des donnes est totalement indpendante du cycle de vie de lapplication. Pour apporter ce caractre de durabilit des donnes au modle objet, il convient donc de trouver un moyen de prolonger lexistence des objets au-del de lexistence dune session applicative. Le souci de la persistance objet consiste donc laborer et mettre en uvre les mcanismes permettant de sauvegarder, de faon fiable et durable, ltat des objets manipuls par une application. Jai adopt la solution du mapping objet/relationnel. Puisque la base de donnes relationnelle est la technologie la plus utilise pour le stockage des donnes. De plus, les outils de mapping objet/relationnel permettent de rduire le temps de dveloppement du code daccs la base de donnes. Hibernate est un projet open source. Son rle est de permettre daccder dune manire objet aux donnes stockes dans une base de donnes relationnelle. Les principales fonctionnalits de Hibernate sont : lAPI permettant de crer, modifier, rcuprer des donnes dans une base de donnes relationnelles possdant un driver JDBC associ. la persistance transparente : pas dintrusion dans le code Java pour rendre une classe persistante. lassignation automatique des valeurs de cls trangres. le mapping O/R dfini dans un fichier XML.

4.3. Framework Log4j


La gestion des messages et des traces, permet le paramtrage de la manire dont lapplication sexcute. Cest pour faciliter la maintenance et de permettre une plus grande personnalisation (par exemple : les libells dfinis par langue). Pour la gestion des traces, jai utilis le Framework Open Source Log4j dont es fonctionnalits principales de Log4j sont : la configuration des paramtres de trace des applications se fait travers un fichier texte.
SAFIR - 70 ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

les paramtres de trace peuvent tre changs au moment de lexcution. les messages et les traces peuvent tre redirigs vers plusieurs sorties : fichier, cran, etc.

4.4. Framework JasperReports


Jai choisi le Framework JasperReports pour le dveloppement dditions. JasperReports est un Framework Java Open source pour ldition. Il a la possibilit de produire un contenu riche travers lcran, limprimante ou travers les fichiers PDF, HTML, XLS, CSV et XML. Cet outil permet : le formatage dynamique des lments du document. la programmation en java. laccs dynamique la base de donnes. lutilisation des fichiers de style pour la prsentation. la possibilit dutiliser les couleurs. linsertion des images dynamiquement. la sparation du modle de dveloppement (la vue et les donnes).

4.5. API JAAS


Il sagit dune API permettant limplmentation de lauthentification et laccs scuris dans les applets et les applications. Le modle de permissions prend en compte lorigine physique dune classe (pour un dossier ou une URL par exemple) mais aussi lorigine logique (grce la signature numrique de lentreprise qui a dvelopp la classe). JAAS permet aussi de complter un modle de permissions diffrent en proposant des fonctionnalits additionnelles.

SAFIR

- 71 -

ENSIAS 2004/2005

Chapitre 4 : tude technique du projet

ProChangeServer@WINCOR-NIXDORF

Conclusion Ce chapitre a t consacr ltude technique du systme. En effet, jai prsent la technologie utilise ainsi que larchitecture logicielle de lapplication. Ensuite, jai dtaill les Frameworks techniques utiliss dans le dveloppement du serveur ProChangeServer. Le chapitre qui suit, sera consacr la conception de ProChangeServer.

SAFIR

- 72 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Chapitre 5 : Conception du projet

Dans ce chapitre, je vais prsenter la phase de conception. Je vais reprendre le modle danalyse selon les Frameworks techniques et larchitecture adopts. Puis je vais exposer un exemple de factorisation de traitement. Ensuite, je vais prsenter quelques exemples des solutions adoptes.

SAFIR

- 73 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

1. Reprise des scnarios


A cette tape, je vais reprendre le modle danalyse et le raffiner selon les spcificits de larchitecture adopte et les solutions technologiques choisis. Cette reprise des schmas est ralise en radaptant les scnarios quoffre lapplication selon larchitecture dgage et les Frameworks conservs. Ces scnarios incluent, dans leurs logiques dimplmentation, les solutions techniques quoffre chaque Framework utilis et les dnouements que propose labstraction en couche. Dans ce sens, de nouvelles collaborations surgissent afin de rpondre cette logique. La figure25 suivante prsente le diagramme de collaboration relatif au cas dutilisation collecte dune transaction dun GAB:

Figure 25 : diagramme de collaboration relatif la collecte de transaction dun GAB.

Sur ce diagramme de collaboration de nouvelles entits apparaissent. Ces entits sont dues leffet du Framework Struts qui propose, comme dcrit prcdemment, un cadre pour la gestion de linteraction du systme avec les utilisateurs.
SAFIR - 74 ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Ncessairement, il y a la classe BalanceStatusForm qui hrite de la classe Form de Struts et qui comporte les informations manipules par lutilisateur. Ces informations sont rcupres au fur et mesure du traitement de lutilisateur pour construire des entits. Quant la classe BalanceStatusAction qui hrite de la classe Action de Struts, elle se charge dappeler ses entits pour en prendre leurs valeurs. Quand une mise jour est effectue, elle redirige laffichage de la page Web pour prendre en compte les nouvelles modifications. Pour accomplir son rle, la classe BalanceStatusAction fait appel lentit GestionaireBalance responsable du traitement des balances. Celle-ci se situe dans la couche Application de larchitecture adopte. En effet, sa responsabilit est de grer les objets du mtier et leur appliquer les traitements ncessaires afin de raliser la fonction dsire par lutilisateur. Le dtail du diagramme de collaboration de la figure25 permet de bien expliquer le rle des nouvelles entits. Ainsi, la squence des changes de messages du diagramme est la suivante : lutilisateur consulte ltat de la balance quotidienne et demande lintgration des nouvelles balances. le systme redirige lutilisateur vers une page Web, pour visualiser ledit tat et lui permet de lancer automatiquement le processus de collecte des donnes pour les balances des GABs non encore intgres. lentit BalanceStatusAction est ensuite appele pour scruter les nouvelles donnes venues et prsenter le sommaire des balances dj intgres. Ainsi, elle formate ces donnes selon les paramtres retourns par lappel de lobjet BalanceStatusForm . Cet acheminement dappel automatique dentits est dtaill dans le fichier de configuration Struts. cette phase lobjet BalanceStatusAction fait appel lobjet responsable du traitement GestionnaireBalance . Celui-ci se charge de la ralisation des traitements ncessaires travers lappel de la mthode getTransactionStatus() .

SAFIR

- 75 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

lentit

GestionnaireBalance

rcupre

la

requte

de

lobjet

BalanceStatusAction et fait appel lobjet Utility laide de la mthode getTransactionParameters() pour charger les paramtres de la transaction. ensuite, lentit GestionnaireBalance lance une instance de lobjet Transaction qui extrait chaque ligne du fichier de la transaction laide de la mthode loadTransactionData(). Comme cest expliqu dans les besoins fonctionnels, il faut valider cette ligne de transaction. lentit GestionnaireBalance cre une instance de lobjet Expression qui doit valider la transaction Cette laide de valide la la mthode transaction validateTransactionData(). mthode

syntaxiquement laide des expressions rgulires. une fois ladite vrification est accomplie, lobjet Transaction est sauvegard dans la base de donnes laide de la mthode saveTransactionData() . pour concrtiser laspect de la journalisation, lentit GestionnaireBalance cre une instance de lobjet Historique pour dcrire lexcution du systme cette tape laide de la mthode saveTransactionState() . aprs, lentit BalanceStatusAction rcupre la bonne excution de toutes les tapes appeles de lentit GestionnaireBalance . Puis, elle affiche lutilisateur laffirmation du succs du traitement par la redirection vers la page Web balanceSucces.jsp .

2. Factorisation des traitements


En observant les diagrammes de collaboration construits, jai constat quil y a des traitements qui se rptent dans plusieurs cas dutilisation. Une approche qui est la plus intuitive pour palier cette similitude de traitement est de les factoriser. Cette dmarche satisfait en mme temps les objectifs fonctionnels tracs auparavant. La figure26 suivante reprsente le diagramme de collaboration o la partie entoure par un cadre doit tre factorise :

SAFIR

- 76 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Figure 26 : partie du diagramme de collaboration devant tre factorise.

La similitude de traitement est visible sur deux niveaux : Premirement, ce diagramme de collaboration ne reflte que le traitement relatif une seule transaction. Cependant, un GAB effectue plusieurs transactions quotidiennement. Ce traitement se rpte autant de fois que le nombre des transactions. Deuximement et selon ltude fonctionnelle, les donnes de la balance sont rcupres en cinq tapes : rcapitulatif de la journe : Balance . liste des transactions : Transaction . dtail des transactions par devise : Denomination . dtail des transactions par les coupures de la devise trangre : Foreign . dtail des transactions par les coupures en Dirham : Local . Le changement ncessaire dans le diagramme de collaboration de la figure25 est de remplacer lappel de fonction getTransactionStatus() par getBalanceStatus() , getDenominationStatus() , getForeignStatus() et getLocalStatus() .

SAFIR

- 77 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Le changement se poursuit mme sur la logique de lappel. Par exemple, la validation syntaxique de lentit Transaction est diffrente de celle de lentit Denomination . Une classe gnrique est implmente pour ce traitement, la diffrence rside dans les caractristiques relatives chacune des parties dcrites. La figure27 suivante reprsente la classe BalanceStatus finalement adopte pour factoriser celles de TransactionStatus , DenominationStatus , ForeignStatus et LocalStatus .

Figure 27 : factorisation du traitement en BalanceStatus .

3. Solutions adoptes
3.1. Multi langage et messages
Compte tenu du caractre multi langage adopt par lapplication, la solution se base sur la manipulation des fichiers dinternalisations offerte par lenvironnement J2EE. De ce fait, chaque cl dans le fichier correspond un mot dune langue donne. Par ailleurs, chaque langue correspond un fichier groupant un ensemble de cls. Le fichier franais est nomm ApplicationRessources_fr.properties et celui anglais amricain est ApplicationRessources_us.properties . Chacun des fichiers a un ensemble de cls similaires, ce qui va les distinguer, cest la valeur de cette cl. Par exemple, la cl rate.update.confirm correspond au message renvoy lutilisateur lors de la confirmation de mise jour du taux de change.
SAFIR - 78 ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

De ce fait, la cl a la valeur La mise jour du taux de change est effectue dans le fichier des messages en franais et la valeur exchange rate is updated successfully dans le fichier des messages en anglais. Cette solution dinternationalisation sadapte pour chaque utilisateur en dtectant ses paramtres locaux. Elle est utilise lors de laffichage des libells et les messages sur la page Web. Dautre part, ces valeurs sont rcupres au nivaux du code pour le contrle dynamique des vnements dclenchs par les utilisateurs. La figure28 suivante reprsente ladaptation de linterface utilisateur selon la configuration relative lutilisateur en lui chargeant les messages et les libells adquats.

Figure 28 : Pattern pour ladaptation de lapplication selon les paramtres de lutilisateur.

3.2. Saisie de la date


Lutilisateur doit saisir la date de temps autre, par exemple pour afficher le rcapitulatif des balances dune priode donne, lutilisateur est invit saisir la date dbut et la date fin. Le problme se pose sur le format de la date saisie. En effet, les requtes utilisant un paramtre date erron ne trouvent pas leurs acheminements vers lutilisateur.

SAFIR

- 79 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Ainsi la conception dune interface graphique reprsentant le calendrier savrait ncessaire. La figure suivante montre comment lutilisateur peut manipuler une date sans avoir la saisir manuellement.

Figure 29 : Pattern de manipulation de la date travers un calendrier.

3.3. Affichage dynamique


Au cours de leur manipulation, les donnes sont rcupres partir dune base de donnes. De ce fait, leur nombre et leur gestion doivent tenir compte de cet aspect dynamique. Le problme se pose sur lindexation des donnes rcupres de la base de donnes. Toutefois, le Framework Struts standard gre ces donnes de faon statique, donc ne permet pas cet aspect dindexation. La solution rsidait dans lintgration dune librairie supplmentaire appele Struts-el . La figure30 montre ladaptation effectue pour palier ce problme. Lexemple prsent est celui de la mise jour du taux de change.

SAFIR

- 80 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Figure 30 : Pattern de gestion dynamique des donnes dans la page Web.

La valeur ajoute de laspect dynamique, offerte par la librairie Struts-el , est lajout dune classe Currency . Cette entit regroupe toutes les donnes devant tre gres de faon dynamique. Ainsi, la nouvelle fonctionnalit agit sur les objets de la classe Currency en les regroupant dans un ensemble index mapp aux entits de la base de donnes. Par ailleurs, la classe RateForm se charge denvoyer les donnes lutilisateur.

3.4. Edition dynamique


Ldition permet aux dcideurs de visualiser les donnes effectivement utilises dans lapplication. Puisque les donnes sont rcupres partir dune base de donnes, elles doivent tre gres dynamiquement. Le problme se pose en ladaptation du modle ddition quelque soit la taille des donnes rcupres de la base de donnes. Le Framework JasperReport gre cet aspect dynamique. De ce fait, une compilation est effectue chaque fois quil y a appel la fonctionnalit ddition. Lavantage de la sparation des donnes de la vue est prsent dans ce Framework. La figure31 montre les composants ncessaires pour raliser ldition. Lexemple prsent est celui de ldition du rcapitulatif de la balance quotidienne :

SAFIR

- 81 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Figure 31 : Pattern ldition de la balance.

Lutilisateur peut consulter la fonctionnalit ddition de la balance en appelant lobjet Edition . Celui-ci fait appel au projet associ en le compilant. Le projet AntProject recompile les fichiers ncessaires. BalanceBean dfinit lobjet devant tre imprim. BalanceSource reprsente linstanciation des objets BalanceBean dont les donnes sont obtenues partir de la base de donnes. BalanceReport dcrit le modle graphique o les donnes doivent tre insres. BalanceSourceApp fait lassociation entre les donnes et la vue pour construire la page dsire.

SAFIR

- 82 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Par ailleurs, les deux entits BalanceReport et BalanceSourceApp utilisent lAPI de JasperReports pour accomplir leurs finalits.

3.5. Tache planifie


Une tache planifie permet le lancement automatique des traitements rptitifs au dbut de chaque priode donne. Le problme tait de trouver un mcanisme paramtrable et gnrique. Comme exemple, les GABs remontent leurs balances quotidiennement, lutilisateur peut laisser ce traitement au systme. Une telle fonctionnalit est ralise par une compilation chaque fois quil y a paramtrage de cette automatisation. La figure32 suivante rsume les composants collaborant pour automatiser la collecte de la balance :

Figure 32 : Pattern dautomatisation de la collecte des balances GABs.

4. Modle final de conception


Jusquici, la construction du modle conceptuel est accomplie et les solutions pour son implmentation sont voues ; jai dfini, larchitecture et les couches quil propose. Je vais, maintenant, prsenter le diagramme de package final de conception dans la figure33 suivante :

SAFIR

- 83 -

ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Figure 33 : diagramme de package final de conception.

Ce diagramme de package est structur comme suit : IHM : ce package regroupe toutes les classes relevant de la couche prsentation. Cest dans ce package, que jai mis les classes relatives au Framework Struts. Application : ce package regroupe les classes qui appartiennent la couche Application de larchitecture ralise. Il comporte les gestionnaires, qui effectuent les traitements ncessaires aux requtes des utilisateurs et qui appellent les services techniques ncessaires. Configuration : ce package contient les classes qui encapsulent la

configuration ncessaire lexcution du systme. Logging : ce package reprsente le service de suivi et de traage et de journalisation. Scurit : ce package contient le Framework de scurit et qui assure le contrle de laccs aux fonctionnalits du systme. Domaine : ce package contient les classes mtiers du systme dtailles tout au long de ltude fonctionnelle. Historique : ce package contient les classes de lhistorisation.
SAFIR - 84 ENSIAS 2004/2005

Chapitre 5 : Conception du projet

ProChangeServer@WINCOR-NIXDORF

Persistance : ce package regroupe le Framework de persistance gnrique adopt. Au terme de cette phase de conception, jai rdig les documents suivants : les diagrammes de collaborations correspondants ladaptation des diagrammes de squence larchitecture choisie. les diagrammes de classes des diffrents patterns et le Framework de traitement dvelopps. le diagramme de package final. Conclusion Dans ce chapitre, jai prsent la phase de conception du projet dans lequel, jai repris les scnarios tablis dans la phase danalyse en incluant la branche technique tudie. Puis jai expos les solutions adoptes afin daboutir au modle final de conception. Dans le chapitre qui suit, je vais dtailler la phase de ralisation du projet.

SAFIR

- 85 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Chapitre 6 : Ralisation

Dans ce chapitre, je vais exposer la partie ralisation. Je vais prsenter les outils utiliss et je vais dcrire en dtail limplmentation du modle final de conception. Aprs, je vais dvoiler quelques crans de lapplication.

SAFIR

- 86 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

1. Outils utiliss
1.1. SGBD Oracle
Oracle est un systme de gestion de bases de donnes dit par la socit du mme nom Oracle Corporation, leader mondial des bases de donnes. Oracle se dcline en plusieurs versions : Oracle Server Standard, une version comprenant les outils les plus courants de la solution Oracle. Oracle Server Enterprise Edition. Oracle est un SGBD permettant dassurer : la dfinition et la manipulation des donnes. la cohrence des donnes. la confidentialit des donnes. lintgrit des donnes. la sauvegarde et la restauration des donnes. la gestion des accs concurrents. Outre la base de donnes, la solution Oracle est un vritable environnement de travail constitu de nombreux logiciels permettant notamment une administration graphique dOracle, de sinterfacer avec des produits divers et dassistants de cration de bases de donnes et de configuration de celles-ci. Les outils dOracle peuvent se classer selon diverses catgories : Les outils dadministration. Les outils de dveloppement. Les outils de communication.

SAFIR

- 87 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Les outils de gnie logiciel. Les outils daide la dcision. Durant la phase de dveloppement du projet, il fallait faire appel aux outils dadministration doracle pour limplmentation de la base de donnes et pour la manipulation des donnes sources. Parmi les outils utiliss au cours de dveloppement : Enterprise Manager Console. SQLPlus Worksheet. SQL Plus. Database Configuration Assistant. Import/Export : outil permettant dchanger des donnes entre deux bases Oracle.

1.2. Serveur dapplication JBoss


Le serveur dapplication est lenvironnement dexcution des applications ct serveur. Il prend en charge lensemble des fonctionnalits qui permettent plusieurs clients dutiliser une mme application. Gestion de la session utilisateur Comme les clients utilisant une mme instance dapplication sur le serveur, il est ncessaire que le serveur dapplication puisse conserver les contextes propres chaque utilisateur. Or la plupart des serveurs dapplication gnrent un identifiant unique pour chaque nouveau client et transmettent cet identifiant lors de chaque change HTTP par URL longs, variables caches ou cookies. Gestion des montes en charge et reprise sur incident Afin de grer toujours plus dutilisateurs, le serveur dapplication doit pouvoir se dployer sur plusieurs machines et ventuellement offrir des possibilits de reprise

SAFIR

- 88 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

sur incident (mme si dans la grande majorit des cas, on se contente dune gestion des montes en charge au niveau rseau). Ouverture sur de multiples sources de donnes Cest le serveur dapplication qui rend accessible les donnes des applications du systme dinformation. Il doit donc pouvoir accder de nombreuses sources de donnes. On sattend galement ce quil fournisse des mcanismes performants tels que le pooling de connexion base de donnes. Pour le choix dun serveur dapplication, jen ai tudi quatre qui se basent sur la plate forme J2EE. Ce sont les serveurs dapplications suivants: BEA WebLogic Server. IBM WebSphere. JBoss Application Server. Oracle Application Server. Je me suis inspir dune tude6 base sur la participation des 1,148 professionnelles des middleware. La source est le site web : Middleware.com, juin 2004. Cette tude, est aussi, commande par SUN MICROSYSTEMS. La figure suivante montre la part de chacun de ces serveurs dapplication :

Ralise par TheServerSide.com: online community of J2EE practitioners.

SAFIR

- 89 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Figure 34 : les principaux serveurs dapplication utilisant la plate forme J2EE.

JBoss Application Server 4.0 est le premier serveur dapplication Open Source tre certifi compatible la plate forme J2EE (Java 2 Platform, Enterprise Edition) en passant 23,000 tests de compatibilit. De plus, cest le premier implmenter lAO (Aspect Orientation) pour Java. Apportant, ainsi, plus de productivit, de performance et la capacit de gestion pour les utilisateurs. Par ailleurs, JBoss AS 4.0 est disponible pour les entreprises sous la licence Open Source LGPL (Lesser General Public License). Enfin, JBoss est compatible avec les principaux systmes dexploitation du march. La figure suivante montre une tude7 de la tendance des utilisateurs de JBoss relativement au systme dexploitation :

Multiples rponses sont permises.

SAFIR

- 90 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Figure 35 : tendance des utilisateurs du JBoss AS.

1.3. IDE Eclipse


Eclipse est un environnement de dveloppement intgr (Integrated Development Environment), dont le but est de fournir une plate-forme modulaire, pour permettre de raliser des dveloppements informatiques [wwwDOUDOUX]. IBM est lorigine du dveloppement dEclipse, qui est dailleurs toujours le cur de son outil Websphere Studio Workbench (WSW), lui mme la base de la famille des derniers outils de dveloppement en Java dIBM. Tout le code dEclipse a t donn la communaut par IBM, afin de poursuivre son dveloppement. Eclipse utilise normment le concept de modules nomms Plug-ins dans son architecture. Dailleurs, hormis le noyau de la plate-forme nomm Runtime , tout le reste de la plate-forme est dvelopp sous la forme de Plug-ins . Ce concept, permet de fournir un mcanisme pour lextension de la plate-forme afin doffrir la possibilit des tiers de dvelopper des fonctionnalits qui ne sont pas fournies en standard par Eclipse. Les principaux modules fournis en standard avec Eclipse concernent Java. Des modules sont en cours de dveloppement pour dautres langages notamment C++, Cobol, mais aussi pour dautres aspects du dveloppement (base de donnes, conception avec UML, ). Ils sont tous dvelopps en Java, soit par le projet Eclipse soit par des tiers commerciaux ou en Open Source.

SAFIR

- 91 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Bien que dvelopp en Java, les performances lexcution dEclipse sont trs bonnes, car il nutilise pas Swing pour linterface Homme/Machine mais un toolkit particulier nomm SWT associ la bibliothque JFace. SWT (Standard Widget Toolkit) est dvelopp en Java par IBM, en utilisant au maximum les composants natifs fournis par le systme dexploitation sous jacent. JFace utilise SWT et propose une API pour faciliter le dveloppement dinterfaces graphiques. SWT et JFace sont utiliss par Eclipse pour dvelopper le Workbench, qui organise la structure de la plate-forme et les interactions entre les outils et lutilisateur. Cette structure repose sur trois concepts : la perspective, la vue et lditeur. La perspective regroupe des vues et des diteurs, pour offrir une vision particulire des dveloppements. En standard, Eclipse propose huit perspectives. Les vues permettent de visualiser et de slectionner des lments. Les diteurs permettent de visualiser et de modifier le contenu dun lment du Workspace. En plus, il offre un espace de travail qui facilite les tches courantes du dveloppeur Java. En effet, il permet la coloration de la syntaxe, la compltion de code, le formatage et lindentation automatiques du code, la navigation et laccessibilit au sein des diffrentes ressources. Lespace de travail de lIDE Eclipse apporte un confort visuel et une facilit ingals dans la tche de codage du dveloppeur Java. Eclipse supporte en plus le factoring du code. Les capacits de factoring de code consistent rarranger les objets et la logique dune portion de code tout en prservant le comportement de lensemble. Eclipse fournit pour cela, un ensemble de facilits qui amliorent tout la fois la lisibilit et la structure du code, lextraction des mthodes et leur renommage dans le projet, par le biais dassistants de transformation et de propagation des modifications avant aperu. Pour le choix dun environnement de dveloppement intgr, jen ai tudi8 cinq qui se basant sur la plate forme J2EE. Les environnements suivants sont les plus complets du march. Cependant, Eclipse est gratuit:

Comparaison http://mojavelinux.com/wiki/doku.php

SAFIR

- 92 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

IDE Eclipse 3.0 IDEA (IntelliJ)

Prix Gratuit

Licence Open Source, CPL Propritaire

Url http://eclipse.org/

$500

http://www.jetbrains.com/idea

JBuilder (Borland)

$3,500 $995, gratuit pour utilisation non commerciale

Propritaire

http://borland.com/jbuilder

JDeveloper (Oracle)

Propritaire

http://www.oracle.com/technolo gy/products/jdev

NetBeans (Sun Microsystems)

Gratuit

Open Source (SPL) http://netbeans.org/

Figure 36 : comparaison entre les IDEs de dveloppement.

2. Reprise des scnarios


A cette tape, je vais traduire le modle de conception pour construire limplmentation. Cette reprise du modle est effectue en sappuyant sur les solutions techniques adoptes. Pour claircir cette dmarche, je vais reprendre le diagramme de collaboration relatif au cas dutilisation collecte de transaction dun GAB (tablit dans la partie de conception de la figure25) en expliquant limplmentation ralise.

SAFIR

- 93 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Figure 25 : diagramme de collaboration de collecte dune transaction dun GAB.

Aprs lidentification de lutilisateur, il invoque la page b_status.jsp partir du menu qui lui est associ. Cette figure37 est relative la deuxime tape du diagramme de collaboration prcdent :

Figure 37 : cran pour invoquer le statu de la balance.

SAFIR

- 94 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

La requte de lutilisateur est intercepte par la classe B_statusAction . La figure38 suivante dfinit les caractristiques des objets B_statusAction et B_statusForm . Le fichier struts-config.xml rsume cette association.

Figure 38 : mappage des objets dans struts-config.xml .

Lappel du message n3 est ralis cette tape. Lobjet B_statusAction rcupre les donnes de lobjet B_statusForm . Ceci est ralis aprs le casting de lobjet form . La figure 39 suivante prsente la rcupration des informations partir de lobjet B_ statusForm .

Figure 39 : rcupration des informations partir de B_statusForm .

Aprs la rcupration des paramtres de la transaction et le chargement des donnes dans des variables temporaires, la valeur syntaxique des donnes est contrle dans la partie n7 du diagramme de collaboration en question. La vrification est accomplie suivant une expression rgulire dfinissant le format des donnes utilises.

SAFIR

- 95 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

La figure40 suivante reprsente cette validation syntaxique :

Figure 40 : validation syntaxique des donnes.

Aprs ladite vrification, linsertion dans la base de donnes est effectue. Ensuite, la sauvegarde de ltat du systme est accomplie. La figure41 suivante reprsente comment est ralise la journalisation de ltat du systme aprs la bonne rception des donnes.

Figure 41 : journalisation de ltat du systme.

La bonne excution de ces tapes constitue laccomplissement du scnario collecte dune transaction dun GAB .

3. Interfaces de lapplication
Linterface de lapplication permet une meilleure communication entre le systme et lutilisateur. De ce fait, elle facilite lutilisation et aide la bonne exploitation des fonctionnalits.
SAFIR - 96 ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Puisque la solution ProChangeServer se base sur les technologies Web, laspect ergonomique adopt tire profit des potentialits offertes par les navigateurs Web.

3.1. Authentification
Lauthentification est la premire fentre rencontre par lutilisateur. Elle lui permet de sidentifier en saisissant son nom et son mot de passe. Selon son groupe dutilisateurs, le systme lui donne ses droits daccs. La figure42 suivante montre la forme dauthentification:

Figure 42 : authentification de lutilisateur.

3.2. Menu
Aprs lauthentification, le menu est activ selon le groupe de lutilisateur. La figure43 suivante illustre le menu relatif ladministrateur :

Figure 43 : menu relatif ladministrateur.

SAFIR

- 97 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

3.3. Menu Taux de change


Un utilisateur privilgi peut mettre jour les taux de change. La figure44 suivante reflte cette fonctionnalit :

Figure 44 : cran de gestion des taux de change.

3.4. Gestion de la date


Afin de faciliter lexploration du calendrier et de faciliter la saisie de la date selon un format particulier, jai reprsent le calendrier sous une page Web. La figure45 suivante indique la simplicit de la manipulation de la date:

SAFIR

- 98 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Figure 45 : calendrier pour slectionner la date.

3.5. Edition des rapports


Pour consulter les donnes existantes dans la base de donnes, le systme peut gnrer des ditions. La figure46 suivante illustre le sommaire de lactivit change dune journe.

SAFIR

- 99 -

ENSIAS 2004/2005

Chapitre 6 : Ralisation

ProChangeServer@WINCOR-NIXDORF

Figure 46 : dition de lactivit de change.

Conclusion Ce chapitre, a t consacr la phase de ralisation. Jen ai prsent les outils utiliss et jen ai expos les tapes dimplmentation selon le modle de conception construit. Enfin, jai prsent quelques crans de linterface homme/machine de lapplication. La conclusion de ce document fera lobjet de la partie suivante.

SAFIR

- 100 -

ENSIAS 2004/2005

Conclusion

ProChangeServer@WINCOR-NIXDORF

Conclusion
Mon projet consistait concevoir et dvelopper une solution de change de devises en libre service pour la socit WINCOR-NIXDORF. Cette solution avait pour objectif de permettre la consolidation des donnes rcupres des Guichets Automatiques Bancaires et de les remonter au serveur de la banque centrale. Pour raliser ce projet, jai commenc par tudier les besoins que spcifie le cahier des charges. Ensuite, jai construit une modlisation du systme en utilisant le langage UML, au terme de ltude fonctionnelle du projet. Aprs, jai dfini larchitecture logicielle de la nouvelle solution et jai choisi les Frameworks techniques ncessaires la ralisation du projet. Toujours dans ltude technique du projet, jai adopt un Framework de scurit, un autre de mapping objet/relationnel et un service de journalisation. Aprs ltude technique, la conception de la solution est ainsi labore. Dans cette phase, jai implment le modle danalyse obtenu en le rendant extensible et rutilisable, pour rpondre aux besoins futurs de lapplication. En plus, jai construit des solutions qui permettent la factorisation des traitements du systme et qui permettent la facilit de son utilisation. Au niveau de la ralisation, jai implment les modules de base de lapplication et ladministration de ses ressources. Cependant, il reste dautres modules tendre pour complter les fonctionnalits exprimes pour le nouveau systme. Durant tout le projet, jai veill respecter les objectifs requis en terme de qualit. Ce travail a fait appel aux nouvelles technologies de dveloppement qui sont riches et qui facilitent la traduction des besoins en produits logiciels. Cependant, elles ncessitent un effort considrable pendant la phase de documentation. Au cours de la priode du projet de fin dtudes, jai eu lopportunit de mettre en application diffrentes connaissances acquises durant mes tudes lENSIAS au profit des besoins exprims dans le monde professionnel relatif au service bancaire. Par ailleurs, jai tir grand bnfice de ce stage, aussi bien au niveau informatique
SAFIR - 101 ENSIAS 2004/2005

Conclusion

ProChangeServer@WINCOR-NIXDORF

quau niveau professionnel. En effet, jai pu raffiner mes capacits dabstraction et de conception. En plus, ce stage ma permis de raffiner ma mthodologie de travail et de dvelopper mon esprit dquipe. En perspective pour ce projet, je vais complter les modules restants de lapplication. En fait, le systme doit subir des amliorations au niveau de la prsentation en offrant plus de possibilits aux utilisateurs et plus de fonctionnalits dadministration.

SAFIR

- 102 -

ENSIAS 2004/2005

Bibliographie

ProChangeServer@WINCOR-NIXDORF

Bibliographie
Ouvrages:
[ACHERGUIELMOUTAOUKIL04] A. Achergui & J. Elmoutaoukil, Rapport de PFE ralisation dune solution de gestion et de suivi de projet en intranet pour OMNIDATA ENSIAS 2004. E. Gamma, R. Helm, R.E. Johnson, J. Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley 1995. Ted Husted et al: Struts in Action, 2003. Cours AD65F, WebSphere Application Server Advanced Edition and EJB, formation IBM. Jim Conallen, Concevoir des applications web avec UML, Eyrolles 2000. Pierre-Alain Muller, Nathalie Gaertner, Modlisation objet avec UML, Eyrolles 2000. A. PATZER, Programmation Java ct serveur (Servlet, JSP, EJB), Eyrolles 2000. A. PATZER, Programmation Java ct serveur (Servlet, JSP, EJB), Eyrolles 2000. Pascal Roques, Franck valle, UML en action, Eyrolles 2001.

[GHJV95]

[HUSTED03] [IBMBOOK] [JIMCONALLEN00] [MULLERGAERTNER00] [PATZER00] [PATZER00] [ROQUESVALLEE01]

SAFIR

- 103 -

ENSIAS 2004/2005

Bibliographie

ProChangeServer@WINCOR-NIXDORF

Adresse Internet :
[wwwASTONA] [wwwASTONS] [wwwCLUBJAVA] http://elisa.aston.fr Jrme LOUVEL, Guide darchitecture. http://elisa.aston.fr Jrme LOUVEL, Guide des standards. http://www.clubjava.com Didier Girard, Processus de dveloppement et nouvelles technologies. [wwwCROS] [wwwDOUDOUX] [wwwFSF] http://www.thierrycros.net Concepts et formalismes UML. http://www.perso.wanadoo.fr/jm.doudoux/java/ Dveloppons en Java avec Eclipse (2003). http://www.fsf.org/ Dfinition des diffrentes licences relatives aux produits Open Source. [wwwIMPROVE] [wwwJAVASUN] [wwwORACLE] [wwwPSTMARTIN] [wwwREDBOOKIBM] http://www.improve-institue.com Processus de dveloppement. http://Java.sun.com/J2EE Simplified Guide to the J2EE, Sun Microsystems. http://www.oracle.com site officiel de Oracle Corporation http://www.pstmartin.freesurf.fr Philipe Saint Martin, Cycles de dveloppement http://www.redbooks.ibm.com Servlet/JSP/EJB, Design and Implementation Guide for IBM WebSphere Application Servers. [wwwTHOMAS] [wwwWINCOR] http://www.psgroup.com A. THOMAS, Java 2 Platforme Entreprise Edition. http://www.wincor-nixdorf.com/internet/ma/ prsentation de la socit wincor-nixdorf Maroc

SAFIR

- 104 -

ENSIAS 2004/2005

Annexe 1 : Cycle de dveloppement en Y

ProChangeServer@WINCOR-NIXDORF

Annexe 1 : Cycle de dveloppement en Y

Ce chapitre est consacr la branche fonctionnelle du cycle de dveloppement. Je vais donc y prsente.

SAFIR

- 105 -

ENSIAS 2004/2005

Annexe 1 : Cycle de dveloppement en Y

ProChangeServer@WINCOR-NIXDORF

Processus Y
Le processus en Y ou Two Track Unified Process (2TUP) est une variante du Unified Process qui sarticule plus sur les aspects techniques. En effet ce processus permet de grer la complexit technologique, en lui rservant toute une branche de son cycle, dissocie de laspect fonctionnel. Il permet donc en plus, de rduire le risque technologique. Y est de nature itrative et incrmentale et permet, de ce fait, de faire des itrations dans ses diffrentes phases. Aussi, 2TUP offre un cadre de gestion des risques travers la dclaration et le suivi dune liste des risques identifis. Le schma reprsentant ce cycle de dveloppement est le suivant :

Figure 1 : cycle de dveloppement en Y.

SAFIR

- 106 -

ENSIAS 2004/2005

Annexe 1 : Cycle de dveloppement en Y

ProChangeServer@WINCOR-NIXDORF

Ce processus se compose de deux branches, une fonctionnelle et lautre technique. Ces deux branches se rencontrent dans la partie de la ralisation do son appellation de cycle en Y. La branche fonctionnelle est compose de deux phases : capture des besoins fonctionnels et analyse ; lobjectif de la phase de capture des besoins, est de dgager et de modliser les besoins fonctionnels du projet. Cette activit repose sur le modle des cas dutilisation du systme et utilise les lments de modlisation acteurs et cas dutilisation [wwwCROS]. Il sagit donc de construire les diagrammes des cas dutilisation, les diagrammes de squence et la description textuelle des cas dutilisation. La construction dune maquette du systme sera de forte utilit par la suite pour reprsenter les besoins fonctionnels. La phase danalyse prcise et structure les besoins pour mieux les comprendre et concourir un modle plus stable, au moyen de paquetages et des classes danalyse [wwwCROS]. En effet cette phase, fournit les classes danalyse, les ralisations des cas dutilisation (par des collaborations entre objets danalyse), les paquetages danalyse et le modle du systme de point de vue analyse. Afin de dgager les classes du modle, les analystes tudient les livrables de la phase prcdente et dduisent une partie du modle. Ensuite ils raffinent le modle ainsi construit par llaboration des diagrammes de squence ou de collaboration des objets qui ralisent les cas dutilisation. En ce qui concerne la branche technique, les objectifs sont [wwwIMPROVE] : rassembler les besoins techniques : scurit, monte en charge, intgration lexistant et autres. laborer une architecture logicielle et applicative qui rpond aux contraintes dgages. identifier les besoins en Frameworks techniques afin de palier aux manques de la technologie. Exemple : gestion de la touche Back des navigateurs, formulaires de saisies interactives, personnalisation de linterface graphique, moteur de persistance Objet/Relationnel avec expressions SQL/Objet.

SAFIR

- 107 -

ENSIAS 2004/2005

Annexe 1 : Cycle de dveloppement en Y

ProChangeServer@WINCOR-NIXDORF

proposer des rgles de dveloppement afin dindustrialiser limplmentation (gestion des exceptions, rgles de nommage, rgles de codage, etc.). Aprs la branche fonctionnelle et la branche technique, le processus propose la phase de conception. La phase de conception consiste reprendre le modle danalyse et le refaire selon les dcisions prises dans la branche techniques. Il sagit donc dadapter son modle danalyse larchitecture adopte et aux Frameworks techniques choisis et dvelopps. Cest aussi dans cette phase que se fait la conception des modles dimplmentation travers le choix des designs pattern appropris ou la construction de nouveaux modles. Aprs la phase de conception, les dveloppeurs abordent la phase de codage et tests. Il sagit l de coder les classes obtenues dans la phase prcdente. Ensuite, ces classes sont testes unitairement en vue dtre intgres dans le systme tout entier. Une fois construit, le systme est prt pour lactivit de test. Cette activit a pour but de tester le systme fabriqu en implmentation. Trois volets sont produits et utiliss : cas de test : ce quil faut tester dans le systme. Ils sapparentent aux cas dutilisation. procdures de test : la dmarche qui permet de drouler le test. composants de test : lenvironnement ncessaire pour pourvoir effectivement excuter les cas de test. Enfin, la phase de dploiement permet la mise en exploitation du logiciel construit, la formation des utilisateurs qui vont lutiliser par la suite.

SAFIR

- 108 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

Annexe 2 : Plan Assurance Qualit

Ce chapitre est consacr la branche fonctionnelle du cycle de dveloppement. Je vais donc y prsente.

SAFIR

- 109 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

1. Objectifs et caractristiques du Plan Assurance Qualit


Le plan dassurance et contrle qualit est un document qui prcise les lments permettant de sassurer de la mise en uvre et de lefficacit des activits prvues pour obtenir la qualit requise.

1.1. Objectifs du plan assurance qualit


Le prsent plan a pour objectif dexposer les dispositions prises pour rpondre aux exigences spcifies dans le cahier des charges du projet ProChangeServer dvelopp pour WINCOR-NIXDORF. De plus, il permet dobtenir la qualit du produit requise en contrlant le planning du projet.

1.2. Domaine dapplication


Les dispositions dcrites dans ce plan dassurance et de contrle de la qualit couvrent le processus de dveloppement, depuis la capture des besoins fonctionnels jusqu la mise en production du logiciel.

1.3. Responsabilits de ralisation et de suivi du plan


Ltablissement, les mises jour du plan et le suivi de son application ont t de ma responsabilit. La coordination des actions entreprendre pour la bonne excution du plan relve de la responsabilit de lencadrant de WINCOR-NIXDORF. Le tableau 1 rsume ces responsabilits :
Intervenants Najib SAFIR Khalid SAADAOUI Edition X X X Validation Suivi du plan Application X

Tableau 1 : responsabilits de ralisation et de suivi du PAQ.

SAFIR

- 110 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

2. Objectifs et engagements du projet


2.1. Objectifs gnriques du projet
Le projet ProChangeServer vise la ralisation dune solution de change des devises trangres en devise locale. Cette solution doit permettre la rcupration des informations envoyes par les GABs effectuant les transactions de change.

2.2. Objectifs qualit du projet


En terme de qualit le projet ProChangeServer doit satisfaire les critres suivants : disponibilit : le systme doit tre en permanence la disposition de ses utilisateurs. fiabilit : le systme le programme excute les fonctions attendues avec la prcision requise (taux de dfaillance minimal). volutivit : il doit tre possible dtendre le systme. rutilisation : il doit tre possible de rutiliser certains modules du systme. indpendance de loutil : surtout pour les services techniques, il doit tre possible de changer loutil utilis.

2.3. Activits dassurance et de contrle de la qualit


Je suis tenu de respecter les dispositions dcrites dans le PAQ et de vrifier ladquation du produit avec les normes en vigueur sur le projet. Dune autre part, le responsable du projet (lencadrant) veille ce que ces dispositions soient respectes.

SAFIR

- 111 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

Les activits qualits sont dans le tableau suivant :


Activits qualit Type dactivit Assurance qualit Descriptif de lactivit laboration du PAQ validation du travail Contrle qualit contrle de la bonne application des procdures applicables

Tableau 2 : activits dassurance et de contrle qualit.

3. Conduite du projet
3.1. Organisation du projet
Lorganisation du projet est rsume dans les tableaux :

ct WINCOR-NIXDORF :
Personne Khalid SAADAOUI chef de projets Rle

Tableau 3 : participants au projet ct WINCOR-NIXDORF.

ct ENSIAS :
Personne Ahmed ETTALBI Najib SAFIR Rle professeur encadrant Stagiaire lve ingnieur

Tableau 4 : participants au projet ct ENSIAS.

SAFIR

- 112 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

Dautre part, un comit de pilotage est constitu et a pour mission de suivre la progression du projet par rapport au planning dj tabli, de modifier le PAQ, de proposer des dcisions correctives ou de mettre en place des ajustements. Ce comit est compos des personnes suivantes :
Personne Ahmed ETTALBI, ENSIAS Khalid SAADAOUI, WINCOR-NIXDORF

Tableau 5 : comit de pilotage

Les personnes charges de la conception et le dveloppement du projet sont les suivants :


Personne Najib SAFIR, ENSIAS

Tableau 6 : dveloppeur du projet

3.2. Planification et suivi du projet


Un planning prvisionnel a t tabli lors de llaboration du cahier des charges et rajust au fur et mesure de lavancement du projet (Tableau 7).

SAFIR

- 113 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

Id 1 2 2.1 2.2 3 3.1 3.2 4 5 Total

Tche Etude prliminaire Etude Fonctionnelle Capture des besoins fonctionnels Analyse Etude technique Architecture logicielle et outils Dveloppement des Frameworks techniques Conception Codage et test

Date de dbut 21/02/2005 28/02/2005 28/02/2005 07/03/2005 21/03/2005 21/03/2005 28/03/2005 11/04/2005 02/05/2005

Date de fin 25/02/2005 18/03/2005 04/03/2005 18/03/2005 08/04/2005 25/03/2005 08/04/2005 29/04/2005 01/07/2005

Dure 5j 15 j 5j 10 j 15 j 5j 10 j 15 j 45 j 95j

Tableau 7 : planning prvisionnel

Pour le suivi des travaux et de dveloppement, il y a vrification des tapes suivantes : lvaluation de lavancement du projet. le traitement des problmes et des risques. le contrle de la cohrence des objectifs du projet (plan, cots, etc.).

SAFIR

- 114 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

4. Dmarche de dveloppement
4.1. Cycle de dveloppement
Le cycle de dveloppement adopt pour le projet est le cycle en Y ou 2TUP. Il suit les principes exhibs dans lannexe 1.

4.2. Description des tapes


4.2.1. Dmarrage du projet Cette tape consiste en la mise en place de lenvironnement de dveloppement ncessaire pour le projet. Activit : apprhender le cahier de charge, raliser le planning et le PAQ. 4.2.2. Capture des besoins fonctionnels Cette tape consiste en la dtermination de lensemble des services que le systme est cens fournir ses utilisateurs. Activits : dterminer les acteurs et les cas dutilisation du systme. description textuelle des cas dutilisation. construction de la maquette du systme. 4.2.3. Analyse Cette tape consiste en la construction dun modle danalyse pour le mtier du systme. Activits : laborer les digrammes de squence des cas dutilisation.

SAFIR

- 115 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

construction du diagramme de classe danalyse. construction du diagramme de paquetage. construction de diagramme dtat/transition pour les classes danalyse. 4.2.4. Dfinition de larchitecture logicielle et choix des outils Le but de cette tape est de dfinir larchitecture logicielle adopter et de dterminer les outils utiliser pour rpondre aux besoins de nature technique. Activits : dfinition de larchitecture logicielle. choix des outils. 4.2.5. Dveloppement des Frameworks Techniques Le but de cette tape est de dvelopper les Frameworks techniques ncessaires la ralisation des besoins techniques et qui sont indpendants de laspect fonctionnel du projet. Activits : dveloppement du Framework de scurit. dveloppement du Framework de mapping objet/relationnel. dveloppement du pattern de logging. 4.2.6. Conception Le but de cette tape est de construire limplmentation du modle danalyse et des couches logicielles de larchitecture choisie. Le Tableau rsume les activits et les rsultats de cette phase. Activits :

SAFIR

- 116 -

ENSIAS 2004/2005

Annexe 2 : Plan Assurance Qualit

ProChangeServer@WINCOR-NIXDORF

construction des diagrammes de collaboration pour raffiner le modle danalyse selon le Framework de prsentation Struts et larchitecture choisie. implmentation du modle danalyse. construction dun Framework de factorisation des traitements rptitifs. construction du diagramme des paquetages finaux. 4.2.7. Ralisation Le but de cette tape est de construire les classes rsultats de la conception et de les tester unitairement. Activits : codage des modules. tests unitaires de ces modules. Il faut signaler que certaines tapes ont subi un certain nombre ditrations avant daboutir aux rsultats raliss.

SAFIR

- 117 -

ENSIAS 2004/2005