Projet de Fin d’Études pour l’obtention du titre d’Ingénieur d’Etat en Génie Informatique Réalisation d’une solution de Reporting invocable via des services Web pour une application de questionnaire en ligne Réalisé par : Fayçal TIRICH

1. eQ Services
Projet de Fin d’Études
pour l’obtention du titre d’Ingénieur d’Etat en Génie
Informatique
Réalisation d’une solution de
Reporting invocable via des
services Web pour une
application de questionnaire
en ligne
Réalisé par : Fayçal TIRICH
Distribution
Nom Organisation / Poste
Florent BOUQUEROD HyperObjects: directeur général
Pascal LIEBART HyperObjects: Responsable e-Questionnaire
Brahim ER RAHA ENSA Agadir: Encadrant

2. eQ Services
I. Dédicace
À mes chers parents qui m’ont soutenu tout au long de mes études ainsi que dans ma vie
entière, pour les sacrifices qu'ils ne cessent de m’offrir, je vous dédie ce travail avec tout le
respect que je vous garderai.
À mes chers sœurs et frères, à toute ma famille et à tous mes amis.
À mes formateurs et à mes encadrants.

3. eQ Services
II. Remerciements
Le travail présenté dans ce mémoire a été effectué pour le compte de la SSII française
HyperObjects. J’aime donc exprimer ma reconnaissance à tous ceux qui ont contribué à la
réalisation de ce projet et plus particulièrement à Monsieur Florent BOUQUEROD pour
l’encadrement architectural, Monsieur Pascal LIEBART pour le suivi fonctionnel de mon travail
et Mademoiselle Marine FLORET pour l’intégration technique. Je tiens à féliciter leur
disponibilité durant toute la période de mon stage et aussi leur sympathie qui a permis de
créer un environnement de travail plus détendus.
J’adresse aussi mes remerciements au corps professoral de l’ENSA et spécialement mon
encadrant Monsieur Brahim ER RAHA ainsi que tout le staff administratif.
Enfin un clin d’oeil à tous les élèves ingénieurs de ma promotion, ainsi que toute personne qui
a contribué de près ou de loin à l’élaboration de ce travail.

4. eQ Services
III. Table des matières
I. Dédicace
II. Remerciements
III. Table des matières
IV. Liste des figures et des tableaux
V. Introduction 1
VI. Sujet de stage 3
A. Situation .......................................................................................... 3
B. Objectifs........................................................................................... 3
C. Tâches à réaliser ............................................................................... 3
D. Qualités requises ............................................................................... 4
E. Coachs ............................................................................................. 4
VII. Analyse de l’existant 5
A. Organisation ..................................................................................... 5
B. Présentation du e-Questionnaire v 4.5 .................................................. 6
C. Caractéristiques logicielles et matérielles............................................... 6
D. Limitations et perspectives .................................................................. 7
E. Planning prévisionnel.......................................................................... 8
VIII. Méthodologies de travail 9
1. Introduction ............................................................................... 9
2. Découverte de l'eXtreme Programming .......................................... 9
3. eXtreme Programming en détails ................................................ 11
a) La naissance ................................................................................ 11
b) XP face aux méthodes traditionnelles............................................... 11
c) Le cycle de développement............................................................. 11
d) Les valeurs du XP ......................................................................... 12
e) Les pratiques du XP....................................................................... 12
4. Conclusion ............................................................................... 13
IX. eQ Charting Services 14
A. Introduction .................................................................................... 14
B. User Stories .................................................................................... 14
C. Architecture .................................................................................... 15
1. Architecture générale ................................................................ 15
2. eQ Générateur Dynamique des Diagrammes ................................. 15
a) XmlDocument Provider .................................................................. 15
b) XmlToDataView Mapper ................................................................. 16
c) eQDDG Engine.............................................................................. 20
d) eQ Parameters ............................................................................. 25
e) Conclusion ................................................................................... 26
3. Partie Services Web .................................................................. 26
a) Introduction ................................................................................. 26
b) Caractéristiques d’un service Web ................................................... 27
c) Services Web : Le cas eQ ............................................................... 28
d) Service Oriented Architecture ......................................................... 28

5. eQ Services
e) Web Services Description Language................................................. 29
f) Simple Object Access Protocol ......................................................... 31
g) Les services Web sous le framwork .NET 2.0..................................... 33
h) Utilisation des services Web avec ASP.............................................. 34
D. Conclusion générale ......................................................................... 35
X. eQ Reporting Services 41
A. Introduction .................................................................................... 41
B. La génération des rapports dans eQ 4.5 .............................................. 41
C. Objectifs......................................................................................... 41
D. Enjeux du module eQ Reporting Services ............................................ 42
E. Étude des outils existants ................................................................. 42
1. Business Objects Crystal Report XI.............................................. 42
a) Introduction ................................................................................. 42
b) Fonctionnalités ............................................................................. 42
c) Architecture ................................................................................. 43
d) Création des rapports .................................................................... 43
2. SQL Server 2005 Reporting Services ........................................... 44
a) Introduction ................................................................................. 44
b) Fonctionnalités ............................................................................. 44
c) Architecture ................................................................................. 44
d) Création des rapports .................................................................... 45
3. Conclusion ............................................................................... 46
F. Solution adoptée.............................................................................. 48
1. Introduction ............................................................................. 48
2. Architecture ............................................................................. 48
3. Explications ............................................................................. 49
4. Conclusion ............................................................................... 52
XI. Perspectives 53
XII. Conclusion générale 55
XIII. Références 56
A. Méthodologie .................................................................................. 56
B. POO, .NET et Infragistics................................................................... 56
C. XML ............................................................................................... 56
D. Services Web .................................................................................. 56
XIV. Annexe 57
A. Microsoft .NET Framework................................................................. 57
1. Introduction ............................................................................. 57
2. Base Class Library .................................................................... 57
3. Le CLR et MSIL......................................................................... 57
4. ASP.NET .................................................................................. 58
B. Le modèle objet du eQ Charting Services ............................................ 59
1. Le module XmlDocument Provider ............................................... 59
2. Le module Xml To DataView Mapper ............................................ 60
3. La Classe eQ Web Service .......................................................... 60
4. Le moteur eQGDD Engine .......................................................... 61
5. Les classes de base du eQGDD Engine ......................................... 62

6. eQ Services
IV. Liste des figures et des tableaux
Figure 1 : Démarche non agile de gestion de projets ............................................................... 9
Figure 2 : Démarche agile de gestion de projets ................................................................... 10
Figure 3 : Cycle de vie du XP ............................................................................................. 11
Figure 4 : Architecture générale du eQ Charting Services ....................................................... 15
Figure 5 : Organigramme du module XML to DataView Mapper ............................................... 17
Figure 6 : Arrangement d’un XML d’une question simple ........................................................ 18
Figure 7 : Arrangement d’un XML d’une question groupée pondérée ........................................ 19
Figure 8 : Arrangement d’un XML d’une question groupée non pondérée .................................. 19
Figure 9 : Programmation classique .................................................................................... 20
Figure 10 : Programmation agile ........................................................................................ 21
Figure 11 : Modèle objet du eQGDD Engine.......................................................................... 23
Figure 12 : Aperçu sur l’utilisation de l’abstraction ................................................................ 24
Figure 13 : Aperçu sur un fragment du fichier de paramétrage................................................ 26
Figure 14 : Les services offerts par eQ Charting Services ....................................................... 29
Figure 15 : WSDL en action ............................................................................................... 30
Figure 16 : Aperçu sur le fichier WSDL du eQ Charting Services .............................................. 31
Figure 17 : L’assistant visuelle du Web Developer basé sur le WSDL ........................................ 31
Figure 18 : Exemple d’une demande SOAP de la méthode GetChartStream() ............................ 32
Figure 19 : Réponse positive du service Web via la balise <GetChartStreamResult> .................. 32
Figure 20 : Réponse négative du service Web via la balise <soap:Fault>.................................. 33
Figure 21 : Déclaration d’un service Web sous .NET .............................................................. 33
Figure 22 : Consommation bas niveau d’un service Web depuis ASP ........................................ 34
Figure 23 : Consommation d’un service Web en utilisant MS SOAP ToolKit pour ASP .................. 35
Figure 24 : Procédure du sauvegarde physique de l’image du diagramme................................. 35
Figure 25 : L’ancienne version de la partie analyse du eQ ...................................................... 36
Figure 26 : Les nouveaux paramètres des diagrammes offerts au client ................................... 37
Figure 27 : Résultat du service Web .................................................................................... 38
Figure 28 : Architecture d’une solution de Reporting avec Crystal Report.................................. 43
Figure 29 : Architecture d’une solution de Reporting avec Reporting Services............................ 45
Figure 30 : Architecture du eQ Reporting Services ................................................................ 48
Figure 31 : Les services offerts de génération de PDF ............................................................ 49
Figure 32 : Invocation du service Web eQ Reporting depuis ASP ............................................. 50
Figure 33 : Exemple de génération complexe des rapports PDF ............................................... 51
Figure 34 : Aperçu sur les nouveaux diagrammes de eQ Charting Services v2........................... 54
Figure 35 : Exemple de diagramme financier visé dans la deuxième version du eQ .................... 54
Figure 36 : Architecture du Framework .NET ........................................................................ 57
Figure 37 : le Common Language Runtime........................................................................... 58
Figure 38 : La classe XmlDocumentProvider ......................................................................... 59
Figure 39 : La classe QuestionInfo ...................................................................................... 60
Figure 40 : La classe WebService eQ................................................................................... 60
Figure 41 : La classe eQGDD.............................................................................................. 61
Figure 42 : Le modèle objet du eQGDD Engine ..................................................................... 62
Figure 43 : Exemple d’abstraction et d’héritage du eQGDD..................................................... 63
Tableau 1 : Caractéristiques matérielles et logicielles du eQ v4.5 .............................................. 7
Tableau 2 : Planning prévisionnel ......................................................................................... 8
Tableau 3 : Exemple de diagrammes générés....................................................................... 40
Tableau 4 : Synthèse comparative de Crystal Report et Reporting Services............................... 47
Tableau 5 : Convention de la notation POO utilisée ............................................................... 59

7. eQ Services
V. Introduction
Après la centralisation de l’information en ligne et le phénomène du commerce électronique, c’est à
présent le tour de l’ère des applications Web de marquer un nouveau tournement radical dans la
manière d’aborder et de gérer le côté informatique des secteurs économiques.
Ces nouveaux services loués par des entreprises appelées Fournisseur d’Applications Hébergées
(FAH) - ou Application Server Provider (ASP) en anglais - sont capables de proposer des outils à
forte valeur ajoutée aussi bien pour les PME que pour les grandes structures.
Cette manipulation s’inscrit dans le cadre de ce qui est couramment connu par l’externalisation ou
l’outsourcing ; C’est un processus par lequel une entreprise confie à un prestataire extérieur la
responsabilité de la gestion d'un domaine (ou d'une fonction) qu'elle-même peut assumer
directement en interne au moyen d'une combinaison spécifique de ressources propres.
Le FAH ne se limite pas à la seule mise à disposition d'un logiciel. En effet, le prestataire FAH
héberge et gère le logiciel et ses différentes versions, effectue les opérations de maintenance
classique, applique les mises à jour éditeur et, de façon plus générale, effectue toutes les tâches
déléguées normalement à la direction des services informatiques de l’entreprise cliente.
Afin d'apporter une solution aux sociétés qui ne disposent pas de structures informatiques et de
compétences internes suffisantes, le FAH a été développé au départ à destination des PME.
Cependant, vu tout l'avantage économique dégagé par cette démarche, ses fournisseurs ont plutôt
été aussi contactés par des grands groupes, et leurs clientèles ne se limitent plus aux simples
entreprises ou associations mais incluent aussi des grandes organisations privées et
gouvernementales.
Réduire les coûts, contrôler les dépenses, diminuer le délai du début d’exploitation, bénéficier du
savoir faire des FAH, éviter le piratage et l’utilisation illégale des produits, mieux connaître et tracer
la clientèle… Il faut dire que les attributions des FAH ne sont plus à démontrer.
www.e-questionnaire.com en est une belle démonstration : Ce service peut être loué et utilisé
directement par des managers et des responsables ne disposant pas forcément de compétences
informatiques avancées, évitant donc aux entreprises de réaliser eux-mêmes des applications pour
leurs questionnaires voire pire opter pour une démarche non informatisée.
Que se soit une compagne marketing, une étude de marché, un audit interne ou tout simplement
une enquête de satisfaction, cette application s’avère très flexible en s’adaptant à un grand nombre
d’applications surtout qu’elle nécessite pas d’installation mais tout simplement une connexion
Internet et un navigateur Web.
1

8. eQ Services
De la création personnalisée des questions à l’analyse avancée des résultats en passant par la
diffusion et le suivi de la population interrogée, e-Questionnaire est une solution compacte,
autonome et performante et surtout un choix stratégique et économique vu les tarifs compétitifs
non comparables aux charges potentielles (logicielles, matérielles et humaines) que l’entreprise
allait supporter si elle avait adopté un développement interne de toutes pièces.
Mon projet consiste à améliorer certaines fonctionnalités de cette solution de questionnaire en
ligne, l'évolution de ce projet s'est poursuivie sur la lignée d’un cahier de charges qu’a dû aussi
connaître des améliorations fréquentes. Cela a donné naissance à plusieurs éléments reliés mais
autonomes en même temps. Afin d'éviter un discours incohérent, la suite de ce rapport suivra la
structure des différents modules qui composent le projet final.
Je discuterai d'abord globalement de la version actuelle de e-Questionnaire, les buts attendus de
mon PFE et la méthodologie de travail que j'ai employée.
Suivra ensuite une section pour chacun des éléments importants du projet. Chacune de ces
sections contiendra une description plus ou moins détaillée de la problématique à résoudre, de la
méthodologie employée, de l’architecture adoptée et d’un aperçu sur le résultat final.
Finalement je conclurai par un bilan global des résultats de ce projet ainsi que de ses suites et
perspectives futures.
2

9. eQ Services
VI. Sujet de stage
Le sujet initial du stage a été décrit de la manière suivante : Adjonction de nouveaux modules à eQ
v4.5.
A. Situation
HyperObjects a développé et anime le service en ligne e-Questionnaire qui permet à ses clients de
créer, de diffuser et d’analyser leurs propres enquêtes en toute autonomie. Ce service de gestion
d’enquêtes en ligne est commercialisé en mode ASP (Application Service Provider).
La version actuelle d’e-Questionnaire (v4.5) a été développée en ASP 3.0 et continue à grandir tous
les jours en fonctionnalités. HyperObjects souhaite aujourd’hui faire évoluer son application vers
des technologies plus récentes permettant de gagner en productivité sur tous ses développements
spécifiques.
Cependant, le développement d’une révision majeure de l’application est très délicat à l’heure
actuelle. HyperObjects souhaite donc privilégier le développement de modules fonctionnels et
autonomes sous forme de Web services invocables depuis la version actuelle d’e-Questionnaire.
B. Objectifs
Les principaux modules à développer sont :
• Service Web dédié à la génération de diagrammes
• Service Web dédié à la génération de rapports (à cette occasion une investigation sera à faire
sur SQL Server 2005 avec Analysis And Reporting Services et Business Objects Crystal Report
Server)
C’est donc aussi l’occasion de passer sur des technologies plus récentes comme :
• SQL Server 2005 avec Analysis And Reporting Services ou bien Business Objects Crystal Report
Server
• ASP.NET 2.0
• Composants Infragistics.
Des difficultés d’intégration sont à prévoir (ces services devront être invoqués depuis un
environnement non .NET).
C. Tâches à réaliser
• Se familiariser avec les outils mis en oeuvre (SQL Server, Visual Studio 2005, Business Objects
Crystal Report Server et composants .NET)
3

10. eQ Services
• Créer des modules en C# et ASP.NET 2.0 et des démonstrations de clients ASP consommateurs
en respectant les spécifications de construction délivrées par mon coach.
• Concevoir des architectures en services Web.
• Dialoguer efficacement avec mon coach à travers les différents outils mis à ma disposition
(Email, VOIP, IM…).
• Livrer du code robuste, testé et documenté
• Rédiger de la documentation en Français.
D. Qualités requises
• Indépendance, relation « client - fournisseur » avec l’équipe de développement de Grenoble
• Esprit d’initiative, démarche expérimentale, force de proposition.
E. Coachs
• Pascal LIEBART (fonctionnel)
• Florent BOUQUEROD (technique)
• Marine FLORET (intégration).
4

11. eQ Services
VII. Analyse de l’existant
A. Organisation
HyperObjects est une SSII (Société de Services en Ingénierie Informatique) de petite taille,
spécialisée dans les technologies Windows/Web. Fondée en 1996 à l’initiative de Florent
BOUQUEROD, diplômé de l’École Centrale de Paris et de Pascal DUBESSET, diplômé de l’ESC
Grenoble, celle-ci est située dans le quartier St-Bruno de Grenoble. Ils ont été rejoints en 1999 par
Philippe GRAÇA, diplômé de l’INSA de Lyon et l’actuel directeur technique.
Trois métiers sont au cœur de leurs activités:
• SSII spécialisée en systèmes d’information marketing
• Editeur de solutions
• Fournisseur d’Application Internet
Grandement insufflées par les fondateurs d’HyperObjects, les valeurs clés de l’entreprise reposent
sur trois piliers que sont le professionnalisme, la productivité et la pro activité. Ceux-ci sont
omniprésents au sein de l’entreprise dans le travail effectué et se confirment d’année en année.
Par son professionnalisme et par la réactivité de ses équipes de développement, HyperObjects a
réussi à lier très rapidement des liens commerciaux forts avec de grands noms de l’industrie et de
l’administration tels que Hewlett Packard, Schneider, Ricoh, ainsi que le Ministère de l’Equipement,
des Transports et du Logement.
En ce qui concerne les forces de la société, il apparaît clairement que la spécialisation de niche sur
le marché des systèmes d’informations marketing est un pilier pour son développement. De plus, le
fait de travailler avec de gros clients, comme HP, est un atout indéniable auprès de ses prospects.
En revanche, sa forte dépendance à HP, qui représente la majorité de son chiffre d’affaire, se
révèle être une de ses faiblesses principales. L’entreprise essaie aujourd’hui de s’affranchir en
devenant un éditeur de logiciel d’un produit de gestion de catalogue électronique.
Au niveau de la vitalité de l’entreprise, HyperObjects a été retenu pour sa forte croissance ses
dernières années (+228% de CA en 5 ans) lors de l'édition 2004 du Deloitte Technology Fast 50 qui
a réuni 259 entreprises. Le Fast 50 est devenu l’indicateur de référence du succès pour les
entreprises technologiques de croissance. HyperObjects a également été classé au niveau européen
dans le classement européen appelé Fast 500.
HyperObjects est composée de deux départements fonctionnels et d’un service, le département
«PIM» (Product Information Management), le service «e-Questionnaire» et le département
«Publications». Le premier, comme son nom l’indique, a pour mission le développement et la
maintenance des solutions de gestion de contenu telles que W-Esperanto (pour HP). Le service «e-
5

12. eQ Services
Questionnaire», qui est en charge de l’application portant son nom, se compose d’une seule
personne. Il peut arriver qu’une ressource du département PIM y soit allouée pour une période
temporaire en cas de besoin. Enfin Le département « Publications » qui se charge de la publication
des données ayant transitées par le département « PIM ».
B. Présentation du e-Questionnaire v 4.5
e-Questionnaire v4.5 comme a été mentionné auparavant, englobe toutes les étapes de création,
diffusion et d'analyse d'une enquête en ligne professionnelle. Ma mission par contre sera plutôt
focalisée sur la partie analyse.
Tous les résultats fournis par e-Questionnaire v4.5 sont sous forme de tableaux et de graphiques
détaillés. La version actuelle permet de choisir des graphiques parmi une bibliothèque de 17 styles:
• Secteurs (simples, éclatés, empilés)
• Histogrammes (simples, empilés, empilés à100%)
• Barres (simples, empilées, empilées à 100%)
• Courbes (simples, empilées, empilées à 100%)
• Anneaux (simples, éclatés)
• Radar (simple, plein)
• Surface.
On peut alors visualiser les réponses individuelles de chaque répondant ou choisir de construire un
rapport. Pour chaque question on peut choisir le graphique le plus sensé par rapport à la nature de
la question et la tendance qu'on veut mettre en évidence. On peut consolider dans un deuxième
temps le rapport en supprimant certaines réponses jugées non représentatives via des filtres ou en
faisant recours à une fonction de croisement qui permet de réaliser une analyse croisée entre deux
questions fermées.
Enfin l'utilisateur a le choix de télécharger le rapport final contenant les différents graphes et
tableaux au format Microsoft Word ou HTML.
C. Caractéristiques logicielles et matérielles
Tous les éléments des questionnaires sont gérés et stockés dans des fichiers XML. Ces derniers (et
pour améliorer l'efficacité) passent par une étape de «dénormalisation» de données via des
procédures stockées afin de faciliter leurs utilisations dans des rapports.
Cette performance et cette grande flexibilité sont rendues possible grâce à l'alliance entre de
grands standards logiciels et matériels qui ont déjà fait leurs preuves.
6

13. eQ Services
Architecture client/serveur (Web)
Stockage des questionnaires XML
Mise en forme des questionnaires XSL, CSS2
SGBD SQL Server 2000
Composants COM/COM+
Serveur Web IIS 5.0 updated
OS Windows Web 2000
Serveurs HP NetServer LP2000R
Processeurs Double Pentium 4, 1Ghz
Mémoires 760Mo SDRAM
Bande passante 2048MB
Tableau 1 : Caractéristiques matérielles et logicielles du eQ v4.5
D. Limitations et perspectives
Victime de son propre succès, e-Questionnaire v4.5 a de plus en plus du mal à supporter seul la
charge des milliers d'utilisateurs instantanés. L'introduction donc d'un nouveau serveur s'impose. Et
vu leurs appétits excessifs aux ressources matérielles, il était clair que le module de génération des
rapports graphiques soit le candidat le mieux placé pour avoir l'honneur d'être hébergé dans la
nouvelle machine.
7

14. eQ Services
E. Planning prévisionnel
mars avril mai juin juillet
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Familiarisation avec
1 l'environnement et étude de
l'existant
Étude avancée du XML et
2 Infragistics dans le Framework
.NET 2.0
Prototype du eQ Générateur
3 Dynamique de Diagrammes
(eQGDD)
eQ Web Service basé sur
eQGDD en C# et exemple
4
démonstration d'un client en
ASP
Déploiement et adaptation du
5 eQ Web Service et rédaction de
sa documentation détaillée
Investigation avancée sur
Reporting Services 2005 et
6
Crystal Report et définition d'un
cahier de charges adapté à eQ
Mise en oeuvre d'un premier
7 prototype du eQ Reporting
Services
Amélioration du prototype et
8
déploiement de la solution
Finalisation du rapport final et
9
préparation de la soutenance
Tableau 2 : Planning prévisionnel
8

15. eQ Services
VIII. Méthodologies de travail
1. Introduction
Mon stage a démarré par une phase d'exploration volontairement étalée sur un mois. La première
quinzaine a été consacrée à une mise à niveau générale focalisée sur les nouveautés implémentées
par le Framework .NET 2.0, après je me suis plutôt concentré sur les classes et les composantes
qui m'ont apparues les plus susceptibles d’être utilisées d’après mon cahier de charge initial.
2. Découverte de l'eXtreme Programming
À première vue, cela apparaît hasardeux de me lancer directement dans la programmation sans
passer par la démarche traditionnelle basée sur la célèbre séquence: spécification -> conception ->
réalisation -> validation.
À vrai dire, sans s’en rendre compte immédiatement, Monsieur Florent BOUQUEROD me faisait
initier à l'eXtreme Programming (XP) qui est un processus de développement logiciel et surtout un
des principaux représentants d'une famille apparaissant de processus: Les processus dits «agiles».
Normalement, avec les méthodes classiques, une grande partie est réservée à des entretiens avec
le client qui essaye d'exprimer son besoin particulier à des développeurs qui se trouvent souvent
face à du ''jamais vu''. Ces derniers tentent alors de croiser ce ''jamais vu'' avec leur expérience du
''déjà vu'' afin de réaliser une modélisation abstraite (totalement incompréhensible par le client
final) sur quoi se baser pour réaliser une application fonctionnelle avec des interfaces homme-
machine livrées aux optimistes des cas juste quelques semaines avant la fin officielle destinée à la
période du projet.
Conception Réalisation Livraison
Figure 1 : Démarche non agile de gestion de projets
Malheureusement, on est loin de vivre dans un monde parfait. Les équipes de développement qui
évoluent souvent dans un environnement changeant ou complexe savent déjà à quel point il est
difficile de s’en tenir aux décisions initiales.
Le client réalise que ses besoins ont changé, ou bien l’équipe découvre en phase d’implémentation
des erreurs de spécification ou de conception qui compromettent le plan initial du développement.
Le changement s’impose donc tôt ou tard… Mais voilà, cette organisation suppose l’absence de
changement, et celui-ci se révèle bien vite très coûteux, suffisamment parfois pour contrarier la
rentabilité du projet.
9

16. eQ Services
Mais puisque le changement est une composante incontournable de tout projet de développement
logiciel, pourquoi ne pas l’accepter ? N’existe-t-il pas un moyen pour que les équipes de
développement ne s’opposent plus à une inflexibilité gelée de la part de leur livrable face aux
demandes du client final ?
Les créateurs du XP ont trouvé une réponse à ces questions en découvrant que certaines pratiques
d’organisation d’équipe et de programmation, permettent de rendre le logiciel extrêmement agile à
tel point qu’il devient plus avantageux de le faire évoluer progressivement que de chercher à le
spécifier et le concevoir complètement dès le départ.
Partant de ce constat, ils ont conçu une démarche qui diffuse le processus de décision tout au long
du projet grâce à l’enchaînement de cycles itératifs très courts :
Livraison Livraison Livraison
Livraison Livraison Livraison
Figure 2 : Démarche agile de gestion de projets
Le grand gagnant de cette démarche est d’abord le client du projet. Plutôt que de voir son
intervention limitée à la phase initiale de recueil du besoin, il intègre véritablement le projet pour
en devenir le pilote.
A chaque itération, il choisit lui-même les fonctionnalités à implémenter, collabore avec l’équipe
pour définir ses besoins dans le détail, et reçoit une nouvelle version du logiciel qui intègre les
évolutions en question.
Cette démarche présente de nombreux avantages en termes de conduite de projet :
• Le client jouit d’une très grande visibilité sur l’avancement du développement
• Le client utilise le logiciel lui-même comme support de réflexion pour le choix des
fonctionnalités à implémenter. Il peut en particulier intégrer très tôt les retours des utilisateurs
pour orienter le développement en conséquence
• La première mise en production du logiciel intervient très tôt dans le projet, ce qui avance
d’autant le moment à partir duquel le client peut en tirer des bénéfices
• L’ordre d’implémentation des fonctionnalités n’est pas guidé par des contraintes techniques,
mais par les demandes du client. Celui-ci peut donc focaliser les efforts de l’équipe sur les
fonctionnalités les plus importantes dès le début du projet, et ainsi optimiser l’utilisation de son
budget.
10

17. eQ Services
3. eXtreme Programming en détails
a) La naissance
On doit XP particulièrement à Kent Beck, un consultant et un vétéran de programmation avec le
langage SmalTalk. Elle a été instaurée lors d'un projet nommé le « Chrysler Comprehensive
Compensation » ou « C3 » pour le compte du groupe américain Daimler Chrysler. Après, L'XP est
né officiellement en octobre 2000 avec le livre «Extreme Programming Explained».
b) XP face aux méthodes traditionnelles
Par rapport aux autres méthodes plus traditionnelles comme RAD et Unified Process (qui s'appuie
sur UML), les professionnels répètent qu’il serait une erreur de les opposer aux méthodes agiles. XP
peut être vu plutôt comme une déclinaison de Unified Process (UP), en ayant bien en tête
cependant que c’est le client qui rédige les spécifications en XP contrairement à UP où les
spécifications sont une interprétation de ce qui a été compris par l’informaticien. Aussi, les
itérations qui sont un des principes des deux méthodes sont environ 6 fois plus fréquentes en XP.
Ainsi, les méthodes classiques et les méthodes agiles sont complémentaires.
UML qui est une méthode de modélisation n’est pas aussi comparable à XP qui est une méthode de
réalisation et d’organisation. D’ailleurs, XP utilise le langage universel qu’est UML pour
communiquer. Toutefois, par sa volonté de rapidité, XP reste prudent sur l’utilisation d’UML. Pour
cause, les diagrammes UML sont trop longs à réaliser alors que la conception en XP étant très
courte et réalisée au fur et à mesure.
c) Le cycle de développement
Scénarios
utilisateur
Spécifications
Approbation
Test
Planning Itération
Exploration
client
d’acceptation
Estimations
Nouveaux scénarios
Figure 3 : Cycle de vie du XP
XP vise une réduction significative de la durée du cycle de développement, c’est-à-dire du temps
qui s’écoule entre le moment où l’on décide d’implémenter une fonctionnalité et celui où l’on met
en production une nouvelle version du logiciel qui intègre la fonctionnalité en question.
L'organisation en itérations fréquentes validées à chaque fois par le client constitue l'innovation de
XP en matière de réduction du temps de développement. L'équipe peut casser parfois la structure
en place lorsque l’ajout de nouvelles fonctionnalités l’exige, ou bien lorsque elle découvre des
11

18. eQ Services
défauts dans la mécanique existante, mais elle peut jamais avoir l’impression de revenir en arrière
ou de perdre du temps inutilement.
XP apporte des solutions concrètes à ces problématiques, avec un ensemble de pratiques qui forme
un système cohérent et efficace.
d) Les valeurs du XP
XP repose sur 4 valeurs fondamentales:
• La communication: c'est le moyen fondamental d'éviter les erreurs. Le moyen à privilégier est la
conversation directe, en face à face. Les moyens écrits ne sont que des supports et des moyens
de mémorisation
• Le courage: il est nécessaire à tous les niveaux et de la part de tous les intervenants,
notamment chez les développeurs (quand des changements surviennent à un stade avancé du
projet, ou quand des défauts apparaissent) et chez le client (qui doit pouvoir prioriser ses
demandes)
• Le retour d'information (feedback): les itérations sont basées sur les retours d'informations du
client, permettant une adéquation totale entre l'application finale et sa demande;
• La simplicité: en XP, la façon la plus simple d'arriver à un résultat est la meilleure. Prévoir
préalablement des évolutions futures n'a pas de sens. Ce principe est résumé en une phrase:
«Tu n'en auras pas besoin.» (en anglais «You ain't gonna need it.»). La meilleure manière de
rendre une application extensible est de la rendre aussi simple (et donc simple à comprendre)
et aussi bien conçue que possible.
e) Les pratiques du XP
Ces 4 valeurs se déclinent en 13 pratiques:
• Client sur le Site (On-Site Customer) : Pour une meilleure communication, le client et les
développeurs travaillent dans le même espace autant que possible.
• Séance de Planification (Planning Game) : Le client définit les scénarios utilisateurs prioritaires.
Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-
jacentes, estiment ces tâches et y souscrivent.
• Intégration Continue (Continuous Integration) : Le système est intégralement assemblé et testé
une à plusieurs fois par jour.
• Livraisons Fréquentes (Frequent Releases) : Le rythme des livraisons est de l'ordre de quelques
semaines.
• Rythme Soutenable (Forty-hour Week) : L'équipe ne fait pas d'heures supplémentaires deux
semaines de suite.
• Tests de Recette (Acceptance Tests) : Retour d'information rapide sur le système, en général
automatisé, constitué à partir de critères de tests définis par le client.
12

19. eQ Services
• Tests Unitaires (Unit Tests) : Tests automatisés écrits pour chaque classe, chaque méthode, et
pour tout quot;ce qui pourrait casserquot; en général. Ces tests doivent passer à 100% continuellement.
• Conception Simple (Simple Design) : Le code doit passer tous les tests et répondre aux critères
de maintenabilité : concision, modularité, cohérence, lisibilité.
• Métaphore (Metaphor) : Une analogie utilisée comme modèle conceptuel du système en cours
de développement.
• Remaniement Continu ou Refactorisation de Code pratiquée sans relâche : modification du code
par laquelle on améliore sa conception sans en modifier le comportement.
• Convention de Code (Coding Standard) : Le code doit suivre une convention de nommage et de
présentation afin d'être lisible par tous les membres de l'équipe.
• Programmation En Binôme (Pair Programming) : Le code de production est toujours écrit par
deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet.
• Propriété Collective du Code (Collective Code Ownership) : Chaque développeur peut modifier
chaque partie du code si le besoin s'en fait sentir.
4. Conclusion
L’eXtreme Programming est une méthode révolutionnaire pour la gestion de projets informatiques.
Basée sur des principes simples, elle permet de venir enfin à bout des dépassements de délais et
donc de budget, tout en utilisant des pratiques agiles et adaptables face aux changements
fréquents des spécifications initiales.
Parmi ces pratiques, La démarche itérative de l’eXtreme Programming s’avère être le principal
atout surtout du point de vue de la maîtrise d'ouvrage.
13

20. eQ Services
IX. eQ Charting Services
A. Introduction
Ce chapitre a pour but de fournir un aperçu général sur le fonctionnement et les services offerts par
le module eQ Charting Services.
Cet aperçu est assisté par une description détaillée de l'ensemble de l'architecture adoptée afin
d'essayer de justifier au mieux les choix faits pour la conception et la réalisation technique du dit
service web.
B. User Stories
Mon coach fonctionnel Pascal LIEBART a joué le rôle de mon client fictif direct. Sa grande
expérience et son sens de communication et de marketing lui ont permet d’avoir une perception
claire et limpide des besoins et des attentes des vrais clients finaux.
Ces spécifications peuvent être résumées comme suit:
• Créer des images représentant les diagrammes des questionnaires
• La source de données pour les diagrammes sera un fichier XML publié par la version ASP du eQ
• Le service Web devra pouvoir, dans un premier temps, choisir pour l'utilisateur final le
diagramme le plus adapté pour chaque question demandée. Après, l'utilisateur pourra à tout
moment personnaliser ce choix
• Les diagrammes générés doivent être facilement paramétrables
• Mise en oeuvre d'une démonstration d'un client en ASP consommant le service Web et générant
du code HTML contenant l'image résultante.
14

21. eQ Services
C. Architecture
1. Architecture générale
Source de
données XML
<?xml…
<Report… Importation Chargement
Xml To
XmlDocument DataView
Provider Mapper
Réorganisation
et filtrage
Infragistics DLL
Code
Flux binaire
eQ Dynamic
eQ Web Service
Diagrams
Generator Engine
<?xml…
<Width… Paramètres
SOAP
XML
<Height… personnalisés
HTTP+XML
Paramètres eQ ASP Client
par défaut
Figure 4 : Architecture générale du eQ Charting Services
2. eQ Générateur Dynamique des Diagrammes
a) XmlDocument Provider
Ce module a pour fonction de retourner un objet XmlDocument représentant la structure XML des
données à analyser. XmlDocument est définie par le .NET 2.0 comme étant une classe qui
implémente le W3C Document Object Model (DOM). Le DOM est une représentation sous forme
d'arborescence en mémoire indépendante (cache) d'un document XML qui permet l'exploration de
ce document et sa modification.
J'ai opté pour l’isolation de cette fonction dans une classe à part, vu que la nature du canal de
transmission des données reçues en amont pouvait à tout moment changer. Par exemple dans un
15

22. eQ Services
premier temps, c'était temporairement un fichier XML accessible via un URL, après on a plutôt
adopté un flux communiqué par un service Web du côté ASP, ça pouvait aussi être un service offert
directement par le moteur SQL Server...
Donc, pour plus d'agilité, le reste du cheminement de la solution n'a pas à se préoccuper du
«Comment», les données sont récupérées, ce qui compte pour les autres composantes, c'est
s'attendre à un objet XmlDocument.
b) XmlToDataView Mapper
Une fois la structure des données XML récupérée, il faut à présent la préparer pour être exploitable
dans la génération des diagrammes correspondants. En fait, la structure XML qui m'est fournie,
n'est pas optimisée uniquement pour mon service Web mais elle est aussi exploitable dans d'autres
applications externes.
Du coup je me trouve face à une structure non normalisée dont on ne peut tirer profit qu'après un
filtrage et une réorganisation des données. Autrement dit, il faut faire un «mapping» d'une
structure hiérarchique (XML) vers une autre structure tabulaire (Table) tout en gardant entre
temps, que les données nécessaires pour le diagramme.
Donc après récupération du XmlDocument de la part du premier module XmlDocumentProvider, je
le fais passer par une étape de nettoyage et de filtrage. Vu la complexité du jeu de données qui
m’est fournie, les expressions de filtrage XPath se sont vite trouvées face à leurs limites et j’ai dû
les supporté par les possibilités d’itération offertes par le langage C#.
Une fois débarrassé des nœuds et attributs inutiles, on n’a nul besoin d’avoir une copie physique de
la structure tabulaire générée, si non, la performance sera sans doute pénalisée avec les allés
retours entre le module et la base de données.
.NET 2.0 se montre en parfaite adéquation avec nos besoins car il nous offre la classe DataTable
qui représente une table de données mais uniquement stockée et gérée en mémoire. C’est une
sorte de super tableau fortement typé qui contient une collection d’objets DataColumn. Après, pour
peupler la dite DataTable, on utilise la méthode NewRow qui retourne un nouvel objet DataRow
respectant le schéma de la collection des colonnes.
Une fois la DataTable créée et remplie, il se peut qu’on aille à la trier et la filtrer en cas de besoin.
Toujours avec le même espace de nom que celui de la DataTable (System.Data), on a aussi droit à
une autre classe DataView qui représente une vue personnalisée d’une DataTable pouvant faire
l'objet de liaisons de données pour le tri, la recherche, la modification et la navigation.
On peut encapsuler toutes ses étapes par l’organigramme suivant:
16

23. eQ Services
Question Id
Chercher la question
Question
Oui Non
Simple ou
groupée?
Isoler le groupe
Isoler les nœuds
de questions
de modalités
Oui Non
Groupe
pondéré?
Isoler pour
Isoler pour
chaque question
chaque question
son groupe de
sa moyenne
modalités
Créer à la volée la
DataTable
correspondante
Fournir une
DataView
(triée ou non) sur la
DataTable
Figure 5 : Organigramme du module XML to DataView Mapper
17

24. eQ Services
Exemples de mapping entre le XML hiérarchique et la DataView tabulaire:
1- Pour le cas d’une question simple :
<Questionnaire QuestionnaireName=quot;Enquête d'accueilquot;>
<ResultForXml Q_Id=quot;460quot; Q_Label=quot;Titrequot; Q_Sort=quot;7quot;
M_Id=quot;465quot; M_Label=quot;Mademoisellequot; M_Sort=quot;8quot;
Total=quot;1.296000000000000e+003quot;
TotalQuest=quot;2.881000000000000e+003quot;
TotalMod=quot;0.000000000000000e+000quot;
Qpercent=quot;4.498438042346407e+001quot;
TotalGroup=quot;0.000000000000000e+000quot;
Ponderation=quot;0quot; ResultDate=quot;10/4/2006quot;
Q_Type=quot;52quot;>
<LGroup TitleParent=quot;Mais avant toute chose, merci de
nous indiquer vos coordonnéesquot; parentType=quot;30quot;
parentId=quot;460quot;>
<LR />
</LGroup>
</ResultForXml>
<ResultForXml Q_Id=quot;460quot; Q_Label=quot;Titrequot; Q_Sort=quot;7quot;
M_Id=quot;464quot; M_Label=quot;Madamequot; M_Sort=quot;9quot;
Total=quot;4.280000000000000e+002quot;
TotalQuest=quot;2.881000000000000e+003quot;
TotalMod=quot;0.000000000000000e+000quot;
Qpercent=quot;1.485595279416869e+001quot;
TotalGroup=quot;0.000000000000000e+000quot;
Ponderation=quot;0quot; ResultDate=quot;10/4/2006quot;
Q_Type=quot;52quot;>
<LGroup TitleParent=quot;Mais avant toute chose, merci de
nous indiquer vos coordonnéesquot; parentType=quot;30quot;
parentId=quot;460quot;>
<LR />
Figure 6 : Arrangement d’un XML d’une question simple
18

25. eQ Services
2- Pour le cas d’une question groupée pondérée
<ResultForXml Q_Id=quot;1095quot; Q_Label=quot;- Intérêt de
l'information présentéequot; Q_Sort=quot;167quot;
M_Id=quot;1068quot; M_Label=quot;sans opinionquot; M_Sort=quot;165quot;
moyenne=quot;3.0383878e+000quot;
maximum=quot;4.0000000e+000quot;
Total=quot;4.600000000000000e+001quot;
TotalQuest=quot;5.660000000000000e+002quot;
TotalMod=quot;4.300000000000000e+002quot;
Qpercent=quot;8.127208480565370e+000quot;
TotalGroup=quot;4.498000000000000e+003quot;
Ponderation=quot;1quot; ResultDate=quot;10/4/2006quot;
Q_Type=quot;41quot;>
<LGroup TitleParent=quot;Merci de noter ces différents
aspects d'e-Questionnairequot; parentType=quot;41quot;
parentId=quot;1060quot;>
<LR type=quot;verbatimquot; idQuestion=quot;1095quot; titleQ=quot;-
Intérêt de l'information présentéequot;
idModalite=quot;1068quot; idParent=quot;1060quot;
GroupTitle=quot;Merci de noter ces différents aspects
d'e-Questionnairequot; countResponse=quot;1quot;
Response=quot;*quot; />
<LR type=quot;verbatimquot; idQuestion=quot;1095quot; titleQ=quot;-
I té êt d l'i f ti é té quot;
Figure 7 : Arrangement d’un XML d’une question groupée pondérée
3- Pour le cas d’une question groupée non pondérée
Figure 8 : Arrangement d’un XML d’une question groupée non pondérée
En plus de la DataView créée, ce module offre aussi d'autres informations sur la question cible à
savoir par exemple le numéro du questionnaire auquel elle appartient, sa nature, son type et ses
modalités...
19

26. eQ Services
c) eQDDG Engine
Le moteur eQ Générateur Dynamique de Diagrammes est un rassemblement d'une vingtaine de
classes (tout à fait ouvert à abriter d'autres) organisées entre elles en profitant au maximum des
possibilités de la programmation orientée objet offertes par le langage C# 2.0.
Le eQGDD repose principalement sur deux fichiers DLL:
• Infragistics2.WebUI.UltraWebChart.v6.1.dll
• Infragistics2.WebUI.Shared.v6.1.dll
Ces deux fichiers sont fournis par la société Infragistics qui a comme champs d'application, tout
besoin ayant une relation avec la couche présentation sous les environnements Microsoft.
Infragistics nous offre aussi une boite à outils intégrée à Web Developer Express Edition 2005 qui
permet de créer un diagramme personnalisé sans écrire la moindre ligne de code. Le challenge
était donc de réaliser une solution qui va permettre de générer des diagrammes d'une manière
dynamique et automatisée et qui ne nécessitera pas une intervention humaine.
Le eQGDD Engine doit donc fournir une certaine intelligence qui choisira le meilleur rendement pour
chaque type de question tout en offrant à l'utilisateur final la possibilité de personnaliser encore son
diagramme selon sa guise.
Alors normalement pour créer un diagramme avec Infragistics, une seule classe suffit:
UltraWebChart. Une fois instanciée, on doit ensuite régler un certain nombre de propriétés et
appeler principalement deux méthodes (DataBind() et SaveTo()) pour avoir notre graphe en sortie.
La démarche classique laisse penser l'architecture suivante:
Chart
Void LoadParam() Void SetParam()
{ {
Prop1
if(C1) if(C1)
Prop2
{ {
…
//… //…
} }
LoadParam()
if(C2) if(C2)
SetParam()
{ {
DrawChart()
//… //…
} }
//… //…
} }
Void DrawChart()
{
//…
}
Figure 9 : Programmation classique
Dans le schéma précédent, la classe Chart gère le cas C1 et le cas C2 sans grand problème. Mais
voilà: si un nouveau cas C3 doit aussi être géré, c'est inévitable, il faut modifier obligatoirement le
code de la classe Chart.
20

27. eQ Services
Tôt ou tard, des changements s'imposeront sur certaines parties du code et chacune de ces
modifications oblige à modifier le code existant... ce qu'est à la fois coûteux et risqué car tout le
monde sait au passage qu'il n'y a pas plus fragile qu'un code informatique.
Pour éviter ça, des pratiques ont été mises en oeuvre par les professionnels en la matière pour
réduire ce risque. Parmi ces pratiques; le principe d'ouverture/fermeture précise que tout module
doit être à la fois:
• Ouvert aux extensions: Le module peut être étendu pour proposer des comportements qui
n'étaient pas prévus lors de sa création
• Fermé aux modifications: Les extensions sont introduites sans modifier le code du module.
En d'autres termes, l'ajout de fonctionnalités doit se faire en ajoutant du code et non en éditant le
code existant. Cette agilité peut se réaliser grâce aux libertés d'abstraction fournies par le
Framework .NET 2.0 et son langage vedette C#.
Le code de la classe Chart peut donc être ouvert/fermé aux modifications en rendant cette dernière
comme étant une classe abstraite qui définie uniquement les méthodes qui ne dépendent pas d'un
cas précis. Par contre pour les autres méthodes qui doivent être individualisées selon une situation
particulière, ces méthodes sont déclarées abstraites et leurs comportements sont plutôt laissés à
des classes dérivées C1 et C2 qui représentent le cas C1 et le cas C2.
Chart
Void DrawChart() protected Prop1
{ protected Prop2
//… …
}
abstract LoadParam()
abstract SetParam()
public DrawChart()
…
C1 C2
LoadParam()
LoadParam() LoadParam()
SetParam()
SetParam() SetParam()
Void LoadParam()
Void LoadParam()
{
Void SetParam() Void SetParam()
{
//…
{ {
//…
}
//… //…
}
} }
Figure 10 : Programmation agile
21

28. eQ Services
Si un troisième cas s'impose alors on introduit une classe C3 qui va aussi dériver de la classe Chart
en implémentant les méthodes abstraites selon le comportement souhaité et ceci, sans toucher ni à
la classe mère Chart ni aux autres classes C1 et C2.
Le mécanisme d'abstraction consiste donc à extraire la partie variable du code que l'on souhaite
rendre agile. Et pour permettre au code d'accueillir les évolutions futures, plutôt que de modifier le
code existant en compromettant le fonctionnement total de l'application, on introduit alors une
sorte de « Plugin » qui ne va avoir d’effet que sur la partie pour laquelle a été créé.
22

29. eQ Services
Figure 11 : Modèle objet du eQGDD Engine
On peut par exemple voir de plus près l’application de cette technique dans ce zoom non exhaustif
du modèle objet (Voir l’annexe pour le modèle objet complet) :
23

30. eQ Services
Figure 12 : Aperçu sur l’utilisation de l’abstraction
La classe principale est la classe Chart, c'est une classe abstraite non instanciable directement.
Cette classe contient un certain nombre de propriétés communes à tout type de diagrammes
comme par exemple les dimensions et la palette de couleurs. Quant aux méthodes, en plus des
fonctions privées, la classe Chart déclare deux autres méthodes abstraites LoadDefaultParameters()
et SetParameters() dont l'implémentation est laissée aux classes dérivées. Par contre et vu que le
24

31. eQ Services
traitement des méthodes GetChartImagePath() et GetChartStream() est le même quelque soit la
diagramme, c'est donc la classe abstraite qui se charge de leurs définitions.
On peut donc remarquer l'utilité immense qui vient apporter les classes abstraites par rapport à la
démarche non orientée objet et aussi par rapport à l'utilisation des Interfaces classiques (Ces
dernières ne donnent pas la possibilité de déclarer à l'intérieur même de la classe interface des
attributs ni d'implémenter des méthodes... ce qui n'est plus le cas avec les classes abstraites).
d) eQ Parameters
Le module eQGDD donne assez de flexibilité aux clients rigoureux (avant de générer les
diagrammes) de paramétrer un grand nombre de propriétés spéciales. Cependant, il existe aussi
des clients ne disposant pas du temps pour chercher la bonne combinaison ou tout simplement
n’ont pas d’attentes particulières du eQ à part le fait d’avoir en sortie un diagramme lisible.
Pour rendre donc la tâche plus facile à cette dernière catégorie, eQGDD est doté d’une sorte
« d’intelligence » qui se charge de tout le travail pour eux. eQGDD n’attend de l’utilisateur que le
numéro de la question, une analyse avancée de la question est alors exécutée pour choisir le
meilleur diagramme avec les meilleurs paramètres selon la nature de question (simple ou groupée,
pondérée ou non, ouverte ou fermée, à choix multiples ou à choix unique…)
Un seul click est donc suffisant pour combler le client, après, s’il n’est pas entièrement satisfait, il
peut toujours surcharger cette proposition par ses propres réglages.
Cette flexibilité et cette puissance ont été rendues possibles en se basant plus particulièrement sur
un fichier XML nommé « ChartParameters.xml » qui regroupe la meilleure combinaison des
paramètres. Cette démarche est tout à fait ingénieuse car un fichier XML est facilement
compréhensible pour les humains comme pour les machines, et donc on a pas besoin d’un éditeur
spécial ni de compétence ou de technologie informatique avancée pour régler ces paramètres.
En plus, cette méthode nous a permis de gagner en vitesse car puisque les paramètres par défaut
se situent plutôt à l’extérieur des classes du eQGDD, il n’est plus donc nécessaire de recompiler le
projet en cas de changement de ses paramètres.
25

32. eQ Services
Figure 13 : Aperçu sur un fragment du fichier de paramétrage
e) Conclusion
Le eQ Générateur Dynamique de Diagramme est la brique principale de mon projet. Sa conception
architecturale et sa réalisation technique sont basées sur une démarche professionnelle, agile et
performante. En gros, ceci a été rendu possible grâce à:
• Division du programme en modules fonctionnels
• Exploiter à fond les nouveautés du Framework .NET 2.0
• Opter pour une programmation orientée objet agile
• Focaliser le paramétrage de l’ensemble de l’application autour de fichiers XML.
L'application de ces règles ainsi que d'autres principes dans le cas du eQGDD m'ont permis donc
d'avoir un modèle maniable, flexible et optimisé pour répondre aux nouvelles spécifications du
client dans des délais assez courts et sans nuire aux autres fonctionnalités du reste de l'application.
3. Partie Services Web
a) Introduction
Une fois le diagramme généré en local, il reste à présent de le faire parvenir à sa destination finale
qu'est la version actuelle en ASP/VBscript du eQ.
26

33. eQ Services
Bien que ASP et ASP.NET paraissent semblables vu leurs noms, il n'en est guerre le cas car le
premier est un langage interprété alors que le deuxième est un langage compilé. La difficulté était
donc de faire communiquer plus précisément les objets du ASP/VBscript d'un côté avec les classes
du eQGDD écrites en C# 2.0 de l'autre côté.
Pour résoudre ce problème, la réponse la plus spontanée ne pouvait pas être autre chose que les
services Web.
b) Caractéristiques d’un service Web
Un service Web est un ensemble de protocoles et de normes informatiques utilisés pour échanger
des données entre les applications.
Les logiciels écrits dans divers langages de programmation et sur diverses plateformes peuvent
employer des services Web pour échanger des données à travers des réseaux informatiques
comme internet. Cette interopérabilité est due à l'utilisation de normes ouvertes regroupées au sein
du terme générique de SOA (Service Oriented Architecture ou Architecture Orientée Services).
L'OSI et le W3C sont les comités de coordination responsables de l'architecture et de la
standardisation des services Web.
Ses avantages sont :
• Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses
plateformes
• Les services Web utilisent des standards et protocoles ouverts
• Les protocoles et les formats de données sont au format texte dans la mesure du possible,
facilitant ainsi la compréhension du fonctionnement global des échanges
• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux
pare-feux (firewalls) sans nécessiter des changements sur les règles de filtrage.
Et ses inconvénients
• Les normes de services Web dans les domaines de la sécurité et des transactions sont
actuellement inexistantes ou toujours dans leur débuts comparées à des normes ouvertes plus
mûres de l'informatique répartie telles que CORBA.
• Les services Web souffrent de performances faibles comparées à d'autres approches de
l'informatique répartie telles que le RMI, CORBA, ou DCOM.
• Par l'utilisation du protocole HTTP, les services Web peuvent contourner les mesures de sécurité
mises en place au travers des pare-feux.
Quelles sont alors les raisons pour créer des services Web ?
27

34. eQ Services
Les services Web implémentent la logique métier rendue consommable par l'utilisation de
standards (majoritairement TCP/IP, HTTP/SMTP... pour le transport, puis XML pour le contenu), ce
qui permet à n'importe quelle technologie utilisant les standards de pouvoir l'exploiter, facilitant
ainsi l'interopérabilité des applications.
La création de service Web se justifie par l'architecture orientée service, c'est à dire la volonté de
rendre accessible un service qui implémente une logique métier cachée à des utilisateurs.
Dans le cadre de contrats d'échanges de données en Business to Business (entreprise <->
entreprise), comme en Business To Customer (entreprise <-> client/utilisateur), un autre intérêt
pour lequel des services Web sont employés est le fait qu'ils se fondent sur le HTTP (donc
possibilité d'utiliser le port 80). En fait, beaucoup d'entreprises se sont protégées en employant
des firewalls qui filtrent et bloquent beaucoup de trafic d'Internet pour des raisons de sécurité.
Dans ce milieu, beaucoup de (presque tous les) ports sont fermés au trafic entrant et sortant et les
administrateurs de ces firewalls ne sont pas désireux de les ouvrir. Le port 80, cependant, est
toujours ouvert parce qu'il est employé par le protocole HTTP utilisé par les navigateurs Web. Avec
cet avantage, le service Web représente une sorte de tunnel qui permet une ouverture et une
extensibilité infinie des applications déjà existantes chez les entreprises.
c) Services Web : Le cas eQ
Dans notre cas précis, les problèmes de sécurité ne sont pas posés car le module offrant le service
Web et le module consommant ce dernier seront hébergés dans deux serveurs qui appartiennent
au même réseau local. Les règles d'accessibilités seront donc facilement paramétrables et surveillés
via les outils d'administration du IIS.
Côté performance, et toujours sachant que le serveur et le client appartiennent au même réseau
local, l'obstacle de la rapidité n'influence plus le fonctionnement de l'application vu que c'est
carrément une liaison directe point-à-point. On gagne donc en temps car on évite la perte destinée
initialement à se trouver un chemin optimum dans le réseau maillé qu'est internet. De même pour
le volume des informations échangées, le fait d'opérer sur un canal Fast Ethernet interne de 100
Mbit/s, on est donc sûr de ne pas interférer et surtout nuire aux utilisations initiales de l'application
ASP eQ 4.5.
d) Service Oriented Architecture
Service Oriented Architecture (SOA) ou l'architecture orientée service est un modèle d’interaction
applicative qui met en oeuvre des services (composants logiciels) :
• Avec une forte cohérence interne
• Et des couplages externes «lâches».
Le service est une action exécutée par un «fournisseur» (ou «producteur») à l’attention d’un
«client» (ou «consommateur»).
28

35. eQ Services
Les architectures SOA ont été popularisées avec l'apparition des services Web dans l'e-commerce
(B2B ou B2C) et elles mettent en application une partie des principes d'urbanisation.
Les architectures SOA reposent principalement sur l’utilisation d’interface d’invocation (SOAP) et de
vocabulaire de description de données (WSDL et XML) qui doivent être communs à l’ensemble des
agents (fournisseurs de services et utilisateurs de services).
Ce dispositif permet de réutiliser les applicatifs métier et aussi permettre à l’entreprise de s’adapter
rapidement à un nouveau contexte de marché.
Figure 14 : Les services offerts par eQ Charting Services
e) Web Services Description Language
Il s'agit d'une tentative de normalisation regroupant la description des éléments permettant de
mettre en place l'accès à un service réseau (service Web).
Le WSDL décrit une Interface publique d'accès à un Service Web. C'est une description basée sur le
XML qui indique «comment communiquer pour utiliser le service»; Le Protocole de communication
et le format de messages requis pour communiquer avec ce service.
Les opérations possibles et messages sont décrits de façon abstraite mais cette description renvoie
à des protocoles réseaux et formats de messages concrets.
29

36. eQ Services
L’objectif du WSDL peut être résumé comme suit:
Quoi et Comment ?
Contrat WSDL
Client Web
Requête valide
Consommateur Service
Réponse
Figure 15 : WSDL en action
Avec Web Developer 2005, le fichier WSDL est dynamiquement créé à partir des fichiers .asmx
synonyme de service Web sous le Framework .NET. Le fichier WSDL correspondant est facilement
récupérable en ajutant juste « ?wsdl » à l’URI du fichier .asmx précédent :
30

37. eQ Services
Figure 16 : Aperçu sur le fichier WSDL du eQ Charting Services
Côté client, une classe nommé Proxy Web doit être créée à partir du contrat WSDL. Cette classe
exploite les informations fournies sur le service Web afin de donner au développeur l'impression de
travailler en local. On peu ainsi:
• Appeler une méthode du service Web comme s'il s'agissait d'une méthode locale tout en
profitant de l'aide visuel du IDE
• Faire valider les appels par rapport au contrat WSDL avant l'envoi du message
• Interagir avec le service Web sans être familier avec la structure du WSDL et notamment pour
les non-initiés du XML
On peut par exemple voir ici l’aide visuel du IDE Web Developer qui se base sur une copie du fichier
WSDL téléchargée en local.
Figure 17 : L’assistant visuelle du Web Developer basé sur le WSDL
f) Simple Object Access Protocol
Simple Object Access Protocol (SOAP) est un protocole de RPC (Remote Procedure Call) orienté
objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire
qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur une autre
machine. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se
faire par un autre protocole, comme SMTP.
Le protocole SOAP est composé de deux parties :
• une enveloppe, contenant des informations sur le message lui-même afin de permettre son
acheminement et son traitement
• un modèle de données, définissant le format du message, c'est-à-dire les informations à
transmettre.
31

38. eQ Services
SOAP a été initialement défini par Microsoft et IBM, mais est devenu depuis une recommandation
du W3C et utilisé notamment dans le cadre d'architectures de type SOA pour les services Web.
L'exemple suivant représente la structure d'une requête SOAP :
<SOAP-ENV:Envelope xmlns:SOAP-ENV=quot;http://schemas.xmlsoap.org/soap/envelope/quot;xmlns:SOAP-
ENC=quot;http://schemas.xmlsoap.org/soap/encoding/quot;xmlns:xsi=quot;http://www.w3.org/2001/XMLS
chema-instancequot;xmlns:xsd=quot;http://www.w3.org/2001/XMLSchemaquot;>
<SOAP-ENV:Body>
<m:GetChartStream xmlns:m=quot;http://www.e-questionnaire.comquot;>
<m:XmlFile>http://marco/eQ/XMLReport.xml</m:XmlFile>
<m:Question>422</m:Question>
<m:ChartType>PieChart</m:ChartType>
</m:GetChartStream>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 18 : Exemple d’une demande SOAP de la méthode GetChartStream()
En cas d'une requête correcte, le service Web répond positivement en renvoyant le résultat. Dans
ce cas précis, et comme le conteneur de la réponse est une balise XML, il est bien sûr impossible de
faire transporter des objets voire des types complexes ou personnalisés (un objet Stream dans ce
cas).
L'astuce était dans ce cas de figure d'envoyer plutôt le code binaire de l'image. On transmet alors
du texte simple non bloqué par les firewalls et dont la taille totale ne dépasse pas quelques dizaines
de kilo-octet.
<?xml version=quot;1.0quot; encoding=quot;utf-8quot;?>
<soap:Envelope xmlns:soap=quot;http://schemas.xmlsoap.org/soap/envelope/quot;
xmlns:xsi=quot;http://www.w3.org/2001/XMLSchema-instancequot;
xmlns:xsd=quot;http://www.w3.org/2001/XMLSchemaquot;>
<soap:Body>
<GetChartStreamResponse xmlns=quot;http://www.e-questionnaire.comquot;>
<GetChartStreamResult>iVBORw0KGgoAAAANSUhEUgAAAfQAAAEsCAYAAAHIFG
IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAADAAAAGCC
DDQSRYQABCAAAQj4EUDofoT4OwQgAAEIQCADBBB6BhqJIkIAAhCAAAAIJABA
A41EESEAAQhAAAJ+BBC6HyH+DgEIQAACEMgAAYSegUaiiBCAAAQgAEIAABCGB
....
</GetChartStreamResult>
</GetChartStreamResponse>
</soap:Body>
</soap:Envelope>
Figure 19 : Réponse positive du service Web via la balise <GetChartStreamResult>
Et en cas d'erreur, un message est transmis au client dans une balise <soap:Fault>
<?xml version=quot;1.0quot; encoding=quot;utf-8quot;?>
<soap:Envelope
xmlns:soap=quot;http://schemas.xmlsoap.org/soap/envelope/quot;xmlns:xsi=quot;http://www.w3.org/2001/XML
Schema-instancequot;xmlns:xsd=quot;http://www.w3.org/2001/XMLSchemaquot;>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>System.Web.Services.Protocols.SoapException:
Le serveur n'a pas pu traiter la demande; System.Exception: Numéro inéxistant
à eQGDD.QuestionInfo.IsSimpleQuestion(String QuestionId)
32

39. eQ Services
...
</faultstring>
<detail/>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Figure 20 : Réponse négative du service Web via la balise <soap:Fault>
g) Les services Web sous le framwork .NET 2.0
La création d'un service Web avec Web Developer 2005 Express Edition est relativement simple et
il n'est plus nécessaire pour un développeur de prendre en charge les bas niveaux du service.
L'espace de nom System.Web.Services a été donc mis en oeuvre par Microsoft et se compose des
classes nécessaires dont doit dériver nos propres classes. Le Framework .NET offre aussi l'espace
de nom System.Web.Services.Protocols pour toutes les opérations de la transmission des données
entre le service Web et ses clients.
ASP.NET prend en charge les services Web via un fichier .asmx. Il s'agit d'un fichier texte similaire
à un fichier .aspx. Il peut faire partie d'une application ASP.NET et il est alors adressable par URI
tout comme les fichiers .aspx.
Voici un exemple très simple de fichier .asmx :
<%@ WebService Language=quot;C#quot; Class=quot;eQquot; %>
using System;using System.IO;
using System.Web.Services;
using System.Web.Services.Protocols;
using eQGDD;
[WebService(Namespace = quot;http://www.e-questionnaire.comquot;)]
public class eQ : System.Web.Services.WebService {
[WebMethod]
public Byte[] GetChartStream(string XmlFile, string Question, string ChartType)
{
eQGDD.eQGDD eQGDD = new eQGDD.eQGDD(XmlFile, Question);
return eQGDD.GetChartStream(ChartType).ToArray();
}
}
Figure 21 : Déclaration d’un service Web sous .NET
Ce fichier commence par une directive ASP.NET Web Service qui définit C# comme langage (On
peut également utiliser Visual Basic, C++ ou un des quelque 30 langages tiers supportés par le
Framework). Il importe ensuite l'espace de nom System.Web.Services et
System.Web.Services.Protocols qui sont obligatoires pour ce qui suit. Un espace de nom (facultatif)
est spécifié après pour le service Web.
Ensuite, la classe eQ est déclarée. Cette classe est dérivée de la classe de base WebService. Enfin,
toutes les méthodes qui seront accessibles à l'intérieur du service ont l'attribut personnalisé
[WebMethod] devant leur signature.
33

40. eQ Services
h) Utilisation des services Web avec ASP
Le fait que SOAP repose sur des technologies normalisées à savoir HTTP et XML, il est donc tout à
fait possible d'utiliser le service Web créé avec C# sous le Framework 2.0 avec n'importe quel
langage offrant au minimum un support d’envoi et de réception de requêtes avec HTTP et celui de
la manipulation des données XML.
Pour le cas d'ASP/VBscript, on peut donc opter pour la démarche suivante:
<%
Envelope = _
quot;SOAP-ENV:Envelope xmlns:SOAP-ENV=quot;http://schemas.xmlsoap.org/soap/envelope/quot;quot; & _
quot; xmlns:SOAP-ENC=quot;http://schemas.xmlsoap.org/soap/encoding/quot;quot; & _
quot; xmlns:xsi=quot;quot;http://www.w3.org/2001/XMLSchema-instancequot;quot; & _
quot; xmlns:xsd=quot;quot;http://www.w3.org/2001/XMLSchemaquot;quot;><SOAP-ENV:Body>quot; & _
quot;<m:GetBestChartStream xmlns:m=quot;quot;http://tempuri.org/quot;quot;> & _
quot;<m:XmlFile>quot; & XmlFile & quot;</m:XmlFile>quot; & _
quot;<m:Question>quot; & Question & quot;</m:Question>quot; & _
quot;<m:D3>quot; & D3 & quot;</m:D3>quot; & _
quot;</m:GetBestChartStream></SOAP-ENV:Body></SOAP-ENV:Envelope>quot;
set HTTPObject = server.CreateObject(quot;MSXML.XMLHTTPRequestquot;)
HTTPObject.open quot;postquot;, quot;http://marco/eQ/eQ.asmxquot;, False
HTTPObject.setRequestHeader quot;Content-Typequot;, quot;text/xmlquot;
HTTPObject.setRequestHeader quot;SOAPMethodNamequot;, _
quot;urn:myserver/soap:m:GetBestChartStreamquot;
HTTPObject.send Envelope
Result = HTTPObject.responseText
set XMLObject = server.CreateObject(quot;Microsoft.XMLDOMquot;)
XMLObject.loadXML Result
XPathQuery =quot;soap:Envelope/soap:BODY/GetBestChartStreamResponsequot;
Response = objReturn.selectSingleNode(XPathQuery).Text
%>
Figure 22 : Consommation bas niveau d’un service Web depuis ASP
On peut très bien distinguer du code précédent l'utilisation bas niveau en détail d'un service Web
selon le protocole SOAP.
D'abord, on commence par l'initialisation d'une variable « Envelope » par un appel correcte d'une
méthode offerte par le service Web. La charge de transmission de cette enveloppe SOAP est
déléguée à un objet XMLHTTPRequest dont le résultat est chargé dans un autre objet XMLDOM. Ce
dernier est en fin parcouru via une requête XPath question d'isoler la balise contenant le résultat
attendu.
Bien que cette solution soit tout à fait fonctionnelle, on remarque d'abord la non utilisation du
fichier WSDL fournie par le service Web. Cette solution suppose donc que le développeur
34

41. eQ Services
consommateur est capable de créer à partir du néant une structure XML valide de l'enveloppe SOAP
et qu'il a une idée a priori du résultat potentiel retourné.
Cette démarche reste donc délicate et un peu difficile à mettre en oeuvre, c'est pourquoi Microsoft
a réalisé un ensemble d'utilitaires gratuits pour ses anciens langages: Microsoft SOAP ToolKit.
Ce Toolkit est un ensemble de DLL qui peuvent être exploités par n'importe quelle langage de la
famille COM. Il offre une structure souple et orientée objet pour créer et consommer des services
Web, il offre aussi une prise en charge du côté sécurité en implémentant des fonctionnalités telles
que l'authentification et l'autorisation.
Ainsi, au lieu de passer par toutes les étapes déjà citées en construisant à la main l'enveloppe
SOAP et en créant soit même les objets HTTP et XML pour envoyer la requête et exploiter la
réponse, ces tâches peuvent plutôt être déléguées à un seul objet «SoapClient» qui se base sur la
description WSDL.
Set eQClient = Server.CreateObject(quot;MSSOAP.SoapClientquot;)
eQClient.ClientProperty(quot;ServerHTTPRequestquot;) = True
eQClient.mssoapinit(quot;http://marco/eQ/eQ.asmx?wsdlquot;)
Response = eQClient.GetBestChartStream(xmlfile, question, d3)
Figure 23 : Consommation d’un service Web en utilisant MS SOAP ToolKit pour ASP
Dans ce cas précis, une fois le code binaire de l'image obtenu, il reste plus que de l'interpréter en
l'affichant dans des pages ASP pour l'utilisateur final ou de le sauvegarder physiquement pour des
utilisations ultérieurs.
Set FSObject = Server.CreateObject(quot;Scripting.FileSystemObjectquot;)
Set FSOFile = objFSO.CreateTextFile(Path)
For i = 1 to LenB(Response)
FSOFile.Write Chr(AscB(MidB(Response, i, 1)))
Next
FSOFile.Close
Figure 24 : Procédure du sauvegarde physique de l’image du diagramme
D. Conclusion générale
Sans parler du gain en performance que cette architecture de service Web a apporté à e-
Questionnaire, sans parler de cette douce migration vers le Framework .NET qui ne pénalise pas
l’actuel exploitation du eQ V4.5, sans parler de cette génération dynamique qui offre le meilleur
rendement pour chaque question… une chose est sûre, c’est surtout le fait de donner aux
utilisateurs finaux plus d’agilité pour personnaliser les diagrammes qui constitue le principal
avantage du module eQ Charting Services
35

42. eQ Services
Alors que la version 4.5 en ASP ne permet que de changer le type du graphe :
Figure 25 : L’ancienne version de la partie analyse du eQ
36

43. eQ Services
En plus de l’amélioration du rendu graphique et la qualité de l’image générée, le nouvel module
permet d’aller plus loin comme on peut voir sur le site production d’eQ :
Figure 26 : Les nouveaux paramètres des diagrammes offerts au client
37

44. eQ Services
Figure 27 : Résultat du service Web
Le eQGDD est tout à fait extensible à fin de générer plus de 40 types différents de diagrammes,
cependant, pour le cas eQ, on a seulement mis l’accent sur les types les plus présentatifs et les
plus pertinents vis-à-vis de la nature des questions posées normalement dans ce genre d’enquêtes.
Exemple de diagrammes que eQGDD génère :
Type Diagramme généré
Pie Chart 3D
38

45. eQ Services
Cylinder Bar Chart 3D
Stack Bar Chart 3D
Column Chart 3D
39

46. eQ Services
Doughnut Chart 3D
Line Chart 3D
Area Chart 3D
Tableau 3 : Exemple de diagrammes générés
40

47. eQ Services
X. eQ Reporting Services
A. Introduction
Alors que le domaine de l’aide à la décision est en pleine explosion, je me suis vu proposer comme
mission la mise en place d’un système fiable de génération de rapports et de prise de décision. En
fait, cette étape du cycle proposée par e-Questionnaire est l’étape la plus importante et la plus
attendue de la part des abonnées de notre service. En plus d’être assez pertinent et
considérablement concluant, le rapport final doit surtout être généré d’une manière optimisée et
performante pour satisfaire les clients dans un temps minime.
B. La génération des rapports dans eQ 4.5
La différence avec le précédent module de génération de diagrammes s’incarne dans le fait que la
génération du rapport ne traite pas chaque question à part mais analyse plutôt l’intégralité des
questions du questionnaire en un seul processus. De plus, la partie Reporting doit pouvoir donner
aux clients la possibilité d’exporter les rapports afin de les consulter ou les exposer ailleurs sans
être obligés d’ouvrir une session internet.
Les utilisateur souhaitant pousser d'avantage leurs analyses, la version 4.5 du eQ leurs propose
deux fonctionnalités intéressantes : le filtrage et le croisement :
• Le « Filtrage » permet de sélectionner une partie des réponses suivant un critère particulier. Par
exemple si l'une des questions d’une enquête permet de déterminer le sexe des répondants, il
sera très facile pour l’utilisateur d'éditer deux rapports distincts: un relatif aux hommes et
l'autre aux femmes.
• La fonction « Croisement » permet de réaliser une analyse croisée entre deux questions
fermées. Pour reprendre l'exemple précédent, si l'on croise les réponses à la question « sexe »
avec les réponses à la question « loisirs », on pourra facilement déterminer les passe-temps
favoris des femmes et mettre en évidence ceux des hommes.
C. Objectifs
Mon intervention consistait d’abord à réaliser une étude comparative des solutions existantes du
Reporting. Je devais pour ça analyser de plus prés les deux solutions proposées par mon coach
technique à savoir SQL Server 2005 Reporting Services et Business Objects Crystal Report XI. Je
devais d’abord effectuer une étude comparative entre les deux solutions en cherchant la possibilité
de leur intégration dans les différentes applications de HyperObjects en général puis d’une manière
plus spéciale au cas eQ.
41

48. eQ Services
Une fois décidé, il fallait toujours depuis un environnement .NET offrir via des services Web la
possibilité à la version actuelle en ASP du eQ d’exploiter les rapports générés de la solution
adoptée.
D. Enjeux du module eQ Reporting Services
Vu que le Reporting est l’initial et l’ultime objectif d’un quelconque questionnaire, ce module doit
donc assurer une performance irréprochable aux utilisateurs, sans trop surcharger le serveur
hébergeant eQ ni peser lourd sur la trésorerie financière de HyperObjects.
La priorité du format d’export des rapports a été donnée au format PDF. En fait le PDF (Portable
Document Format) certes créé par Adobe, mais reste un format ouvert dont les spécifications sont
publiques et utilisables librement.
Les rapports générés seront donc plus compacts et surtout exploitables gratuitement (par le biais
d’Acrobat Reader) pour les utilisateurs n’ayant pas des licences Microsoft Word.
E. Étude des outils existants
1. Business Objects Crystal Report XI
a) Introduction
Crystal Report est un outil de Reporting développé au début par la société Crystal Decisons puis
racheté par le géant Business Objects. Il permet de filtrer, grouper et publier de manière conviviale
et pertinente les données issues d’une base de données. Les fonctions Crystal Reports peuvent être
intégrées dans les applications Java, .NET et COM, et déployées sous Windows, UNIX et Linux.
b) Fonctionnalités
Crystal Report est optimisé pour donner une vision absolue de l’activité des entreprises en :
• Créant des rapports avancés au formatage très complexe avec une grande richesse de
l'information contenue.
• Consultant les données et les formater sous forme d'informations dynamiques.
• Intégrant des éléments interactifs dans les rapports.
• Gérant les rapports et les publier sur le Web avec Business Objects Enterprise
Les rapports peuvent contenir des éléments interactifs : le même rapport peut ainsi s'adapter aux
besoins des différents utilisateurs. Les utilisateurs peuvent analyser ou éditer les informations en
passant instantanément d'une lecture statique à une analyse interactive. Ils peuvent également
consulter ces informations sur différents portails Web. Les rapports peuvent être intégrés (en
totalité ou en partie) et partagés en toute sécurité dans des documents Microsoft Office au format
Word, PowerPoint ou Excel.
42