Mise en oeuvre du thorme de Bayes - Page de Michaël …michael.cambay.pagesperso-orange.fr/bayes/Rapport Projet Bayes CCI... · de déterminer les affinités avec un sujet mais

Master 2 CCI 2004-2005 Projet Bayes

MMiissee eenn ŒŒuuvvrree dduu TThhééoorrèèmmee ddee

BBAAYYEESS AAuutteeuurrss :: MMiicchhaaeell CCaammbbaayy,, TThhiieerrrryy CCaappuuttii,, CChhaannttaall LLlloorreennss TTuutteeuurr :: GGuuiillllaauummee SScchhaacchhtteellee

1/46


1 Tables des matières 1 Tables des matières ........................................................ 2

2 Préambule ................................................................... 4 2.1 Remerciements ......................................................................... 4 2.2 Remerciements spéciaux.............................................................. 4 2.3 Comment lire ce rapport.............................................................. 4

3 Contexte, sujet et objectif ............................................... 5 3.1 Le choix du sujet de stage ............................................................ 5 3.2 La constitution et présentation de l’équipe ....................................... 5 3.3 L’appropriation du sujet et l’effervescence ....................................... 6 3.4 La soutenance initiale ................................................................. 6

4 Management du projet..................................................... 7 4.1 Plan Qualité ............................................................................. 7 4.2 Plan Assurance Qualité ................................................................ 8

5 Conception : les bases ....................................................11 5.1 Reformulation des objectifs .........................................................11 5.2 Apprentissage du domaine statistique Bayesien .................................12 5.3 Prospection sur l’Etat de l’art ......................................................15 5.4 Concertation avec le client sur l’orientation du Projet.........................17

6 Conception : l’application idéale .......................................18 6.1 Inventaires des données..............................................................18 6.2 Inventaires de services. ..............................................................20 6.3 Les calculs ..............................................................................21 6.4 Exploitation de la connaissance.....................................................21

7 Conception : une architecture modulaire .............................23 7.1 Schéma théorique .....................................................................23 7.2 Définition des modules ...............................................................23 7.3 Conclusions .............................................................................25

8 Phasage et Planification..................................................26 8.1 Phase 1..................................................................................26 8.2 Phase 2..................................................................................27 8.3 Contrat avec le client : la Phase 1 .................................................28

9 Réalisation : La base de données .......................................29 9.1 Modèle Conceptuel de Données.....................................................29 9.2 Modèle Logique de Données .........................................................30 9.3 Génération et validation de la base................................................30

10 Réalisation : le Moteur Bayesien ........................................31 10.1 Langage et outils de développement ..............................................31

2/46


10.2 Définition du Moteur..................................................................31 10.3 Données en entrée ....................................................................31 10.4 Données en sortie .....................................................................32 10.5 Diagramme de classe UML ...........................................................33 10.6 Cinématique du GBE ..................................................................34 10.7 Conclusions .............................................................................34

11 Réalisation : les interfaces Homme/Machine .........................35 11.1 Les outils et les objectifs ............................................................35 11.2 Synoptique des Ecrans ................................................................35 11.3 Administration de la base de référence ...........................................36 11.4 Menu d’exploitation...................................................................38

12 Réalisation : Intégration, tests, recette ...............................42 12.1 Intégration des modules..............................................................42 12.2 Tests de l’application.................................................................42 12.3 Recette avec le Client : la Phase 1.................................................42

13 Difficultés rencontrées ...................................................43 13.1 Difficulté du domaine de l’application ............................................43 13.2 Management de projet ...............................................................43 13.3 Environnement technique............................................................44

14 Conclusions .................................................................45

15 Index.........................................................................46

3/46


2 Préambule

2.1 Remerciements Dans le cadre de ce projet, nous tenons à exprimer nos remerciements aux membres du jury, enseignants et professionnels. Nous tenons également à remercier notre tuteur M. Guillaume Schachtele, pour sa vision très globale et ouverte du sujet du projet, et l’autonomie qu’il nous a donnée pour en déterminer et en réaliser les objectifs. Nous remercions également Mme Corine Cauvet, responsable de la formation, pour son énergie et son soutien sans faille ainsi que M Jean Pierre Marciano, directeur de l’Atelier de Modélisation, qui nous a accueillis et accompagnés dans cette formation intensive, et M Philippe Thibaud, responsable des projets, pour ses précieux conseils sur la conduite et le management de projets de qualité. Enfin, nous remercions Cendrine Chaffaut et Sarah Zohar, Statisticiennes au CHU Saint Louis à Paris, qui nous ont fourni avec beaucoup de gentillesse et de professionnalisme, les cours théoriques et le support nécessaire à l’accession au niveau élémentaire pour traiter le sujet du projet : le théorème de Bayes.

2.2 Remerciements spéciaux De manière générale, ce projet et cette formation ont été extrêmement intensifs. Rien n’aurait été possible sans le soutien inconditionnel de nos familles, compagnons et compagnes qui ont œuvrés, bienveillants, pour la réussite de nos objectifs. Ils partagent notre succès.

2.3 Comment lire ce rapport Ce document suit un plan assez classique : préambule, organisation, conception, réalisation et conclusion. Nous avons écrit ce rapport pour qu’il soit lu comme un récit dont le fil conducteur est l’histoire et la vie de ce projet. Pour rendre attrayante et digeste sa lecture, les différents chapitres sont émaillés d’anecdotes sur les difficultés du projet et les solutions développées. Ce rapport se suffit à lui-même, en résumant les différents documents disponibles par ailleurs comme l’étude préalable ou le cahier des charges. Ce rapport est disponible au format pdf à l’adresse suivante : http://perso.wanadoo.fr/michael.cambay/bayes/_idx_bayes.htm Nous vous souhaitons une bonne lecture.

4/46

http://perso.wanadoo.fr/michael.cambay/bayes/_idx_bayes.htm


3 Contexte, sujet et objectif

3.1 Le choix du sujet de stage C’est au mois de novembre 2004, lors des sessions de mises à niveau précédant le début effectif de la formation, que les sujets de projet nous ont été communiqués par M Philippe Thibaud. Ce fut l’occasion pour nombre d’entre nous de communiquer par email essentiellement, en vue de déterminer les affinités avec un sujet mais aussi les affinités personnelles pour essayer de constituer des équipes polyvalentes mais homogènes. « J’ai été attiré par les deux propositions de M Guillaume Schachtele (un logiciel d’intrusion, et mise en œuvre du théorème de Bayes) pour leurs envergures et le défi qu’elles présentaient car je n’avais aucune connaissance spécifique ‘réseau et sécurité’ ou ‘statistiques’. » (Michael Cambay) « Je suis de nature plutôt scientifique et je me suis orienté naturellement vers les sujets de Guillaume Schachtele. Plusieurs d’entre eux portaient sur les systèmes et réseaux, que je connais par ailleurs et j’ai préféré le sujet qui traite des probabilités. C’est en effet, une bonne occasion de mettre en pratique un thème qui me plait et d’apprendre sur un sujet qui a de plus en plus de débouchés dans de nombreux domaines d’applications. » (Thierry Caputi) « J’ai été rapidement attirée par les sujets proposés par Mr Schachtele et plus particulièrement le théorème de Bayes. Il s’agit d’un domaine que je ne connaissais pas du tout et complètement à l’opposé de ce que j’ai l’habitude de traiter dans mon environnement professionnel » (Chantal Llorens) Jihad Araji Marques qui a abandonné la formation par la suite, était féru de mathématiques. Les sujets sur Bayes et sur les nombres premiers proposés par M Schachtele avaient sa préférence.

3.2 La constitution et présentation de l’équipe Les équipes sont formées mi-novembre 2004, avec M thibaud. Les règles de constitution des équipes mirent en concurrence plusieurs sujets et donc étudiants mais le processus d’attribution se fit de manière démocratique et élégante. Notre détermination et notre nombre facilitèrent l’obtention du sujet souhaité. L’équipe, officiellement constituée, était composée de : Michael Cambay : Informaticien temps réel et objet depuis 20 ans. Attend entre autres de la formation un diplôme en phase avec les postes recherchés dans un marché de l’emploi très concurrentiel. Thierry Caputi : Administrateur Système avec 20 ans d’expérience, actuellement au Conseil Régional Provence Alpes Côte d’Azur, engagé dans un processus de titularisation.

5/46


Chantal Llorens: Analyste depuis 25 ans, dans le monde gros système, connaissant bien les domaines bancaires et monétique, cherche une extension de ces compétences NTIC pour répondre au marché. Jihad Araji Marques : étudiant possédant un DESS de conception de Système C.A.O, cherche des compétences techniques pratiques en réseaux par exemple car il pense que son diplôme est trop spécialisé.

3.3 L’appropriation du sujet et l’effervescence Le processus d’appropriation du sujet, avait en fait démarré avant l’attribution de ceux-ci. Dès début novembre, Michael et Thierry ont rencontré individuellement plusieurs fois M Guillaume Schachtele pour des séances de défrichage du sujet. A la constitution officielle de l’équipe, chacun avait déjà sa propre vision du projet, ses convictions, ses certitudes. Le vocabulaire lui-même était propre à chacun et naturellement nous ne nous « entendions » pas. Chacun poussé par un désir individuel de réussir le projet, proposait son approche, mettant l’accent sur des points que les autres trouvaient hors sujet. L’impression d’avancer contre et non avec les autres était grande. De plus, à part Jihad, chacun de nous avait eu l’habitude de mener des projets et était sûr de sa valeur et de sa capacité à diriger les autres. En même temps le dynamisme et l’intérêt de tous pour le sujet étaient manifestes et c’est donc avec une effervescence certaine que nous avons donc commencé à fonctionner. Les difficultés de communication se sont progressivement dissipées car chaque discussion apportait son lot d’éclaircissements sur le vocabulaire, sur le domaine statistique, et plus généralement sur les personnalités et compétences de chacun. Ce fut un processus long, empirique, chaotique pourrait on dire, demandant de l’humilité, une grande écoute des autres, beaucoup de bon sens et une remise en question permanente. Car malgré la grande expérience professionnelle de la plupart d’entre nous, ce contexte de création d’équipe était entièrement nouveau. Dans le monde professionnel, on intègre très souvent des équipes déjà constituées, avec une certaine collégialité. Même dans le cas d’équipes pluridisciplinaires, le niveau des participants est homogène, le domaine est connu de tous etc.

3.4 La soutenance initiale C’est donc sur le mode du consensus que nous avons abordé la préparation de la soutenance initiale. Avec le recul, nous comprenons que notre présentation révélait la nature ambiguë de ce consensus. Nous avons parlé d’un chef de projet « tournant » car nous n’avions pas pu nous mettre d’accord sur un chef. Nous avons présenté un sujet très peu concret car nous n’avions pas la même vision pratique du projet. Etc. Le jury, nous a mis an garde contre l’aspect vague de nos objectifs face au caractère illimité d’un projet « mettant en œuvre le théorème de Bayes ». Rendez vous était pris fin avril pour la soutenance finale : Douche froide.

6/46


4 Management du projet Au début de la formation, nous n’avions pas encore eu les cours de management de projet et de gestion de la qualité. Mais tel M Jourdain faisant de la prose sans le savoir, nous avons mené notre projet avec une démarche de Qualité que nous allons détaillé ici.

4.1 Plan Qualité

4.1.1 Reconnaissance du but Après la soutenance initiale, nous avons compris que nous avions donné l’image d’une équipe peu organisée, sans leader, face à un projet très large sans objectifs concrets voir sans objectif du tout. Avant toute chose, nous avons voulu reformuler correctement et par écrit le sujet du projet, de façon a en délimiter le périmètre et en dégager les demandes principales exprimées et non exprimées. La validation de ce document par notre client a chassé la mauvaise impression et le sentiment de flou de notre première prestation. Cela nous a conforté sur l’orientation à suivre pour notre projet

4.1.2 Choix d’un pilote Avec ce premier travail d’équipe, nous avons compris la nécessité d’avoir un capitaine ayant une vision globale du projet. Les compétences de chacun semblaient suffisantes pour venir à bout de tout projet mais il fallait coordonner les énergies, focaliser les efforts, fédérer et orienter l’équipe. Michaël proposa d’être Chef de projet, en se positionnant comme un fédérateur qui écouterait tous les membres de l’équipe et laisserait un maximum de responsabilité à chacun. L’objectif étant de favoriser les initiatives positives de chaque membre de l’équipe, tout en assumant un rôle d’arbitre le cas échéant. Le travail de défrichage théorique qu’il avait déjà mené convainquit l’équipe qu’il avait une bonne vision du projet.

4.1.3 Etude préalable et Cahier des Charges Fonctionnel L’étude préalable a été écrite et présentée à notre tuteur dans le but de définir l’orientation du projet. Le cahier des charges fonctionnel a définit le contrat passé avec notre client. Nous n’avons pas jugé utile de faire un cahier des charges techniques car la réalisation était faite par les concepteurs.

4.1.4 Organisation du projet Notre projet se divisait en 4 sous domaines : la base de données le ‘moteur bayesien’ les Interfaces Homme/Machine ou IHM. La documentation et le management.

Une version du projet était donc stockée dans un répertoire possédant 4 sous répertoires.

7/46


De plus, nous avons utilisé les notions d’espace de développement & validation (DEV), et de production (PRD). Ainsi le projet à tout moment existait en deux versions permettant à chacun d’utiliser des modules de production (fiables) pour en développer ou en tester d’autres, sans interactions préjudiciables

4.1.5 Parallélisme et Responsabilité L’organisation de l’espace projet a permis de développer en parallèle les parties IHM et moteur Bayesien de façon à optimiser le temps de réalisation. Chacun a eu la responsabilité et l’autonomie complète de la réalisation de sa partie. Le chef de projet n’était pas là pour tout superviser dans le détail mais pour s’assurer que l’ensemble était cohérent. Autonomie ne voulant pas dire solitude, les solutions développées ont toujours été validées par l’équipe.

4.2 Plan Assurance Qualité

4.2.1 Relations avec le maître d’ouvrage Vis-à-vis de notre maître d’ouvrage et tuteur, l’organisation de l’équipe et le rôle de chacun furent vite établis. L’interface unique serait le chef de projet, pour éviter tout erreur de communication, non dit, qui pro quo ou autres. A chaque réunion avec le maître d’œuvre, l’équipe parlerait d’une seule voix pour poser les questions de chacun ou proposer tel ou tel scénario. Un compte rendu ou débriefing suivrait les réunions pour éviter au mieux toute erreur de compréhension ou d’interprétation. Nous avons jalonné notre projet par des revues avec le maître d’ouvrage aux moments clefs (Cahier des Charges, Livraisons partielles, etc.) et nous avons planifié assez longtemps à l’avance ces dates. Cela nous a obligé à bien gérer notre temps, ce qui fut bénéfique à la progression du projet. Nous avons régulièrement tenu notre client informé de l’état d’avancement du projet, et nous lui avons toujours présenté des solutions réalistes et en phase avec ces attentes. Cette communication claire et droite a permis de maintenir un climat de confiance sympathique pour tout le monde.

4.2.2 Organisation interne de l’équipe De manière interne, une priorité à la souplesse et à l’initiative personnelle a été donnée pour permettre à chacun de vivre le projet à son rythme et de trouver sa place dans l’équipe. Cela nous a permis de déceler tôt les problèmes d’analyse ou de conception car écoutant toutes les critiques ou propositions, nous étions obligés de bien formaliser nos idées pour arriver à un accord. Ce fut souvent « sonore » au début du projet mais cette attitude nous a permis de ne pas revenir sur la conception lors de la phase de réalisation. En accord avec cet état d’esprit orienté sur la souplesse et la réactivité, nous n’avons pas planifié de revues internes. C’est « à la demande », aussi souvent que le besoin s’en est fait sentir, que nous nous sommes réunis pour des revues de conceptions ou de tests etc.

8/46


4.2.3 Gestion du temps La principale contrainte de ce projet a été naturellement le temps. Avant même de commencer le travail, nous avons opté classiquement pour un découpage en étape du projet, avec la contrainte de n’admettre aucun retard à chacune d’elles. Ce mode de fonctionnement piloté par le temps a eu deux effets : Nous sommes arrivés à nos objectifs dans le temps imparti. Nous avons maîtrisé le choix des compromis à faire dans la réalisation

du projet, et nous avons pu très tôt dialoguer avec notre tuteur pour lui expliquer nos options. Il n’y a donc pas eu de mauvaises surprises de dernière minute

Nous avons utilisé MSProject pour planifier notre temps et de fait, la seule planification initiale a suffit : nous nous y sommes reportés sans jamais avoir à décaler tel ou tel jalon.

4.2.4 Gestion du matériel L’université a mis à notre disposition son réseau et ses PC. Cela dit, la disponibilité de ces derniers était réduite du fait des cours monopolisant les salles informatiques ou même du rapport étudiant/poste. Les postes de l’université, pour des raisons compréhensibles, n’étaient accessibles qu’en mode utilisateur, interdisant toute installation logicielle en mode superviseur. Bien que tournant sous la même version de Window2000 et Linux, des différences de configurations existaient entre les postes. Enfin, Internet était disponible sur chacun d’eux (là aussi avec des différences de comportements dues aux différences de configuration) L’administration du réseau de l’université, s’est avérée inadéquate par rapport à nos besoins en terme de réactivité notamment. Par exemple, l’attribution d’espaces partagés privés pour gérer professionnellement nos projets a pris plus de la moitié de la durée de la formation. Enfin, chaque membre de l’équipe possédait un PC personnel, bien maîtrisé et plus puissant que ceux de l’université. Seul l’un d’entre eux était portable. Ils fonctionnaient tous sous Windows XP mais en version pro ou familiale, SP1 ou SP2. Pour faire face à cette hétérogénéité de matériel et aux points faibles du réseau, nous avons établi des règles de gestion au niveau logiciel essentiellement.

4.2.5 Gestion des versions Les sources logicielles de notre projet étaient sur un espace (public au départ puis privé par la suite) du serveur Mistral de l’université et nous avons géré leurs sauvegardes quotidiennement (ou du moins à chaque session de travail) sur le PC personnel du chef de projet, grâce à un logiciel permettant la synchronisation de répertoire et un double transfert Université/clef USB puis Clef USB/PC perso. Cela a demandé une grande rigueur et une grande coordination de l’équipe, chacun gérant ses propres transferts en vue de travailler à domicile. La re-synchronisation du travail individuel sur le réseau de l’université se faisait toujours à deux, avec, établissement de la séquence de transfert sur papier, puis après validation de celle-ci, exécution de la séquence par l’un des membres sous la

9/46


supervision de l’autre. Cette procédure peut sembler lourde mais elle est plus longue à décrire qu’à effectuer. Elle nous a affranchis des problèmes de mise à jour partielle, d’écrasement de version, etc. Elle palliait à l’absence d’un logiciel de versionning comme CVS ou Visual Source Safe.

4.2.6 Gestion du logiciel Les caractères génériques, modulaires et multi plateforme du projet nous ont orientés, vous le verrez par la suite sur les technologies JAVA, ODBC, et client léger. La plateforme Window2000/XP, maîtrisée et disponible pour tous (équipe et client) permet de tel développement. La documentation et le suivi du projet ont été effectués avec les « classiques » de la suite Office et du standard PDF pour leurs caractères standard et « universels ». Il est à noter que nous avons, en cours de projet, abandonné le JDK JBuilder de Borland, lourd et complexe, pour migrer avec succès sur Eclipse, SDK open source, très convivial et puissant.

10/46


5 Conception : les bases

5.1 Reformulation des objectifs Comme vous l’avez lu dans le chapitre sur le management de projet, la reformulation du projet a été notre premier travail. En voici le résumé.

5.1.1 Enoncé du sujet Projet L’objectif de ce projet est de développer en langage c ou c++ une application générique utilisant le théorème de Bayes de façon à ce qu’il puisse être appliqué de manière générique pour un cas donné.

Extension 1 : Développer en PHP ou java une interface web pour piloter le programme et afficher des statistiques

Extension 2 : Développer un module serveur permettant à l’application de recevoir ses paramètres et ses données depuis d’autres machines sur le réseau.

5.1.2 Synoptique de l’application et de ses extensions

Ce schéma très général est important car il délimite bien le projet. Il va rester tout au long du développement une référence simple et un but. Ses articulations seront la base de la modularité du projet.

5.1.3 Orientation du projet Approche : De façon à répondre le plus efficacement possible, notre approche va s’articuler autour des trois axes suivants : Généricité, Ouverture, Modularité

APPLICATION GENERIQUE

IHM locale

Internet

IHM WEB

Réseau

Client

Serveur web Serveur

Légende : Application de base Extension 1 Extension 2

11/46


Notion de généricité : Les applications possibles du théorème de Bayes sont très nombreuses et diverses. L’objectif du projet n’est pas de réaliser une application utilisant cette méthode dans un et un seul domaine spécifique. L’application devra idéalement être capable de traiter la diversité des problématiques bayesiennes de manière générique. Exemples : le diagnostic d’une maladie, les anti-spams, la catégorisation, …

Notion d’ouverture : Une fois l’application développée, la prise en charge d’une nouvelle interface ne doit pas remettre en cause la conception initiale. La description des extensions 1 et 2, est interprétée comme une demande de nouvelles interfaces.

Notion de modularité Aux vues des contraintes de généricité et d’ouverture, cette application se doit d’être modulaire.

Choix de langage, plate-forme Notre tuteur Guillaume Schachtele propose le langage C ou C++, mais n’exclut aucun langage. De même la plate-forme est libre de choix.

5.2 Apprentissage du domaine statistique Bayesien Avant toute chose, il nous a fallu apprendre un minimum de théorie sur les statistiques et le théorème de Bayes en particulier. A part Jihad qui avait un bon bagage mathématique, nous étions des novices en matière de probabilité. Grâce à la gentillesse de Cendrine Chaffaut et Sarah Zohars, deux statisticiennes professionnelles du CHU Saint Louis à Paris, nous avons obtenu un cours de probabilités ainsi que les éclaircissements nécessaires à sa compréhension. Nous avons complété notre connaissance théorique des probabilités grâce à quelques sites Internet très didactiques comme www.homeomath.com et fr.wikipedia.org. Outre l’appropriation du domaine, cette phase nous permit la délimitation du périmètre du projet. Le domaine étant très vaste, nous n’avons pas la prétention d’inclure dans ce rapport un cours de statistique complet. Mais nous allons succinctement décrire ci-dessous les différentes notions utiles à la compréhension de notre projet, étayées de quelques exemples.

5.2.1 Quelques définitions Pour illustrer ces notions de probabilité nous utiliserons toujours le même exemple : le jet d’un dé à 6 faces.

Epreuve ou expérience aléatoire C’est une expérience pouvant être répétée dans des conditions identiques et dont l'issue n'est pas prévisible à priori. (Le jet d'un dé en regardant le nombre correspondant sur la face supérieure est une expérience aléatoire ou une épreuve)

12/46

http://www.homeomath.com/

http://fr.wikipedia.org/

http://homeomath.imingo.net/simulation.htm


Univers Il est associé à une expérience aléatoire: ensemble des cas possibles d'une expérience aléatoire. L'univers est généralement noté Ω. Exemple: Ω= 1, 2, 3, 4, 5, 6

Eventualité, cas possible C’est le résultat d'une épreuve, noté généralement ω1, ω2, .... Exemple: 1, 2, 3, 4, 5, 6 sont les éventualités de l'expérience aléatoire du jet de dé.

Evénement C’est une partie de l'univers. Exemple: "obtenir un nombre pair" est un événement, A = 2,4,6. Un événement est un ensemble (d’éventualités) Si une éventualité appartient à un événement, on dit qu'elle réalise cet

événement. L'événement particulier Ω est un événement particulier puisqu'il

contient toute les éventualités d'une même expérience aléatoire, il est donc toujours réalisé on l'appelle événement certain.

Aucune éventualité n’appartient à l'événement ø, il est donc jamais réalisé, ø est appelé événement impossible.

Evénement élémentaire C’est un événement réduit à une seule éventualité. Exemple: "obtenir 6" est un événement élémentaire, B= 6

Opérations sur les événements Les événements étant des ensembles on peut définir les mêmes opérations que sur les ensembles. C'est-à-dire la complémentarité, la réunion, l’intersection, etc.

Evénements incompatibles Si A B = , les événements A et B sont dit incompatibles, il ne peuvent pas se réaliser en même temps. Exemple soient A et B: A : "Obtenir un nombre<3 «, A = 1, 2 B : "Obtenir un nombre >3", B = 4, 5, 6 A B : "Obtenir un nombre < 3 et >3" et A B = .

Probabilités On définit généralement une probabilité comme "le rapport entre le nombre de cas favorables et le nombre de cas possibles". Prenons un dé honnête à 6 faces et lançons-le deux fois. La probabilité d'obtenir un double six sera alors de 1/36 (une seule combinaison favorable sur les 36 résultats possibles des 2 lancers) tandis que celle d'obtenir un neuf sera de 4/36 (9=6+3=3+6=4+5=5+4). Les choses se compliquent quand il s'agit de courses de chevaux: s'il y a 8 chevaux au départ, chacun n'a pas une probabilité 1/8 de gagner

5.2.2 Thomas Bayes et son théorème Le révérend Thomas Bayes (1702-1760), pasteur et mathématicien anglais, a exposé sa théorie des probabilités dans un essai publié à Londres en 1764, après sa mort, par la Royal Society dont il était membre depuis 1742. Le théorème de Bayes est une conséquence immédiate de la loi de composition des probabilités (qui est

13/46


nécessairement un des axiomes fondamentaux de toute théorie des probabilités). Si A et B sont deux événements, cette loi de composition des probabilités

(B|A) = P(B) P(A|B) rver A sachant que B s'est réalisé". Cette

yes. Ce théorème se généralise sans peine au

e manière plus précise on dit :

indique que la probabilité P(AB) d'observer à la fois A et B est simplement donnée par: P(AB) = P(A) Poù P(A|B) se lie "probabilité d'obseéquation implique immédiatement: P(B|A) = P(B) P(A|B)/P(A) qui est le théorème de Bacas de plusieurs événements A, B, C, D, etc. DSoit un univers décomposé en n événements élémentaires (donc

incompatibles) (c'est à dire une partition de ) et soit p une probabilité sur , on a alors pour tout événement M (de probabilité non nulle):

5.2.3 Exemples d’application du théorème Ebriété Un conducteur sobre a 1 chance sur 1 000 d’avoir un accident

que le conducteur soit

Un conducteur ivre a 1 chance sur 50 d’avoir un accident Un conducteur sur 100 conduit en état d’ivresse

Un accident vient d’arriver, quelle est la probabilitéivre ?

17% des accidents impliquent un conducteur ivre !

14/46


« Faux positifs » médicaux Le test médical d'une maladie rare est considéré comme fiable à 99%. Cette maladie touche une personne sur 100 000 dans la population. Vous effectuez le test. Il se révèle positif.

Pas de panique ! Sous la forme donnée, ce problème simplifié, et même caricaturé, nous indique que sur un million de personnes, dix mille (1%) seront considérées comme atteintes alors que 10 seulement (une sur 100 000) sont atteintes de la maladie. Ce test fiable à 99% donne, dans le cas où il est positif, heureusement 999 fausses alertes sur 1000.

5.2.4 Conclusion Nous avons maintenant une connaissance du théorème de Bayes et de ses domaines d’application vastes et multiples.

5.3 Prospection sur l’Etat de l’art Avec en tête une première idée des attentes du client et les bases théoriques nécessaires, nous avons prospecté, principalement via Internet pour connaître les applications bayésiennes génériques du marché ou universitaire. Nous en avons trouvé trois : BUGS, Probayes et Bayesia. Elles partagent leur généricité et les ressources humaines impliquées dans le développement, aussi bien qualitatives (statisticiens, chercheurs, mathématiciens, informaticiens, etc.) que quantitatives (de l’ordre de 100 années/hommes). Voici une rapide description de chacune d’entre elle.

5.3.1 B.U.G.S Le projet BUGS (Bayesian inference Using Gibbs Sampling) tourne autour d’un moteur flexible d’analyse bayesienne de modèles statistiques complexes utilisant la méthode MCMC (Markov Chain Monte Carlo). Ce projet a débuté en 1989 au MCR Biostatistics Unit a abouti à plusieurs logiciels dont le programme `Classic' BUGS, puis WinBUGS. Le développement continue de nos jours avec la version OpenBUGS développée à l’université d’Helsinki. Toutes ces versions ont en commun leur généricité mais aussi le niveau élevé requis pour leur manipulation, et leur apprentissage (Elles utilisent un langage propriétaire pour les programmer). Le survol de ce projet nous a surtout permis de limiter le domaine de notre étude en le centrant sur des notions statistiques basiques.

5.3.2 La solution Bayesia Le logiciel Bayesialab permet la modélisation et la simulation de systèmes complexes. Il exploite les réseaux Bayésiens dynamiques qui constituent l'outil de modélisation idéal pour représenter de manière compacte de tels processus. Domaines d’application proposés par le logiciel Modélisation de systèmes complexes (processus industriels) Analyse globale de risque et politique de sécurité (réseau de transport

ferroviaire) Marketing (élaboration d’un profil client face à un produit ciblé) Risk manager

15/46


Data Mining des bases clients (marketing et gestion des fraudes) Détection des intrusions Analyse des trajectoires de santé

Le produit comprend un algorithme d’apprentissage qui permet de construire le réseau bayesien. BayesiaLab dispose de nœuds Décision pour la modélisation des actions. BayesiaLab offre ainsi une palette complète et totalement inédite d’outils de gestion du risque à la fois très puissants et à la portée de tous. Les résultats peuvent se présenter sous différents formats en fonction du domaine d’application (%, graphe,…) Pour conclure, le principal avantage de cette approche réside dans le fait que le système fournit des probabilités en sortie. Il est alors possible de gérer le compromis entre précision et sensibilité, simplement en ajustant les probabilités « seuil. » Enfin, cette approche devrait permettre aux analystes de sécurité des réseaux de mesurer l'influence de chaque paramètre sur la variable cible dans le modèle de détection.

5.3.3 La solution Probayes Cette application permet de classer des textes suivant leur contenu. On peut arriver à les différencier, les sélectionner, les catégoriser… Le système fonctionne suivant 2 modes, l’apprentissage et la classification: En phase d’apprentissage, on indique dans une base de données des

couples correspondant à des observations avérées (exemples + étiquetages). Un mode d’apprentissage incrémental permet d’enrichir au vol les connaissances de l’application en lui fournissant des couples Texte–Classe : (S1=x, S4=y : Classe2)

En classification, l’application prend un texte et fournit en retour les classes avec leurs probabilités respectives (Classe1 = 0.3, Classe2 = 0.7).

La figure ci dessous montre l’intégration pratique du module PTC :

16/46

http://www.bayesia.com/FR/produits/bLab/BLabPolitiques.php

http://www.bayesia.com/FR/produits/bLab/BLabAnalyse.php


5.3.4 Conclusion sur les applications existantes Les applications utilisant le théorème de Bayes sont en pleine expansion. Beaucoup de domaines peuvent exploiter ces étonnantes propriétés : anti-spam, logique floue, prévisions etc. Le théorème de Bayes est présent partout dans notre quotidien.

5.4 Concertation avec le client sur l’orientation du Projet Après ce tour d’horizon des applications génériques et en avoir pris plein les yeux, nous nous sommes sentis tout petits ! Quelle arrogance ou quelle folie de notre part de vouloir rivaliser avec des statisticiens, des experts, sur des domaines si pointus, et sans connaissance préalable ! Nous sommes revenus vers notre client pour le tenir informer de nos découvertes et lui demander des précisions sur ses attentes. Il nous a confirmé qu’il attendait une solution concrète, modulaire et générique, avec une analyse la plus exhaustive possible. Il espérait également une réutilisation de notre travail. Dans la mesure où nous respections ces demandes, nous avions carte blanche pour définir notre projet. Avec le peu de temps imparti au projet, nous devions donc nous concentrer sur la conception et certainement prévoir un découpage de l’application en plusieurs phases de développement.

17/46


6 Conception : l’application idéale Pour tracer le portrait robot d’une application générique idéale, nous avons fait un inventaire des données utilisées et des services proposés par les applications existantes.

6.1 Inventaires des données Nous allons décrire ici les données informatiques généralement associées aux applications génériques

6.1.1 Evénement et Eventualité Un événement est constitué de Son nom comme « avoir de la fièvre » ou « Noël au balcon ». Dans la

mesure où il est unique, le nom de l’événement a un rôle d’identifiant de l’événement.

Ses éventualités, avec nom, valeur (%), cardinalité etc. Dans les cas simples les éventualités d’un événement se réduisent à 2 (Vrai ou Faux).

Son coût général d’acquisition. Cette notion permet, lors de la résolution d’un problème par un système expert, de poser les bonnes questions et d’optimiser les acquisitions de données. Le coût d’acquisition se décompose généralement en trois attributs : le prix, la durée, et le risque.

6.1.2 Connaissance La connaissance (aussi appelée « a priori ») est l’ensemble des données connues qui permettent de calculer une probabilité conditionnelle avec le théorème de Bayes. En pratique, la connaissance est une base de données constituée d’événements, de probabilités, etc. Selon les applications, cette connaissance peut ou non évoluer. Précisons ci-dessous cette notion :

Connaissance statique Certaines applications se contentent d’exploiter une connaissance sans que l’utilisateur puisse la mettre à jour. La création, ou la mise à jour de la connaissance est entièrement à la charge des concepteurs du système. Voici deux exemples : Dans le cas de système expert, l’utilisateur n’a pas forcément les

compétences nécessaires pour valider le résultat du système et enrichir la base de données avec le cas qu’il vient de traiter.

Dans un système à logique floue comme la détermination du style de photo (voir exemple plus haut), l’utilisateur n’a là non plus aucune possibilité d’entrer le style réel de la photo.

Connaissance dynamique D’autres applications permettent à leurs utilisateurs de modifier la connaissance. Voici quelques exemples : Le cas le plus connu est celui du filtre anti-spam, où l’application va

prendre en compte les choix précédents de l’utilisateur (l’a priori au sens bayesien) pour affiner son pronostique.

18/46


La classification de messages en catégories (par exemple : sport, science, social, politique, etc.) est une version étendue du filtre anti-spam où un lot d’événements de « départ » permet d’obtenir un lot de probabilités (pour chaque catégorie)

Commentaires sur la connaissance Il est important de noter que la nature évolutive de ces applications, leur capacité à ‘apprendre’ peut faire penser à de l’intelligence artificielle. Cependant les décisions de modification de la connaissance sont toujours du ressort de l’utilisateur. A partir de l’a priori fourni par l’utilisateur, ces applications proposent, sans aucun raisonnement, la solution que l’utilisateur aurait probablement choisie.

6.1.3 Probabilité et Cardinalité Probabilité d’une éventualité Une probabilité est un nombre réel souvent exprimé en pourcentage qui indique donc la probabilité d’une éventualité dans l’univers.

Cardinalités des éventualités Les données des problèmes soumis aux applications utilisant le théorème de Bayes sont souvent des cardinalités (issues de statistiques). Par exemple, on connaît le nombre E d’événements vrais sur une population P. Les probabilités des événements sont calculées à partir des cardinalités, et les cardinalités n’interviennent plus dans le calcul des probabilités conditionnelles. Cependant, si on ne connaît pas au minimum la cardinalité de la population dont est issue une probabilité, il sera impossible de mettre à jour cette dernière. C’est pourquoi, bien qu’inutiles au calcul final, les cardinalités doivent être conservées pour gérer une connaissance dynamique.

Probabilité conditionnelle entre deux éventualités Une probabilité conditionnelle est un nombre réel souvent exprimer en pourcentage qui relie une éventualité «Cible» à une éventualité «Condition» selon la formule de statistique : P (Cible|Condition).

6.1.4 Cas Un cas synthétise le problème à soumettre à l’application. Il est constitué : D’un contexte : Une ou plusieurs éventualités connues, les

«Conditions» décrivant le contexte du cas à étudier. De cibles : Une ou plusieurs éventualités recherchées, les « Cibles »,

dans le cas à étudier. De choix : Dans le but d’enrichir la base de connaissances en y ajoutant

les résultats réels du cas étudié, l’utilisateur peut indiquer ce résultat pour chaque événement cible.

Eventuellement le nom du cas (son identifiant). Celui-ci sera utile si le cas est archivé soit pour être reproposé ultérieurement à l’application (avec une connaissance enrichie) soit pour revenir sur le choix de l’utilisateur et mettre à jour la connaissance en conséquence.

19/46


6.1.5 Hiérarchisation des cas Les cas sont hiérarchisés comme suit :

Cas simple : Il concerne 1 éventualité Cible par rapport à 1 éventualité Condition, et s’appuie sur le théorème de Bayes pour obtenir la probabilité conditionnelle associée.

Cas multiple : Il concerne 1 éventualité Cible par rapport à N éventualités Conditions. C’est donc un ensemble de cas simples. La probabilité résultat d’un cas multiple est la combinaison des probabilités conditionnelles des cas simples

Cas général ou Cas Il concerne N éventualités Cibles par rapport N éventualités Conditions. C’est donc un ensemble de cas multiples partageant les mêmes éventualités Conditions. Il sert avant tout pour manipuler d’un seul coup des cas multiples.

6.2 Inventaires de services. A partir de l’examen de ces différentes applications et théories, nous avons répertorié les principales fonctions ou services qu’une application générique devrait idéalement assurer. On distingue 3 types de services : l’apprentissage de la connaissance, le calcul de probabilité conditionnelle et l’exploitation de la connaissance

6.2.1 L’apprentissage de la connaissance L’apprentissage est le terme générique pour désigner l’ensemble des fonctions qui modifient cette connaissance. On distingue deux types d’opérations sur la connaissance.

L’apprentissage des événements et éventualités C'est-à-dire la création, modification ou suppression d’événements et éventualités dans la base.

L’apprentissage des probabilités C’est la création, modification, suppression directe ou indirecte des probabilités liées aux événements de la base de connaissance. La combinaison des apprentissages direct et indirect est possible. Apprentissage direct

C’est la création, modification, suppression directe des probabilités des événements de la base.

Apprentissage indirect C’est la création, modification, suppression des cardinalités liées aux

événements de la base, le plus souvent en fonction d’un cas précis. Quand l’utilisateur choisit d’enrichir ou d’appauvrir la base avec un cas traité, il incrémente ou décrémente les différentes cardinalités ce qui indirectement modifie les probabilités.

20/46


6.2.2 Hiérarchisation des événements Les relations de probabilités entre les événements permettent de manière indirecte de hiérarchiser les événements. En effet, un événement peut être « cible » pour rapport à l’un et « condition » par rapport à un l’autre. Par exemple : Soit les événements M pour « problème Moteur » E pour « panne Essence » B pour « problème Batterie » L pour « problème Liquide Batterie » C pour « problème Cosses Batterie » Alors, L’événement B peut être une cible par rapport à L ou C L’événement B peut être une condition par rapport à M

6.2.3 L’historique de l’apprentissage Garder un historique des modifications de la base permet de revenir en arrière pour corriger une de ces modifications. Attention : chaque apprentissage modifie le comportement de l’application, mais ceci n’implique pas de re-traiter tous les cas déjà soumis pour obtenir de meilleurs résultats. C’est la nature même des applications génériques exploitant le théorème de Bayes de travailler à partir de données incomplètes ou confuses.

6.3 Les calculs Voici les différents calculs réalisés par les applications génériques

6.3.1 Calcul de la probabilité conditionnelle Ce traitement gère le cas « Une Cible Une Condition ». Il permet d’obtenir par le théorème de Bayes, la probabilité conditionnelle d’un événement cible en fonction d’un événement condition.

6.3.2 Calcul de combinaisons de probabilités Ce traitement gère le cas « Une Cible Plusieurs Conditions ». Il permet d’obtenir la probabilité globale d’un événement cible dans un contexte où plusieurs événements condition sont connus. Il combine les probabilités conditionnelles d’un même événement cible par rapport à différentes éventualités connues du contexte.

6.3.3 Hiérarchisation des calculs Ce traitement gère le cas « Plusieurs Cibles Plusieurs Conditions ». Son rôle est de décomposer ce cas en autant de « Une Cible Plusieurs Conditions ». Il doit tenir compte des liens hiérarchiques entre les événements.

6.4 Exploitation de la connaissance Cette fonction permet toutes opérations sur la base de connaissance pour en extraire par exemple les évènements les plus spécifiques ou les plus sensibles etc. Après examen de la base de connaissance, un système expert pourra proposer d’acquérir tel événement plutôt qu’un autre en fonction

21/46


de critère de coût, risque ou délai. C’est un domaine très utile pour l’aide à la décision, le data mining, etc.

22/46


7 Conception : une architecture modulaire A partir de tous ces éléments, fonctionnalités et contraintes, nous avons défini une architecture théorique permettant de réaliser le projet et ses extensions. Cette architecture sera notre objectif pour le projet même si nous savons que nous n’aurons pas le temps de tout réaliser voir même de tout concevoir. Les différentes phases de développement définies seront décrites aux chapitres suivants.

7.1 Schéma théorique

Voici le schéma de l’architecture idéale. Chacun des modules est un système complet et indépendant, qui dialogue avec les autres

7.2 Définition des modules Nous allons détailler les rôles des différents modules de l’application.

7.2.1 Le module base de donnée : La Connaissance sera gérée par une base de donnée relationnelle moderne (SQL) et accessible via un middleware (ODBC ou JDBC). Elle devra conserver les événements, les probabilités et cardinalités nécessaires au calcul de probabilités conditionnelles. Les événements pourront avoir 2 à n éventualités. Une hiérarchisation des événements sera possible (pour gérer des systèmes experts)

IHM Edition Evénements

IHM Edition Probabilités

IHM Edition Cas

Analyse de Cas Multi Cible Multi Condition 1) Analyse compatibilité des Conditions 2) Analyse hiérarchique des événements cibles 3) Pour chaque cible Appeler Cas Mono Cible 4) Retour IHM Soumission

d’un Cas

IHM Aide sur Cas

Client ou Automate sur le réseau

Serveur WEB

XML sur TCP/IP

XML sur TCP/IP

XML sur TCP/IP

Parser XML

ODBC JDBC

IHM Paramétrage

Analyse de Cas Mono Cible Multi Condition 1) Pour chaque couple Cible – Condition 1.1) Récupérer les probabilités requises 1.2) Calculer la probabilité conditionnelle 2) Combiner les probabilités

Intégrité de la Connaissance Gestion incrémentale Demande statistique etc.

SQL sur xDBC

AArrcchhiitteeccttuurree tthhééoorriiqquuee dduu pprroojjeett MMiissee eenn œœuuvvrree dduu tthhééoorrèèmmee ddee BBaayyeess aavveecc sseess eexxtteennssiioonnss

23/46


La base de données devra conserver également les cas soumis et traités par l’application.

7.2.2 Le module d’Analyse d’un Cas Ce module devra analyser un cas à traiter pour le décomposer en cas simple de calcul de probabilité conditionnelle d’une éventualité d’événement « condition » vis-à-vis d’une éventualité d’événement « cible ». A partir de son accès à la base de données, il peut analyser la cohérence du cas à traiter puis la hiérarchisation des probabilités conditionnelles à trouver. Il reçoit ses ordres et retourne ses résultats au module Parser XML Il donne des ordres de calcul de probabilités conditionnelles au module d’Analyse d’un Cas Mono Cible et combine les résultats de ce dernier.

7.2.3 Le module d’Analyse d’un Cas Mono Cible Ce module est la brique de base de l’application. Il effectue le fameux calcul de probabilité conditionnelle en appliquant le théorème de Bayes. Il a accès à la base de données pour récupérer les probabilités concernées.

7.2.4 Le module Parser XML Pour communiquer soit avec des IHM ou d’autres processus clients, l’application utilise un protocole propriétaire encapsulé dans du XML et transporté sur TCP/IP. Le XML et le TCP/IP ont été choisis pour leur caractère standard. Ce module interprète les ordres des interfaces et les aiguille vers les modules adéquats, soit pour des opérations sur la base, soit pour des traitements.

7.2.5 Le module Intégrité de la Connaissance Ce module gère l’intégrité applicative de la base de données. A noter: La place exacte et le rôle exhaustif de ce module ne sont pas complètement définis à ce jour. A priori ce module servirait à centraliser la génération de requêtes SQL pour simplifier le dialogue XML avec les interfaces.

7.2.6 Le module Serveur WEB Dans le cadre de l’extension 1, une IHM via le web est demandée. Par soucis d’homogénéisation, on utilisera systématiquement des IHM WEB pour dialoguer avec l’application y compris dans le cas d’IHM locales.

7.2.7 Le protocole de communication PCB Le dialogue client/application n’est pas à proprement parlé un module. Il sera formalisé par un protocole propriétaire lui-même encapsulé dans du XML puis transporté sur TCP/IP. En tant que protocole, il formalisera les échanges avec les IHMs ou d’autres machines sur le réseau (extension 2). Ce protocole sera appelé PCB pour Protocole de Communication Bayesien.

7.2.8 IHM Edition d’Evénement Permet d’éditer, modifier, supprimer des événements et leurs attributs. Idéalement codé en JAVA, dialoguant grâce au PCB avec l’application.

24/46


7.2.9 IHM Edition de Probabilité Permet d’éditer, modifier, supprimer des probabilités et cardinalités éventualités d’événements. La mise en relation d’éventualité d’événement permet une hiérarchisation de ces derniers. Idéalement codé en JAVA, dialoguant grâce au PCB avec l’application

7.2.10 IHM Edition de Cas à traiter Permet d’éditer, modifier, supprimer des cas. Permet également de mettre à jour (par incrémentation ou décrémentation) la base de données. Idéalement codé en JAVA, dialoguant grâce au PCB avec l’application.

7.2.11 IHM Soumission de Cas Permet de soumettre un cas à l’application pour obtenir une probabilité. Ce module ressemble beaucoup au précédant mais ne fait pas la même chose. Si cette modularité était préjudiciable, ce module et le précédant pourraient être fusionnés. Idéalement codé en JAVA, dialoguant grâce au PCB avec l’application

7.2.12 IHM Paramétrage (ou Administration) Permettra l’administration de l’application. Idéalement codé en JAVA, dialoguant grâce au PCB avec l’application

7.3 Conclusions Cette architecture respecte parfaitement les besoins de modularité et d’ouverture voulue par le client. Mais dans le cadre du master2 CCI, sa réalisation complète n’est pas possible, faute de temps. Nous allons découper sa réalisation en phases pour pouvoir proposer à notre client la réalisation concrète d’un sous ensemble du projet, premières pierres de l’édifice.

25/46


8 Phasage et Planification

8.1 Phase 1 Cette première phase définit le strict minimum pour respecter la base du projet. Ce sera une application à part entière, fonctionnelle. En plus de sa qualité de « livrable », elle a pour but de : Valider définitivement le modèle générique de données. Valider définitivement le moteur et ses traitements. Valider quelques IHM.

Nous allons commenter cette architecture par rapport à l’architecture théorique idéale vue précédemment.

8.1.1 Schéma

8.1.2 Le module base de données : La base de donnée utilisée sera ACCESS, choisie pour ses facilités de « maquettage », sa disponibilité et sa maîtrise par l’équipe. Une fois le modèle de données validé, les requêtes SQL de génération de la base seront conservées pour garantir un portage vers d’autres SGBDR.

8.1.3 Les modules d’Analyse de Cas Ils sont semblables aux modules idéaux. Ils constituent ce que nous allons appeler « le moteur » puis nommer GBE (pour Generic Bayesian Engine). Dans un premier temps nous avions pensé les coder en VBA, qui est complètement interfacé avec ACCESS. Au final, nous les avons directement codés en JAVA, n’ayant eu aucune difficulté à maîtriser ce langage. Le dialogue entre le moteur et la base se fait via une connection JDBC/ODBC en SQL.



IHM Edition Cas

Analyse de Cas Multi Cible Multi Condition 1) Analyse compatibilité des Conditions 2) Analyse hiérarchique des événements cibles 3) Pour chaque cible Appeler Cas Mono Cible 4) Retour

IHM Soumission d’un Cas

ODBC JDBC


SQL / ACCES

ACCESS

AArrcchhiitteeccttuurree PPhhaassee 11 dduu pprroojjeett MMiissee eenn œœuuvvrree dduu tthhééoorrèèmmee ddee BBaayyeess BBuuttss :: VVaalliiddaattiioonn dduu mmooddèèllee ddee ddoonnnnééeess,, ddeess ttrraaiitteemmeennttss ssiimmpplleess eett ddee qquueellqquueess IIHHMMs

26/46


Le dialogue entre le moteur et les IHM se fait par les arguments de la ligne de commande lors de l’appel du moteur par les IHM.

8.1.4 Les IHM Elles sont moins nombreuses que celles de l’application idéale. Seul subsiste le minimum vital pour renseigner le référentiel et soumettre un cas. Elles seront codées à partir de formulaires ACCESS. Le dialogue avec la base est nativement pris en charge par ACCESS. Elles sont semblables dans leurs fonctionnalités a celles de l’application idéale. Sont prévus : IHM Edition d’événements et d éventualités IHM Edition de Probabilité conditionnelles IHM Edition de Cas à traiter IHM Soumission de Cas

8.2 Phase 2 La deuxième phase s’affranchit de la nécessité d’ACCESS aussi bien en tant que SGBDR qu’en tant qu’IHM. Les IHMs sont portées en JAVA et dialoguent avec du XML sur TCP/IP. On distinguera deux versions des IHMs, la première continuant à utiliser du SQL encapsulé dans XML+TCP/IP et la deuxième se servant de PCB, le protocole de communication propriétaire axé sur le domaine bayésien. Le module «Parser XML» est implémenté. Outre la gestion des couches TCP/IP et XML, il interprète les commandes des clients via le protocole PCB de l’application.

8.2.1 Schéma

8.2.2 Détails Seules les grandes lignes de la phase 2 sont connues, le principe étant d’arriver par étapes successives au modèle idéal.



IHM Edition Cas

Analyse de Cas Multi Cible Multi Condition 1) Analyse compatibilité des Conditions 2) Analyse hiérarchique des événements 3) Pour chaque cible Appeler Cas Mono Cible 4) Retour

IHM Soumission d’un Cas

IHM Aide sur Cas

XML sur TCP/IP

Parser XML ODBC

JDBC

IHM ...


Intégrité de la Connaissance Gestion incrémentale Demande statistique etc...

SQL sur ODBC

AArrcchhiitteeccttuurree PPhhaassee 22 dduu pprroojjeett MMiissee eenn œœuuvvrree dduu tthhééoorrèèmmee ddee BBaayyeess BBuutt :: VVaalliiddaattiioonn pprroottooccoollee XXMMLL,, vvaalliiddaattiioonn ddee llaa ggeessttiioonn ddee ll’’iinnttééggrriittéé ddee llaa bbaassee

27/46


La mise en œuvre idéale de ce projet devrait savoir prendre en charge tout type de données susceptibles d’enrichir notre référentiel en plus des IHM que nous avons développées.

8.3 Contrat avec le client : la Phase 1 Mi janvier nous présentons notre étude préalable au client et nous lui proposons un cahier des charges visant à réaliser la phase 1 du projet. Ce cahier des charges est validé. La réalisation commence.

28/46


9 Réalisation : La base de données La modélisation des données fut la première étape de notre réalisation. C’est la colonne vertébrale de l’application sur laquelle tous les modules s’appuient. Nous avons utilisé l’outil Win’Design.

9.1 Modèle Conceptuel de Données Nous avons utilisé la méthode Merise et son modèle conceptuel de donnés pour modéliser les données de l’application générique. L’outil informatique utilisé fut Win’Design. Notre travail de recherche nous a permit de trouver et d’optimiser le MCD assez vite. Sa première version ne comprenait pas l’entité cas multiple, que nous avons rajoutée en cours de développement. C’est la version finale qui est présentée ici. Il est à noter que certains identifiants d’entité sont des noms (d’événement ou d’éventualité) plutôt que des numéros dans un double but : éviter la redondance numéro unique/nom unique, et surtout faciliter les tests et la validation avec des requêtes SQL « lisibles » (les noms étant plus parlant que les numéros).

Schéma du MCD :

29/46


9.2 Modèle Logique de Données A partir du MCD, Win’Design automatise les tâches de création du Modèle Logique de Données. Nous avons simplement eu besoin de retoucher certains noms générés. Le modèle logique met bien en évidence les cinq entités/tables/objets que l’on retrouve partout dans le projet.

Schéma du MLD :

9.3 Génération et validation de la base. Là encore Win’Design automatise cette tâche en générant la base de données au format ACCESS, dans un ficher BAYES.MDB. A ce stade, nous avons passé en revue tous les services idéaux précédemment inventoriés dans l’étude préalable pour vérifier que la base satisfaisait à toutes ces exigences.

30/46


10 Réalisation : le Moteur Bayesien

10.1 Langage et outils de développement Le moteur a été développé en JAVA, par Michaël qui connaissait déjà la programmation en C++ et la conception Objet. Le sdk JBuilder 2005 de Borland a été utilisé au départ car gratuit, installé sur les machines de l’université, et utilisé dans le cadre des cours JAVA de M Roland Renier. Cependant après quelques semaines nous avons découvert Eclipse, un environnement Open Source très puissant et bien mieux optimisé que JBuilder. Après un essai de migration rapide et indolore du projet sous Eclipse nous avons complètement adopté ce sdk.

10.2 Définition du Moteur Le moteur a pour rôle de calculer la ou les probabilités conditionnelles demandées dans un cas. Nous l’avons appelé GBE pour Generic Bayesian Engine.

10.3 Données en entrée

10.3.1 Ligne de commande Dans la phase 1, le GBE lit ses ordres via la ligne de commande. Il fonctionne donc « au coup par coup » : A chaque lancement, il traite un cas puis se termine. Ce lancement peut être effectué de 3 manières : • depuis une console ou un shell. • depuis l’environnement de développement Eclipse. • Indirectement via un formulaire ACCESS La ligne de commande contient au minimum le numéro du cas à traiter (c'est-à-dire son identifiant dans la base) A partir du numéro de cas, le GBE ira chercher les informations nécessaires au calcul. Grâce à sa 2ième entrée :

10.3.2 Connexion JDBC/ODBC C’est par le biais de cette connexion que le GBE pourra retrouver tous les éléments du calcul à effectuer. Cette connexion peut être paramétrée depuis la ligne de commande en indiquant le nom de la source de donnée ODBC. Avec Windows, la création/modification d’une source de données se fait via le menu Démarrer / Panneau de Configuration / Outils d’Administration / Source de Données (ODBC) II est à noter que si le GBE ne peut établir la connexion ODBC, ou si la structure de la base de données connectée ne correspond pas strictement à celle attendue, le GBE se termine immédiatement avec un message d’erreur. Cette vérification automatique et systématique des méta données de la base a pour but de lever toute ambiguïté sur l’intégrité des résultats du GBE.

31/46


10.3.3 Socket TCP/IP Nous avons vu que dans les phases ultérieures, le GBE sera à l’écoute de commandes via une socket TCP/IP. Dans la phase 1, seule la méthode de paramétrage du port de cette socket est prévue via la ligne de commande.

10.4 Données en sortie

10.4.1 Connexion JDBC/ODBC Nous n’allons pas revenir ici sur la structure de la base de données. Il suffit de se rappeler qu’un cas possède un champ d’erreur et que les cas multiples et simples auxquels il est associé possèdent eux aussi un champ d’erreur et en plus, un champ résultat. Ainsi le GBE, après un calcul met à jour différents champs (résultat, erreur éventuelle et horodate) dans la base de données connectée.

10.4.2 Console et Fichier de log Le GBE utilise la sortie standard (sur une console ou un shell) en parallèle avec un fichier de log (en ascii) généré dans son répertoire de travail. • Cela assure une traçabilité hors environnement de développement. • Cela permet des tests du GBE indépendamment de tout IHM

Voici un exemple du fichier de log GBE.LOG: STD: ------------------------------------------------------------------------------------- CFG: SmartOut : Launched on Sat Apr 16 18:29:14 CEST 2005 STD: ------------------------------------------------------------------------------------- STD: Program : Generic Bayesian Engine STD: Version : v1.10 Release STD: Created : 2005 Jan 23 STD: Compiled : 2005 apr 10 STD: Authors : Michaël Cambay STD: ------------------------------------------------------------------------------------- STD: Usage : java GBE [cas=n] [dbg_gen=1|0] [dbg_chk=1|0] [dbg_sql=1|0] [odbc=name] STD: Note : arguments are case unsensitive STD: Arguments : cas=n -> n is the case number to compute STD: dbg_gen=1|0 -> set|reset debug general code (else default) STD: dbg_chk=1|0 -> set|reset debug database check (else default) STD: dbg_sql=1|0 -> set|reset debug sql transactions (else default) STD: odbc=name -> name is the ODBC Data Souce Name (default=BAYES) STD: ------------------------------------------------------------------------------------- STD: line parse: cas=1 dbg_gen=1 dbg_chk=0 dbg_sql=0 odbc=BAYES_DEV STD: ------------------------------------------------------------------------------------- CFG: Filter STD: ON CFG: Filter ERR: ON CFG: Filter CFG: ON CFG: Filter DBG: ON CFG: Filter CHK: OFF CFG: Filter SQL: OFF STD: ------------------------------------------------------------------------------------- STD: Connexion : jdbc:odbc:BAYES_DEV OK STD: Database : Checked Ok STD: ------------------------------------------------------------------------------------- STD: CAS : n°1 (Prévision Méteo) inconnu : 60,0 % P(meteo[beau]) inconnu : 30,0 % P(meteo[nuageux]) inconnu : 10,0 % P(meteo[pluvieux]) connu : 30,0 % P(vent[calme]) a priori : 40,0 % P(meteo[beau]|vent[calme]) a priori : 30,0 % P(meteo[nuageux]|vent[calme]) a priori : 30,0 % P(meteo[pluvieux]|vent[calme]) connu : 50,0 % P(saison[seche]) a priori : 70,0 % P(meteo[beau]|saison[seche]) a priori : 40,0 % P(meteo[nuageux]|saison[seche]) a priori : 20,0 % P(meteo[pluvieux]|saison[seche]) STD: BAYESED : 66,667% P(vent[calme]|meteo[beau]) STD: BAYESED : 75,0 % P(saison[seche]|meteo[beau]) STD: COMBINED : 85,714% P(Connus|meteo[beau]) STD: BAYESED : 25,0 % P(vent[calme]|meteo[nuageux]) STD: BAYESED : 21,429% P(saison[seche]|meteo[nuageux]) STD: COMBINED : 8,333% P(Connus|meteo[nuageux]) STD: BAYESED : 8,333% P(vent[calme]|meteo[pluvieux]) STD: BAYESED : 3,571% P(saison[seche]|meteo[pluvieux]) STD: COMBINED : 0,336% P(Connus|meteo[pluvieux]) STD: ------------------------------------------------------------------------------------- STD: Program : Exit on Sat Apr 16 18:29:16 CEST 2005 STD: -------------------------------------------------------------------------------------

32/46


10.5 Diagramme de classe UML Le moteur GBE est complètement orienté objet. A partir du diagramme de classe de GBE, nous allons décrire les objets et leurs interactions.

Nous retrouvons dans ce diagramme des objets « métier » qui sont stockés dans la base de données. Ils ont les mêmes noms que les entités équivalentes du MCD. Eventualite, Evenement et ProbCnd dérivent directement de GBE_SqlObject. Cas, Cas_Multiple et Cas_Simple dérivent indirectement de GBE_SqlObject.

33/46


Les autres objets de l’application sont des utilitaires GBE_Database gère ODBC et les tests de cohérence de la base. GBE_ResultSet gère les ensembles de résultats SQL et encapsule les

exceptions. GBE_SqlObject factorise l’accès à la base pour tous les objets « métiers » GBE_Header affiche l’identité (nom, version, etc.) du GBE GBE_Usage affiche une aide sur la ligne de commande du GBE GBE_Main est le point d’entrée du GBE.

Enfin une dernière catégorie d’objets plus génériques est utilisée. Il sont réutilisables tels quels pour d’autres applications java. SmartOut centralise toutes les sorties console ou log. Il est configurable

pour filtrer à la volée tel ou tel type de données. C’est très utile pour debugger : on ne modifie pas le code mais seulement la configuration des filtres. Il a également un rôle de formatage et de normalisation de la sortie (indentation, saut de ligne, etc.)

SmartObject normalise le traitement des erreurs. Tout objet de l’application, ayant à gérer des erreurs, en dérive. Cela garantit une homogénéité de comportement. Ces fonctionnalités permettent d’éviter le recours à un traitement systématique des exceptions, toujours lourd à mettre en place.

SmartFraction est un petit objet facilitant la manipulation de fraction. Il est utilisé pour gérer le trio probabilité/cardinalité/population.

10.6 Cinématique du GBE L’orientation Objet, dont l’Encapsulation, a pour effet de répartir les traitements sur les différents objets du programme, chacun gérant uniquement ses données et ne connaissant que ses voisins immédiats. Ainsi dans le programme principal, le traitement d’un cas tient en deux lignes : la construction d’un objet Cas et l’appel de sa méthode Compute(). Par un effet de cascade, le Cas crée des Cas_Multiple qui créent à leur tour des Cas_Simple qui créent des Evenement qui créent des Eventualite etc. A la fin de la construction du Cas, toute erreur de création à été remontée et on sait si le calcul de la ou les probabilités conditionnelles est réalisable. De la même manière, l’appel de la méthode Compute() du Cas déclenche en cascade la méthode Compute() des Cas_Multiple, Cas_Simple etc. Le théorème de Bayes est codé dans la méthode Compute() du Cas_Simple. La combinaison des probabilités est dans Compute() du Cas_Multiple.

10.7 Conclusions Il n’y a pas eu de difficultés particulières pour ce développement. L’outil Open Source Eclipse est du meilleur niveau. La conception Objet est très souple et a permis d’intégrer sans effet de bord ni délai, l’objet Cas_Multiple que nous avons eu à ajouter dans notre MCD. On peut estimer le temps de développement et de test du moteur au alentour de 60h.

34/46


11 Réalisation : les interfaces Homme/Machine

11.1 Les outils et les objectifs Pour la phase 1, l’objectif des IHM est triple : Valider la base de données. Valider le moteur. Valider une interface minimum.

Chantal et Thierry ont conçu et programmé les IHM à l’aide des formulaires ACCESS, pour leur facilité de maquettage et leur possibilité de génération automatisée d’interface. Nous avons vu que dans la phase 2 du projet, ces IHM seront codées en JAVA et qu’un nouveau module du GBE centralisera les contrôles de cohérences et d’intégrité des données, allégeant ainsi la tâches des IHM. Dans cette optique, les IHM actuelles n’implémentent que des contrôles basiques et peu de contrôles de niveau applicatif.

11.2 Synoptique des Ecrans

Les IHM sont articulées autour de deux fonctionnalités qui peuvent être confiées à des personnes de profil différent : L’administration des données, partie la plus complexe, à réserver à

l’expert statisticien. Celui-ci doit entrer ses données selon la logique suivante : évènement, éventualités, probabilités conditionnelles. Tous ces écrans autorisent la création, modification,

Menu général

Exploitation Gestion des Evènements et Eventualités

Création d’un cas

Sélection d’un cas pour Exécution

Consultation des résultats

Gestion des probabilités conditionnelles

Visualisation d’un cas

Affichage des résultats

Exécution du moteur

35/46


suppression dans les tables ‘Evénement’, ‘Eventualité’ et ‘Probabilité - conditionnelle’.

L’exploitation, partie utilisateur permettant la création de cas, leur soumission et la consultation de résultats.

11.2.1 Ecran d’accueil

Ce formulaire est lancé en automatique au démarrage d’Access. Il permet d’orienter l’utilisateur vers les deux grandes fonctions. Tous les écrans possèdent un bouton ‘Aide’ donnant des conseils et des règles de gestion.

11.3 Administration de la base de référence

Cet écran gère à la fois les évènements et ses éventualités associées.

36/46


11.3.1 Gestion d’évènement : A un évènement donné on associe un nom, délai1, un prix, un risque, une population de l’étude et au moins deux éventualités

Sélection d’un évènement Par la boîte de dialogue ‘sélection/recherche’ Par les flèches ‘suivant’ ‘précédent’.

Création d’un événement Le bouton ‘création’ vide le formulaire pour préparer la saisie. Saisir ensuite le nouvel événement avec toutes ou parties de ces

propriétés. Après une création, le bouton ‘Actualiser’ rafraîchit la boîte de dialogue ‘sélection/recherche’

Suppression d’un événement Le bouton ‘suppression’ supprime l’évènement en cours.

11.3.2 Gestion d’éventualités: Seules les éventualités en rapport avec l’évènement en cours s’affichent. A une éventualité donnée on associe un nom, une probabilité et une cardinalité Important : Le total des probabilités des éventualités doit être égal à 1. Le total des cardinalités des éventualités doit être égal à sa population.

Sur chaque ligne existe un bouton ‘Voir les probabilités conditionnelles associées’ qui permet d’appeler l’écran suivant.

11.3.3 Gestion des probabilités conditionnelles.

Créer une probabilité conditionnelle entre deux éventualités d’événement, c’est associer ces deux éventualités, l’une en tant que « cible » et l’autre en tant que « condition. »

1 Dans la phase 1, ces données ne sont pas exploitées

37/46


L’éventualité « condition » est celle sélectionnée dans l’écran précédant, lors de l’appui le bouton ‘voir les probabilités conditionnelles associées’. Il est possible d’associer plusieurs évènements cibles à un évènement condition. Dans le corps de l’écran apparaissent tous les évènements et éventualités cibles déjà associés à l’évènement condition en cours. Il est possible d’en ajouter en utilisant les boîtes de dialogue situées en bas. La somme des probabilités des éventualités d’un évènement cible doit être égal à 1.

11.4 Menu d’exploitation Voici le menu d’exploitation pour soumettre les cas et visualiser les résultats :

Cet écran permet de : saisir un nouveau cas soumettre le cas saisi relancer un ancien cas sachant qu’on a modifié les probabilités

conditionnelles des évènements qui le composent consulter les résultats du cas traité.

38/46


11.4.1 Saisie d’un cas

La saisie d’un cas se compose de deux étapes : Sélection d’un évènement cible et une ou plusieurs éventualités

associées Sélection d’un ou plusieurs évènements condition et d’une éventualité

pour chacun Les évènements cibles et conditions sont proposés à partir de la table des probabilités conditionnelles préalablement renseignées au moyen des écrans précédents. Le programme reboucle sur la saisie des conditions, jusqu'à ce que l’utilisateur clique sur le bouton < fin de saisie >. Ce bouton entraîne la mise à jour des tables Cas, Cas_simple et Cas_multiple qui seront utilisées par le moteur Bayesien pour le calcul des statistiques et le stockage des résultats de ces calculs.

39/46


11.4.2 Soumission d’un cas

Cet écran est appelé par la saisie d’un cas la sélection d’un cas enregistré.

Il résume les données d’un cas à soumettre et propose sa soumission (au moteur GBE)

40/46


11.4.3 Sélection d’un cas pour afficher son résultat :

11.4.4 Visualisation d’un résultat

Euréka ! Le fameux résultat sur l’ivresse au volant (consternant ) s’affiche à l’écran.

41/46


12 Réalisation : Intégration, tests, recette

12.1 Intégration des modules L’assemblage des modules base de données, moteur et IHM n’a pas posé de problème. La connexion JDBC/ODBC, reliant le moteur à la base de données, a fonctionné rapidement dès le début du développement. Elle a été testée sur les PC de l’université, et sur nos PC personnels. La connexion des IHM à la base est native, donc pas de problème non plus. Enfin la connexion des IHM au moteur via un appel avec arguments a été sans soucis. On peut noter que la fonction de log du moteur GBE a été développée après la connexion avec l’IHM. En effet, hors de l’environnement Eclipse, le moteur affichait ses résultats sur une console temporaire qui se fermait trop rapidement pour voir quoi que ce soit.

12.2 Tests de l’application Les tests ont été pensés dès le début du projet et ont été appliqués à chaque étape de sa réalisation. Il y a de nombreuses raisons à cela, qui relèvent du bon sens et de la gestion efficace d’un projet. Mais il y en a une incontournable : Savoir si notre application fournissait des résultats fiables n’était pas si évident, pour nous qui ne sommes pas des experts en statistique ! Nous avons donc élaboré plusieurs jeux de tests, dont les solutions étaient connues et certifiées. Ces jeux nous ont servi de gabarit pour nos développements. Nous les avons utilisés à chaque étape de validation et Dieu sait combien de fois nous avons annoncé à la cantonade qu’il ferait probablement beau demain et combien de fois nous nous sommes consternés devant le problème de l’ivresse au volant.

12.3 Recette avec le Client : la Phase 1 Le 19 avril 2005, notre client et tuteur M Guillaume Schachtele, est venu réceptionner son produit. La recette s’est déroulée en trois étapes Présentation générale de l’application. Démonstration de l’application au travers des IHM Réponses aux questions

En conclusion, M Guillaume Schachtele était très satisfait de notre travail. Les exigences initiales avaient été respectées : nous avions bien conçu et réalisé une application opérationnelle, générique, modulaire et ouverte. Elle s’inscrit dans la logique d’un développement de plus grande envergure pouvant être repris l’année prochaine dans le cadre des projets de Master CCI. Ce qui nous ferait très plaisir.

42/46


13 Difficultés rencontrées Tout au long de ce rapport nous avons déjà abordé certaines difficultés rencontrées et les stratégies mises en œuvre pour y faire face. En voici un résumé.

13.1 Difficulté du domaine de l’application Faille de conception L’assimilation du domaine statistique nous a pris du temps, et nous avons découvert en cours du développement une fonctionnalité que nous n’avions pas vue au début. Nous avons intégré cette fonction dans notre architecture générale au plus haut niveau. Ce fut assez simple toutefois compte tenu de la cohérence de cette architecture. L’impact au niveau de la réalisation a été minime pour la base de données (ajout d’une table) et le moteur (ajout d’un objet). C’est l’ergonomie des IHM qui a été la plus longue à revoir.

Ergonomie et Vulgarisation L’ergonomie des IHM dépend évidement du profil des utilisateurs. Le théorème de Bayes jongle avec des éventualités qui, vu du référentiel, sont des « conditions » et vu de l’exploitation sont des « cibles ». Après nous être nous même trompés dans la manière de rentrer certains problèmes dans notre application, nous avons remplacé, dans la saisie des cas, ces notions mouvantes de « cible » et « condition » par des termes plus simples comme « connue » et « demandée ».

13.2 Management de projet Démarche unifiée Chacun d’entre nous a apporté à l’équipe son expérience et sa vision d’un projet. Chantal avait l’expérience du développement en équipe dans le cadre de gros projets très structurés et trouvait les conceptions de Michael brouillonnes et floues. Michael avait l’expérience du développement en équipe dans le cadre orienté objet avec une approche en spirale et trouvait la vision de Chantal trop rigide et pas assez réactive. Thierry avait l’expérience du travail en équipe mais dans un cadre d’administration et trouvait nos débats improductifs. Jihad n’avait pas d’expérience du travail en équipe, connaissait bien la programmation en solo et voulait commencer tout de suite à coder. Mais au fil du temps et des discutions nous avons appris à nous connaître et voir les bonnes choses que chacun apportait au projet : le sens de la mesure de Thierry, l’organisation de Chantal ou l’imagination de Michael. Jihad pour sa part a quitté le projet et la formation au mois de janvier si bien que nous n’avons pas eu l’occasion de bien le connaître.

Motivations Dès le début du projet, Jihad nous a fait part de ses doutes sur la pertinence, dans son cursus, de suivre le Master 2 CCI. Son implication

43/46


dans le projet était donc relative. Pour le motiver au maximum, nous lui avons confié un travail très en rapport avec ces intérêts (la technique) de veille technologique et de prospection sur les outils et composants susceptibles de nous servir dans le projet (XML, JDBC, TCP/IP, etc.). Au fil du temps, sa participation à la vie de la formation a diminué, jusqu'à son départ définitif. Une bonne communication avec lui nous a permis d’anticiper son désistement et de le gérer au mieux.

13.3 Environnement technique Le déroulement normal de la formation, nous a apporté quotidiennement de nouvelles connaissances et compétences. Cet environnement technique en mutation constante et rapide a eu deux effets de bord : Avec l’apparition (ou l’apprentissage) de nouvelles technologies ou

méthodes, certaines solutions adoptées ou envisagées initialement pour le projet pouvaient devenir obsolètes avant même leur réalisation.

Inversement, l’apprentissage de certaines technologies pressenties pour le projet arriveraient tard dans le planning du projet.

Pour pallier à ce problème, nous avons utilisé les compétences initiales de chacun sans attendre que tout le monde ait le même niveau dans chaque domaine. Nous avons joué avec notre hétérogénéité pour augmenter le potentiel de l’Equipe.

44/46


14 Conclusions Une bonne équipe c’est avant tout de la communication. Ce projet nous l’aura appris maintes fois. L’élaboration d’un vocabulaire commun, la formulation d’idée, l’écoute des autres, la rédaction, l’explication et la négociation, les langages de programmation, les protocoles, tout est communication. La communication amène l’échange et le partage. Grâce à une entraide et un support mutuel, nous avons renforcé la cohésion de notre équipe ! Chacun de nous a travaillé à 200% et si des moments de fatigue ont existé, notre détermination et la confiance dans notre succès n’a jamais été remise en cause. Chaque projet est un défi, et celui-ci a été nouveau pour nous. Nous avons le sentiment d’avoir vécu une aventure intense et espérons vous faire partagé notre enthousiasme. « Malgré quelques difficultés que nous avons su surmonter, nous pensons avoir correctement atteint nos objectifs, à savoir un logiciel qui correspond au cahier des charges, terminé en respectant les délais et les contraintes fixées par notre tuteur. Nous considérons avoir réussi notre mission et garderons un bon souvenir de notre collaboration même si quelquefois elle a pu être difficile » (Chantal) « Avec du travail, de la méthode, quelques litres de sueur …, ce sujet qui semblait si vaste et inaccessible a été ramené sur le plancher des vaches, je remercie mes colocataires pour leur soutien, et j’en garderai un très bon souvenir. » (Thierry) « Je lève la tête du guidon. Dernière ligne droite, Arrivée en vue, Franchir la ligne. Et je comprends soudain les coureurs cyclistes, leur visage moucheté, leur sourire ahuri, leur satisfaction … » (Michael) Chantal « Madame Cobol », Thierry « Le roi du coupé collé » Michael « L’homme objet »

45/46


15 Index a priori .............................. 18 ACCESS .............................. 27 AIDE.................................. 36 anti-spam ........................... 17 apprentissage ...................... 20 architecture ........................ 23 Bayes ................................ 13 BAYES.MDB.......................... 30 Bayesia .............................. 15 BUGS................................. 15 Cas ................................... 20 Cas général ......................... 20 Cas multiple ........................ 20 Cas simple .......................... 20 Cible ................................. 19 classification ....................... 16 Condition............................ 19 connaissance ....................... 18 Connexion........................... 31 console .............................. 31 coût.................................. 18 data mining......................... 22 debugger ............................ 34 diagramme de classe.............. 33 Difficultés........................... 43 durée................................ 18 Eclipse............................... 31 Ecrans ............................... 35 effervescence ....................... 6 encapsulation ...................... 34 Evénement.......................... 13 Eventualité ......................... 13 exceptions .......................... 34 expérience.......................... 12 Fichier de log....................... 32 GBE .................................. 26 GBE.LOG ............................ 32 Generic Bayesian Engine .... 26, 31 généricité ........................... 12 Hiérarchisation..................... 20 interfaces Homme/Machine ..... 35 JAVA ................................. 31

JBuilder .............................31 JDBC .................................23 JDBC/ODBC .........................26 logique floue .......................17 matériel .............................. 9 MCD ..................................29 MCMC ................................15 Merise................................29 méta données ......................31 modularité ..........................12 moteur.......................... 26, 31 objets « métier » ..................33 ODBC.................................23 Open Source ........................34 OpenBUGS...........................15 orientation Objet ..................34 ouverture ...........................12 PCB...................................24 Phasage..............................26 phases ...............................25 prévisions ...........................17 prix ..................................18 Probabilités.........................13 Probayes ............................16 protocole............................24 Reformulation ......................11 requêtes SQL .......................29 risque ...............................18 sdk ...................................31 Serveur WEB ........................24 shell..................................31 Socket TCP/IP ......................32 SQL ...................................26 TCP/IP ...............................24 théorème de Bayes ................13 UML ..................................33 Univers..............................13 versionning..........................10 versions............................... 9 Win’Design ..........................29 WinBUGS ............................15 XML...................................24

46/46

Documents

Mise en oeuvre du thorme de Bayes - Page de Michaël …michael.cambay.pagesperso-orange.fr/bayes/Rapport Projet Bayes CCI... · de déterminer les affinités avec un sujet mais