eQ Services

                     Projet de Fin d’Études
                     pour l’obtention du titre d’Ingénieur d’Etat...
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...
eQ Services


II. Remerciements


Le travail présenté dans ce mémoire a été effectué pour le compte de la SSII française
H...
eQ Services


III. Table des matières
I.      Dédicace
II.     Remerciements
III.    Table des matières
IV.     Liste des ...
eQ Services

                 e) Web Services Description Language................................................. 29
   ...
eQ Services


IV. Liste des figures et des tableaux
Figure   1 : Démarche non agile de gestion de projets ...................
eQ Services


V. Introduction
Après la centralisation de l’information en ligne et le phénomène du commerce électronique, ...
eQ Services

De la création personnalisée des questions à l’analyse avancée des résultats en passant par la
diffusion et l...
eQ Services


VI. Sujet de stage
Le sujet initial du stage a été décrit de la manière suivante : Adjonction de nouveaux mo...
eQ Services

•   Créer des modules en C# et ASP.NET 2.0 et des démonstrations de clients ASP consommateurs
    en respecta...
eQ Services


VII.          Analyse de l’existant
A. Organisation
HyperObjects est une SSII (Société de Services en Ingéni...
eQ Services

Questionnaire», qui est en charge de l’application portant son nom, se compose d’une seule
personne. Il peut ...
eQ Services


  Architecture                                      client/serveur (Web)

  Stockage des questionnaires     ...
eQ Services


        E. Planning prévisionnel
                                           mars       avril        mai     ...
eQ Services


VIII.          Méthodologies de travail
1. Introduction
Mon stage a démarré par une phase d'exploration volo...
eQ Services

Mais puisque le changement est une composante incontournable de tout projet de développement
logiciel, pourqu...
eQ Services

3. eXtreme Programming en détails
a) La naissance
On doit XP particulièrement à Kent Beck, un consultant et u...
eQ Services

défauts dans la mécanique existante, mais elle peut jamais avoir l’impression de revenir en arrière
ou de per...
eQ Services

•   Tests Unitaires (Unit Tests) : Tests automatisés écrits pour chaque classe, chaque méthode, et
    pour t...
eQ Services


IX. eQ Charting Services
A. Introduction
Ce chapitre a pour but de fournir un aperçu général sur le fonction...
eQ Services


C. Architecture

1. Architecture générale
 Source de
données XML
<?xml…
 <Report…        Importation        ...
eQ Services

premier temps, c'était temporairement un fichier XML accessible via un URL, après on a plutôt
adopté un flux ...
eQ Services



                                 Question Id


                              Chercher la question




     ...
eQ Services

Exemples de mapping entre le XML hiérarchique et la DataView tabulaire:


1- Pour le cas d’une question simpl...
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 d...
eQ Services

c) eQDDG Engine
Le moteur eQ Générateur Dynamique de Diagrammes est un rassemblement d'une vingtaine de
class...
eQ Services

Tôt ou tard, des changements s'imposeront sur certaines parties du code et chacune de ces
modifications oblig...
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...
eQ Services




                         Figure 11 : Modèle objet du eQGDD Engine

On peut par exemple voir de plus près l...
eQ Services




                     Figure 12 : Aperçu sur l’utilisation de l’abstraction



La classe principale est la ...
eQ Services

traitement des méthodes GetChartImagePath() et GetChartStream() est le même quelque soit la
diagramme, c'est ...
eQ Services




                Figure 13 : Aperçu sur un fragment du fichier de paramétrage
e) Conclusion
Le eQ Générateu...
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 ...
eQ Services

Les services Web implémentent la logique métier rendue consommable par l'utilisation de
standards (majoritair...
eQ Services

Les architectures SOA ont été popularisées avec l'apparition des services Web dans l'e-commerce
(B2B ou B2C) ...
eQ Services

L’objectif du WSDL peut être résumé comme suit:


                                     Quoi et Comment ?


  ...
eQ Services

                Figure 16 : Aperçu sur le fichier WSDL du eQ Charting Services


Côté client, une classe nomm...
eQ Services

SOAP a été initialement défini par Microsoft et IBM, mais est devenu depuis une recommandation
du W3C et util...
eQ Services

                    ...
                    </faultstring>
                    <detail/>
             </soap:...
eQ Services

h) Utilisation des services Web avec ASP
Le fait que SOAP repose sur des technologies normalisées à savoir HT...
eQ Services

consommateur est capable de créer à partir du néant une structure XML valide de l'enveloppe SOAP
et qu'il a u...
eQ Services

Alors que la version 4.5 en ASP ne permet que de changer le type du graphe :




                 Figure 25 :...
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’alle...
eQ Services




                             Figure 27 : Résultat du service Web


Le eQGDD est tout à fait extensible à f...
eQ Services




Cylinder Bar Chart 3D




Stack Bar Chart 3D




Column Chart 3D




                                     ...
eQ Services




Doughnut Chart 3D




Line Chart 3D




Area Chart 3D




                    Tableau 3 : Exemple de diagr...
eQ Services


X. eQ Reporting Services
A. Introduction
Alors que le domaine de l’aide à la décision est en pleine explosio...
eQ Services

Une fois décidé, il fallait toujours depuis un environnement .NET offrir via des services Web la
possibilité ...
eQ Services

c) Architecture
Lors de la demande de l’affichage d a
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
eQ Services PFE
Prochain SlideShare
Chargement dans…5
×

eQ Services PFE

2 619 vues

Publié le

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

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 619
Sur SlideShare
0
Issues des intégrations
0
Intégrations
34
Actions
Partages
0
Téléchargements
172
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

eQ Services PFE

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 45. eQ Services Cylinder Bar Chart 3D Stack Bar Chart 3D Column Chart 3D 39
  46. 46. eQ Services Doughnut Chart 3D Line Chart 3D Area Chart 3D Tableau 3 : Exemple de diagrammes générés 40
  47. 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. 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
  49. 49. eQ Services c) Architecture Lors de la demande de l’affichage d a

×