Etude, Conpception Et Refonte D'une Plateforme

UNIVERSITE MOHAMMED V AGDAL
ECOLE MOHAMMADIA DINGENIEURS
Filire : Gnie Informatique

Option : Systmes dInformation
Ingnierie & Qualit du Logiciel
Mmoire de Projet de Fin dEtudes

N INF 2012/41
ETUDE, CONPCEPTION ET REFONTE DUNE

PLATEFORME BI
Ralis par :
Mlle Mounia OUHAJOU
M. Jihad TAWFIQ
Encadr par :
Prof. N. EL FADDOULI
M.R.AGOUDAL
M.M.BENYAHYA
Anne Universitaire : 2011- 2012

1
UNIVERSITE MOHAMMED V AGDAL

ECOLE MOHAMMADIA DINGENIEURS
Filire : Gnie Informatique

Option : Systmes dInformation
Ingnierie & Qualit du Logiciel
Mmoire de Projet de Fin dEtudes

N INF 2012/41
ETUDE, CONPCEPTION ET REFONTE DUNE

PLATEFORME BI
Ralis par :
Mlle Mounia OUHAJOU
M. Jihad TAWFIQ
Soutenu le 31 mai 2012 devant le jury :
M. S. BENNANI
Professeur lEMI
Prsident
Mme. A. RETBI
Professeur lEMI
Rapporteur
M. N. EL FADDOULI
Professeur lEMI
Encadrant interne
M. R. AGOUDAL
OriginalSoft System
Encadrant externe
Anne Universitaire : 2011- 2012

2
Ddicace
A mes trs chers parents,
Tous les mots du monde ne sauraient exprimer limmense amour que je vous
porte, ni la profonde gratitude que je vous tmoigne pour votre affection, votre
soutien et les valeurs que vous minculquez toujours. Sans vous, je ne serais pas
lhomme que je suis aujourdhui.
Au grand Dr. Abdessamad Tamouro, mon mentor, second pre et ami,
Cest grce nos innombrables heures passes ensemble que mes navires ne
perdent plus le cap. Merci pour tout lamour que tu maccordes, pour toutes les
leons que tu mapprends. Que cet humble travail puisse te rendre fier de moi.
A mon frre Nizar, mon meilleur ami et compagnon de lutte.
Que ce travail sajoute nos combats mens ensemble. Sache que je crois toujours
en toi et que tes ralisations sont des mdailles que jaccroche firement ma
poitrine.
A mon oncle, M. Jamal Benomar,
Ton parcours extraordinaire depuis les geles de la rpression jusquau sommet
des Nations-Unis est ma vritable inspiration.
A la trs chre Khalti Khadija, pour tous les sentiments damour que tu me
portes.
A ma surette Nadine.
A la mmoire de mes grand-mres, du grand-pre que je nai jamais connu.
A ma binme trs spciale Mounia,
A mes amis et camarades :
Ado, Anouar, Halim, Hassan, Java, Joe, Kristina, Lamya, Mahdi, Mehdi,
Mouna, Mustapha, Omar, Ouajih, Oussama, Petra, Rubio, Salma, Solaymane,
Soufiane, Souhail The Boss et tous les autres.
Jihad
3
Ddicace
A mon adorable mre et mon agrable et cher pre,
Nul mot ne pourra exprimer ma gratitude et ma reconnaissance envers vous deux,
mes trs chers parents. Je ne cesserais de vous remercier pour tous les sacrifices
que vous avez faits mon gard. Vous tes les toiles qui ornent mon univers. Je
vous aime
A mon cher frre et ami Habib,
Cette diction est un rappel pour que tout au long de ma vie, je remercie toujours
le ciel de tavoir comme frre
A ma chre sur confidente Karima,
Je naurais espr avoir meilleure sur. En guise de mon amour, je te ddie le
prsent travail.
A mon tante et seconde mre Rqia,
Tu mas tant couvert dattention. Merci pour ton soutien et appui.
A mes grands-parents maternels,
Merci pour toute lattention que vous portez mon parcours et mon travail.
A la mmoire de mes grands-parents paternels,
A mes oncles, tantes, cousins et cousines,
A mon binme,
Merci pour ton appuie, ton soutien permanent et ta comprhension.
A mes chres amies,
Amina, Amal, Asma, Assia, Fatima, Ghizlane, Imane, Soukaina, Yasmine
A mes amis et camarades,
Abrar, Aicha, Aziz, Fadwa Hasna, Houda, Mariam, Maria, Meriem, Nabil,
Ouissam, Salah, Sara, Siham, Solaymane, Sophia, Smail, Redouane,Youssef,
Yassine, Wafaa, Wahiba
Mounia
4
Remerciements
Au terme de ce projet, nous tenons exprimer notre gratitude envers tous
ceux qui ont assist de prs ou de loin sa ralisation.
Nous remercions ardemment notre encadrant lEcole Mohammadia
dIngnieurs Monsieur le professeur N. EL FADDOULI pour la qualit indite
de son suivi et la pertinence de ses conseils
Nous tenons remercier chaleureusement Messieurs R. AGOUDALE et
M. BENYAHYA, chefs de projet Original Soft System pour nous avoir
impliqus dans ce projet, pour le savoir-faire quils nous ont transfr.
Nous adressons nos vifs remerciements :
Monsieur le professeur S. BENNANI, chef du dpartement informatique,
pour nous avoir honor en prsidant le jury.
Madame la professeure A. RETBI, professeure lEcole Mohammadia
dIngnieurs pour avoir accept de juger et valuer notre projet.
Un grand merci galement lensemble du corps professoral et
administratif lEcole Mohammadia dIngnieurs pour son support et sa
disponibilit.
Rsum
Les logiciels de gestion intgre et daide la dcision reprsentent un

devis important pour lamlioration des performances des entreprises.
Cependant les cots dacquisition et de mise en place
des solutions
commercialises par les acteurs majeurs du march demeurent trs levs.

Conscients de ces faits, les responsables d'Original Soft System ont lanc
le projet Optimis. Construit en J2EE/Swing et adapt aux PME marocaines, il
sagit dun ERP qui assure la majorit des fonctionnalits exiges par une
entreprise : gestion du personnel, de la documentation, des achats, des ventes, du
stock
Original Soft System dsire complter sa solution par une plateforme
dcisionnelle. Cette dernire doit fournir aux dcideurs des entreprises
utilisatrices une meilleure prise de dcision. Parmi les traitements que la
plateforme doit assurer : le chargement et transformation des donns depuis
diffrents bases de donnes, grer les processus de transfert et garantir un
reporting volu.
Dans notre projet de fin dtudes, nous avons mis en application les
lments dj prsents de la plateforme dans la construction dun DataMart pour
lactivit des ventes, en passant par la collecte des indicateurs, le choix du
modle et la phase ETL sous Talend Open Studio. Nous avons galement conu
et gnr des rapports dtat laide diReport puis nous avons procd au
dveloppement dans la plateforme Optimis Report des fonctionnalits daccs et
diffusion des rapports.

.

.
Original Soft System Optimis
J2EE Swing

.
Original Soft System Optimis
.
.

Talend Open Studio
iReport
.
Abstract
Enterprise Resource Planning and decision support softwares represent a significant

tool for improving business performances. However, the costs of acquisition and
implementation of solutions promoted by the market leaders remain very high.
Recognizing these facts, Original Soft Systems executives launched the project
Optimis. The latter is an ERP built in J2EE/Swing customized to provide the majority of
functionalities required by small-size Moroccan companies: Stock, sales, purchases, staff
In order to market a complete solution, Original Soft Systems desires to associate a
decisional platform to its ERP. The platform Optimis Report must perform many treatments in
order to support decision makers from extraction, transformation and loading of data in new
structures (datamarts and datawarehouses) to reporting.
In our graduation project, we have implemented the existing elements of the
platform in the construction of a DataMart for sales activity, through the collection of
indicators, the choice of model and the ETL phase via Talend Open Studio. We also
designed and generated reports using iReport and
then we
proceeded to
develop inside
platform report access and distribution features.
Liste des acronymes

Acronyme
Signification
2TUP
BI
CA
CRM
DM
DWH
ERP
ETL
OSS
SI
SQL
TOS
UML
XML
Two-Track Unified Process

Business Intelligence
Chiffre daffaires
Customer Relationship Management
DataMart
DataWarehouse
Entreprise Ressources Planning
Extract-Transform-Load
OriginalSoft System
Systme dinformation
Structured Query Language
Talend Open Studio
United Modeling Language
Extensible Markup Language
Liste des figures
N figure
Figure 1.1
Figure 1.2
Figure 2.1
Figure 2.2
Figure 3.1
Figure 3.2
Figure 3.3
Figure 3.4
Figure 3.5
Figure 3.6
Figure 3.7
Figure 3.8
Figure 3.9
Figure 3.10
Figure 3.11
Figure 3.12
Figure 4.1
Figure 4.2
Figure 4.3
Figure 4.4
Figure 4.5
Figure 4.6
Figure 4.7
Figure 4.8
Figure 4.9
Figure 4.10
Figure 4.11
Figure 4.12
Figure 4.13
Figure 5.1
Figure 5.2
Figure 5.3
Figure 5.4
Figure 5.5
Figure 5.6
Figure 5.7
Figure 5.8
Figure 5.9
Figure 5.10
Nom figure
Architecture fonctionnelle de la solution
Cycle de dveloppement SCRUM
Exemple de schma en toile
Exemple de schma en flocon
Schma conceptuel de FAIT_VENTE
Schma conceptuel de FAIT_PAIEMENTS
Schma conceptuel global du DataMart Ventes
Paramtrage de la connexion la BD source
Connexion avec BD source et slection des tables des donnes
extraire
Connexion au DM et slection des tables alimenter
Job DIM_CLIENT
Job DIM_ARTICLE
Job DIM_FACTURE
Job FAIT_VENTE
Job FAIT_PAIEMENT
Scheduler de Talend Open Studio
Etapes de cration de rapport
Fonctionnement de JasperReports
Interface daccueil de iReport
Liste des drivers de connexion aux sources de donnes
Paramtrage de la connexion au DataMart
Liste des Templates proposes par iReport
Saisi de la requte SQL
Rapport des CA par client
Rapport des CA par produit pendant une dure donne
Rapport du total des paiements reus par rapport au total des factures
mises pour un client.
Transfert des fichiers dans WinSCP
Chargement des rapports dans Optimis
Saisi de valeur de paramtre de rapport dans Optimis
Cycle de dveloppement de la mthode 2TUP
Interface dOptimis avec longlet reporting ouvert.
Interface de chargement des rapports dans Optimis
Interface de liste des catgories des rapports
Interface de liste des rapports affects une catgorie
Diagramme des cas dutilisation du module reporting
Diagramme des classes
Diagramme de squence dautorisation de rapport un utilisateur et
excution
Diagramme de squence dautorisation de rapport une liste,
dfinition dhoraires de diffusion et paramtres
Interface de cration de listes de diffusion
Page
17
19
22
23
27
28
28
30
31
31
32
32
32
33
33
34
35
36
37
37
38
39
39
41
42
43
44
44
45
47
48
48
49
49
51
57
58
59
60
10
Figure 5.11
Figure 5.12
Figure 5.13
Figure 5.14
Figure 5.15
Interface principale dajout de destinataires aux listes

Interface de choix de liste de diffusion pour ajout
Interface dinsertion de destinataires
Interface daffectation dun destinataire une liste
Interface de saisi dhoraire et paramtre denvoi dun rapport.
60
61
62
62
62
11
Liste des tableaux
N tableau
Nom tableau
Page
Tableau 1.1
Planning du projet
29
Tableau 5.1
Fiche de description de cas dutilisation Crer liste de diffusion
52
Tableau 5.2
Fiche de description de cas Ajouter destinataire une liste
53
Tableau 5.3
Fiche de description de cas Dfinir horaires denvoi une liste
54
Tableau 5.4
Fiche de description de cas Autoriser rapport une utilisateur
55
Tableau 5.5
Fiche de description de cas Consulter historique de paramtrage
56
12
Table des matires
INTRODUCTION:................................................................................................................... 17
CHAPITRE I : CONTEXTE GENERALE DU PROJET :...................................................... 18
1. Prsentation de lorganisme daccueil :......................................................................... 18
2. Prsentation du projet : .................................................................................................. 18
2.1.
Problmatique : ...................................................................................................... 18
2.2.
Objectifs : ............................................................................................................... 19
2.3.
Contraintes : ........................................................................................................... 20
2.4.
Dmarche : ............................................................................................................. 20
2.5.
Planning : ............................................................................................................... 21
3. Conclusion :................................................................................................................... 22
1. Architecture dcisionnelle : ........................................................................................... 23
1.1.
Business Intelligence : ........................................................................................... 23
1.2.
DataMart : .............................................................................................................. 23
1.3.
Modlisation DataMart/DataWarehouse : ............................................................. 24
2. Extraction des donnes : ................................................................................................ 25

3. Reporting : ..................................................................................................................... 26
4. Conclusion :................................................................................................................... 26
CHAPITRE III : CONCEPTION ET REALISATION DE DATAMART DE VENTES : ..... 27
1. Choix des indicateurs : .................................................................................................. 27
2. Modlisation : ................................................................................................................ 27
2.1.
Dmarche suivie pour la modlisation :................................................................. 27
2.2.
Dimensions recueillies : ......................................................................................... 28
2.3.
Choix du modle : .................................................................................................. 28
3. Schma conceptuel des donnes: .................................................................................. 28

4.1.
FAIT_VENTE : ..................................................................................................... 28
4.2.
FAIT_PAIEMENT : .............................................................................................. 29
4. Implmentation ETL : ................................................................................................... 30

4.1.
Composants Talend utiliss : ................................................................................. 31
4.2.
Connexion la base de donnes : .......................................................................... 31
4.3.
Chargement des tables de dimensions : ................................................................. 33
4.4.
Chargement des tables de faits : ............................................................................. 35

13
5. Mise jour des donnes du DataMart : ......................................................................... 35

6. Conclusion :................................................................................................................... 36
CHAPITRE IV : PROCESSUS DE REPORTING :................................................................ 37
1. Gnralits :................................................................................................................... 37
2. Les rapports : ................................................................................................................. 38
2.1.
Chiffre daffaire par client : ................................................................................... 42
2.2.
Chiffre daffaire par produit pendant une dure donne : ...................................... 43
2.3. Total des paiements reus par rapport au total des factures mises pour un client
donn : .............................................................................................................................. 44
3. Excution des rapports dans Optimis Report Viewer : ................................................. 45
Conclusion :.......................................................................................................................... 47
CHAPITRE V : CONCPETION ET REALISATION DOPTIMIS REPORT VIEWER ET
SHARE :................................................................................................................................... 48
1. Mthodologie : .............................................................................................................. 48
2. Analyse fonctionnelle : .................................................................................................. 49
2.1.
Analyse et critique de lexistant : ........................................................................... 49
2.2.
Etude de la problmatique : ................................................................................... 52
2.3.
Description des fonctionnalits principales : ......................................................... 52
3. Analyse technique : ....................................................................................................... 52

4. Conception : .................................................................................................................. 53
4.1.
Identification des profils utilisateurs :.................................................................... 53
4.2.
Modlisation UML : .............................................................................................. 53
5. Ralisation : ................................................................................................................... 61
5.1.
Cration de listes de diffusion : ............................................................................. 61
5.2.
Ajout de destinataires une liste : ......................................................................... 62
5.3.
Saisi de dtails de diffusion : ................................................................................. 63
CONCLUSION ET PERSPECTIVES : ................................................................................... 65

WEBOGRAPHIE: .................................................................................................................... 66
ANNEXES : ............................................................................................................................. 67
14
Table des matires
INTRODUCTION:................................................................................................................... 17
CHAPITRE I : CONTEXTE GENERALE DU PROJET :...................................................... 18
1. Prsentation de lorganisme daccueil :......................................................................... 18
2. Prsentation du projet : .................................................................................................. 18
2.1.
Problmatique : ...................................................................................................... 18
2.2.
Objectifs : ............................................................................................................... 19
2.3.
Contraintes : ........................................................................................................... 20
2.4.
Dmarche : ............................................................................................................. 20
2.5.
Planning : ............................................................................................................... 21
3. Conclusion :................................................................................................................... 22
1. Architecture dcisionnelle : ........................................................................................... 23
1.1.
Business Intelligence : ........................................................................................... 23
1.2.
DataMart : .............................................................................................................. 23
1.3.
Modlisation DataMart/DataWarehouse : ............................................................. 24
2. Extraction des donnes : ................................................................................................ 25

3. Reporting : ..................................................................................................................... 26
4. Conclusion :................................................................................................................... 26
CHAPITRE III : CONCEPTION ET REALISATION DE DATAMART DE VENTES : ..... 27
1. Choix des indicateurs : .................................................................................................. 27
2. Modlisation : ................................................................................................................ 27
2.1.
Dmarche suivie pour la modlisation :................................................................. 27
2.2.
Dimensions recueillies : ......................................................................................... 28
2.3.
Choix du modle : .................................................................................................. 28
3. Schma conceptuel des donnes: .................................................................................. 28

4.1.
FAIT_VENTE : ..................................................................................................... 28
4.2.
FAIT_PAIEMENT : .............................................................................................. 29
4. Implmentation ETL : ................................................................................................... 30

4.1.
Composants Talend utiliss : ................................................................................. 31
4.2.
Connexion la base de donnes : .......................................................................... 31
4.3.
Chargement des tables de dimensions : ................................................................. 33
4.4.
Chargement des tables de faits : ............................................................................. 35

15
5. Mise jour des donnes du DataMart : ......................................................................... 35

6. Conclusion :................................................................................................................... 36
CHAPITRE IV : PROCESSUS DE REPORTING :................................................................ 37
1. Gnralits :................................................................................................................... 37
2. Les rapports : ................................................................................................................. 38
2.1.
Chiffre daffaire par client : ................................................................................... 42
2.2.
Chiffre daffaire par produit pendant une dure donne : ...................................... 43
2.3. Total des paiements reus par rapport au total des factures mises pour un client
donn : .............................................................................................................................. 44
3. Excution des rapports dans Optimis Report Viewer : ................................................. 45
Conclusion :.......................................................................................................................... 47
CHAPITRE V : CONCPETION ET REALISATION DOPTIMIS REPORT VIEWER ET
SHARE :................................................................................................................................... 48
1. Mthodologie : .............................................................................................................. 48
2. Analyse fonctionnelle : .................................................................................................. 49
2.1.
Analyse et critique de lexistant : ........................................................................... 49
2.2.
Etude de la problmatique : ................................................................................... 52
2.3.
Description des fonctionnalits principales : ......................................................... 52
3. Analyse technique : ....................................................................................................... 52

4. Conception : .................................................................................................................. 53
4.1.
Identification des profils utilisateurs :.................................................................... 53
4.2.
Modlisation UML : .............................................................................................. 53
5. Ralisation : ................................................................................................................... 61
5.1.
Cration de listes de diffusion : ............................................................................. 61
5.2.
Ajout de destinataires une liste : ......................................................................... 62
5.3.
Saisi de dtails de diffusion : ................................................................................. 63
CONCLUSION ET PERSPECTIVES : ................................................................................... 65

WEBOGRAPHIE: .................................................................................................................... 66
ANNEXES : ............................................................................................................................. 67
16
INTRODUCTION:
Le Maroc occupe une place pondre sur la scne conomique rgionale que ce soit
en tant que pays mergent bon rythme de croissance ou en tant que nouveau hub attractif
dinvestissements. Comme le dveloppement du tissu conomique du pays sappuie
essentiellement sur les petites et moyennes entreprises, ces dernires se trouvent dans
lobligation damliorer leur rendement et de sadapter de hauts niveaux de performance que
le dcollage conomique et la comptition imposent.
Le recours linformatisation a montr sa primordialit dans les stratgies
dencouragement et de mise niveau de lentreprenariat dans plusieurs pays. Pour cela,
lusage des systmes dinformation de gestion et daide la prise de dcision est de plus en
plus exig.
Comme les acteurs majeurs du march des progiciels de gestion intgrs et doutils
dinformatique dcisionnelle (SAP, SAGE, Microsoft, ) imposent des cots considrables
dacquisition et de mise en place de leurs solutions ainsi que ceux de la formation excdant
les capacits des PME marocaines. Original Soft System, start-up marocaine avec solide
exprience de ses collaborateurs, a rflchi prsenter un produit rassemblant la fois un
ERP 1 et une suite BI adapts lentreprise marocaine.
Le produit Optimis quOriginal Soft System dveloppe se base principalement sur des
outils Open Source qui ont prouv leur efficacit comme : Talend Open Studio pour
lextraction, transformation & chargement des donnes, iReport pour le reporting ainsi que le
Framework de dveloppement J2EE Open Swing.
Lobjectif de notre projet de fin dtudes consiste soumettre la chane doutils
dcisionnels mis en place des traitements squentiels commencer par la ralisation de
DataMart de lactivit des ventes. Les rsultats manant de cette nouvelle structure de
donnes sont exploits avec une plus large envergure dans les outils de reporting. Il est
galement question denrichir le produit en ajoutant des fonctionnalits daccs aux rapports
dtat desquels une entreprise peut avoir besoin.
Ce rapport se compose de cinq chapitres, le premier prsente laspect organisationnel
du projet. Quant au deuxime, il englobe les notions et les techniques impliques. Le
troisime chapitre expose la conception et la ralisation du DataMart des ventes. Nous avons
consacr le quatrime chapitre notre ralisation de rapports via iReport. Le dernier chapitre
prsente notre contribution lenrichissement de la plateforme Optimis Report.
Annexe A : ERP
17
CHAPITRE I : CONTEXTE GENERALE DU PROJET :

1. Prsentation de lorganisme daccueil :
OriginalSoft System (OSS) est une socit marocaine de services spcialise dans les
nouvelles technologies de linformation et de la communication. Cr en 2010, son sige
social est bas Rabat.
OSS est une entreprise taille humaine qui a su dvelopper travers lexpertise de ses
collaborateurs un vritable mtier autour de sa fonction de socit de services. La double
expertise, technique et fonctionnelle, a permis OSS de proposer des services allant du
conseil sur le terrain (audit et conseil informatique, en production, maintenance, qualit,
achat, stocks), vers linformation des rsultats et adaptation des logiciels.
A travers son exprience, OSS a conu et ralis le logiciel Optimis. Ce dernier est un
logiciel intgr destin optimiser la gestion dentreprises.
Votre satisfaction, notre soucis, notre fiert ; telle est la devise adopte par les
dcideurs de lentreprise. Ainsi, OSS sest fixe comme objectif de rpondre aux
proccupations de ses clients qui sont constitus des PME-PMI, leur apporter une expertise
technique et fonctionnelle de pointe, leur proposer des solutions avec un meilleur rapport
qualit/prix. La stratgie dOriginalSoft System est dtablir avec ses clients une collaboration
long terme.
2. Prsentation du projet :
2.1.Problmatique :
Loffre dOriginalSoft System est centre autour du logiciel Optimis qui a t adapt,
customis et enrichi afin de rpondre aux besoins des PME-PMI marocaines. Cest une
solution base sur jAllInOne 2 ; un ERP libre dvelopp en communaut en sappuyant sur la
bibliothque Swing de Java et suivant le paradigme MVC 3.
Pour suivre les volutions de linformatique et afin de fournir aux entreprises
utilisatrices dOptimis les moyens qui leur permettent de collecter, consolider, modliser et
restituer leurs donnes dans le but doffrir une aide la dcision et permettre aux responsables
de stratgie davoir une vue densemble sur les activits traites, OSS a jug important
dajouter une couche dcisionnelle sa solution.
Afin de fournir un produit au cot rduit et vu aussi les hautes performances de
certains outils libres de Business Intelligence, Optimis Report se combine entre lOpen Source
et le propritaire. La chaine BI propose par OSS utilise Talend Open Studio 4 pour la
conception des processus ETL, JasperReports pour la conception des rapports coupl
lditeur graphique iReport 5 ainsi quun module de reporting dans lERP Optimis dont
Annexe
Annexe
4 Annexe
5 Annexe
2
3
B : jAllInOne
C : MVC
D : Talend Open Studio
E : iReport
18
plusieurs fonctionnalits ne sont pas encore dveloppes.

Dans notre projet de fin dtudes nous sommes censs complter et enrichir cette
chane BI en dveloppant les lments manquants :
Optimis Report Share et Optimis Report Viewer.
2.2.Objectifs :
La finalit attendue de notre projet est davoir une plateforme BI gnrique qui peut
supporter lensemble des processus dcisionnels depuis lextraction des donnes de la base de
donnes de production jusqu la diffusion des rapports dactivit dans les boites mail des
responsables correspondants.
Pour se faire, nous devons suivre dabord lenchanement classique dun projet BI en
choisissant une activit donne assure par lERP Optimis (dans notre cas ventes &
paiements), relever des indicateurs et construire le DataMart correspondant.
Vu que le reporting constitue un lment important dans le projet en ce concerne la
mise en place doutils de visualisation et diffusion de rapports, il est dabord ncessaire
denchainer sur la dmarche BI jusqu conception et gnration de rapports via iReport. Ces
rapports constitueront lentre principale dOptimis Report Viewer, outil de visualisation des
rapports et dOptimis Report Share, outil de diffusion des rapports.
Nos objectifs se rsument alors concevoir et mettre en place un DataMart pour
lactivit des ventes, concevoir et gnrer des rapports dtat, concevoir et dvelopper les
fonctionnalits daccs et diffusion des rapports ncessaires au module de reporting.
Figure 1 .1 : Architecture fonctionnelle
19
2.3.Contraintes :
Nous dnombrons les diffrentes contraintes du projet :
Taille importante :
Vu dans sa globalit, le projet reprsente un volume intressant et par la suite une
bonne conduite du projet est fortement exige.
Plusieurs composantes entrelaces :
Le projet impose une transition entre une partie mene proprement en dmarche BI et
dont les rsultats doivent aider conduire une partie de dveloppement doutils avec
les mthodes qui correspondent. La transition doit tre galement bien gre.
Choix du cheminement suivre :
Par consquent des deux contraintes cites ci-dessus, il faut adopter une dmarche tout
au long du projet simple implmenter et qui permet de faire des itrations sans
causer des blocages au niveau organisationnel.
Complexit de la base de donnes :
Il sagit dune base de donnes dERP construite pour soutenir un accs performant,
les tables que nous devons crer et rajouter aux 166 tables existantes doivent alors
respecter les contraintes dintgrit de la base et conserver la persistance des donnes.
2.4.Dmarche :
Aprs multiples runions avec les responsables dOSS, dans le but de clarifier leurs
exigences en matire de ralisation de la plateforme BI requise, et suite aux recommandations
de notre encadrant, nous avons opt pour lune des mthodes Agiles pour la gestion de projet.
La mthode choisie pour mener le projet tant la mthode SCRUM, nous dfinissons
dabord la terminologie SCRUM que nous utiliserons :
Product Owner : reprsente le client et est responsable de la priorisation du backlog
Sprint Backlog : une liste des items de la plus haute priorit du backlog de produit.
Sprint : priode qui dure, en pratique, entre 2 et 4 semaines focalise sur l'effort de l'quipe
pour atteindre les buts fixs.
En projetant la mthodologie dfinie ci-dessus sur notre projet, les Product Owners
(PO) sont les responsables dOSS reprsents par MM. Agoudal et Benyahia.
Le projet peut tre dcoup selon les sprints suivants :
Sprint 1 : Etude prliminaire
Sprint 2 : Conception & cration dun datamart de ventes
Sprint 3 : Reporting
Sprint 4 : Dveloppement dOptimis Report Share et ajout de fonctionnalits au Viewer.
20
Figure 1.2 : Cycle de vie suivant SCRUM propos par TIMWI Consulting
2.5.Planning :
N du
sprint
0
Description
Backlog du sprint
Livrables
Priodes
Prliminaire
Planification
Etude de lexistant
Etude des besoins
Conception du DM
Choix des
indicateurs
Modlisation
Schma
conceptuel des
donnes
ETL
Dfinition des
sources de
donnes
Implmentation
ETL
Conception &
gnration des
rapports sous iReport
Consultation sur
Optimis Report Viewer
Conception
& cration du
DataMart
Reporting
Dossier dtude
prliminaire
Liste des indicateurs

recueillis
Schma de
conception du DM
Dossier des jobs
raliss sous TOS
Fichiers .jrxml et
.xml des rapports
Rapports format
PDF
Rapport de
problmes
dexcution
Du
06/02/2012
Au
17/02/2012
Du
13/02/2012
Au
29/02/2012
Du
01/03/2012
Au
16/03/2012
21
Ralisation
dO.R. Share
et ajout de
fonctionnalit
s O.R.
Viewer
Analyse de lexistant
au niveau de Viewer
Conception des
fonctionnalits
ajouter Viewer
Conception des
fonctionnalits
dvelopper dans Share
Ralisation
Dossier de
conception de la
solution
Nouveau schma
physique des
donnes
Maquettes des
interfaces
Code source
Du
19/02/2012
Au
25/05/2012
Tableau 1.1 : Planning du projet
Le tableau ci-dessus dcrit le planning que nous avons ralis et suivi afin de maitrise
notre travail. Il est illustr par le diagramme de Gant 6.
3. Conclusion :
Dans ce chapitre, nous avons prsent laspect organisationnel de notre projet ainsi
quun descriptif de lorganisme daccueil. Nous passons par la suite une prsentation des
notions et des techniques employes au niveau du projet.
Annexe F : Digramme de GANT
22
CHAPITRE II : NOTIONS ET TECHNIQUES :

Dans ce chapitre, nous allons prsenter les notions dinformatique dcisionnelle que
nous utilisons ; savoir larchitecture dcisionnelle, le processus ETL et le reporting. Les
outils engags au cours du projet sont spcifis.
1. Architecture dcisionnelle :
1.1.Business Intelligence :
Linformatique dcisionnelle (en anglais Business intelligence) est une discipline de
linformatique qui cible l'exploitation des donnes de l'entreprise afin de faciliter la prise de
dcision par les responsables, c'est--dire la comprhension du fonctionnement actuel et
l'anticipation des actions pour un pilotage clair de l'entreprise.
Les
outils
dcisionnels
sont
bass
sur
l'exploitation
d'un systme
d'information dcisionnel aliment grce l'extraction de donnes diverses partir des
donnes de production, d'informations concernant l'entreprise ou son entourage et de donnes
conomiques.
1.2.DataMart :
Le DataMart est un ensemble de donnes cibles, organises, regroupes et agrges
pour rpondre un besoin spcifique un mtier ou un domaine donn. Il est donc destin
tre interrog sur un panel de donnes restreint son domaine fonctionnel, selon des
paramtres qui auront t dfinis lavance lors de sa conception.
De faon plus technique, le DataMart peut tre considr de deux manires diffrentes,
attribues aux deux principaux thoriciens de linformatique dcisionnelle, Bill
Inmon et Ralph Kimball :
Dfinition d'Inmon : Le DataMart est issu dun flux de donnes provenant du

DataWarehouse. Contrairement ce dernier qui prsente le dtail des donnes pour toute
lentreprise, il a vocation prsenter la donne de manire spcialise, agrge et
regroupe fonctionnellement.
Dfinition de Kimball : Le DataMart est un sous-ensemble du DataWarehouse, constitu
de tables au niveau dtail et des niveaux plus agrgs, permettant de restituer tout le
spectre dune activit mtier. Lensemble des DataMarts de lentreprise constitue le
DataWarehouse.
Considrant le contexte auquel elle se rapporte, on peut privilgier suivant les

entreprises lune ou lautre de ces dfinitions.
Pour la modlisation des donnes et ladministration de la base de donnes, nous
utiliserons MySQL Workbench 7.
Annexe J : MySQL Workbench 5.2
23
1.3.Modlisation DataMart/DataWarehouse :
La conception et la modlisation de DataMart (et plus gnralement de
DataWarehouse) se ramnent dfinir deux concepts principaux : faits et dimensions. Cest la
mise en place de faits et de dimensions qui permet de dfinir le schma de modlisation que le
DM/DWH doit suivre :
1.3.1. Les faits :
Une table de faits est une table qui contient les donnes observables (les faits) que l'on
possde sur un sujet et que l'on veut tudier, selon divers axes d'analyse (les dimensions).
Les faits , dans un entrept de donnes, sont normalement numriques, puisque d'ordre
quantitatif. Il peut s'agir du montant en argent des ventes, du nombre d'units vendues d'un
produit, etc.
1.3.2. Les dimensions :
Une dimension est une table qui contient les axes d'analyse (les dimensions) selon
lesquels on veut tudier des donnes observables (les faits) qui, soumises une analyse
multidimensionnelle, donnent aux utilisateurs des renseignements ncessaires la prise de
dcision.
On appelle donc dimension un axe d'analyse. Il peut s'agir des clients ou des produits
d'une entreprise, d'une priode de temps comme un exercice financier, des activits menes
au sein d'une socit, etc.
1.3.3. Schma relationnel DM/DWH :
Schma en toile :
Dans ce schma, on associe chaque dimension une cl primaire non composite qui va
figurer aussi dans les tables de faits auxquelles est relie la dimension.
Figure 2.1 : Exemple de schma en toile
Schma en flocon :
24
Driv du schma en toile, ce schma permet de factoriser les dimensions afin de

rduire les redondances. Il permet galement la gestion des relations multi-niveaux. Nous
reprenons le mme exemple des ventes cit dans le paragraphe ci-dessus.
Figure 2.2: Exemple de schma en flocon

2. Extraction des donnes :
Les processus ETL (Extract-Transform-Load) permettent dextraire, transformer et
charger les donnes depuis des sources diverses et htrognes (Bases de donnes, fichiers
plats) jusquau DWH ou DM. Pralablement, lETL doit effectuer d-normalisation,
nettoyage et remplacement dans le contexte de ces donnes puis les charger. Les donnes
arrivant la structure cible (DWH ou DM) sont alors homognes.
Il sagit de ltape la plus importante dans un projet dcisionnel car cest son niveau
quon dtecte les anomalies et on effectue les calculs complexes.
Plusieurs outils dETL sont prsents sur le march, variant entre le libre et le payant.
Voici une liste des outils les plus demands :
-
Pentaho Data Integration (PDI)

SQL Server Integration Services (SSIS)
Talend Open Studio (TOS)
Dans notre projet, nous avons eu recours Talend Open Studio pour
25
3. Reporting :
Le reporting occupe le dernier maillon dans une chane de projet dcisionnel.
Il sagit de techniques informatiques permettant lextraction des donnes depuis un
DM/DWH et leur prsentation dans des rapports humainement lisibles et personnaliss selon
le got du lecteur.
Etant probablement l'application la plus utilise encore aujourd'hui de linformatique
dcisionnelle, le reporting permet aux gestionnaires :
de slectionner des donnes relatives telle priode, telle production, tel secteur de
clientle, etc.,
de trier, regrouper ou rpartir ces donnes selon les critres de leur choix,
de raliser divers calculs (totaux, moyennes, carts, comparatif d'une priode l'autre, ...),
de prsenter les rsultats dune manire synthtique ou dtaille, le plus souvent
graphique selon leurs besoins ou les attentes des dirigeants de lentreprise
Il existe des outils danalyse dcisionnelle qui permettent de modliser des

reprsentations base de requtes afin de constituer des rapports (ou tableaux de bords).
Parmi ces outils, nous citons les plus connus :
-
BIRT
Pentaho Reporting
iReport
iReport, dont le moteur de rapport est JasperReport, est le logiciel employ par
lentreprise pour la conception et la ralisation des diffrents rapports.
4. Conclusion :
Nous avons dfini dans ce chapitre les notions et les technologies employer dans
notre projet. Les lments non mentionns seront inclus dans lannexe. Nous exposons au
chapitre suivant notre conception et ralisation du DataMart.
26
CHAPITRE III : CONCEPTION ET REALISATION DE DATAMART DE VENTES :

Dans ce chapitre, nous prsentons les tapes dune partie importante du volet
dcisionnel de notre projet. il sagit de la conception et la ralisation dun DataMart pour
lactivit des ventes. Cette partie est dune telle importance car elle sert principalement
examiner la chane BI en cours de construction et obtenir, par la suite, grce aux techniques
de reporting des rapports dactivits qui vont servir dentre dans une partie ultrieure du
projet.
1. Choix des indicateurs :
Aprs avoir dtermin lactivit sur laquelle ltude dcisionnelle va porter, il faut
relever des indicateurs cls gnriques permettant dextraire des rapports sur ltat des ventes
dune entreprise.
Les responsables de la socit daccueil, et grce leur exprience dans le mtier du
conseil et dans le secteur des PME, ont rectifi et valid la liste dindicateurs relatifs aux
ventes et paiements que nous avons labor.
Les indicateurs choisis pour rpondre aux besoins prdfinis dans le secteur des ventes
sont les suivants :
Le chiffre daffaire ralis par lentreprise pour un client donn.

Le chiffre daffaire obtenu pendant une dure donne de lactivit.
Le chiffre daffaire ralis par lentreprise pour un article donn.
Total des paiements reus pour un client par rapport aux factures mises pour ce
dernier.
Total des paiements reus pour une priode donne par rapport au total des factures
mises.
2. Modlisation :
2.1.Dmarche suivie pour la modlisation :
Avant dentamer ltape de modlisation des donnes, nous avons commenc par
tudier le fonctionnement de lERP et notamment larchitecture de sa base de donnes.
Par la suite, nous avons procd la dfinition des donnes utiles ce qui nous a permis
de dfinir les sources de donnes destines lextraction pour cerner un ensemble de tables et
leurs colonnes et inspecter les relations entre elles.
Nous avons examin les indicateurs prcdemment relevs pour en dduire quatre axes
danalyse : temps, client, et facture que nous allons illustrer par des dimensions
correspondantes.
27
2.2.Dimensions recueillies :
-
Dimension date : sert localiser la date ou la priode pour laquelle il faut effectuer un
calcul. Elle est relie aux tables de faits ventes et paiements.
Dimension client : permet dextraire des informations relatives un client avec qui
lentreprise a effectu une opration de vente. Commune aux deux tables de faits.
Dimension article : reprsente les articles que lentreprise met en vente. Elle est relie
la table de fait des ventes.
Dimension facture : dcrit les factures que lentreprise met aux clients lors dune
opration de vente. Elle est relie uniquement la table de faits des paiements.
2.3.Choix du modle :
Nous avons d faire le choix parmi les modles suivants : en toile, en flocon (et en
constellation). Le modle choisi est le modle en toile car il est le plus simple et le plus
adquat au cas de notre DataMart pour les raisons suivantes :
Performance : dans ce modle, on na besoin que de peu de jointures dans une requte,
ce qui fournit par la suite une facilit dans la navigation.
Volumtrie : les tables sources que nous avons dfinies dans lERP ne sont pas trs
volumineuses.
Hirarchie : Il ny a aucune relation dhirarchie entre les tables de dimensions
prcdemment prsentes.
3. Schma conceptuel des donnes:
Le choix des indicateurs et la dduction des dimensions danalyse nous ont mens
laborer deux tables de fait. Ces tables de fait permettent dexprimer les diffrents indicateurs
que nous avons recueillis auparavant.
Ces tables de faits seront notes : FAIT_VENTE et FAIT_PAIEMENT.
4.1.FAIT_VENTE :
Cette table va fournir les donnes ncessaires aux calculs relatifs aux indicateurs de
chiffre daffaire.
28
Figure 3.1 : Schma conceptuel de la table FAIT_VENTE
4.2.FAIT_PAIEMENT :
Dans cette table, il y a les donnes relatives aux oprations de paiement. Relie
DIM_DATE, DIM_CLIENT, ses donnes permettent de calculer les indicateurs relatifs aux
soldes des clients.
29
Figure 3.2 : Schma conceptuel de la table FAIT_PAIEMENT
Ainsi, le schma global de notre DataMart est comme suit.
Figure 3.3: Schma conceptuel global du DataMart des ventes
4. Implmentation ETL :
Dans cet axe, nous allons dcrire les tapes de mise en uvre du systme dcisionnel
conu pour cette phase du projet, pour cela nous allons prsenter les composants utiliss dans
30
Talend Open Studio puis leur exploitation dans lalimentation du DataMart puis ltape de
mise jour de ce dernier une fois charg en donnes.
4.1.Composants Talend utiliss :
Limplmentation ETL consiste mettre en place ce quon appelle en nomenclature de
Talend des jobs permettant dextraire les donnes partir de leurs sources, deffectuer les
transformations ncessaires et de les charger dans le DataMart cible. Lhomognit des
donnes est importante afin de respecter les contraintes dintgrit de la structure cible.
Les composants que nous avons utiliss sont les suivants :
tMySQLInput : Ce composant (not graphiquement
) permet dindiquer les
tables sources de la base de donnes de production (test2) qui vont subir une extraction des
donnes.
Le tMysqlInput excute une requte en base de donnes selon un ordre strict qui doit
correspondre celui dfini dans le schma. La liste des champs rcupre est ensuite
transmise au composant suivant via une connexion de flux (Main row).
tMySQLOutput : Ce composant (reprsent graphiquement par
) permet de
dterminer les tables destination qui vont accueillir les donnes extraites et transformes
depuis la source.
Le tMysqlOutput excute laction dfinie sur la table et/ou sur les donnes dune
table, en fonction du flux entrant provenant du composant prcdent.
Des flches reliant les tables sources ou cibles, permettent dexprimer les flux de
transformations ou de chargement des donnes. Le traitement des bases de donnes MySQL
source et destination traites dans cette partie du projet seffectue via les deux composants
tMySQLInput et tMySQLOutput cits ci-dessus.
tMap : Llment tMap (dont la notation graphique est

) permet deffectuer
diffrentes jointures entre les divers composants des sources de donnes et mme des
transformations sur des flux. Il permet de choisir les donnes extraire en se connectant la
base de donnes de production, les transformer, les rendre homognes et les charger dans les
tables de destination.
4.2.Connexion la base de donnes :
Les tches effectues par Talend consistent principalement extraire des donnes
dune base de donnes sources, qui est dans notre cas Test2 et les transformer avant de les
charger dans la base de donnes destination Mydbtest .
31
Figure 3.4 : Paramtrage de la connexion la base de donnes source
Ainsi, tablir la connexion avec les deux bases de donnes en question est
indispensable afin de rcuprer le schma de la base de donnes Test2.
32
Figure 3.5 : Connexion avec la

contenant les donnes extraire
BD
source
et slection
des
tables
Une fois la connexion a t tablie, nous pouvons importer les tables de la base source,
slectionner celles ncessaires pour raliser la phase ETL et modifier titre dexemples leurs
schmas et types de donnes sil le faut.
Figure 3.6 : Connexion avec le DataMart MyDBtest et slection de

toutes les tables de dimensions et de faits alimenter.
4.3.Chargement des tables de dimensions :

Il y a quatre tables de dimensions charger depuis les tables slectionnes dans la base
de donnes source en exploitant les composants Talend prcdemment dfinis. Ces tables
sont : DIM_CLIENT, DIM_ARTICLE, DIM_FACTURE et DIM_DATE.
33
4.3.1. DIM_CLIENT :
Cette table sera alimente par les donnes contenues dans les deux tables
SAL07_CUSTOMERS et REG04_SUBJECTS. La premire, catgorise SALES (ventes),
contient les informations spcifiques uniquement aux clients savoir les identifiants, types,
modes de paiements etc. La deuxime, catgorise REGISTER (registre) sert dans la base de
donnes de lERP pour stocker les informations dtailles sur toute personne physique ou
moral en interaction avec lentreprise : (Nom, prnom/raison sociale, adresse, ge, etc.)
Figure 3.7 : Job DIM_CLIENT
4.3.2. DIM_ARTICLE :
Via un mapping grce au composant tMap, la table DIM_ARTICLE va puiser juste les
donnes ncessaires de la table ITM01_ITEMS rserve dans la base de donnes de lERP
aux informations relatives aux articles mis en vente ou autre.
Figure 3.8 : Job DIM_ARTICLE:
4.3.3. DIM_FACTURE :
Une facture est une sorte de document qui indique le tiers auquel on a vendu un article
avec des modalits de paiement donnes. La table DOC01_SELLING qui enregistre toutes les
donnes relatives aux oprations de vente reprsente la source des donnes utiles pour former
une dimension des factures.
Figure 3.9 : Job DIM_FACTURE
4.3.4. DIM_DATE :
Lalimentation des dimensions relatives au temps a pos un nombre de questions dans
les milieux de linformatique dcisionnelle. Les experts du domaine (nos remerciements aux
membres du forum www.labeldecisionnel.com) nous ont recommand de suivre une politique
34
de chargement part pour la table DIM_DATE en utilisant un script SQL qui permet de
charger un large intervalle de dates qui sincrmentent rgulirement.
4.4.Chargement des tables de faits :
4.4.1. FAIT_VENTE :
Nous rappelons que la table de faits FAIT_VENTE est celle qui permet de calculer les
indicateurs relatifs au chiffre daffaire et ses projections sur les clients, les articles et le temps.
Cest pour cela quelle sera alimente via quatre tables de la base de donnes de lERP :
DOC01_SELLING,
DOC02_SELLING_ITEMS,
SAL07_CUSTOMERS
et
REG04_SUBJECTS.
Figure 3.10 : Job FAIT_VENTE

4.4.2. FAIT_PAIEMENT :
Cette table doit contenir des donnes permettant de fournir des statistiques sur les
paiements quun client a effectus et par la suite on peut calculer ses soldes, fiabilit
Elle sera alimente via jointure avec PAY01_PAYMENT et SAL07_CUSTOMERS.
Figure 3.11: Job FAIT_PAIEMENT

5. Mise jour des donnes du DataMart :
Le rafrachissement priodique des donnes du DataMart est primordial. Plusieurs
mthodes de rafrachissement sont disponibles savoir lexcution manuelle des scripts de
jobs ou lutilisation des fonctionnalits garanties par lETL Talend Open Studio.
Il est possible de choisir laction appliquer sur les donnes entrantes aux tables de
destination parmi update or insert si les mises--jours sont juges plus volumineuses que
35
les insertions et insert or update en situation inverse. Dans notre cas de systme
dcisionnel de ventes, nous prvoyons un nombre dinsertions beaucoup plus suprieur celui
des mise--jours.
Talend Open Studio continent un programmeur de tches scheduler qui permet de
configurer le script de chargement. Dans le cas du rafrachissement des donnes de notre
DataMart, nous choisissons dordonnancer une mise--jour chaque jour minuit.
Figure 3.12: Scheduler de Talend Open Studio
6. Conclusion :
Nous avons prsent dans ce chapitre les tapes de ralisation du DataMart des ventes
depuis la modlisation et la conception jusqu lexcution des jobs gnrs par Talend Open
Studio pour mise jour. Maintenant que notre structure destination est oprationnelle, nous
pouvons lexploiter pour gnrer des rapports dtat employer dans une partie ultrieure du
projet.
36
CHAPITRE IV : PROCESSUS DE REPORTING :

Pour faciliter la tche aux responsables, un environnement de Reporting est
primordial. La conception et la ralisation de Optimis Viewer a t faite pour rpondre
cette fonction. Nous notons que les rsultats qui apparaissent dans les rapports sont des
donnes de test.
1. Gnralits :
Maintenant que le DataMart que nous avons cr est aliment avec toutes les
informations ncessaires llaboration des rapports et que le choix de loutil de reporting est
dj fait, il suffit dentamer le travail requis : la conception des rapports.
En fait, JasperReports, tant loutil de reporting en question, coupl avec lditeur
graphique iReport vont nous permettre de crer des rapports dont les rsultats pourraient tre
affich lcran, imprim ou stock dans des fichiers de diffrents format.
JasperReports est entirement dvelopp en Java et peut tre intgr dans une
gamme trs varie d'applications Java (y compris les applications J2EE). Son objectif
principal est de fournir un moyen simple et flexible pour la gnration de documents.
La cration de rapports avec JasperReports se droule gnralement en 4 tapes :
-
L'obtention d'un fichier modle XML ( l'aide de lditeur graphique iReport)

La construction du rapport partir du modle
Le remplissage des diffrents champs du rapport avec les donnes en provenance de
la base de donnes (comme elles peuvent provenir de dautres sources).
L'exportation du rsultat dans plusieurs formats possibles (PDF, HTML, XHTML,
EXCEL, document WORD, document CSV, PowerPoint ...).
L'exportation du rsultat dans plusieurs formats possibles (PDF, HTML,
XHTML, EXCEL, document WORD, document CSV, PowerPoint ...).
Figure 4 .1 : Etapes de cration dun rapport
37
Le fonctionnement de JasperReports est relativement simple. En effet, tous les

concepts tournent autour du langage Java. Une fois le modle XML (JasperDesign) compil,
il est charg dans un objet Java (JasperReport) qui peut lui-mme tre srialis et stock dans
un fichier (avec l'extension .jasper). Cet objet srialis est alors utilis lorsque l'application
dsire complter le rapport avec des donnes. En fait, la dfinition du rapport ncessite la
compilation de toutes les expressions Java dclares dans le modle XML. Le
rsultat obtenu aprs le processus de remplissage des champs est un nouvel objet Java
(JasperPrint) qui reprsente le document final. Celui-ci peut tre stock sur disque pour
un usage ultrieur (sous forme srialise et avec l'extension .jrprint), directement
imprim ou encore transform dans un format lisible (PDF, HTML, ...).
Figure 4.2 : Fonctionnement de JasperReports
2. Les rapports :
Les rapports rpondants aux indicateurs relevs au pralable sont comme suit :
-
La rpartition du chiffre daffaire ralis par lentreprise sur lensemble des clients
enregistrs.
La rpartition du chiffre daffaire ralis pendant une dure donne sur lensemble
des articles vendus.
Le total des paiements reus par rapport au total des factures mises pour un client
donn.
Bien sr avant dentamer la conception des rapports, il faut se connecter la source de

donnes, et ceci via un utilitaire trs intuitif quon dmarre depuis laccueil de iReport en
cliquant sur licne quaffiche la capture ci-dessous.
38
Figure 4.3 : Interface daccueil de iReport
iReport offre le choix entre plusieurs DRIVERS de connexion, une liste qui couvre la
majorit des sources de donnes courantes. Dans notre cas, nous devons choisir un driver
JDBC.
Figure 4.4 : Liste des drivers de connexions aux sources de donnes
39
Pour tablir la connexion, il est impratif de saisir les informations ncessaires la

connexion. Chose qui se fait moyennant linterface ci-dessous.
Figure 4.5 : Paramtrage de la connexion au DataMart
Avant de saisir la requte SQL et les paramtres correspondants, lutilitaire de cration

propose de choisir un Template parmi plusieurs choix pr-faits, sinon concevoir un Template
personnalis (ce qui fut notre cas afin dy ajouter les logos des entreprises concernes).
40
Figure 4.6 : Liste des Templates proposs par iReport
Le Template choisi, il est temps de saisir la requte SQL correspondante au rapport,

une requte qui dfinira les donnes qui vont garnir le rapport une fois son gabarit conu.
Figure 4.7 : Saisie de la requte SQL
41
Aprs avoir suivi les tapes, qui sont plus au moins similaires pour la conception de
nos trois rapports nous passons par la suite ce qui est spcifique chaque rapport.
2.1.Chiffre daffaire par client :
La requte SQL qui permet dafficher le chiffre daffaire rparti sur le total des clients
Dans ce rapport, nous dsirons prsenter lutilisateur final la rpartition du chiffre

daffaire (dans notre DM, reprsent par la sommation de total_ttc qui est la valeur tout taxe
compris dune opration de vente groupe par client). Ce champ figure dans la table de faits
FAIT_VENTE.
Les informations spcifiques au client savoir son identifiant et son nom (ou raison
sociale en cas dentreprise) sont extraits de la table de dimension DIM_CLIENT.
Dans ce rapport, nous avons prfr ne pas utiliser loption de paramtres offerte par
iReport parce quil est rapport uniquement de la part de tous les clients enregistrs dans le
chiffre daffaire ralis depuis le dbut des enregistrements.
42
Figure 4.8 : Rapport des chiffres daffaires par client
2.2.Chiffre daffaire par produit pendant une dure donne :

Ce rapport paramtrable, les paramtres entrer sont les dates de dbut et de fin de la
priode dans laquelle il faut calculer le chiffre daffaire total et sa rpartition sur les produits
(articles) vendus pendant cette priode.
Dans ce rapport, il y a utilisation de sous rapports (SubReports) pour laffichage du
graphe en camembert et laffichage lentte de la somme totale du chiffre daffaire.
La requte SQL entre est:
Voici un aperu du rapport gnr

(Rq : Nous utilisons la notation anglo-saxonne des dates en AAAA-MM-JJ vue que cest la
notation utilise dans le DM).
43
Figure 4.9 : Rapport des chiffres daffaires par produit pendant une dure
donne
2.3.Total des paiements reus par rapport au total des factures mises pour un client
donn :
Ce rapport prend en paramtre le nom (raison sociale) du client et prsente son

lecteur des calculs lis ses paiements et facturations savoir la balance qui est la diffrence
des sommes factures et des sommes payes et le ratio des mmes variables. Ces calculs
permettent lentreprise de dgager le profil du client trait, son aptitude payer et par la
suite sa fiabilit.
La requte SQL utilise est la suivante :
44
En saisissant la valeur de paramtre Raison Sociale : EMI, nous obtenons le rapport suivant :
Figure 4.10 : Rapport du total des paiements reus pour lensemble des
factures mises pour un client donn
3. Excution des rapports dans Optimis Report Viewer :

La compilation de rapports travaills dans iReport, dans sa version 4.5.0 gnre les
fichiers portant les extensions : .jrxml et .jasper. Aprs excution, le rapport se gnre
galement dans le format slectionn, dans ce cas, cest un fichier PDF.
Pour tester la capacit de la plateforme visualiser des rapports. Nous essayons
dexcuter les rapports crs dans Optimis.
Pour ce faire, nous transfrons les fichiers des rapports de la machine o ils sont
localiss au server via le client SFTP WinSCP afin de les charger dans la plateforme.
45
Figure 4.11 : Transfert des fichiers dans WinSCP
Nous chargeons le rapport dans Optimis et nous indiquons le paramtre nom_client du

rapport relatif aux factures et paiements :
Figure 4.12 : Chargement de rapport dans Optimis
Nous saisissons la valeur : EMI du paramtre nom_client pour visualiser ltat de

solvabilit du client EMI.
46
Figure 4.13 : Saisi de valeur de paramtre de rapport dans Optimis
A lexcution, un message derreur est signal. Aprs examen du code de la

fonctionnalit de visualisation et demande de renseignement auprs du forum dutilisateurs
dune version similaire de jAllInOne, nous constatons que les rapports dveloppes dans les
versions ultrieurs la 1.2.7 diReport ne sont pas compatibles avec loutil de visualisation au
niveau de la plateforme.
Nous avons remdi ce problme en recompilant les fichiers de rapports dans
iReport dans sa version 1.2.7. La recompilation gnre des fichiers .jasper excutables par
Viewer.
Pour une solution perptuelle, nous suggrons comme perspective dupgrader le noyau
dexcution de Viewer pour saligner avec les dernires versions diReport.
Conclusion :
Ce chapitre a trait du processus de Reporting. Ce dernier consiste principalement
concevoir, crer et publier les rapports sous le format voulu. Ainsi, il faut mettre ces
rapports sous la disposition des gens intresss et ceci via Optimis Viewer .
47
CHAPITRE V : CONCPETION ET REALISATION DOPTIMIS REPORT VIEWER

ET SHARE :
Nous dtaillons dans ce chapitre la dernire phase de notre projet. Cest la phase dans
laquelle nous agissons directement sur la plateforme Optimis Report en concevant et
dveloppant le module Reporting.
1. Mthodologie :
La focalisation sur une mthode agile pour mener ce sprint dcoule primordialement
du fait que nous avons adopt la mthode SCRUM, agile elle-mme, pour grer lensemble de
notre projet de fin dtudes. Cest pour cette raison, dabord, que nous avons dcid de ne pas
dvier de la logique agile adopte ds le dpart.
Avec la panoplie des mthodes agiles prsentes, nous avons d faire un choix
judicieux pour adopter la mthode la plus adapte la conduite du dit sprint. Pour cela, nous
nous sommes appuys sur des documentations de plusieurs mthodes ainsi que sur la nature
du projet mener dans cette priode pour cerner le choix entre les deux mthodes XP et
2TUP.
Notre exprience avec le cycle de dveloppement en Y adopt en Two Track Unified
Process a privilgi le choix de 2TUP face la mthode XP.
48
Figure 5.1 : Le cycle de dveloppement selon la mthode 2TUP
2. Analyse fonctionnelle :
2.1.Analyse et critique de lexistant :
Avant notre intervention, le module Reporting de lERP Optimis ne permettait que la
visualisation de rapports installs en disque dur.
La visualisation dans ce module est intgre dans le Viewer. Le noyau de ce dernier est la
bibliothque libre JasperReports.
Les rapports conus dans une version de iReport suprieure 1.2.7 ne sont pas
visualisables dans le Viewer du module Reporting.
49
Figure 5.2 : Interface dOptimis avec longlet du reporting ouvert
Ladministrateur charge les rapports et dfinit les paramtres de chacun avec des
valeurs par dfaut :
Figure 5.3: Interface de chargement des rapports dans Optimis
Le choix de la catgorie des rapports doit passer dabord par la prdfinition des
catgories dans longlet : Catgorie rapports :
50
Figure 5.4 : Liste des catgories des rapports
A laffectation des rapports une catgorie, cette dernire sajoute la barre des
onglets :
Figure 5.5 : Liste des rapports affects une catgorie
Nous sommes amens conclure que la plateforme ne permet que lexcution des
rapports. Le mcanisme de manipulation des rapports ninclut pas la gestion des droits
daccs, ainsi, lutilisateur excute les rapports existant dans la machine ce qui prive
lutilisateur dune manipulation simple et rduit la confidentialit des rapports.
51
2.2.Etude de la problmatique :
La plateforme est destine lusage des employs de PME dsirant bnficier de
rapports dactivit de diffrents secteurs, pour cela, il faut tendre le primtre fonctionnel de
la plateforme jusqu permettre chaque utilisateur de la plateforme daccder des
catgories de rapports donnes et les excuter sur le Viewer.
Le but du reporting est de bnficier les diffrents tiers dun organisme de rapports dtat.
Pour des raisons de confidentialit et dhirarchie, la plateforme ne peut pas tre accessible
tous les associs. Tenant compte de ces faits, nous avons propos un autre mode daccs aux
rapports : la diffusion en mailing lists.
2.3.Description des fonctionnalits principales :
Aprs runions avec les dcideurs, nous sommes parvenus relever les fonctionnalits
principales rajouter la plateforme. Ces fonctionnalits sont les suivants :
Gestion des accs aux utilisateurs : Ladministrateur doit dabord grer la liste des
comptes dutilisateurs quil cre et auxquels il dfinit des rles (profiles) prcis.
Pour des raisons de scurit mais aussi de besoin mtier de chaque utilisateur,
ladministrateur doit grer laccs des utilisateurs des catgories de rapports puis
des rapports eux-mmes.
Excution personnalise des rapports : Lutilisateur peut choisir et saisir les
paramtres selon lesquels il va excuter ses rapports et dfinir leurs formats (PDF,
HTML) pour quil puisse avoir exactement les informations dsires pour sa prise
de dcision.
Cration des listes de diffusion : Ladministrateur doit crer des listes de diffusion et
y ajouter des destinataires par saisi de leurs informations.
Gestion de la diffusion des rapports : Via cette fonctionnalit, OSS vise largir les
capacits de son produit jusqu lautomatisation de la diffusion des rapports sur leurs
bnficiaires.
Ladministrateur donne accs de certains rapports des listes de diffusion et selon le
besoin planifie les horaires denvoi.
3. Analyse technique :
Dans notre mise en uvre sur la plateforme, nous devons tenir compte des contraintes
techniques imposes par la partie prenante. Ceci pour respecter lhomognit de la solution
et permettre par la suite une facilit dintgration et maintenabilit.
Les tables crer pour accueillir les donnes utiles pour ces fonctionnalits doivent se
joindre la base de donnes Test2 de lERP, une base de donnes MySQL. Le modle
relationnel des donnes8 englobant les nouvelles tables explicite les liens entre elles et
quelques tables de la base de donnes Test2.
Annexe H : Modle relationnel de

donnes
8
52
Les dveloppements doivent se faire galement dans le cadre de larchitecture J2EE

avec le Framework Open swing 9.
4. Conception :
4.1.Identification des profils utilisateurs :
Deux profiles vont agir sur la plateforme :
Administrateur : cest la personne charge de la gestion du module et notamment la

gestion des accs.
Utilisateur : toute personne de lorganisme ayant un accs des fonctionnalits de
lERP. Plus spcifiquement les responsables.
4.2.Modlisation UML :
4.2.1. Diagramme des cas dutilisation :
Dans ce diagramme, nous prsentons tous les cas dutilisation du module de reporting,
certains cas reprsentent des fonctionnalits dj existantes comme le chargement et
lexcution des rapports.
Figure 5.6 : Diagramme des cas dutilisation du module de reporting
Annexe I : Open Swing
53
Seuls les cas dutilisation que nous mettrons en place seront dtaills :
Fiche de description dun cas dutilisation

Titre
Crer liste de diffusion
But
Cration des listes de diffusion qui vont contenir des destinataires de

rapports.
Version 1.2
Ladministrateur cre des listes de diffusion.
Administrateur
Version
Flux
principal
Acteurs
Description des enchainements

Scnario
nominal
1- Ladministrateur accde linterface des listes de diffusion

2- Ladministrateur saisit le nom de la liste et sa description
3- Le systme valide lajout.
Pr
condition
Post
condition
Frquence
Ladministrateur est identifi et authentifi
Liste de diffusion cre prte y ajouter destinataires.
A la demande
Tableau 5.1 : Fiche de description du cas dutilisation Crer liste de

diffusion

Titre
Ajouter destinataires une liste
But
Ajout de destinataires liste de diffusion de rapports
54
Version
Flux
principal
Version 1.2
Ladministrateur ajoute des destinataires une liste prcdemment

cre.
Administrateur
Acteurs

Scnario
nominal
1234-
Ladministrateur ouvre la rubrique dajout de destinataires

Ladministrateur slectionne une liste.
Ladministrateur saisit les informations sur un destinataire
Le systme valide lajout.
Pr
condition
Ladministrateur est identifi et authentifi

Liste prcdemment cre.
Post
condition
Liste de diffusion contient des destinataires.

Rapports peuvent tre autoriss.
Frquence
A la demande
Tableau 5.2 : Fiche de description du cas dutilisation Ajouter

destinataires une liste

Titre
Dfinir horaires denvoi une liste
But
Planifier les horaires dans lesquels les destinataires reoivent les

rapports.
Version
Version 1.2
Flux
principal
Ladministrateur dfinit la date de dbut et la frquence denvoi une

liste
55
Acteurs
Administrateur

Scnario
nominal
Pr
condition
Post
condition
Frquence
1234-
Ladministrateur ouvre la rubrique dautorisations de rapports aux listes

Ladministrateur slectionne un rapport
Ladministrateur saisit le calendrier denvoi.
Ladministrateur est identifi et authentifi.

Liste prcdemment cre.
Rapport prcdemment autoris une liste.
-
A la demande
Tableau 5.3 : Fiche de description du cas dutilisation Dfinir horaires

denvoi une liste

Titre
Autoriser un rapport un utilisateur
But
Affecter chaque utilisateur de la plateforme le rapport qui lui est

autoris.
Version
Version 1.2
Flux
principal
Ladministrateur dfinit les rapports accessibles un utilisateur dans

chaque catgorie.
56
Acteurs
Administrateur

Scnario
nominal
1234-
Ladministrateur ouvre la page des autorisations dun rapport.

Ladministrateur choisit longlet des utilisateurs
Ladministrateur saisit un nouvel utilisateur
Pr
condition
Post
condition
Frquence
- Lutilisateur peut excuter le rapport.
Ladministrateur est identifi et authentifi.

Rapport prcdemment charg
A la demande
Tableau 5.4 : Fiche de description du cas dutilisation Autoriser un

rapport un utilisateur

Titre
Consulter historique de paramtrages
But
Avoir une traabilit sur les valeurs de paramtres avec lesquelles un

utilisateur excute un rapport
Version
Version 1.2
Flux
principal
Ladministrateur ou lutilisateur veut consulter lhistorique des

paramtrages.
57
Acteurs
Administrateur
Utilisateur

Scnario
nominal
Pr
condition
Post
condition
Frquence
1234-
Lutilisateur ouvre la rubrique dhistoriques.

Le systme affiche les rapports autoriss et paramtrs
Lutilisateur slectionne un rapport.
Le systme affiche les valeurs de paramtres saisies par date.
Ladministrateur/lutilisateur est identifi et authentifi.

Rapport prcdemment charg
Rapport prcdemment autoris un utilisateur
-
A la demande
Tableau5.5 : Fiche de description du cas dutilisation Consulter

historique de paramtrages
58
4.2.2. Diagramme de classes:
Figure 5.7 : Diagramme de classes.
4.2.3. Diagrammes de squence :

Dans la notation UML, les diagrammes de squences sont la reprsentation graphique
des interactions entre les acteurs et le systme selon un ordre chronologique. Nous dtaillons
dans cette partie la description des besoins par la description textuelle des cas dutilisation.
Nous prsentons ci-dessous deux diagrammes de squence rassemblant une majorit des
fonctionnalits
Diagramme de squence : Autorisation de rapport utilisateur et excution.
59
Figure 5.8 : Diagramme de squence dautorisation de rapport et

excution
Diagramme de squence : Autorisation de rapport une liste et dfinition dhoraires de

diffusion et paramtres.
60
Figure 5.9 : Diagramme de squence dautorisation de rapport une liste,

dfinition dhoraires de diffusion et paramtres.
5. Ralisation :
Dans cette partie, nous allons prsenter quelques interfaces graphiques des
fonctionnalits que nous avons dveloppes en se basant sur la conception propose dans les
parties prcdentes.
Nous tenons noter que les nouvelles fonctionnalits doivent se conformer
l'architecture technique de la solution et respecter l'exigence d'interfaces graphiques de la
solution.
Toutes les nouvelles fonctionnalits sont groupes sous l'onglet "Rapports". Le nom
choisi pour dsigner le module Reporting par lentreprise.
5.1.Cration de listes de diffusion :
L'administrateur peut ajouter des listes de diffusion selon le besoin tout en saisissant le
nom de la liste et un descriptif pour spcifier la raison de diffusion aux destinataires de cette
liste.
61
Figure 5.10 : Interface de cration de listes de diffusion
5.2.Ajout de destinataires une liste :

L'administrateur slectionne d'abord une liste puis y insre des destinataires en
saisissant les informations suivantes: nom & prnom, description (raison d'envoi au
destinataire), e-mail.
Figure 5.11: Interface principale dajout de destinataires aux listes
62
Figure 5.12 : Interface de choix de liste de diffusion pour ajout.
Figure 5.13 : Interface daffectation dun des tinataire une liste.
5.3.Saisi de dtails de diffusion :

Ladministrateur saisit les paramtres dexcution du rapport et dfinit le calendrier de
son envoi la liste.
63
Figure 5.14 : Interface daffectation dun destina taire une liste.
Figure 5.15 : Interface de saisi dhoraire et paramtre denvoie dun

rapport.
64
CONCLUSION ET PERSPECTIVES :
Au terme de ce rapport, nous rappelons quil sagit dun projet de fin dtudes que
nous avons effectu au sein dOriginal Soft System pendant une dure de quatre mois. Notre
mission consistait tudier, concevoir et mettre en place la plateforme BI Optimis.
Notre projet se dcoupe en deux sections :
La premire suit lenchainement de projet dcisionnel. Elle est compose des parties
suivantes : analyse de lactivit des ventes pour relve des indicateurs cls de performance ; le
choix des axes danalyse et du modle ; la construction du schma du DataMart ;
lalimentation de ce dernier partir de la base de donnes de lERP Optimis via lETL Talend
Open Studio. Ensuite, la cration de rapports dtat partir des donnes du DataMart laide
de loutil de conception de rapports iReport.
Dans la deuxime partie du projet, nous tions amens enrichir la plateforme par
dveloppement du module de reporting. Pour ce faire, nous avons dcel les besoins en
matire de consultation et diffusion des rapports. Nous avons fait la conception des
fonctionnalits ajouter conformment aux spcifications UML. Dans la mise en uvre, le
framework Open Swing en suivant le pattern MVC.
Le projet nous a permis de cumuler des connaissances diverses dans les champs de
linformatique dcisionnelle, du dveloppement de modules en ERP. Nous avons eu
galement loccasion de pratiquer les mthodes agiles pour la gestion du projet et dacqurir
lexprience du travail collaboratif.
Dans le but de garantir une continuit souple au projet, il est important de proposer
certaines perspectives. Nous suggrons les points suivants :
-
Upgrade du noyau dexcution des rapports pour saligner avec les dernires versions
de JasperReports.
Utilisation de lordonnanceur dexcution des jobs ETL offert par Talend Open Studio
pour son efficacit.
Ajout des mcanismes denvoi des rapports un serveur FTP.
Ajout de la gestion de versioning des rapports (CVS).
65
WEBOGRAPHIE:
[1] Dossier sur linformatique dcisionnelle. Consult en mi fvrier 2012

http://www.commentcamarche.net/contents/entreprise/business-intelligence.php3
[2] Article de Wikipdia sur les datamarts. Consult en mi fvrier 2012
http://fr.wikipedia.org/wiki/Datamart/
[3] Article sur ladoption de la mthode SCRUM. Consult circa 07/02/2012.
http://www.cprime.com/community/articles/whentousescrum.html
[4] Cours sur la modlisation de datamarts. Visit le 25/02/2012
http://blog.developpez.com/jmalkovich/p8718/modelisation
[5] Forum ddi au BI Labeldecisionnel. Visit circa 01/03/2012
http://labeldecisionnel.com
[6] Tutoriel de JasperReports/iReport. Visit circa 14/03/2012
http://jpq.developpez.com/bi/tutoriels/jasperreports/initiation/
[7] Article sur la mthodologie 2TUP. Consult circa 05/04/2012
http://www.e-bancel.com/Processus_2TUP.php
[8] Portail de JAllInOne. Visit mi avril 2012.
http://jallinone.source.net
http://jaspersoft.com/JasperSoft_Products.htm
BIBLIOGRAPHIE:
[9] Talend Open Studio, Composants, Guide de rfrence. Edition 2010
[10] iReport 4.2.7 Ultimate User Guide, dition 2010
66
ANNEXES :
ERP :
ERP est lacronyme signifiant Enterprise Ressource Planning (en franais : Progiciel de
Gestion Intgr (PGI) mais ERP reste le terme le plus courant).
Cest un progiciel qui intgre les principales composantes fonctionnelles de
lentreprise : gestion de production, gestion commerciale, logistique, ressources humaines,
comptabilit, contrle de gestion
Le principe fondateur des ERP est de construire des applications informatiques pour
rpondre aux besoins fonctionnels cits ci-dessus tout en ayant recours la modularit. Ces
modules doivent tre indpendants entre eux mais partagent une base de donnes unique en
commun.
La dcision de mise en place dERP est avantageuse pour les considrations
suivantes :
Intgrit et unicit du SI : un ERP permet une logique et une ergonomie unique

travers sa BD, elle aussi unique au sens logique, c'est--dire, il peut exister plusieurs
bases de donnes physiques mais respectant la mme structure. En autres mots : un
ERP permet dviter les redondances dinformations entre diffrents systmes
dinformations de lentreprise.
Rcupration immdiate des donnes : lutilisateur peut rcuprer des donnes ou les
enregistrer de manire immdiate, les mises jour seffectuent en temps rel et se
rpercutent sur lensemble des modules concerns.
Multilingue et multidevise : les ERP taient en premier lieu destins lexploitation
dans les grandes entreprises et surtout les multinationales, do cette adaptation au
march mondial.
Pas dinterfaage entre les modules : les traitements sont synchroniss et les processus
de gestion sont optimiss. Egalement, les services informatiques de lentreprise ne
soccupent que de la maintenance volutive ( savoir, amliorer les rgles de gestion
etc.) laissant la maintenance corrective au soin de lditeur.
Etc.
Les ERP sont orients principalement aux grands organismes (surtout les
multinationales) du fait des cots considrables exigs par les diteurs majeurs : SAP, Oracle,
SAGE, Microsoft
Cependant, le march des ERP commence souvrir peu peu aux petites et
moyennes structures avec ldition de versions ddies aux PME mais aussi avec des ERP
Open Source qui cotent beaucoup moins cher en labsence de cot dacquisition de licence.
67
jAllInOne :
jAllInOne est une application oriente services ralise en java de type ERP/CRM avec un
front-end Swing.
Lapplication jAllInOne a t dveloppe en quelques mois grce aux outils Open
Swing, cest une plateforme de dveloppement qui permet de crer des RIAs (Rich Internet
Applications) avec des interfaces graphiques complexes en contenu mais qui ne ncessitent
pas un temps important pour le dveloppement.
Grce la quantit limite de bits transfrs sur internet - vu que seuls les blocs de
donnes circulent sans contenu de prsentation -, jAllInOne se caractrise par un bon temps
de rponse sur internet.
Le lancement de lapplication cliente se fait via Java Web Start utility (inclus dans la
distribution JRE). Juste la premire fois o jAllInOne est invoqu, lapplication cliente doit
tre tlcharge depuis le serveur : aprs le premier tlchargement, lapplication cliente
sinstalle dans la machine cliente. Java Web Start synchronise automatiquement lapplication
cliente lorsque des mises jour sont disponibles au niveau du serveur.
Le ct serveur peut tre lanc en utilisant Java Servlet qui ne ncessite pas un EJB
Container, pour cela, jAllinOne ct serveur peut sexcuter dans nimporte quel web
container (comme Tomcat, JBoss, Jetty) en utilisant nimporte quelle version de java
suprieure 1.4.
jAllInOne couvre la majorit des fonctionnalits dont une entreprise de petite ou
moyenne taille peut avoir besoin savoir : ventes, achats, gestion de production, gestion de
maintenance, gestion de personnel, CRM et gestion des activits etc.
Il faut noter aussi que jAllInOne est une application multiutilisateur, multi compagnie,
et multilingue (franais, anglais, italien, croate, allemand et russe).
68
Architecture globale de jAllInOne
69
MVC :
1. Architecture Modle/Vue/Contrleur
L'architecture Modle/Vue/Contrleur (MVC) est une faon d'organiser une

interface graphique d'un programme. Elle consiste distinguer trois entits
distinctes qui sont, le modle, la vue et le contrleurayant chacun un rle prcis
dans l'interface.
L'organisation globale d'une interface graphique est souvent dlicate. Bien que la
faon MVC d'organiser une interface ne soit pas la solution miracle, elle fournit
souvent une premire approche qui peut ensuite tre adapte. Elle offre aussi un
cadre pour structurer une application.
Dans l'architecture MVC, les rles des trois entits sont les suivants.
modle : donnes (accs et mise jour)

vue : interface utilisateur (entres et sorties)
contrleur : gestion des vnements et synchronisation
i. Rle du modle
Le modle contient les donnes manipules par le programme. Il assure la gestion

de ces donnes et garantit leur intgrit. Dans le cas typique d'une base de donnes,
c'est le modle qui la contient.
Le modle offre des mthodes pour mettre jour ces donnes (insertion
suppression, changement de valeur). Il offre aussi des mthodes pour rcuprer ses
donnes. Dans le cas de donnes importantes, le modle peut autoriser plusieurs
vues partielles des donnes. Si par exemple le programme manipule une base de
donnes pour les emplois du temps, le modle peut avoir des mthodes pour avoir,
tous les cours d'une salle, tous les cours d'une personnes ou tous les cours d'une
groupe de Td.
ii. Rle de la vue
La vue fait l'interface avec l'utilisateur. Sa premire tche est d'afficher les donnes
qu'elle a rcupres auprs du modle. Sa seconde tche est de recevoir tous les
actions de l'utilisateur (clic de souris, slection d'une entres, boutons, ). Ses
diffrents vnements sont envoys au contrleur.
La vue peut aussi donner plusieurs vues, partielles ou non, des mmes donnes. Par
exemple, l'application de conversion de bases a un entier comme unique donne.
Ce mme entier est affich de multiples faons (en texte dans diffrentes bases, bit
par bit avec des boutons cocher, avec des curseurs). La vue peut aussi offrir la
possibilit l'utilisateur de changer de vue.
70
iii. Rle du contrleur
Le contrleur est charg de la synchronisation du modle et de la vue. Il reoit tous

les vnements de l'utilisateur et enclenche les actions effectuer. Si une action
ncessite un changement des donnes, le contrleur demande la modification des
donnes au modle et ensuite avertit la vue que les donnes ont chang pour que
celle-ci se mette jour. Certains vnements de l'utilisateur ne concerne pas les
donnes mais la vue. Dans ce cas, le contrleur demande la vue de se modifier.
Dans le cas d'une base de donnes des emplois du temps. Une action de l'utilisateur
peut tre l'entre (saisie) d'un nouveau cours. Le contrleur ajoute ce cours au
modle et demande sa prise en compte par la vue. Une action de l'utilisateur peut
aussi tre de slectionner une nouvelle personne pour visualiser tous ses cours. Ceci
me modifie pas la base des cours mais ncessite simplement que la vue s'adapte et
offre l'utilisateur une vision des cours de cette personne.
Le contrleur est souvent scind en plusieurs parties dont chacune reoit les
vnements d'une partie des composants. En effet si un mme objet reoit les
vnements de tous les composants, il lui faut dterminer quelle est l'origine de
chaque vnement. Ce tri des vnements peut s'avrer fastidieuse et peut conduire
un code pas trs lgant (un norme switch). C'est pour viter ce problme que le
contrleur est rparti en plusieurs objets.
iv. Interactions
Les diffrentes interactions entre le modle, la vue et le contrleur sont rsumes

par le schma de la figure suivante.
Interactions entre le modle, la vue et le contrleur
71
2. Utilisation native en Swing
La plupart des composants Swing (sauf les conteneurs) utilisent une classe
spcifique pour contenir leurs donns.
Les boutons (JButton) utilisent un objet de classe ButtonModel pour les

donnes.
Les curseurs (JSlider) utilisent un objet de classe BoudedRangeModel pour les
donnes.
Les listes (JList) utilisent un objet de classe ListModel pour les donnes et
un objet de classe ListSelectionModel pour grer les slections.
Les arbres (JTree) utilisent un objet de classe TreeModel pour les donnes et
un objet de classe TreeSelectionModel pour grer les slections.
Les tables (JTable) utilisent des objets de
classe TableModel et TableColumnModel pour les donnes et un objet de
classe ListSelectionModel pour grer les slections.
Les composants de texte (JTextComponent et les classes
drives JEditorPane, JTextArea et JTextField) utilisent un objet de
classe Document pour grer le texte.
72
Talend Open Studio :
Talend Open Studio est dvelopp par Talend, une socit franaise (www .talend.com). La
premire version de Talend Open Studio a vu le jour au 2me semestre 2006, et la version
actuelle est la 5.0.2
Talend Open Studio est un ETL (Extract Transform Load) du type gnrateur de
code . Lors de chaque opration dintgration de donne, un code spcifique est gnr, soit
en Java ou en Perl selon le choix de lutilisateur. Les donnes traites et les traitements
effectus sont donc intimement lis.
Les traitements sur TOS se ralisent via une interface graphique, le Job Designer
(base sur Eclipse RCP) qui permet la cration des processus de manipulation de donnes.
De nombreux types d'tapes sont disponibles pour se connecter aux principaux SGBD
(Oracle, DB2, MS SQL Server, PostgreSQL, MySQL,...) ainsi que pour traiter tous les types
de fichiers plats (CSV, Excel, XML), aussi bien en lecture qu'en criture. Talend facilite la
construction des requtes dans les bases de donnes en dtectant le schma et les relations
entre tables. Un rfrentiel permet de stocker les mtadonnes afin de pouvoir les exploiter
dans diffrents jobs.
Le Job Designer intgre une Component Library : une palette graphique de
composants et connecteurs.
Les processus d'intgration sont construits simplement en dposant des composants et
connecteurs sur le diagramme, en dessinant leurs connexions et relations, et en modifiant leurs
proprits.
La plupart de ces proprits peut tre issue des mtadonnes dj dfinies.
La Component Library inclut plus de 80 composants et connecteurs, fournissant des
fonctions basiques telles que des associations, transformations, agrgations et recherches; des
fonctions spcialises comme le filtrage de donnes, le multiplexage de donnes...
Cette librairie supporte tous les principaux SGBDR, formats de fichiers, annuaires
LDAP...
La Component Library peut facilement tre complte en utilisant des langages
standards tels que Perl, Java ou SQL.
La conception trs visuelle des "jobs" permet de prsenter des statistiques d'excution
en temps rel ou encore de tracer les donnes transitant ligne ligne dans les composants de
la chane de traitement.
73
Quand un job d'intgration est lanc via le Job Designer (en mode graphique), il est
possible d'afficher les statistiques de traitement en temps rel, montrant le nombre de lignes
traites et rejetes, ainsi que la vitesse d'excution (lignes par secondes). On peut ainsi reprer
immdiatement les goulots d'tranglement.
Il est aussi possible d'activer un mode de traage, qui affiche pour chaque ligne le
comportement adopt et montre le rsultat des transformations. Les fonctionnalits de
dbogage traditionnelles sont videmment disponibles.
L'enrichissement des traitements par ajout de code spcifique :
La totalit du code gnr par Talend Open Studio, quel que soit le langage cible, est
toujours visible et accessible depuis l'environnement de conception.
On peut bien sr implmenter des spcificits mtiers propres aux donnes traites,
ceci en ajoutant de nouvelles routines .
74
iReport/JasperReport :
JasperReports est un moteur de rapport dvelopp par la socit JasperSoft et distribu sous
une licence open source. iReport est l'diteur de rapport de JasperSoft. Ces outils, fortement
demands dans les mtiers de reporting, existent au march depuis 2001.
Dans notre projet, nous utilisons JasperReports et iReport dans leur version 4.5.0,
sortie en dcembre 2011.
Les rapports gnrs sont des fichiers XML et peuvent galement tre crs et
modifis manuellement.
1. Gnrateur de rapport :
Le moteur JasperReports permet la gnration de rapports au format PDF, HTML,
XML, CSV, RTF, XLS et TXT. Il utilise JFreeChart pour gnrer les graphiques et peut tre
intgr dans toute application dveloppe avec le langage Java.
Il supporte, en plus des bases de donnes classiques, les serveurs danalyse
multidimensionnelle ce qui permet dexploiter les possibilits du serveur Mondrian
directement dans un rapport JasperReports.
2. Conception des rapports :
La conception des tats se fait soit par description XML soit par outil graphique (iReport).
Cest cette dernire option quon a souvent recours grce son ergonomie.
Les rapports sont dcomposs en bandes dans lesquelles les lments graphiques sont
dposs. Chaque bande a un comportement spcifique et apparat une ou plusieurs fois.
Un rapport excute une itration sur un jeu de donnes principal. Certaines bandes
sont affiches avant ou aprs lensemble des donnes de ltat, dautres le sont une fois pour
chaque lment du jeu de donnes.
Les diffrentes bandes disponibles sont :
titre du rapport, affich au dbut de la premire page.
entte de la page, affiche au dbut de chaque page.
en-tte des colonnes, affiches avant les donnes.
dtails, rpts pour chaque lment des donnes.

75
fin des colonnes, affiche aprs lensemble des donnes.
pied de page, affiche en bas de chaque page.
dernire page, affiche dans la dernire page.
page de rsum, conclut le rapport.
Pour crer des rapports plus riches, il est possible dutiliser des jeux de donnes
secondaires dans certains lments, comme les graphiques et les tableaux, ou dinsrer des
tats secondaires.
3. Interface graphique : iReport :
Plusieurs diteurs graphiques taient associs JasperReports comme Jasper Assistant
et JasperPal, mais depuis que JasperSoft a mis iReport, ce dernier a domin tous les autres
outils.
iReport est donc l'outil de conception dtats officiel de JasperReports et se prsente
sous la forme d'une application Java ddie.
Il supporte la quasi-totalit des fonctionnalits de JasperReports (tableaux, tableaux
croiss, graphiques) et dispose galement d'une extension ddie l'administration de la plateforme dcisionnelle de JasperSoft.
L'interface et le mode de fonctionnement des rapports JasperReports destinent
principalement iReport des spcialistes.
76
Interface diReport
77
Diagramme de GANT :
78
MySQL Workbench :
MySQL Workbench est outil visuel unifi pour architectes, dveloppeurs et

administrateurs de base de donnes. MySQL Workbench fournit la modlisation des donnes,
le dveloppement SQL et des outils d'administration complets pour la configuration des
serveurs, l'administration des utilisateurs et davantage. MySQL Workbench est disponible
sous Windows, Linux et Mac OS.
MySQL Workbench permet un administrateur de base de donnes, un dveloppeur
ou un architecte de donnes de concevoir, de modliser, de gnrer et de grer visuellement
des bases de donnes. Il comprend tous les lments ncessaires un modlisateur de donnes
pour crer des modles entit-relation complexes et procder une pro-ingnierie ou une
rtro-ingnierie. Il offre galement des fonctionnalits cls qui permettent d'accomplir les
tches dlicates de gestion des modifications et de documentation, qui exigent habituellement
beaucoup de temps et d'efforts.
79
Modle relationnel de donnes :
Les tables dont la nomenclature se prcde par REP sont rserves au reporting .
Les 4 premires tables REP01_DOCUMENT, REP02_DOC_PROPERTIES,
REP03_DOC_PROP_VALUE, REP04_CATEGORY existaient prcdemment dans la base
de donnes. Elles servent au stockage des informations relatives uniquement aux rapports,
leurs paramtres et valeurs par dfaut et catgories.
80
Le tableau suivant prsente les tables que nous avons ajoutes et lutilit de chacune.
Table
Utilit
REP05_LISTE_DIFFUSION
REP06_AFF_USER_RAPPORT
REP07_AFF_DESTINATAIRE
Informations relatives aux listes de diffusion

Accs des utilisateurs aux rapports
Informations relatives aux destinataires ajouts aux
listes.
Enregistrement des autorisations des rapports des
listes de diffusion.
Enregistrement des valeurs de paramtres saisies par
ladministration avant diffusion dun rapport
Enregistrement des dates de dbut et fin et frquence
denvoi de rapports aux destinataires dune liste
Historique des saisies de paramtres faites par les
utilisateurs pour excution des rapports.
REP08_AFF_LISTE_RAPPORT
REP09_PARAM_SHARE
REP10_HORAIRE_DIFF
REP12_PARAM_VIEWER
81
Open Swing :
Open Swing est le Framework open source de composants graphiques bass sur Swing
et une plateforme pour dveloppement dapplications client/serveur deux ou trois tiers ; Il
permet de dvelopper des RIAs (Rich Internet Applications) bases sur le protocole http et un
front-end Swing. La cration des interfaces graphiques utilise le designer dinterfaces de
lIDE java adopt : Eclipse, NetBeans, JDeveloper ou JBuilder et mme des IDE non-java
(JB, Delphi, Visual Studio .NET). Plusieurs technologies et mcanismes sont utiliss dans
Open Swing comme POJO, MVC, data binding
Il peut tre facilement intgr dans plusieurs couches serveur comme Spring,
Hibernate, iBatis, JPA.
82

Etude, Conpception Et Refonte D'une Plateforme

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Etude, Conpception Et Refonte D'une Plateforme

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSITE MOHAMMED V AGDAL

ECOLE MOHAMMADIA DINGENIEURS

Filire : Gnie Informatique

Mmoire de Projet de Fin dEtudes