Développement et intégration des techniques de Data Mining pour une plateforme de coopération

Transcription

1 Ecole Nationale d Ingénieurs de Tunis Département TIC Université El MANAR II Développement et intégration des techniques de Data Mining pour une plateforme de coopération MEMOIRE DE PROJET DE FIN D ETUDES Pour l obtention du Diplôme d Ingénieur en Informatique Elaboré par Khaled Gaaloul Equipe de recherche : ECOO LORIA Responsable de l équipe : Prof. Claude Godart Encadreurs : Prof. Assistant François Charoy Prof. Noureddine Ellouze Année Universitaire : 2003/2004 Laboratoire Lorrain de Recherche en Informatique et ses Applications UMR 7503

2 0 Rapport de projet de fin d'études Mars - Juin 2004 Page 2

3 0 Je dédie ce travail à mes parents qui m'ont soutenu tout au long de mes études et auxquels tout revient, à mes frères et à ma sœur qui m'ont toujours encouragé. Rapport de projet de fin d'études Mars - Juin 2004 Page 3

4 0 Remerciement C'est un grand plaisir pour moi autant qu'un devoir de remercier toutes les personnes qui ont contribué, de près ou de loin, à la réalisation de ce stage. Je tiens d'abord à remercier vivement M. Claude GODART, responsable du projet ECOO, pour l'opportunité qu'il m'a offerte en m'accueillant au sein de son équipe. Je tiens à remercier aussi M. Francois CHAROY, mon encadrant, pour ses conseils et son soutien tout au long du stage. Mes vifs remerciements vont aussi à M. Walid GAALOUL, mon encadrant technique, qui m'a offert l'occasion de le solliciter pour ses compétences et sa large expérience et avec qui ce fut un plaisir de collaborer. J'exprime ma reconnaissance et mon respect envers tous les enseignants de l Ecole Nationale d Ingénieurs de Tunis dont j'ai été honoré par leur soutien et leur investissement personnel tout particulièrement M. Noureddine ELLOUZE et Mme Rahma BENAYED. Mes remerciements s'adressent aussi à tous les membres de l'équipe ECOO en particulier M. Sami BHIRI et M. Adnène GUABTNI pour l amabilité avec laquelle ils m ont intégré dans leur équipe. Finalement j'exprime ma grande reconnaissance à mes amis Abdelhalim LARHLIMI, Nizar Messai et Mohamed El Habib pour m'avoir accueilli et facilité mon intégration aussi bien dans l'environnement du travail qu'ailleurs. Khaled GAALOUL Rapport de projet de fin d'études Mars - Juin 2004 Page 4

5 0 Résumé Actuellement le développement d applications et de modèles coopératifs fait l'objet de nombreux travaux de recherche. Certes, plusieurs solutions existantes notamment les workflows permettent la coopération mais souvent leurs modèles utilisés restent classiques et manquent d automatisme et de performance. Afin d y remédier, nous allons utiliser les techniques de fouille de données généralement appelée Data Mining pour extraire des modèles de workflow qui soient en harmonie avec le souhait de l utilisateur. En effet, les techniques de Data Mining construisent ledit modèle de manière automatique et apportent ainsi un gain énorme tant en performance qu'en maniabilité ou en temps de travail. L'objectif de mon stage est de mettre en œuvre un outil pour la collecte de traces d exécution greffé au système de gestion de workflow BONITA. Cet outil va générer ainsi un fichier log qui va contenir des informations se rapportant aux événements qui ont eu lieu lors d instanciation de workflow dans BONITA. Ceci va assurer par la suite l établissement de statistiques nécessaires pour l approche du workflow mining adoptée. MOTS CLÉS : système flexible de workflow BONITA, Data Mining, plate-forme J2EE, API JMS, Parser XML. Abstract Currently, the development of cooperation models is the subject of many advanced researches. Although cooperative solutions already exists, but in the major cases, their models still using classical methods leading to the waste of performance and automatism. In order to remedy with this problems, the Data Mining techniques will be used which allow the extraction of models that are in accordance with the user wish. In fact, data mining offers techniques to build an automatic model that carry out a new performance and save working time. The goal of my training course is to build and implement a tool for the collect of execution traces of the WFMS BONITA. This tool allows the generation of a workflow log that contains information about events taking place. Thanks to this workflow log we will make statistics necessary for the workflow mining approach. KEYWORDS: flexible workflow system BONITA, data mining, J2EE Platform, JMS API for the execution collects, XML Parser. Rapport de projet de fin d'études Mars - Juin 2004 Page 5

6 0 ملخ ص تسع عد د من األبحاث ف م اد ن متعد دة إلى ترس خ عمل ة الت رابط و الت عاون ب ن أنظمة متباعدة و حت ى داخل نظام متعد د الوحدات. تتمث ل هذه العمل ة ف الق ام بتشغ ل األنظمة المذكورة و ا ستغالل الن تائج المتحص ل عل ها. نكه تبقى انعمهي ت غير فع انت بحيث تكون انن تائج انمتحص م عهيها بعيدة عه انمأمول. لهذا سنقوم ف عملنا هذا بترس خ ق م و مبادئ جد دة ف م دان الن ظام الت عاون. نطلق على هذه الفكرة ا سم البحث المعلومات الذ ي س خو ل لنا الحصول على الن تائج المرجو ة. ترتكز هذه العمل ة على ا لتقاط جم ع األحداث ال ت ستحصل وسط نظام عمل تعاون طلق عل ه تم ف ما بعد ا ستخراج هذه األحداث عن طر ق ملف ات مستحدثة للغرض كون له دالالت على ا حصائ ات تابعة لنظامنا بون تا ثم بواسطة نظام تصف ة مع ن سنتحص ل على المعط ات الت ستساعدنا ا ستخراج أشكال و نماذج كاملة و متكاملة مع نظامنا الت عاون بون تا ف هذه الحالة. Rapport de projet de fin d'études Mars - Juin 2004 Page 6

7 0 Table des matières CHAPITRE 1 : INTRODUCTION GENERALE CONTEXTE DU STAGE ENVIRONNEMENT DU STAGE Présentation générale du laboratoire LORIA Présentation de l'équipe ECOO PRESENTATION DU SUJET ORGANISATION DU RAPPORT CHAPITRE 2 : ETAT DE L ART INTRODUCTION PROCEDES D ENTREPRISES ET COOPERATION Besoin de coopération Procédés d entreprises et outils de travail coopératif Les workflows comme outil de coopération BONITA : UN WORKFLOW COOPERATIF Problématique Environnement logiciel de BONITA DATA MINING Limites des statistiques L'avantage de data mining CONCLUSION CHAPITRE 3 : CAHIER DES CHARGES INTRODUCTION PROBLEMATIQUE DEFINITION DES BESOINS Besoins fonctionnels Besoins non fonctionnels CONCLUSION CHAPITRE 4 : CONCEPTION GLOBALE INTRODUCTION ETUDE DE L EXISTANT Présentation de BONITA Architrecture de BONITA PRESENTATION DU CONTENU Installation de Bonita v Conception de l outil de collecte de traces Développement d un parseur XML pour les traces d exécution CONCLUSION CHAPITRE 5 : CHOIX TECHNOLOGIQUES INTRODUCTION LES CHOIX TECHNIQUES Choix du langage La plate-forme J2EE Le choix de l API pour l échange de messages Le serveur d application JOnAS Présentation de la technologie XML Le choix du parseur XML Rapport de projet de fin d'études Mars - Juin 2004 Page 7

8 0 5.3 CONFIGURATION LOGICIELLE Cygwin Utilisation de l'outil ANT CONFIGURATION MATERIELLE CONCLUSION CHAPITRE 6 : MISE EN ŒUVRE INTRODUCTION PLANIFICATION DEPLOIEMENT Outil de collecte de traces d exécution Le parseur XML CONCLUSION CHAPITRE 7 : TESTS ET VALIDATIONS INTRODUCTION LANCEMENT DE "PROCESSMODEL" CREATION DE "SUBSCRIPTION" ETABLISSEMENT DES STATISTIQUES POUR L APPROCHE DU WORKFLOW MINING CONCLUSION CONCLUSION ET PERSPECTIVES BIBLIOGRAPHIE Rapport de projet de fin d'études Mars - Juin 2004 Page 8

9 0 Table des illustrations FIGURE 1: TREFLE FONCTIONNEL D'UN COLLECTICIEL FIGURE 2 : MODELE STATIQUE VS MODELE COOPERATIF FIGURE 3 : ARCHITECTURE D'UNE APPLICATION J2EE FIGURE 4 : STATISTIQUES ET DATA MINING FIGURE 5 : ARCHITECTURE DE BONITA FIGURE 6 : EXECUTION D'ACTIVITES DANS UN PROJET WORKFLOW FIGURE 7 : OUTIL DE COLLECTE DE TRACES GREFFE A BONITA FIGURE 8 : FICHIER XML DE LA COLLECTE DE TRACES D'EXECUTION FIGURE 9 : PARSEUR XML JDOM FIGURE 10 : API JMS DANS LA PLATE-FORME J2EE FIGURE 11 : ARCHITECTURE DE JONAS FIGURE 12 : DEROULEMENT DE LA COLLECTE DE TRACES D'EXECUTION FIGURE 13 : STRUCTURE D'UN SINGLETON FIGURE 14 : EXEMPLE D UN FICHIER XML FIGURE 15 : DIAGRAMME UML DU PARSEUR XML FIGURE 16 : LANCEMENT DE PROCESS-MODEL FIGURE 17 : FICHIER LOG DU PROJET E-CITIZEN DE PROCESS-MODEL FIGURE 18 : CREATION ET EXECUTION DU PROJET SUBSCRIPTION FIGURE 19 : FICHIER LOG DU PROJET SUBSCRIPTION FIGURE 20 : STATISTIQUES SUR LES ACTIVITES DE E-CITIZEN ET SUBSCRIPTION Rapport de projet de fin d'études Mars - Juin 2004 Page 9

10 0 INTRODUCTION GENERALE 1.1 Contexte générale du stage 1.2 Environnement du stage 1.3 Présentation du sujet 1.4 Organisation du rapport Rapport de projet de fin d'études Mars - Juin 2004 Page 10

11 Chapitre 1 : Introduction générale Chapitre 1 : INTRODUCTION GENERALE 1.1 Contexte du stage Ce stage se situe dans le cadre du projet de fin d'études pour l'obtention du diplôme d'ingénieur en Informatique. Il est effectué dans le laboratoire de recherche INRIA Lorraine LORIA, au sein de l'équipe ECOO et sous la direction du Département TIC de l Ecole Nationale d Ingénieurs de Tunis. Dans ce qui suit nous présentons l'environnement du stage (laboratoire et équipe), le sujet à traiter et l'organisation du rapport. 1.2 Environnement du stage Présentation générale du laboratoire LORIA Le LORIA, Laboratoire Lorrain de Recherche en Informatique et ses Applications, est une unité mixte de recherche commune aux organismes suivants [LOR] : - CNRS, Centre National de la Recherche Scientifique - INRIA, Institut National de Recherche en Informatique et en Automatique - INPL, Institut National Polytechnique de Lorraine - Université Henri Poincaré - Université Nancy 1 - Université Nancy 2 Le LORIA poursuit des activités de recherche selon les thématiques suivantes [LOR] : - Calculs, réseaux et graphismes à hautes performances - Télé-opérations et assistant intelligents - Ingénierie des langues, du document et de l'information scientifique et technique - Qualité et sûreté des logiciels et systèmes informatiques - Bio informatique et applications à la gnomique Présentation de l'équipe ECOO L'équipe de recherche ECOO (Environnements pour la COOpération) a pour objectif de concevoir et de réaliser des services de base pour le développement d'applications coopératives. Elle s'intéresse plus particulièrement à la coopération par partage d'objets dans les applications interactives (co-conception, génie-logiciel, édition coopérative, workflow,...) distribués sur un réseau à large échelle par exemple le Web. Rapport de projet de fin d'études Mars - Juin 2004 Page 11

12 Chapitre 1 : Introduction générale Les axes de recherches de l'équipe ECOO sont : - Étude des concepts de base de la coopération et définition de modèles de coopération: L'objectif est de mettre en évidence des briques de base de la coopération par l'analyse des usages courants et de les intégrer dans un formalisme commun pour pouvoir les composer. - Définition d un modèle d espace pour activités coopérantes distribuées : L objectif est de définir un support adaptable permettant une gestion efficace de la distribution et du partage d'objets, et permettant à des usagers possédant une faible infrastructure informatique de s'interconnecter tout en conservant leurs habitudes et leurs outils. - Développement d'une activité transversale sur le thème de la conception et programmation objet. 1.3 Présentation du sujet Les technologies de l'information et de la communication peuvent servir de levier pour améliorer l'analyse de l'environnement et la communication entre des partenaires d'une équipe et la coordination des activités au sein d'une entreprise ou entre des entreprises. En effet, l'essor des outils de travail coopératif a bien servi à augmenter l'efficacité et la qualité du travail en organisant les apports collectifs des organisations de travail. Afin d'assurer les besoins de coopération émergeants, les outils de coopération étaient amenés à garantir un niveau considérable de portabilité, de réutilisabilité et de support de l'hétérogénéité des différents agents de coordination et de coopération. Les systèmes de workflow proposent la solution la plus adaptée. En effet, ils permettent d intégrer la dimension coopérative du travail tout en prenant en compte les interactions et les engagements que l on peut trouver dans un processus [WfM00]. Mais face à la mutation des marchés, les entreprises doivent être de plus en plus réactives pour obtenir la satisfaction du client qui se trouve maintenant placée au centre de leurs préoccupations. Si une organisation en processus est considérée comme une solution très prometteuse, il s avère pourtant que sa mise en œuvre n a abouti le plus souvent qu à une simple automatisation des processus [Sha01]. Le workflow mining offre des techniques qui permettent de réaliser des modèles compacts et réactifs de workflow. En effet, ces techniques modélisent automatiquement ledit modèle en se basant sur les données extraites lors de l exécution d un workflow. Ainsi elles apportent, d une part, un gain énorme tant en performance qu'en maniabilité ou en temps de travail et d autre part elles répondront aux attentes de ses utilisateurs [PMSI97]. Rapport de projet de fin d'études Mars - Juin 2004 Page 12

13 Chapitre 1 : Introduction générale Le but du stage est de mettre en œuvre un outil pour la collecte de traces d exécution greffé au système de gestion de workflow BONITA tout en respectant ses spécifications ainsi que ses pré requis. Cet outil va générer ainsi un fichier log qui va contenir des informations se rapportant aux événements qui ont eu lieu lors d instanciation et d exécution de workflows. Ceci va assurer par la suite le log de données nécessaires à l établissement de statistiques utilisées ou formulées pour l approche du workflow mining adoptée. 1.4 Organisation du rapport Synthétisant notre travail, le plan du présent rapport est inspiré du cycle de développement du produit réalisé. Il est constitué de six chapitres. Nous commencerons par un bref état de l art (cf. chapitre 2) sur la coopération et les procédés d entreprises, les outils de coopération, les systèmes de workflows coopératifs et la plate-forme de développement du moteur de workflow. Ensuite, le troisième chapitre explicitera en détails le cahier des charges, c est à dire toutes les exigences et la majorité des fonctionnalités que doit supporter le produit. Par la suite nous analyserons le cahier des charges pour aboutir à une conception globale récapitulant de manière plus formelle les différents aspects du projet (cf. chapitre 4). Avant d'expliciter en détails le travail réalisé et les défis techniques relevés (cf. chapitre 6 ), nous consacrerons le cinquième chapitre à la présentation des technologies, des outils utilisés et des choix technologiques adoptés. Enfin, avant de conclure, nous procéderons à des tests d'exécution et de validation du travail effectué (cf. chapitre 7 ). Rapport de projet de fin d'études Mars - Juin 2004 Page 13

14 Chapitre 1 : Introduction générale ETAT DE L ART 2.1 Introduction 2.2 Procédés générale d entreprises et coopération 2.3 Bonita un workflow coopératif 2.4 Data Mining 2.5 Conclusion Rapport de projet de fin d'études Mars - Juin 2004 Page 14

15 Chapitre 2 : Etat de l art Chapitre 2 : ETAT DE L ART 2.1 Introduction Dans ce chapitre nous commençons par une brève présentation des besoins de coopération. Ensuite nous présentons les types d'outils de travail coopératif existants, notamment les systèmes de workflows. Dans ce même contexte, nous présentons le Système Flexible de Workflow Coopératif BONITA adapté aux applications de type co-conception et co-ingénierie et proposé par l'équipe ECOO (Environnements pour la Coopération). Et pour finir, nous allons faire une présentation introductive au data mining qui sera utilisé comme outil d aide à la conception et la modélisation des patrons de workflows. 2.2 Procédés d entreprises et coopération Besoin de coopération Parmi les effets de la mondialisation, une vague effervescente de phénomènes économiques a vu le jour (e.g. les fusions de groupes financiers et industriels, l'extension à l'international des structures des entreprises, l'externalisation intensive de services, l'utilisation des outils de la nouvelle économie, etc.). Entre autres, cette métamorphose économique a eu des conséquences technologiques considérables. En effet, elle ne peut pas se réaliser sans la mise en oeuvre et le déploiement de concepts et d'outils technologiques nouveaux. En particulier, sans ces outils technologiques, les entreprises ne pourront pas opérer un passage à l'échelle mondiale avec des systèmes d'information qui ont été préalablement conçus pour des besoins internes [Baï03]. Afin de pouvoir mieux s'ouvrir les unes vers les autres, les entreprises ont donc exprimé un besoin énorme en mécanismes supportant l'interconnexion et la coopération de leurs applications en général et de leurs procédés métiers en particulier. En effet, l'automatisation des procédés d'entreprises devenant de plus en plus répandue (e.g. en gestion de la chaîne de production, en gestion de la chaîne logistique, en gestion de la relation client, etc.), l'interconnexion et la coopération de ces procédés s'avèrent incontournables en deçà et au-delà des frontières des organisations [Baï03]. Mais face à la mutation des marchés, les entreprises doivent être de plus en plus réactives pour obtenir la satisfaction du client qui se trouve maintenant placée au centre de leurs préoccupations. Ainsi les techniques de Data Mining vont offrir des outils facilitant la conception Rapport de projet de fin d'études Mars - Juin 2004 Page 15

16 Chapitre 2 : Etat de l art et la modélisation des applications intra et inter entreprises. Notre but est d'intégrer ces techniques au sein de notre système de workflow coopératif BONITA qui en était dépourvu Procédés d entreprises et outils de travail coopératif En voyant le fait que l'automatisation des procédés d'entreprises est devenue trés répandue, il s est avèré alors que l'interconnexion et la coopération de ces procédés soient incontournables en deçà et au-delà. En effet, un procédé entreprise est un Workflow composé de plusieurs activités implantées par l entreprise elle même ou par plusieurs entreprises. Par suite la coopération des entreprises est encapsulée dans la définition même des procédés. En effet, pour la réalisation d'un procédé inter ou intra entreprises, les entreprises ou départements d'entreprises sont amenées à coopérer et à agir ensemble. Pour assurer cette coopération [Rub03] il existe des outils dont le domaine est le travail coopératif. Ils comprennent les diverses plates-formes, tant matérielles que logicielles permettant à un certain nombre de personnes de travailler en groupe. Ainsi les applications CSCW (Computer-Supported Cooperative Work) offrent à un groupe d'utilisateurs distants ou non, l'opportunité de travailler et de communiquer dans un même espace virtuel. Ils vont contribuer à la réalisation de tâches communes de manière synchrone ou asynchrone. Les applications CSCW permettent la réalisation de travaux tels la conception d'un projet commun ou encore la coédition d'un document. Ainsi, le CSCW est une discipline rassemblant différents domaines de recherche sur la même idée de l'importance de la coopération. C'est un environnement où chaque utilisateur est bien conscient de son appartenance à une communauté. Les systèmes de travail coopératif encore appelés collecticiels ou groupware, peuvent être représentés par un trèfle fonctionnel, comprenant trois espaces : Les espaces de production, de coordination et de coopération (voir figure 2.1)[Rub03]. L'espace de production comprend tous les objets qui résultent d'une activité de groupe (e.g. logiciels), ainsi que les référentiels communs entre agents coopérants (e.g. Espace de coédition de documents), mais aussi l'espace privé de chaque utilisateur du système (e.g. Espace de fichiers privatifs). Cet espace décrit le côté statique du système. L'espace de coordination regroupe les acteurs, les groupes, les rôles et les tâches, ainsi que les acteurs responsables des activités et des tâches. De plus, cet espace introduit les relations temporelles entre ces différents éléments. Ces deux espaces présentent chacun un des aspects du système. Cet espace décrit la partie dynamique du système. Rapport de projet de fin d'études Mars - Juin 2004 Page 16

17 Chapitre 2 : Etat de l art L'espace de communication offrira aux acteurs du collecticiel la possibilité d'échanger de l'information. La sémantique de l'information échangée n'est pas perceptible par le système, qui ne joue que le rôle de simple messager, elle ne concerne que les acteurs communicants. La communication entre acteurs pourra être de deux types: synchrone (e.g. chat, visioconférence) ou asynchrone (e.g. forum, ). Figure 1: Trèfle fonctionnel d'un collecticiel Selon les collecticiels, les trois facettes (production, coordination et communication) n'ont pas la même importance. L'importance est mise sur l'une des facettes, selon le système concerné. Les systèmes de coédition de documents mettent l'accent sur les services de production, les systèmes de gestion de procédés (ou de tâches workflow) insistent sur la coordination et enfin les médiaspaces (espaces de média) sur la communication Les workflows comme outil de coopération Le workflow est un concept qui associe des technologies et outils capables d'acheminer automatiquement des événements et des tâches à des programmes ou des utilisateurs. C'est une solution logicielle permettant l'exécution des enchaînements d'activités sans avoir d'expérience en Rapport de projet de fin d'études Mars - Juin 2004 Page 17

18 Chapitre 2 : Etat de l art la matière (e.g. authentification et gestion des utilisateurs, notification des tâches par messagerie électronique, modification dynamique de l'instance d'un processus en cours, etc.). à : Les workflows font parti des systèmes de gestion de procédés. Ils servent essentiellement décrire explicitement la méthode de travail, pouvoir réutiliser une méthode élaborée précédemment, mesurer la qualité du travail effectué (e.g. temps, coûts, etc.), accélérer les procédés d'entreprises, à intégrer les procédés à travers les départements, les applications et les frontières du système, avoir les vues ponctuelles et globales du système, automatiser les tâches spécifiques, assurer la conscience du groupe, la coordination entre partenaires dans le cadre d'un projet coopératif. Le workflow comporte un certain nombre d'étapes logiques, nommées activités. Une activité peut impliquer l'interaction manuelle d'un utilisateur ou d'un participant au workflow, comme elle peut être exécutée en utilisant des ressources de machine[wfm00]. L établissement d un workflow se compose de trois phases : 1. La phase d analyse : conception et définition du procédé ; 2. La phase de définition du procédé : conception et formalisation des procédés avec la définition des conditions nécessaires pour le bon fonctionnement et l intégration ; 3. La phase d exécution : traitement des tâches et interaction avec les utilisateurs et les applications. Enfin, on distingue dans les applications de workflow classiquement quatre catégories : 1. Le workflow de production, qui correspond à la gestion des processus de base de l entreprise. Les procédures supportent peu de changements dans le temps, et les transactions sont répétitives. On peut y trouver par exemple la production de contrats d assurance, la gestion de litiges, la gestion de réclamations clients, etc. 2. Le workflow administratif, qui correspond à tout ce qui est routage de formulaires, basé en général sur une infrastructure de messagerie. 3. Le workflow ad-hoc pour la gestion des procédures non déterminées, ou mouvantes. Rapport de projet de fin d'études Mars - Juin 2004 Page 18

19 Chapitre 2 : Etat de l art 4. Le workflow coopératif, gérant des procédures évoluant assez fréquemment, et liées à un groupe de travail restreint dans l entreprise. Nous allons nous intéreser dans la suite au système de workflow coopératif Bonita [Bon04]. 2.3 Bonita : un workflow coopératif Problématique Les modèles de workflows classiques ont été conçus pour enchaîner des boîtes noires interagissant uniquement en début et en fin d'exécution. Si cela est suffisant pour des activités répétitives, de type administration ou production, cela ne l'est plus pour les activités créatives. En effet, les modèles restent trop rigides à cause des inadaptations à supporter les interactions coopératives, des dépendances entre activités du type fin-démarrage et des exécutions strictement séquentielles [Val01]. Les modèles de workflows coopératifs Ils offrent plus de flexibilité lors de l exécution, c est à dire la possibilité pour les tâches coordonnées d'interagir en cours d'exécution. En effet, les tâches possèdent des dépendances mutuelles pour communiquer entre elles, ce qui assure la coopération lors de leurs exécutions (cf. fig.2). Procédé Edition Revue Modification... Exécution 1)Modèle statique Edition Revu e Modificatio n 2)Modèle coopératif Edition Revu e Modificatio n Anticipable Anticipating Executing Figure 2 : Modèle statique Vs Modèle coopératif Rapport de projet de fin d'études Mars - Juin 2004 Page 19

20 Chapitre 2 : Etat de l art Environnement logiciel de BONITA Bonita est un système de Worflow coopératif conçu pour indiquer, exécuter, surveiller et coordonner les flux d organismes du travail. L originalité de Bonita réside dans un moteur d'exécution qui est basé sur le nouveau modèle d'anticipation d'activité proposé par l'équipe ECOO. Notre système se compose de deux composants. Le premier est celui du composant de modélisation BONITA qui assurent la modélisation ainsi que la visualisation de processus de workflow. Le deuxième composant est responsable de la phase d exécution, il est chargé de La gestion des données flexible permettant aux activités de permuter des données d'une manière optimum. Une description plus détaillée sera faite dans le chapitre de la conception globale. Le développement du moteur de workflow BONITA est centré sur la plate-forme J2EE (JavaTM 2 Platform, Enterprise Edition). J2EE [Cas02] est un ensemble d'apis dédiées au développement d'applications d'entreprise (cf. figure 3). Certaines de ces APIs sont incluses dans Java 2 Standard Edition (la version "standard" de Java), comme par exemple JDBC (pour Java DataBase Connectivity, dont le package est java.sql) ou encore RMI (pour Remote Methods Invocation, dont le package est java.rmi). D'autres ne sont pas distribuées avec le JDK ou JRE standard mais avec le SDK J2EE. C'est le cas par exemple des EJBs (pour Enterprise Java Beans). Figure 3 : Architecture d'une application J2EE Rapport de projet de fin d'études Mars - Juin 2004 Page 20

21 Chapitre 2 : Etat de l art Cette plate-forme inclue : un modèle de programmation (application multi-tiers, client légers), une plate-forme (ensemble de spécifications et de politiques requises), un ensemble de test de compatibilité, une implantation de référence, des différents services tels que les connexions aux bases de données, la messagerie, les transactions, etc. Le système de workflow coopératif Bonita sera notre outil de travail. En effet, le développement de l outil de collecte de traces d exécution d un projet workflow ainsi que l outil de filtrage seront greffés et testés sur Bonita. 2.4 Data mining Le data mining est le descendant et, selon certains, le successeur des statistiques telles qu'elles sont pratiquées actuellement. Statistiques et data mining ont le même but celui de réaliser des «modèles» compacts et compréhensibles rendant compte des relations liant la description d'une situation à un résultat (ou un jugement) concernant cette description. L'hypothèse implicite est bien sûr que le résultat, la mesure ou le jugement que nous essayons de modéliser dépend effectivement des éléments de description que nous avons Limites des statistiques Même si l approche statistique fonctionne bien pour un certain nombre de problèmes, cependant, elle n'est pas universelle. En effet, plusieurs problèmes se posent, tels que: L'abondance de données est telle que personne n'aura jamais le temps de les examiner «à la main». Il y a trop de problèmes à modéliser. Par exemple, dans le cas d'un produit nouveau, aucune l'expérience nécessaire n'existe pas pour formuler des hypothèses de dépendances a priori comme le requiert un travail statistique classique. Les problèmes sont trop complexes. Beaucoup de grandeurs reliées aux données (place de stockage, temps d'accès) augmentent plus vite que la quantité de données elles-mêmes. De plus, comme seules quelques variables sont pertinentes pour un problème donné, la plupart sont «inutiles» (mais peuvent être cruciales pour un autre problème). Les problèmes ne sont pas toujours précisément définis. Rapport de projet de fin d'études Mars - Juin 2004 Page 21

22 Chapitre 2 : Etat de l art L'avantage de data mining La différence essentielle est que les techniques de data mining construisent ledit modèle de manière automatique alors que les techniques statistiques «classiques» requièrent d'être maniées et guidées par un statisticien professionnel, celui-ci ayant déjà une idée peut-être préconçue des «hypothèses de dépendance» à formuler. D autant plus que les techniques de data mining apportent un gain énorme tant en performance qu'en maniabilité ou en temps de travail. La possibilité de réaliser ses propres modèles statistiques par soi-même sans besoin de sous-traiter ou de se concerter avec un statisticien apporte une grande liberté aux utilisateurs opérationnels [PMSI97]. L'avantage de posséder un tel modèle est double : Le modèle est descriptif et explicatif : il éclaire la situation en «vous disant où regarder», quelles sont les variables descriptives qui sont importantes pour déterminer le résultat. Le modèle est prédictif : si vous êtes en face d'une situation nouvelle, décrites par les variables sur lesquelles vous avez basé votre modèle, vous pouvez «faire tourner» le modèle sur ces variables pour obtenir une estimation du résultat à attendre (cf. fig.4). En plus les techniques rassemblées sous le nom de data mining : permettent de construire des modèles rendant compte de la totalité des relations entre les données, sans simplification abusive. construisent ces modèles de manière automatique alors que les techniques statistiques «classiques» requièrent d'être maniées - et guidées - par un statisticien professionnel. grâce à une approche différente vis-à-vis des données, peuvent bâtir des modèles à partir de plusieurs millions d'exemples, ou au contraire de seulement quelques centaines. donnent un sens à tout un tas de données automatiquement générées (tickets de caisse, parcours de site Web; opérations bancaires, etc.) qui ne coûtent que la peine de les conserver. Ces données sont en trop gros volume pour pouvoir être examinées à la main, coûtent de l'argent à stocker et ne peuvent donc justifier leur utilité que si on peut en tirer quelque chose rapidement et sans trop d'effort [PMSI97]. La figure suivante illustre les apports de data mining par rapport à l approche statistiques lors de la manipulation d une source de données. Rapport de projet de fin d'études Mars - Juin 2004 Page 22

23 Chapitre 2 : Etat de l art Figure 4 : Statistiques et Data mining Cette figure illustre l apport de data mining. En effet, les résultats sont des modèles qui apportent une description plus riche à l utilisateur et lui permettent ainsi d avoir des modèles globaux et complets. 2.5 Conclusion Au milieu de ces outils de coopérations, des systèmes de workflow coopératif, de la plateforme de développement et des techniques de data mining l environnement du travail a été cerné. L étape qui en suit sera l analyse des besoins nécessaires pour une bonne conception de l application dont je suis demandé de faire (cf. chapitre 3). Rapport de projet de fin d'études Mars - Juin 2004 Page 23

24 Chapitre 2 : Etat de l art CAHIER DES CHARGES 3.1 Introduction 3.2 Problématique 3.3 Etude des besoins 3.4 Conclusion générale Rapport de projet de fin d'études Mars - Juin 2004 Page 24

25 Chapitre 3 : Cahier des charges Chapitre 3 : CAHIER DES CHARGES 3.1 Introduction Une analyse des besoins est nécessaire pour une bonne conception de l outil qui fera l objet de mon stage. Cette analyse doit être fidèle aux objectifs du projet. Ainsi l analyse du cahier des charges doit comporter la partie problématique qui expose le problème à résoudre associée à la partie étude des besoins qui dégage les différentes attentes de l utilisateur par rapport à cet outil. 3.2 Problématique La coopération fait l'objet de nombreuses recherches approfondies au sein de plusieurs laboratoires dans le monde. Certes, plusieurs solutions existantes notamment les workflows permettent la coopération mais souvent leurs modèles utilisés restent classiques et manquent d automatisme et de performance. Afin de remédier à ces carences et ainsi de modifier, maintenir, et améliorer le système, il est crucial de comprendre son comportement. Les workflows sont généralement basés sur des modèles explicites de processus qui ne répondent pas fidèlement aux besoins souhaités. Pour soutenir la modélisation et la conception de ces WFMS nous proposons d exploiter les techniques de Data Mining (fouille de données) pour extraire des modèles de workflow qui soient en harmonie avec le souhait de l utilisateur. En effet, les techniques de data mining construisent ledit modèle de manière automatique et apportent ainsi un gain énorme tant en performance qu'en maniabilité ou en temps de travail. Le workflow mining désignera par la suite l ensemble des techniques pour la découverte de modèles de workflows. Les logs vont contenir des informations sur des évènements (exécution d activités) qui ont eu lieu lors de l exécution d un scénario de workflow [Gaa04]. Le but du stage est de mettre en œuvre un outil pour la collecte de traces d exécution greffé au système de gestion de workflow BONITA tout en respectant ses spécifications ainsi que ses pré requis. Cet outil va générer ainsi un fichier log qui va contenir des informations se rapportant aux événements qui ont eu lieu lors d instanciation de workflow. Ceci va assurer par la suite l établissement de statistiques nécessaires pour l approche du workflow mining adoptée. 3.3 Définition des besoins A la suite d une étude minutieuse faite pour dégager les principales phases au déroulement de mon stage, il s est avéré nécessaire de modéliser les différentes étapes concernant l outil à Rapport de projet de fin d'études Mars - Juin 2004 Page 25

26 Chapitre 3 : Cahier des charges développer d une part et d autre part répondre aux différents besoins des utilisateurs à savoir l équipe ECOO. Ces besoins peuvent être classifiés suivant deux types. En premier lieu, les besoins fonctionnels qui consistent à dégager les différents modules à réaliser. En second lieu, les besoins non fonctionnels qui représentent les contraintes à imposer sur le produit Besoins fonctionnels Modules Spécification Période Etude et documentation sur les systèmes flexibles de workflow Etude de l architecture logicielle de BONITA et installation de la nouvelle version. Etude et documentation sur les API s JMS. Conception et développement de l API de collecte de trace. Réalisation de tests d exécution de l API greffée à BONITA. Conception et développement d un filtre pour les traces obtenues. Réalisation de tests de filtrage. Une vue d ensemble sur les WFMS (WorkFlow Management System), tels que leur classification, leurs rôles, etc. Etude et compréhension de l architecture logicielles de BONITA avec ses pré requis tels que le serveur d application, le moteur de workflow, etc. Installation de la dernière version Bonita v1.2. Compréhension de la structure d échange de messages sous JMS et manipulation de quelques exemples. Recherche des technologies et des outils à utiliser pour la conception. Puis, développement de l API JMS au sein de l architecture du WFMS BONITA. Lancement de BONITA et exécution de divers scénarios de workflows pour la collecte de traces d événements pour chaque instanciation de scénario avec possibilité de raffinement de code selon la collecte désirée. Etude de XML parsing et développement d un outil Parser pour le filtarge de données à partir de fichier log (collecte de traces). Exécution de l outil Parser XML et vérification des résultats par rapport au contrainte de l algorithme de workflow mining. Table 1 : Besoins Fonctionnels 1 semaine. 2 semaines. 1 semaine. 4 semaines. 1 semaine. 3 semaines. 2 semaines. La spécification sera plus détaillée dans le chapitre conception globale (cf. chapitre 4). Rapport de projet de fin d'études Mars - Juin 2004 Page 26

27 Chapitre 3 : Cahier des charges Besoins non fonctionnels Il s agit, en fait, des contraintes diverses à imposer sur le produit à réaliser et le processus de réalisation. Besoin sur le processus : Livraison : la date de livraison du produit a été fixée à mi-juin. Cette échéance sera en avance d une semaine de la fin de mon stage avec l équipe ECOO. Donc, il faut respecter le délai. Implémentation : Le langage utilisé pour l implémentation de cette application est le langage de programmation Java. Besoins sur le produit : En réalisant cette application, il faut prendre en considération la satisfaction du public cible. En effet la facilité avec laquelle ils exécutent leur requêtes ainsi que la présence de tous ce qu ils cherchent déterminent le pourcentage de réussite de cette application. De ce fait, il faut éviter les difficultés d utilisation ainsi que la complexité du résultat en assurant un outil simple à intégrer et à manipuler et qui soit efficace dans la phase du traitement de résultat. En effet, il faut opter pour une interface qui soit à la fois simple et explicite et qui assurera donc une bonne impression chez l utilisateur (cf. chapitre 4). 3.4 Conclusion Afin de bien mener mon projet à terme, il a fallu mettre en évidence les différents modules de développement tout en tenant compte des différentes contraintes entre chaque module. Car l expérience a toujours montré l intérêt que peut porter le fait de rendre un produit modulaire. Ainsi dans le chapitre qui suit, les choix conceptuels devront être respectés jusqu au bout de la réalisation, afin de disposer par la suite d une architecture rigoureuse et donc plus facile à faire évoluer. Rapport de projet de fin d'études Mars - Juin 2004 Page 27

28 Chapitre 3 : Cahier des charges CONCEPTION GLOBALE générale 4.1 Introduction 4.2 Etude de l existant 4.3 Présentation du contenu 4.4 Conclusion Rapport de projet de fin d'études Mars - Juin 2004 Page 28

29 Chapitre 4 : Conception Globale Chapitre 4 : CONCEPTION GLOBALE 4.1 Introduction Il s'agit de la phase opérationnelle de création de l'ouvrage. Elle est menée par la maîtrise d'œuvre, en relation avec la maîtrise d'ouvrage. Cette phase commence par la réception du cahier des charges où les spécifications des besoins fonctionnelles ont été réalisées. Elle se clôture par la livraison de l'ouvrage. En effet, la maîtrise d œuvre va assurer l évolution du produit ainsi que son exploitation (performance, disponibilité) pour aboutir au produit final (cf. chapitre 6). Dans ce qui suit, nous allons faire une étude de l existant qui porte sur l architecture logicielle de WFMS (WorkFlow Management System) Bonita. Puis, introduire le contenu de notre travail notamment les outils pour la collecte et le filtrage des traces d exécutions de scénarios de workflows. 4.2 Etude de l existant Cette partie consiste à étudier le traitement et la circulation des informations pour établir la liste des ressources. De ce fait il est important de ne pas être en contradiction avec des choix déjà existant de la plate-forme. Pour ce faire, il est important d analyser l existant de la plate-forme Présentation de BONITA Bonita est un système flexible de workflow coopératif, conforme aux caractéristiques de WfMC (Workflow managemenet Consortium), basées sur le modèle de workflow proposé par l'équipe ECOO, qui incorpore l'anticipation des activités comme un mécanisme plus flexible lors de l exécution de workflows. Bonita est un Open Source, elle est téléchargeable sous la license de LGPL (Lesser General Public License). Le système fournit : Un ensemble complet d'outils graphiques intégrés pour exécuter le processus défini, instantiatier et commander ce processus, et assurer une interaction entre les utilisateurs et d'autres applications. Un navigateur basé à 100% sur l environnement d'intégration de Web Services qui utilise le SOAP (Simple Object Access Protocol) et des technologies de XML pour encapsuler des workflows existants et les édite en tant que Web Services sous J2EE. Un moteur de Worflow de troisième génération basé dans le modèle d'anticipation d'activité. Cette flexibilité permet une augmentation considérable de vitesse des phases de conception et de développement des applications coopératives [Bon04]. Rapport de projet de fin d'études Mars - Juin 2004 Page 29

30 Chapitre 4 : Conception Globale Architrecture de BONITA Bonita est un système de Workflow coopératif conçu pour indiquer, exécuter, surveiller et coordonner les flux d organismes du travail. Le concept principal de ce système est le moteur d'exécution de Bonita qui est basé sur le nouveau modèle d'anticipation d'activité proposé par ECOO. Ce système se compose de deux composants. Le premier est celui du composant de modélisation BONITA qui assurent la modélisation ainsi que la visualisation de processus de workflow. Le deuxième composant est responsable de la phase d exécution, il est chargé de La gestion des données flexible permettant aux activités de permuter des données d'une manière optimum (cf. fig.5). Le développement du moteur de workflow est centré sur la plate-forlme J2EE qui est conforme au cahier des charges de JavaBeans 2.0 d'entreprise (EJB) qui fournit un environnement plus flexible et plus portatif pour des applications réparties [Bon04]. La figure suivante montre l'architecture de base de Bonita : Figure 5 : Architecture de Bonita Bonita intègre un grand nombre de services pour contrôler et simplifier beaucoup d'aspects coopératifs, tel que la mise en place de service de messages JMS pour nous informer lors de la définition et l'exécution d un processus de workflow. Chaque interaction entre l utilisateur et l application sera enregistrée dans le noyau de Bonita en tant qu évènement JMS. Rapport de projet de fin d'études Mars - Juin 2004 Page 30

31 Chapitre 4 : Conception Globale D après l architecture de Bonita, le navigateur côté client va reporter la liste des projets ayant été exécutés. Ces données restent toutes fois dépourvues de plusieurs détails qui demeurent important pour la découverte et l extraction de modèles de workflow dans Bonita. Pour cela, à l aide des services JMS déjà évoqués que notre travail se basera. 4.3 Présentation du contenu Grâce à l analyse du cahier de charges, une spécification des besoins fut dégagée. En effet, l application sera présentée suivant trois grandes entités tout en attachant une importance pour leur complémentarité. Ces entités sont : l étude de l architecture logicielle de Bonita et l installation de la nouvelle version, la conception de l outil de collecte de trace qui sera greffé au WFMS, et le développement d un filtre pour les traces d évènements. Après avoir extrait ces entités, il faudra passer à l identification et à la conception des fonctionnalités relatives à chacune d entre elles Installation de Bonita v1.2 Bonita est intégré dans le Consortium ObjectWeb (Open Source Middleware). Les pré requis pour l installation de Bonita sont les suivants : En premier lieu, le serveur d application JOnAS [Jon] (Java Open Application server) qui intègre le serveur Tomcat. Ensuite, l installation de JDK [SUN] en tant que plate-forme de développement, suivi par l installation d une version de Jakarta ANT [JakAnt] pour la compilation et l exécution de targets pour le fichier Build.xml de Bonita (cf. chapitre 5). Enfin, il y a la configuration de la base de données, pour cette version c est la BD Mckoi [Cons] qui doit avoir la configuration nécessaire pour l accès aux données ainsi que la configuration de serveur d application JOnAS Conception de l outil de collecte de traces La conception d un outil de collecte de traces, qui sera greffé à Bonita, a pour but d enregistrer dans des fichiers logs des évènements qui vont se produire lors de l instanciation et de l exécution d un projet workflow au sein de Bonita. Parmi les services qu intègre Bonita pour le contrôle des aspects coopératifs se trouve le service de messages JMS qui est utilisé par les composants logicielle de Bonita pour assurer un échange d informations et de messages relatant à l exécution d un workflow. En effet, il s agit d une API de la plate-forme J2EE qui permet de construire des messages pour la transmission des données. Chaque interaction entre l utilisateur et l application tels que la création d un projet Rapport de projet de fin d'études Mars - Juin 2004 Page 31

32 Chapitre 4 : Conception Globale ou sa suppression (create projet, delete project), l exécution d une activité ou sa terminaison (start, terminate), etc. (cf. fig.6). sera enregistrée en tant qu évènement JMS. Figure 6 : Exécution d'activités dans un projet workflow Les services de messagerie JMS permettent de fournir tous les évènements qui viennent de se produire lors de l exécution des activités d un workflow. Les événements sont généralement de différents types, ils peuvent être le nom du projet, le nom de l activité dans ce projet, son état d exécution(par exemple: en attente, prête, exécutée, etc.), la date de son exécution, etc. Toutes ces informations nous seront de très grande utilité pour la constitution du workflow log. Afin d arriver à la construction de ce fichier log, il faudra concevoir un outil qui va collecter toutes les traces d exécution. Cet outil de collecte de trace est une sorte d espion greffé à Bonita, puisqu il va espionner toutes les transactions qui vont être produit par les services de messageries JMS lors de l exécution d une instance de workflow (cf. fig.7). Rapport de projet de fin d'études Mars - Juin 2004 Page 32

33 Chapitre 4 : Conception Globale Figure 7 : Outil de collecte de traces greffé à Bonita L outil s appuie sur l API JMS pour extraire les évènements échangés dans Bonita et les retourner après sous forme de fichiers XML contenant les informations nécessaires à notre algorithme de workflow mining. La figure ci-dessus illustre bien la démarche à suivre pour l extraction d évènements lors de l exécution d une instance de workflow. En effet, une fois le projet de workflow établi dans l éditeur graphique WorkList et que les activités soient modéliser dans le GraphEditor (cf. fig.6), l outil va se mettre en écoute et extraire les évènements à partir du serveur de messagerie (cf. chapitre 5). Une fois les évènements collectés, cette API va les retourner sous forme de fichier XML. Chaque fichier XML sera authentifié par la date de création du projet workflow dans Bonita (cf. fig.8). L utilité du fichier XML va se révéler lors du développement du filtre XML. En effet, une fois les données saisies, une analyse syntaxique nommée Parseur XML devra se faire pour aboutir à des statistiques sur les activités que contient l exécution d une instance de workflow (voir section suivante). Rapport de projet de fin d'études Mars - Juin 2004 Page 33

34 Chapitre 4 : Conception Globale Figure 8 : Fichier XML de la collecte de traces d'exécution Développement d un parseur XML pour les traces d exécution Une fois les projets de workflow exécutés et leurs traces d exécutions collectées dans les fichiers XML, la phase suivante sera l étude de XML parsing (analyse lexicale du code). Le développement d un outil Parser pour le filtrage et l extraction de données à partir du fichier log. Pour cette phase, la solution logicielle pour le filtrage du fichier log sera le recours aux parseurs XML. Pour notre cas, il s agit du parseur JDOM [CSI]. Le but de JDOM est de faciliter la manipulation au sens large de document XML : lecture d'un document, représentation sous forme d'arborescence, manipulation de cet arbre, définition d'un nouveau document, exportation vers plusieurs cibles (cf. chapitre 5). Rapport de projet de fin d'études Mars - Juin 2004 Page 34

35 Chapitre 4 : Conception Globale La démarche à suivre pour le développement de ce filtre s illustre dans la figure qui suit où il y a une interaction entre une partie du WFMS Bonita et cet outil de filtrage. Figure 9 : Parseur XML JDOM Une fois que le parseur JDOM a parcouru le document XML, le résultat sera un tableau qui va contenir des statistiques sur les activités que contient le projet de workflow considéré. Ces statistiques seront les données nécessaires pour l établissement des techniques de workflow mining. En effet, les statistiques saisies seront exploitées par des règles pour découvrir des patrons de workflow qui décrivent le modèle global du workflow sin-die [Gaa04]. 4.4 Conclusion Après avoir fini avec la conception globale et avant de se lancer dans la réalisation de l ouvrage, il est nécessaire de prendre le temps de découper le projet en tâches afin de planifier son exécution et de définir les ressources à mobiliser. C est la partie de la conception détaillée. Mais avant d'expliciter en détails le travail réalisé et les défis techniques relevés (cf. chapitre 6), nous consacrerons le cinquième chapitre à la présentation des technologies, des outils utilisés et des choix techniques adoptés. Rapport de projet de fin d'études Mars - Juin 2004 Page 35

36 Chapitre 4 : Conception Globale CHOIX TECHNOLOGIQUES générale 5.1 Introduction 5.2 Les choix techniques 5.3 Configuration logicielle 5.4 Configuration matérielle 5.5 Conclusion Rapport de projet de fin d'études Mars - Juin 2004 Page 36

37 Chapitre 5 : Choix technologiques Chapitre 5 : CHOIX TECHNOLOGIQUES 5.1 Introduction Le pari le plus important des programmeurs est d utiliser correctement leurs applications sur n importe quelle plate-forme sans changement du code source «Write once, Run anywhere», de pouvoir communiquer facilement avec d autres applications, et de fournir un support sécurisé. Cependant, les outils ou langages déjà existants allient rarement les fonctionnalités de vitesse, portabilité et sécurité des applications générées. Le choix d un environnement et d un langage de programmation doit alors être décidé sur la base de l importance de l un de ces critères compte tenu du type de l application développé. Dans ce chapitre, nous allons présenter le langage adopté pour le développement ainsi que les technologies choisies pour assurer le bon déroulement du travail. 5.2 Les choix techniques Choix du langage Pour choisir le langage approprié pour développer notre projet, plusieurs critères doivent être pris en compte : La sécurité : la sécurité consiste à conserver les informations sensibles dans les mains des utilisateurs autorisés. La performance et la puissance : la performance et la puissance d un langage dépendent de son compilateur et de son cycle d exécution. La portabilité : la portabilité d un langage dépend de la plate-forme qui le supporte. La richesse des fonctionnalités : c est le nombre de fonctions qu un langage peut faire. La simplicité de développement : la facilité de développement offert par un langage. Le coût de support : le support est la plupart du temps gratuit. La consommation mémoire : c est allouer de l espace qu il utilise lors de l exécution. La réutilisation : c est le fait qu un programme réalisé puisse être utilisé par un autre programme sans être obligé de le programmer une autre fois. En plus, il est important de ne pas être en contradiction avec des choix déjà existant de la plate-forme de développement. Pour ce faire, il est important d analyser l existant de la plateforme. Donc, dans notre cas il faut s y referer à la plate-forme J2EE sur laquelle est centrée le développement de Bonita [Val01]. Rapport de projet de fin d'études Mars - Juin 2004 Page 37

38 Chapitre 5 : Choix technologiques La plate-forme J2EE J2EE constitue une infrastructure de gestion des applications. Elle dispose d APIs des services utilisées pour concevoir ces applications. Cette plate-forme définit une architecture standard incluant: Un modèle de programmation (application multi-tiers, client léger) Un ensemble de test de compatibilité Une implantation de référence Différents services: connexions aux bases de données, la messagerie, les transactions, etc. Nous allons entreprendre un tour d'horizon des APIs couvertes par l'api "entreprise" de Sun. Parmi ces APIs nous allons citer les plus importants tels que: JDBC : est une API permettant de travailler avec des bases de données relationnelles. Elle permet d'envoyer des requêtes SQL à une base. RMI : est une API fournissant une approche de haut niveau de la programmation distribuée. On peut ainsi invoquer des méthodes d'un objet distant (résidant sur un serveur) de la même manière que l'on appelle les méthodes d'un objet local. JNDI : est une API pour communiquer avec les services de nommage et d'annuaire en réseau. EJB : les EJB sont des composants (au même titre que des Java Beans) destinés à tourner dans un serveur d'application EJB pour encapsuler des services de données ou logique métier. La valeur ajoutée des EJBs réside dans les services fournis par le serveur. Le framework EJB est ainsi tenu d'assurer, de manière transparente, la sécurité, la persistance, le support réseau et la gestion des transactions aux composants. JSP : Les JSPs sont des pages HTML comportant du code imbriqué. Elles présentent l'avantage d'être beaucoup plus proche du document HTML que du code Java. JMS : est une API d'échange asynchrone de message ou d'évènements critiques entre applications. Comme JNDI et JDBC, JMS est une API construite pour reposer sur des services de messagerie existants fournis par divers vendeurs. JMS permet maintenant de gérer les transactions et est utilisée pour la communication asynchrone entre EJBs (des EJBs pilotés par messages ou message driven beans). JMS sera l API pour notre développement (cf. chpaitre 6). JTA : est une API permettant de gérer des transactions distribuées. JAXP : est une API qui unifie les différentes implémentations de parsers XML (parsers SAX, DOM et processeurs XSLT) [Cas02]. Rapport de projet de fin d'études Mars - Juin 2004 Page 38

39 Chapitre 5 : Choix technologiques Le choix de l API pour l échange de messages Le langage approprié pour développer notre projet est donc le langage Java qui répond aux critères que nous venons de citer. L outil de collecte de traces dépend d un service intégré dans Bonita, ce service est le responsable de la construction de messages pour la transmission de données. Il s agit de l API JMS ( pour Java Message service) intégrée à la plate-forme J2EE et dont l architecture s illustre comme suit : Figure 10 : API JMS dans la plate-forme J2EE JMS peut être utilisé dans un composant web ou un EJB où un type d'ejb particulier a été ajouté pour traiter les messages et des échanges JMS peuvent être intégrés dans une transaction gérée avec JTA (Java Transaction API). JMS définit plusieurs entités : Un provider JMS : outil qui impémente l'api JMS pour échanger les messages : ce sont les brokers de messages. Un client JMS : composant écrit en java qui utilise JMS pour émettre et/ou recevoir des messages. Un message : données échangées entre les composants. Rapport de projet de fin d'études Mars - Juin 2004 Page 39

40 Chapitre 5 : Choix technologiques Les messages sont asynchrones mais JMS définit deux modes pour consommer un message : Mode synchrone : ce mode nécessite l'appel de la méthode receive() ou d'une de ces surcharges. Dans ce cas, l'application est arrêtée jusqu'à l'arrivée du message. Une version surchargée de cette méthode permet de rendre la main après un certain time out. Mode asynchrone : il faut définir un listener qui va lancer un thread qui va attendre les messages et exécuter une méthode lors de leur arrivée. Les brokers de messages ou MOM (Middleware Oriented Message) permettent d'assurer l'échange de messages entre deux composants nommés clients. Les deux clients n'échangent pas directement des messages : un client envoi un message et le client destinataire doit demander la réception du message. Le transfert du message et sa persistance sont assurés par le broker. Les échanges de message sont asynchrones et fiables puisque les messages ne sont délivrés qu'une seule fois. Les MOM représentent le seul moyen d'effectuer un échange de messages asynchrones. Ils peuvent aussi être très pratique pour l'échange synchrone de messages plutôt que d'utiliser d'autres mécanismes plus compliqués à mettre en œuvre (sockets, RMI, CORBA, etc.). Les brokers de messages peuvent fonctionner selon deux modes : le mode point à point (queue) le mode publication/abonnement (publish/subscribe) Le mode point à point (point to point) repose sur le concept de files d'attente (queues). Le message est stocké dans une file d'attente puis il est lu dans cette file ou dans une autre. Le transfert du message d'une file à l'autre est réalisé par le broker de message. Chaque message est envoyé dans une seule file d'attente. Il y reste jusqu'à ce qu'il soit consommé par un client et un seul et d ou le problème pour notre application qui est manipulée par plusieurs utilisateurs [CSI]. Tandisque le mode publication/abonnement repose sur le concept de sujets (Topics). Plusieurs clients peuvent envoyer des messages dans ce topic. Le broker de message assure l'acheminement de ce message à chaque client qui se sera préalablement abonné à ce topic. Le message possède donc potentiellement plusieurs destinataires. L'émetteur du message ne connaît pas les destinataires qui se sont abonnés. Donc, ce mode sera choisi pour la collecte de traces d exécutions. Rapport de projet de fin d'études Mars - Juin 2004 Page 40

41 Chapitre 5 : Choix technologiques Les interfaces qui définissent l'api sont : Connection : Cette interface définie des méthodes pour la connection au broker de messages. Session : Elle représente un contexte transactionnel de réception et d'émission pour une connection donnée. Message : Cette interface se compose du header (entête), properties (propriétés) et body (corps du message). MessageProducer : L'interface MessageProducer est la super interface des interfaces qui définissent des méthodes pour l'envoi de messages. MessageListener : L'interface MessageConsumer est la super interface des interfaces qui définissent des méthodes pour la réception de messages Le serveur d application JOnAS JOnAS [Jon] est le serveur d'application Java utilisé par Bonita se conformant à la spécification J2EE. En outre sa forte modularité lui permet d'être utilisé comme : un serveur J2EE, pour déployer et exécuter des applications EAR (c. à. d. pour des applications composées simultanément de composants web et d'ejb), un conteneur d EJB, pour déployer et exécuter des composants EJB (c. à. d. pour des applications sans interfaces Web ou utilisant des moteurs de JSP/Servlet qui ne sont pas intégrés comme conteneur J2EE JOnAS), un conteneur Web, pour déployer ou exécuter des JSPs et Servlets (c. à. d. pour des applications sans composants EJB). Outre l implémentation de tous les standards J2EE, trois aspects critiques de J2EE ont été implémentés très tôt dans le serveur JOnAS : J2EE CA: Les systèmes d'information de l'entreprise (EIS Enterprise Information Systems) sont facilement accessibles aux applications JOnAS. En respectant l'architecture des connecteurs J2EE (J2EE CA), il permet le déploiement de tout connecteur se conformant à J2EE CA. L'EIS est alors disponible depuis un composant applicatif J2EE. JOnAS intègre un connecteur JDBC qui peut être utilisé en remplacement du service Bases de Données de JOnAS, et qui propose en plus la gestion d'un pool de requêtes JDBC pré compilées (PreparedStatement). Rapport de projet de fin d'études Mars - Juin 2004 Page 41

42 Chapitre 5 : Choix technologiques JMS: Les implémentations de JMS peuvent être facilement introduites dans JOnAS. Elles s'exécutent sous forme de services JOnAS dans la même JVM (Java Virtual Machine) ou dans une JVM séparée. JonAS propose des fonctionnalités d'administration qui masquent les APIs d'administration propriétaires de JMS. Actuellement, plusieurs implémentations de JMS peuvent être utilisées tel que l'implémentation open source JORAM (Java Open Reliable Asynchronous Messaging) d'objectweb. JTA: La plate forme JOnAS supporte les transactions distribuées impliquant des composants multiples, ainsi que des ressources transactionnelles [Jon]. Figure 11 : Architecture de JOnAS Présentation de la technologie XML Le langage de balisage extensible (Extensible Markup Language, XML) est un sousensemble de SGML (Standard Generalized Markup Language). Son but est de permettre au SGML générique d'être transmis, reçu et traité sur le Web de la même manière que l'est HTML aujourd'hui. XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et HTML. Les documents XML se composent d'unités de stockage appelées entités, qui Rapport de projet de fin d'études Mars - Juin 2004 Page 42

43 Chapitre 5 : Choix technologiques contiennent des données analysables ou non. Les données analysables se composent de caractères, certains formant les données textuelles, et le reste formant le balisage. Le balisage décrit les structures logique et de stockage du document. XML fournit un mécanisme pour imposer des contraintes à ces structures [XML01]. Chaque document XML contient un ou plusieurs éléments, dont les limites sont marquées soit par des balises ouvrantes et fermantes, soit, pour les éléments vides, par une balise d'élément vide. Chaque élément a un type, identifié par un nom, parfois appelé son «identificateur générique» (IG), on peut y associer un jeu de spécifications d'attribut. Chaque spécification d'attribut comprend un nom et une valeur. Exemple simple de document XML: <?xml version="1.0" encoding="iso8859-1"?> <CATALOG> <CD> <TITLE>Empire Burlesque</TITLE> <ARTIST>Bob Dylan</ARTIST> <COUNTRY>USA</COUNTRY> <COMPANY>Columbia</COMPANY> <PRICE>10.90</PRICE> <YEAR>1985</YEAR> <MONTH> junuary </MONTH> </CD> </CATALOG> Exemple de document XML La structure des éléments d'un document XML peut, à des fins de validation, être contrainte à l'aide de déclarations de type d'élément et de liste d'attributs. La déclaration de type d'un élément contraint le contenu de cet élément. Une déclaration de type d'élément se formule soit en spécifiant le lien vers le document DTD (Document Type Definition), soit en intégrant directement au début du document XML la définition des types d'éléments. <?xml version="1.0" encoding="iso8859-1"?> <!DOCTYPE CATALOG[ <!ELEMENT CATALOG (CD)*> <!ELEMENT CD (TITLE,ARTIST,COUNTRY,COMPANY,PRICE,YEAR,MONTH)> <!ELEMENT TITLE (#PCDATA)> <!ELEMENT ARTIST (#PCDATA)> <!ELEMENT COUNTRY (#PCDATA)> <!ELEMENT COMPANY (#PCDATA)> <CATALOG> <CD> <TITLE>Empire Burlesque</TITLE> <ARTIST>Bob Dylan</ARTIST> <COUNTRY>USA</COUNTRY> <COMPANY>Columbia</COMPANY> </CD> </CATALOG> Document XML avec DTD interne Rapport de projet de fin d'études Mars - Juin 2004 Page 43

44 Chapitre 5 : Choix technologiques La définition des types de données est interprétée comme suit:!element CATALOG (à la ligne 3) définit l'élément CATALOG comme ayant un sous élément obligatoire : (CD)*. L'étoile signifie qu'il peut y en avoir plusieurs.!element CD (à la ligne 4) définit l'élément CD comme ayant 7 sous éléments obligatoires: (TITLE,ARTIST,COUNTRY,COMPANY,PRICE,YEAR,MONTH).!ELEMENT TITLE (à la ligne 5) définit l'élément TITLE comme étant de type "CDATA" (chaîne de caractères).!element ARTIST (à la ligne 6) définit l'élément ARTIST comme étant de type "CDATA" (chaîne de caractères). Pour notre fichier DTD, relatif au fichier XML de la collecte de traces, il sera de type externe ( La définition des types de données est spécifiée dans le fichier workflow_log.dtd comme suit: <?xml version="1.0" encoding="iso8859-1"?> <!ELEMENT Project(log_line*)> <!ELEMENT log_line (user,task,state,event,date,time)> <!ATTLIST user id ID #REQUIRED description CDATA "none"> <!ELEMENT Task (#PCDATA)> <!ELEMENT state EMPTY> <!ATTLIST state name (READY DEAD ANTICIPABLE EXPIRED ANTICIPATING EXECUTING EXECUTED INERROR FINISHED TERMINATED CHECKEDOUT ANT_SUSPENDED EXEC_SUSPENDED BAD_TRANSITION) #REQUIRED> <!ELEMENT event (#PCDATA)> <!ELEMENT date (#PCDATA)> <!ELEMENT time (#PCDATA)> Fichier DTD workflow_log Ce fichier est alors enregistré sous le nom "workflow_log.dtd" et est spécifié dans le fichierxml comme suit : <?xml version="1.0" encoding="iso8859-1"?> <!DOCTYPE WorkFlow_log SYSTEM " <Project name="subscribeonline"> <log_line> <user id="admin"/> <Task name="connection"/> <state name="executing"/> <event name="setnodestate"/> <date>"7/4/2004"</date> <time>"16:36:52"</time> </log_line> </Project> Intégration du fichier DTD dans XML Rapport de projet de fin d'études Mars - Juin 2004 Page 44

45 Chapitre 5 : Choix technologiques Le choix du parseur XML Une fois l outil de collecte de traces d exécutions réalisé, le résultat sera sous format de fichier XML. Pour analyser le contenu de ce fichier, il faut développer un parseur XML. L'analyseur syntaxique (généralement francisé en parseur) est un outil logiciel permettant de parcourir un document et d'en extraire des informations. Dans le cas de XML (on parle alors de parseur XML), l'analyseur permet de créer une structure hiérarchique contenant les données contenues dans le document XML [CSI]. On distingue deux types de parseur XML : les parseurs validants (validating) permettant de vérifier qu'un document XML est conforme à sa DTD, les parseurs non validants (non-validating) se contentant de vérifier que le document XML est bien formé (c'est-à-dire respectant la syntaxe XML de base). Les analyseurs XML sont également divisés selon l'approche qu'ils utilisent pour traiter le document. On distingue actuellement deux types d'approches : Les API utilisant une approche hiérarchique : les analyseurs utilisant cette technique construisent une structure hiérarchique contenant des objets représentant les éléments du document, et dont les méthodes permettent d'accéder aux propriétés. La principale API utilisant cette approche est DOM (Document Object Model). Les API basés sur un mode événementiel permettent de réagir à des événements (comme le début d'un élément, la fin d'un élément) et de renvoyer le résultat à l'application utilisant cette API. SAX (Simple API for XML est la principale interface utilisant l'aspect événementiel. Cependant, il existe JDOM qui présente de grandes similitudes avec le DOM dans le sens qu'il représente un document XML via une structure arborescente. Mais il est une API uniquement java car il s'appuie sur un ensemble de classe de java notamment les collections. Le but de JDOM n'est pas de définir un nouveau type de parseur mais de faciliter la manipulation au sens large de document XML : lecture d'un document, représentation sous forme d'arborescence, manipulation de cet arbre, définition d'un nouveau document, et exportation vers plusieurs cibles. Pour parser un document XML, JDOM utilise un parseur externe de type SAX ou DOM. Le choix d'utiliser un de ces outils doit tenir compte de leurs points forts et de leurs faiblesses. Rapport de projet de fin d'études Mars - Juin 2004 Page 45

46 Chapitre 5 : Choix technologiques les avantages les inconvénients DOM SAX JDOM Parcours libre de l'arbre. Possibilité de modifier la structure et le contenu de l'arbre. Peut gourmand en ressources mémoire. Rapide. Principes faciles à mettre en œuvre. Permet de ne traiter que les données utiles. Beaucoup plus pratique. Il offre une plus grande facilité pour répondre au cas les plus classique d'utilisation. Dépend de SAX ou de DOM. Gourmand en mémoire. Doit traiter tout le document avant d'exploiter les résultats. Traite les données de manière séquentielle. Un peu plus difficile à programmer, il est souvent nécessaire de sauvegarder des informations pour les traiter. JDOM possède moins de fonctionnalité que DOM. Dépend de la plate-forme J2EE. Table 2 : Comparaison des parseurs A la lumière des informations présentées dans ce tableau, JDOM sera donc notre choix. En effet, vu le nombre de fichiers XML à traiter et le temps qu il va falloir pour saisir toutes les données nécessaires. Il semble que cette API soit la plus qualifiée pour ce rôle. 5.3 Configuration logicielle Cygwin Un des plus grands problèmes que les développeurs font face aujourd'hui sont les applications sur les plates-formes incompatibles. Des stations de travail Windows continuent à être ajoutés à un environnement déjà peuplé par Linux et autres logiciels d'exploitation basés sur UNIX. Rapport de projet de fin d'études Mars - Juin 2004 Page 46

47 Chapitre 5 : Choix technologiques Cygwin est comme un environnement Linux pour Windows. Il se compose d une couche d'émulation fournissant les fonctionnalités API de Linux et d une collection d'outils qui fournit l environnement Linux. Il permet d'écrire du code en C ou en Java, code qui pourra être utilisé sur une autre machine Windows ne disposant pas de Cygwin. Ses outils sont des outils de développement populaires de GNU pour Microsoft Windows. En utilisant Cygwin, les développeurs peuvent contrôler les environnements hétérogènes d'une manière cohérente et efficace [Cyg] Utilisation de l'outil ANT L'outil ANT [JakAnt] est un moyen pour automatiser la compilation, le déploiement et beaucoup d'autres opérations manuellement fastidieuses. Il est en quelque sorte ce qu'est le MAKE pour le langage C ou C++. L'utilisation de ANT revient à écrire plusieurs fichiers XML de configuration et aussi de compilation qui décrivent la façon de procéder du ANT. ANT présente plusieurs avantages dont la Portabilité (commandes Unix et Win32), la Rapidité (une seule VM utilisée), la syntaxe rigoureuse d XML (document bien formé), et de très nombreuses tâches déjà implémentées hormis les classes Java. 5.4 Configuration matérielle Postes COMPAQ: Processeurs PENTIUM III 650 MHz. 128 Mo de RAM. 13 Go d espace disque. Carte Réseau : Intel 8255x-based PCI Ethernet Adapter (10/100). Autres : Réseau local de LORIA. Connexion Internet haut débit. 5.5 Conclusion Tout au long de ce chapitre, j ai proposé et justifié les choix techniques adoptés pour la réalisation du projet. Dans le chapitre suivant, je proposerai une conception du travail demandé en tenant compte de ces différents outils choisis. Rapport de projet de fin d'études Mars - Juin 2004 Page 47

48 Chapitre 5 : Choix technologiques MISE EN OEUVRE générale 6.1 Introduction 6.2 Planification 6.3 Déploiement 6.4 Conclusion Rapport de projet de fin d'études Mars - Juin 2004 Page 48

49 Chapitre 6 : Mise en œuvre Chapitre 6 : MISE EN ŒUVRE 6.1 Introduction L expérience a toujours montré l intérêt que peut porter le fait de rendre un produit modulaire. Le concept même de la modularité a été retenu depuis que les développeurs se sont mis à concevoir de grands systèmes. Cette approche «modulariste» a toujours été optée par la totalité des développeurs. Pour cela, il fallait trouver le chemin et le moyen pour distinguer les différents modules à développer. Dans ce chapitre sera présenté le développement des entités (modules) qui ont été défini dans la conception globale. Nous allons, tout d abord, résumé le travail qui est entre autre la planification faite pour arriver à cette phase ultime. Ensuite, pour le déploiement, nous allons mettre en œuvre les différentes classes de fonctionnalités pour le produit. 6.2 Planification Pendant tout le processus de conception, nous avons dû passer par plusieurs étapes importantes pour aboutir au produit qui répond bien aux spécifications décrites dans le cahier des charges. En fait nous nous sommes donnés pour tâche d étudier la faisabilité du produit que nous voulons concevoir, nous avons déterminé alors les différents scénarios de développement après avoir défini le problème, les solutions alternatives et les ressources requises. Après avoir bien étudié la faisabilité, il s est avéré pratique de développer un bon cahier de charges où nous avons donné une spécification complète et validée des fonctions, interfaces et performances. Le cahier de charges ainsi fait, il faut passer à l étape suivante qui n est d autre que la conception globale et les choix technologiques. Dans cette étape, nous avons donné une spécification complète et vérifiée de l architecture globale (matérielle et logicielle) en définissant les différents modules du produit à réaliser ainsi que des choix technologiques à faire (cf. chapitres 4 et 5). Une fois cette étape achevée, il faut passer à l étape suivante qui n est d autre que la conception détaillée, elle ne fait qu approfondir l étude faite précédemment comme son nom l indique. Au cours de cette étape, nous devons, en premier lieu, donner une spécification complète et vérifiée des outils conçus, des fonctions traitées et des relations se trouvant entre les composants du produit réalisé. En second lieu, nous allons attaquer la partie codage qui devra être simple à faire si nous avons bien défini notre conception détaillée. A ce niveau du projet, Rapport de projet de fin d'études Mars - Juin 2004 Page 49

50 Chapitre 6 : Mise en œuvre nous devons spécifier le nom, la fonction, les sorties d erreur, les entrées, les sorties et les algorithmes pour chaque composant. De toute évidence, c est à cette étape du cycle qu on doit toucher les différents aspects techniques et manipuler les structures de données créées pour ce produit. 6.3 Déploiement Outil de collecte de traces d exécution L outil de collecte de traces d exécution est greffé au WFMS Bonita, il permet de collecter tout événement se produisant lors de l exécution d une activité faisant partie d un scénario de workflow définit dans Bonita. Les services de messagerie JMS dans Bonita permettent de fournir ces évènements. Donc, le développement de cet outil va se baser sur l API JMS. Le mode choisi pour répondre à ces besoins est le mode publication/abonnement de JMS (cf. chapitre 5). En effet, il repose sur le concept de sujets (Topics). Plusieurs clients peuvent envoyer des messages dans ce topic et ce sont les brokers de message qui vont assurer l'acheminement de ce message à chaque client qui se sera préalablement abonné à ce topic notamment les administrateurs de Bonita. Le message possède donc potentiellement plusieurs destinataires. Dans ce cas, l'émetteur du message ne connaît pas les destinataires qui se sont abonnés. Ce qui compte pour lui, c est d envoyer le message vers le WFMS Bonita. Le message représente une requête bien définie par l émetteur tels que la demande de création d un projet, celle d une activité, etc. Bonita est un open source, la consultation du code nous à amener à bien saisir le fonctionnement sur le plan de communication de messages entre l utilisateur et le serveur. Après avoir localiser le package responsable de l authentification de l utilisateur et de la création de projets workflow. Il s est avéré que le mieux sera d intégrer dans le package nommé «manager» l outil de collecte de traces nommée LogListener. Le LogListener va se mettre en écoute lors de la connection de l utilisateur manager. En effet, il va écouter les messages échangés entre Bonita et le manager connecté qui se produisent à chaque nouveau évènement. Son rôle consiste à extraire ces évènements se trouvant dans le serveur de messagerie. Ces évènements contiennent le nom de l utilisateur, le nom du projet, les noms des activités, leurs états, et le temps d exécution. A chaque instanciation de workflow, le LogListener produit un fichier XML identifié par le nom du projet et sa date d accès. La figure suivante illustre l approche adoptée et son intégration au sein de Bonita. Rapport de projet de fin d'études Mars - Juin 2004 Page 50

51 Chapitre 6 : Mise en œuvre Figure 12 : Déroulement de la collecte de traces d'exécution Dans la suite, nous présentons un exemple (cf. fig.12) d exécution d une instance workflow et de la collecte de traces de cette exécution. Une fois le WFMS Bonita lancé, il faut que l utilisateur soit authentifié. Après l authentification de l utilisateur, les interfaces locales (éditeurs Rapport de projet de fin d'études Mars - Juin 2004 Page 51

52 Chapitre 6 : Mise en œuvre graphiques) de Bonita sont lancées, c est là où l utilisateur peut procéder à l instanciation de workflow. Grâce aux interfaces WorkList et GraphEditor, l utilisateur arrive à créer de nouveaux projets workflow ou à manipuler des projets workflow existants. Ces projets contiennent des activités qui sont exécutés dans un ordre bien défini lors de leur conception. Les manipulations faites sur les projets workflow ainsi que leurs exécutions sont les évènements dont nous avons besoins. En effet, ces évènements sont stockés dans le serveur de messagerie JMS que le LogListener va extraire par la suite pour produire des fichiers XML les contenant. notre outil. Dans ce qui suit, nous allons présenter l approche conceptuelle adoptée pour implanter Les patrons de conception Nous avons utilisé le patron de conception singleton pour implanter l outil LogListener. En effet, les patron de conception décrivent des solutions simples et élégantes à des problèmes de conception de logiciels orientés objet. Ils sont le résultat d'un travail obscur de remaniement de la conception et du code effectués par les développeurs pour conquérir une réutilisablité et une flexibilité plus grande dans les logiciels. Les patrons de conception facilitent la réutilisation de solutions de conception et d'architectures efficaces. En clair, les patrons de conception aident le concepteur à obtenir plus rapidement une conception plus juste. Ainsi nous bénéficions, dés la compréhension et l'utilisation d'un patron de conception, d'une perception qui permet de rendre les conceptions plus flexibles, plus modulaires, réutilisables, et intelligibles, et peut conduire à une architecture plus légère, ce qui fait l intérêt de la conception orientée objet [Des94]. Parmi ces patrons figure le singleton. Son intérêt se trouve en programmation, lorsqu il est nécessaire de créer un objet qui devra posséder durant tout le programme une instance unique : il s'agit dans notre cas du développement de l outil LogListener. Le singleton LogListener va constituer ainsi une bonne solution pour empêcher la création de multiples objets d'une même classe et donc assurer l'unicité durant tout le programme [Des94]. Cette classe singleton doit assurer deux fonctions : - Empêcher la création de multiples instances de la classe : Le problème est vite réglé : il suffit de déclarer le constructeur comme privé. Ainsi il sera impossible de créer une instance de la classe à l'extérieur de la classe elle-même. - Assurer une instance de la classe : Pour permettre d'accéder à cette instance unique, il est également nécessaire de penser à fournir un point d'appel, nous allons fournira donc une Rapport de projet de fin d'études Mars - Juin 2004 Page 52

53 Chapitre 6 : Mise en œuvre méthode statique. Il existe déjà un standard de nommage, nous l'utilisons donc et nous l appelons la méthode : getinstance() (cf. fig.13). Il faut également que cette instance soit accessible à n'importe quel moment du programme. La méthode statique getinstance() rempliera cette tâche. De plus, c'est elle qui va s'occuper de créer l'instance unique si besoin. C'est à dire : à l'appel de cette méthode, l'instance unique sera créée si le singleton de la classe LogListener pointe sur NULL, ce qui devrait être le cas au début du programme. Figure 13 : Structure d'un singleton La majorité des méthodes hérite des interfaces de l API JMS, tel que la méthode onmessgae() qui traite les messages échangés. Le tableau suivant liste les principales méthodes utilisées ainsi qu une brève explication pour chaque méthode. Méthodes LogListener() subscription() CreateSubscription() onmessage() Rôles Constructeur de la classe. Il a pour but d initialiser les attributs tels que le nom et le mot de passe de l utilisateur. En plus, la création de répertoire et de fichiers lors de l accès à la liste de projet. Pour abonner l utilisateur authentifié aux services JMS. Elle comporte la création de l annuaire JNDI, celle de l objet factory pour la création de la connection : TopicConnection() qui renvoie l objet connection pour la création de la session : TopicSession () une fois un utilisateur est abonné. Elle joue le rôle le plus important. C est là où le fichier XML sera rempli par les évènements. En effet, onmessage() saisi ces évènements pour effectuer après les instructions nécessaires pour l écriture du fichier XML. Elle s occupe aussi de la mise à jour dans la liste des projets workflow. Table 3 : Les méthodes de LogListener Rapport de projet de fin d'études Mars - Juin 2004 Page 53

54 Chapitre 6 : Mise en œuvre Une fois la connection fermée, LogListener va générer un répertoire contenant tous les fichiers XML propres aux exécutions des projets workflows. Donc, la prochaine étape consiste à filtrer ces fichiers XML (cf. fig.14) afin d aboutir aux données requises par le workflow mining. Figure 14 : Exemple d un fichier XML La figure illustre l arborescence du fichier XML relatant au projet workflow. La balise <log_line> regroupe le nom de l utilisateur ainsi que les attributs de l activité (nom, état, événement, date, et heure d exécution) Le parseur XML JDOM va effectuer une analyse lexicale pour chaque fichier XML généré par l outil LogListener. En effet, il va parcourir chaque document pour extraire des données sur les activités, leur nombre d occurrence, la liste des activités qui les précèdent et celles qui les suivent. JDOM va utiliser le parseur externe SAX pour faciliter la manipulation des fichiers XML. Rapport de projet de fin d'études Mars - Juin 2004 Page 54

55 Chapitre 6 : Mise en œuvre Les étapes à suivre pour la réalistion de l opération de filtrage et l extraction des données ou du Parsing des fichiers XML seront les suivantes : 1 ère étape : Définir une classe «activitystatistic» où sera déterminée le nom de l activité, son nombre d occurrence, les activités qui la précèdent et celles qui la suivent. En effet, cette classe aura pour rôle de mettre à jour l opération de filtrage du fichier XML grâce aux méthodes Getters() et Setters() appliqués aux attributs que nous venons de spécifier. 2 ème étape : le parcours du fichier XML pour extraire les données (nom, occurrence, etc.). Il faut définir ainsi une classe «ParserXML» qui aura pour rôle : - La lecture du répertoire qui contient les fichiers XML : la méthode readxmldirectory() va se charger de la lecture des fichiers XML se trouvant dans le répertoire défini. - La saisie de chaque fichier pour le parsing : c est la méthode readxmlfile() qui va saisir chaque fichier pour l analyser. - Le traitement de chaque fichier XML se fait événement par événement, c est à dire balise par balise. En effet, le traitement se fait sur un fichier XML, donc notre analyse procède par la lecture des balises se trouvant dans le fichier considéré. - Après l analyse de chaque fichier XML, il y aura la création d un fichier de sortie qui comprend le résultat de cette analyse. Ce fichier sera de type XML afin d avoir une représentation raffinée et bien structurée des statistiques requises pour l approche de workflow mining. Le diagramme UML (cf. fig.15) qui suit définie bien les deux premières étapes et met en évidence la relation d association entre les deux classes «activitystatic» et «ParserXML». Dans la suite, nous allons plus détailler la méthode readxmlfile() de la classe «ParserXML». La méthode readxmlfile() s appuie sur le parseur SAX pour l analyse des fichiers XML. L analyse d un fichier se fait de la manière suivante : - la réception du fichier XML d entrée comme input, - l utilisation de SAX comme parseur : SAXBuilder pour le filtrage de l input, - le dégagement des attributs de la classe activitystatic à l aide des méthodes getrootelement() et getchildren() héritées de SAX, - l élaboration d algorithmes de calculs et de mise à jour de ces attributs, - en sortie, il y a un fichier XMl : output contenant les statistiques évoquées précédemment qui est généré chaque fois que l analyse du fichier input est terminée. Rapport de projet de fin d'études Mars - Juin 2004 Page 55

56 Chapitre 6 : Mise en œuvre Figure 15 : Diagramme UML du Parseur XML 3 ème étape : l utilisation de l outil ANT va faciliter le déploiement du parseur XML. Son but est de fournir un outil pour permettre la construction d'applications (compilation, exécution de tâches post et pré compilation, etc.). Ces processus de construction d'applications sont très importants car ils permettent d'automatiser des opérations répétitives tout au long du cycle de vie de l'application ANT repose sur un fichier de configuration XML (build.xml) qui décrit les différentes tâches qui devront être exécutées par l'outil. Il fournit un certain nombre de tâches courantes qui sont codées sous forme d'objets développés en java. Le fichier de configuration contient un ensemble de cible (target). Chaque cible contient une ou plusieurs tâches. Chaque cible peut avoir une dépendance envers une ou plusieurs autres cibles pour pouvoir être exécutée. Le build.xml que nous avons défini va répondre à nos besoins en matière de faciliter de déploiement de l outil de filtrage XML. Il faut procéder comme suit : Rapport de projet de fin d'études Mars - Juin 2004 Page 56

57 Chapitre 6 : Mise en œuvre - Une fois le projet défini, il faut définir le target par défaut à compiler, le répertoire source pour la compilation, créer le répertoire de destination, et définir les variables d environnements systèmes. <project name="parser" default="exec" basedir="."> <property name="src" value="c:\java\src"/> <property name="lib" value="c:\java\lib"/> <property name="ant_home" value="c:\bonita-v1.2\ant"/> <property name="java_home" value="c:\j2sdk1.4.1_01"/> <property name="jdom" value="c:\java"/> <target name="init"> <!-- Create the lib directory structure used by compile --> <mkdir dir="${lib}"/> </target> Initialisation du build.xml - Ensuite, il faut définir un target pour la compilation de la source en déclarant les variables d environnements à utilisées. Ce target va à l aide de la commande javac incluse dans ANT généré les fichiers.class pour leur exécution dans la prochaine target d exécution. <target name="compile" depends="init" description="compile the source "> <javac srcdir="${src}" destdir="${lib}"> <classpath> <pathelement path="${path}:${ant_home}/bin:${java_home}/bin:${jdom}:${src}:${lib}"/> <fileset dir="${java_home}\lib: ${JDOM "> <include name="**/*.jar"/> </fileset> </javac> </target> Le target de compilation dans build.xml Rapport de projet de fin d'études Mars - Juin 2004 Page 57

58 Chapitre 6 : Mise en œuvre - Après avoir compiler les fichiers sources, le target exec va exécuter la classe ParserXML tout en tenant compte des arguments d entrée (nom du répertoire, le fichier de destination, la fenêtre de recherche [Gaa04]) qui sont respectivement (traces, Stat et 3). <target name="exec" description="executer ParserXML"> <java classname="parserxml" fork="yes"> <arg line=" traces Stat.xml 3 "/> <classpath> <fileset dir="${lib}"> <include name="*.jar"/> </fileset> <fileset dir="${java_home}: ${JDOM}"> <include name="**/*.jar"/> </classpath> </java> </target> Le target d exécution dans build.xml - Enfin, le dernier target clean va vider le répertoire lib au cas ou il y aura des modifications dans le répertoire src. <target name="clean" description="clean up" > <!-- Delete the ${lib} directory trees --> <delete file="${lib}/parserxml.class"/> <delete file="${lib}/test.jar"/> <echo message="clean"/> </target> </project> Le target clean dans build.xml 6.4 Conclusion Une fois que la conception détaillée est achevée et que les besoins spécifiés dans le cahier des charges sont réalisés, il faut passer aux tests de validation du produit. En effet, il sera testé et validé par l équipe ECOO. Le chapitre suivant va se consacrer à cette dernière tâche. Rapport de projet de fin d'études Mars - Juin 2004 Page 58

59 Chapitre 6 : Mise en œuvre TESTS ET VALIDATIONS générale 7.1 Introduction 7.2 Lancement de "ProcessModel" 7.3 Création de "Subscription" 7.4 Etablissement des statistiques pour l approche du workflow mining 7.5 Conclusion Rapport de projet de fin d'études Mars - Juin 2004 Page 59

60 Chapitre 7 : Tests et validations Chapitre 7 : TESTS ET VALIDATIONS 7.1 Introduction La validation du travail réalisé consiste à suivre les étapes d'exécution de la plate-forme. Pour cela, nous allons créer deux projets de workflow dans Bonita : "ProcessModel" et "Subscription". Chaque projet regroupe un ensemble d activités. "ProcessModel" représente un service de change qui peut être exécuté à partir de ANT car il figure comme un exemple de workflow dans Bonita. La deuxième activité "Subscription" va créer un service d inscription et cette fois en utilisant l interface GraphEditor. Par la suite, nous allons saisir les logs de workflow pour effectuer leur filtrage via le parseur XML conçu. 7.2 Lancement de "ProcessModel" "ProcessModel" est une instance de workflow déjà définie sous Bonita v1.2. Pour la lancer, il suffit de taper la commande ant process-model sous cygwin lors du lancement de Bonita v1.2 (cf. chpitra 5). En effet, process-model figure comme target dans le build de WFMS Bonita. La visualisation de "ProcessModel" se trouve dans les interfaces locales de Bonita, c est à dire WorkList et GraphEditor (cf. fig.16). Figure 16 : Lancement de process-model Rapport de projet de fin d'études Mars - Juin 2004 Page 60

61 Chapitre 7 : Tests et validations suivant : L outil de collecte de traces d exécution de "ProcessModel" va générer le fichier XML Figure 17 : Fichier log du projet e-citizen de process-model Cette figure montre bien les évènements qui se sont produit lors de l exécution d activités du projet "e-citizen". Dans ce fichier XML, nous remarquons que pour chaque ligne de log (<log_line>) correspond les attributs de l activité (nom, état, événement, date, et heure d exécution). 7.3 Création de "Subscription" "Subscription" sera modélisé à partir des interfaces WorkList et GraphEditor. Le projet crée va comporter six activités qui sont respectivement start, writeinformation, sendinformation, checkinformation, reject, et vlidate. Le but est d assurer la fonction d inscription qui peut se faire soit directement c est à dire sur le lieu d inscription (writeinformation), soit via le net (sendinformation). Une fois les données relatives à l inscrit terminées, l activité qui suit : checkinformation va vérifier la Rapport de projet de fin d'études Mars - Juin 2004 Page 61

62 Chapitre 7 : Tests et validations validité du contenu. Ainsi l inscription sera confirmée ou rejetée pour manques d informations. La figure suivante présente la création puis l exécutions des activités du projet workflow "Subscription". Figure 18 : Création et exécution du projet Subscription Elle présente l enchaînement suivi pour l exécution des activités du projet workflow subscription. L activité CheckInforamtion (couleur rouge) est en état d exécution. Pour validate (couleur verte) nous pouvons l exécuter en mode anticipable, tandisque reject (couleur rose) a été exécutée en mode anticipable. Les autres activités (couleur bleu clair) sont déjà exécutées donc ils sont en état terminate. Après l exécution de tout le projet, l outil de collecte de traces va générer le fichier XML qui a enregistré tout ces évènements (cf. fig.19). Rapport de projet de fin d'études Mars - Juin 2004 Page 62